🛡️ Øvelse 13 – Trusselsmodellering af webapplikation

ℹ️ Information

Denne øvelse bygger videre på jeres arbejde med system- og sikkerhedsmål i øvelse 11 og risikovurdering i øvelse 12.

I skal nu tage udgangspunkt i det højest prioriterede misbrugstilfælde og undersøge:

Hvordan kan dette misbrugstilfælde realiseres teknisk gennem systemets arkitektur?

Hvor misbrugstilfældet beskriver, hvad der kan gå galt for forretningen, bevæger vi os nu ned på et teknisk niveau og undersøger, hvordan det kan ske.

📊 Overblik: Fra mål til tekniske trusler

[Systemmål]
     ↓
[Sikkerhedsmål / misbrugstilfælde]
     ↓
[Risikovurdering og prioritering]
     ↓
[Trusselsmodellering]
     ↓
[Tekniske trusler]

🧭 Shostacks fire grundspørgsmål

Trusselsmodellering kan struktureres omkring Shostacks fire grundspørgsmål:

What are we working on?
What can go wrong?
What are we going to do about it?
Did we do a good enough job?

I denne øvelse arbejder I primært med spørgsmål 1 og 2.

I vores kontekst betyder det:

1. Forstå og visualisér systemet

Hvilken del af arkitekturen er relevant for det valgte misbrugstilfælde?
Hvilke komponenter, dataflows og tillidsgrænser indgår?

2. Identificér tekniske trusler

Hvordan kan misbrugstilfældet realiseres gennem denne del af arkitekturen?
Brug STRIDE som hjælp til at identificere relevante trusler.

De næste spørgsmål behandles senere i udviklingsprocessen:

3. Mitigation / afhjælpning

Hvilke sikkerhedsforanstaltninger skal reducere eller håndtere truslerne?

4. Validering

Har vores sikkerhedsforanstaltninger reduceret risikoen tilstrækkeligt?
Er trusselsmodellen stadig relevant?

🧭 I denne øvelse identificerer I problemerne – I skal endnu ikke designe løsningerne.

🔍 Fokus i denne øvelse

I risikovurderingen arbejdede I med:

Hvor vigtigt er dette misbrugstilfælde?

I trusselsmodelleringen spørger vi i stedet:

Hvordan kan det prioriterede misbrugstilfælde realiseres teknisk?

Fokus er derfor på:

hvilke dele af arkitekturen der er relevante for misbrugstilfældet
hvilke dataflows der indgår
hvor der findes tillidsgrænser
hvilke tekniske trusler der kan føre til, at misbrugstilfældet realiseres

Trusselsmodellering handler dermed ikke om at finde alle tænkelige problemer i hele systemet.

Vi afgrænser analysen med udgangspunkt i de risici, vi tidligere har prioriteret.

⚠️ I skal ikke reverse engineere eller dokumentere hele systemet.

Find kun den del af arkitekturen, som I har brug for at forstå for at kunne undersøge det valgte misbrugstilfælde.

🛠️ STRIDE-modellen

STRIDE er en model, der hjælper med at kategorisere og identificere tekniske trusler.

Kategori	Spørgsmål
Spoofing	Kan nogen udgive sig for at være en anden?
Tampering	Kan data eller funktionalitet ændres uautoriseret?
Repudiation	Kan en aktør benægte at have udført en handling, uden at systemet kan dokumentere det modsatte?
Information Disclosure	Kan uvedkommende få adgang til information?
Denial of Service	Kan nogen reducere eller forhindre systemets tilgængelighed?
Elevation of Privilege	Kan nogen opnå rettigheder, de ikke burde have?

💡 STRIDE er et brainstormingsværktøj – ikke en facitliste.

Ikke alle STRIDE-kategorier behøver at være relevante for alle komponenter eller dataflows.

STRIDE hjælper jer med at stille spørgsmål til arkitekturen. Modellen identificerer trusler – ikke nødvendigvis konkrete sårbarheder.

En sårbarhed er en svaghed i systemet, som kan gøre det muligt for en trussel at blive realiseret.

STRIDE som struktur for den indledende analyse

STRIDE kan bruges som struktur for den fælles samtale om systemet.

Tag eksempelvis en komponent, et dataflow eller en tillidsgrænse ad gangen og spørg:

Kan Spoofing være relevant her?

Kan data ændres uautoriseret her?

Kan information blive eksponeret her?

Kan nogen opnå flere rettigheder end tiltænkt?

STRIDE giver ikke nødvendigvis svaret. Modellen hjælper jer med systematisk at stille spørgsmålene og bringe gruppens eksisterende viden om systemet frem.

Eksempelvis kan en person i gruppen sige:

"Jeg har lige gennemgået vores autentificeringsmekanisme. Den ser ud til at håndtere dette, men lad os notere den antagelse."

En anden kan måske sige:

"Vi har faktisk ikke gennemgået denne del af datahåndteringen længe. Vi ved derfor ikke, om data kan blive læst eller ændret på en måde, som ikke er tilsigtet. Det bør vi undersøge nærmere senere."

I det sidste eksempel kan Information Disclosure eller Tampering være relevante trusler.

Trusselsmodelleringen fortæller os ikke nødvendigvis, hvilken konkret sårbarhed der eventuelt findes. Den hjælper os derimod med at identificere hvilken del af systemet og hvilken type problem vi bør undersøge nærmere.

På den måde kan trusselsmodellen bruges til at indsnævre den efterfølgende analyse af implementeringen. I stedet for at undersøge hele kodebasen lige grundigt kan vi rette vores opmærksomhed mod de komponenter, dataflows eller funktioner, hvor de relevante trusler er identificeret.

Den mere konkrete undersøgelse kan derefter foretages gennem eksempelvis kodegennemgang, test eller andre analysemetoder.

Diskussionen kan dermed både synliggøre:

hvad teamet allerede ved
hvilke sikkerhedsantagelser teamet bygger på
hvor gruppens medlemmer har forskellig viden
hvilke områder ingen i gruppen ved nok om endnu
hvad der bør undersøges nærmere senere

🗺️ Visualisering af arkitekturen

Start med det højest prioriterede misbrugstilfælde fra øvelse 12.

Tegn derefter den del af systemets tekniske arkitektur, der er relevant for dette misbrugstilfælde.

Tag udgangspunkt i de store og vigtige dele af systemet. Det kan eksempelvis være:

en webapplikation
et API eller en backend
en database eller et andet datalager
en ekstern tjeneste

Vis de relevante forbindelser og dataflows mellem delene.

Markér derefter de tillidsgrænser, som er relevante for analysen.

💡 Formålet er ikke at tegne hele systemets arkitektur eller beskrive den enkelte applikations interne opbygning.

I skal kun tegne de dele, der er nødvendige for at kunne undersøge, hvordan det valgte misbrugstilfælde kan realiseres teknisk.

Et simpelt blokdiagram er tilstrækkeligt.

Tillidsgrænser

En tillidsgrænse findes dér, hvor data eller kommunikation bevæger sig mellem områder med forskellige niveauer af tillid eller forskellige sikkerhedsantagelser.

Det kan eksempelvis være:

mellem internettet og et internt system
mellem en ekstern tjeneste og jeres system
mellem systemdele med forskellige sikkerhedsrettigheder

⚠️ En forbindelse mellem to komponenter er ikke automatisk en tillidsgrænse. Det afhænger af, om tillidsniveauet eller sikkerhedsantagelserne ændrer sig.

🔄 Trusselsmodellering er iterativ

En trusselsmodel er ikke noget, der udarbejdes én gang og derefter er færdigt.

Den bør revurderes, når eksempelvis:

nye funktioner introduceres
arkitekturen ændres
nye integrationer tilføjes
nye trusler bliver kendte
risikovurderingen ændrer sig

Når der senere tilføjes sikkerhedsforanstaltninger, bør disse også indgå i den løbende vurdering.

⚠️ En forældet trusselsmodel kan give et misvisende billede af systemets aktuelle trusler.

🤝 Trusselsmodellering som team- og videndelingsaktivitet

Trusselsmodellering fungerer godt som en fælles brainstorming- og videndelingsaktivitet.

Tegn diagrammet synligt for hele gruppen og diskutér:

Hvordan kunne det prioriterede misbrugstilfælde blive realiseret gennem denne arkitektur?

Gruppens medlemmer vil ofte have forskellig viden om systemet.

Nogle kender måske kildekoden bedst, mens andre har bedre forståelse for eksempelvis Docker-konfigurationen, HTTP-kommunikationen, databasen, infrastrukturen eller forretningslogikken.

Når I sammen tegner arkitekturen og anvender STRIDE på de relevante dele af systemet, bliver denne viden gjort synlig og delt i gruppen.

Trusselsmodelleringen kan derfor også afsløre områder, hvor teamet mangler viden.

Hvis en person eksempelvis spørger:

"Ved vi egentlig, hvordan autorisation bliver håndhævet mellem disse to komponenter?"

og ingen i gruppen kan svare sikkert, er det i sig selv et vigtigt resultat af analysen.

Det betyder ikke nødvendigvis, at der findes en sårbarhed. Det betyder, at teamet har identificeret et område, hvor der mangler viden, eller hvor en sikkerhedsantagelse bør undersøges.

Formålet er derfor ikke kun at producere et diagram eller en liste over trusler.

Trusselsmodelleringen skal også bidrage til en fælles forståelse af systemets arkitektur, sikkerhedsantagelser, eksisterende viden og områder, der kræver yderligere undersøgelse.

🔎 Hvordan finder I systemets arkitektur?

I får ikke nødvendigvis et færdigt arkitekturdiagram udleveret.

En del af trusselsmodelleringen er derfor at danne sig et kvalificeret billede af, hvordan systemet er opbygget, og hvilke komponenter der er relevante for det valgte misbrugstilfælde.

Der er flere måder at undersøge arkitekturen på. I kan eksempelvis:

undersøge kildekoden for at identificere applikationer, services, API'er, datalagre og eksterne integrationer
undersøge Docker-konfigurationen og de kørende containere for at se, hvilke runtime-komponenter systemet består af
observere applikationens kommunikation med browserens udviklerværktøjer eller Burp Suite for at identificere HTTP-kald, endpoints og dataflows
læse konfigurationsfiler og dokumentation for at identificere databaser, services og eksterne afhængigheder
kombinere flere af disse tilgange for at skabe et mere kvalificeret billede

💡 De forskellige metoder viser forskellige dele af systemet.

Eksempelvis viser Burp Suite primært den kommunikation, som kan observeres mellem klienten og systemet, mens kildekoden eller Docker-konfigurationen kan afsløre komponenter, som ikke er direkte synlige fra klienten.

Formålet er ikke at kortlægge hele systemet perfekt.

I skal identificere de komponenter, dataflows og tillidsgrænser, der er relevante for det misbrugstilfælde, I analyserer.

📝 Instruktioner

🎯 Udvælg det højest prioriterede misbrugstilfælde fra øvelse 12.
🔎 Undersøg systemet og identificér den del af arkitekturen, der er relevant for misbrugstilfældet.

I kan eksempelvis:

undersøge kildekoden
undersøge Docker-konfigurationen og de kørende containere
observere HTTP-kommunikation med browserens udviklerværktøjer eller Burp Suite
undersøge konfigurationsfiler og dokumentation

Brug gerne flere metoder og sammenlign jeres observationer.

🗺️ Tegn et simpelt arkitekturdiagram, der viser de relevante systemkomponenter, eksterne systemer eller tjenester, dataflows og datalagre.
🚧 Identificér og markér relevante tillidsgrænser.
🛠️ Gennemgå de relevante komponenter, dataflows og tillidsgrænser med STRIDE.

Brug STRIDE til systematisk at spørge, hvilke tekniske trusler der kan være relevante.

Del den viden, I hver især allerede har om systemet, og vær opmærksomme på:

hvad I ved
hvilke antagelser I gør
hvor I er uenige
hvad I endnu ikke ved
🏷️ Markér de relevante STRIDE-kategorier og identificerede trusler på arkitekturdiagrammet ved de komponenter eller dataflows, hvor de er relevante.
🔗 Beskriv kort, hvordan de identificerede trusler kan bidrage til, at det valgte misbrugstilfælde realiseres.
❓ Notér eventuelle væsentlige antagelser, usikkerheder eller områder, som bør undersøges nærmere.

⚠️ Tip: Formålet er ikke at udføre sårbarhedstest eller bevise, at konkrete sårbarheder kan udnyttes. I skal udarbejde en trusselsmodel, hvor relevante tekniske trusler identificeres og knyttes til arkitekturen.

⚠️ Tip: Hold diagrammet simpelt. I skal ikke forstå eller dokumentere hele systemet. Find kun nok af arkitekturen til at kunne analysere det valgte misbrugstilfælde.

🔎 Fra trusselsmodellering til konkrete sårbarheder

Trusselsmodelleringen fortæller os ikke nødvendigvis, om der findes en konkret sårbarhed i implementeringen.

Den hjælper os derimod med at indsnævre, hvilke typer problemer vi bør lede efter, og hvor i systemet det giver mening at lede efter dem.

Eksempelvis:

Hvis Spoofing er en relevant trussel omkring en bestemt del af systemets autentificering, kan den del af implementeringen undersøges nærmere.
Hvis Tampering er relevant for et bestemt dataflow, kan den kode, der modtager, behandler eller gemmer disse data, undersøges nærmere.
Hvis Information Disclosure er relevant omkring et bestemt datalager eller en bestemt funktion, kan den relevante adgangskontrol og datahåndtering undersøges nærmere.
Hvis Elevation of Privilege er relevant mellem to dele af systemet, kan den relevante autorisation og rettighedskontrol undersøges nærmere.

På den måde hjælper trusselsmodelleringen med at gøre den efterfølgende analyse af implementeringen mere målrettet og risikobaseret.

I stedet for at undersøge hele systemets implementering lige grundigt kan vi bruge trusselsmodellen til at identificere de dele af systemet, hvor der er størst grund til at undersøge implementeringen nærmere.

💡 Trusselsmodellering identificerer hvilke tekniske trusler der er relevante, og hvor i systemet de er relevante.

Efterfølgende kan kodegennemgang, sikkerhedstest og andre analysemetoder bruges til at undersøge, om der findes konkrete sårbarheder i de relevante dele af implementeringen, som gør det muligt at realisere disse trusler.

Det er også her, de spørgsmål og videnshuller, som gruppen identificerede under trusselsmodelleringen, kan bruges til at målrette den videre undersøgelse.

💭 Refleksionsspørgsmål

Hvilke kilder brugte I til at forstå den relevante del af arkitekturen, og hvad kunne de forskellige kilder vise jer?
Hvilken viden blev delt eller gjort tydelig under trusselsmodelleringen? Opstod der antagelser, usikkerheder eller spørgsmål, som gruppen bør undersøge nærmere?
Hvordan hjalp STRIDE jer med systematisk at stille spørgsmål til arkitekturen og identificere tekniske trusler, som I måske ikke selv havde tænkt på?
Hvorfor er det vigtigt at tage udgangspunkt i et prioriteret misbrugstilfælde frem for at forsøge at analysere hele systemet på én gang?
Hvad er forskellen mellem et misbrugstilfælde, en teknisk trussel og en sårbarhed, og hvordan kan trusselsmodellen hjælpe med at identificere, hvilke dele af implementeringen der bør undersøges nærmere?

✅ Selvevaluering – du har forstået trusselsmodellering, når du...

Du har forstået den grundlæggende tilgang i denne øvelse, når du kan:

forklare forskellen mellem risikovurdering og trusselsmodellering
forklare, hvorfor et prioriteret misbrugstilfælde kan anvendes som udgangspunkt for trusselsmodellering
afgrænse den del af arkitekturen, der er relevant for et konkret misbrugstilfælde
anvende forskellige informationskilder til at danne et kvalificeret billede af systemets arkitektur
tegne et enkelt arkitekturdiagram med relevante komponenter og dataflows
forklare, hvad en tillidsgrænse er
anvende STRIDE som struktur for en indledende analyse og fælles diskussion
forklare, hvordan trusselsmodellering kan fungere som en videndelingsaktivitet i et udviklingsteam
identificere og synliggøre antagelser, usikkerheder og manglende viden
forklare forskellen mellem et misbrugstilfælde, en teknisk trussel og en sårbarhed
forklare, hvordan en identificeret teknisk trussel kan bidrage til, at et misbrugstilfælde realiseres
forklare, hvordan en trusselsmodel kan hjælpe med at identificere hvilke dele af implementeringen der bør undersøges nærmere
forklare, hvordan en trusselsmodel kan bruges til at målrette senere kodegennemgang og sikkerhedstest
forklare, hvorfor trusselsmodellering er en løbende og iterativ aktivitet

💡 Hvis I kan starte med et prioriteret misbrugstilfælde og forklare hvor i arkitekturen og gennem hvilke tekniske trusler det kan realiseres, samtidig med at I kan pege på hvad I ved, hvad I endnu mangler viden om, og hvilke dele af implementeringen der bør undersøges nærmere, har I forstået den grundlæggende idé med trusselsmodellering.

📚 Links

Threat Modeling Manifesto

Last update: 2026-09-23 09:54:23