Trusselsmodellering før testen: hvad den giver testen

En pentest af et SaaS-produkt skal bruge en begrænset tid på det, der betyder mest, men hvad der betyder mest, er ikke altid klart for den, der skal teste. En trusselsmodel giver svaret på forhånd. Den beskriver, hvad produktet består af, hvad der kan gå galt, og hvad I har gjort ved det, og den gør det muligt at målrette testen mod de dele, hvor en fejl vil koste mest.

Trusselsmodellering er ikke en test i sig selv. Det er et stykke tænkearbejde, som udviklingsteamet gør med eller uden hjælp udefra. Men en god model gør testen skarpere og rapporten lettere at forklare over for kunderne.

Hvad en trusselsmodel er

OWASP beskriver trusselsmodellering som en struktureret og gentagelig måde at få indsigt i et systems sikkerhed på, set fra en angribers side. Arbejdet kan samles i fire spørgsmål:

Hvad arbejder vi på?
Hvad kan gå galt?
Hvad gør vi ved det?
Har vi gjort det godt nok?

For et SaaS-produkt betyder det første spørgsmål en beskrivelse af de dele, kunderne bruger, hvordan data bevæger sig mellem dem, og hvor grænserne går mellem det, der er betroet, og det, der ikke er. Den vigtigste grænse er som udgangspunkt den mellem kunderne. → Multi-tenant

NIST anbefaler i sit rammeværk for sikker softwareudvikling (SSDF), at producenter bruger risikomodellering, fx trusselsmodellering, til at vurdere sikkerhedsrisikoen for softwaren, og at områder med høj risiko, som adgangskontrol og beskyttelse af følsomme data, vurderes grundigere.

Hvad modellen giver testeren

Uden en model starter testeren med at finde ud af, hvordan produktet hænger sammen. Det tager tid fra selve testen. Med en model kan testeren gå direkte til de steder, hvor I selv mener, at risikoen er størst, og til de steder, hvor I er mindst sikre på jeres egne svar.

Konkret kan modellen give testeren:

Et overblik over dele og dataflow · hvilke komponenter, integrationer og grænseflader der findes.
Grænserne mellem kunder og roller · hvor adskillelsen skal holde, og hvem der må hvad.
De værdier, der skal beskyttes · kundedata, betalinger, administratoradgang eller noget helt fjerde.
Jeres egne antagelser · de steder, hvor I regner med, at noget holder, og gerne vil have det efterprøvet.

Modellen er et input til testen, ikke en facitliste. En god tester vil også se efter det, I ikke har forestillet jer. → Udviklerne og testeren

Modellen som grundlag for omfanget

Når I skal beslutte, hvad testen skal dække, er det let at tage udgangspunkt i det, der er nyt, eller det, kunden spørger om. En trusselsmodel giver et andet udgangspunkt: de dele af produktet, hvor en fejl har størst konsekvens for kunderne. Det kan være adskillelsen mellem kunder, administrationen af brugere eller en integration med adgang til mange kunders data.

Omfanget bliver lettere at forsvare, når det kan føres tilbage til en vurdering. Spørger en kunde, hvorfor et modul ikke var med, kan I svare ud fra modellen frem for ud fra budgettet alene. Hvad der påvirker omfanget, og dermed prisen, kan I drøfte ud fra pris og tilbud. → Hvad skal med i en test af et SaaS-produkt?

Hvornår modellen laves

OWASP anbefaler, at trusselsmodellering sker tidligt, gerne i designfasen, og at modellen holdes ved lige, efterhånden som systemet ændrer sig. For et softwarehus betyder det, at modellen ikke er et dokument, der skrives én gang før den årlige test. Den opdateres, når der kommer nye dele, nye integrationer eller en ny arkitektur. → Større omskrivning eller ny arkitektur

Har I ingen model i dag, er tiden op til en planlagt test en god anledning til at lave den første. Den behøver ikke være stor. En tegning af produktets dele, en liste over de vigtigste trusler og en kort beskrivelse af, hvad I har gjort ved dem, er nok til at gøre en forskel.

Modellen over for kunderne

Kunder spørger måske ikke direkte efter en trusselsmodel, men de kan spørge, hvordan I arbejder med sikkerhed i udviklingen. At kunne svare, at I laver trusselsmodeller ved større ændringer, og at de bruges til at målrette testen, er et konkret svar. → Spørgsmål om sikker udvikling

Selve modellen er derimod et internt dokument. Den beskriver produktets svage steder og bør behandles med samme fortrolighed som de tekniske bilag i rapporten. Vil en kunde se den, kan en kort beskrivelse af metoden og de vigtigste konklusioner være nok. Det viser, at arbejdet bliver gjort, uden at kortet over produktets svage steder forlader huset.

Et tænkt eksempel

Et softwarehus med et bookingsystem til klinikker skal have sin første pentest, fordi en stor kunde kræver det. Før testen bruger to udviklere og produktejeren en eftermiddag på en simpel model. De tegner produktets dele: bookingsiden, som patienterne bruger, klinikkernes administration, en integration til et journalsystem og en supportfunktion, hvor medarbejdere kan logge ind som en klinik for at hjælpe.

Da de når til spørgsmålet om, hvad der kan gå galt, bliver supportfunktionen og integrationen hurtigt de to steder, der fylder mest. Begge giver adgang på tværs af klinikker. Bookingsiden er synlig udefra, men rummer færre data.

Modellen bliver sendt til testeren sammen med testkonti. Testen bruger derfor mere tid på supportadgangen og integrationen end på bookingsiden, og omfangsafsnittet forklarer hvorfor. Da kunden spørger, kan sælgeren pege på modellen som begrundelse for prioriteringen.

Det skal I lade være med

Lade modellen erstatte testen · den beskriver, hvad I tror, testen viser, hvad der holder.
Skrive den én gang og glemme den · produktet ændrer sig, og modellen skal følge med.
Give testeren modellen som en grænse · det, der ikke står i modellen, kan også være sårbart.
Gøre den så stor, at ingen vil bruge den · en kort model, der bruges, er bedre end en lang, der ikke gør.
Dele den frit med kunder · den peger direkte på produktets svage steder.
Holde den for jer selv over for testeren · en model, testeren ikke kender, gør ikke testen skarpere.

Hvad kan og ikke kan konkluderes

En trusselsmodel kan gøre testen mere målrettet og omfanget lettere at begrunde over for kunderne. Den kan ikke vise, at produktet er sikkert, og den kan ikke dække trusler, ingen har tænkt på. Det er netop dét, testen er til for.

Tjekliste til trusselsmodellen

☐ Findes der en beskrivelse af produktets dele, dataflow og grænser?
☐ Er de vigtigste trusler og jeres svar på dem skrevet ned?
☐ Er modellen opdateret efter seneste større ændring?
☐ Har testeren fået modellen før testen?
☐ Er omfanget af testen begrundet ud fra modellen?
☐ Er det besluttet, hvad kunderne må se af den?

Kilder

OWASP Cheat Sheet Series: Threat Modeling: trusselsmodellering som struktureret proces, de fire spørgsmål og anbefalingen om at modellere tidligt og løbende.
NIST SP 800-218, Secure Software Development Framework: opgave PW.1.1 om risikomodellering, fx trusselsmodellering, og grundigere vurdering af områder med høj risiko.

Senest gennemgået: oktober 2026.