Rodårsager efter red teaming: fra enkeltfund til mønstre

Efter en red team-øvelse er det let at gå direkte fra fundlisten til rettelserne: denne konto havde for mange rettigheder, denne alarm blev overset, denne medarbejder bekræftede ikke en anmodning. Hver rettelse lukker et hul, men hvis årsagen bag hullet er den samme, dukker et nyt op et andet sted. Arbejdet med rodårsager hviler på at spørge, hvorfor hvert fund kunne opstå, og at lede efter de svar, der går igen på tværs af fundene.

Det korte svar på, hvordan I kommer fra enkeltfund til mønstre, er: grupper fundene, spørg til årsagen bag hver gruppe i både mennesker, processer og teknologi, og placer ansvaret for årsagen hos den, der kan ændre den.

Hvad en rodårsag er

NIST’s ordliste definerer rodårsagsanalyse som en principbaseret, systematisk tilgang til at finde de underliggende årsager til et bestemt sæt risici. Pointen er ordet underliggende. En rodårsag er ikke selve svagheden, men det forhold i organisationen, der gjorde, at svagheden kunne opstå og bestå.

Et eksempel kan gøre forskellen tydelig. Fundet er, at en servicekonto havde administratorrettigheder i flere systemer. Den direkte rettelse er at fjerne rettighederne. Rodårsagen kan være, at ingen ejer servicekonti, at rettigheder ikke bliver gennemgået, eller at en leverandør opretter konti uden at følge jeres proces. Hver af de tre årsager kræver en anden ændring.

Hvad de regulerede rammer forventer

De tekniske reguleringsstandarder for TLPT kræver, at både det røde teams og det blå teams rapport indeholder en analyse af de grundlæggende årsager til vellykkede angreb, og at afhjælpningsplanen for hvert resultat rummer en sådan analyse. TIBER-EU’s vejledning om det røde teams rapport tilføjer, at holdet skal se på mennesker, processer og teknologi samlet og ikke begrænse sig til det tekniske.

For en frivillig øvelse er kravet ikke bindende, men det er et godt mål for, hvad I skal bede om. Holdets bud på rodårsager er et udgangspunkt. Den endelige analyse må organisationen selv lave, fordi holdet kun ser den del af virkeligheden, øvelsen gav adgang til. → Red team-rapporten

Gruppér fundene først

Begynd med at lægge fundene fra holdets rapport og forsvarets rapport ved siden af hinanden. Grupper dem efter, hvad de har til fælles, ikke efter, hvilket system de handler om. Grupper kan fx være:

Rettigheder og konti · fund, hvor adgang var bredere eller ældre end nødvendigt.
Synlighed · fund, hvor data manglede eller ikke blev brugt.
Bekræftelse af identitet · fund, hvor en person eller en proces stolede på en henvendelse uden kontrol.
Ændringer · fund, der opstod i forbindelse med nye systemer, leverandører eller omlægninger.
Reaktion · fund, hvor noget blev set, men ikke ført videre.

Grupperingen kan vise mere end de enkelte fund. Fem fund om rettigheder i fem forskellige systemer peger på noget andet end fem tilfældige svagheder. Angrebsvejen kan hjælpe, fordi den viser, hvilke fund der byggede på hinanden. → Angrebsvejen som rapportens rygrad

Spørg hvorfor, til svaret kan ejes

For hver gruppe spørger I, hvorfor fundene kunne opstå. Svaret på det første hvorfor kan være endnu en svaghed. Fortsæt, til I når et svar, som en bestemt funktion i organisationen kan ændre. Hvis svaret bliver så bredt, at ingen kan eje det, er I gået for langt. “Manglende sikkerhedskultur” er ikke en brugbar rodårsag; “ingen proces for at fjerne adgang, når en medarbejder skifter afdeling” er.

Kategorier, der kan hjælpe med at ramme det rigtige niveau:

Ejerskab · ingen eller uklar ejer af et system, en konto eller en proces.
Proces · en arbejdsgang, der mangler, ikke følges eller ikke passer til virkeligheden.
Arkitektur · en opbygning, der gør det svært at begrænse adgang eller se aktivitet.
Leverandørstyring · krav, der ikke stilles til eller følges op hos leverandører.
Kompetencer og bemanding · opgaver, der ikke kan løses med de folk, der er til rådighed.
Prioritering · kendte svagheder, der er udskudt uden en bevidst beslutning.

Hvem skal sidde med

Rodårsager i organisationen kan ikke findes af sikkerhedsfunktionen alene. Til analysen bør der deltage nogen fra IT-drift, fra den funktion, der ejer de berørte processer, og, hvor fund handler om mennesker, fra HR. Hvis leverandører er en del af årsagerne, kan det være relevant at drøfte analysen med dem bagefter.

Analysen bør ledes af en, der kan holde fokus på årsager frem for skyld. Det er let for en workshop om rodårsager at blive en diskussion om, hvem der burde have gjort hvad. Gør det klart fra start, at rodårsagerne skal skrives om forhold og ansvar, ikke om personer. → Fund om mennesker i rapporten

Tidspunktet betyder også noget. Hvis analysen holdes, før forsvaret har skrevet sin rapport, mangler halvdelen af grundlaget. Hvis den venter for længe, er detaljerne glemt, og de direkte rettelser er allerede sat i gang uden at være koblet til en årsag. Et godt tidspunkt er efter den fælles gennemgang af forløbet, hvor holdet og forsvaret har set hinandens version, og før handlingsplanen bliver endelig. Så kan rodårsagerne skrives ind i planen fra begyndelsen i stedet for at blive tilføjet bagefter.

Fra rodårsag til handling og risiko

Hver rodårsag skal have en ejer og en beslutning, ligesom de enkelte fund. Forskellen er, at ændringerne tager længere tid og kan kræve ressourcer, budget eller ændringer i aftaler. Det gør rodårsagerne til et naturligt emne for ledelsen og for risikostyringen, også når de enkelte fund for længst er rettet. En rodårsag, der ikke kan rettes inden for en rimelig tid, bør registreres som en risiko med en ejer. → Fra øvelse til risikoregister

Den direkte rettelse af det enkelte fund skal ikke vente på, at rodårsagen er løst. Begge dele hører hjemme i handlingsplanen, men med forskellige tidshorisonter. → Handlingsplan efter red teaming

Det skal I lade være med

At stoppe ved den direkte rettelse · så dukker samme type fund op igen.
At gøre rodårsagen til en person · årsager handler om forhold og ansvar.
At formulere årsager, ingen kan eje · brede formuleringer fører ikke til handling.
At lade sikkerhedsfunktionen analysere alene · ejerne af processerne skal med.
At vente med rettelserne, til analysen er færdig · begge spor kan køre samtidig.
At tro, at holdets bud er hele svaret · holdet så kun en del af organisationen.

Hvad kan og ikke kan konkluderes

En rodårsagsanalyse efter en øvelse kan vise mønstre i de fund, øvelsen gav, og pege på forhold i organisationen, der bør ændres. Den kan ikke vise alle årsager til svagheder i jeres miljø, fordi øvelsen kun afprøvede bestemte scenarier. Analysen bliver stærkere, når den holdes op mod fund fra pentest, rigtige hændelser og tidligere øvelser, og svagere, hvis den kun bygger på én rapport.

Kilder

NIST CSRC Glossary, root cause analysis: definition af rodårsagsanalyse (kilder: SP 800-30 Rev. 1 og SP 800-39).
Kommissionens delegerede forordning (EU) 2025/1190: artikel 13, stk. 2, litra c, og bilag V og VI om analyse af grundlæggende årsager i rapporter og afhjælpningsplan.
ECB, TIBER-EU Red Team Test Report Guidance (2025): rodårsager ses på tværs af mennesker, processer og teknologi.

Senest gennemgået: oktober 2026.