Kravspecifikationen til en red team‑øvelse: det, indkøb sender til leverandørerne

Når sikkerhedsfunktionen har fået ja til en red team-øvelse, lander opgaven hos indkøb, og indkøbsfunktionens skabelon er skrevet til varer og driftsydelser med faste specifikationer. En øvelse kan ikke beskrives på den måde, fordi det gode tilbud netop er det, der foreslår en vej til målet, som I ikke selv havde tænkt på. Kravspecifikationen hviler derfor på en enkel arbejdsdeling: I beskriver spørgsmålet, rammen og kravene til styring og leverance; leverandøren foreslår scenarier og fremgangsmåde inden for rammen.

Teksten handler om indkøb i en privat virksomhed, hvor I selv vælger proces og leverandører. Spørgsmålene til de tilbud, der kommer tilbage, er beskrevet for sig. → Valg af leverandør til red teaming

Dokumentet er selv fortroligt

En kravspecifikation til en red team-øvelse fortæller, hvad organisationen frygter, hvilke systemer der er vigtigst, og hvornår forsvaret skal afprøves. Det er oplysninger, en modstander ville betale for. Send den derfor kun til leverandører, I har valgt at spørge, og bed om en fortrolighedsaftale, før de får detaljerne.

TIBER-EU’s vejledning om indkøb af testere anbefaler, at leverandøren bruger et kodenavn for virksomheden i sin interne tilbudsproces og i tilbuddet, fordi folk i sikkerhedsmiljøet kan kende nogen i forsvaret. Rådet gælder de regulerede test, men kan bruges direkte i en privat proces. Hold også navnet på øvelsen og tidspunktet ude af emnefelter og mødeindkaldelser. → Kodenavn og dokumenthåndtering

Formål og spørgsmål

Første afsnit skal beskrive, hvad øvelsen skal svare på, i en eller to sætninger. Et eksempel kunne være: Kan en modstander, der starter med en kompromitteret medarbejderkonto, nå betalingssystemet, og opdager vi det, før der flyttes penge? Spørgsmålet er det, leverandørerne bygger deres forslag på, og det er det, I senere vurderer tilbuddene op imod. → Formålet med øvelsen

Beskriv også baggrunden kort: hvorfor øvelsen gennemføres nu, hvad der er afprøvet før, og hvem der skal bruge resultatet. Det giver leverandøren mulighed for at foreslå et forløb, der passer til jeres modenhed. Nævn også, hvem der er kontaktperson under tilbudsfasen, og at spørgsmål kun stilles via den person.

Rammen uden at låse løsningen

Rammen fortæller, hvad der er inden for og uden for. Den fortæller ikke, hvordan holdet skal arbejde. Gode punkter i rammen er:

Mål og flag · hvilke forretningsfunktioner eller data øvelsen skal forsøge at nå.
Udelukkede områder · systemer, lokationer eller personer, der ikke må berøres.
Mennesker og bygninger · om social engineering og fysisk adgang kan indgå.
Tidsrum · den periode, øvelsen kan ligge i, og perioder, der er fredede.
Trusselsgrundlag · hvilke modstandere I er mest optaget af, eller et ønske om, at leverandøren selv foreslår et grundlag.

Undgå at skrive bestemte teknikker eller værktøjer ind som krav. Det gør tilbuddene ens og fjerner den viden, I køber. Bed i stedet leverandøren beskrive to eller tre scenarier, der kan besvare spørgsmålet, og begrunde valget. → Hvad bestemmer omfanget af en red team-øvelse?

Krav til holdet

Her er indkøbsfunktionens vante krav til kompetence og erfaring relevante, men de skal gøres konkrete:

Navngivne personer · hvem der arbejder i jeres miljø, og hvilken erfaring de har.
Udskiftning · at ændringer i holdet undervejs skal aftales med jer.
Underleverandører · om leverandøren bruger tilknyttede konsulenter, og på hvilke vilkår.
Uvildighed · om leverandøren leverer andre IT- eller sikkerhedsydelser til jer i dag.

Det sidste punkt fylder i TIBER-EU’s vejledning, hvor en leverandør, der har leveret IT- eller sikkerhedsydelser til virksomheden, ikke kan bruges, hvis det skaber en interessekonflikt. Vejledningen anbefaler også at skifte leverandør fra test til test. Ingen af delene er krav uden for rammen, men de er gode spørgsmål. → Tilknyttede konsulenter

Risikostyring, data og sletning

Bed leverandøren beskrive, hvordan risikoen styres: hvordan holdet arbejder sammen med white team, hvilke stopregler leverandøren selv foreslår, hvordan holdets handlinger logges, og hvordan en uventet påvirkning af driften håndteres. Svaret siger mere om leverandørens modenhed end en liste over certificeringer.

Spørg også til forsikring. DORA, forordning (EU) 2022/2554, artikel 27, stk. 1, litra e, kræver ved trusselsbaserede penetrationstest, at testerne er fuldt dækket af relevante erhvervsansvarsforsikringer. Kravet gælder kun de regulerede test, men kan bruges som pejlemærke i en privat kravspecifikation. → Krav til TLPT-testere

Skriv desuden kravene til leverandørens håndtering af jeres oplysninger ind fra starten: hvor materialet opbevares, hvem der har adgang, og hvornår det slettes. TIBER-EU’s vejledning nævner, at leverandøren ikke må bruge oplysninger fra testen til andre kunder, og at parterne skal aftale, hvordan følsomme oplysninger destrueres efter testen. Vejledningens bilag indeholder tjeklister til aftalen med testerne, som kan bruges som inspiration til jeres egne punkter.

Leverancer og vurdering

Beskriv, hvad I forventer at modtage: en rapport med tidslinje og angrebsvej, en ledelsesversion, en gennemgang med forsvaret og en anbefaling til opfølgning. Bed om et eksempel på en anonymiseret rapport, så I kan se, om den kan læses af både forsvaret og ledelsen. Skriv også, om I ønsker et møde, hvor holdet og forsvaret gennemgår forløbet sammen, og hvem der skal deltage fra jeres side. → Red team-rapporten

Fortæl også, hvordan tilbuddene vurderes. Når vægten ligger på forslaget til scenarier, styringen og leverancen, får I tilbud, der kan sammenlignes på det, der betyder noget. TIBER-EU’s vejledning opfordrer til dialog med mulige leverandører under indkøbet, og en afklarende samtale før tilbudsfristen kan spare en runde. En opgavebeskrivelse til en almindelig penetrationstest er beskrevet på penetrationtest.dk.

Det skal I lade være med

At genbruge skabelonen til en penetrationstest · den beskriver systemer, ikke spørgsmål og mennesker.
At skrive teknikker ind som krav · så køber I jeres egen plan i stedet for leverandørens viden.
At sende dokumentet bredt · det fortæller, hvor I er sårbare.
At vurdere på pris alene · forskellen ligger i scenarier, styring og leverance.
At glemme sletning · det skal stå i kravene, ikke aftales bagefter.

Hvad kan og ikke kan konkluderes

En kravspecifikation, der beskriver spørgsmålet og rammen, giver tilbud, der kan sammenlignes på indhold og styring. Den sikrer ikke, at øvelsen bliver god. Det afhænger af leverandørens arbejde og af white team. Den erstatter heller ikke kontrakten, hvor ansvar, tilladelser og stopregler skal stå præcist. → Kontrakten om en red team-øvelse

Tjekliste før afsendelse

☐ Er spørgsmålet formuleret i én eller to sætninger?
☐ Er udelukkede områder og fredede perioder beskrevet?
☐ Beder dokumentet om scenarieforslag i stedet for at fastlægge teknikker?
☐ Er der krav til navngivne personer, underleverandører og uvildighed?
☐ Er fortrolighed, opbevaring og sletning beskrevet?
☐ Er vurderingskriterierne skrevet ned?
☐ Sendes dokumentet kun under fortrolighed og kodenavn?

Kilder

ECB, TIBER-EU Guidance for Service Provider Procurement (2025): afsnit 3.1 om dialog med leverandører, udskiftning i holdet, rotation, uvildighed, kodenavn i tilbudsprocessen og fortrolighed, samt bilag med tjeklister til aftaler.
Forordning (EU) 2022/2554 (DORA): artikel 27, stk. 1, litra e, om erhvervsansvarsforsikring for testere ved TLPT.

Senest gennemgået: oktober 2026.