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

Hvad er flowchart for håndtering af cyberhændelser i soc og csirt?

En proces for håndtering af cyberhændelser er det arbejdsforløb, et security operations center eller et CSIRT følger, når en detektion udløses. Triagér og berig alarmen, afgør om det er en ægte hændelse, erklær en hændelse og fastsæt alvorsgraden, sæt en incident commander på, find hvert system og hver konto angriberen har rørt, inddæm uden at ødelægge sporene, fjern truslen, bevis at den er væk, og genetablér først derefter. Denne skabelon tegner sekvensen ud i fem baner: Detektion / SOC, incident responder, incident commander, IT-drift og ledelse.

Det er værd at være præcis om, hvad processen ikke er, for to naboprocesser bliver ofte smeltet sammen med den, og begge bliver svagere af det. Det er ikke it-incident management, som måles på at genetablere en afbrudt service og lukker, når brugeren arbejder igen; en sikkerhedshændelse er ikke slut, når servicen er tilbage, for en for tidlig genetablering kan give angriberen adgangen igen. Det er heller ikke anmeldelse af databrud. Vurderingen af, om personoplysninger er berørt, om en tilsynsmyndighed eller en kunde skal underrettes, og efter hvilken frist, ligger hos juridisk, den databeskyttelsesrådgiver og kommunikation, kører efter lovbestemte frister frem for tekniske, og hører til i den bredere proces for håndtering af sikkerhedshændelser. Dette diagram kører ved siden af det arbejde i stedet for at opsluge det.

Formen følger den sekvens, det meste offentliggjorte materiale deler. SANS' seks trin (forberedelse, identifikation, inddæmning, udrensning, genetablering og læring) passer direkte ind, og NIST SP 800-61 Revision 2 grupperer det samme arbejde 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, men rækkefølgen, en responder faktisk arbejder i, er den samme. Forberedelse er ikke tegnet som en kasse, fordi det er løbende arbejde (værktøjer, vagtplaner, retainer-aftaler, øvelser) og ikke et trin, der udføres under en hændelse. Det, diagrammet reelt skal beskytte, er rækkefølgen: spor før udrensning, verifikation før genetablering, og en navngiven person, der kan godkende at tage et produktionssystem af nettet.

Hvad dette flowchart dækker

I denne skabelon

• Fem rollebaner (Detektion / SOC, incident responder, incident commander, IT-drift og ledelse) på tværs af seks fasekolonner: Detektion og triage, Erklæring, Afdækning og inddæmning, Udrensning, Genetablering og Læring.
• Triagen i SOC-banen: 'Triagér og berig alarmen' fører til beslutningen 'Ægte hændelse?', hvis nej-gren kører 'Luk alarmen og tun reglen', så en falsk positiv ændrer detektionen i stedet for bare at blive afvist.
• Overlevering og kommando: 'Erklær hændelse og fastsæt alvorsgrad' flytter arbejdet fra SOC'et til en incident responder, og 'Udpeg incident commander' navngiver den person, der ejer beslutningerne resten af hændelsen.
• Beslutningen 'Vil inddæmningen afbryde drift?', som ejes af incident commanderen, og hvis ja-gren går gennem 'Godkend driftsafbrydende inddæmning' i ledelsesbanen, før IT-drift kører 'Isolér berørte maskiner og konti'.
• Spor før oprydning: 'Sikr beviser og diskkopier' ligger mellem inddæmningen og udrensningskolonnen, som dækker jagten på flere fodfæster, fjernelse af malware og persistens samt nulstilling af adgange og patchning af de udnyttede sårbarheder.
• Verifikationsbeslutningen 'Er truslen helt fjernet?', der løber tilbage til 'Kortlæg berørte systemer og konti', når den fejler, og derefter genopbygning fra rene backups, overvåget genetablering i SOC-banen, en evaluering af hændelsen og 'Opdatér detektionsregler og playbooks' før lukning.

Hvornår du skal bruge skabelonen

• I driver eller er ved at bygge et SOC eller CSIRT og vil have det tekniske forløb på én side: fra alarmkøen til den detektionsregel, der fanger det næste gang.
• I skriver runbook-delen af jeres beredskabsplan for cybersikkerhed og har brug for, at rækkefølgen mellem inddæmning, bevissikring og udrensning er aftalt før en hændelse i stedet for diskuteret under den.
• I forbereder en skrivebordsøvelse eller en purple team-test og vil have beslutningspunkter, løkker og overleveringer lagt ud, så der er noget at teste imod.
• I har brug for, at sikkerhed, IT-drift og ledelse på forhånd bliver enige om, hvem der må godkende at tage et produktionssystem af nettet, og hvad der sker, når den person sover.
• I onboarder analytikere og vil have eskalationsvejen fra triage til responder til incident commander tegnet eksplicit i stedet for lært ved osmose.

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.