Tiden det tar för en angripare att utnyttja en nyupptäckt sårbarhet krymper för varje år. I takt med att AI-drivna verktyg för exploateringsutveckling blir vanligare krymper fönstret från det att en sårbarhet publiceras till dess att den utnyttjas i praktiken. I dag handlar det ofta om dagar snarare än veckor. För IT-avdelningen är slutsatsen tydlig: patchar behöver rullas ut snabbare.
Men här uppstår en klassisk konflikt. En patch kan lösa ett säkerhetsproblem, men den kan också orsaka ett nytt. Innan en patch rullas ut i hela organisationen behöver du känna dig trygg med att den faktiskt är stabil. Frågan är hur du hinner göra den bedömningen i en takt där nya sårbarheter dyker upp nästan dagligen, samtidigt som tiden för att granska varje enskild patch blir allt kortare.
Att lösa det manuellt genom att sätta fler personer på uppgiften skalar inte i längden. Det är därför autonom patchhantering blivit ett allt viktigare verktyg i IT-avdelningens arsenal. Målet är inte att ta bort människan ur processen, utan att ge tekniker bättre beslutsunderlag så att varje enskild bedömning tar kortare tid.
Från magkänsla till pålitlighetspoäng
Traditionellt har bedömningen av om en patch är säker att rulla ut byggt mycket på erfarenhet och magkänsla: Har den här leverantören historiskt levererat stabila patchar? Finns det kända problem kopplade till just den här uppdateringen?
Med autonom patchhantering vägs den här typen av signaler samman till en pålitlighetspoäng baserad på leverantörens historik, tillgänglig benchmarkdata och telemetri från din egen miljö eller från andra organisationer som kör samma patch. Det ger en snabbare och mer datadriven första bedömning än att förlita sig på enskilda teknikers erfarenhet.
Poängen är dock precis vad namnet antyder: en indikator, inte en garanti. Därför behöver de flesta organisationer fortfarande testa patchar i en testgrupp innan de går vidare. Problemet är att en testgrupp sällan speglar den verkliga produktionsmiljön fullt ut. Den är för liten, för homogen, eller helt enkelt för "ren" jämfört med den rörigare verkligheten på golvet.
Dynamiska utrullningsringar istället för manuella scheman
Ett sätt att hantera det här är att låta systemet själv definiera utrullningsringar och tidsplan baserat på risk och beteende hos enheterna, istället för att en tekniker manuellt ska sätta upp scheman för varje patch.
En vanlig modell delar in enheterna i fyra steg, där risken trappas upp i takt med att patchen bevisar sig stabil:
- Canary-ringen – ett fåtal enheter med låg verksamhetsrisk. Patchas först, för att snabbt upptäcka uppenbara problem.
- Early adopters – en bredare mix av enhetstyper, fortfarande utan kritiska system. Testar patchen i lite mer verklighetstrogen miljö.
- Generell population – majoriteten av organisationens enheter. Får patchen först när den klarat sig genom de två tidigare stegen.
- Kritisk ring – produktionsservrar, ledningens enheter och andra verksamhetskritiska system. Patchas sist, och bara om patchen visat sig stabil hela vägen.
Fördelen är att risken trappas upp stegvis och automatiskt, utan att någon behöver sitta och manuellt bedöma vilka enheter som ska ingå i vilken grupp för varje enskild patch.
Störningar för slutanvändaren - den bortglömda kostnaden
Det pratas mycket om att en dålig patch kan orsaka driftstörningar. Även en patchutrullning som fungerar som avsett kan skapa frustration om den stör användaren mitt i arbetet, till exempel genom en omstart under ett viktigt möte eller försämrad prestanda under en presentation.
Här spelar tajmning stor roll. Genom att rulla ut patchar när enheten är inaktiv istället för mitt i användarens arbetsflöde minskar den upplevda störningen avsevärt. Där det inte går att styra tajmningen fullt ut är en självbetjäningsportal ett bra komplement, så att användaren själv kan välja när patchen ska installeras.
Oavsett om patchen installeras autonomt i bakgrunden, under enhetens inaktiva tid eller när användaren själv väljer det, bör målet vara detsamma: slutanvändarens upplevelse ska förbättras eller förbli helt opåverkad. En patch ska aldrig skapa mer störning.
Flaskhalsen är fortfarande testningen
De senaste årens utveckling inom autonom patchhantering har redan tagit många organisationer från patchcykler på flera månader till cykler som tar några dagar. Ändå räcker det sällan. Säkerhetsteamet behöver kortare ledtider, och med goda skäl: i dagens hotlandskap kan även några dagar räcka för att en angripare ska utnyttja en sårbarhet.
Anledningen till att det fortfarande tar dagar snarare än timmar är att den verkliga verifieringen bygger på att vänta: vänta på att användarnas inaktiva tid ska infinna sig, vänta på att användare hämtar hem patchar via självbetjäningsportalen, vänta på att medarbetare arbetar igenom sin vanliga arbetsdag och eventuellt rapporterar problem. I bästa fall får du svar inom ett dygn. I sämsta fall dröjer det veckor.
Nästa steg för IT-avdelningen är att testa patchar snabbare utan att sänka kvaliteten på riskbedömningen. En idé som börjar diskuteras i branschen är att simulera verklig användning i en sandlåda som liknar produktionsmiljön, för att korta ner väntetiden från timmar eller dagar till minuter. Det är ingen färdig funktion ännu, men det visar vart utvecklingen är på väg: från att vänta på verkligheten till att simulera den..
Väntan är den egentliga risken
Många IT-avdelningar drar sig för att rulla ut patchar snabbt av rädsla för de störningar en dålig patch kan orsaka. När du väger riskerna mot varandra blir skillnaden tydlig. En misslyckad patchutrullning kan skapa interna störningar. De är irriterande, men oftast hanterbara. Ett obehandlat säkerhetshål under lång tid riskerar däremot dataintrång, förtroendeskada och i värsta fall ekonomiska konsekvenser som är betydligt svårare att återhämta sig från.
Ju snabbare organisationen kan verifiera att en patch är stabil, desto kortare blir tiden systemen står oskyddade utan att det sker på bekostnad av driftsäkerheten.
Vill du se hur automatiserad och riskbaserad patchhantering fungerar i praktiken? Endpoint Central från ManageEngine ger dig full kontroll över patchhantering, sårbarhetshantering och enhetssäkerhet i en och samma lösning – för Windows, macOS och Linux. Andra alternativ: Vulnerability Manager Plus och Patch Manager Plus.
Hör av dig till oss för en genomgång eller en testperiod.
