Eskaleringsprocedure

Også kendt som: eskaleringsvej

Aftalte regler for, hvornår et problem skal sendes videre op til en mere erfaren eller mere ansvarlig person, og til hvem.

Kladde - dette opslag er endnu ikke gennemgået.

Sådan kommer du i gang

De typiske trin i rækkefølge. Tilpas dem til jeres organisation.

Byg en alvorlighedsmatrix med fire eller fem niveauer og objektive kriterier, fx hvilke systemer der er ramt, og hvor kritiske de er, hvor mange brugere eller kunder der er berørt, om personoplysninger kan være involveret, og om der er tegn på en aktiv angriber.
Skriv for hvert niveau, hvem der skal have besked, inden for hvor mange minutter, via hvilken kanal, og hvem der har beslutningskompetencen.
Fastlæg begge veje - funktionel eskalering til folk med mere specialviden, fx tier 2, netværksteamet eller jeres eksterne incident response-leverandør, og hierarkisk eskalering til folk med mere beslutningskompetence, fx den sikkerhedsansvarlige, IT-direktøren eller krisestaben - og lad hver af dem kunne udløses for sig.
Tilføj tidsgrænser, der eskalerer automatisk, fx til den næste i kæden, hvis en alarm ikke er kvitteret inden for 15 minutter, og sæt dem op som eskaleringspolitikker i jeres vagtværktøj.
Send enhver mulig væsentlig hændelse direkte til den, der vurderer væsentlighed efter NIS2, fordi fristen på 24 timer for tidlig varsling løber fra kendskabet, og send alt, der kan involvere personoplysninger, til databeskyttelsesfunktionen med det samme.
Navngiv personer og stedfortrædere, ikke kun roller, og hav telefonnumrene på papir eller i en kanal, der ikke afhænger af de angrebne systemer.
Registrér hver beslutning om eskalering og nedskalering med tidsstempel, og skriv kriterierne for at skalere ned igen.
Afprøv proceduren i øvelser, og gennemgå den efter hver reel hændelse og mindst én gang om året, så matrix og kontaktoplysninger er opdaterede.

Typiske faldgruber

Alvorlighedsniveauer, der er så vage, at alt enten bliver kritisk eller ignoreret.
Eskalering, der afhænger af, om den vagthavende tør vække en direktør om natten, i stedet for af klare regler.
Kontaktoplysninger, der kun ligger i den mail- eller katalogtjeneste, som hændelsen har lagt ned.
At holde en mulig NIS2- eller GDPR-sag tilbage, til den er sikker, så fristen for indberetning allerede er overskredet.

Gode vejledninger

Vejledning til NIS 2-loven - Hændelsesunderretning(åbner i en ny fane) · Styrelsen for Samfundssikkerhed
Plan - Your cyber incident response processes(åbner i en ny fane) · NCSC UK (på engelsk)
Site Reliability Engineering - Managing Incidents(åbner i en ny fane) · Google (på engelsk)

Teknisk uddybning

Eskalering har to dimensioner, som ITIL og de fleste rammer for hændelseshåndtering holder adskilt. Funktionel (horisontal) eskalering flytter en alarm eller hændelse til personer med mere specialiseret viden, fx fra en analytiker på niveau 1 i SOC'en til niveau 2 eller 3, til netværksteamet eller til en ekstern incident response-leverandør på retainer. Hierarkisk (vertikal) eskalering flytter den til personer med mere beslutningskompetence, fx den sikkerhedsansvarlige, IT-direktøren, krisestaben eller bestyrelsen, fordi der skal træffes en beslutning, som den nuværende behandler ikke har mandat til. De fleste procedurer kombinerer begge og udløser dem uafhængigt af hinanden.

Udløserne defineres i en alvorlighedsmatrix, typisk med fire eller fem niveauer (SEV1 til SEV4 eller P1 til P4), med objektive kriterier som berørte systemer og deres kritikalitet, antal berørte brugere eller kunder, bekræftet eller mistænkt involvering af personoplysninger, tegn på en aktiv angriber, lateral bevægelse eller kompromitterede privilegerede konti og opmærksomhed fra medier eller tilsynsmyndigheder. Hvert niveau angiver, hvem der skal informeres, inden for hvilken tid, via hvilken kanal, og hvem der har beslutningskompetencen. Tidsbaseret eskalering er lige så vigtig: bliver en hændelse på et givet niveau ikke kvitteret inden for fx 15 minutter eller inddæmmet inden for en fastsat periode, eskalerer den automatisk. Vagtværktøjer implementerer det som eskaleringspolitikker, der kalder den næste i kæden.

Lovbestemte tærskler hører hjemme i matricen. Efter NIS2 artikel 23, stk. 3, er en hændelse væsentlig, hvis den har forårsaget eller kan forårsage alvorlige driftsforstyrrelser eller økonomiske tab, eller hvis den har påvirket eller kan påvirke andre ved at forvolde betydelig materiel eller immateriel skade, og Kommissionens gennemførelsesforordning (EU) 2024/2690 fastsætter kvantitative tærskler for udbydere af digital infrastruktur og digitale tjenester. Fordi fristen på 24 timer for den tidlige varsling løber fra kendskabet til en væsentlig hændelse, skal proceduren hurtigt sende mulige hændelser videre til den, der vurderer væsentligheden. På samme måde skal enhver hændelse, der kan involvere personoplysninger, straks eskaleres til databeskyttelsesfunktionen, fordi fristen på 72 timer efter databeskyttelsesforordningens artikel 33 løber sideløbende.

Typiske fejl er procedurer, der nævner roller, men ikke personer eller stedfortrædere, kontaktoplysninger, der kun ligger i systemer, som hændelsen har ramt, eskalering, der afhænger af, om den første på vagt tør vække en direktør om natten, og alvorlighedsniveauer, der er så vagt defineret, at alt enten er kritisk eller ignoreres. Kriterier for nedskalering og en registrering af hver eskaleringsbeslutning med tidsstempel hører også til proceduren, fordi de fødes ind i hændelsesrapporten og erfaringsopsamlingen.

Hvad du bør lære først

Alt det, dette bygger på - grundlaget først.

Trussel
→Hændelseshåndtering
→Eskaleringsprocedure

Relationer

Del af: Beredskabsplan
Forudsætter: Hændelseshåndtering
Bruges sammen med: Ledelsesansvar Security operations center (SOC)Triage af alarmer

Kilder og videre læsning

Standarder og officielle tekster

NIST SP 800-61 Rev. 3 - Incident Response Recommendations and Considerations

Kursusmateriale

Cyber Security Fast Track - Kursuskompendium, Modul 6 og 7

Hvor dataene kommer fra

Dette opslag er skrevet af en AI ud fra kilderne ovenfor og er endnu ikke gennemgået af et menneske. Brug det som udgangspunkt, og tjek alt vigtigt mod kilderne.

Se gennemgangskøen Foreslå en rettelse på GitHub Dette begreb som JSON

Test dig selv

Indlæser…