[KUNSKAPSSAMARBETE] Sårbarhedshåndtering starter ofte som en afgrænset sikkerhedsproces, men fejl i arbejdet får hurtigt konsekvenser for risikostyring, compliance, patch management, interne politikker, KPI’er og endda rapporteringen til ledelsen.
Ud fra det, jeg har oplevet i forskellige organisationer, betragter mange teams sårbarhedshåndtering som en forholdsvis enkel proces. Man kører en scanning, gennemgår resultaterne, klassificerer fundene og opretter sager.
Det, der ofte kommer bag på folk, er, at det ikke er selve identifikationen, der kræver mest arbejde. Den mest tidskrævende del er afhjælpningen.
At kende problemet er ikke det samme som at løse det
Det bliver tydeligt, så snart en sårbarhed når udviklingsteamet.
Det er nemt at fortælle en udvikler: ”Der er en SQL-injektion i denne kode.” Udvikleren vil sandsynligvis være enig i, at det er et problem. Den svære del kommer bagefter: Hvad skal der helt konkret gøres for at løse det?
Den samme udfordring opstår, når en sårbarhed findes i en tredjepartsafhængighed. Biblioteket skal måske patches eller udskiftes, men der findes muligvis ingen patch. En udskiftning kan samtidig påvirke hele systemet. Beslutningen er dermed ikke længere rent teknisk den har direkte forretningsmæssige konsekvenser.
Her kan AI hjælpe, men kun til en vis grad. Teknologien kan vurdere alvorligheden af et fund, analysere resultaterne og foreslå mulige løsninger. Men når afhjælpningen påvirker leverancetider, systemstabilitet eller forretningen som helhed, kan AI kun rådgive. Den endelige beslutning skal stadig træffes af mennesker, som forstår disse afvejninger.
Mål sikkerhedsværktøjer på det arbejde, de eliminerer
En fejl, jeg ofte ser, er, at sikkerhedsværktøjer vurderes på antallet af fund, de genererer. I praksis betyder flere fund sjældent bedre sikkerhed, hvis de samtidig skaber mere arbejde.
Hver ny scanner lover bedre synlighed. Når organisationer løbende tager flere værktøjer i brug, resulterer det ofte i endnu en rapport, endnu et dashboard eller endnu en liste med sårbarheder. Hvis ingeniører skal sammenligne flere rapporter eller undersøge det samme problem flere gange, bliver processen mindre effektiv ikke mere sikker.
Derfor bør fund samles og prioriteres, før der oprettes sager. Hvis den samme sårbarhed opdages af en scanner og senere bekræftes gennem en penetrationstest, bør det stadig resultere i én samlet sag med al relevant kontekst. Målet er ikke at levere alle fund, men at levere den rigtige information til de rigtige personer.
Yderligere værktøjer kan hjælpe med aggregering, deduplikering og automatisering men kun hvis de reducerer dobbeltarbejde frem for at skabe mere af det.
Afhjælpningsmål skal afspejle den operationelle virkelighed
Dmytro Tereshchenko er Vice President hos Sigma Software
Kompleksiteten bliver særligt tydelig, når organisationer fastsætter mål for afhjælpning. Mange ønsker de kortest mulige SLA’er. I praksis skal målene hænge sammen med den måde, sårbarheder identificeres og afhjælpes på.
Hvis en politik eksempelvis kræver, at kritiske sårbarheder skal løses inden for én arbejdsdag, men scanninger kun gennemføres én gang om ugen, kan problemet måske ikke engang opdages inden for tidsrammen.
Releasecyklusser er en anden begrænsning. Selv når en løsning er klar, kan implementeringen være nødt til at vente til næste release. Forretningsmæssige hensyn kan også afgøre, hvornår ændringer kan gennemføres sikkert.
Derfor bør afhjælpningsmål fastsættes med udgangspunkt i organisationens scanningsfrekvens, releaseprocesser og operationelle forhold. Udviklere, DevOps-specialister og systemadministratorer bør inddrages i dialogen, fordi det er dem, der skal implementere løsningerne.
Der findes ikke én universel SLA for sårbarhedshåndtering. Det rette mål afhænger af, hvordan organisationen identificerer, prioriterer, tester og implementerer sikkerhedsrettelser. Det afgørende er at have en proces, der holder sårbarheder synlige, prioriterede og på vej mod afhjælpning.
Flere fundne sårbarheder giver ikke automatisk bedre sikkerhed
Når backloggen indeholder hundredvis eller tusindvis af sårbarheder, er den første reaktion ofte: ”Det her har jeg ikke lyst til at tage fat på.”
Blot at tælle åbne fund forbedrer ikke sikkerheden, fordi det ikke bringer afhjælpningen videre. Teams skal stadig beslutte, hvilke sårbarheder der skal håndteres først, og hvordan de skal håndtere dem, der ikke kan patches.
Prioriteringen kan heller ikke alene baseres på den alvorlighedsgrad, som et værktøj tildeler. En kritisk sårbarhed i et internt system kan udgøre en mindre risiko end en sårbarhed med middel alvorlighed i en interneteksponeret applikation. Prioriteringen bør afspejle, hvor afhjælpningen reducerer organisationens angrebsflade mest effektivt.
Ikke alle sårbarheder kan løses med en patch. I sådanne tilfælde må organisationen reducere risikoen gennem kompenserende kontroller, begrænset adgang eller andre afbødende tiltag.
Konklusion
De fleste organisationer ved allerede, hvor mange af deres svagheder findes. Den egentlige udfordring er at sikre, at sårbarhederne faktisk kan afhjælpes.
Det kræver, at man stiller andre spørgsmål:
- Hvad forhindrer os i at afhjælpe sårbarhederne?
- Vil endnu en kontrol hjælpe teams med at afhjælpe sårbarheder mere effektivt?
- Afspejler vores SLA’er den måde, afhjælpning faktisk foregår på?
Svarene på disse spørgsmål afgør, om sårbarhedshåndtering reducerer risikoen eller blot skaber mere arbejde.
Af Dmytro Tereshchenko er Vice President hos 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
