Flowchart for sårbarhedsstyring (fra scanning til verificeret lukning)

Hvad er flowchart for sårbarhedsstyring (fra scanning til verificeret lukning)?

Sårbarhedsstyring er den tilbagevendende driftscyklus, der finder kendte svagheder på tværs af en it-portefølje, afgør hvilke af dem der betyder noget, får dem rettet og beviser det. Udløseren er en tidsplan snarere end en begivenhed: et scanningsvindue åbner mod aktivregistret, og alt nedstrøms afhænger af, at det register er korrekt. Diagrammet herunder følger én cyklus fra ende til anden. Scanningens omfang og dækning af adgangsoplysninger aftales, før noget scannes, den autentificerede scanning køres, leverandørbulletiner ankommer side om side med scannerens eget output, fund deduplikeres og bekræftes, en scoring kombinerer alvorlighed med udnyttelighed og hvad aktivet reelt indeholder, en frist og en navngiven ejer knyttes til fundet, en ændring bærer rettelsen, en gen-scanning enten lukker fundet eller genåbner det, og registret og nøgletallene er det, ledelsen gennemgår, før næste vindue åbner.

Dette er programmet, ikke rettelsen. Det, én systemejer gør inde i en enkelt sag — validere fundet mod sin egen opsætning, vælge mellem en patch, en opgradering, en konfigurationsændring og en udfasning, teste den og udrulle den — er processen for udbedring af sårbarheder, og den hænger på det ene trin "Gennemfør patchen, konfigurationsændringen eller den kompenserende kontrol", der er tegnet her. Selve leverandørpatchen, med sin anvendelighedsvurdering, test uden for produktion, ringudrulning og tilbagerulning, er patch management, en selvstændig cyklus, denne proces trækker på uden at rumme den. Og hele workflowet for sikkerhedsundtagelser — forretningsmæssig begrundelse, kompenserende kontroller, et godkendelsesniveau der følger risikoscoringen, en registerpost og en fornyelsesgennemgang — ligger bag beslutningen "Er en undtagelse godkendt med en udløbsdato?" snarere end inden i den. At holde de grænser synlige er det, der forhindrer ét diagram i at forsøge at være tre. Betragt det følgende som et udgangspunkt, der skal tilpasses under jeres egen sikkerhedspolitik, jeres lovkrav og en kompetent sikkerhedspraktikers dømmekraft.

Fire beslutninger bærer processen. "Er alle aktiver i scope scanbare?" kommer først, fordi dækningsfejl er usynlige: et aktiv, ingen scanningsskabelon når, giver ingen fund, og et rent dashboard og en uscannet portefølje ser identiske ud i rapporten. "Kendt udnyttet eller kritisk alvorlighed?" er prioriteringsopdelingen, og den ligger i analytikerens bane, fordi beviset for udnyttelse er dennes, mens det akutte spor, den åbner, ligger hos sikkerhedsledelsen, som har beføjelsen til at afbryde andet arbejde. "Kan det udbedres inden for SLA'en?" ligger med vilje i banen Systemejer / IT-drift frem for analytikerens — den, der skal gennemføre ændringen, er den, der ved, om vinduet findes — og dens negative gren fører til en undtagelsesbeslutning ejet af sikkerhedsledelsen, fordi det at acceptere risiko er en ledelseshandling og ikke en teknisk. "Viser den nye scanning, at fundet er lukket?" giver processen tilbage til analytikeren, så lukning hviler på bevis frem for på, at nogen markerer en sag som færdig.

Hvad dette flowchart dækker

I denne skabelon

• Fem swimlanes (Sårbarhedsanalytiker, Systemejer / IT-drift, Ændringsansvarlig, Sikkerhedsledelse og Leverandør) fordelt på seks faser: omfang og opdagelse, scanning og indtag, triage, prioritering og tildeling, udbedring og verifikation samt rapportering og gennemgang
• En dækningsport før al scanning: "Er alle aktiver i scope scanbare?" sender manglende adgangsoplysninger og ikke-udrullede agenter tilbage til at blive rettet, fordi et aktiv, scanneren ikke kan autentificere sig mod, rapporterer næsten intet og alligevel tæller som scannet
• To indtagsveje til én kø: scannerens eget output og en leverandørbulletin, der ankommer på trinnet "Udgiv bulletinen og den rettede version", så noget, der annonceres mellem scanningsvinduer, ikke ligger uden ejer til næste cyklus
• Et triagepar, de fleste diagrammer klemmer ned i én boks: "Er fundet bekræftet på aktivet?" sender ubekræftede resultater til "Undertryk som falsk positiv med dokumentation", en lukket terminal, der stadig kræver en begrundelse, en udløbsdato og en godkender
• Scoring og frist som to adskilte handlinger: "Scor efter CVSS, udnyttelighed og aktivets værdi" giver scoringen, "Kendt udnyttet eller kritisk alvorlighed?" adskiller akut arbejde fra det rutinemæssige bånd, og først derefter navngives en ansvarlig for udbedringen
• Lukning på bevis, med to sløjfer og en undvigelsesvej: "Viser den nye scanning, at fundet er lukket?" genåbner alt, der stadig er til stede, "Kan det udbedres inden for SLA'en?" sender videre til "Er en undtagelse godkendt med en udløbsdato?", og forsinkede fund eskaleres, før nøgletallene udgives

Hvornår du skal bruge skabelonen

• I skriver eller omskriver en standard for sårbarhedsstyring og har brug for ét billede af, hvem der scanner, hvem der scorer, hvem der retter, og hvem der accepterer restrisikoen
• Fund forældes forbi deres frister, og ingen kan sige, om de går i stå ved triage, ved tildeling, ved ændringsvinduet eller ved gen-scanningen
• I skal vælge eller udskifte en scanner og vil have processen aftalt, før scanningspolitikker, adgangsoplysningslagre, aktivgrupper og SLA-bånd konfigureres
• Sikkerhed og IT-drift er uenige om, hvad der tæller som udbedret, så gen-scanningen, undtagelsesvejen og eskaleringsvejen skal gøres eksplicitte og have en ejer
• En auditor eller et kundespørgeskema om sikkerhed har bedt om en dokumenteret beskrivelse af, hvordan sårbarheder identificeres, scores, udbedres og verificeres

Sådan fungerer det

1. Omdøb banerne til jeres roller

   Erstat Sårbarhedsanalytiker, Systemejer / IT-drift, Ændringsansvarlig, Sikkerhedsledelse og Leverandør med de roller, der reelt findes hos jer. I et lille team er analytikeren og systemejeren ofte samme person: læg de baner sammen frem for at tegne en overlevering, der kun findes på papiret. Hold alligevel sikkerhedsledelsen adskilt, for undtagelses- og eskaleringsgrenene har brug for en myndighed, der ikke også er den, der retter.

2. Skriv jeres regel for scanningsomfang og dækning

   Angiv hvilke aktiver der er i scope, hvordan de kommer dertil fra registret eller CMDB'en, hvilke der scannes med adgangsoplysninger eller en agent, og hvilke der ikke gør, samt hvor ofte hver gruppe scannes. Notér undtagelserne, og hvem der må give en. Dækning er det tal, der giver mening til alle andre tal i programmet, så sæt det på diagrammet frem for at lade det ligge i en værktøjsindstilling, ingen læser.

3. Definér hvordan et fund scores

   Angiv hvilken alvorlighedsskala I bruger, og hvor scoren kommer fra, og angiv derefter hvad I lægger til den. En alvorlighedsscore beskriver den tekniske effekt; bevis for udnyttelse og aktivets kontekst beskriver, hvor bekymrede I bør være denne uge. Skriv den kombination, I reelt bruger, ned, navngiv dens input, og registrer hvem der må tilsidesætte en scoring, og på hvilket bevis den tilsidesættelse hviler.

4. Fastsæt SLA-båndene, og start uret

   Sæt jeres egne udbedringsfrister på diagrammet, og slet pladsholderne. Aftal hvert bånd med dem, der skal overholde det, og vær eksplicit om, hvornår uret starter, for opdagelsesdato, sagsdato og leverandørens udgivelsesdato giver meget forskellige forældelsesrapporter fra den samme portefølje. Angiv hvad det akutte spor betyder i praksis, og hvem der må åbne det.

5. Aftal undtagelses- og eskaleringsvejen

   Beslut hvem der må godkende en undtagelse, hvilket bevis der følger med den, den længste levetid den må have, og hvilken kompenserende kontrol der skal være aktiv, mens den løber. Aftal derefter eskaleringen for alt, der er forsinket uden en undtagelse: hvem der informeres, ved hvilken alder, og hvad der sker, hvis intet ændrer sig derefter. Begge veje har brug for en navngiven person frem for en fælles postkasse.

6. Beslut hvad der beviser, at et fund er lukket

   Lukning bør hvile på en gen-scanning af det berørte aktiv, ikke på at en sag markeres som færdig. Skriv ned hvilken scanning der beviser det, hvor hurtigt den køres efter en rettelse, og hvad der sker, når gen-scanningen stadig rapporterer fundet. Registrér om en kompenserende kontrol lukker et fund eller kun reducerer det, for de to konventioner giver meget forskellige registre og meget forskellige nøgletal.

7. Afprøv det mod et reelt fund

   Tag to fund fra sidste cyklus, ét der blev lukket til tiden og ét der blev forsinket eller endte som en undtagelse, og følg begge gennem diagrammet. Ethvert trin, folk beskriver, men som ikke er tegnet, og ethvert tegnet trin, der stille springes over i praksis, er den observation, det er værd at handle på, før I udgiver processen til andre.

Ofte stillede spørgsmål

Hvilke trin består en proces for sårbarhedsstyring af?

En scanningscyklus åbner mod aktivregistret, og omfanget og dækningen af adgangsoplysninger fastsættes, før noget køres; aktiver, scanneren ikke kan nå, rettes og tjekkes igen. Den planlagte, autentificerede scanning køres, og leverandørbulletiner, der ankommer mellem scanninger, går ind i den samme kø. Fund deduplikeres og beriges med exploit-data, bekræftes derefter mod aktivet, og alt ubekræftet undertrykkes som falsk positiv sammen med sin dokumentation. Bekræftede fund scores på alvorlighed, udnyttelighed og aktivets værdi, sendes til et akut spor eller et standardfristbånd, og tildeles en navngiven ansvarlig for udbedringen. Den ansvarlige udbedrer enten inden for fristen, gennem et ændringsvindue hvor det er nødvendigt, eller anmoder om en undtagelse med en udløbsdato. En gen-scanning bekræfter lukningen eller genåbner arbejdet. Til sidst opdateres registret, forsinkede fund eskaleres, nøgletal for dækning, forældelse og lukning udgives, og ledelsen gennemgår tendensen før næste cyklus.

Hvad er forskellen på sårbarhedsstyring og patch management?

Sårbarhedsstyring er den cyklus, der opdager svagheder på tværs af en it-portefølje, scorer dem og driver dem frem til en verificeret lukning, uanset hvad løsningen ender med at være. Patch management er én af disse løsninger: den driftscyklus, der tager en leverandørudgivelse, vurderer om den er relevant, tester den, planlægger den og udruller den. NIST's vejledning om planlægning af patch management i virksomheder (SP 800-40 Revision 4) siger det samme fra den anden vinkel, ved at ramme patching som forebyggende vedligehold og som én af flere måder at reagere på den risiko, en software-sårbarhed skaber. Den praktiske konsekvens er, at et sårbarhedsprogram, der kun måles på installerede patches, vil underrapportere sig selv, fordi konfigurationsændringer, opgraderinger, udfasning og kompenserende kontroller også lukker fund, og nogle fund slet ikke har en patch at installere.

Er en CVSS-score nok til at prioritere udbedring?

CVSS, som vedligeholdes af FIRST, scorer teknisk alvorlighed fra 0,0 til 10,0, og de kvalitative bånd i version 3.1 er Lav 0,1-3,9, Middel 4,0-6,9, Høj 7,0-8,9 og Kritisk 9,0-10,0. Version 4.0, udgivet i 2023, bevarer en basisscore og tilføjer eksplicitte Trussels- og Miljøgrupper af målepunkter. Det, CVSS bevidst ikke fortæller jer, er, hvor sandsynlig udnyttelse er, eller hvor meget et givent aktiv betyder for jer. Teams tilføjer som regel to andre signaler: en udnyttelsessandsynlighedsscore som EPSS, også fra FIRST, der estimerer sandsynligheden for, at en sårbarhed bliver udnyttet i praksis inden for de næste tredive dage, og genberegnes dagligt, samt bevis for faktisk udnyttelse som CISA's katalog over kendt udnyttede sårbarheder (Known Exploited Vulnerabilities). Aktivets kontekst er det tredje input, og det er alene jeres. Det er derfor, dette diagram scorer og derefter dirigerer på "Kendt udnyttet eller kritisk alvorlighed?" frem for at sortere en liste efter score.

Hvor ofte bør sårbarhedsscanninger køre, og hvem ejer processen?

Rammeværk er forskellige, så tag frekvensen fra det, der gælder for jer, frem for fra en generel regel. ISO/IEC 27001:2022 Annex A-kontrol 8.8, håndtering af tekniske sårbarheder, kræver, at information om tekniske sårbarheder i systemer i brug indhentes, at eksponeringen vurderes, og at passende foranstaltninger træffes, men den fastsætter intet interval og overlader kadencen til jeres risikovurdering. PCI DSS version 4 er mere præskriptiv for miljøer med kortholderdata: interne sårbarhedsscanninger mindst hver tredje måned og efter enhver væsentlig ændring, udført som autentificerede scanninger, med eksterne scanninger fra en godkendt scanningsleverandør (Approved Scanning Vendor). Mange organisationer scanner langt oftere end minimum, fordi omkostningen ved endnu en scanning er lav. Hvad ejerskab angår, er den sædvanlige opdeling den, der er tegnet her: sikkerhed ejer opdagelse, scoring og rapportering; systemejeren ejer rettelsen; ledelsen ejer undtagelser og eskaleringer. Et program, hvor sikkerhed også ejer udbedringen, har en tendens til at gå i stå, fordi analytikeren hverken har ændringsrettighederne eller den driftsmæssige risiko.

Hvilke registreringer bør en proces for sårbarhedsstyring producere?

Nok til at genskabe ethvert enkelt fund et år senere uden at åbne scanneren. I praksis betyder det en registerpost pr. fund med det berørte aktiv, opdagelsesdatoen, scoringen og hvad der lå til grund for den, den tildelte ansvarlige, fristen, den valgte løsning og beviset for lukning. Ved siden af ligger scanningskonfigurationen og beviset for dækning, så en gennemgår kan se, hvad der var i scope, og hvad der var autentificeret; undertrykkelseslisten, med en begrundelse og en revisionsdato for hver falsk positiv; undtagelsesregistret, med begrundelse, kompenserende kontrol, godkender og udløb; og resultatet af den gen-scanning, der lukkede hvert fund. Rapportering er den sidste registrering: dækning, forældelse i forhold til fristbåndene og lukningsraten over tid, sammen med hvad ledelsen besluttede, når tendensen flyttede sig. En gennemgår vil som regel teste registret mod scanneren frem for omvendt, så uforklarede fund, der findes i værktøjet men ikke i registret, er det almindelige fund.