Threat modeling i YAML

Hotmodellering – att tänka som en hackare innan koden ens är skriven

Under åren har jag testat på ett och annat verktyg för säkerhet, men när det kommer till att faktiskt förutse sårbarheter är det få saker som slår en väl genomförd hotmodellering. Vi lägger ofta enormt mycket tid på att baka in rätt funktioner i våra system, men hur ofta sätter vi oss ner och frågar: "Vad är det absolut värsta som skulle kunna hända med vår arkitektur?" Det är precis det hotmodellering handlar om – och det är ett av de mest underskattade verktygen vi har för att bygga säkra system från grunden.

Att hitta hålen innan de grävs

Många tror att systemsäkerhet handlar om att installera brandväggar eller köra automatiska sårbarhetsskanningar på färdig kod. Det är naturligtvis viktigt, men hotmodellering sker långt tidigare. Det är en strukturerad process där vi analyserar systemets arkitektur innan, eller under tiden, vi bygger det. Genom att rita upp hur data flödar och identifiera potentiella svagheter kan vi stoppa säkerhetshål innan de ens har blivit till kod. Det sparar inte bara tid, utan också enorma mängder pengar och framtida frustration.

Fällan med stelbenta verktyg

Om du har testat hotmodellering tidigare har du säkert stött på det stora problemet: dokumentationen. Det finns en uppsjö av riktigt dåliga verktyg från tunga aktörer som OWASP och Microsoft för just detta ändamål. Tyvärr tillför de sällan något av värde till det dagliga arbetet. Istället blir de ofta administrativa monster som innebär att modellerna snabbt blir utdaterade, tappar sin relevans och till slut glöms bort i något hörn.

Från tunga rapporter till kod i ditt repo

Själv har jag fastnat för Threagile https://github.com/Threagile/threagile. Istället för att klicka runt i sega, grafiska användargränssnitt görs hela dokumentationen och modelleringen här direkt i YAML-filer. Utifrån denna rådata genererar verktyget sedan dina rapporter och diagram helt automatiskt. Detta öppnar upp för ett mycket smartare arbetsflöde:

• Automatisk versionshantering: Genom att lägga modellen direkt i ditt källkodsrepo följer den med dina vanliga releaser.
• Tydlig spårbarhet: Du ser exakt när och varför arkitekturen ändrades ur ett säkerhetsperspektiv.
• Levande dokumentation: Säkerhetsmodellen blir en naturlig del av utvecklarnas vardag. Byggs in i CI/CD-kedjan, rapport som PDF eller HTML. Visst, arbetet tar lite mer tid initialt och tröskeln är något högre i början. Men genom att göra ett bra och ordentligt jobb tidigt sparar du massvis med tid och akuta sårbarhetsfixar under projektets senare faser.
• Samt att man i workshop med utvecklingsteamen verkligen kan fokusera på det viktiga, att hitta hoten. En whiteboard med många frågor och diskussioner är den viktigaste inputen till din modell.

En kulturfråga, inte bara för experter

Det bästa med att flytta hotmodelleringen närmare koden är att säkerhet slutar vara en diffus magkänsla eller ett externt granskningsmoment. Det blir en laginsats. När utvecklare, produktägare och arkitekter sätter sig runt samma levande modell förändras hur hela teamet ser på sin egen produkt. I slutändan handlar hotmodellering om att ge sig själv arbetsro. Att veta att vi har gjort vårt bästa för att förutse stormen, innan det ens har börjat blåsa.