[KUNSKAPSSAMARBETE] Sårbarhetshantering börjar ofta som en avgränsad säkerhetsprocess, men misstag i arbetet får snabbt konsekvenser för riskhantering, regelefterlevnad, patchhantering, interna policys, KPI:er och till och med rapporteringen till ledningen.
Utifrån min erfarenhet från olika organisationer betraktas sårbarhetshantering ofta som en relativt enkel process. Man kör en skanning, granskar resultaten, klassificerar fynden och skapar ärenden.
Det som ofta kommer som en överraskning är att det inte är upptäckten som kräver mest arbete. Den mest tidskrävande delen är att faktiskt åtgärda sårbarheterna.
Att känna till problemet är inte samma sak som att lösa det
Det blir särskilt tydligt när en sårbarhet når utvecklingsteamet.
Det är enkelt att säga till en utvecklare: ”Här finns en SQL-injektion i koden.” Utvecklaren håller sannolikt med om att det är ett problem. Den svåra frågan kommer därefter: Vad behöver egentligen göras för att åtgärda det?
Samma utmaning uppstår när en sårbarhet hittas i ett tredjepartsbibliotek. Biblioteket kan behöva uppdateras eller ersättas, men någon patch kanske inte finns tillgänglig. Ett byte kan dessutom påverka hela systemet. Beslutet är då inte längre enbart tekniskt – det får direkta affärsmässiga konsekvenser.
Här kan AI vara till hjälp, men bara till en viss gräns. Tekniken kan bedöma allvarlighetsgrad, analysera resultat och föreslå möjliga lösningar. Men när åtgärder påverkar leveranstider, systemstabilitet eller verksamheten i stort kan AI endast fungera som rådgivare. Det slutliga beslutet måste fortfarande fattas av människor som förstår dessa avvägningar.
Mät säkerhetsverktyg efter hur mycket arbete de eliminerar
Dmytro Tereshchenko, Vice President på Sigma Software
Ett återkommande misstag jag ser är att säkerhetsverktyg utvärderas utifrån hur många fynd de genererar. I praktiken innebär fler fynd sällan bättre säkerhet om de samtidigt skapar mer arbete.
Varje ny skanner lovar bättre insyn. När organisationer successivt inför fler verktyg leder det ofta till ytterligare rapporter, dashboards och listor över sårbarheter. Om ingenjörer måste jämföra flera rapporter eller utreda samma problem flera gånger blir processen mindre effektiv inte säkrare.
Därför bör fynd samlas, korreleras och prioriteras innan ärenden skapas. Om samma sårbarhet upptäcks av en skanner och senare bekräftas genom ett penetrationstest bör det fortfarande resultera i ett enda ärende med all relevant information samlad. Målet är inte att leverera varje fynd, utan att leverera rätt information till rätt personer.
Ytterligare verktyg kan bidra med aggregering, deduplicering och automatisering – men bara om de minskar dubbelarbete istället för att skapa mer av det.
Åtgärdsmål måste spegla den operativa verkligheten
Komplexiteten blir särskilt tydlig när organisationer definierar mål för hur snabbt sårbarheter ska åtgärdas. Många strävar efter så korta SLA-tider som möjligt. I praktiken måste dessa mål vara förenliga med hur sårbarheter identifieras och åtgärdas.
Om policyn exempelvis kräver att kritiska sårbarheter ska åtgärdas inom en arbetsdag, men skanningar endast genomförs en gång i veckan, kan problemet i värsta fall inte ens upptäckas inom den tidsramen.
Även releasecykler påverkar. Även om en lösning finns färdig kan driftsättning behöva vänta till nästa planerade release. Affärskritiska verksamheter kan dessutom begränsa när förändringar kan genomföras på ett säkert sätt.
Därför bör åtgärdsmål definieras med hänsyn till organisationens skanningsfrekvens, releaseprocesser och operativa förutsättningar. Utvecklare, DevOps-specialister och systemadministratörer bör involveras i diskussionen eftersom det är de som ansvarar för att implementera lösningarna.
Det finns ingen universell SLA för sårbarhetshantering. Rätt målsättning beror på hur organisationen identifierar, prioriterar, testar och driftsätter säkerhetsåtgärder. Det viktiga är att ha en process som håller sårbarheter synliga, prioriterade och i rörelse mot åtgärd.
Fler upptäckta sårbarheter innebär inte automatiskt bättre säkerhet
När backloggen innehåller hundratals eller till och med tusentals sårbarheter är den spontana reaktionen ofta: ”Det här vill jag inte ta tag i.”
Att enbart räkna öppna sårbarheter förbättrar inte säkerheten eftersom det inte driver åtgärdsarbetet framåt. Teamen måste fortfarande avgöra vilka problem som ska hanteras först och hur de ska hantera sådant som inte kan patchas.
Prioriteringen kan inte heller enbart baseras på den allvarlighetsgrad som ett verktyg tilldelar. En kritisk sårbarhet i ett internt system kan innebära mindre risk än en medelhög sårbarhet i en internetexponerad applikation. Prioriteringen bör utgå från var åtgärder ger störst effekt på organisationens attackyta.
Alla sårbarheter kan inte lösas med en patch. I dessa fall måste organisationen minska risken genom kompenserande säkerhetsåtgärder, begränsad åtkomst eller andra former av riskreducering.
Slutsats
De flesta organisationer vet redan var många av deras svagheter finns. Den verkliga utmaningen är att säkerställa att sårbarheterna faktiskt kan åtgärdas.
Det innebär att ställa andra frågor:
- Hur upptäcker vi vad som hindrar åtgärder?
- Kommer ytterligare en kontroll verkligen att hjälpa teamen att åtgärda sårbarheter mer effektivt?
- Speglar våra SLA:er hur åtgärdsarbetet faktiskt går till i praktiken?
Svaren på dessa frågor avgör om sårbarhetshanteringen bidrar till att minska riskerna eller om den bara skapar mer arbete.
Av Dmytro Tereshchenko, Vice President på Sigma Software
Artikeln är ett kunskapsamarbete mellan Sigma Software Group och IT Media Group. Sponsrade inlägg och kunskapsamarbeten är en del av IT Media Groups annonserbjudande. Om du har frågor kring sponsrade inlägg, hör av dig till info@itmediagroup.se
