För mig blir Threat modeling värdefullt först när resultatet går att testa med både positiva och negativa kontrollfall. Threat modeling flyttar säkerhetsdiskussionen till designfasen genom att fråga vilka tillgångar, trust boundaries och missbruksvägar som finns innan systemet är färdigbyggt.
Threat modeling i praktiken
Första byggstenen: Data flow diagrams gör gränser och externa beroenden synliga. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
En annan viktig del: STRIDE kan användas som frågebatteri men är inte ett mål i sig. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Det tekniska ankaret: Abuse cases beskriver hur en legitim funktion kan missbrukas. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Det som ofta avgör kvaliteten: Riskägare behöver kunna acceptera eller prioritera designåtgärder. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Arbetsgång utan genvägar
- Rita den enklaste arkitekturen med dataflöden.
- Markera trust boundaries och känslig data.
- Gå igenom varje flöde med konkreta missbruksscenarier.
- Välj kontroller som kan testas senare.
- Lägg kvarvarande risk i backlog med ägare.
För Threat modeling håller jag därför införandet i små steg. Då går det att skilja ett säkerhetsproblem från ett rent driftfel och att rulla tillbaka just den ändring som gav ett oväntat resultat.
Ett testbart exempel
För en filuppladdning markerar jag klient, API, objektlagring och eventuell parser som separata komponenter. Då blir frågor om filtyp, malware, SSRF och parserisolering naturliga innan implementationen låser designen.
När en bra idé blir fel i drift
- Att göra modellen så detaljerad att ingen uppdaterar den.
- Att bara lista OWASP-kategorier utan koppling till den faktiska designen.
- Att threat modela efter release och kalla det förebyggande arbete.
Efterkontroll
För Threat modeling vill jag avsluta med mätbara efterkontroller i stället för att nöja mig med att en statusruta visar ”enabled”. De viktigaste kontrollerna här är:
- Varje högriskflöde har en kontroll eller accepterad risk.
- Kontrollerna kan översättas till testfall.
- Arkitekturförändring triggar uppdaterad modell.
Ett negativt test hör också till Threat modeling: den väg, identitet eller operation som inte ska vara tillåten ska misslyckas på ett förutsägbart sätt. Då kan nästa tekniker upprepa kontrollen och förstå både avsikten och gränsen.
Slutsats
Threat modeling – hitta designrisker innan de blir sårbarheter handlar därför inte om att samla fler säkerhetsinställningar. Det handlar om att minska en konkret risk med en kontroll som har tydligt scope, tydlig ägare och ett verifierbart resultat. När före-läge, förändring och eftertest dokumenteras blir säkerhetsarbetet både säkrare och lättare att förvalta.