Threat Modeling for Developers: STRIDE, PASTA & DREAD with Practical Examples

What Is Threat Modeling?

Threat modeling is the structured process of identifying security threats, understanding attack surfaces, and designing mitigations — before writing code. It's where you answer: "What can go wrong?"

Microsoft's Data: Internal Microsoft research found that threat modeling at the design phase prevented 64% of security bugs that would otherwise have been found (expensively) during penetration testing or post-release.

---

When to Threat Model

---

STRIDE: The Most Popular Framework

STRIDE was developed by Microsoft and categorizes threats into 6 types:

STRIDE Applied: User Authentication System

System: Login page → API → Database → Session management

Spoofing:
  Threat: Attacker uses stolen credentials
  Mitigation: MFA, rate limiting, impossible travel detection

Tampering:
  Threat: Session token modified to change user ID
  Mitigation: Signed JWTs, server-side session validation

Repudiation:
  Threat: User denies making a purchase
  Mitigation: Immutable audit log with timestamps and IP

Information Disclosure:
  Threat: Password hashes exposed via API
  Mitigation: Never return password fields, use Argon2id

Denial of Service:
  Threat: Credential stuffing overwhelms login endpoint
  Mitigation: Rate limiting (5/min), CAPTCHA after 3 failures

Elevation of Privilege:
  Threat: Regular user accesses admin panel
  Mitigation: Server-side role checks on every request

---

PASTA: Process for Attack Simulation and Threat Analysis

PASTA is a risk-centric methodology with 7 stages:

---

DREAD: Threat Scoring

DREAD scores each threat on 5 dimensions (1-10 scale):

Score Interpretation:

• 40-50: Critical — Fix immediately
• 30-39: High — Fix this sprint
• 20-29: Medium — Plan for next cycle
• 10-19: Low — Backlog

---

Data Flow Diagram Template

┌──────────────┐         HTTPS          ┌──────────────────┐
│   Browser    │ ─────────────────────► │   API Gateway     │
│  (External)  │ ◄───────────────────── │   (Trust boundary) │
└──────────────┘                        └────────┬─────────┘
                                                 │
                                    ┌────────────┴────────────┐
                                    │                         │
                              ┌─────▼──────┐          ┌──────▼──────┐
                              │  Auth       │          │  Business   │
                              │  Service    │          │  Logic      │
                              │ (Internal)  │          │  (Internal) │
                              └─────┬──────┘          └──────┬──────┘
                                    │                         │
                              ┌─────▼──────┐          ┌──────▼──────┐
                              │  User DB   │          │  Data Store │
                              │ (Secrets)  │          │ (PII)       │
                              └────────────┘          └─────────────┘

Trust boundaries to analyze:

• Browser ↔ API Gateway (public internet)
• API Gateway ↔ Internal services (network boundary)
• Services ↔ Databases (data access boundary)

---

Threat Modeling Checklist

• Identify all entry points (APIs, webhooks, file uploads, event sources)
• Map data flows (where does sensitive data travel?)
• Define trust boundaries (where do security contexts change?)
• Apply STRIDE to each component and data flow
• Score threats using DREAD
• Identify mitigations for high-risk threats
• Document accepted risks with justification
• Review threat model when architecture changes

---

Further Reading

• OWASP Threat Modeling — Methodology guide
• Microsoft (2024), "Threat Modeling Tool" — Free threat modeling application
• Shift-Left Security — Security at design time
• OWASP Proactive Controls — Developer security practices