🌱 Module 1 · Foundations
What is Threat Modeling?
Understanding what threat modeling is, why it matters, when to use it, and where it fits in the security lifecycle — before we touch a single diagram.
🎯 Learning Objectives
- Define threat modeling in plain language, without jargon
- Explain the core question threat modeling answers: "What could go wrong?"
- Describe where threat modeling sits in the development process
- Name at least three reasons why organizations perform threat modeling
- Identify the four key questions of any threat model
1The Simple Definition
Let's start with the most honest definition possible:
Threat Modeling, Defined
Threat modeling is the process of thinking like an attacker — systematically identifying what could go wrong with your system, why it would matter, and what you can do about it — before attackers find it first.
That's it. Everything else in this course — STRIDE, DFDs, risk matrices — are just tools to help you do that thinking more rigorously and more consistently.
The House Analogy
Imagine you're buying a house. Before you move in, you walk around it and ask:
The House Threat Model
The four questions of threat modeling — illustrated with a house analogy
This is exactly what threat modeling does for software systems. Instead of a house, you have an application. Instead of thieves, you have attackers. But the thinking process is identical.
2The Four Key Questions
Adam Shostack — one of the pioneers of threat modeling — boiled the entire discipline down to four questions. Memorize these. Every threat model you ever do is just answering these four questions:
1. What are we building?
Map your system: components, data flows, trust boundaries. You can't protect what you don't understand.
2. What can go wrong?
Enumerate threats systematically. Use frameworks like STRIDE to avoid missing categories.
3. What are we doing about it?
Identify mitigations — security controls, design changes, monitoring, or explicit risk acceptance.
4. Did we do a good enough job?
Review and validate. Is the analysis complete? Are mitigations adequate? Will we revisit this?
Teaching Tip
When teaching live, ask students to apply these four questions to something they already know — their home, their car, their school. Grounding the abstraction in familiar contexts dramatically improves retention before moving to software systems.
3Why Threat Modeling Matters
Here's an uncomfortable fact: most security vulnerabilities are designed in, not coded in. They come from decisions made early in a project — architecture choices, protocol selections, trust assumptions — long before the first line of code is written.
Cost of Fixing Bugs Over Time (NIST Data)
Fixing a design flaw in production costs ~30× more than fixing it during design. This is why we threat model early.
Three Concrete Benefits
1
Find problems early, when they're cheap to fix
Changing an architecture diagram costs nothing. Patching a production authentication bypass costs millions in breach costs, customer compensation, and reputation damage.
2
Build a shared security mental model across the team
Threat modeling forces developers, architects, PMs, and security engineers to sit together and ask hard questions. The conversation itself is valuable, independent of what's written down.
3
Create an audit trail of conscious security decisions
A documented threat model shows regulators, auditors, and customers that security was considered intentionally — not bolted on after the fact.
The "We'll Add Security Later" Fallacy
Security can't be added to a finished system like a paint coat. If authentication wasn't designed into the architecture, adding it later requires re-architecting. The only cheap time to think about security is before you build.
4Where Threat Modeling Fits in Development
Threat modeling lives in the design phase of development. But it shouldn't be a one-time event. A good team revisits their threat model whenever something significant changes.
Threat Modeling in the SDLC
Threat modeling is most valuable in the Design phase but should be revisited throughout the project lifecycle
When Should You Threat Model?
- Before writing a single line of code — the ideal time; maximum impact, minimum cost
- When adding a major new feature — e.g. "we're adding OAuth login"
- When integrating a new third-party service — new trust boundary = new attack surface
- When a new attack type emerges — e.g. prompt injection for AI systems
- After a security incident — to understand what was missed
5Common Misconceptions
Myth: "Threat modeling is only for security experts"
Reality: Threat modeling is most effective when the entire team participates — developers, architects, PMs. Security expertise helps, but the goal is structured critical thinking, which any engineer can learn.
Myth: "We need a perfect, exhaustive threat model"
Reality: An imperfect threat model done and acted on is infinitely better than a perfect one never completed. Start small. The goal is better security decisions, not a comprehensive academic paper.
Myth: "Threat modeling is a one-time activity"
Reality: Systems evolve. Threat landscapes change. New attack techniques emerge. Threat models must be living documents, revisited at every major change — not artifacts filed in a drawer after the first workshop.
Myth: "Threat modeling replaces penetration testing"
Reality: They complement each other. Threat modeling finds design-level issues before building. Penetration testing finds implementation-level issues in what was built. You need both.
6Knowledge Check
✏️ Exercise 1.1
When is the best time to perform threat modeling?
Your team is starting a new product. From a cost and effectiveness perspective, when should you first perform threat modeling?
✏️ Exercise 1.2
What does the threat modeling process answer?
Which of the following best captures all four key questions of threat modeling?
7Module Summary
Key Takeaways
- Threat modeling = structured thinking like an attacker, applied before attackers do
- It answers four questions: build, break, fix, check
- Most valuable in the design phase — cheapest time to make security changes
- It's a team activity, not just a security-team activity
- It's a living document, not a one-time checkbox
Instructor Note — Classroom Activity
Ask each student to think of a system they interact with daily (email, banking app, school portal). Have them spend 3 minutes writing answers to all four threat modeling questions for that system. Share and discuss. This makes the abstract immediately concrete.