Leverandørscenariet: angrebet kommer gennem en betroet tredjepart

Driftsleverandører, overvågningsleverandører og konsulenter har adgang til jeres systemer, fordi de skal have det. Et leverandørscenarie undersøger, hvad en modstander kan gøre, hvis den adgang bliver misbrugt, og om jeres forsvar opdager det. Scenariet hviler på to forudsætninger: at I ved, hvilke tredjeparter der har adgang til hvad, og at enhver del af øvelsen, der berører en leverandørs egne systemer, er godkendt af leverandøren. Uden den anden forudsætning er scenariet ikke en øvelse, men et angreb på en tredjepart.

For CISO’en er scenariet interessant, fordi leverandørers adgang kan være blevet til gennem projekter og aftaler, som sikkerhedsfunktionen ikke selv har formet. Øvelsen kan vise, om den adgang er synlig og styret.

Et genkendt angrebsmønster

MITRE ATT&CK, der er en offentlig vidensbase over modstanderes adfærd, beskriver misbrug af betroede relationer som en måde at opnå første adgang på. Beskrivelsen nævner IT-leverandører og sikkerhedsleverandører, hvis adgang kan række ud over de systemer, de vedligeholder, og som kan være mindre undersøgt end andre adgangsveje. Kataloget nævner også kompromittering af forsyningskæden, hvor software eller udstyr ændres, før det når frem.

Begge mønstre kan danne grundlag for et scenarie. Det første er lettest at bruge i en red team-øvelse, fordi det kan afgrænses til jeres side af forbindelsen. Det andet kræver i praksis leverandørens aktive deltagelse og bliver hurtigt et projekt for sig.

To måder at bygge scenariet på

Leverandørscenariet kan bygges på to måder, og forskellen er afgørende for tilladelserne.

Leverandørens adgang som udgangspunkt · holdet får en adgang, der svarer til den, leverandøren har til jeres miljø. Øvelsen foregår hos jer, og leverandørens egne systemer berøres ikke. Det er en variant af assumed breach. → Udgangspunktet i assumed breach
Angrebet går gennem leverandøren · holdet skal selv finde vejen via leverandørens systemer eller medarbejdere. Det kræver leverandørens udtrykkelige tilladelse og en aftale om afgrænsning hos leverandøren.

Den første form er den, I selv kan bestemme over. Den anden afhænger af en tredjeparts vilje og egne regler, og det er tvivlsomt, om den kan holdes skjult for leverandørens ledelse.

Hvem der kan give tilladelse til hvad

I kan kun give tilladelse til test af det, I selv ejer eller har ret til at lade teste. En leverandørs systemer, netværk og medarbejdere hører ikke under jeres tilladelse, heller ikke selvom de leverer til jer. → Tilladelser til red teaming

Det betyder i praksis:

Jeres systemer · tilladelsen kommer fra jer.
Adgangen, som leverandøren har til jeres systemer · tilladelsen kommer fra jer, men kontrakten med leverandøren kan indeholde vilkår, der skal respekteres.
Leverandørens egne systemer og medarbejdere · tilladelsen skal komme fra leverandøren, skriftligt og fra en person, der kan give den.
Andre kunder hos leverandøren · de må ikke berøres, og det skal stå i aftalen.

Tilladelsen fra leverandøren bør nævne den aktive periode, de systemer og personer, der må indgå, og den kontaktperson, der har givet den. Gem den sammen med jeres egen tilladelse, så holdet kan fremvise begge, hvis det bliver nødvendigt.

Driftsleverandøren og overvågningsleverandøren kan også have en rolle i forsvaret. Det skal afklares, hvem hos leverandøren der kender til øvelsen, og hvem der ikke gør. → SOC-leverandøren og øvelsen

Afgrænsning ved grænsefladen

Det sværeste i scenariet er at trække grænsen ved grænsefladen. En fjernadgang, en integration eller en delt konto kan ligge hos jer, hos leverandøren eller begge steder. Kortlæg grænsefladerne, før scope godkendes, og skriv for hver af dem, hvem der ejer den, og om den er med. → Scope i red teaming

Hvor det er uklart, hvem der ejer en del, skal den behandles som fredet, indtil det er afklaret. Det er bedre at lade en del ligge end at teste noget, der viser sig at tilhøre en anden.

Aftal også, hvem hos leverandøren white team kan kontakte, hvis øvelsen giver uventede følger. En leverandør, der oplever en forstyrrelse uden at kende årsagen, kan reagere med beslutninger, der rammer flere kunder end jer. Kontaktpersonen skal kunne nås i hele den aktive periode og skal kunne stoppe en eskalering hos leverandøren uden at sprede kendskabet til øvelsen. → Fredede områder

Hvad scenariet kan vise

Et leverandørscenarie kan give svar, som en almindelig leverandørvurdering ikke giver.

Overblik · ved I, hvilke tredjeparter der har adgang, og til hvad?
Rettigheder · svarer adgangen til leverandørens opgave, eller er den bredere?
Synlighed · ser forsvaret, hvad der sker i en leverandørs session, og kan det skelne normalt arbejde fra misbrug?
Reaktion · ved forsvaret, hvem hos leverandøren der skal kontaktes, og kan adgangen lukkes hurtigt uden at stoppe driften?

Den britiske myndighed NCSC har udgivet principper for sikkerhed i forsyningskæden, der handler om at forstå, hvem leverandørerne er, og at få og holde kontrol med dem. Scenariet kan være en praktisk afprøvning af, om den kontrol findes.

Resultaterne fra scenariet hører ikke kun hjemme i sikkerhedsfunktionen. Fund om leverandøradgange kan kræve løsninger i kontrakter, i krav til leverandørens logning eller i processer for, hvornår en adgang åbnes og lukkes. Sørg derfor for, at den, der ejer leverandøraftalerne, får fundene og er med i handlingsplanen.

Finanssektoren: tredjeparter i TLPT

For finansielle virksomheder, der er udpeget til trusselsbaserede penetrationstest efter DORA, gælder særlige regler. Forordningen fastsætter, at virksomheden bevarer det fulde ansvar, når tredjepartsudbydere indgår i testen, og åbner for samlede test, hvor en tredjepartsudbyder indgår i én test for flere finansielle virksomheder. TIBER-DK beskriver, at mindst ét scenarie i en test med flere parter bør dække tredjepartsudbyderens systemer. Det er rammens regler for de regulerede test. → Tredjeparter i TLPT

Det skal I lade være med

At gå ud fra, at jeres tilladelse dækker leverandørens systemer · det gør den ikke.
At lade grænsefladen være uklar · det, der ikke er afklaret, er fredet.
At glemme leverandørens andre kunder · de må ikke berøres.
At overse leverandørens rolle i forsvaret · afklar, hvem der ved besked.
At bruge en leverandørs adgang uden at kende kontraktens vilkår · aftalen kan have regler for brug og logning.

Hvad kan og ikke kan konkluderes

Et leverandørscenarie kan vise, om leverandørers adgang til jeres miljø er kendt, begrænset, overvåget og mulig at lukke. Det kan ikke vise, hvor godt leverandøren selv er beskyttet, medmindre leverandøren har givet tilladelse til at blive testet, og det siger intet om andre leverandører end dem, der indgik.

Tjekliste før scenariet godkendes

☐ Er leverandørerne med adgang kortlagt?
☐ Er det valgt, om scenariet starter med leverandørens adgang eller går gennem leverandøren?
☐ Foreligger skriftlig tilladelse fra leverandøren, hvor dens systemer berøres?
☐ Er grænsefladerne beskrevet, og er uklare dele fredet?
☐ Er det afklaret, hvem hos leverandøren der kender til øvelsen?

Kilder

MITRE ATT&CK, Trusted Relationship (T1199): misbrug af tredjeparter med adgang som en måde at opnå første adgang på.
MITRE ATT&CK, Supply Chain Compromise (T1195): ændring af software eller udstyr, før det når frem.
NCSC, Supply chain security guidance: principper for at få og holde kontrol med leverandører.
DORA, forordning (EU) 2022/2554: artikel 26, stk. 3 og 4 (tredjepartsudbydere i TLPT og samlet test).
Danmarks Nationalbank, TIBER-DK Implementation Document: scenarie, der dækker tredjepartsudbyderens systemer i en test med flere parter.

Senest gennemgået: oktober 2026.