Security Champions · Module 4a
Security Champions Program
Threat Modeling
A structured approach to predicting what can go wrong — and deciding what to do about it — before it happens.
Part 1 of 2 · Concepts & Methods
01 / 40
Your journey · Program map
Your journey so far
9 modules. One toolkit. You are at Module 4.
Context
Your toolkit · So far
What you already have
Modules 1–3
M1–2
Champion role + sprint workflow + business language
You can frame risk, write requirements, and work within the dev process
M3
OWASP Top 10 through five lenses
Architecture, third-party code, unpredictable conditions — you know where risks live
M2
STRIDE and trust boundaries: the foundation
The vocabulary for systematic threat identification
Context
Module 4 · From recognition to hunting
From recognition to hunting
You know what risks look like. But how do you find them in YOUR product, systematically?
This is the module that turns you from someone who recognizes risks into someone who hunts them. Threat modeling is the Champion's primary production skill.
By the end, you'll have a complete workflow:
1
Diagram your system
Data flow diagrams that expose trust boundaries
2
Walk it with STRIDE
Six threat categories applied to every component
3
Score with DREAD → file tickets
Prioritized backlog items with acceptance criteria — not a report, not a presentation
Context
Act 1 · Terminology
Not just prevention
Your role as a Champion: threat modeling is your primary production skill. The output is prioritized backlog tickets — not a report, not a presentation, not a conversation. You don't model the whole system alone — you ensure it gets modeled.
A common first answer to "why threat modeling?" is: to prevent issues. That's partially right — but only partially. You cannot prevent everything. Not a hurricane, not a zero-day, not a state-level attacker.
Threat modeling is the art of predicting possible incidents and figuring out how to stop them. "Stop" means three things: prevent where possible, detect what you couldn't prevent, and respond quickly to mitigate what got through.
Prevention implies control you don't have. A mature security posture assumes some threats will get through and builds detection and response into the architecture from the start.
05 / 40 · Terminology
Act 1 · Terminology
Action, not thing
Consider a car crossing the street — a car with bad brakes. The threat actor is the car (or the driver). The threat action is the hit. The damage is injury. But here's the key: if that car is parked, standing still, it is not a threat.
A threat is an action or process that could cause harm to business objectives. Not a thing. Not a state. An action. A server on the internet is not a threat. The actions someone can perform against it — those are threats.
An open S3 bucket is a vulnerability — an attribute of the system. The threat is data exfiltration by an attacker. The risk is: probability of discovery × impact of leaked data. If the bucket holds public marketing assets, risk is low. If it holds PII — the same vulnerability, radically different risk.
Champion's takeaway
When reviewing your backlog, ask "what can someone do?" — not "what exists." A server isn't a threat. The unauthorized access to it is.
06 / 40 · Terminology
Act 1 · Terminology
Different words, different things
Teams use "threat" and "risk" interchangeably, and it leads to bad prioritization.
Threat — an action or process that could cause harm
Vulnerability — an attribute that permits the threat to succeed
Risk — probability × impact, the business-level measurement
Damage — the result of a realized threat
Vulnerability — an attribute that permits the threat to succeed
Risk — probability × impact, the business-level measurement
Damage — the result of a realized threat
Risk is a measurement of the threat. The threat is the action; the risk is the number.
A team reports a "critical vulnerability" — an unpatched library with a CVSS 9.8. But the library is used in an internal admin panel accessible only via VPN. The threat is remote code execution. The vulnerability is the unpatched library. The risk — given the VPN-only access — is medium, not critical. Without separating these terms, the team spends a sprint on a medium-risk fix while a high-risk auth bypass in the public API stays in the backlog.
Champion's takeaway
Next time someone says "risk" in a meeting, ask: do you mean the threat, the vulnerability, or the actual business impact? Clarifying this one distinction prevents hours of circular discussion.
07 / 40 · Terminology
Knowledge check · terminology
Knowledge check
Test your instinct
A database server is publicly accessible on port 5432 with default credentials. What is the threat?
C. The server is an asset. The default credentials are a vulnerability. The data is what's at stake. The threat is the action — an attacker connecting and extracting data.
08 / 40 · Quiz
Act 1 · Real-world case
Two actions, one disaster
The 2011 Fukushima disaster is a textbook case of threat modeling failure. The tsunami hit the station — but "a big wave" isn't the threat action. The actual threat actions were more specific:
1. Water flooded the basement — stopping the diesel backup generators
2. Reserve power lines were disrupted
2. Reserve power lines were disrupted
One threat actor. Two threat actions. In combination, they caused the reactor meltdown. The vulnerability? A design decision. Diesel generators were placed in the basement of a coastal station, below the waterline.
A single threat actor (tsunami) can produce multiple threat actions. If you only model "tsunami → damage" you miss the actual failure chain. Decomposing into specific actions reveals the real vulnerability: generator placement.
09 / 40 · Case
Time to think · Design decisions
Fukushima · Failure chain
One threat actor. Two threat actions. The design flaw is in the orange box — the only part that was preventable.
Each STRIDE category targets a specific goal: Spoofing attacks authenticity. Tampering attacks integrity. Repudiation attacks authenticity. Information disclosure attacks confidentiality. Denial of service attacks availability. Elevation of privilege attacks authorization (not in CIAA, but maps to confidentiality + integrity). This mapping gives you a systematic way to check: "for each goal, which STRIDE threats apply here?"
10 / 40
Act 1 · Security goals
The four goals
Every security control protects one or more of these fundamental goals:
Confidentiality — data accessible only to authorized parties
Integrity — data is accurate and unaltered
Authenticity — identity of users and systems is verified
Availability — systems and data accessible when needed
Integrity — data is accurate and unaltered
Authenticity — identity of users and systems is verified
Availability — systems and data accessible when needed
These four goals become concrete in Act 4: each STRIDE category maps to a specific goal it violates. Spoofing violates authenticity. Tampering violates integrity. And so on.
11 / 40 · Terminology
Act 2
Act 2
What are you protecting?
Before modeling threats, identify what's valuable — and why.
12 / 40
Act 2 · Assets
Value comes in three flavors
An asset is anything that has value to the business. But "value" has three distinct meanings.
Type 1
Procurement value
Your product worked for five years and built a client database. Losing it means losing that investment.
Type 2
Cash flow generation
That database right now generates revenue. If its integrity is disrupted, the revenue stops.
Type 3
Negative consequences
A Confluence page with team salaries doesn't generate revenue. But leaking it under GDPR generates fines.
13 / 40 · Assets
Knowledge check · asset value
Knowledge check
A team's internal wiki contains employee home addresses and salary data. It generates no revenue. Why is it an asset?
C. This is a "negative consequences" asset. Its value comes from the damage if compromised — GDPR penalties, lawsuits, reputational harm.
14 / 40 · Quiz
Act 3 · Adversaries
Know your adversaries
The obvious adversaries — hackers, fraud operators — come to mind quickly. But some are less obvious. On one real product, partners were using established trust relationships to access assets they shouldn't have touched.
Common adversary types: competitors (or partners acting as competitors), black-hat hackers, and fraud operators.
Don't forget the non-obvious ones: employees with excessive access, and regular users whose misuse can cause unintentional damage.
External attackers need to find a way in. Partners already have access — through APIs, shared databases, trust-based integrations. When a partner turns adversarial, they bypass most perimeter controls by design.
🎭Competitors
Trust exploitation
💻Black-hats
Technical attacks
💰Fraud ops
Financial motivation
🏢Insiders
Excessive access
15 / 40 · Adversaries
Act 3 · Adversary landscape
Adversary capability ladder
Higher rows = more resources, patience, sophistication. Which rows target your product?
16 / 40 · Adversaries
Act 3 · Adversaries
What defenders control
Not every adversary is an equal threat. A useful evaluation model has three attributes: intent, capability, and opportunity.
Intent — controlled by the adversary. "They want your client list."
Capability — controlled by the adversary. "They have engineers who can exploit APIs."
Opportunity — controlled by you. "Your API returns full user objects with no rate limiting."
Capability — controlled by the adversary. "They have engineers who can exploit APIs."
Opportunity — controlled by you. "Your API returns full user objects with no rate limiting."
As defenders, we primarily control opportunity. We cannot change who wants to attack us or how skilled they are. We can only change how much access our system gives them.
Capability belongs to the adversary — their skills, tools, budget. We can't make attackers less skilled. We can make their skills irrelevant by eliminating the opportunities.
17 / 40 · Adversaries
Act 3 · ICO Venn
Intent · Capability · Opportunity
A threat exists only where all three overlap. Remove opportunity — the only circle you control — and the threat disappears.
18 / 40 · ICO
Knowledge check · ICO model
Knowledge check
In the Intent–Capability–Opportunity model, what do defenders primarily control?
C. You can't change intent or capability. You can change how much access your system provides. Every firewall rule, rate limit, and auth check reduces opportunity.
19 / 40 · Quiz
Time to think · What you control
Before & after controls
The adversary is identical in both. Controls don't weaken the attacker — they remove the opportunity.
20 / 40
Pause · The principle
“
“
The principle, in one line
You cannot choose your adversaries. You can choose how much opportunity your system gives them.
Every security control you implement is an opportunity removed.
21 / 40
Act 3 · The big picture
The five questions
Before diving into specific methods, here's what threat modeling answers:
Assets — what are we trying to protect? How valuable?
Adversaries — who might try to attack, and why?
Vulnerabilities — how might the system be weak?
Threats — what actions might exploit vulnerabilities?
Risk — how important × how likely?
Possible defenses — what controls reduce opportunity?
Adversaries — who might try to attack, and why?
Vulnerabilities — how might the system be weak?
Threats — what actions might exploit vulnerabilities?
Risk — how important × how likely?
Possible defenses — what controls reduce opportunity?
We've covered assets and adversaries. Next: the specific methods that answer the remaining questions — starting with three approaches and seven frameworks.
22 / 40
Act 4
Act 4
How to model threats
Three approaches, seven methods, one daily toolkit.
23 / 40
Act 4 · Methods
Three starting points
Approach 1
Asset-centric
Start from what's valuable. Draw data flows. Business impact analysis.
Speaks the language of business — managers understand money
Can miss threats not targeting high-value assets
Approach 2
Attacker-centric
Start from adversaries. Brainstorm what they could do.
Forces you to think like an attacker
You can't model adversaries you haven't imagined
Approach 3
System-centric
Start from architecture. Map components, find threats per component.
Systematic and thorough
Treats all components equally without business context
Combine all three. Asset-centric for alignment, system-centric for thoroughness, attacker brainstorming for high-value features.
24 / 40 · Methods
Act 4 · Methods mapping
Which method for which approach?
Your daily toolkit is STRIDE + DREAD. The next slides cover five additional frameworks — know they exist, but master the first two. They handle the vast majority of real-world threat modeling.
Asset-centric
PASTA
TRIKE
OCTAVE
Attacker-centric
Brainstorming
OWASP Top 10
Top risks
System-centric
STRIDE
DREAD
VAST
LINDDUN
In 99% of cases, you'll use STRIDE + DREAD — they're standard, well-tooled, and easy to explain to managers. The rest are worth knowing so you can choose when the situation calls for it.
Remember
Master STRIDE + DREAD first — they cover 90% of real-world threat modeling. Learn the others when you hit their specific use case.
25 / 40 · Methods
Act 4 · PASTA
PASTA: seven steps
Process for Attack Simulation & Threat Analysis
PASTA is the most structured method. Seven steps, each building on the previous:
1. Define objectives
2. Define technical scope
3. Decompose the application
4. Analyze threats
5. Vulnerability analysis
6. Attack analysis
7. Risk & impact analysis
2. Define technical scope
3. Decompose the application
4. Analyze threats
5. Vulnerability analysis
6. Attack analysis
7. Risk & impact analysis
The output of each stage provides input for the next. Asset-centric and risk-oriented — speaks business language.
Not analysis — those have taxonomies. The hardest step is decomposition: deciding how deep to go. Without a stopping rule, the model never ships.
26 / 40 · PASTA
Act 4 · OCTAVE
OCTAVE
Operationally Critical Threat, Asset & Vulnerability Evaluation
OCTAVE works in two phases — organizational and technological — then produces a strategy and plan.
Phase 1 · Organizational
Assets, threats, practices
Identify critical assets, the threats to them, and current security practices. Business-facing.
Phase 2 · Technological
Components, vulnerabilities
Map the technical infrastructure, identify vulnerabilities in components that support critical assets.
Output: Risk-based strategy and mitigation plan. More business-oriented than STRIDE — used by risk officers, auditors, and senior management.
When to use
OCTAVE fits organizations assessing enterprise-wide risk — compliance-driven environments, regulated industries. Too heavy for a single feature sprint.
27 / 40 · OCTAVE
Act 4 · Methods
Where to stop
How deep should decomposition go? You could stop at application interfaces. You could go to runtime, container escapes, CPU vulnerabilities. As the saying goes: to create an apple, you first must create the universe.
The answer is organizational. Decomposition stops at the boundary of your team's RACI matrix. If a separate DevOps team handles runtime, runtime is their scope.
The boundary isn't set by your curiosity — it's set by the company's structure.
Practical rule
Decompose to the boundary of your team's RACI. If nobody on your team can fix it, document the dependency and move on.
28 / 40 · Methods
Act 4 · DFD example
Data Flow Diagram · Library System
Tap a flow to highlight it and see what crosses each trust boundary.
Step 1: List your components — services, databases, external APIs, user interfaces. Even 3–5 is enough to start.
Step 2: Draw data flow arrows between them. Ask: what data moves, in which direction?
Step 3: Mark trust boundaries — dashed lines wherever data crosses between different trust levels (user → server, internal → external, app → database).
A whiteboard sketch with 3 components and 2 boundaries beats no DFD at all. You can always add detail later.
Step 2: Draw data flow arrows between them. Ask: what data moves, in which direction?
Step 3: Mark trust boundaries — dashed lines wherever data crosses between different trust levels (user → server, internal → external, app → database).
A whiteboard sketch with 3 components and 2 boundaries beats no DFD at all. You can always add detail later.
29 / 40 · DFD
Act 4 · STRIDE
The daily toolkit
Six categories, most threats
STRIDE is what you use day-to-day. Run it on each component of your DFD. Each category maps to a security property it violates.
S
Spoofing
Impersonate a user or service?
violates: Authentication
T
Tampering
Modify data in transit or at rest?
violates: Integrity
R
Repudiation
Deny actions with no record?
violates: Non-repudiation
I
Info disclosure
Data leak to wrong systems?
violates: Confidentiality
D
Denial of service
Make system unavailable?
violates: Availability
E
Elevation
Low-privilege reach admin?
violates: Authorization
30 / 40 · STRIDE
Act 4 · From list to plan
The connection
STRIDE finds the threats.
DREAD tells you which to fix first.
DREAD tells you which to fix first.
STRIDE gives you a list of potential threats for each component. But your sprint has limited capacity. DREAD gives each threat a defensible score — so you fix the highest-scoring ones first.
📋
STRIDE
finds threats
→
📊
DREAD
scores them
→
🎯
BACKLOG
prioritized tickets
31 / 40
Act 4 · DREAD
Making priorities defensible
DREAD scores each threat on five attributes, 1–5. Average them for a priority score.
Damage — how bad would the impact be?
Reproducibility — how easy to repeat?
Exploitability — how easy to exploit?
Affected users — how many impacted?
Discoverability — how easy to find?
Reproducibility — how easy to repeat?
Exploitability — how easy to exploit?
Affected users — how many impacted?
Discoverability — how easy to find?
DREAD gives you a defensible answer when asked "why this, why now?" — "Scores 4.2: easy to reproduce, affects all users, no auth needed" beats "because it's important."
DREAD correlates with CVSS (the vulnerability scoring standard). If you know one, the other feels familiar.
32 / 40 · DREAD
Act 4 · TRIKE
TRIKE
Requirement-based threat modeling
TRIKE starts from requirements, not architecture. It maps CRUD operations (Create, Read, Update, Delete) per asset, then builds a DFD, and assigns risk values.
1. Define system via requirement model
2. Risk assessment using CRUD matrix
3. Build Data Flow Diagram
4. Assign risk values
2. Risk assessment using CRUD matrix
3. Build Data Flow Diagram
4. Assign risk values
Less common than STRIDE but more structured for requirement-heavy environments where you need traceability from business requirement to risk score.
When to use
TRIKE works when you have well-defined data assets and clear CRUD operations. Strong for data-centric applications; less practical for event-driven architectures.
33 / 40 · TRIKE
Act 4 · VAST
VAST
Visual, Agile, and Simple Threat modeling
VAST is built for Agile/DevOps environments. Three pillars:
Pillar 1
Automation
Eliminates repetition in threat modeling. Ongoing, not one-time. Scales to the entire enterprise.
Pillar 2
Integration
Integrates with tools throughout the SDLC. Supports Agile DevOps workflows natively.
Pillar 3
Collaboration
Brings together app developers, system architects, security team, and senior executives.
When to use
VAST is purpose-built for Agile/DevOps at scale. If your org has 50+ developers and continuous delivery, VAST's automation focus pays off.
34 / 40 · VAST
Act 4 · LINDDUN
LINDDUN
Privacy threat modeling
LINDDUN is the privacy-focused counterpart to STRIDE. Seven categories of privacy threats:
Linkability — can actions be linked to an individual?
Identifiability — can a person be identified?
Non-repudiation — can a person deny involvement?
Detectability — can the existence of data be detected?
Disclosure of information — is personal data exposed?
Unawareness — are users unaware of data processing?
Non-compliance — does processing violate regulations?
Identifiability — can a person be identified?
Non-repudiation — can a person deny involvement?
Detectability — can the existence of data be detected?
Disclosure of information — is personal data exposed?
Unawareness — are users unaware of data processing?
Non-compliance — does processing violate regulations?
Use LINDDUN when your product handles personal data under GDPR or similar regulations. It catches privacy risks that STRIDE misses.
When to use
Reach for LINDDUN when your product handles PII, health data, or behavioral analytics. STRIDE finds security threats; LINDDUN finds privacy threats.
35 / 40 · LINDDUN
Knowledge check · STRIDE
Knowledge check
A user modifies the price field in a POST request before it reaches the server. Which STRIDE category?
B — Tampering. Data modified in transit. Spoofing = impersonating a user. Elevation = gaining admin rights. This is straightforward data modification — integrity violation.
36 / 40 · Quiz
Time to think · The full picture
Threat modeling workflow
Seven steps, top to bottom. The output is a prioritized backlog — security stories your team can actually ship.
37 / 40
Closing
What you covered
01
Threat = action, not thing. A parked car isn't a threat. The hit is.
02
Three asset values. Procurement cost, cash flow, penalties.
03
ICO model. You control opportunity, not intent or capability.
04
Seven methods. PASTA, OCTAVE, STRIDE, DREAD, TRIKE, VAST, LINDDUN.
05
STRIDE → DREAD → Backlog. Find threats, score them, ship tickets.
38 / 40
Complete
Part 1 complete
Your results
—
Quizzes correct
—
XP earned
—
Rank
—
Best streak
—
Reflections
—
Wager style
39 / 40
Next
Part 2
See it in action
You now have the toolkit. In Part 2, you'll watch the entire threat modeling process applied to a real payment API — from asset identification to backlog tickets.
40 / 40
Reflection
Retake
Reset all progress?
Your quiz answers, XP, wagers, and reflections will be cleared. You'll start from slide 1.