Threat Modeling

Threat Modeling

Threat modeling is the practice of thinking like an attacker before you build (or before you’re breached), so you find design weaknesses while they’re still cheap to fix. Adam Shostack frames it as four questions:

1. What are we working on? (a diagram / data-flow of the system)
2. What can go wrong? (the threats)
3. What are we going to do about it? (mitigations)
4. Did we do a good job? (validation)

Everything below is a structured way to answer question 2 thoroughly.

STRIDE

STRIDE (Microsoft) is the most widely used framework. Walk each element of your data-flow diagram and ask whether each threat category applies:

Threat	Violates	Example
Spoofing	Authentication	Logging in as another user
Tampering	Integrity	Modifying data in transit or at rest
Repudiation	Non-repudiation	Denying an action with no audit trail
Information disclosure	Confidentiality	Leaking PII or secrets
Denial of service	Availability	Exhausting a resource to take it down
Elevation of privilege	Authorization	A normal user gaining admin rights

STRIDE is the best default for software/system design reviews.

DREAD — ranking what you find

STRIDE finds threats; DREAD helps prioritize them by scoring Damage, Reproducibility, Exploitability, Affected users, and Discoverability. It is subjective — treat the scores as a conversation tool for relative ranking, not a precise metric. Many teams now substitute a simpler likelihood × impact matrix or OWASP Risk Rating.

PASTA — risk- and business-centric

PASTA (Process for Attack Simulation and Threat Analysis) is a heavier, seven-stage methodology that ties technical threats to business impact and simulates real attacker behavior. Use it for high-stakes systems where you need to justify security spend to the business, not for a quick feature review.

Attack trees

An attack tree models a single attacker goal as the root, with branches of sub-goals and leaf techniques (AND/OR nodes). They’re excellent for reasoning about a specific high-value target — “compromise the signing key” — and complement STRIDE’s breadth with depth.

Goal: Read another user's messages
├── OR Steal their session
│   ├── XSS to exfiltrate cookie
│   └── Network MitM (no TLS / stripped TLS)
├── OR Server-side access
│   ├── SQL injection -> dump messages
│   └── Compromise an admin account
└── OR Endpoint compromise
    └── Malware on the victim's device

When to use which

Situation	Reach for
Design review of a feature/system	STRIDE
Ranking a found set of threats	DREAD / likelihood × impact
Business-aligned, high-stakes program	PASTA
Deeply analyzing one critical goal	Attack trees

Start simple. A whiteboard diagram + STRIDE delivers most of the value; add the heavier methods only where the stakes justify them.

Worked example: a small web app

System: a web app with a browser client, an API server, and a database.

1. Diagram the data flows: browser → API (HTTPS) → DB; plus an admin panel.
2. STRIDE the API boundary: Spoofing → enforce auth on every endpoint; Tampering → validate/normalize all input, sign anything client-held; Information disclosure → no secrets in logs, least-privilege DB user; Elevation → server-side authorization checks, never trust the client’s role claim.
3. Mitigate & record each threat with an owner and a test.
4. Validate: add tests/monitoring that would fail if a mitigation regresses.

Pair the model with adversarial testing — see Red Teaming — and feed confirmed gaps into your Incident Response prep.

Tooling

• OWASP Threat Dragon — free, open-source diagramming + STRIDE, desktop or web.
• Microsoft Threat Modeling Tool — free, STRIDE-driven, generates a threat list from your diagram.
• pytm — threat models as code (Python), good for versioning models alongside the system.

Related

• Blue Team Tools — detecting the threats you model
• Enterprise Incident Response — responding when one gets through
• Cyber Red Teaming — adversarial validation of the model
• Threats Catalog — real-world TTPs to inform “what can go wrong”