Når kundens krav om red teaming er mere, end der er brug for: alternativer, I kan foreslå

En kunde skriver i et udkast til kontrakt, at leverandøren hvert år skal gennemføre en red team-øvelse. Jeres leverance er et afgrænset modul, en supporttjeneste eller en integration, og en fuld øvelse mod hele organisationen ville koste mere tid og risiko, end den giver kunden af svar. Det, I kan foreslå, hviler på to spørgsmål: hvad kunden reelt vil vide om jer, og hvilket format der besvarer netop det.

Kort sagt kan purple teaming, en øvelse med udgangspunkt i et allerede sket brud, en smal øvelse om én proces eller en målrettet penetrationstest give kunden et bedre svar end en stor øvelse. Forslaget skal være skriftligt, sige ærligt hvad formatet ikke viser, og accepteres af kunden. Teksten er ikke juridisk rådgivning.

Begynd med kundens spørgsmål

Ordet red teaming dækker over meget i kundekrav, og det er ikke sikkert, at kunden har tænkt over forskellen på en øvelse og en test. Spørg derfor, hvad kunden skal kunne konkludere bagefter. Er det, om I opdager et angreb, om en angriber kan nå kundens data gennem jer, om den tjeneste, kunden bruger, er sikker, eller om I kan håndtere en hændelse? Hvordan man afklarer selve spørgsmålet, er beskrevet særskilt. → Når nogen spørger til red teaming

Svaret afgør forslaget. Et krav, der i virkeligheden handler om tjenestens sikkerhed, besvares ikke bedre af en skjult øvelse, der går gennem jeres receptionist.

Spørg også, hvor kravet kommer fra. Kravet kan være en standardklausul, skrevet til kundens største leverandører og sendt bredt ud. Det kan også bygge på et konkret krav fra kundens tilsyn eller bestyrelse, som kunden selv skal kunne dokumentere over for andre. I det første tilfælde er der som udgangspunkt plads til at forhandle formatet. I det andet skal forslaget kunne bruges af kunden over for den, der stillede kravet, og så er det en god idé at spørge, hvilken dokumentation kunden selv skal aflevere.

Forholdsmæssighed som argument

NIS2-direktivets artikel 21, stk. 1, kræver, at væsentlige og vigtige enheder træffer passende og forholdsmæssige foranstaltninger, og at proportionaliteten vurderes ud fra eksponering for risici, enhedens størrelse og sandsynligheden for hændelser og deres alvor. For de digitale tjenesteudbydere, som forordning (EU) 2024/2690 gælder for, gentager artikel 2, stk. 2, de samme hensyn.

Bestemmelserne giver ikke en leverandør en ret til at sige nej til et kontraktkrav. De giver et sprog til dialogen: kunden skal selv tage hensyn til proportionalitet i sin leverandørstyring, og et krav, der ikke står i forhold til den risiko, jeres leverance udgør for kunden, er svært at begrunde. Er I selv omfattet af NIS2, skal jeres egne foranstaltninger også stå i forhold til risikoen.

Brug argumentet konkret. Beskriv, hvilke data og systemer hos kunden jeres leverance kan nå, hvilke adgange jeres medarbejdere har, og hvad der ville ske, hvis de blev misbrugt. Når risikoen er beskrevet, bliver det tydeligt, hvilket format der rammer den, og kunden får et grundlag for at acceptere et andet format end det, der stod i udkastet. Hvordan kravene ser ud fra en NIS2-leverandørs side mere generelt, beskriver nis2-pentest.dk.

Fire alternativer og det, de besvarer

Purple teaming · et åbent samarbejde mellem angribere og forsvarere, der viser, om overvågningen ser bestemte angrebsmønstre. Passer, når kunden vil vide, om I opdager noget. → Purple teaming
Assumed breach · øvelsen begynder fra en position, en angriber kunne have fået, fx en kompromitteret supportkonto. Passer, når kunden vil vide, hvad der sker, hvis adgangen til kundens miljø misbruges. → Udgangspunkt i et sket brud
Smal øvelse om én proces · fx den proces, hvor jeres medarbejdere får adgang til kundens data. Passer, når en bestemt angrebsvej bekymrer kunden. → En smal red team-øvelse om én forretningsproces
Målrettet penetrationstest · af den tjeneste eller integration, kunden bruger. Passer, når spørgsmålet i virkeligheden handler om tekniske svagheder.

En tabletopøvelse om, hvordan I og kunden håndterer en hændelse sammen, kan supplere alle fire, når kunden er mere optaget af samarbejdet end af teknikken. Nielco IT sælger også phishing- og social engineering-test selvstændigt, hvis kundens bekymring alene handler om medarbejderne.

Et tænkt eksempel

En leverandør af lønsystemer til mellemstore virksomheder får et krav om årlig red teaming fra en ny kunde i energisektoren. Kunden forklarer på et møde, at bekymringen er, om en angriber kan bruge leverandørens supportadgang til kundens lønmiljø. Leverandøren foreslår i stedet en årlig øvelse med udgangspunkt i en kompromitteret supportkonto, med måling af, hvornår leverandørens overvågning opdager misbruget, og en penetrationstest af integrationen hvert andet år.

Forslaget beskriver, hvad formatet ikke dækker: social engineering mod leverandørens medarbejdere og fysisk adgang er ikke med. Kunden accepterer og får det skrevet ind i kontrakten. Eksemplet er tænkt.

Sådan dokumenterer I forslaget

Et mundtligt ja fra en kontaktperson holder ikke, når kundens revisor eller en ny sikkerhedschef spørger, hvorfor kravet ikke blev opfyldt. Skriv forslaget, så det kan læses uden mødet:

Kundens spørgsmål · formuleret i kundens egne ord, som det blev afklaret.
Jeres leverance · hvad kunden bruger, og hvor den kan udgøre en risiko.
Det foreslåede format · omfang, hyppighed, og hvem der gennemfører det.
Grænserne · det, formatet ikke viser, sagt lige ud.
Dokumentationen · hvad kunden får bagefter. → Dokumentation til kunden efter jeres egen red team-øvelse
Revurdering · hvornår kravet tages op igen, fx ved en ny tjeneste eller en hændelse.

Det endelige mål er, at kontraktens ordlyd ændres, så den beskriver det aftalte format. En sideaftale, der modsiger kontrakten, er en svag dokumentation. → Kravet om red teaming står i kontrakten

Det skal I lade være med

At kalde alternativet red teaming · det skaber en forventning, formatet ikke kan indfri.
At afvise kravet uden et forslag · så står kunden tilbage med et krav og intet svar.
At vælge format efter, hvad der er billigst · formatet skal besvare kundens spørgsmål.
At love en fuld øvelse senere uden beslutning · et løfte i en forhandling bliver til en forpligtelse.
At lade aftalen blive mundtlig · kontrakten skal sige det samme som forslaget.

Hvad kan og ikke kan konkluderes

Et velbegrundet alternativ kan give kunden et mere præcist svar på det, kunden er bekymret for, og spare begge parter for en øvelse, der rammer bredere end nødvendigt. Det kan ikke vise det samme som en fuld, skjult øvelse mod hele organisationen, og det fritager ikke for et krav, kunden har pligt til at stille efter sin egen regulering. Hvor kravet kommer fra en finansiel kundes TLPT, gælder andre regler. → Kundens TLPT omfatter jeres tjeneste

Kilder

Direktiv (EU) 2022/2555 (NIS2): artikel 21, stk. 1, om passende og forholdsmæssige foranstaltninger og vurderingen af proportionalitet.
Kommissionens gennemførelsesforordning (EU) 2024/2690: artikel 1 om de omfattede tjenesteudbydere og artikel 2, stk. 2, om et sikkerhedsniveau, der står i forhold til risiciene.

Senest gennemgået: oktober 2026.