Trusselsmodel: find appens vigtigste sikkerhedsrisici

Brug modellen til at vælge – ikke til at samle frygt

OWASP beskriver trusselsmodellering som en struktureret, gentagelig måde at forstå et system, finde relevante trusler og beslutte, hvad der skal gøres ved dem. Resultatet er ikke et certifikat for, at appen er sikker. Det er et vedligeholdt beslutningsgrundlag med afgrænsning, antagelser, prioriterede risici, handlinger og bevis.

Omfang

Den app, funktion eller brugerrejse, som vurderingen faktisk dækker.

Systemkort

Brugere, frontend, backend, datalagre, eksterne tjenester og forbindelserne mellem dem.

Trusler

Konkrete scenarier, som kan skade fortrolighed, data, adgang, økonomi eller arbejdsgange.

Beslutninger

Ejer, prioritet, valgt reaktion, kontrol, test og eventuel accepteret restrisiko.

Et enkelt flow kan være et bedre sted at begynde end hele virksomheden. Vælg for eksempel login, oprettelse af en booking, godkendelse af en udgift eller import af kundedata – alt efter hvor appens største konsekvens ligger.

Tegn det, der faktisk kører

Kortet må gerne være kasser og pile. Det vigtige er, at det viser eksterne aktører, processer, datalagre, dataflow og tillidsgrænser. En tillidsgrænse er et sted, hvor data eller kontrol skifter sikkerhedskontekst – eksempelvis fra browser til API, fra egen backend til en ekstern AI-tjeneste eller fra én virksomhed til en anden.

1. 1. Afgræns brugerrejsen: Skriv start, ønsket resultat og de forretningsregler, som altid skal holde.
2. 2. Placér aktørerne: Anonym bruger, medarbejder, administrator, support, automatisk job og eksterne systemer.
3. 3. Placér komponenterne: Browser eller mobilklient, API, funktioner, database, filager, køer og leverandørtjenester.
4. 4. Tegn dataflowet: Markér hvad der sendes, hvor identiteten kommer fra, og hvor data lagres eller forlader jeres kontrol.
5. 5. Markér grænserne: Internet, cloudprojekt, miljø, tenant, administrativ adgang og tredjepart er typiske steder at undersøge.

Spørg hvad der kan gå galt ved hver grænse

STRIDE er én mulig spørgeramme, ikke et krav til en bestemt teknologi. Den hjælper med at undersøge seks typer problemer systematisk. Brug også virksomhedens egne regler; en teknisk gyldig handling kan stadig være forkert for forretningen.

Gå også brugerrejsen igennem med en uærlig, men ellers gyldig bruger: Kan et trin springes over, gentages, udføres i forkert rækkefølge eller køres samtidigt fra to faner? OWASP fremhæver, at sådanne forretningslogiske fejl ofte ikke kan findes af en almindelig sårbarhedsscanner.

Skriv trusler som scenarier, andre kan teste

“Dårlig sikkerhed” kan ikke prioriteres eller testes. Brug en konkret sætning med aktør, handling, mål og konsekvens. Knyt den derefter til appens faktiske grænse og den regel, der skal holde.

Her kan der vælges en målbar modforanstaltning: Backend udleder virksomhed fra den godkendte identitet, kontrollerer fakturaens ejerskab ved hvert kald, logger afvisningen dataminimeret og har en negativ test med et id fra en anden testvirksomhed.

Prioritér efter skade og sandsynlighed

Talværdier kan give falsk præcision. Brug en enkel, dokumenteret vurdering og skriv usikkerheden ned. En sandsynlig mindre gene og et usandsynligt tab af alle kundedata kræver forskellige beslutninger, selv om begge får samme resultat i en grov formel.

• Konsekvens: Kan scenariet ramme persondata, penge, juridiske pligter, drift, flere kunder eller muligheden for at gendanne appen?
• Sandsynlighed: Er grænsen offentlig, kræver den login, er handlingen let at gentage, og findes der allerede kontroller?
• Eksponering: Hvor mange poster, brugere, tenants og eksterne handlinger kan ét fejltrin påvirke?
• Bevis: Er kontrollen kun en antagelse, eller findes der test, konfiguration, alarmer og dokumentation, som viser at den virker?

Sæt en navngiven ejer på de højest prioriterede scenarier. Et åbent punkt uden ejer, beslutning og kontroltidspunkt er stadig en ukendt driftsrisiko.

Vælg en bevidst reaktion på hver væsentlig trussel

OWASP beskriver fire overordnede reaktioner: reducér truslen, fjern årsagen, overfør ansvar på et aftalt grundlag eller acceptér risikoen. Accept må være en synlig forretningsbeslutning med begrundelse – ikke fravær af tid eller ejerskab.

• Reducér: Indfør eksempelvis server-side rettighedskontrol, rate limiting, MFA, backup eller en sikker godkendelsesregel.
• Fjern: Luk et ubrugt endpoint, drop en unødvendig datakopi eller fjern en funktion med uforholdsmæssig risiko.
• Overfør: Brug en leverandør til en afgrænset opgave, men dokumentér stadig grænseflade, aftale, ansvar og fejltilstand.
• Acceptér: Registrér hvem der accepterer hvilken restrisiko, hvorfor og hvornår beslutningen skal vurderes igen.

Gør reduktioner til krav, der kan afprøves. “Brug sikker login” er uklart. “En stjålet administratorsession kan tilbagekaldes, og testen bekræfter afvisning bagefter” kan bygges, testes og driftes.

Opdatér modellen, når virkeligheden ændrer sig

OWASP anbefaler at vedligeholde trusselsmodellen sammen med systemet. Genbesøg den afgrænsede del, når appen får en ny funktion, en ny integration, et andet dataflow, ændret infrastruktur eller efter en sikkerhedshændelse. Hele dokumentet behøver ikke omskrives ved hver lille rettelse.

• Gem diagram, trusselsliste, beslutninger og tests sammen med anden versionsstyret driftsdokumentation.
• Notér dato, omfang, deltagere, antagelser og den version eller arkitektur, modellen beskriver.
• Lad både en person med teknisk indsigt og en, der kender arbejdsgangen, gennemgå de vigtigste scenarier.
• Kontrollér at lukkede punkter stadig har et aktivt teknisk bevis i den kørende app.

Typiske fejl

• En generisk tjekliste kaldes en trusselsmodel: Den nævner kendte sårbarheder, men ikke appens komponenter, dataflow og forretningsregler.
• Kun en ekstern hacker medregnes: Fejlkonfiguration, en uærlig gyldig bruger, samtidige handlinger og leverandørsvigt bliver overset.
• Diagrammet viser kun frontend og database: Jobs, filer, AI-tjenester, webhooks, supportadgang og dashboardindstillinger mangler.
• Alt får høj prioritet: Teamet kan ikke se, hvad der skal håndteres nu, og hvad der er en begrundet restrisiko.
• Kontrollen findes kun i brugerfladen: Et direkte API-kald kan omgå den synlige knap eller rækkefølge.
• Dokumentet arkiveres efter mødet: Nye integrationer og hændelser ændrer systemet, mens risikobilledet står stille.

Tjekliste til en brugbar trusselsmodel

• ☐ Omfang, kritisk brugerrejse og forretningsregler er skrevet i almindeligt sprog.
• ☐ Aktører, frontend, backend, datalagre, jobs og eksterne tjenester er med på systemkortet.
• ☐ Dataflow og tillidsgrænser viser, hvor identitet, data eller kontrol skifter kontekst.
• ☐ Truslerne beskriver aktør, handling, mål, svaghed og konkret konsekvens.
• ☐ Både tekniske angreb, uærlige gyldige brugere, fejl og leverandørsvigt er overvejet.
• ☐ Konsekvens, sandsynlighed, eksponering og eksisterende bevis er vurderet uden falsk præcision.
• ☐ Hver væsentlig trussel har en ejer og en dokumenteret beslutning om reduktion, fjernelse, overførsel eller accept.
• ☐ Valgte kontroller er formuleret som målbare krav og dækket af relevante negative tests.
• ☐ Diagram, antagelser, beslutninger og testbevis er versionsstyret og kan findes af andre.
• ☐ Modellen har et aftalt kontrolpunkt ved væsentlige funktioner, integrationer, arkitekturændringer eller hændelser.

Brug risikobilledet til at vælge relevante guides

• Roller og rettigheder, hvis brugere kan nå forkerte funktioner eller data
• API-sikkerhed, hvis klienten kan omgå formularens grænser
• Botter og rate limiting, hvis et offentligt flow kan misbruges i stor skala
• Backup og gendannelse, hvis tab eller ødelæggelse af data er kritisk
• Logning og overvågning, hvis hændelser skal opdages og forklares
• Prompt injection, hvis AI-funktionen læser ubetroet indhold eller kan handle

Officielle kilder

Metoden og de tekniske begreber er kontrolleret mod aktuelle primærkilder. En trusselsmodel skal altid tilpasses den konkrete app, stack og forretning.

• OWASP: Threat Modeling Cheat Sheet
• OWASP: Threat Modeling
• OWASP: Business Logic Security Cheat Sheet
• Microsoft: Threat Modeling Tool