🔄 Module 4 · Foundations
The Threat Modeling Process
Now that you know what to look for, here's how to do it — a repeatable five-step process for conducting threat models on any system, from a simple login page to a cloud-native microservices platform.
🎯 Learning Objectives
- Execute the five-step threat modeling process end to end
- Create a basic Data Flow Diagram (DFD) with correct elements and trust boundaries
- Systematically enumerate threats using STRIDE per element
- Score and prioritize threats using likelihood × impact
- Produce actionable mitigation decisions for each threat
1The 5-Step Process Overview
Threat Modeling Process — End to End
A linear process, but in practice you often cycle back — especially between steps 2 and 3 as new threats reveal gaps in your model
2Step 1 — Define Scope & Identify Assets
Before drawing a single box, answer: What are we modeling? Scope creep kills threat models. Be explicit about what's in and out of scope.
Common Scoping Mistake
Trying to threat model "the whole company" in one session. Instead, pick a specific feature, service, or integration — something bounded. "The password reset flow" is a perfect scope. "The entire e-commerce platform" is not.
Scoping Questions to Answer
- ✓What feature or system are we modeling?
- ✓What data does it handle? (PII, financial, health, secrets?)
- ✓Who are the legitimate users? (employees, customers, admins?)
- ✓What are the external dependencies? (3rd-party APIs, cloud services?)
- ✓What are the crown jewels? (most valuable assets to protect)
- ✓What is explicitly OUT of scope?
3Step 2 — Draw the Architecture (DFD)
A Data Flow Diagram (DFD) is the visual backbone of your threat model. It shows how data moves through your system — who sends it, what processes it, where it's stored, and where trust boundaries exist.
DFD Elements
DFD Notation Reference
The four standard DFD notation elements — learn these and you can draw any system's threat model diagram
DFD Drawing Rules
- Data must flow somewhere — every flow arrow has a source and destination
- Label every flow — what data moves? (credentials, user records, API responses)
- Every trust boundary must be visible — draw dashed lines where trust levels change
- Processes have numbers — makes them easy to reference in threat tables
- Keep it honest — draw how the system actually works, not how you wish it worked
Example DFD — Password Reset Flow
Password reset flow DFD — numbered processes, labeled flows, and explicit trust boundaries. This is the foundation for threat identification.
4Step 3 — Identify Threats (STRIDE per Element)
With the DFD drawn, go through each element systematically and apply STRIDE. The output is a threat table — the core deliverable of a threat model.
| # | Component | STRIDE | Threat Description | Priority |
|---|---|---|---|---|
| T-01 | Process 1: Reset Handler | Spoofing | Attacker submits another user's email and receives a reset link | High |
| T-02 | Flow ⑥: Email delivery | Info Disc. | Reset link sent to compromised/wrong email exposes token | Medium |
| T-03 | Data Store: Token Store | Tampering | Attacker guesses or brute-forces the reset token (if too short) | High |
| T-04 | Process 1: Reset Handler | Denial of Svc | Flood of reset requests for a single account locks out the user | Medium |
| T-05 | Flow ⑦: Token + New PW | Tampering | MITM intercepts the reset form submission and changes the new password | Low |
| T-06 | Process 3: Password Updater | Elevation | Token replay: used token is not invalidated, can reset password again | High |
Threat ID Convention
Give every threat a unique ID (T-01, T-02…). This lets you reference threats in code comments, Jira tickets, and design docs without ambiguity. Over time, your threat log becomes a powerful security knowledge base.
5Step 4 — Score and Prioritize Risks
Not all threats are equal. You can't fix everything at once, so you need a way to decide what to fix first. The simplest approach: score each threat on Likelihood and Impact.
Scoring Criteria
📈 Likelihood Factors
- How easy is it to exploit? (skill required)
- Is there existing tooling (exploit kits)?
- How exposed is the attack surface?
- Has this been exploited in similar systems before?
💥 Impact Factors
- How much data would be exposed or corrupted?
- What's the financial/legal consequence?
- How many users are affected?
- Is the damage reversible?
| Threat ID | Likelihood | Impact | Risk Score | Priority Action |
|---|---|---|---|---|
| T-01 | High | High | Critical | Fix before launch |
| T-03 | High | High | Critical | Fix before launch |
| T-06 | High | High | Critical | Fix before launch |
| T-02 | Medium | High | High | Next sprint |
| T-04 | Medium | Medium | Medium | Next sprint |
| T-05 | Low | Low | Low | Document & monitor |
6Step 5 — Mitigate & Validate
For each threat (starting with Critical), decide on a mitigation strategy. There are four valid responses — you don't always have to fix:
Mitigate
Implement a control that reduces likelihood or impact. Most threats should be mitigated.
Transfer
Move the risk to another party (insurance, contract, or a specialized vendor). E.g. use a PCI-certified payment processor.
Eliminate
Remove the risky feature entirely if it's not worth the security cost. The safest code is code you don't ship.
Accept
Consciously choose to accept a low-risk threat. Document the decision and the reasoning — never accept implicitly.
Mitigation Table — Password Reset Example
| Threat ID | Mitigation Strategy | Specific Control | Owner |
|---|---|---|---|
| T-01 | Mitigate | Rate-limit reset requests per email; send reset only if email exists (don't confirm which emails are registered) | Backend team |
| T-03 | Mitigate | Generate 256-bit cryptographically random tokens. Expire after 15 minutes. Single use only. | Backend team |
| T-06 | Mitigate | Invalidate token immediately after use. Delete all outstanding reset tokens on password change. | Backend team |
| T-02 | Accept | If email provider is compromised, we can't prevent token interception. Document as accepted risk; monitor for unusual resets. | Security team |
| T-04 | Mitigate | Max 3 reset requests per email per hour. Return same success message regardless of whether email exists. | Backend team |
| T-05 | Transfer | Enforced HTTPS/TLS already mitigates MITM. Responsibility on network layer (TLS termination at load balancer). | Infra team |
Validation: Closing the Loop
After mitigations are implemented, validate them: Do they actually address the threat? Did implementing one control create a new vulnerability? Schedule a review — and update your threat model document so the next team inherits your knowledge.
7Module Summary
The 5-Step Process
- Scope — define what you're modeling, identify crown jewels
- Model — draw DFD with elements (external entities, processes, data stores, flows) and trust boundaries
- Identify — apply STRIDE per element; build a numbered threat table
- Score — Likelihood × Impact → prioritized list (Critical, High, Medium, Low)
- Mitigate — for each threat: Mitigate, Transfer, Eliminate, or Accept (with documentation)