Threat Modeling: STRIDE
Threat modeling is the habit of looking at a design before it is attacked and asking, structurally, what could go wrong. It is the cheapest security you will ever do: a threat caught on a whiteboard costs a conversation, while the same threat caught in production costs an incident. STRIDE is the checklist that makes the exercise repeatable — six categories of threat walked against each part of a system.
Done against Meridian, STRIDE turns the vague question "is app.meridian.example secure?" into a concrete list of specific threats, each with an owner and a decision. That list is the backlog the rest of this book systematically closes.
Draw the System First
You cannot model what you cannot see, so threat modeling starts with a simple data-flow diagram: the browser, app.meridian.example, api.meridian.example, the database, and the trust boundaries between them — the lines where data crosses from one level of trust to another. Threats concentrate at those boundaries, because that is where untrusted input meets trusted code. A diagram that omits the admin backdoor or the third-party integration will produce a model that misses exactly the threats that matter.
STRIDE, Category by Category
Each letter is a lens you point at every element and every data flow. Spoofing — can someone pretend to be another user or service? Tampering — can data be altered in transit or at rest? Repudiation — can someone deny an action with no record to prove otherwise? Information disclosure — can data leak to someone who should not see it? Denial of service — can the system be knocked offline? Elevation of privilege — can someone gain rights they were never granted?
Walking those six against Meridian's login and search surfaces the real work: spoofing points at authentication and MFA (Chapter 3), tampering and disclosure at encryption and TLS (Chapter 2), and elevation of privilege at the authorization checks whose absence causes the web flaws of Chapter 6. STRIDE is, in effect, a table of contents for the controls this book builds.
From Threats to Decisions
A threat list that just lists threats is half-finished. Every entry gets one of four dispositions: mitigate (add a control), accept (document the risk and move on), transfer (insure or outsource it), or eliminate (remove the risky feature entirely). Some threats are correctly accepted — the value of the exercise is the explicit, owned decision, not driving residual risk to zero.
Keep It Lightweight Enough to Happen
The best threat model is the one that actually gets done. A one-hour STRIDE session at design time, repeated whenever the architecture changes, beats a formal model that is too heavy to ever run. Meridian re-models when it adds an API or an integration, because the design that was safe last quarter grew new trust boundaries since.
STRIDE — a fast, category-driven checklist, ideal for design reviews and the default you should start with.
Attack trees — model the many paths to one specific goal in depth; reach for them when a single high-value threat needs thorough analysis.
PASTA — a heavier, risk-centric, seven-stage process for whole programs; worth it when a formal, business-aligned methodology is required.
- Modeling once and never again, so the model describes an architecture that has since grown a new API, a new integration, and new trust boundaries.
- Listing threats without deciding what to do about each — an un-triaged list is a to-do nobody owns.
- Modeling the diagram instead of the system: if the drawing omits the admin console or the third-party integration, the model misses exactly where real threats live.
- Treating every threat as must-fix, when some are correctly accepted — the goal is an explicit decision per threat, not zero residual risk.
- Making the process so heavy it never runs, so the design ships with no model at all.
- Threat-model at design time and re-model whenever the architecture changes, not after an incident.
- Anchor the model to a data-flow diagram with explicit trust boundaries, because threats cluster where data crosses a boundary.
- Give every identified threat an explicit disposition — mitigate, accept, transfer, or eliminate — with a named owner.
- Start with STRIDE and reach for attack trees or PASTA only when a specific threat or a formal program demands the extra depth.
- Keep sessions short enough that they actually happen every design cycle.
Knowledge Check
Why do trust boundaries get special attention in a threat model?
- Threats concentrate where data crosses a level of trust
- They are the only place encryption can be applied
- Data-flow diagrams cannot be drawn without them
- They are the only elements STRIDE can be applied to
In STRIDE, which threat category does a missing authorization check on an endpoint fall under?
- Elevation of privilege
- Repudiation, denying an action was ever taken
- Denial of service against the endpoint
- Spoofing another user's identity
A threat model lists 40 threats but records no decision for any of them. What is the core problem?
- An un-triaged threat list is a to-do nobody owns
- Forty threats is too many for any real system to have
- Threat models should only ever record threats, never decisions
- The team used STRIDE instead of a heavier methodology
You got correct