En penetrationstest, der er planlagt ud fra en liste over systemer, kan give mange fund uden at belyse de hændelser, ledelsen faktisk frygter. En trusselsbaseret test vender rækkefølgen om: den begynder med, hvem der realistisk kunne gå efter virksomheden, hvad de ville have ud af det, og hvilke veje de sandsynligvis ville vælge.
Svaret på, om formen passer til jer, afhænger af tre ting. Kan I beskrive et trusselsbillede, der er konkret nok til at styre opgaven? Har I systemer og processer, hvor konsekvensen af et bestemt forløb er værd at afprøve? Og er I klar til at modtage et resultat, der handler om et scenarie frem for en bred gennemgang af alt?
Fra systemliste til trusselsbillede
Den almindelige bestilling spørger: hvilke systemer skal med? Den trusselsbaserede bestilling spørger først: hvad ville en modpart ønske at opnå hos os? Det kan være adgang til kunders oplysninger i kundeportalen, at standse ordreflowet i webshoppen eller at ændre betalingsoplysninger i ERP-systemet.
Når målet er formuleret, bliver det lettere at se, hvilke systemer, roller og forbindelser der hører med. En modpart, der vil ramme økonomifunktionen, interesserer sig måske mere for mailkonti og godkendelsesgange end for den offentlige hjemmeside. Overblikket over det, I viser udadtil, er stadig et nyttigt udgangspunkt. → Angrebsflade
Trusselsbilledet er altså ikke en pæn indledning til rapporten. Det er grundlaget for de valg, der gør opgaven anderledes end en standardtest.
Hvor trusselsbilledet kommer fra
Et brugbart trusselsbillede bygger på oplysninger, I kan pege på. Det kan være egne hændelser og nærved-hændelser, henvendelser fra kunder om forsøg på svindel, offentlige trusselsvurderinger fra myndigheder og den viden, jeres branche deler. Det kan også være en enkel analyse af, hvilke oplysninger og funktioner der ville gøre mest skade, hvis de blev misbrugt.
Skriv trusselsbilledet i almindeligt sprog. En formulering som økonomisk motiverede angribere, der vil omdirigere betalinger, er mere brugbar end en lang liste over mulige trusler. Notér samtidig, hvilke antagelser der ligger bag, så de kan genbesøges senere.
I større organisationer kan trusselsbilledet komme fra en særskilt efterretningsfunktion eller en ekstern leverandør. I en mindre virksomhed kan det være resultatet af et møde mellem ledelsen, IT-ansvarlig og driftsleverandøren. Begge dele kan bruges, så længe kilderne er synlige.
Scenariet bliver til scope
Ud fra trusselsbilledet vælges et eller nogle få scenarier. Et scenarie beskriver udgangspunkt, mål og grænser: hvor starter testeren, hvad er målet, og hvad må ikke berøres? Udgangspunktet kan være internettet, en almindelig medarbejderkonto eller en position bag forsvaret. → Assume breach
Scenariet skal stadig oversættes til et almindeligt scope med systemer, tidsrum, kontaktpersoner og stopkriterier. Den trusselsbaserede form fritager ikke for en præcis afgrænsning, den giver blot afgrænsningen en begrundelse. → Scope i en penetrationstest
Aftal også, hvad der tæller som et resultat. Det kan være, at målet blev nået, at det blev nået delvist, eller at forsøget blev opdaget og stoppet. Hvert udfald giver forskellig viden, og rapporten skal kunne vise, hvilket af dem der foreligger.
Rapporten bør desuden fortælle historien i den rækkefølge, den skete. Hvilke trin lykkedes, hvor måtte testeren skifte vej, og hvilke forudsætninger blev givet undervejs? For ledelsen er forløbet ofte mere oplysende end de enkelte fund, fordi det viser, hvor flere små svagheder tilsammen åbnede en vej. For IT er de enkelte fund stadig nødvendige, så hver rettelse kan placeres hos den rigtige ejer.
Hvornår formen passer, og hvornår en almindelig test er nok
Den trusselsbaserede form giver mest, når virksomheden allerede har styr på de grundlæggende test og vil vide, hvordan forsvaret holder over for et sammenhængende forløb. Den kan også være relevant, når ledelsen stiller et konkret spørgsmål om én bestemt type hændelse.
En almindelig penetrationstest kan være det bedre valg, når I har brug for bred dækning af en ny kundeportal, eller når en kunde beder om dokumentation for et bestemt system. Her er det dækningen af funktioner og roller, der tæller, ikke et enkelt scenarie.
De to former kan også kombineres over tid. Et år kan den brede test af webshoppen give overblik over svaghederne, mens et senere scenarie undersøger, om de rettede forhold holder, når en modpart forsøger at komme fra kontornettet til ERP-systemet. Rækkefølgen bør følge de beslutninger, I skal træffe, ikke et ønske om at prøve alle former.
Grænsen til red teaming er flydende. Red teaming arbejder typisk med længere forløb, flere indgange og afprøvning af virksomhedens evne til at opdage og reagere. → Red teaming eller penetrationstest
TLPT: den regulerede udgave i finanssektoren
For finansielle virksomheder har trusselsbaseret test fået en reguleret form. DORA, EU’s forordning om digital operationel modstandsdygtighed i den finansielle sektor, bruger begrebet trusselsledet penetrationstest (TLPT) og beskriver i artikel 26 avanceret test på dette grundlag for de virksomheder, som myndighederne udpeger. Ordlyden og kravene til test og testere skal læses i forordningen selv.
Den regulerede udgave har egne krav til forløb, roller og godkendelse. En trusselsbaseret penetrationstest uden for den ramme er ikke det samme og bør ikke præsenteres som en TLPT. Mere om grænsedragningen findes på red-teaming.dk. → Finansielle virksomheder og DORA
Det skal I lade være med
- At kalde en standardtest trusselsbaseret · Uden et beskrevet trusselsbillede er det blot en ny etiket.
- At skrive et trusselsbillede uden kilder · Antagelser, der ikke kan efterprøves, giver et scenarie, der ikke kan forsvares.
- At vælge for mange scenarier · Opgaven bliver bred og overfladisk og mister sin pointe.
- At glemme stopkriterier · Et realistisk forløb kræver stadig klare grænser for drift, data og medarbejdere.
- At læse et nået mål som eneste resultat · Hvor forsøget blev bremset eller opdaget, er lige så vigtig viden.
- At sammenblande formen med TLPT · Den regulerede test har egne krav, som en almindelig bestilling ikke opfylder.
Hvad kan og ikke kan konkluderes
En trusselsbaseret test kan vise, hvordan det valgte scenarie forløb under de aftalte forhold, og hvor forsvaret holdt eller gav efter. Den kan give ledelsen et konkret svar på et konkret spørgsmål.
Den kan ikke sige noget om scenarier, der ikke blev valgt, eller om systemer, der lå uden for forløbet. Trusselsbilledet ændrer sig også, så konklusionen gælder det billede, testen byggede på. → Sådan læser I en pentestrapport
Tjekliste før en trusselsbaseret bestilling
- ☐ Er trusselsbilledet skrevet ned med kilder og antagelser?
- ☐ Er målet for hvert scenarie formuleret i forretningssprog?
- ☐ Er udgangspunkt, systemer og grænser beskrevet i et almindeligt scope?
- ☐ Er stopkriterier og kontaktpersoner aftalt?
- ☐ Er det aftalt, hvilke udfald rapporten skal skelne mellem?
- ☐ Er det afklaret, om virksomheden er omfattet af regulerede krav som TLPT?
Kilder
- DORA, forordning (EU) 2022/2554: begrebet trusselsledet penetrationstest (TLPT) og artikel 26 om avanceret test.
- Danmarks Nationalbank om TIBER-DK og TLPT: den danske ramme for trusselsbaserede red team-test og TLPT i den finansielle sektor.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler om penetrationstest
Læs også: Typer af penetrationstest · Assume breach
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
