Threat Modeling
Threat modeling is a structured approach to identifying, quantifying, and addressing security risks. By thinking like an attacker before attacks occur, you can build more secure systems and prioritize defenses.
When to Threat Model
Threat Modeling Process
Decompose
Understand the system
Identify
Find potential threats
Prioritize
Rank by risk
Mitigate
Address the threats
STRIDE Framework
STRIDE is a mnemonic for six threat categories, developed by Microsoft. Each category maps to a security property that can be violated.
S - Spoofing Identity
Pretending to be someone or something else
Examples: Forged authentication tokens, impersonating users, ARP spoofing
Mitigations: Strong authentication, MFA, certificate pinning, digital signatures
T - Tampering with Data
Modifying data or code without authorization
Examples: SQL injection, man-in-the-middle, modifying files/configs
Mitigations: Input validation, hashing, digital signatures, access controls
R - Repudiation
Denying having performed an action
Examples: Deleting logs, claiming "I didn't do that", shared accounts
Mitigations: Audit logging, digital signatures, timestamps, secure log storage
I - Information Disclosure
Exposing information to unauthorized parties
Examples: Data breaches, verbose error messages, insecure storage
Mitigations: Encryption, access controls, data classification, secure error handling
D - Denial of Service
Making a system unavailable to legitimate users
Examples: DDoS attacks, resource exhaustion, crash bugs
Mitigations: Rate limiting, load balancing, redundancy, input validation
E - Elevation of Privilege
Gaining capabilities without proper authorization
Examples: Buffer overflow to SYSTEM, IDOR, privilege escalation bugs
Mitigations: Least privilege, sandboxing, input validation, regular patching
STRIDE per Element
Different system elements are susceptible to different STRIDE threats:
| Element | S | T | R | I | D | E |
|---|---|---|---|---|---|---|
| External Entity | ✓ | ✓ | ||||
| Process | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Data Store | ✓ | ✓ | ✓ | ✓ | ||
| Data Flow | ✓ | ✓ | ✓ |
DREAD Risk Rating
DREAD is a risk rating system that helps prioritize threats based on five factors, each scored 1-10.
D
Damage
How bad is the impact?
R
Reproducibility
How easy to reproduce?
E
Exploitability
How easy to exploit?
A
Affected Users
How many impacted?
D
Discoverability
How easy to find?
# DREAD Calculation Example
# Scale: 1 (Low) to 10 (High)
Threat: SQL Injection in Login Form
----------------------------------------
Damage: 9 # Full database access
Reproducibility: 10 # Always works
Exploitability: 8 # Well-known technique
Affected Users: 10 # All users
Discoverability: 7 # Found with basic testing
----------------------------------------
DREAD Score = (9 + 10 + 8 + 10 + 7) / 5 = 8.8 (Critical)
Risk Rating Scale:
- 1-3: Low Risk
- 4-6: Medium Risk
- 7-8: High Risk
- 9-10: Critical RiskPASTA Framework
Process for Attack Simulation and Threat Analysis (PASTA) is a seven-stage, risk-centric threat modeling framework.
Stage 1: Define Objectives
Identify business objectives, security requirements, and compliance needs. Understand what you're protecting and why.
Stage 2: Define Technical Scope
Document the technical environment: components, dependencies, data flows, trust boundaries, and technologies.
Stage 3: Application Decomposition
Create data flow diagrams (DFDs), identify entry points, assets, trust levels, and access controls.
Stage 4: Threat Analysis
Research applicable threats using threat intelligence, attack libraries (ATT&CK), and industry reports.
Stage 5: Vulnerability Analysis
Map vulnerabilities to threats. Use vulnerability databases, security testing, and code review findings.
Stage 6: Attack Modeling
Create attack trees and simulate attack scenarios. Determine attack likelihood and potential impact.
Stage 7: Risk & Impact Analysis
Quantify residual risk, prioritize threats, and recommend countermeasures aligned with business risk tolerance.
Attack Trees
Attack trees visualize the different paths an attacker could take to achieve a goal. The root node is the attacker's goal, and child nodes represent steps to achieve it.
Attack Tree: Compromise User Account
=====================================
[Goal: Access User Account] (OR)
├── [Steal Credentials] (OR)
│ ├── [Phishing Attack]
│ │ ├── Send spearphishing email
│ │ └── Create credential harvesting page
│ ├── [Credential Stuffing]
│ │ ├── Obtain breached credentials
│ │ └── Automate login attempts
│ ├── [Keylogger]
│ │ ├── Deliver malware via email
│ │ └── Exploit browser vulnerability
│ └── [Shoulder Surfing]
│
├── [Bypass Authentication] (OR)
│ ├── [Exploit MFA Weakness]
│ │ ├── SIM swapping
│ │ ├── MFA fatigue (push bombing)
│ │ └── SS7 interception
│ ├── [Session Hijacking]
│ │ ├── Steal session cookie (XSS)
│ │ └── Session fixation
│ └── [Password Reset Flaw]
│ ├── Predictable reset tokens
│ └── Account takeover via email
│
└── [Exploit Authorization Flaw] (OR)
├── [IDOR] - Access other user's data
└── [Privilege Escalation] - Modify roleAttack Tree Notation
AND Nodes
All child nodes must be completed to achieve the parent goal. Example: "Steal credentials AND bypass MFA"
OR Nodes
Any child node can achieve the parent goal. Example: "Phishing OR credential stuffing OR keylogger"
Data Flow Diagrams (DFD)
DFDs are essential for threat modeling. They show how data moves through a system and identify trust boundaries.
DFD Elements
Example Web Application DFD
Trust Boundaries
Threat Modeling Tools
Microsoft Threat Modeling Tool
Free tool for creating DFDs and automatically generating STRIDE threats. Good for Windows/Azure apps.
DownloadOWASP Threat Dragon
Open-source threat modeling tool with web and desktop versions. Creates DFDs and documents threats.
OWASP ProjectIriusRisk
Commercial platform with questionnaire-based approach and integration with issue trackers.
iriusrisk.comThreagile
Agile threat modeling as code. Define models in YAML, generate reports and diagrams.
threagile.ioThreagile Example
# Threagile threat model (YAML)
threagile_version: 1.0.0
title: E-Commerce Application
author:
name: Security Team
business_criticality: critical
technical_assets:
Web Application:
id: web-app
description: Customer-facing web application
type: process
usage: business
technologies:
- web-application
machine: container
internet: true
encryption: none
Customer Database:
id: customer-db
description: PostgreSQL database with customer data
type: datastore
usage: business
technologies:
- postgresql
machine: container
encryption: transparent
trust_boundaries:
DMZ:
id: dmz
description: Demilitarized zone
type: network-cloud
technical_assets_inside:
- web-app
Internal Network:
id: internal
description: Internal corporate network
type: network-on-prem
technical_assets_inside:
- customer-db
data_flows:
- id: user-to-web
source: internet
target: web-app
protocol: https
authentication: session-id
- id: web-to-db
source: web-app
target: customer-db
protocol: tcp
authentication: credentialsThreat Modeling Questions
Use these questions to guide your threat modeling sessions:
What are we building?
- • What does the system do?
- • What data does it handle?
- • Who uses it?
- • What technologies are used?
What can go wrong?
- • How could an attacker abuse this?
- • What are the trust boundaries?
- • Where does data flow?
- • What are the entry points?
What are we doing about it?
- • What controls exist?
- • What controls are needed?
- • What's the priority?
- • Who is responsible?
Did we do a good job?
- • Did we find all threats?
- • Were mitigations effective?
- • What did we learn?
- • What should we do next time?
Threat Model Documentation
Evidence to Capture
A threat model is a design artefact with a version, a date and named assumptions. Without those it cannot be reviewed, revised or defended a year later.
Diagram and scope version: The data flow diagram or component diagram the session worked from, with its version or commit, and the system boundary drawn on it.
Assumptions: What the model assumes is true: trust in the identity provider, network segmentation, data classification. Most model failures are failed assumptions.
Threats as sentences: Each threat written as actor, component, action and consequence, with its STRIDE category, rather than a one-line slogan such as "injection possible".
Rating and rationale: The DREAD or equivalent score with the reasoning per factor. A bare number cannot be audited and will be re-litigated every cycle.
Controls credited: The existing control each threat is judged against, and whether that control is verified or assumed to exist.
Session record: Date, participants and the owner who accepted this model as the current baseline for the system.
False Positives in a Threat Model
Threat models over-report far more often than they under-report, and the excess is what trains teams to ignore the output.
- Threat with no path: A threat requiring a capability the architecture excludes — no exposure, no credential path, no writable interface — is a thought, not a finding.
- Control credit with no evidence: Assuming web application firewall coverage or segmentation that was never verified under-reports now and over-reports after the first incident.
- Duplicated across elements: The same weakness appears against the data store, the flow and the process. Count it once, with one treatment and one owner.
- Generic catalogue paste: Filling every STRIDE category for every element produces hundreds of entries nobody triages. Categories that cannot apply should be ruled out explicitly.
- Privacy finding as security threat: Purpose limitation and retention issues are not STRIDE threats. They belong in a privacy analysis and distort the ranking when merged in.
- Already mitigated by design: A threat answered by a control present in the deployed design, rather than the proposed one, is closed. Note it and move on.
Model Maintenance and Treatment
The output is a maintained model, threats routed into delivery work and an explicit review trigger — not a document filed once at design time.
Turn threats into owned work
- • Give every unmitigated threat an owner, a target release and an acceptance criterion
- • Attach the mitigation to the architecture decision record it changes
- • Close a threat only when the control is verified in the deployed system
Keep the model current
- • Re-run the model on architecture change, new integration, or a new actor targeting the sector
- • Version the diagram alongside the code or infrastructure it describes
- • Re-test the assumptions list each cycle and delete the ones that no longer hold
Review trigger
- • New data flow crossing a trust boundary
- • Threat catalogue or ATT&CK revision touching a modelled element
- • An incident that contradicts a control the model credited