Flowchart for håndtering af sikkerhedshændelser

Hvad er flowchart for håndtering af sikkerhedshændelser?

En proces for håndtering af sikkerhedshændelser er den rækkefølge, en organisation følger fra det øjeblik, noget mistænkeligt bliver opdaget, til hændelsen kan lukkes. Den er bevidst ikke den samme som en almindelig IT-hændelsesproces. Målet er ikke kun at få driften op at køre igen, men at finde ud af, hvad en angriber har gjort, forhindre mere af det, holde beviserne intakte og afgøre, om hændelsen skal anmeldes til en tilsynsmyndighed.

De fleste offentliggjorte processer har det samme skelet. NIST SP 800-61r2 deler forløbet op i forberedelse, detektion og analyse, inddæmning, udbedring og genopretning samt efterbehandling. ISO/IEC 27035 bruger planlægning og forberedelse, detektion og rapportering, vurdering og beslutning, respons og læring. Diagrammet her følger den form og trækker de to beslutninger frem, der giver flest diskussioner midt i en aktiv hændelse: er det overhovedet en sikkerhedshændelse, og er bruddet anmeldelsespligtigt.

Det, teams typisk gør forkert under pres, er rækkefølgen. At inddæmme en maskine ved at slukke den ødelægger beviserne i den flygtige hukommelse. At genopbygge en server, før omfanget er analyseret, betyder, at I ikke længere kan dokumentere, hvad der blev hentet ud. At genåbne driften, før systemerne er verificeret rene, geninficerer resten af miljøet. At aftale rækkefølgen på forhånd (med én bane pr. rolle) er det, der får reglerne til at overleve et opkald klokken tre om natten.

Hvad dette flowchart dækker

I denne skabelon

• Fem rollebaner (Anmelder / detektion, Sikkerhedsteam, Hændelsesleder, IT-drift samt Jura og kommunikation) fordelt på fem faser: Detektion og anmeldelse, Triage og klassificering, Inddæmning, Udbedring og genopretning samt Underretning og evaluering
• Detektion og anmeldelse: mistænkelig aktivitet anmeldes gennem én fælles hændelseskanal og logges derefter af sikkerhedsteamet, som samtidig starter hændelsens tidslinje
• Beslutningen 'Bekræftet sikkerhedshændelse?' efter triage, der sender falske positiver til en lukket registrering og bekræftede hændelser videre til klassificering af alvorlighed og konsekvens
• Beslutningen 'Høj alvorlighedsgrad?', der udpeger en navngiven hændelsesleder ved alvorlige sager og sender alt andet direkte videre til inddæmning
• Inddæmning delt i en akut del ('Isoler berørte systemer') og en varig del, med bevissikring og systemkopier imellem, efterfulgt af analyse af omfang og berørte data, fjernelse af truslen og tjekket 'Er systemerne verificeret rene?', der løber tilbage til isolering, når svaret er nej
• Beslutningen 'Er bruddet anmeldelsespligtigt?' hos jura og kommunikation, som fører til underretning af tilsynsmyndighed og registrerede inden for fristen, og derefter til en evaluering efter hændelsen og en lukning med nedskrevet læring

Hvornår du skal bruge skabelonen

• I skal skrive eller opdatere jeres beredskabsplan for sikkerhedshændelser og har brug for én side, der viser, hvem der gør hvad, i hvilken rækkefølge
• I forbereder en ISO 27001-audit eller en kundes sikkerhedsgennemgang og er blevet bedt om at fremvise en dokumenteret responsproces (diagrammet dokumenterer processen; det påviser ikke i sig selv, at I efterlever standarden)
• I skal køre en skrivebordsøvelse og vil have beslutningspunkter, overleveringer og underretningsfristen tegnet op, så I har noget konkret at teste mod
• I onboarder nye analytikere eller en vagtordning, der også omfatter folk uden for sikkerhedsteamet
• I vil have sikkerhed, IT-drift og jura til at blive enige om deres overleveringer inden en hændelse, ikke midt i den

Sådan fungerer det

1. Omdøb banerne til jeres faktiske roller

   Erstat de fem baner med de roller, I reelt har: SOC eller MSSP, servicedesk, sikkerhedsansvarlig, platformteam, DPO, ekstern forensics-leverandør eller advokat. Findes en rolle ikke hos jer, så slet banen frem for at lade den stå ubemandet.

2. Fastlæg jeres kriterier for alvorlighed

   Åbn boksen 'Klassificer alvorlighed og konsekvens' og erstat kommentaren med jeres egen matrix: hvad gør en hændelse alvorlig, hvem må erklære den, og hvilken responstid forpligter hvert niveau jer til.

3. Ret fristen og tilsynsmyndigheden til

   Ret beslutningen 'Er bruddet anmeldelsespligtigt?', så den nævner de regler, der gælder for jer: GDPR (72 timer til Datatilsynet), NIS2, sektorspecifikke krav og eventuelle kontraktlige varslingsfrister over for kunder, som ofte er kortere end de lovbestemte.

4. Tilføj de kontaktpunkter, folk har brug for kl. 3 om natten

   Skriv hændelseskanalen, vagttelefonen, vagtplanen for hændelsesledere og placeringen af bevismateriale ind i boksenes kommentarfelter, så diagrammet også kan bruges under en hændelse, ikke kun ved en gennemgang bagefter.

5. Juster løkkerne, og tilføj de trin, I mangler

   Tag stilling til, om grenen fra 'Er systemerne verificeret rene?' tilbage til isolering passer til jeres arbejdsgang, og tilføj det, der er særligt for jeres miljø: aktivering af en forensics-aftale, anmeldelse til cyberforsikringen eller en godkendelse af kundekommunikation.

6. Send det til godkendelse, og gem versionen

   Del diagrammet med den sikkerhedsansvarlige, IT-drift og jura til underskrift, og gem derefter den godkendte version. En beredskabsplan er et styret dokument, og den version, I øver på, bør være den version, I har udgivet.

Ofte stillede spørgsmål

Hvilke faser består processen for håndtering af sikkerhedshændelser af?

Diagrammet bruger fem: detektion og anmeldelse, triage og klassificering, inddæmning, udbedring og genopretning samt underretning og evaluering. Det ligger tæt op ad NIST SP 800-61r2, der arbejder med detektion og analyse; inddæmning, udbedring og genopretning; samt efterbehandling. NIST har også en forberedelsesfase, men forberedelse er løbende arbejde (værktøjer, vagtplaner, øvelser, aftaler) frem for et trin, I udfører under en hændelse. Derfor er den ikke tegnet ind i flowet.

Hvad er forskellen på håndtering af sikkerhedshændelser og almindelig IT-hændelsesstyring?

En IT-hændelse er slut, når driften er genoprettet. Det er en sikkerhedshændelse ikke, for der er en modpart. Genopretter I for tidligt, kan I genetablere angriberens adgang, og der følger forpligtelser med, som en ITIL-proces ikke bærer: sikr beviser før genopbygning, fastslå hvilke data der er berørt, og underret tilsyn og registrerede, hvor det kræves. Derfor placerer diagrammet bevissikring og systemkopier før udbedring og lægger en underretningsgren ind efter genopretningen.

Hvem bør være hændelsesleder, og hvornår udpeges vedkommende?

Hændelseslederen bør være den, der har beføjelse til at træffe beslutningerne (tage et produktionssystem offline, hyre ekstern advokat, kontakte kunder), ikke nødvendigvis den mest tekniske person, der er ledig. Rollen koordinerer, den efterforsker ikke. I dette diagram udpeges lederen kun, når beslutningen 'Høj alvorlighedsgrad?' svarer ja; mindre alvorlige hændelser bliver hos sikkerhedsteamet. Ved lange forløb overleveres rollen eksplicit ved hvert vagtskifte.

Hvornår begynder de 72 timer til anmeldelse af et brud?

Efter GDPR løber de 72 timer, fra organisationen bliver bekendt med, at der er sket et brud på persondatasikkerheden, ikke fra angrebets start og ikke fra undersøgelsens afslutning. I må gerne anmelde i etaper, hvis I endnu ikke har det fulde billede. Underretning af de berørte personer er en selvstændig vurdering: den kræves uden unødig forsinkelse, når bruddet sandsynligvis indebærer en høj risiko for dem. Andre regelsæt har andre frister, så skriv den, der gælder jer, ind i beslutningsboksen.