Scenariebaseret test: når en sandsynlig hændelse bestemmer øvelsen

Sikkerhedsfunktioner kan få spørgsmålet: hvad sker der, hvis det, vi frygter, faktisk rammer os? En scenariebaseret test besvarer det ved at lade en konkret, sandsynlig hændelse styre hele øvelsen, fra udgangspunkt over forløb til målet. Svaret hviler på et skriftligt scenarie, som ledelsen kan genkende, holdet kan arbejde efter, og white team kan styre ud fra.

Hvor en bred test spørger, hvad der kan findes, spørger scenariet, hvordan en bestemt historie ville udvikle sig hos jer. En kort forklaring af trusselsbaseret test for købere generelt findes på penetrationtest.dk. Her handler det om, hvordan sikkerhedsfunktionen selv bygger og bruger scenariet.

Et scenarie er en historie med grænser

Et scenarie beskriver en hændelse fra begyndelse til slut, men i et sprog, der er til at styre efter. Det svarer på fem spørgsmål: Hvem er modstanderen? Hvad vil den opnå? Hvor starter den? Hvilke dele af organisationen kan den bevæge sig igennem? Og hvad må den ikke røre? Svarene bliver til den ramme, holdet arbejder inden for.

Et tænkt eksempel fra et forsyningsselskab: en modstander, der vil forstyrre afregningen af kunder, får adgang gennem en leverandørs fjernadgang og forsøger at nå systemet, der danner fakturaer. Historien er kort, men den peger på konkrete funktioner, leverandører og kontroller. Den fortæller også, hvem der skal give tilladelse, og hvilke dele af driften der skal beskyttes særligt. → Leverandørscenariet

Hvad gør et scenarie brugbart?

Ikke alle historier er lige gode at øve på. Et brugbart scenarie har nogle kendetegn, som white team kan bruge som tjek, før det godkendes.

Sandsynligt · det bygger på trusselsefterretning eller organisationens egne erfaringer og ikke kun på fantasi. → Trusselsefterretning som grundlag
Forankret i et mål · det ender ved en funktion eller et datasæt, som ledelsen anser for vigtigt.
Afgrænset · det er tydeligt, hvor historien starter, og hvad der er udenfor.
Målbart · det indeholder punkter, hvor forsvaret burde kunne se eller stoppe forløbet.
Gennemførligt · det kan afprøves inden for den tid og de tilladelser, øvelsen har.

TIBER-DK lægger op til, at udvælgelsen også tager højde for, om holdet vurderer scenariet som gennemførligt, og for organisationens størrelse og risikoprofil. Et smukt scenarie, der ikke kan gennemføres sikkert, hjælper ingen.

Hvem skriver scenariet?

Scenariet bliver bedst, når flere parter bidrager. Efterretningen leverer modstanderen og dens sandsynlige adfærd. Forretningen leverer målet og viden om, hvad der ville gøre ondt. Holdet vurderer, hvad der kan gennemføres sikkert. White team samler trådene og godkender den endelige udgave. Hvis en enkelt part skriver scenariet alene, risikerer det at miste enten realisme eller forankring i forretningen.

Det færdige scenarie er et fortroligt dokument. Det beskriver, hvor organisationen mener, den er sårbar, og hvordan øvelsen skal forløbe. Opbevar det derfor sammen med øvelsens øvrige materiale, og del det kun med dem, der har brug for det. Efter øvelsen kan det deles bredere som en del af gennemgangen med forsvaret.

Flere scenarier giver bredere læring

Et enkelt scenarie afprøver en enkelt historie. TIBER-DK kræver mindst tre fuldt udarbejdede scenarier, og mindst et af dem skal handle om henholdsvis tilgængelighed, integritet og fortrolighed. Princippet er værd at overveje også uden for finanssektoren: et forsvar, der er godt til at opdage datatyveri, er ikke nødvendigvis godt til at opdage en manipulation af betalinger. → Betalingssvindel som scenarie

Flere scenarier kræver mere tid og flere tilladelser. Vælg derfor efter, hvilke typer hændelser organisationen ved mindst om. Hvis ransomware er gennemgået i en skrivebordsøvelse sidste år, kan et scenarie om fortrolige oplysninger give mere ny viden end endnu en øvelse om kryptering. → Ransomware som scenarie

Udgangspunktet er et valg

Scenariet skal sige, hvor modstanderen starter. Det kan være uden for organisationen, med en almindelig medarbejders adgang eller hos en leverandør. Valget er ikke kun teknisk. Det afgør, hvilken del af forsvaret der bliver afprøvet, og hvor meget af øvelsens tid der går til at komme ind.

Når udgangspunktet er inde bag det yderste forsvar, taler man om assumed breach. Det er en måde at bruge tiden på de dele af forløbet, organisationen ved mindst om. Valget bør være bevidst og fremgå af rapporten, så ingen tror, at den yderste beskyttelse blev afprøvet. → Assumed breach som scenarie

Når virkeligheden ikke følger manuskriptet

Ingen scenarier holder hele vejen. Holdet kan sidde fast, forsvaret kan reagere tidligt, eller driften kan kræve, at en del af forløbet flyttes. Det er ikke et tegn på, at scenariet var dårligt, men det kræver en aftalt måde at justere på. White team skal kunne beslutte, om holdet får et aftalt skub videre, om et andet udgangspunkt tages i brug, eller om scenariet afsluttes.

Hver justering skal skrives ned med tidspunkt og begrundelse. Ellers bliver det umuligt bagefter at skelne mellem det, forsvaret selv stoppede, og det, øvelsen ændrede. → Når scenariet skal justeres midt i øvelsen

Når øvelsen er slut, bliver scenariet rapportens rygrad, også med de justeringer, der blev nødvendige undervejs. Det er historien, rapporten fortæller. Det gør resultatet lettere at bruge, fordi ledelsen kan genkende historien, og fordi hver iagttagelse kan placeres i forløbet. Det gør også sammenligning mulig: hvis samme scenarie afprøves igen senere, kan organisationen se, om forsvaret stopper forløbet tidligere. → Målet for øvelsen

Det skal I lade være med

At skrive scenariet uden kilder · Ledelsen vil spørge, hvorfor netop denne historie, og svaret skal findes.
At lade scenariet være for bredt · En historie, der omfatter alt, styrer ingenting.
At vælge udgangspunkt uden at sige det højt · Et forløb, der starter indenfor, siger intet om det yderste forsvar.
At justere scenariet uden at notere det · Uregistrerede ændringer gør resultatet umuligt at læse.
At øve den samme slags hændelse hver gang · Variation mellem tilgængelighed, integritet og fortrolighed giver bredere læring.

Hvad kan og ikke kan konkluderes

En scenariebaseret test kan vise, hvordan en bestemt type hændelse forløb hos jer under de aftalte forhold, og hvor forsvaret greb ind. Den kan ikke sige noget om hændelser, der ikke var en del af scenariet, og den kan ikke bevise, at en virkelig hændelse ville forløbe på samme måde. Resultatet er stærkest, når scenariet er velbegrundet, og når justeringerne undervejs er dokumenteret.

Tjekliste før et scenarie godkendes

☐ Bygger scenariet på trusselsefterretning eller egne erfaringer?
☐ Ender det ved et mål, som ledelsen anser for vigtigt?
☐ Er udgangspunkt, forløb og udelukkelser beskrevet?
☐ Er der punkter, hvor forsvaret burde kunne se forløbet?
☐ Har holdet vurderet scenariet som gennemførligt med de givne tilladelser?
☐ Er det aftalt, hvordan justeringer besluttes og dokumenteres?

Kilder

Danmarks Nationalbank: TIBER-DK Implementation Document: kriterier for scenarievalg, mindst tre scenarier og fordelingen på tilgængelighed, integritet og fortrolighed.

Senest gennemgået: oktober 2026.