Red-teaming

Udgangspunktet i assumed breach: hvilken bruger og hvilken adgang?

Udgangspunktet i assumed breach: hvilken bruger og hvilken adgang?

I et assumed breach-scenarie er det udgangspunkt, holdet får, den vigtigste enkeltbeslutning i hele planlægningen. Vælger I en adgang, der er for stærk, besvarer øvelsen et spørgsmål, ingen har stillet. Vælger I en, der ikke ligner noget realistisk, bliver resultatet let at afvise. Valget skal derfor hvile på jeres trusselsbillede og på en klar beskrivelse af, hvilken situation øvelsen skal efterligne. Derefter handler det om at etablere adgangen uden at afsløre øvelsen og om at dokumentere den, så rapporten kan læses rigtigt.

Hvorfor scenariet springer indgangen over, og hvad det betyder for målingen, er beskrevet for sig. Her er emnet selve udgangspunktet. → Assumed breach som scenarie

Udgangspunktet afgør, hvad resultatet betyder

Et resultat fra et assumed breach-scenarie er altid betinget. Det siger: fra denne adgang kunne holdet nå så langt, og forsvaret så dette. Hvis udgangspunktet ikke er beskrevet præcist, kan ingen vurdere, om konklusionen gælder for jeres situation.

Tænk derfor udgangspunktet som en del af resultatet og ikke som en teknisk detalje i forberedelsen. Det skal kunne forklares for ledelsen i én sætning: hvem holdet lod som om det var, og hvad det havde adgang til ved start.

Tre spørgsmål til valget

Valget kan struktureres med tre spørgsmål, der hver kræver et svar fra en anden kilde.

  1. Hvilken indgang er sandsynlig? · trusselsefterretningen og jeres egne hændelser peger på, hvordan en modstander mest sandsynligt ville komme ind, fx gennem en medarbejder, en leverandør eller en fjernadgang. → Trusselsefterretning
  2. Hvilken rolle ville modstanderen få? · en indgang gennem en medarbejder giver den medarbejders rettigheder. Rollen i organisationen bestemmer, hvad holdet kan nå uden videre.
  3. Hvor står adgangen? · på en arbejdsplads på kontoret, en hjemmearbejdsplads, et system hos en leverandør eller en konto i en cloudtjeneste. Placeringen afgør, hvilke kontroller holdet møder først.

Overvej også tidspunktet i modstanderens forløb. Et udgangspunkt kan efterligne situationen lige efter indgangen, hvor modstanderen kun har den ene adgang, eller en situation, hvor modstanderen har været inde i nogen tid og kender miljøet. Det sidste kræver mere forberedelse og flere leg-ups, og det skal begrundes særskilt, fordi det springer endnu mere af forløbet over.

Svarene giver tilsammen en beskrivelse, der kan godkendes. Hvis svarene peger i flere retninger, kan det være et tegn på, at øvelsen skal have flere scenarier med hvert sit udgangspunkt. → Scenarievalg

Repræsentativ frem for bekvem

Det mest bekvemme udgangspunkt er ikke nødvendigvis det mest repræsentative. En konto, der allerede findes til test, kan have rettigheder, ingen almindelig medarbejder har. En arbejdsplads, der er sat op i hast, kan mangle de kontroller, de rigtige arbejdspladser har.

Stil derfor kravet, at udgangspunktet skal ligne det, en rigtig medarbejder i den valgte rolle har. Samme type udstyr, samme opsætning, samme rettigheder og samme adgang til systemer. Afvigelser kan være nødvendige, men de skal noteres, så de kan nævnes i rapporten.

En rigtig medarbejders adgang eller en testidentitet

Et særligt spørgsmål er, om holdet skal bruge en eksisterende medarbejders adgang eller en identitet, der er oprettet til øvelsen. Svaret har både praktiske og etiske sider.

  • En eksisterende medarbejders adgang · ligner virkeligheden mest, men gør medarbejderen til en del af øvelsen. Det kræver samtykke, overvejelser om personoplysninger og en plan for, hvordan medarbejderen beskyttes, hvis forsvaret reagerer.
  • En testidentitet i en rigtig rolle · beskytter medarbejderne, men skal oprettes, så den ligner en almindelig konto i rollen. Oprettelsen kan i sig selv blive set og afsløre øvelsen.

Hvis I vælger en eksisterende medarbejders adgang, skal medarbejderen også have en klar besked om, hvad der sker bagefter: hvornår adgangen gives tilbage, om adgangskoder skal skiftes, og hvem der kan svare på spørgsmål. Valget bør drøftes med HR og den, der rådgiver om persondata, før det træffes. → Medarbejderhensyn

Hvem der etablerer adgangen

Udgangspunktet etableres af white team, ikke af den almindelige IT-drift. Hvis en bestilling går gennem de sædvanlige kanaler, kan den blive opdaget eller behandlet efter rutiner, der giver adgangen ekstra rettigheder for at få den til at virke.

Udpeg en person i white team med de nødvendige rettigheder, som kan oprette adgangen og dokumentere den. Brug øvelsens kodenavn i interne notater, så formålet ikke fremgår af almindelige sager. → Kodenavn og dokumenter

TIBER-DK kræver, at testplanen beskriver forudsætningerne for hver angrebsvej og de leg-ups, kontrolteamet skal stille til rådighed, med frister. Kravet gælder de regulerede test, men det er en god disciplin: udgangspunktet planlægges, før den aktive fase begynder, og ikke i sidste øjeblik.

Før holdet får adgangen, skal white team kontrollere, at den svarer til beskrivelsen. Det handler om rettigheder, gruppemedlemskaber, adgang til systemer og udstyrets opsætning. En adgang, der viser sig at være stærkere end aftalt, ændrer hele øvelsens resultat.

Notér kontrollen, og gem den med øvelsens dokumentation. Hvis noget måtte ændres undervejs, fx fordi adgangen ikke virkede, noteres ændringen med tidspunkt og begrundelse.

Udgangspunktet i rapporten

Rapporten skal beskrive udgangspunktet så præcist, at læseren kan forstå resultatet uden at kende forberedelsen. Rollen, placeringen, rettighederne og eventuelle afvigelser fra en almindelig medarbejders adgang skal fremgå. Det skal også fremgå, at udgangspunktet var et valg og ikke noget, holdet selv skaffede. → Red team-rapporten

Når øvelsen er slut, skal adgangen lukkes, og lukningen skal dokumenteres. En testidentitet, der bliver liggende, er en risiko i sig selv, også selv om ingen kender den uden for white team.

Det skal I lade være med

  • At bruge en eksisterende testkonto uden kontrol · den kan have rettigheder, ingen medarbejder har.
  • At lade IT-driften oprette adgangen gennem de sædvanlige kanaler · det kan afsløre øvelsen eller give forkerte rettigheder.
  • At bruge en medarbejders adgang uden samtykke og plan · medarbejderen bliver en del af øvelsen.
  • At ændre adgangen undervejs uden at notere det · resultatet kan ikke længere læses rigtigt.
  • At glemme at lukke adgangen · en efterladt testidentitet er en åben dør.

Hvad kan og ikke kan konkluderes

Et veldokumenteret udgangspunkt gør det muligt at sige, hvad en modstander med netop den adgang kunne nå, og hvad forsvaret så. Det kan ikke overføres til andre roller eller placeringer uden videre. En anden afdeling eller en anden type adgang kan give et helt andet forløb.

Tjekliste til udgangspunktet

  • ☐ Er udgangspunktet begrundet i trusselsbilledet?
  • ☐ Er rolle, placering og rettigheder beskrevet?
  • ☐ Er det besluttet, om der bruges en rigtig medarbejders adgang eller en testidentitet?
  • ☐ Er HR og persondatarådgivning inddraget, hvor det er relevant?
  • ☐ Er adgangen oprettet af white team og kontrolleret før start?
  • ☐ Er det aftalt, hvem der lukker adgangen efter øvelsen?

Kilder

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Artikler om red teaming

Læs også: Insiderscenariet · Leverandørscenariet

→ Kontakt · Tlf. 70 13 63 23 · Red teaming hos Nielco IT

Skrevet af John Nielsen, indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Om John Nielsen · LinkedIn

John Nielsen, Nielco IT

Overvejer I en red team‑øvelse?

Fortæl kort, hvad øvelsen skal give svar på, og hvornår ledelsen skal have resultatet. Så vender jeg tilbage.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.