Driftsleverandører og cloududbydere i øvelsen

Når en organisation har lagt dele af driften, overvågningen eller infrastrukturen ud til andre, kommer en red team-øvelse, der skal være realistisk, let til at berøre leverandører. For hver leverandør skal tre ting afklares, før øvelsen begynder: om leverandøren skal give tilladelse, om leverandøren deltager som en del af blue team eller white team, og hvem hos leverandøren der skal kende til øvelsen. Svaret hviler på jeres kontrakter med leverandørerne og på de vilkår, cloududbyderne selv har fastsat for sikkerhedstest.

Leverandørerne kan være både en del af det forsvar, der skal måles, og en part, der skal give lov. Den dobbeltrolle skal håndteres bevidst.

Kortlæg leverandørerne i scenariet

Begynd med scenariet og spørg, hvilke leverandører det berører. En oversigt kan omfatte:

Driftsleverandør · driver servere, netværk eller arbejdspladser for jer.
SOC-leverandør · overvåger og eskalerer alarmer. → SOC-leverandøren og øvelsen
Cloududbyder · leverer infrastruktur eller platform, som jeres systemer kører på.
SaaS-leverandører · leverer forretningssystemer, som holdet kan komme i berøring med.
Ekstern servicedesk · tager imod henvendelser fra medarbejdere. → Servicedesken i øvelsen

For hver leverandør skal det fremgå, hvilke handlinger i scenariet der kan berøre dem, og hvad jeres kontrakt siger om sikkerhedstest. Hvordan en driftsleverandør inddrages i almindelige tekniske test, er beskrevet på penetration-test.dk. En red team-øvelse rejser yderligere spørgsmål, fordi den er skjult og løber længere. SaaS-leverandører er en særlig gruppe. Deres tjenester kan være delt med andre kunder, og deres vilkår kan forbyde test, der ikke er godkendt på forhånd. Hvis scenariet kun berører jeres egen konfiguration og jeres egne brugere, kan det være tilstrækkeligt, men læs vilkårene, før I går ud fra det.

Tilladelse fra driftsleverandøren

Hvis øvelsen berører systemer, som en driftsleverandør ejer eller driver, skal leverandøren give tilladelse til de handlinger, der berører dem. Kontrakten med leverandøren kan indeholde krav om varsling, særlige kontaktpersoner eller begrænsninger på, hvad der må testes. Læs den, før scope låses. → Tilladelser til en red team-øvelse

Tilladelsen kan fx gives af en eller to personer i leverandørens ledelse eller sikkerhedsfunktion, som ikke deltager i den daglige overvågning af jeres miljø. Deres rolle og fortrolighed bør beskrives skriftligt. Hvis leverandøren ikke vil give tilladelse, må den del af scenariet udgå eller ændres. Det er ikke nødvendigvis et tab. Et scenarie, der stopper ved leverandørens grænse, kan stadig måle, om jeres egen overvågning opdager aktiviteten, og om eskaleringen til leverandøren fungerer. Notér i så fald, hvor grænsen gik, så rapporten ikke kommer til at sige mere, end øvelsen dækkede.

Cloududbydernes egne regler

Cloududbyderne har deres egne regler for sikkerhedstest, og de gælder ved siden af jeres tilladelse. Reglerne er forskellige fra udbyder til udbyder og kan ændre sig, så de skal læses for hver øvelse.

Microsoft skriver i sin dokumentation for Azure, at der ikke kræves forhåndsgodkendelse til penetrationstest af egne Azure-ressourcer, men at testen skal følge Microsofts regler for sikkerhedstest, og at red team-aktiviteter er omfattet af de samme regler. Tredjeparter må teste med udtrykkelig skriftlig tilladelse fra ejeren af ressourcerne. AWS skriver, at en række tjenester kan testes uden forhåndsgodkendelse, men at red team-, blue team- og purple team-test samt simuleret phishing kræver, at der indsendes en formular om simulerede hændelser på forhånd.

For sikkerhedsfunktionen betyder det, at der skal være en person, der kender udbydernes regler, og at tidsplanen giver plads til en eventuel godkendelse. → Cloud som scenarie

Leverandøren som en del af blue team

Hvis en SOC-leverandør eller driftsleverandør er en del af den overvågning og reaktion, øvelsen skal måle, er det vigtigt, at de personer, der arbejder med jeres miljø i det daglige, ikke kender til øvelsen. Ellers måler I ikke den reaktion, I ville få ved et rigtigt angreb.

Aftal samtidig, hvad der sker, når leverandøren eskalerer. Leverandørens procedure kan indebære, at den kontakter jer, sin egen ledelse eller i nogle tilfælde andre kunder, hvis en hændelse ser ud til at berøre fælles infrastruktur. White team skal kunne gribe ind, før en eskalering når for langt. Aftal med leverandørens kontaktperson, hvordan en eskalering kan bekræftes som øvelse, og hvem der derefter informerer leverandørens egne vagter. Det skal kunne ske hurtigt og uden at afsløre resten af scenariet. → Stopregler

Varsling uden afsløring

Det kan være nødvendigt at varsle en leverandør om, at der i en periode kan forekomme usædvanlig aktivitet, uden at sige, hvad den består i. En kort, neutral varsling til en enkelt kontaktperson kan være nok til, at leverandøren ved, hvem der skal ringes til, hvis der opstår tvivl.

Varslingen bør ikke indeholde detaljer, der kan nå frem til dem, der overvåger. Brug kodenavnet, og aftal en kanal, hvor kontaktpersonen kan bekræfte en aktivitet over for white team. Overvej også, om varslingen overhovedet er nødvendig. Hvis leverandørens kontrakt ikke kræver den, og hvis white team kan håndtere en eskalering uden, kan det give et mere retvisende billede at undlade den. Beslutningen bør tages bevidst og noteres. → White team

Finansielle virksomheder og TLPT

For finansielle virksomheder, der er udpeget til TLPT efter DORA, indeholder artikel 26, stk. 3 og 4, særlige regler om IKT-tredjepartsudbydere: virksomheden skal sikre deres deltagelse, når de er omfattet, og bevarer det fulde ansvar, og der er under bestemte betingelser mulighed for samlet test. Reglerne gælder TLPT. De siger ikke noget om, hvordan en frivillig øvelse uden for rammen skal organiseres. → Tredjeparter i TLPT

Det skal I lade være med

At gå ud fra, at jeres egen tilladelse dækker leverandørens systemer · leverandøren skal selv sige ja.
At glemme cloududbydernes regler · de gælder ved siden af jeres aftale.
At varsle de personer, der skal måles · så måler I ikke den reelle reaktion.
At lade en eskalering hos leverandøren køre uden plan · den kan nå andre kunder.
At låse scope, før kontrakterne er læst · de kan begrænse, hvad der må testes.

Hvad kan og ikke kan konkluderes

En øvelse, der inddrager leverandørerne bevidst, kan vise, hvordan opdagelse og eskalering fungerer på tværs af organisationens grænser. Den kan ikke vise, hvordan leverandøren beskytter andre kunder, og resultatet siger ikke noget om leverandørens samlede sikkerhed. Hvis en leverandør har været holdt uden for scope, skal det fremgå af rapporten.

Tjekliste før start

☐ Er alle leverandører, scenariet berører, kortlagt?
☐ Har hver driftsleverandør givet skriftlig tilladelse gennem en person uden for den daglige overvågning?
☐ Er cloududbydernes regler læst, og er en eventuel godkendelse indhentet?
☐ Er det aftalt, hvem hos leverandøren der kender til øvelsen?
☐ Kan white team gribe ind i en eskalering hos leverandøren?

Kilder

Microsoft Learn, Penetration testing (Azure): ingen forhåndsgodkendelse for test af egne Azure-ressourcer, regler for sikkerhedstest gælder, red team-aktiviteter er omfattet, tredjeparter kræver skriftlig tilladelse fra ejeren.
AWS, Penetration Testing: tjenester, der kan testes uden forhåndsgodkendelse, og krav om formular om simulerede hændelser ved red, blue og purple team-test og simuleret phishing.
DORA, forordning (EU) 2022/2554: artikel 26, stk. 3 og 4, om IKT-tredjepartsudbydere og samlet test i TLPT.

Senest gennemgået: oktober 2026.