Opdagelse, eskalering og reaktion: tre ting, øvelsen kan måle

En red team-øvelse uden aftalte målepunkter ender let som en fortælling om, hvor langt holdet kom. Det er den mindst nyttige del af resultatet. Den egentlige værdi ligger i tre spørgsmål om forsvaret: blev aktiviteten opdaget, nåede oplysningen frem til nogen med mandat, og hvad blev der gjort ved den? Svarene hviler på definitioner, som white team og sikkerhedsfunktionen er enige om, før den aktive test begynder, og på en dokumentation, der gør det muligt at sætte et tidspunkt og et forløb på hvert af de tre led.

Hvorfor målingen skal aftales på forhånd

Bagefter er det fristende at definere en opdagelse, så den passer til det, der skete. Hvis en analytiker kiggede på en alarm og lukkede den, var det så en opdagelse? Hvis vagthavende nævnte mistanken på et morgenmøde, men ingen skrev den ned, var det en eskalering? Uden en aftale på forhånd bliver svaret et spørgsmål om velvilje, og så kan resultatet ikke bruges til at prioritere.

Målepunkterne hører derfor hjemme i planlægningen, ved siden af målet for øvelsen og rules of engagement. De skal være forstået af white team, af holdet, der skal dokumentere sine skridt, og af den, der skal skrive rapporten. Blue team kender dem ikke før afslutningen. → Målet for øvelsen

Opdagelse: hvad tæller?

NIST’s Cybersecurity Framework 2.0 beskriver detektion som det, at mulige angreb og kompromitteringer bliver fundet og analyseret, og skelner mellem overvågning, der finder uønskede hændelser, og analyse, der karakteriserer dem. Den skelnen er nyttig i en øvelse. En logpost, som ingen har set, er ikke en opdagelse. En alarm, der blev genereret, men aldrig åbnet, er heller ikke.

En brugbar definition kan have flere trin, som hver får sit eget tidspunkt:

Spor registreret · aktiviteten efterlod en logpost eller en hændelse i et overvågningssystem.
Alarm rejst · et system eller en medarbejder gjorde opmærksom på aktiviteten.
Vurderet som mistænkelig · en person tog stilling og fandt, at det var værd at forfølge.
Erklæret som hændelse · forsvaret besluttede at håndtere det som en sikkerhedshændelse.

Trinene gør det muligt at se, hvor kæden brast. Nogle af de vigtigste fund kan ligge mellem første og tredje trin. → Alarmer, der blev overset

Eskalering: hvem fik besked?

Eskalering måles som vejen fra den, der så noget, til den, der kan beslutte. CSF 2.0 har det som et selvstændigt resultat under incident management: hændelser eskaleres eller løftes efter behov. I en øvelse betyder det, at der skal aftales, hvilke roller der regnes som beslutningsniveauer. Det kan være vagthavende i SOC’en, den ansvarlige for IT-driften, CISO’en og den, der kan aktivere beredskabet.

Målingen handler ikke kun om, at beskeden nåede frem, men også om, ad hvilken vej. Gik den gennem de aftalte kanaler, eller ved et tilfælde? Blev overvågningsleverandørens telefon taget? Og blev oplysningen ændret undervejs, så beslutningstageren fik et andet billede end analytikeren? → Eskalering: fra alarm til beslutning

Reaktion: hvad blev der gjort?

Det tredje led er handlingen. Reaktion kan være at undersøge videre, spærre en konto, isolere en maskine, kontakte en leverandør eller aktivere beredskabsplanen. CSF 2.0 placerer inddæmning under incident mitigation, hvor formålet er at forhindre, at en hændelse breder sig.

I en øvelse er reaktionen begrænset af to hensyn: den skal være realistisk, og den må ikke skade driften mere end nødvendigt. Derfor skal målepunktet tage højde for, at white team kan have grebet ind. En reaktion, der blev standset af white team, tæller stadig som en beslutning, og den skal noteres som sådan. → Inddæmning under øvelsen

Notér også, hvad reaktionen ramte, og om den ramte det rigtige. En reaktion mod et system, holdet aldrig var på, er værd at forstå. Hvis forsvaret spærrede en konto, men holdet havde tre andre, er det et andet resultat, end hvis spærringen stoppede forløbet.

Sådan bliver målepunkterne til en måleplan

En måleplan behøver ikke at være lang. Den skal kunne bruges af white team under øvelsen og af rapportskriveren bagefter. Den bør indeholde:

Definitioner · hvad der tæller som opdagelse, eskalering og reaktion, med de trin, I har valgt.
Kilder til tidspunkter · holdets logbog, overvågningssystemernes tidsstempler, sager i hændelseshåndteringen og white teams egne notater.
Ansvar for indsamling · hvem der sikrer, at data fra forsvaret er til stede, når øvelsen er slut, fx hos SOC-leverandøren.
Forhold, der påvirker målingen · leg-ups, pauser, kontrolleret afsløring og personer, der både er i white team og i forsvaret.
Hvad der ikke måles · fx enkeltpersoners præstation eller dele af forsvaret, som ikke er med i scenariet.

Måleplanen er også det dokument, der gør resultatet sammenligneligt med senere øvelser, så vidt det overhovedet er muligt. → Tid til opdagelse og tid til reaktion

Data fra begge sider

En måling bygget på holdets logbog alene viser kun det, holdet gjorde. For at se, hvad forsvaret så, kræves forsvarets egne data: alarmer, sager, beslutninger og kommunikation. TIBER-DK, Nationalbankens ramme for regulerede test, kræver, at blue team efter den aktive test kortlægger sine handlinger ved siden af holdets og for hvert skridt angiver, hvad der blev opdaget, og hvilke logposter der svarer til det. Rammen gælder kun de regulerede test, men tanken kan bruges i enhver øvelse.

Når de to sider lægges sammen, opstår tidslinjen, som er det mest brugbare resultat af hele øvelsen. → Tidslinjen for red og blue team

Det skal I lade være med

At definere målepunkterne bagefter · så bliver de tilpasset forløbet.
At regne en logpost som en opdagelse · spor, ingen har set, er synlighed, ikke opdagelse.
At måle eskalering som “nogen fik det at vide” · notér hvem, hvornår og ad hvilken vej.
At glemme white teams indgreb · en standset reaktion er stadig en reaktion.
At bruge målingen til at bedømme enkeltpersoner · den siger noget om funktionerne.
At lade forsvarets data forsvinde · aftal opbevaring med leverandører, før øvelsen slutter.

Hvad kan og ikke kan konkluderes

Målingen kan vise, hvor langt et bestemt forløb nåede gennem opdagelse, eskalering og reaktion, og hvor det gik i stå. Den kan ikke vise, hvordan forsvaret ville reagere på et andet scenarie, og den giver ikke et samlet modenhedstal. Et forløb, der blev opdaget hurtigt, siger noget om netop det forløb.

Tjekliste til måleplanen

☐ Er opdagelse defineret i trin, så hvert trin får et tidspunkt?
☐ Er det aftalt, hvilke roller der regnes som beslutningsniveau?
☐ Er det beskrevet, hvordan white teams indgreb noteres?
☐ Er kilderne til tidspunkter kendt og synkroniseret?
☐ Er det aftalt med leverandører, at deres data opbevares til afslutningen?
☐ Står det i planen, hvad målingen ikke omfatter?

Kilder

Cybersecurity Framework 2.0, CSWP 29 fra NIST: funktionerne Detect og Respond, herunder eskalering (RS.MA-04) og inddæmning (RS.MI-01).
Danmarks Nationalbank, TIBER-DK Implementation Document: blue teams rapport med opdagede skridt og tilhørende logposter.

Senest gennemgået: oktober 2026.