Skip to content
Olivier Reuland

Threat Modelling 101: Choosing the Right Framework for Your Security Programme

A short practical intro to STRIDE, DREAD, and PASTA, three complementary threat modelling frameworks for different stages of your security process.

Most engineering teams only start thinking about security threats after something goes wrong. A vulnerability slips through a code review, a penetration test surfaces a critical flaw, or, worst of all, a breach makes the conversation unavoidable. Threat modelling flips this dynamic. It's the practice of systematically identifying and prioritising security risks before they become incidents.

The challenge is knowing which framework to use. Three methodologies dominate the field: STRIDE, DREAD, and PASTA. Each serves a different purpose, and applying the wrong one at the wrong stage wastes time and creates false confidence. Here's how to think about each.

STRIDE

STRIDE was developed at Microsoft and remains one of the most widely adopted threat modelling frameworks in software engineering. It's designed to be applied during the design phase, when changing architecture is still cheap.

The acronym maps to six threat categories:

  • Spoofing: Impersonating a user, system, or service to gain unauthorised access
  • Tampering: Modifying data in transit or at rest
  • Repudiation: Performing an action and then denying it happened
  • Information Disclosure: Exposing data to parties who shouldn't see it
  • Denial of Service: Disrupting availability for legitimate users
  • Elevation of Privilege: Gaining access beyond what was authorised

The value of STRIDE is its structure. By walking through each component in a data flow diagram and asking "could this component be exploited in any of these six ways?", teams surface a broad range of threats quickly. It's not designed to tell you how serious each threat is, just to make sure nothing gets missed.

When do I use it: Early in the design phase, especially when reviewing new features, integrations, or architectural changes.

Example: Consider a SaaS application with a standard user login endpoint. Running STRIDE across it surfaces:

  • Spoofing: An attacker replays a stolen session token to authenticate as another user.
  • Tampering: An attacker modifies the user_id claim in a JWT to access a different account.
  • Repudiation: No audit log exists, so a user can deny having performed a destructive action.
  • Information Disclosure: Error messages reveal whether an email address is registered, enabling account enumeration.
  • Denial of Service: The endpoint has no rate limiting, allowing an attacker to flood it and lock out legitimate users.
  • Elevation of Privilege: A bug in the role-check middleware lets a standard user reach admin routes.

In a two-hour design review, this exercise has surfaced six distinct threats across a single endpoint, before a line of production code is written.

The OWASP Threat Modeling Process is an excellent next step to learn more about this.

DREAD

Once you have a list of threats, whether from STRIDE or elsewhere, you still need to decide what to fix first. That's where DREAD comes in.

DREAD is a scoring model that rates each threat across five dimensions, each scored from 1 to 10:

  • Damage: How bad would a successful attack actually be?
  • Reproducibility: How reliably can the attack be repeated?
  • Exploitability: How much skill and effort does the attack require?
  • Affected Users: What proportion of your user base would be impacted?
  • Discoverability: How easy is it for an attacker to find this vulnerability?

The five scores are averaged to produce a single risk rating, which allows teams to compare threats and make defensible prioritisation decisions. The main criticism of DREAD is that scoring can be subjective, two engineers might rate the same threat differently. I think it’s just like story points in DevOps. It does not matter, because we learn as a team how we work over time, and act accordingly. One team might set their threat limit to 40, others 20, once they know how they tend to rate threats.

Importantly, the framework provides a useful common language for discussing risk, especially in cross-functional conversations between security and engineering.

When do I use it: After threat identification, to rank and communicate risk to engineering and product stakeholders.

Example: Taking the Information Disclosure threat from above (email enumeration via error messages), a DREAD assessment might look like this:

  • Damage: 3. Low direct harm, but enables targeted phishing.
  • Reproducibility: 10. Trivially repeatable with a simple script.
  • Exploitability: 9. Requires no special skills or tooling.
  • Affected Users: 8. Any registered email address in the system could be enumerated.
  • Discoverability: 8. Any attacker testing the login form would find this immediately.

Risk score: 30 out of 50. That pushes this fix to the top of the remediation backlog ahead of lower-scoring items, such as the missing audit log (score: 21), giving the engineering team a clear and defensible priority order.

PASTA

STRIDE and DREAD are primarily technical tools. PASTA (Process for Attack Simulation and Threat Analysis) takes a broader view. It's a seven-stage methodology that connects technical threats directly to business impact, making it the right choice for organisations that need their security programme to align with regulatory requirements or executive risk tolerance.

The seven stages move from defining business objectives through technical scoping, system decomposition, threat intelligence analysis, vulnerability identification, attack simulation, and finally risk-impact assessment. The output isn't just a list of threats, it's a risk-prioritised mitigation plan that speaks the language of business decision-makers.

When do I use it: For strategic security assessments, compliance-driven reviews (SOC 2, ISO 27001, NIST), or when preparing for a board-level security briefing.

Example: Applied to the same SaaS authentication service, a PASTA exercise might look like this:

  1. Define Objectives: Protect user accounts, maintain SOC 2 Type II compliance, and avoid a credential breach.
  2. Define Technical Scope: Login API, session management, password reset flow, and third-party OAuth integration.
  3. Decompose the System: User database, auth service, email delivery service, and Redis token store.
  4. Analyse Threats: Credential stuffing, session hijacking, and OAuth misconfiguration.
  5. Analyse Weaknesses: No MFA enforcement, JWT secrets stored in environment variables, no rate limiting on the login endpoint.
  6. Model/Simulate Attacks: Simulate a credential stuffing campaign against /login using a publicly available breach credential list.
  7. Analyse Risk/Impact: A realistic attack scenario could compromise around 3% of accounts. At 20,000 users, that is approximately 600 account takeovers, a likely SOC 2 audit finding, and a potential notification obligation under applicable data protection law.

Where STRIDE and DREAD tell you what to fix and in what order, PASTA tells you what it costs the business if you do not.

Which Framework Is Right for You?

The honest answer is that they complement rather than compete with each other.

  • Use STRIDE during design to make sure you've thought through the attack surface from every angle.
  • Use DREAD to turn that list into a prioritised backlog your engineering team can act on.
  • Use PASTA when you need to step back, connect your technical findings to business risk, and build a security programme that holds up to scrutiny, from auditors, from investors, or from your own leadership team.

Threat modelling doesn't need to be a heavyweight process. Even a two-hour whiteboard session using STRIDE on a new feature can surface issues that would have cost ten times as much to remediate in production. The frameworks exist to make that conversation structured and repeatable, not to replace engineering judgement, but to sharpen it.

Related

Olivier Reuland