Flowchart for håndtering af cyberhændelser i SOC og CSIRT

Sådan fungerer det

1. Omdøb banerne, så de passer til jeres struktur

   Erstat Detektion / SOC, incident responder, incident commander, IT-drift og ledelse med det, I faktisk har: en ekstern MSSP, tier 1 og tier 2 delt i hver sin bane, et platform- eller cloud-team i stedet for IT-drift, en forensics-leverandør på retainer. Slet hellere en bane end at lade den stå ubemandet, og læg commanderen ind i responder-banen, hvis det reelt er én person, der gør begge dele.

2. Læg jeres alvorsmatrix på erklæringstrinnet

   Åbn 'Erklær hændelse og fastsæt alvorsgrad', og erstat noten med jeres egne kriterier: hvad der gør en hændelse kritisk, hvem der må erklære en, og hvad hvert niveau forpligter jer til i svartid, bemanding og tilkald uden for arbejdstid. Alvorsgraden driver hver eneste efterfølgende beslutning i diagrammet, så det er værd at være konkret.

3. Fastlæg reglen for godkendelse af inddæmning

   Grenen 'Vil inddæmningen afbryde drift?' virker kun, hvis nogen kan svare på den klokken tre om natten. Skriv ned, hvilke systemer der må isoleres på responderens egen beføjelse, hvilke der kræver en forretningsbeslutning, hvem der har den beslutning, og hvad der sker, hvis vedkommende ikke kan træffes inden for en aftalt tid.

4. Fastlæg reglerne for bevissikring før inddæmningen

   Notér jeres indsamlingsrækkefølge på 'Sikr beviser og diskkopier': hukommelse og aktiv netværkstilstand før disk, disk før arkiverede logs, efter det princip om flygtighed, der er beskrevet i RFC 3227. Skriv, at maskiner isoleres på netværksniveau frem for at blive slukket, og angiv hvor kopierne opbevares, og hvem der kvitterer for dem.

5. Definér, hvad 'truslen er helt fjernet' betyder

   Skriv exit-kriterierne ved siden af beslutningen 'Er truslen helt fjernet?': observationsvinduet uden aktivitet fra angriberen, alle indikatorer fejet igennem hele miljøet, alle kompromitterede adgange roteret, den udnyttede sårbarhed lukket. Beslut også, om fejlgrenen fører tilbage til afdækningen, som her, eller til inddæmningen.

6. Kobl den til processerne på hver side, og versionér den

   Tilføj eksplicitte henvisninger til jeres proces for anmeldelse af databrud, til problem- eller ændringsstyring for de permanente rettelser og til cyberforsikring eller leverandørunderretning, hvis det er relevant. Send derefter diagrammet til godkendelse hos sikkerhedsansvarlig, IT-drift og ledelse, og gem den godkendte version — den plan, I øver, bør være den plan, I udgiver.

Ofte stillede spørgsmål

Hvilke faser består håndteringen af en cyberhændelse af?

Dette diagram bruger seks kolonner: Detektion og triage, Erklæring, Afdækning og inddæmning, Udrensning, Genetablering og Læring. Det svarer til SANS' seks trin — forberedelse, identifikation, inddæmning, udrensning, genetablering og læring — og til NIST SP 800-61 Revision 2, der grupperer arbejdet som detektion og analyse; inddæmning, udrensning og genetablering; samt efterbehandling. Revision 3 omorganiserer vejledningen omkring funktionerne i Cybersecurity Framework 2.0 frem for en fast fasemodel. Forberedelse er ikke tegnet som et trin, fordi det er løbende arbejde — detektionsudvikling, vagtplaner, retainer-aftaler, øvelser — der udføres før en alarm, ikke under den.

Hvordan adskiller det sig fra it-incident management og fra anmeldelse af databrud?

It-incident management genetablerer en afbrudt service og lukker, når brugeren arbejder igen. En sikkerhedshændelse har en modstander i sig, så genetablering er ikke målstregen: det er punktet med størst risiko, hvis truslen stadig er til stede — og derfor lægger dette diagram en verifikationsbeslutning før genetableringen. Anmeldelse af databrud er den anden nabo. Vurderingen af, om personoplysninger er berørt, om en tilsynsmyndighed eller en kunde skal underrettes, og inden for hvilken lovbestemt frist, er juridisk og kommunikativt arbejde på et juridisk ur, og det kører parallelt med den tekniske håndtering frem for inde i den.

Hvorfor kommer bevissikring før udrensning?

Fordi de mest almindelige inddæmningshandlinger ødelægger netop de spor, I får brug for. At slukke en maskine mister malware, der kun ligger i hukommelsen, aktive netværksforbindelser, dekrypteret materiale og injicerede processer. At genopbygge en server, før omfanget er forstået, fjerner de artefakter, der viser, hvordan angriberen kom ind, og hvad vedkommende nåede. Princippet om flygtighed i RFC 3227 er den praktiske regel: sikr hukommelse og aktiv tilstand først, derefter disk, derefter arkiverede logs. I dette diagram ligger bevistrinnet efter isoleringen og før alt udrensningsarbejde, og maskiner isoleres på netværksniveau, så de bliver ved med at køre.

Hvordan afgør man, at truslen er helt fjernet?

Med kriterier, der er skrevet før hændelsen, ikke vurderet i situationen. Typisk: ingen observeret aktivitet fra angriberen i hele miljøet i et aftalt observationsvindue; hver indikator fra undersøgelsen fejet igennem alle maskiner, ikke kun dem, der udløste alarm; hver adgang, der kan være opsnappet, roteret — inklusive service- og maskinkonti; og den sårbarhed eller fejlkonfiguration, der gav den første adgang, lukket. Når svaret er nej, betyder det som regel, at omfanget var forkert, snarere end at oprydningen var sjusket — og derfor fører fejlgrenen her tilbage til 'Kortlæg berørte systemer og konti' frem for til isoleringen.

Hvem godkender inddæmning, der tager et produktionssystem af nettet?

En person med beføjelse til at acceptere den forretningsmæssige konsekvens, og det er sjældent den responder, der opdagede problemet. Dette diagram sender det tilfælde gennem ledelsesbanen, men pointen er ikke navnet på banen: den er, at beslutningen, den navngivne rolle og reserveløsningen, hvis vedkommende ikke kan træffes, er aftalt på forhånd. Mange teams forhåndsgodkender isolering for en defineret liste af systemer og alvorsgrader, så de almindelige tilfælde aldrig venter på et opkald, og reserverer eskalationen til omsætningskritiske eller sikkerhedsrelaterede services. Uden det foregår diskussionen, mens angriberen stadig arbejder.