Threat Modeling

What it is

Threat modeling is a structured, proactive process for identifying potential security threats to a system, assessing their likelihood and impact, and designing mitigations before implementation. It answers four questions: What are we building? (architecture decomposition via data flow diagrams); What can go wrong? (threat enumeration via frameworks like STRIDE); What are we going to do about it? (mitigations mapped to each threat); and Did we do a good enough job? (validation that mitigations are in place and effective). Threat modeling is most valuable in the design phase — at that point, architectural decisions are still reversible and mitigations are cheapest to implement. A fix identified in threat modeling costs 10–100x less than the same fix discovered in penetration testing or production.

STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) is the most widely used threat categorisation framework, developed by Microsoft. It is applied to each element (process, data store, data flow, external entity) and trust boundary in a Data Flow Diagram (DFD). PASTA (Process for Attack Simulation and Threat Analysis) is a risk-centric methodology with seven stages that aligns threat modeling to business objectives and simulates attacker decision-making. Attack trees are graphical models that decompose an attacker's goal into sub-goals and alternative paths, providing a systematic way to enumerate attack scenarios. DREAD (Damage, Reproducibility, Exploitability, Affected users, Discoverability) is a risk-scoring rubric for prioritising identified threats.

Why it exists

Most security vulnerabilities are introduced during the design phase, not the coding phase. Architectural decisions — which authentication mechanism to use, how to store credentials, whether to validate input on the client or server — establish patterns that, once instantiated in code, are expensive to change. Threat modeling creates a structured forcing function to reason about adversarial scenarios at design time, before those decisions are frozen. It also shifts the conversation from "what security features do we have?" to "what threats do we face and do our controls actually address them?" — the difference between checkbox security and risk-based security. Regulatory frameworks (SOC 2, PCI DSS, ISO 27001) increasingly require evidence of security risk assessment that threat modeling directly provides.

When to use

• During the design phase of any new feature that involves authentication, authorisation, data storage, external integrations, or privilege changes.
• When designing a new system or service from scratch.
• When making significant architectural changes (adding an API, changing an auth mechanism, integrating a new third party).
• As part of a Security Development Lifecycle (SDL) gate before major feature launches.
• When onboarding critical new vendors or supply chain components.

When not to use

• Minor bug fixes: Threat modeling is not required for small, low-risk code changes; apply it proportionally to risk.
• As a replacement for testing: Threat modeling identifies theoretical threats; SAST, DAST, and penetration testing validate that mitigations actually work.
• After significant implementation is complete: Threat modeling is least effective when it must react to existing design choices rather than informing them.

Typical architecture

STRIDE APPLIED TO A WEB APPLICATION DFD:

DFD Elements:
  [Browser] ---(HTTPS)---> [Load Balancer]
                           [Load Balancer] ---> [App Server]
                                               [App Server] --> [DB]
                                               [App Server] --> [Auth Service]

STRIDE analysis for App Server process:
  S — Spoofing:      Can an attacker impersonate a user?
                     Mitigation: JWT validation, short-lived tokens
  T — Tampering:     Can an attacker modify data in transit?
                     Mitigation: TLS everywhere, HMAC on messages
  R — Repudiation:   Can users deny their actions?
                     Mitigation: immutable audit log with user ID
  I — Information    Can an attacker read sensitive data?
      Disclosure:    Mitigation: field-level encryption, no secrets in logs
  D — Denial of      Can an attacker make the app unavailable?
      Service:       Mitigation: rate limiting, WAF, auto-scaling
  E — Elevation of   Can a user escalate their privileges?
      Privilege:     Mitigation: RBAC, server-side authz checks

DREAD SCORING (example threat):
  SQLi via user search input:
  D (Damage):         3 — full DB exfiltration
  R (Reproducibility):3 — trivial with sqlmap
  E (Exploitability): 3 — no auth required
  A (Affected):       3 — all users
  D (Discoverability):2 — needs enumeration
  Score: 14/15 — Critical, immediate mitigation

SDL INTEGRATION:
  Design review → Threat model created
  Code review → Mitigations verified in code
  Pre-launch → Pen test validates open threats

Pros and cons

Implementation notes

Start with a Data Flow Diagram (DFD) at level 1 or 2 — not too detailed, not too abstract. The diagram must capture all external entities, processes, data stores, data flows, and trust boundaries. Trust boundaries are the most important elements to identify: STRIDE threats are most commonly exploitable across trust boundaries (between the internet and your application, between your application and a database, between user-controlled input and a privileged process). Use Microsoft Threat Modeling Tool or OWASP Threat Dragon to create and maintain DFDs. For teams new to threat modeling, STRIDE-per-element is the most accessible starting method: for each element in the DFD, systematically ask which STRIDE categories apply. For high-maturity teams, shift to STRIDE-per-interaction: analyse each data flow rather than each element, which is more rigorous but more time-consuming.

Integrate threat modeling into the pull request or design review process via a lightweight template. A one-page threat model with: architecture context, trust boundaries, top 5 STRIDE threats, and mitigations is more useful than a 50-page document that nobody reads. Assign ownership of each threat to a specific engineer and track remediation in the issue tracker. Revisit the threat model when the architecture changes — especially when adding new external integrations, changing authentication mechanisms, or processing new categories of sensitive data.

Common failure modes

• Analysis paralysis: Attempting to enumerate every possible threat before implementing any mitigation; timebox the exercise and focus on high-DREAD threats first.
• Stale threat models: A threat model created at project start and never updated is misleading — it implies threats were addressed that may have been reintroduced by subsequent changes.
• Missing trust boundaries: DFDs that do not explicitly mark trust boundaries miss the most important threat surfaces; trust boundaries between components are where the most critical threats emerge.
• No tracking of mitigations: Identifying threats without tracking whether mitigations were implemented means the threat model has no effect on actual security.
• Security team silo: Threat models created by security teams without developer involvement produce mitigations that are impractical to implement and generate friction rather than security improvement.

Decision checklist

• Is there a DFD that captures all external entities, processes, data stores, flows, and trust boundaries?
• Has STRIDE (or an equivalent) been applied at each trust boundary?
• Is each identified threat assigned a risk score (DREAD or equivalent)?
• Is each high-risk threat assigned to an owner with a mitigation task?
• Is the threat model stored alongside the codebase and updated with architecture changes?
• Are mitigations validated in code review and/or testing?

Example use cases

• New payment feature: Before implementing a checkout flow, a STRIDE analysis of the DFD identifies: spoofing of the payment provider callback (→ HMAC webhook signature), tampering with order amounts in transit (→ sign order total server-side), elevation of privilege via coupon code abuse (→ server-side coupon validation).
• API gateway launch: STRIDE identifies IDOR (Broken Object Level Authorisation) as the top threat; mitigation is mandatory object-level authorisation check in each endpoint handler, tested by DAST in CI.
• Third-party integration: PASTA analysis of a new data-sharing integration with a partner identifies data exfiltration as the primary risk; mitigation includes field-level encryption and egress rate limiting.

Related patterns

• Defense in Depth — Threat modeling determines which DiD layers need strengthening.
• Secure SDLC — Threat modeling is a key stage in the Secure Development Lifecycle.
• API Security — OWASP API Top 10 is a pre-enumerated threat list that can seed API threat models.

Further reading

• OWASP Threat Modeling
• Microsoft Threat Modeling Tool
• OWASP Threat Dragon (open-source tool)