Scope i red teaming: bredt mål, klare udelukkelser

Scope i en red team-øvelse ser anderledes ud end i en penetrationstest, og det kan overraske den, der har bestilt pentest i årevis. Hvor pentestens scope kan være en liste over systemer, adresser eller applikationer, der må testes, beskriver red teamets scope, hvad holdet skal forsøge at nå, hvilke veje der er åbne, og hvad der under ingen omstændigheder må røres. Det hviler på organisationens kritiske funktioner, på konkrete mål for hvert scenarie og på en kort, præcis liste over udelukkelser.

Kort sagt: målet er bredt, grænserne er skarpe. Holdet får lov at finde vejen selv, men ikke at gå hvor som helst.

Hvorfor en systemliste ikke rækker

En modstander holder sig ikke til en liste. Vejen til et betalingssystem kan gå gennem en medarbejders indbakke, en leverandørs fjernadgang eller en reception. Hvis scopet kun nævner betalingssystemet, kan holdet enten ikke komme derhen, eller det må bede om lov ved hvert skridt, og så mister øvelsen den realisme, der var grunden til at vælge den. Omvendt giver et scope uden grænser ingen kontrol, og det er white team, der står med ansvaret, når noget uventet bliver berørt.

Den generelle forklaring af scope i en almindelig pentest findes på penetrationtest.dk (penetrationtest.dk). Her handler det om, hvordan sikkerhedsfunktionen formulerer et scope, der giver holdet frihed uden at give slip på kontrollen.

Scopets byggesten

Et brugbart scope for en red team-øvelse kan rumme disse dele:

Kritiske funktioner · de forretningsfunktioner, øvelsen skal belyse, og de vigtigste systemer og processer, der understøtter dem.
Mål · konkrete punkter, holdet skal forsøge at nå i hvert scenarie, også kaldet flag.
Tilladte indgange · om mennesker, bygninger, leverandører og eksterne tjenester må indgå, og på hvilke vilkår.
Lokationer og lande · hvor øvelsen må foregå fysisk og organisatorisk.
Tidsrum · hvornår den aktive test må finde sted, og om der er perioder, der er undtaget.
Udelukkelser · systemer, personer, steder og handlinger, der er holdt ude.
Godkendelse · hvem der har godkendt scopet, og hvornår.

TIBER-DK kræver, at scopedokumentet omfatter alle virksomhedens identificerede kritiske eller vigtige funktioner med de vigtigste systemer og tjenester bag, også dem, der er lagt ud til IKT-leverandører. Udelades en funktion, skal det begrundes. Det er et krav for TIBER-test, men disciplinen er værd at låne. → Kritiske eller vigtige funktioner

Fra funktion til mål

Mål gør scopet konkret. Et mål kan være at opnå en bestemt adgang til et system, der understøtter en kritisk funktion, eller at kunne vise, at en transaktion kunne være ændret. Målet skal kunne dokumenteres, uden at noget faktisk ændres eller fjernes. → Mål for øvelsen

TIBER-DK beskriver flag som de mål, holdet skal stræbe efter at nå under den aktive test, fastlagt for hver kritisk funktion i scope. Rammen lægger også op til, at flagene kan justeres undervejs, efterhånden som efterretningen og testen giver ny viden. Det er en nyttig påmindelse om, at scopet ikke behøver at være fastfrosset, men at ændringer skal godkendes og noteres.

Formuler målene, så de siger noget om forretningen. Et mål som “administratoradgang til et domæne” er let at måle, men svært at forklare for ledelsen. Et mål som “mulighed for at ændre udbetalingsoplysninger i skadesystemet” kan forstås af alle, og det gør det lettere at vurdere, hvor alvorligt et nået mål er. Det tekniske mellemtrin kan stadig stå i holdets plan; scopet skal vise, hvorfor målet betyder noget.

Udelukkelser er en del af scopet

Det, der holdes ude, er lige så vigtigt som det, der er med. Udelukkelser kan skyldes risiko for drift eller sikkerhed, manglende tilladelse fra en tredjepart, hensyn til personer eller simpelthen et bevidst valg om at fokusere. Hver udelukkelse skal være præcis nok til, at holdet kan overholde den, og begrundet, så rapporten kan forklare, hvad øvelsen ikke belyste. → Fredede områder

Undgå den brede formulering “alt uden for X”. Den skaber tvivl, når holdet står i en situation, ingen havde forudset. Det er bedre at beskrive, hvad der er med, og supplere med en kort, konkret liste over det, der er ude. Aftal samtidig, hvad holdet gør, hvis det alligevel støder på noget udelukket: stopper, noterer og kontakter white team, før det går videre ad en anden vej.

Leverandører og systemer, I ikke ejer

Kritiske funktioner kan hvile på leverandører: drift, cloud, overvågning, betalingsformidling. Scopet skal tage stilling til, om leverandørens del indgår, og om der foreligger den nødvendige tilladelse. DORA’s artikel 26 om trusselsbaseret penetrationstest nævner, at testen skal dække flere eller alle kritiske eller vigtige funktioner og udføres på produktionssystemer, og at IKT-tredjepartsudbydere kan indgå. Bestemmelsen gælder udpegede finansielle virksomheder og deres TLPT, ikke frivillige øvelser, men den viser, hvor tæt leverandørerne ligger på scopet i praksis. → Leverandører i øvelsen

Hvem godkender scopet?

Scopet er ikke et teknisk dokument, der kan godkendes af IT alene. Det fastlægger, hvilke risici organisationen accepterer, og hvilke medarbejdere og bygninger der kan blive berørt. I TIBER-DK skal scopet godkendes af Nationalbankens TIBER-team og derefter attesteres af den øverste ledelse i virksomheden. Uden for TIBER er der ingen tilsvarende formel instans, men princippet holder: scopet bør godkendes af den person i ledelsen, der bærer risikoen, og white team bør stå for det i det daglige. → Ledelsens godkendelse

Scopet hænger tæt sammen med spillereglerne. Det ene siger, hvor holdet må bevæge sig, det andet, hvordan. → Rules of engagement i red teaming

Det skal I lade være med

At genbruge pentestens scope · en liste over systemer siger ikke, hvad holdet skal nå.
At formulere mål, der kræver ændringer i drift · målet skal kunne bevises uden skade.
At skrive udelukkelser i vage vendinger · holdet skal kunne overholde dem i en presset situation.
At glemme leverandørerne · de kritiske funktioner stopper ikke ved jeres egne servere.
At lade scopet blive ændret uden spor · hver justering skal godkendes og noteres.

Hvad kan og ikke kan konkluderes

Et godt scope gør det muligt at sige præcist, hvilke funktioner og mål øvelsen har belyst, og hvilke den bevidst har holdt ude. Det kan ikke gøre øvelsen dækkende for hele organisationen, og et mål, holdet ikke nåede, er ikke et bevis for, at vejen er lukket. Den kan bare ikke findes inden for den tid og de regler, øvelsen havde.

Tjekliste til scopet

☐ Er de kritiske funktioner, øvelsen skal belyse, navngivet?
☐ Har hvert scenarie konkrete mål, der kan dokumenteres uden skade?
☐ Er det afklaret, om mennesker, bygninger og leverandører indgår?
☐ Er udelukkelserne præcise og begrundede?
☐ Foreligger tilladelser fra de tredjeparter, der berøres?
☐ Er scopet godkendt af den, der bærer risikoen?

Kilder

Danmarks Nationalbank, TIBER-DK Implementation Document: scopedokumentets indhold, begrundelse for udeladte funktioner, flag pr. funktion, godkendelse og attestation.
DORA, forordning (EU) 2022/2554: artikel 26 om trusselsbaseret penetrationstest, kritiske eller vigtige funktioner, produktionssystemer og IKT-tredjepartsudbydere.

Senest gennemgået: oktober 2026.