Uge 43: Threat Modeling
- Kenneth H Sørensen
- Oct 27
- 7 min read
Updated: Nov 1
Threat Modeling i SSDLC
Jeg så i sidste uge på application security generelt og begreber som shift-left, og security by design, men hvordan gør man det rent faktisk i praksis.
Jeg vil se på
SSDLC - en struktureret proces der indbygger sikkerhed i alle faser af udviklingen
Threat Modeling - en teknik til at identificere og mitigere trusler allerede i designfasen
Herunder Shostacks Data Flow Diagram (DFD3)
OWASP SAMM - en model til at måle, hvor godt organisationen arbejder med sikkerhed, og hvor den kan forbedres.
Indhold
Secure Software Development Lifecycle (SSDLC)
SSDLC er et framework, der sikrer, at sikkerhed ikke bliver et separat trin, men en integreret del af hele udviklingsprocessen.
Formålet er at opdage og håndtere sårbarheder, så tidligt som muligt, før de når produktion.
SSDLC bygger på den klassiske Software Development Lifecycle (SDLC), som dækker faser som krav, design, implementering, test, udrulning og vedligeholdelse.
Der findes mange modeller for SDLC - f.eks waterfall, agile og DevOps, men de adresserer sjældent sikkerhed eksplicit.
Derfor udvider SSDLC den klassiske model ved at indarbejde sikkerhed i hver fase af udviklingen.
Faser og aktiviteter:
Planlægning / Krav - fælles grundlag for sikkerhedskrav, inden udv. (tidligt)
Identificér sikkerhedskrav og risici
Resultat bruges som input til designfasen (threat modeling)
Lav risikovurdering (sandsynlighed × konsekvens) og fastlæg sikkerhedsmål
1-5 i hver kategori ganges samme = risikoniveau for hver ting der kan gå galt
Bruges til at prioritere trusler og definere acceptable risikoniveauer
Design - design af sikkert system og plan for modforanstaltninger, før kode
Kortlæg arkitektur og dataflow, og marker trust boundaries
F.eks Shostack dataflow diagram DFD3
Udfør Threat Modeling for at finde trusler og planlægge kontroller
F.eks STRIDE
Implementering - sikre, at koden skrives og valideres med sikkerhed i fokus
Følg secure coding practices (mønstre) og udfør kode-reviews
Undgå almindelige fejl som SQL Injection, XSS, og hardcodede secrets
Brug SAST (Static Analysis Security Testing) til at finde fejl i koden
Automatisk scanning for kendte sårbarheder under udviklingen
Test - sikre, at app er sikker, når den kører
Brug DAST / IAST / SCA til at teste den kørende applikation
DAST: tester applikationen udefra (black box)
IAST: kombinerer intern (SAST) og ekstern test (DAST)
SCA: finder sårbare afhængigheder og biblioteker
Udrulning - minimere angrebsfladen ved korrekt deployment og konfig
Brug sikre konfigurationer, hemmelighedshåndtering og system-hardening
Sørg for, at prod.miljøet er korrekt konfigureret, og at secrets opbevares sikkert
(f.eks i Key Vault)
Vedligeholdelse - fastholde sikkerhed over tid
Patch løbende, overvåg hændelser og log relevant sikkerhedsdata
Gør reaktion mulig ift. opdatering, nye trusler og sikkerhedshændelser
SSDLC skaber et fælles sprog for udviklere og sikkerhedsfolk.
Det gør det muligt at planlægge sikkerhed systematisk (proaktivt) i stedet for reaktivt.
Threat Modeling
Threat Modeling er en metode til systematisk at identificere og forstå potentielle trusler mod et system. Den bruges til at besvare det klassiske spørgsmål: "Hvad kan gå galt?"
Formålet er at finde og mitigere sikkerhedsproblemer tidligt i udviklingsprocessen, inden de når produktion.
Metoden benytter et Four Questions Framework
Hvad bygger vi? - forstå systemets arkitektur, dataflow og komponenter
Hvad kan gå galt? - identificér trusler, sårbarheder og mulige angreb
Hvad gør vi ved det? - planlæg konkrete kontroller og modforanstaltninger
Har vi gjort nok? - er risikoniveau acceptabelt? er modforanstaltningerne tilstrækkelige?
STRIDE-modellen
En af de mest anvendte metoder i threat modeling er STRIDE, udviklet af Microsoft.
STRIDE kategoriserer trusler ud fra, hvilken sikkerhedsegenskab de truer.
Kategori | Betydning | Egenskab den bryder |
S - Spoofing | Forfalskning af identitet | Authentication (Autenticitet) |
T - Tampering | Ændring af data | Integrity (Integritet) |
R - Repudiation | Benægtelse af handling | Non-repudiation (Ansvarlighed / bevisbarhed) |
I - Information Disclosure | Læk af data | Confidentiality (Fortrolighed) |
D - Denial of Service | Overbelastning | Availability (Tilgængelighed / Robusthed) |
E - Elevation of Privilege | Uaut. adgangsforøgelse | Authorization / Access Control (Adgangsstyring) |
Eks på trusler og kontroller - OBS: Se konkret STRIDE-analyse for Use Case 1 senere
Kategori | Eksempel på trussel | Mitigeringsidé |
Spoofing | Angriber udgiver sig for en intern service | Brug mTLS og valider service-certifikater |
Tampering | Ændring af data under upload eller i DB | Checksums og signerede URLs |
Repudiation | Bruger nægter at have foretaget en handling | Audit logs, korrelations-ID’er og tidsstempler |
Information Disclosure | Data eller URLs lækker til uvedkommende | HTTPS, korte TTL’er, least privilege |
Denial of Service | Mange store uploads overbelaster systemet | Rate limiting og kvoter pr. tenant |
Elevation of Privilege | Intern komponent får for høje rettigheder | Scoped service-tokens og rollebaseret adgang |
Hvordan SSDLC og Threat Modeling hænger sammen
SSDLC definerer hvornår sikkerhed skal indgå i arbejdet - (proces)
Threat Modeling er en del af SSDLC og definerer hvad der konkret skal sikres - (metode)
Trusselsmodellen fra designfasen bliver til krav og opgaver i de senere faser
Implementering - udfør validering, rate-limit og logging
Test - verificér, at mitigeringer virker
Vedligehold - overvåg at antagelserne stadig holder
Kombinationen af SSDLC og Threat Modeling realiserer
shift-left - flyt sikkerhed tidligt i udviklingen
Security by Design - indbyg sikkerhed i arkitektur og kode
Samt udgør grundlaget for moderne DevSecOps, hvor sikkerhed integreres i hele udviklings- og driftslivscyklussen.
OWASP SAMM - måling af modenhed
Formål
OWASP SAMM (Software Assurance Maturity Model) bruges til at måle og forbedre, hvor godt en organisation arbejder med sikkerhed i sin udviklingsproces.
Sammenhæng
SSDLC definerer hvordan og hvornår sikkerhed skal indgå i udviklingen.
Threat Modeling identificerer hvad der konkret skal sikres.
SAMM vurderer hvor modent arbejdet med sikkerhed er.
Modellen
SAMM opdeler modenhed i niveau 0–3 inden for fire hovedområder:
Styring
Design
Implementering
Verifikation
Ikke alle organisationer skal sigte mod niveau 3 på alt.
Det afhænger af risikoprofil, forretningskontekst, og ressourcer.
Et mindre udviklingsteam kan have passende sikkerhed på niveau 1–2,
mens orgs. med følsomme data eller compliance-krav bør ligge højere.
Delkonklusion
SAMM fungerer som et kompas for løbende forbedring
det viser, hvor org står nu, og hvor den skal modnes næste gang
STRIDE-analyse - Use Case 1: Upload billede
Afgrænsning
Analysen dækker Use Case 1: Upload billede, hvor data bevæger sig fra brugerens upload i mobilappen til, at systemet har registreret billedet og udsendt eventen ImageUploaded.
Mobilappen og API Gateway udvikles af andre teammedlemmer og indgår derfor kun som eksterne kald mod backend.
Analysen omfatter kun backend-delen, hvor trusler og modforanstaltninger kan styres direkte.
Egne modeller VS Shostack-DFD
Jeg har tidligere tegnet egne modeller, der beskriver funktionelle flows mellem komponenter.
Når de sammenlignes med Shostacks Data Flow Diagram (DFD)-metode, bliver det tydeligt, at mine modeller mangler sikkerhedsrelevante elementer
pilene angiver ikke kommunikationstype eller protokol
trust boundaries mellem zoner er ikke markeret
datastores er ikke modelleret som selvstændige elementer
Et korrekt DFD skal ikke vise funktionalitet, men dataflows og tillidsgrænser, fordi det er det, STRIDE-analysen anvendes på.
Egne modeller for ref.:
Disse figurer danner grundlaget for det formelle DFD, der anvendes i analysen
Trackunit system indledende model (Image 1)
Min del (de grå microservices, DB og storage) (Image 2)
Data Flow Diagram (level 1)
Formålet med DFD'et er at vise hvordan data bevæger sig mellem processer, datalagre og eksterne aktører, og hvor trust boundaries opstår.
Notation Data Flow Diagram (DFD3)
Firkanter (skarp hjørne) = eksterne processer
Firkanter (runde hjørner) = intern proces (egen komponent)
Cylinder = datastores
Pile = kommunikationstype (f.eks HTTPS, mTLS, SASL/SSL)
Firkanter (stiplede linjer) = trust zones (område med fælles sikkerhedsniveau)
External zone: Human user og mobile app (untrusted)
API Edge (DMZ): API Gateway, validerer tokens og videresender trafik via mTLS
Internal Trust Zone: Backend services (Ingestion, Storage, Media Access, AI, Kafka, MinIO) som kommunikerer over mTLS og SASL/SSL
JWT/OAuth2 anvendes eksternt mellem klient og gateway
mTLS sikrer gensidig autentifikation og kryptering internt i backend
Et level 1 DFD bør vise de vigtigste kommunikationslinjer.
Hver pil mellem to zoner repræsenterer en trust boundary, som STRIDE-analysen efterfølgende adresserer.
DFD: Vores Trackunit system
DFD: 'Use Case 1 - Upload billede' (Image 4)
STRIDE for trust boundary mellem API gateway og Ingestion Service
Kategori | Eksempel på trussel | Mitigeringsidé |
Spoofing | Angriber udgiver sig for en intern service | Kræv JWT / OAuth token fra mobilapp (Gateway ansvar). Brug mTLS mellem interne services. Valider service-certifikater. |
Tampering | Ændring af data under upload eller i DB | Brug presigned HTTPS URL'er med kort TTL. Valider checksum / ETag efter upload. Evt. versionering i MinIO. |
Repudiation | Bruger nægter at have foretaget en handling | Log korrelations-ID'er. Gem timestamp, userId og checksum. Central audit logging. |
Information Disclosure | Data eller URLs lækker til uvedkommende | Presigned URL'er med kort TTL. Tvungen HTTPS. Log ikke URL'er. Begræns adgang til objektets key. |
Denial of Service | Mange store uploads overbelaster systemet | Rate limiting pr. bruger/tenant. Maks. filstørrelse. Kø- eller backpressure-mekanisme. Overvågning og alarmer. |
Elevation of Privilege | Intern komponent får for høje rettigheder | Scoped service-tokens og rollebaseret adgang. Least-privilege servicekonti Afgrænsede MinIO og Kafka-rettigheder. Opbevar secrets sikkert (ikke i kode). |
Opsummering
De er alle relevante trusler, dog er repudiation en lille smule mindre relevant i den her use case.
Dvs. mest relevante trusler i denne use case er
Spoofing
Tampering
Repudiation
Information Disclosure
Denial of Service
Elevation of Privilege
De afspejler backend-ansvaret for autenticitet, integritet, fortrolighed, adgangsstyring og robusthed.
Der fokuseres derfor på
sikre forbindelser (HTTPS og mTLS)
korrekt autentificering
begrænsede rettigheder og ressourcekontrol for at beskytte systemet mod uautoriseret adgang, datatab og overbelastning.
Konklusion
Ovenstående giver et klart billede af, hvordan sikkerhed kan bygges systematisk ind i udviklingen.
SSDLC giver processen, Threat Modeling gør den konkret, og SAMM hjælper med at måle, hvor godt det udføres.
Tilsammen skaber de en ramme, hvor sikkerhed bliver en kontinuerlig del af softwareudviklingens kvalitet.
Refleksion
Arbejdet med SSDLC, Threat Modeling og STRIDE har gjort det tydeligt, hvor mange sikkerhedsbeslutninger der skal træffes tidligt i udviklingsprocessen.
Jeg forstod især, hvor vigtigt det er at tænke i dataflow og tillidszoner (trust boundaries) fremfor kun funktionalitet.
At tegne et korrekt DFD og udføre STRIDE på en konkret use case gjorde sammenhængen mellem teori og praksis meget tydelig.
Det ændrer min tankegang og fremtidig tilgang fra at "bygge og derefter sikre" til at designe med sikkerhed fra start.
Jeg tænker dog, at det kræver erfaring at vurdere trusselsniveauer realistisk og at balancere mellem detaljer og overblik.
Det er et område, jeg vil arbejde mere med for at gøre min trusselsmodellering mere effektiv og konsistent i fremtiden.
Videre plan
Jeg er i gang med at færdiggøre Use Case 1 og udføre smoke test for at bekræfte funktionaliteten, før jeg begynder på de mere sikkerhedsrelaterede dele.
Når kernen fungerer stabilt, vil jeg gradvist begynde at implementere principperne fra SSDLC, Threat Modeling og STRIDE i koden.
Fokus vil være på at gøre sikkerhed til en integreret del af udviklingen fremfor et eftertrin, herunder:
Sikre forbindelser og autentificering (f.eks mTLS og tokens)
Logging og sporing af hændelser
Least privilege og ressourcekontrol
Senere i forløbet vil jeg se på, hvordan SAST, DAST og SCA kan integreres i CI/CD-pipelinen (GitHub Actions) for at automatisere sikkerhed i build- og deploy-processen.
Ressourcer
OWASP SAMM
Artikel: Software Assurance Maturity Model Overview
NIST SSDF (SP 800-218)
Artikel: Secure Software Development Framework (SSDF) Explained
(Læst intro - skimmet resten)
OWASP Threat Modeling Cheat Sheet
Artikel: Threat Modeling Cheat Sheet Introduction
Microsoft Threat Modeling
Dokumentation: Introduction to Microsoft Threat Modeling Tool
Adam Shostack
Blog: Data Flow Diagrams 3.0
YouTube (video): Data Flow Diagrams in Threat Modeling
GitHub
Evt. videre læsning
Shostack, A. - "Threat Modeling: Designing for Security" (Wiley, 2014)
OWASP ASVS - Application Security Verification Standard
BSIMM 13 - Building Security In Maturity Model
