En användbar hotmodell förklarar vad du skyddar, vem eller vad som kan påverka det, var förtroendet förändras och hur du kommer att minska och testa de viktigaste riskerna. Börja med det faktiska projektet i stället för en generisk lista över verktyg.
Definiera en omfattning som är tillräckligt liten för att kunna resonera om
Börja med en fungerande tjänst: en kundportal, en publiceringswebbplats eller en intern applikation. Skriv ned de komponenter du driver och de externa system du är beroende av. En hotmodell bör synliggöra antaganden, inte antyda att varje möjligt angrepp har lösts. Håll den första versionen tillräckligt liten för att de som driftsätter applikationen ska kunna förklara den utan en separat konsult som tolkar diagrammet.
Lista de värdefulla resultaten och tillgångarna. Dessa kan omfatta kunddata, administrationsåtkomst, betalningsstatus, publicerat innehåll och förmågan att återställa tjänsten. Tillgänglighet kan vara en tillgång även när informationen är offentlig. Bestäm vilka fel som skulle vara besvärande och vilka som skulle skada människor eller organisationen. Den distinktionen hjälper dig att prioritera kontroller i stället för att behandla varje varning lika.
Rita upp platserna där förtroendet förändras
OWASP:s vägledning för hotmodellering använder dataflöden och förtroendegränser för att göra en design begriplig. För en liten hostad applikation, rita upp webbläsaren, webbprocessen, databasen, administratören, destinationen för säkerhetskopior och externa integrationer. Markera informationen som rör sig mellan dem. En begäran som korsar från en icke betrodd klient till en privilegierad serveråtgärd förtjänar explicit validering och auktorisering.
Anta inte att det faktum att man befinner sig på samma maskin gör varje komponent lika betrodd. En offentlig uppladdningsprocess bör inte ha samma behörigheter som databasadministration. Ett säkerhetskopieringsjobb kan behöva läsåtkomst utan förmågan att ändra live-applikationsposter. Att separera dessa roller gör effekten av en komprometterad komponent lättare att begränsa och de nödvändiga behörigheterna lättare att granska.
Välj konkreta felscenarier
Använd en handfull troliga händelser för att utmana designen. En angripare stjäl ett administratörslösenord; en användare begär en annan användares post; en uppladdning fyller disken; en driftsättning exponerar en konfigurationsfil; en återställningskopia kan inte återställas. Beskriv utgångsläget, den påverkade komponenten och konsekvensen. Ett specifikt scenario är lättare att testa än en bred instruktion om att förbättra säkerheten.
Inkludera misstag och missbruk av legitima arbetsflöden såväl som extern intrusion. En nytt försök kan skapa två värdefulla operationer, eller två begäranden kan tävla om att ändra samma objekt. OWASP:s vägledning för affärslogik belyser dessa processantaganden. Kontrollera vem som får flytta ett arbetsflöde till nästa tillstånd och om upprepning eller omordning av en begäran ändrar resultatet oväntat.
| Scenario | Kontroll att undersöka | Bevis att samla in |
|---|---|---|
| Stulen administrationsuppgift | Begränsad åtkomst och en andra faktor där det stöds | En obehörig inloggning kan inte slutföras |
| En annan användares objekt begärs | Server-side-objektauktorisering | Ett isolerat test returnerar ett nekat resultat |
| Disken töms av uppladdningar | Kontroller för storlek, kvot och lagringstid | En gräns tillämpas innan tjänstefel uppstår |
| Dubblerad arbetsflödesbegäran | Idempotens och transaktionsgränser | En upprepad begäran skapar ett utfall |
Prioritera efter påverkan och en trovärdig väg
För varje scenario, dokumentera dess potentiella påverkan och de villkor som krävs för att det ska inträffa. Undvik att låtsas att en gissad numerisk poäng är en exakt sannolikhet. Du kan fortfarande skilja ett internetexponerat svagt lösenord från en mycket villkorad lokal händelse. Tilldela en ägare och ett praktiskt nästa steg till de viktiga riskerna så att modellen skapar arbete som någon faktiskt kan slutföra.
Överväg informationslivscykeln såväl som applikationskompromettering. En diagnostikexport kan avslöja onödiga data under i övrigt normal drift. Ett kvarhållet kontofält kan skapa exponering långt efter att dess syfte upphört. Integritetsgranskning kan därför ta bort information eller förkorta lagringstiden, medan säkerhetsgranskning begränsar åtkomsten till det som återstår. Båda ändringarna hör hemma i modellen när de skyddar projektet.
Testa kontrollerna i en auktoriserad miljö
Skapa en staging-miljö med representativa behörigheter och påhittade poster. Testa nekad åtkomst, begärandebegränsningar, arbetsflödesomförsök och återställning. Använd inte riktiga kunddata när syntetiska data kan demonstrera beteendet. Målet är att verifiera kontrollen, inte att generera imponerande angripstrafik. Håll dig inom system som du äger eller uttryckligen har behörighet att bedöma.
Dokumentera vad som godkändes, vad som misslyckades och vad som fortfarande är okänt. Ett skannerresultat kan bidra med bevis men ersätter inte ett test av applikationens affärsregler. På samma sätt verifierar ett nätverksskyddsalternativ inte objektauktorisering eller hantering av hemliga filer. Koppla de användbara resultaten till scenariot så att framtida underhållare förstår varför en viss kontroll finns.
Håll modellen kopplad till förändring
Granska de relevanta delarna när du lägger till en integration, exponerar en ny slutpunkt, ändrar en behörighet eller flyttar data till en annan destination. Du behöver inte rita om hela arkitekturen för en mindre textändring. Utlösaren är ett ändrat antagande om åtkomst, information eller systembeteende. Håll modellen bredvid dokumentationen för driftsättning och återställning i stället för att lämna den som en engångsutdata från en workshop.
SwissOctet tillhandahåller en katalog över infrastrukturval, inte en färdig hotmodell för applikationen. Välj den konfiguration och de alternativ som stödjer dina kontroller och verifiera sedan den driftsättning du bygger. En liten, underhållen modell med testade åtgärder är mer användbar än en stor samling säkerhetsprodukter utan tydlig förklaring av vilka risker de hanterar.
Din praktiska checklista.
- Lista tillgångar och konsekvenser av fel.
- Rita dataflöden och förtroendegränser.
- Välj specifika scenarier för intrusion, misstag och arbetsflöden.
- Tilldela kontroller och ägare till de viktiga riskerna.
- Testa med syntetiska data i en auktoriserad miljö.
- Granska modellen när ett relevant antagande ändras.
Detaljerna som spelar roll.
Behöver jag ett formellt ramverk för att börja?+
Nej. Ett litet diagram och en dokumenterad uppsättning scenarier kan vara användbara. Ett ramverk hjälper till att säkerställa att du granskar risker konsekvent.
Ersätter en sårbarhetsskanner hotmodellering?+
Nej. Skannrar kan hitta tekniska svagheter, medan en hotmodell även undersöker designantaganden, behörigheter och affärsarbetsflöden.
Hur ofta bör jag uppdatera modellen?+
Uppdatera de påverkade delarna när dataflöden, integrationer, behörigheter eller exponerad funktionalitet ändras, och granska olösta risker regelbundet.
Gå till källan.
Dessa referenser stöder de tekniska begreppen i denna guide. Följ aktuell dokumentation innan du ändrar ett produktionssystem.
- OWASP: Threat Modeling Cheat Sheet cheatsheetseries.owasp.org
- OWASP: Hotmodellering i praktiken devguide.owasp.org
- OWASP: Business Logic Security cheatsheetseries.owasp.org
Redaktionell vägledning av SwissOctet. Exemplen är illustrativa. Tjänstespecifikationer, tillgängliga alternativ och avtalsvillkor måste verifieras separat.