Datatyveri som scenarie: når målet er fortrolige oplysninger

Tab af fortrolige oplysninger er en af de hændelser, ledelsen frygter mest, fordi skaden rammer kunder, medarbejdere og forretningens tillid på samme tid. Spørgsmålet for CISO’en er, om scenariet skal med i øvelsen, og hvordan det holdes inden for en forsvarlig ramme. Svaret hviler på en klar arbejdsdeling: organisationen udpeger de data, der betyder mest, white team godkender, hvordan adgang bevises med aftalte markører eller testdata, og øvelsen måler, om forsvaret opdager, eskalerer og stopper forløbet. Ingen rigtige data forlader organisationen.

Scenariet giver derfor viden om kontrol og reaktion omkring de vigtigste oplysninger. Det giver ikke et billede af, hvad et faktisk tab ville koste.

Hvorfor fortrolighed fortjener sit eget scenarie

I de regulerede test for finanssektoren skal trusselsefterretningsrapporten indeholde mindst tre scenarier, og et af dem skal omfatte fortroligheden af oplysninger. De to andre dækker tilgængelighed og integritet. Det er rammens krav til TLPT, men opdelingen er også en nyttig huskeregel i en frivillig øvelse: et ransomware-scenarie måler noget andet end et scenarie, hvor modstanderen vil have fat i oplysninger og helst ikke ses.

Forskellen har betydning for målingen. Et angreb rettet mod tilgængelighed bliver synligt, når skaden sker. Et angreb rettet mod fortrolighed kan forløbe uden synlige følger for driften, og det stiller større krav til overvågningen. → Ransomware som scenarie

Kronjuvelerne og deres ejere

Scenariet begynder med en beslutning om, hvilke oplysninger der er organisationens vigtigste. Det kan være kundedata, forretningshemmeligheder, oplysninger om kommende opkøb, kildekode, prisaftaler eller data, som tilsynsmyndigheder forventer beskyttet. Valget bør tage udgangspunkt i, hvad der ville gøre mest skade i jeres situation, og ikke i, hvad der er lettest at sætte op. → Målet for øvelsen

Hver kronjuvel skal have en ejer. Ejeren er den forretningsansvarlige, der kender oplysningernes værdi og kan sige, hvor de opbevares, hvem der har adgang i dag, og hvad et tab ville betyde. Uden en ejer ender scenariet med at handle om systemer i stedet for om oplysninger, og resultatet bliver svært at bruge i forretningen.

Hvilke oplysninger · den konkrete datamængde, ikke blot systemet.
Hvem ejer dem · navngiven ansvarlig i forretningen.
Hvorfor de er vigtige · kunder, konkurrence, tilsyn eller kontrakter.
Hvem skal vide besked · ejeren kan indgå i white team eller orienteres af det.

Bevis for adgang uden at flytte rigtige data

Øvelsen skal vise, at holdet kunne have fået fat i oplysningerne, ikke at det faktisk tog dem. Det gøres med flag, som white team godkender på forhånd. Et flag kan være en markørfil med et aftalt indhold, et sæt testdata, der ligner de rigtige uden at være det, eller en aftalt oplysning, som kun kan læses med den adgang, scenariet handler om.

Testdata har en særlig fordel i et fortrolighedsscenarie. Hvis white team vil vide, om overvågningen reagerer, når oplysninger bevæger sig ud af organisationen, kan det godkendes, at holdet flytter testdata i stedet for rigtige data. Så kan reaktionen måles, uden at nogen fortrolig oplysning kommer i fare. Hvad der må flyttes, i hvilken mængde og til hvilken modtager, er white teams beslutning og står i rules of engagement.

Alt, der placeres som flag eller testdata, registreres og fjernes ved afslutningen.

White team, stopregler og persondata

White team ejer scenariet og godkender flag, testdata og grænser, før holdet begynder. For et fortrolighedsscenarie bør rules of engagement mindst slå fast, at rigtige fortrolige data ikke må kopieres ud, at holdet kun dokumenterer adgang med det, der er aftalt, og at tilfældige fund af fortrolige oplysninger meldes til white team. → White team

Stopreglerne skal dække det særlige ved scenariet. Hvis holdet ved et uheld får adgang til oplysninger, der ikke var forudset, eller hvis der er tvivl om, hvorvidt en handling berører rigtige data, stopper holdet og spørger. I de regulerede test skal kontrolteamet vurdere risici, herunder den risiko, der ligger i at give testerne adgang til følsomme oplysninger. Samme vurdering hører hjemme i en frivillig øvelse. → Stopregler

Et scenarie om fortrolige oplysninger kommer tæt på persondata, også når kronjuvelen er forretningsdata. Databeskyttelsesforordningen kræver passende sikkerhed, herunder en procedure for regelmæssig afprøvning af foranstaltningernes effektivitet, og nævner uautoriseret adgang til personoplysninger som en af de risici, sikkerhedsniveauet skal tage højde for. Det kan begrunde øvelsen, men det fritager ikke for at begrænse, hvad holdet ser og gemmer. Teksten er ikke juridisk rådgivning. → Persondata i øvelsen

Aftal derfor, at holdet dokumenterer adgang med flag og skærmbilleder, der ikke viser personoplysninger, og at intet rigtigt indhold gemmes i holdets materiale. Hvis det alligevel sker, slettes det efter aftalt procedure, og white team noterer det.

Hvad blue team og overvågningen måles på

Måleplanen bør aftales, før øvelsen går i gang, og bygge på tre spørgsmål:

Blev det opdaget? · og i hvilken fase: ved adgangen til oplysningerne, ved samlingen af dem eller først, da testdata bevægede sig.
Blev det eskaleret? · nåede alarmen frem til den, der kan træffe beslutninger, og fik dataejeren besked?
Blev det stoppet? · lykkedes det at afbryde forløbet, før flaget var nået?

Svarene sammenholdes med holdets logbog, så begge sider bidrager til tidslinjen. → Opdagelse, eskalering og reaktion

Resultatet i rapport og forbedringer

Rapporten skal fortælle dataejeren og ledelsen, hvilke kronjuveler holdet kunne have nået, hvilke flag der blev nået, og hvor forsvaret reagerede. Formuleringen skal være præcis: et nået flag betyder, at adgangen var mulig i dette forløb, ikke at oplysningerne er tabt. → Red team-rapporten

Forbedringerne bør fordeles efter ejerskab. Dataejeren kan tage stilling til, hvem der har brug for adgang. Sikkerhedsfunktionen kan se på overvågningen omkring de vigtigste oplysninger og på eskaleringsvejen. Ledelsen kan beslutte, om klassifikationen af data skal opdateres.

Det skal I lade være med

At bruge rigtige fortrolige data som bevis · flag og testdata er nok.
At vælge kronjuveler uden ejer · så kan ingen bruge resultatet.
At lade holdet afgøre, hvad der må flyttes · det er white teams beslutning.
At glemme tilfældige fund · de skal meldes og håndteres efter aftale.
At præsentere et nået flag som et datalæk · det var adgang, ikke tab.

Hvad kan og ikke kan konkluderes

Scenariet kan vise, om de vigtigste oplysninger kunne nås i dette forløb, og om forsvaret opdagede, eskalerede og stoppede det. Det kan ikke vise, hvad et reelt tab ville koste, eller at oplysningerne er beskyttet mod alle veje.

Tjekliste før scenariet godkendes

☐ Er kronjuvelerne udpeget og hver tildelt en ejer?
☐ Er flag og testdata godkendt af white team?
☐ Forbyder rules of engagement kopiering af rigtige fortrolige data?
☐ Er håndtering af tilfældige fund og persondata aftalt?
☐ Er måleplanen for opdagelse, eskalering og stop på plads?

Kilder

Kommissionens delegerede forordning (EU) 2025/1190 om TLPT: bilag III, nr. 5, litra c (scenarie om fortrolighed af oplysninger), artikel 1, nr. 14 og 15 (flagmål og følsomme oplysninger), og artikel 5, stk. 2, litra a (risiko ved testernes adgang til følsomme oplysninger).
Databeskyttelsesforordningen (EU) 2016/679: artikel 32, stk. 1, litra d (regelmæssig afprøvning), og stk. 2 (risiko for uautoriseret adgang til personoplysninger).

Senest gennemgået: oktober 2026.