Design It Security-First, Not After It Breaks

Threat modeling is structured thinking about what can go wrong before it goes wrong: you enumerate the assets, the actors, and the ways attackers reach them, then design controls into the system rather than bolting them on after the pentest. It is cheap insurance — an hour at design time versus an incident at 2am — and it is how a team decides what to build instead of risking everything on the review bed.

The STRIDE Framework

Microsoft's STRIDE is the teaching mnemonic — six threat categories, each with the security property it attacks and the defense it pairs with: - Spoofing — pretending to be someone else (attacks authenticity). Defense: authentication, strong identity. - Tampering — modifying data or code in transit or at rest (integrity). Defense: hashing, signatures, integrity monitoring. - Repudiation — denying you did something (non-repudiation). Defense: tamper-evident, auditable logs. - Information Disclosure — reading data you should not (confidentiality). Defense: encryption at rest/in transit, least privilege. - Denial of Service — making it unavailable (availability). Defense: capacity, rate limits, resilience. - Elevation of Privilege — gaining more rights than granted (authorization). Defense: strict authorization, privilege isolation, the IDOR lesson.

Drawing a Data Flow

The tool that makes STRIDE concrete is the Data Flow Diagram: boxes for processes, external actors, and data stores, arrows for how data moves between them, and an explicit trust boundary separating "data I control" from "data that arrived from an untrusted source" (the browser, an API partner, a user upload, a webhook). Every arrow crossing a trust boundary is a threat candidate: anything that feeds attacker-controlled data across the line and into a sink (query, command, path, HTML — every injection lesson) needs a control at that crossing. Most frameworks and reviewers let you draw the diagram crudely — the value is calling the boundaries explicit, not the aesthetics.

Threat Trees and Attack Scenarios

Go one level deeper with attack trees: root = "attacker reads a customer's data", children = the ways that root could happen ("steal session cookie", "exploit IDOR", "impersonate the login page", "exfiltrate via SSRF"), and each child branches into its own sub-paths. Then for each high-value leaf you pick a control in the defense-in-depth stack. The point is prioritization: an attack tree maps to a risk discussion in a way a checklist never can, and it lets you spend control budget on the mostly-likely and most-damaging perimeters rather than on everything equally.

Bake It Into the Cadence

Threat modeling is a habit, not an annual artifact. Model at the start of each design/project, re-model when the architecture meaningfully changes (new service, new data), and reuse the diagrams in the pentest scoping (the pen-testing lesson) so testers hit the trust boundaries you named. Update the model after every real incident — a discovered flaw is a missing child in your old tree. Teams that ship threat models are not more paranoid; they are earlier: the control costs pennies at the whiteboard and fortunes in the review flood.