Red teaming i sikkerhedsprogrammet: ved siden af pentest og audit

Et sikkerhedsprogram med mange testformer kan let blive en kalender fuld af aktiviteter, der hver især giver en rapport, men tilsammen ikke svarer på det, ledelsen vil vide. Red teaming hører hjemme i programmet som den aktivitet, der afprøver, om forsvaret fungerer som helhed over for et konkret scenarie. Den forudsætter, at de andre aktiviteter allerede har gjort deres arbejde, og den giver dem et nyt grundlag at prioritere ud fra.

Svaret på, hvordan testformerne supplerer hinanden, hviler på, at hver af dem besvarer et bestemt spørgsmål. Når spørgsmålene er tydelige, bliver rækkefølgen også tydelig.

Hver aktivitet sit spørgsmål

Det første skridt er at beskrive, hvad hver aktivitet i programmet skal besvare. En enkel opdeling kan se sådan ud:

Sårbarhedsscanning · hvilke kendte svagheder findes i systemerne lige nu?
Penetrationstest · kan svaghederne i et afgrænset system udnyttes, og hvad betyder det?
Audit og kontrolgennemgang · er de aftalte kontroller beskrevet, implementeret og fulgt?
Tabletop-øvelse · ved organisationen, hvem der beslutter hvad under en hændelse?
Purple teaming · kan bestemte handlinger opdages, og hvordan forbedres detektionen?
Red teaming · kan forsvaret opdage, eskalere og standse et realistisk forløb fra start til mål?

Hvordan en penetrationstest afgrænses, og hvad den kan sige, er forklaret på penetrationtest.dk. For sikkerhedsfunktionen er pointen, at ingen af aktiviteterne kan erstatte de andre. En pentest siger ikke, om blue team reagerer. En red team-øvelse giver ikke et fuldt overblik over svagheder i et bestemt system. → Det, red teaming tester

Rækkefølgen betyder noget

Red teaming giver mest, når de grundlæggende ting er på plads. Hvis scanninger og penetrationstest jævnligt viser alvorlige svagheder, som ikke bliver rettet, vil en red team-øvelse sandsynligvis finde de samme svagheder ad en dyrere vej. Det er bedre at lukke dem først. → Åbne fund før red teaming

På samme måde bør organisationen have afprøvet sin beredskabsplan i en tabletop-øvelse, før den bliver udsat for et skjult forløb. Hvis rollerne i en krise ikke er klare, vil red team-øvelsen vise det, men læringen kunne være opnået billigere. → Red teaming eller tabletop

En mulig rækkefølge over en periode er derfor: rette kendte svagheder, afprøve beslutningsgange i en tabletop, styrke detektionen i purple teaming og derefter måle helheden i en red team-øvelse. Resultaterne fra øvelsen fører så tilbage til de andre aktiviteter.

Resultaterne skal føde de andre aktiviteter

En red team-øvelse er mest værd, når dens resultater ændrer resten af programmet. Et fund om, at en bestemt type aktivitet ikke blev opdaget, kan blive til et emne for næste purple team-session. Et fund om, at en leverandørforbindelse gav adgang længere ind end forventet, kan blive til scope for næste penetrationstest. Et fund om, at eskaleringen gik i stå en fredag aften, kan blive til en tabletop om vagtordningen. → Fra fund til processer

Det kræver, at nogen ejer koblingen. Det kan være CISO’en eller den person, der har ansvaret for testprogrammet. Uden en ejer bliver rapporten fra red team-øvelsen en selvstændig leverance, der ikke påvirker, hvad der testes næste gang.

Audit har en særlig rolle her. Hvis øvelsen viser, at en kontrol findes på papiret, men ikke virkede i praksis, er det et input til næste kontrolgennemgang. Omvendt kan audit pege på kontroller, som det giver mening at afprøve i et scenarie. → Revision og red teaming

Programmet i finanssektoren

For finansielle virksomheder omfattet af DORA er programmet delvist beskrevet i forordningen. Artikel 24 kræver, at virksomheder, som ikke er mikrovirksomheder, etablerer, vedligeholder og gennemgår et program for test af digital operationel modstandsdygtighed som en del af IKT-risikostyringen. Efter stk. 6 skal disse virksomheder mindst en gang om året sikre, at der gennemføres passende test af alle IKT-systemer og applikationer, der understøtter kritiske eller vigtige funktioner. → DORA’s testprogram

TLPT efter artikel 26 er den avancerede test, som kun udpegede virksomheder skal gennemføre. For andre finansielle virksomheder kan en red team-øvelse uden for TLPT-rammen indgå i programmet som et frivilligt element. Den må ikke forveksles med TLPT. Teksten er ikke juridisk rådgivning.

Planlæg over året, ikke kun pr. aktivitet

Et program, der er planlagt pr. aktivitet, kan ende med at samle flere tests i samme periode, fordi budgettet skal bruges, eller fordi en revision nærmer sig. Det belaster de samme personer i IT og sikkerhed og gør det svært at følge op.

Planlæg i stedet over en længere periode og tag hensyn til, hvornår hver aktivitet kan give input til den næste. En red team-øvelse bør fx ikke ligge samtidig med en stor penetrationstest af de samme systemer, fordi blue team så ikke kan skelne mellem aktiviteterne, og fordi ressourcerne til opfølgning bliver delt. → Hvor ofte giver red teaming mening?

Ledelsen skal kunne se helheden

Ledelsen kan modtage rapporter fra de enkelte aktiviteter hver for sig. Det gør det svært at se, om programmet som helhed gør organisationen bedre til at modstå et angreb. Saml derfor resultaterne i en fælles oversigt, der viser, hvilke spørgsmål der er besvaret i perioden, hvilke svar der gav anledning til bekymring, og hvad der er gjort ved dem.

Red team-øvelsen kan her fungere som en slags samlet kontrol. Hvis forløbet blev opdaget og standset tidligt, understøtter det, at de andre aktiviteter har virket. Hvis det ikke blev opdaget, peger rapporten på, hvor i programmet der mangler noget. Den sammenhæng er lettere at forklare for en direktion end en række enkeltstående rapporter med hver sin skala.

Det skal I lade være med

At lade red teaming erstatte pentest · øvelsen dækker et forløb, ikke alle svagheder i et system.
At bestille red teaming med mange åbne fund · øvelsen viser det, I allerede ved.
At lade rapporten stå alene · resultaterne skal ændre de andre aktiviteter.
At lægge testformerne oven i hinanden · blue team kan ikke skelne, og opfølgningen bliver tynd.
At forveksle en frivillig øvelse med TLPT · de har forskellige rammer og krav.

Hvad kan og ikke kan konkluderes

Et program, hvor hver aktivitet har et tydeligt spørgsmål og en plads i rækkefølgen, gør det lettere at forklare ledelsen, hvad sikkerhedsarbejdet afprøver, og hvor svarene findes. Det kan ikke sikre, at alle risici er afdækket. Et sammenhængende program viser kun det, aktiviteterne er designet til at undersøge, og huller i designet bliver ikke synlige af sig selv.

Tjekliste til programmet

☐ Har hver aktivitet et beskrevet spørgsmål?
☐ Er kendte alvorlige svagheder lukket, før red team-øvelsen planlægges?
☐ Er beslutningsgange afprøvet i en tabletop?
☐ Er der en ejer af koblingen mellem resultater og næste aktivitet?
☐ Er aktiviteterne spredt, så de ikke rammer de samme personer samtidig?

Kilder

DORA, forordning (EU) 2022/2554: artikel 24, stk. 1 og 6, om testprogrammet og årlig test af systemer, der understøtter kritiske eller vigtige funktioner; artikel 26 om TLPT for udpegede virksomheder.

Senest gennemgået: oktober 2026.