Threat Modeling Basics
Threat modeling is the structured process of identifying what could go wrong in a system before it's built or shipped, so that security controls can be designed in rather than bolted on afterward. It answers four questions popularized by Adam Shostack: what are we building, what can go wrong, what are we going to do about it, and did we do a good enough job? Unlike a penetration test, which probes a finished system for exploitable flaws, threat modeling happens earliest in the design phase, working from architecture diagrams and data flows rather than running code, which makes fixing an identified issue dramatically cheaper — redesigning a component on a whiteboard costs far less than patching and redeploying it after a breach.
Cricket analogy: A team's coaching staff studies an opponent's batting lineup before the toss to plan bowling changes in advance, rather than reacting only after runs are already conceded — that's threat modeling versus reacting to an in-progress collapse.
The STRIDE Framework
STRIDE, developed at Microsoft, gives threat modelers a memorable checklist of threat categories to walk through for each component in a system: Spoofing (impersonating another user or system), Tampering (unauthorized modification of data), Repudiation (denying an action without proof it happened), Information Disclosure (exposing data to unauthorized parties), Denial of Service (degrading availability), and Elevation of Privilege (gaining capabilities beyond what was granted). Applying STRIDE to a login endpoint, for instance, surfaces concrete questions: can an attacker spoof another user's session token, can login attempt logs be tampered with, can a user deny having reset their own password without an audit trail, and can a normal user's session somehow be elevated to an admin role through a parameter tampering bug.
Cricket analogy: Spoofing is like an impostor walking into the dressing room wearing a team blazer and claiming to be a substitute fielder nobody actually called up.
Running a Threat Modeling Session
A practical threat modeling session starts by drawing a data flow diagram (DFD) that shows processes, data stores, external entities, and trust boundaries — the points where data crosses from a less trusted zone (like the public internet) into a more trusted one (like an internal API). For each element crossing a trust boundary, the team walks through the relevant STRIDE categories and records findings in a lightweight table: threat description, affected component, risk rating, and mitigation. Risk is typically rated using a simple scheme like likelihood times impact, or a more formal model like DREAD, so the team can prioritize fixing a high-likelihood, high-impact authentication bypass before spending time on a low-impact, hard-to-exploit edge case.
Cricket analogy: A DFD's trust boundary is like the boundary rope itself — the ground team tracks exactly which zone a ball crosses into, since a shot into the stands is scored differently than one still inside the field.
Threat Model Table — Login Endpoint
| Threat (STRIDE) | Component | Likelihood | Impact | Mitigation |
|--------------------------|-------------------|------------|--------|--------------------------------------|
| Spoofing session token | Auth service | Medium | High | Signed, short-lived JWTs + HTTPS |
| Tampering login logs | Audit log store | Low | High | Append-only log, write-once storage |
| Repudiation of password reset | Reset flow | Medium | Medium | Log with timestamp + IP + email sent |
| Info disclosure via error msg | Login API | High | Medium | Generic 'invalid credentials' message|
| DoS via login brute force| Auth service | High | Medium | Rate limiting + account lockout |
| Elevation via role param | Session creation | Low | High | Server-derived role, never client-set|Threat modeling doesn't need heavy tooling to start. A whiteboard, a data flow diagram, and thirty focused minutes with the STRIDE checklist for a new feature's design review catches far more issues per hour spent than most other security activities.
A common mistake is treating threat modeling as a one-time exercise done before launch. Architectures evolve — a new third-party integration, a new microservice, or a new data flow can introduce fresh trust boundaries that need re-modeling, so it should be revisited whenever the design changes meaningfully.
- Threat modeling identifies risks during design, before code is written, making fixes far cheaper than post-breach patching.
- It answers four questions: what are we building, what can go wrong, what will we do about it, and did we do enough.
- STRIDE covers six threat categories: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege.
- Data flow diagrams map processes, data stores, and trust boundaries where less-trusted data enters a more-trusted zone.
- Findings are typically ranked by likelihood times impact, or a formal model like DREAD, to prioritize fixes.
- A lightweight whiteboard session with STRIDE can catch significant issues in thirty focused minutes.
- Threat models must be revisited whenever the architecture changes, not treated as a one-time pre-launch task.
Practice what you learned
1. How does threat modeling primarily differ from penetration testing?
2. In the STRIDE framework, what does the 'R' stand for?
3. What is a 'trust boundary' in a data flow diagram?
4. In the lesson's login endpoint threat table, what mitigation addresses the 'Information disclosure via error message' threat?
5. Why should a threat model be revisited after the initial design review?
Was this page helpful?
You May Also Like
What Is Web Application Security?
An introduction to why web applications are attacked, what an attack surface is, and the core disciplines that keep applications and their data safe.
The CIA Triad in Web Apps
How confidentiality, integrity, and availability apply concretely to web application design, and what breaks when each one fails.
The OWASP Top 10 Overview
A tour of the OWASP Top 10, the industry-standard list of the most critical web application security risks and why it matters to every developer.
Secure SDLC Overview
How security practices integrate into every phase of the software development lifecycle, from requirements gathering through deployment and maintenance.