MSP’ens egen red team‑øvelse: når én adgang kan ramme mange kunder

Hos en udbyder af administrerede tjenester samles adgangen til kundernes systemer i de samme værktøjer: fjernadministrationen, teknikernes konti, sagssystemet og stedet, hvor kundernes adgangsoplysninger opbevares. En red team-øvelse mod MSP’en selv skal derfor svare på et spørgsmål, som en almindelig øvelse ikke har: hvor langt kan en angriber komme mod kunderne gennem jer? Svaret hviler på scenarier, der går mod de fælles værktøjer, og på en afgrænsning, der stopper holdet ved grænsen til kundernes miljøer.

Kort sagt er målet at bevise, at en angriber kunne have handlet i en kundes miljø, uden at holdet gør det. Det kræver flag, der ligger i MSP’ens egne systemer, en testkunde, hvor det er muligt, og klare regler for, hvornår holdet standser. Teksten er skrevet til sikkerhedschefen hos MSP’en og er ikke juridisk rådgivning.

Hvorfor MSP’en er et mål for sig

Myndigheder i fem lande, herunder det britiske NCSC og den amerikanske CISA, har i en fælles vejledning beskrevet, at MSP’er har betroede forbindelser og privilegeret adgang til kundernes systemer, og at en kompromitteret MSP kan bruges som vej ind til flere kunder på én gang. MITRE ATT&CK beskriver det samme mønster som misbrug af betroede relationer, hvor en angriber går gennem en tredjepart, der allerede har adgang til målet.

NIS2-direktivet nævner udbydere af administrerede tjenester og administrerede sikkerhedstjenester som en sektor i bilag I, og betragtning 86 peger på, at udbydere af administrerede sikkerhedstjenester på grund af deres integration i kundernes drift udgør en særlig risiko. I Danmark definerer NIS 2-loven i § 3, nr. 34, en udbyder af administrerede tjenester, og § 6, stk. 1, kræver bl.a. forsyningskædesikkerhed og politikker til vurdering af foranstaltningernes effektivitet. En øvelse er én måde at vurdere effektiviteten på, ikke et krav i sig selv. → NIS2 og red teaming

Scenarier, der går mod de fælles værktøjer

Scenarierne bør tage udgangspunkt i det, der gør MSP’en særlig. Eksempler, beskrevet på det niveau, en ledelse kan godkende:

Teknikerens konto · en angriber har overtaget en teknikers identitet. Hvor langt rækker rettighederne, og opdager nogen det?
Servicedesken · en angriber udgiver sig for at være en tekniker eller en kunde og beder om ny adgang. → Servicedesken i øvelsen
Fjernadministrationen · platformen, der når alle kunder, er målet. Kan holdet få rettigheder til at handle i den?
Adgangsoplysningerne · stedet, hvor kundernes administratoradgange opbevares. Kan det nås, og bliver forsøget set?

Et scenarie med udgangspunkt i en allerede overtaget konto kan spare tid og fokusere på det, der betyder mest: hvad der sker, efter at angriberen er inde. → Udgangspunkt i et sket brud

Grænsen til kundernes miljøer

Kundernes systemer tilhører kunderne. Jeres tilladelse til øvelsen dækker jeres egne systemer, ikke kundernes, og holdet må ikke handle i et kundemiljø, medmindre kunden selv har givet skriftlig tilladelse. Grænsen skal derfor ligge i scope-dokumentet og i reglerne for holdet, ikke kun i en fælles forståelse. → Fredede områder

Tre greb gør grænsen praktisk:

Flag ved grænsen · holdet skal vise, at det har opnået en rettighed i jeres værktøj, som kunne bruges mod en kunde, og stopper dér.
Testkunde · findes der en intern testkunde eller et demomiljø i fjernadministrationen, kan holdet gå hele vejen dertil.
Stopregel · nærmer holdet sig en kundes data eller systemer, stopper det og kontakter white team. → Stopregler

Kundedata findes også i jeres egne systemer, fx i sager og dokumentation. Aftal, hvordan holdet håndterer det, hvis det ser kundeoplysninger undervejs, og hvad der skal slettes bagefter. Kontrakterne med kunderne kan desuden indeholde krav om varsling eller fortrolighed, som påvirker øvelsen. Læs dem, før scope låses.

Overvej også jeres egne underleverandører. Fjernadministrationen, sagssystemet og opbevaringen af adgangsoplysninger kan være købt som tjenester hos andre, og deres vilkår for sikkerhedstest gælder ved siden af jeres egen tilladelse. Hvis en del af scenariet går gennem en sådan tjeneste, skal leverandørens regler være læst, og en eventuel godkendelse skal foreligge, før holdet går i gang. Ellers kan øvelsen ende med at berøre en tredjepart, som hverken I eller kunderne har aftaler med om test.

Jeres overvågning betjener også kunderne

Hvis MSP’ens SOC både overvåger jer selv og jeres kunder, kan en opdagelse under øvelsen udløse en procedure, der varsler kunder om en mulig kompromittering. Det er netop den reaktion, øvelsen gerne vil måle, men den må ikke nå kunderne som en falsk alarm. White team skal kunne bekræfte en eskalering som øvelse, før den går ud af huset, uden at forsvaret får besked for tidligt. → Eskalering under øvelsen

Hvordan MSP’en håndterer det, når det er en kunde, der bestiller en øvelse i det miljø, I driver, er et andet spørgsmål. → Driftsleverandøren og MSP’en i kundens red team-øvelse

Hvad kunderne skal høre bagefter

Kunderne vil have en interesse i resultatet, fordi det handler om den adgang, de har givet jer. Beslut før øvelsen, hvad de får at vide: at en øvelse er gennemført, hvilke fælles værktøjer der var inden for rammerne, og at fundene følges op. Detaljerne om vejen ind deles ikke, heller ikke med de kunder, hvis systemer holdet kunne have nået. Hvordan en teknisk test af jeres egen platform kan dokumenteres, beskriver penetration-test.dk. → Hvad kunderne kan få at se

Det skal I lade være med

At lade holdet bevise adgangen i et rigtigt kundemiljø · flaget skal ligge i jeres egne systemer.
At gå ud fra, at jeres tilladelse dækker kunderne · kun kunden kan give lov til sit miljø.
At glemme kundedata i sagssystemet · også dér skal håndteringen være aftalt.
At lade SOC’ens kundevarsling køre uden white team · en falsk alarm kan nå hele kundekredsen.
At udelade fjernadministrationen for at undgå risiko · så afprøver øvelsen ikke det vigtigste.

Hvad kan og ikke kan konkluderes

En øvelse mod MSP’ens fælles værktøjer kan vise, om en angriber kan få den adgang, der ville række ud til kunderne, og om jeres forsvar ser det. Den kan ikke vise, hvordan den enkelte kundes eget forsvar ville reagere, og den siger ikke noget om de dele af kundernes miljøer, der var uden for rammerne.

Tjekliste før øvelsen

☐ Værktøjer · er de fælles værktøjer, der når kunderne, kortlagt og prioriteret?
☐ Grænse · står grænsen til kundemiljøerne i scope og regler for holdet?
☐ Testkunde · findes der et miljø, holdet kan gå hele vejen til?
☐ Kontrakter · er kundekontrakternes krav om varsling og fortrolighed læst?
☐ Eskalering · kan white team standse en kundevarsling, før den sendes?
☐ Kommunikation · er det besluttet, hvad kunderne får at vide bagefter?

Kilder

Direktiv (EU) 2022/2555 (NIS2): artikel 6, nr. 39 og 40, bilag I, punkt 9, og betragtning 86 om udbydere af administrerede tjenester og sikkerhedstjenester.
NIS 2-loven, lov nr. 434 af 6. maj 2025: § 3, nr. 34, og § 6, stk. 1, nr. 4 og 6.
Kommissionens gennemførelsesforordning (EU) 2024/2690: artikel 1 om udbydere af administrerede tjenester og bilagets punkt 7 om vurdering af foranstaltningernes effektivitet.
CISA m.fl., Protecting Against Cyber Threats to Managed Service Providers and their Customers (AA22-131A): MSP’ers betroede forbindelser og privilegerede adgang som vej til kunderne.
MITRE ATT&CK, Trusted Relationship (T1199): misbrug af tredjeparter med adgang til målet.

Senest gennemgået: oktober 2026.