Flowchart for håndtering af sikkerhedshændelser

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.