Forretningskritiske SaaS‑tjenester i øvelsen: udbydernes regler og jeres egen del

Kundeoplysninger i et CRM-system, lønsedler i et HR-system og betalinger i et økonomisystem ligger hos udbydere, som I ikke ejer, og som har deres egne regler for, hvad kunder må afprøve. Det kan få SaaS-tjenesterne til at forsvinde ud af scope, selv om de rummer netop det, en modstander vil have fat i. Svaret hviler på en skelnen mellem udbyderens platform og jeres egen del af tjenesten: platformen er ikke jeres at teste, men konti, roller, opsætning, integrationer og overvågningen af dem er jeres, og de kan indgå i scenariet, når udbyderens regler er afklaret.

En red team-øvelse skal nå et mål, der betyder noget for forretningen. Når kronjuvelerne er kundelisten, persondata om medarbejdere eller muligheden for at ændre en leverandørs kontonummer, kan målet ligge i en tjeneste, der tilgås via browser og single sign-on.

Hvis øvelsen stopper ved grænsen til tjenesterne, kan rapporten vise, at holdet nåede en brugerkonto, men ikke hvad kontoen kunne have ført til. Det er netop den del, ledelsen spørger til. Scenarier om identitet og infrastruktur hos en cloududbyder er beskrevet for sig; her er fokus på de færdige forretningsapplikationer. → Cloud og identitet som scenarie

Udbyderens regler kommer først

Hver tjeneste har sine egne vilkår, og de gælder ved siden af jeres tilladelse. Nogle udbydere offentliggør en politik for sikkerhedstest, nogle kræver forhåndsvarsel, og nogle tillader kun bestemte former for afprøvning. Microsofts regler for sikkerhedstest af egne onlinetjenester forbyder fx social engineering rettet mod Microsofts medarbejdere og adgang til andre kunders data, men opfordrer kunder til at afprøve sikkerhedsovervågning og detektion i egen tenant.

For hver tjeneste i scope bør white team afklare:

Findes der en offentliggjort testpolitik? · og hvilken version gælder på øvelsestidspunktet?
Skal udbyderen varsles? · og kan det ske, uden at øvelsen bliver kendt i jeres egen organisation?
Hvad er udelukket? · fx overbelastning, test af udbyderens infrastruktur eller kontakt til udbyderens support.
Hvad siger jeres kontrakt? · den kan indeholde vilkår, der går videre end den offentlige politik.

Findes der ingen politik, så spørg udbyderen skriftligt og gem svaret sammen med tilladelserne. Et mundtligt ja fra en sælger er ikke nok. → Tilladelser til en red team-øvelse

Jeres egen del af tjenesten

Selv når platformen er udelukket, er der meget, der er jeres:

Konti og roller · hvem har administratorrettigheder i tjenesten, og hvem kan tildele dem?
Adgang · er tjenesten koblet til jeres single sign-on, og gælder de samme krav om login som andre steder?
Opsætning · deling, eksport og adgang udefra er indstillinger, I selv har valgt.
Integrationer · tekniske brugere og forbindelser til andre systemer kan have bred adgang og blive glemt.
Overvågning · sender tjenesten de hændelser, jeres forsvar har brug for, og bliver de læst?

Det er her, scenariet finder sin værdi. Spørgsmålet er ikke, om tjenesten kan brydes, men om en modstander med en stjålet konto eller en glemt integration kan nå målet, og om nogen opdager det.

Scenarier, der passer

Tre eksempler på, hvordan en SaaS-tjeneste kan indgå:

HR-systemet som mål · holdet skal vise adgang til et aftalt flag, som white team har placeret som en fiktiv medarbejderpost, uden at åbne rigtige personalesager.
Økonomisystemet i en forretningsproces · holdet forsøger at nå frem til en ændring af stamdata, men flaget ligger før noget gemmes eller godkendes. → Betalingssvindel som scenarie
CRM-systemet som udgangspunkt · en konto i salgsafdelingen er startpunktet, og spørgsmålet er, hvor langt den kan føre mod andre systemer gennem integrationer.

I alle tre tilfælde er det jeres egen tenant og jeres egne data, der indgår. Flag frem for rigtige data mindsker både risikoen og mængden af personoplysninger, holdet kommer i berøring med.

Spor, der ligger hos udbyderen

Den største forskel på en SaaS-tjeneste og et system i eget datacenter viser sig, når forsvaret skal se, hvad der skete. Aktivitetslogs fra tjenesten ligger hos udbyderen, og hvilke hændelser der registreres, hvor længe de gemmes, og om de kan sendes videre til jeres egen overvågning, afhænger af tjenesten og af det abonnement, I har købt. Undersøg det i planlægningen, ikke først når white team skal rekonstruere tidslinjen.

Hvis det viser sig, at login, eksport eller ændring af rettigheder i en forretningskritisk tjeneste ikke når frem til forsvaret, er det et fund, før øvelsen er begyndt. Det kan være klogt at rette det først og lade øvelsen måle, om forsvaret bruger de nye oplysninger. → Detektionsdækning

Hvem skal kende til øvelsen

Systemejeren for en SaaS-tjeneste kan sidde i en forretningsenhed, der har købt tjenesten og administrerer den, og ikke i sikkerhedsfunktionen. Hvis den enhed ikke kender til øvelsen, kan en reaktion på holdets spor ende som en henvendelse til udbyderens support, som så kan reagere efter sine egne procedurer. Overvej, om en enkelt person med administratoradgang skal være med i white team, og aftal, hvad der sker, hvis udbyderen kontakter jer om usædvanlig aktivitet. → Driftsleverandører og cloududbydere i øvelsen

Finansielle virksomheder

For finansielle enheder fastslår DORA, forordning (EU) 2022/2554, i artikel 28, stk. 1, litra a, at enheden til enhver tid har det fulde ansvar for at overholde sine forpligtelser, også når den bruger IKT-tjenester fra tredjeparter. Det taler for, at forretningskritiske SaaS-tjenester ikke uden videre holdes ude af afprøvningen. Hvordan tjenesterne indgår i den samlede plan for afprøvning, kan I se nærmere på under DORA’s testprogram. Teksten er ikke juridisk rådgivning.

Det skal I lade være med

At antage, at en tjeneste er udelukket, fordi den er hos en udbyder · jeres egen del kan afprøves.
At gå videre uden udbyderens regler · og uden at gemme dem sammen med tilladelserne.
At kontakte udbyderens support som led i scenariet · det er udbyderens medarbejdere, ikke jeres.
At hente rigtige persondata som bevis · brug et flag i jeres egen tenant.
At glemme integrationerne · de kan være den bredeste adgang i tjenesten.

Hvad kan og ikke kan konkluderes

Et scenarie med en SaaS-tjeneste kan vise, om jeres konti, opsætning og integrationer giver en modstander en vej til målet, og om forsvaret ser det. Det siger intet om sikkerheden i udbyderens platform, og et negativt resultat i én tjeneste kan ikke overføres til andre.

Tjekliste før scenariet

☐ Er de forretningskritiske SaaS-tjenester kortlagt?
☐ Er udbyderens testpolitik og kontrakt læst for hver tjeneste i scope?
☐ Er varsling af udbyderen afklaret?
☐ Er integrationer og tekniske brugere med i kortlægningen?
☐ Er flaget placeret i jeres egen tenant uden rigtige persondata?
☐ Ved systemejeren, hvad der sker, hvis udbyderen henvender sig? → Rules of engagement i red teaming

Kilder

Microsoft: regler for sikkerhedstest af Microsofts onlinetjenester: forbud mod social engineering rettet mod Microsofts medarbejdere og adgang til andre kunders data; opfordring til at afprøve overvågning og detektion i egen tenant.
Forordning (EU) 2022/2554 (DORA): artikel 28, stk. 1, litra a, om finansielle enheders fulde ansvar ved brug af IKT-tjenester fra tredjeparter.

Senest gennemgået: oktober 2026.