STRIDE vs PASTA vs Attack Trees: Threat Modeling Compared

The methodology question that misses the point

There’s a persistent question in security circles: which threat modeling methodology is best? STRIDE or PASTA? Attack trees or DREAD? The debate can get surprisingly heated, with practitioners defending their chosen framework like sports fans defending their team.

But here’s what we’ve learned from years of doing threat modeling: comparing threat modeling methodologies often distracts from the real question. The framework you choose matters less than whether you’re actually asking the right questions about your architecture.

Every established threat modeling methodology exists because it provides structure. It turns abstract thinking into a repeatable process. And that’s valuable. But the methodology itself is a means, not an end.

Before diving into which framework to use, it helps to understand what problem they’re all solving.

The four questions that matter more than methodology

Security architect Adam Shostack’s framing has become foundational in threat modeling circles, and for good reason. Every threat modeling methodology is ultimately a structured way to answer four fundamental questions:

1. What are we building? Understand your system’s components, data flows, trust boundaries, and external dependencies.
2. What can go wrong? Systematically identify potential threats and vulnerabilities across those components.
3. What are we going to do about it? Develop specific, actionable remediations for identified threats.
4. Did we do a good enough job? Evaluate whether your analysis was comprehensive and whether your remediations actually address the threats.

Different methodologies structure these questions differently. They emphasize different aspects. They categorize findings in different ways. But they’re all fundamentally answering the same four questions. Understand that frame, and any methodology becomes a tool rather than dogma.

STRIDE: The systematic workhorse

STRIDE is the most widely adopted threat modeling methodology, developed by Loren Kohnfelder and Praerit Garg at Microsoft in the late 1990s. If you’ve done any structured threat modeling, you’ve probably encountered it.

What it is

STRIDE is a categorization framework that organizes threats into six categories: Spoofing (pretending to be something you’re not), Tampering (modifying data or code), Repudiation (denying you did something you did), Information Disclosure (exposing confidential data), Denial of Service (making systems unavailable), and Elevation of Privilege (gaining unauthorized capabilities).

How it works

You start by decomposing your system into a data flow diagram or architectural graph. Then you systematically work through each component and each data flow, asking for each STRIDE category: “Could this happen here?” You document findings, severity, and impact.

Strengths

STRIDE is comprehensive and systematic. The six categories provide broad coverage of threat types. It’s well-documented with years of refinement and public guidance. Teams new to threat modeling appreciate the structure — it removes the question of “what do we look for?” because the categories answer it. You can teach it relatively quickly, and multiple people can apply it consistently.

Limitations

STRIDE can feel checklist-heavy if applied mechanically. Teams sometimes treat it as “apply all six categories to every component and check boxes,” missing the point that you’re supposed to think critically about what makes sense for each architectural element. It also requires system decomposition upfront, which means significant effort before you start identifying threats. For complex systems, data flow diagrams can become unwieldy.

Best for

STRIDE works best for teams wanting a structured, repeatable process that scales across many systems. It’s ideal when you need consistency across multiple teams or departments, and when you want junior security practitioners to apply the methodology without requiring years of experience.

PASTA: Risk-centric and business-aligned

PASTA (Process for Attack Simulation and Threat Analysis) emerged in the 2000s as a more risk-centric alternative. Where STRIDE is threat-focused, PASTA is risk-focused — it ties threat analysis explicitly to business impact.

What it is

PASTA is a seven-stage methodology: (1) Define business objectives, (2) Define technical scope, (3) Application decomposition, (4) Threat analysis, (5) Vulnerability analysis, (6) Attack modeling, and (7) Risk and impact analysis. It’s heavyweight by design.

How it works

You start by understanding what the business is trying to protect and why. Then you decompose the application technically. Only after establishing context do you move into threat analysis. The approach forces explicit connection between security findings and business outcomes.

Strengths

PASTA shines when you need to explain security findings to non-technical stakeholders. Because threats are explicitly tied to business impact and risk scoring, you’re not just saying “we found an elevation of privilege vulnerability.” You’re saying “we found an elevation of privilege vulnerability that could result in unauthorized access to customer payment data, affecting compliance requirements and customer trust.” It also forces consideration of attacker perspective — you’re modeling specific attack scenarios, not just threat categories.

Limitations

PASTA requires significantly more expertise and coordination. You need people who understand business risk, technical architecture, and security analysis working together. The process is time-consuming — not because it’s bloated, but because doing it right demands rigor. It’s harder to teach and scale than STRIDE. If your organization lacks clear business context or risk frameworks, PASTA can feel academic.

Best for

PASTA works best for organizations that need to connect security findings directly to business impact, especially when budget decisions or executive communication matter. It’s valuable for larger organizations where security and business teams need to speak the same language about risk.

Attack Trees: Visual, goal-oriented analysis

Attack trees (popularized by Bruce Schneier) take a different angle entirely. Rather than starting with system components or threat categories, you start with an attacker’s goal and work backward.

What it is

An attack tree is a hierarchical decomposition of a goal (usually an attacker’s goal) into sub-goals and attack methods. The root is the goal — “gain access to the admin dashboard.” Branches represent different ways to achieve it. Sub-branches represent even more specific attack steps. Nodes are typically AND/OR gates, showing whether a sequence of actions is required or alternative paths exist.

How it works

You define your target (what would be the worst outcome if compromised). You ask: what are all the ways an attacker could achieve that? For each way, you ask: what sub-goals must be achieved? You keep decomposing until you reach concrete attack steps. You can annotate branches with estimated cost, difficulty, or likelihood.

Strengths

Attack trees are intuitive for communicating threats to non-technical stakeholders. A visual diagram is often more compelling than a text list of threats. The approach is flexible — you can focus on high-value targets or specific scenarios without needing to comprehensively model everything. It forces attacker-centric thinking: you’re not just listing threats, you’re thinking about how an attacker would actually achieve their goal.

Limitations

Attack trees can become unwieldy for complex systems quickly. A three-level tree can become a visual mess. The methodology doesn’t inherently ensure comprehensive coverage — you might miss entire categories of threats because you didn’t think of a particular attack path. Building a thorough attack tree requires significant security expertise. And attack trees are often used for deep dives on specific targets, not full system analysis.

Best for

Attack trees excel when you’re analyzing a specific, high-value target or attack scenario in depth. They’re valuable for communicating findings to executives and non-technical stakeholders. They work well alongside other methodologies as a complementary approach — use STRIDE for systematic coverage, then use attack trees to deeply analyze the most critical threats.

Honorable mentions: DREAD, LINDDUN, VAST, OCTAVE

The threat modeling landscape includes several other approaches worth knowing about:

DREAD is a risk rating system (Damage, Reproducibility, Exploitability, Affected Users, Discoverability), not a complete methodology. It’s useful for scoring and ranking threats but requires another methodology to identify them in the first place.

LINDDUN is a privacy-focused variant that explicitly addresses data privacy threats through seven categories (Linkability, Identifiability, Non-repudiation, Detectability, Disclosure, Unawareness, Non-compliance). Use it when privacy is a primary concern.

VAST (Visual, Agile, Simple Threat modeling) is designed for automation and at-scale analysis, emphasizing speed and integration into development workflows.

OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation) is an organizational methodology that starts with business context and asset criticality, similar to PASTA’s business-first approach but with different emphasis.

Each exists because different organizations have different priorities. The existence of multiple methodologies isn’t a weakness — it’s a sign that there’s no one-size-fits-all approach to threat modeling.

Choosing your threat modeling methodology: The honest answer

Here’s what we’ve seen work in practice: the best methodology is the one your team will actually use.

Starting with a rigorous approach that your team abandons is worse than starting with a simpler approach you’ll maintain. Perfect threat modeling that never happens doesn’t protect anyone. Imperfect threat modeling that gets done regularly provides real value.

This doesn’t mean methodology doesn’t matter. It means the method serves the practice, not the other way around. You should choose based on:

• Your team’s expertise. New to threat modeling? STRIDE provides structure. Experienced practitioners? PASTA or attack trees might give you the depth you need.
• Your organizational context. Need business alignment? PASTA. Need to communicate to non-technical stakeholders? Attack trees. Need comprehensive systematic coverage? STRIDE.
• Your constraints. PASTA is thorough but time-intensive. STRIDE is lighter-weight. Attack trees can be focused on specific scenarios.
• Your complementarity needs. These methodologies complement each other. STRIDE for systematic coverage, attack trees for deep dives, PASTA for risk alignment.

The real insight is this: starting imperfect is better than not starting. Most teams discover their methodological preferences through practice. Start with one approach, apply it, learn what works and what doesn’t, and adjust. Threat modeling is iterative by nature — let your methodology be too.

How ThreatKrew approaches this

When we built ThreatKrew, we chose to build on STRIDE as our foundation. Not because STRIDE is objectively the “best” methodology — that’s the wrong framing — but because STRIDE provides the most systematic, repeatable framework for automated analysis at scale.

Here’s our reasoning: STRIDE’s categorization is explicit and comprehensive. That explicitness makes it suitable for encoding in algorithms. The six categories provide clear structure for systematic analysis. Every component and data flow can be methodically evaluated against each category.

But STRIDE is only the starting point. We layer in MITRE ATT&CK for real-world adversary technique mapping. We add NIST SP800-53 for actionable remediation controls. And critically, we built independent verification into our analysis pipeline to challenge findings regardless of which category generated them. That independent review process is how we address STRIDE’s potential weakness of becoming checklist-like, ensuring that findings are genuinely rigorous rather than mechanically applied.

The deeper philosophy matters more than the framework choice. We built ThreatKrew on two principles: (1) methodologies should be encoded so they’re repeatable and accessible, and (2) no single pass through a methodology is complete — independent verification and questioning are essential.

The methodology is the means, not the end. The end is finding real risks and helping teams address them. That’s why we focus on the four questions: what are we building, what can go wrong, what do we do about it, and did we do it well?

Understanding the four questions and what different methodologies emphasize helps you use any approach more effectively. And that’s the real goal — not choosing the “right” methodology, but democratizing threat modeling so every team can apply the discipline that enterprises have had to rely on expensive consultants to access.

Getting started with methodologies

If you’re new to threat modeling, here’s a practical path:

1. Start with STRIDE. Learn the six categories. Apply them to a simple system. Get the feel for systematic threat identification.
2. Add attack trees for high-value targets. Once you understand the basics, use attack trees to deeply analyze your most critical assets.
3. Integrate business context. Over time, connect findings to business impact — pulling in PASTA’s risk-centric thinking.
4. Let your team’s practices evolve. The “best” methodology for your organization will emerge from what works in your context.

The frameworks are tools for thinking, not substitutes for it. Use them to structure your thinking, but remain focused on the core question: are we identifying the real risks in our architecture?

---

Ready to apply the right threat modeling methodology to your systems? Learn more about how threat modeling fits your security architecture, or discover how we built ThreatKrew. Ready to get started? Explore the automated threat modeling tool or join the Founders Program to see how it helps your team find risks faster.