Eskalering af sikkerhedshændelser: flowchart fra SOC til CISO

Hvad er eskalering af sikkerhedshændelser: flowchart fra soc til ciso?

En proces for eskalering af sikkerhedshændelser er svaret på ét spørgsmål, der gentages på hvert alvorlighedsniveau: hvem skal vide det nu, og hvem har lov til at beslutte, hvad der sker næste gang. Den starter, dér hvor en SOC-analytikers vagt starter, med en alarm, der skal triageres og bekræftes som en reel hændelse frem for støj. Herfra følger diagrammet nedenfor én hændelse op ad stigen, gennem en alvorsbeslutning der afgør, om den bliver hos SOC'et eller flytter til hændelseslederen, en anden beslutning der afgør, om hændelseslederen kan håndtere den alene, eller om CISO'en og kriseledelsen bliver inddraget, et tjek for personoplysninger der overdrager til en dedikeret databrudsproces, hvor det er relevant, en beslutning om, hvorvidt nogen uden for organisationen skal have besked, og en kadence af opdateringer til ledelsen, der kører, indtil hændelsen er bekræftet inddæmmet, og stigen er klatret ned igen.

Dette diagram er bevidst ikke selve den tekniske respons: det indeholder ikke detektionsudvikling, bevishåndtering, inddæmningsmekanik eller udrensningstrin, som hører til en dedikeret proces for håndtering af cyberhændelser, der kører under det. Det er heller ikke den alvorlighedstest, en almindelig it-servicedesk bruger til at vurdere et almindeligt nedbrud, og det er ikke den detaljerede regulatoriske arbejdsgang for et bekræftet brud på persondatasikkerheden, som har sine egne beslutninger og sit eget lovbestemte ur i en separat proces. Det, dette diagram ejer, er smallere og, i en aktiv hændelse, lige så vigtigt: selve eskaleringsvejen, hvem der får besked ved hver tærskel, og punktet hvor det er sikkert at afvikle hændelsen. Betragt det som et udgangspunkt, der tilpasses jeres egen beredskabsplan, jeres regulatoriske forpligtelser og den dømmekraft, som den, der besidder CISO-rollen eller tilsvarende hos jer, udøver, og ikke som en erstatning for nogen af delene.

To beslutninger bærer stigens vægt. 'Når tærsklen for S1/S2?' ligger hos SOC-analytikeren, fordi det er den første person, der ser beviserne, og som kan træffe den afgørelse, og at få den galt i begge retninger enten begraver en alvorlig hændelse i SOC-køen eller vækker CISO'en for en phishing-anmeldelse. 'Er hændelsen inddæmmet?' ligger hos banen for ledelse og kriseledelse af den modsatte grund: inddæmning er en teknisk vurdering, der træffes et andet sted i organisationen, men beslutningen om at afvikle kriseledelsen og stoppe opdateringskadencen tilhører dem, der indkaldte den. Mellem de to ligger beslutningerne 'Personoplysninger involveret?' og 'Kræves ekstern underretning?' med vilje i banen Juridisk / databeskyttelse, fordi spørgsmålet om, hvorvidt der findes en forpligtelse, er et juridisk spørgsmål, selv når udløseren var teknisk.

Hvad dette flowchart dækker

I denne skabelon

• Fem swimlanes (SOC-analytiker, Hændelsesleder, CISO / sikkerhedsledelse, Juridisk / databeskyttelse og Ledelse / kriseledelse) fordelt på syv faser: Detektion og triage, Alvorsklassificering, Responsniveau, Inddæmning og vurdering, Juridisk og anmeldelse, Ledelsestilsyn og Nedtrapning og lukning
• En 'Sand positiv?'-beslutning lige efter triageringen, så en bekræftet falsk positiv sendes tilbage til at justere detektionsreglen frem for blot at blive lukket, og kun en reel hændelse fortsætter op ad stigen
• Den første eskaleringsbeslutning, 'Når tærsklen for S1/S2?', der deler stigen i to: S3- og S4-hændelser bliver hos SOC'et, får en sag og bliver løst uden nogensinde at nå frem til hændelseslederen
• En anden beslutning inde i den eskalerede gren, 'Er alvorsgraden S1?', der afgør, om hændelseslederen og systemejeren håndterer en S2-hændelse alene, eller om CISO'en bliver inddraget, og kriseledelsen bliver aktiveret ved S1
• Beslutningen 'Personoplysninger involveret?' i banen Juridisk / databeskyttelse, hvis ja-gren overdrager hændelsen til en dedikeret databrudsproces frem for at gentage den vurdering på dette diagram
• Beslutningen 'Kræves ekstern underretning?', der fører til underretning af tilsynsmyndigheden, de retshåndhævende myndigheder, kunderne og forsikringsselskabet, hvor hver enkelt gælder, efterfulgt af en kadence af opdateringer til ledelsen styret af 'Er hændelsen inddæmmet?', som løber i en løkke, indtil kriseledelsen kan afvikles

Hvornår du skal bruge skabelonen

• I skriver eller opdaterer en beredskabsplan, og eskaleringsvejen er beskrevet i løbende tekst, som ingen kan følge klokken to om natten
• Jeres SOC og jeres ledelse er uenige om, hvornår CISO'en skal vækkes, og I har brug for at få tærsklen skrevet ned frem for at diskutere den sag for sag
• I bygger et runbook for større hændelser eller krisekommunikation og har brug for, at punktet, hvor jura og ekstern underretning kommer i spil, bliver gjort eksplicit
• En auditor, et forsikringsselskab eller et bestyrelsesudvalg har spurgt, hvordan jeres organisation eskalerer og rapporterer en sikkerhedshændelse, adskilt fra hvordan den bliver teknisk inddæmmet
• I onboarder en ny hændelsesleder eller CISO og vil have niveauerne, overleveringerne og afviklingsbeslutningen på én side frem for lært fra sidste hændelse

Sådan fungerer det

1. Omdøb banerne til jeres reelle eskaleringskæde

   Erstat SOC-analytiker, Hændelsesleder, CISO / sikkerhedsledelse, Juridisk / databeskyttelse og Ledelse / kriseledelse med de roller, der reelt holder hver beslutning hos jer. En mindre organisation lægger ofte hændelseslederen ind i CISO-banen eller sender jura gennem en ekstern advokat; slet eller læg en bane sammen frem for at lade den stå ubemandet.

2. Skriv jeres alvorlighedskriterier på den første beslutning

   Åbn 'Når tærsklen for S1/S2?' og erstat pladsholderen med jeres egne definitioner: berørte systemer eller data, antal brugere eller kunder, om produktionen er forringet, og om der er nogen sikkerhedsmæssig konsekvens. Betegnelserne S1 til S4 på dette diagram er illustrative, ikke en standard, så gør kriterierne konkrete nok til, at to analytikere på forskellige vagter når frem til samme afgørelse.

3. Navngiv, hvem der må erklære hvert niveau

   Angiv på diagrammet, eller i den tilknyttede plan, hvem der kan bekræfte en S2 uden at vække nogen andre, og hvem der kan erklære en S1 og udløse aktiveringen af kriseledelsen. Tilføj en stedfortræder for begge roller og en regel for, hvad der sker, hvis ingen af dem kan træffes inden for en aftalt tid, for eskaleringskriterier, som kun én person kan godkende, svigter netop, når de er mest nødvendige.

4. Bekræft jeres udløsere for personoplysninger og underretning

   Arbejd sammen med jura eller jeres databeskyttelsesansvarlige om at skrive den reelle test bag 'Personoplysninger involveret?' og 'Kræves ekstern underretning?': hvad der tæller som personoplysninger hos jer, hvilke tilsynsmyndigheder, kunder, retshåndhævende myndigheder og forsikringsselskaber der eventuelt skal have besked, og hvad de lovbestemte eller kontraktlige frister er i jeres jurisdiktion. Peg grenen for personoplysninger mod jeres faktiske databrudsprocedure frem for at lade den stå som en etiket.

5. Fastsæt kadencen for opdateringer til ledelsen

   Beslut, hvor ofte kriseledelsen sender en statusopdatering, mens 'Er hændelsen inddæmmet?' bliver ved med at svare nej, hvem der modtager den, og hvad den skal indeholde: nuværende konsekvens, tiltag der er gjort, og det næste beslutningspunkt. Skriv kadencen ned, før en hændelse sker; at beslutte den undervejs er, hvordan opdateringer enten stopper med at blive sendt eller overtager responsen.

6. Definér, hvad inddæmmet og lukket betyder

   Aftal, hvilke beviser der skal til for at svare ja på 'Er hændelsen inddæmmet?', og separat, hvad der skal være opfyldt, før kriseledelsen afvikles, og hændelsen lukkes. De to er ikke samme øjeblik: en hændelse kan være teknisk inddæmmet længe før kommunikation, jura og de berørte forretningsejere er klar til at stoppe med at behandle den som aktiv.

7. Afprøv det mod en tidligere hændelse

   Tag en hændelse, I faktisk har kørt, helst en der nåede CISO'en eller længere, og følg den gennem diagrammet. Notér hvert punkt, hvor den reelle eskalering skete hurtigere, langsommere eller ad en anden vej end diagrammet viser, og brug de forskelle som dagsorden for at opdatere planen før næste hændelse, ikke under den.

Ofte stillede spørgsmål

Hvilke trin består en proces for eskalering af sikkerhedshændelser af?

En SOC-analytiker gennemfører tier 1-triage på alarmen og bekræfter, at den er sand positiv; en falsk positiv lukkes og føres tilbage ind i detektionsreglen. Den bekræftede hændelse holdes op mod S1/S2-tærsklen: S3 og S4 bliver hos SOC'et, får en sag og bliver løst der. En S1- eller S2-hændelse flytter til hændelseslederen, som tjekker, om den specifikt er S1. En S2 håndteres af hændelseslederen og systemejeren. En S1 eskaleres til CISO'en, som leder inddæmningen, mens kriseledelsen aktiveres. Jura tjekker derefter, om personoplysninger er involveret, og overdrager til en databrudsproces, hvor det er tilfældet, og beslutter, om tilsynsmyndigheden, de retshåndhævende myndigheder, kunderne eller forsikringsselskabet skal have besked. Kriseledelsen sender opdateringer i en fast kadence, indtil hændelsen er inddæmmet, og afvikler den derefter med en hændelsesrapport.

Hvordan adskiller dette sig fra en proces for håndtering af cyberhændelser?

De besvarer forskellige spørgsmål om samme hændelse. En proces for håndtering af cyberhændelser er den tekniske livscyklus: triagér alarmen, fastsæt dens omfang, inddæm den uden at ødelægge beviser, udryd truslen, verificér at den er væk, og genetabler, som regel kørt helt inde i SOC'et og it-driften. Denne eskaleringsproces handler om mennesker og beføjelse frem for teknik: på hvilket tidspunkt holder en hændelse op med udelukkende at være SOC'ets beslutning, hvem får besked, mens den klatrer op, og hvem skal godkende, at den klatrer ned igen. I en aktiv S1 kører de to side om side, hvor det tekniske team arbejder med inddæmnings- og udrensningstrinnene, mens denne stige afgør, hvem der ellers er i rummet, og hvad der bliver kommunikeret udadtil.

Hvorfor overdrager "Personoplysninger involveret?" til en anden proces?

Fordi vurderingen bag den beslutning har sine egne tests og sit eget lovbestemte ur, som fortjener deres eget diagram frem for at blive presset ind i én kasse her. Om et brud skal anmeldes til en tilsynsmyndighed, og separat om de berørte personer selv skal have besked, er spørgsmål med forskellige tærskler og forskellige ejere, typisk den databeskyttelsesansvarlige og jura. At holde den vurdering på en dedikeret databrudsproces betyder, at den kan være detaljeret og holdes ajour med reglerne i jeres jurisdiktion, uden at hver ændring også skal tjekkes igen mod eskaleringsstigen. Dette diagram har kun brug for at vide, at overdragelsen skete, og at sagen bliver fulgt.

Hvad er forskellen på alvorlighed og eskaleringsniveau?

Alvorlighed beskriver hændelsens egen konsekvens: hvor meget er berørt, hvor slemt, og for hvor mange mennesker. Eskaleringsniveau beskriver, hvem der aktuelt er ansvarlig for den, og hvem der har fået besked. De to hænger sammen, men er ikke identiske, og det er derfor, dette diagram behandler dem som separate beslutninger frem for én. En hændelse kan blive bekræftet som S1 i alvorlighed, i det øjeblik den forstås, men eskaleringen når først frem til CISO'en og banen for ledelse og kriseledelse, når den alvorlighed rent faktisk er blevet erklæret og sendt videre op; omvendt kan en hændelse, der så mindre ud ved den første triagering, klatre samme stige senere, hvis bevis i stil med "konsekvensen ændrede sig ved næste opdatering" kommer ind, uden at dens oprindelige alvorlighedsmærkat nogensinde bliver genbesøgt.

Hvem beslutter, hvornår kriseledelsen skal afvikles?

Den, der indkaldte den, ud fra beviser frem for presset for at komme videre. Dette diagram placerer med vilje "Er hændelsen inddæmmet?" i banen Ledelse / kriseledelse: inddæmning i teknisk forstand bekræftes af sikkerheds- og it-teamet, der arbejder med hændelsen, men at trappe krisestrukturen ned, stoppe opdateringskadencen og fortælle den bredere organisation, at hændelsen er slut, er en separat afgørelse, der ligger hos den, der ejer kriseresponsen. Skriv exit-kriterierne ned på forhånd, for eksempel en defineret observationsperiode uden gentagelse og hvert berørt system verificeret, så beslutningen ikke bliver truffet udelukkende ud fra, hvor trætte folk i rummet er.