Understanding the 7 Stages of PASTA Threat Modeling

PASTA (Process for Attack Simulation and Threat Analysis) is often described as a self-contained, seven-stage sequence. In mature practice, it functions less as a closed method and more as connective tissue between other named standards and frameworks, each entering at a specific stage: business impact analysis at the start, MITRE ATT&CK during threat analysis, CVE and exploitability data during vulnerability analysis, attack trees during attack modeling, and quantitative risk models at the end. This paper examines PASTA threat modeling stage by stage through that lens, uses adoption data on one of these inputs to ground the argument concretely, and closes by naming a real tension: a PASTA process integrating this many external inputs is a substantially different undertaking than a lightweight version run by a small team.

Introduction

Most descriptions of PASTA threat modeling present its seven stages as a self-sufficient method: define objectives, define scope, decompose the application, analyze threats, analyze vulnerabilities, model attacks, assess risk and impact. This is accurate as a description of the methodology’s structure, but it understates how the method is actually practiced by mature security teams, where each stage typically pulls in a specific external standard or data source rather than generating its analysis from first principles.

This paper walks through PASTA’s seven stages organized around that integration, specifying what a well-run instance of each stage typically draws on. It covers the early, business-defining stages, application decomposition, threat analysis and its relationship to MITRE ATT&CK, grounded in adoption data, vulnerability analysis and exploitability data, attack modeling, risk and impact analysis, and quantitative risk models, names the tension this integration creates, and states this paper’s limitations.

Stages 1 and 2: What Feeds the Business Case

PASTA’s first stage, definition of objectives, and second stage, definition of technical scope, are where the methodology’s risk-centric claim originates, and in mature practice these stages draw on business impact analysis techniques, borrowed from business continuity planning, to quantify what a compromise would actually cost. They also draw on existing compliance requirement mappings, asset inventories, and configuration management data that most regulated organizations already maintain for other purposes. A PASTA process that starts these stages from a blank page, rather than pulling from artifacts the organization already has, is redoing work rather than integrating it.

Stage 3: What Feeds the Architecture Model

Application decomposition depends on having an accurate data flow diagram and a clear map of trust boundaries, and mature practice typically draws this from existing architecture documentation and diagramming conventions rather than reconstructing the system from scratch during the threat modeling exercise itself. Where that documentation is stale or incomplete, and it very often is in fast-moving development environments, this stage’s quality is capped by the quality of the architecture artifacts feeding it, regardless of how carefully the subsequent stages are executed.

Stage 4: Where MITRE ATT&CK Enters

Threat analysis, PASTA’s fourth stage, is where the methodology asks which adversaries and techniques are actually plausible against the system just decomposed. In current practice, MITRE ATT&CK, the widely adopted knowledge base of adversary tactics and techniques grounded in real-world observations, is the dominant external input at this stage. A joint study by UC Berkeley’s Center for Long-Term Cybersecurity and McAfee found that more than 80 percent of surveyed enterprises use ATT&CK in some form, and among adopters, 54 percent specifically report using it for threat modeling.

This adoption figure is worth reading alongside a caution from the same study: 81 percent of surveyed security professionals report experiencing the tactics and techniques cataloged in ATT&CK’s cloud matrix on a regular basis, but fewer than half report full confidence in their existing tools’ ability to detect them. Threat analysis correlating against ATT&CK identifies which techniques are plausible; it does not, on its own, confirm that the organization’s defenses can actually catch them, which is a separate and later concern this paper returns to.

Stage 5: Where CVE, CVSS, and Exploitability Data Enter

Weakness and vulnerability analysis, PASTA’s fifth stage, is where identified vulnerabilities get mapped against the threats established in stage four. Mature practice at this stage increasingly incorporates exploitability data, not just published vulnerability severity, since prior analysis has found that fewer than 5 percent of published CVEs are ever confirmed exploited in the wild, and that raw CVSS severity is a poor predictor of which vulnerabilities attackers actually use. A stage 5 analysis that ranks findings by CVSS score alone, without incorporating exploitability signals such as EPSS or known-exploited-vulnerability catalogs, inherits the same weakness a checklist-only approach to threat modeling has elsewhere in this methodology: it produces a defensible-looking severity ranking that doesn’t reliably track real attacker behavior.

Stage 6: Where Attack Trees and Adversarial Validation Enter

Attack modeling, PASTA’s sixth stage, is where hypothesized attack paths get structured and, in the strongest implementations, tested. Attack trees, which decompose an attack goal into the sequence of steps required to achieve it, are the most common structuring technique at this stage. The step that separates a theoretical attack tree from a validated one is adversarial testing, red teaming, or penetration testing against the specific hypothesized path, which is also where the confidence gap noted- security professionals doubting their tools’ detection capability- gets tested directly rather than left as an open question.

Stage 7: Where Quantitative Risk Models Enter

Risk and impact analysis, PASTA’s final stage, is meant to translate validated attack paths into business-relevant risk figures. Frameworks such as FAIR (Factor Analysis of Information Risk) and the risk assessment methodology in NIST Special Publication 800-30 provide structured, quantitative approaches to this translation, expressing risk in terms of probable financial loss or a standardized qualitative scale rather than an ad hoc severity label assigned by whoever is running the analysis. A stage 7 that skips this structure and assigns high, medium, or low labels by intuition reintroduces exactly the analyst-to-analyst inconsistency problem prior work on PASTA has identified as a persistent weakness of risk-centric methodologies generally.

The Integration Tension: Rigor Versus Scope

Describing PASTA’s seven stages this way, each drawing on a named external framework, makes the methodology sound more rigorous, and in a well-resourced implementation, it is. It also makes clear that a fully integrated PASTA process, incorporating business impact analysis, current architecture documentation, MITRE ATT&CK correlation, exploitability-informed vulnerability analysis, validated attack trees, and a quantitative risk model, is a substantially heavier undertaking than the seven-stage outline suggests on its own. A small application security team running PASTA against a large portfolio is unlikely to fully integrate all six external inputs at every stage for every system, and the methodology’s own documentation does not specify a minimum viable subset. This is a real, unresolved tension between doing PASTA thoroughly and doing it consistently across everything an organization needs modeled.

Limitations and Open Questions

The adoption data in MITRE ATT&CK Enters and measures MITRE ATT&CK use in general security operations, not usage specifically within a PASTA-based threat modeling process; the 54 percent figure indicates threat modeling broadly, not PASTA by name, and this paper’s application of it to PASTA’s fourth stage specifically is an inference, not a direct measurement.

Second, the associations drawn between PASTA’s stages and frameworks like FAIR, NIST SP 800-30, and structured attack trees are based on common practice and methodology literature rather than a survey measuring how many organizations actually pair these specific frameworks with PASTA by name. No dataset cited in this paper measures integration rates for those pairings directly.

Third, the tension is stated but not resolved. This paper does not have data on how many organizations run a fully integrated, six-input version of PASTA versus a lighter version incorporating only some external frameworks, nor does it have outcome data comparing the two. It is plausible that a lighter, less integrated version still outperforms no threat modeling at all, but this paper does not establish that comparison empirically.

Conclusion

PASTA threat modeling’s seven stages, examined individually, each have a natural point of integration with another named standard or framework: business impact analysis and compliance mapping at the start, architecture documentation feeding decomposition, MITRE ATT&CK during threat analysis, exploitability data during vulnerability analysis, attack trees and adversarial validation during attack modeling, and quantitative risk models such as FAIR or NIST SP 800-30 at the end. Adoption data on MITRE ATT&CK specifically indicates this kind of integration is already common practice for at least one stage, with 54 percent of adopting organizations using the framework for threat modeling directly. Whether organizations integrate the remaining five inputs as consistently is not established by available data, and the resulting tension between thorough, fully integrated PASTA and consistent, scalable PASTA across a large portfolio remains an open, unresolved question.

References

1. UcedaVélez, T., and Morana, M.M. Risk Centric Threat Modeling: Process for Attack Simulation and Threat Analysis. Wiley, 2015.
2. Center for Long-Term Cybersecurity, UC Berkeley, and McAfee. MITRE ATT&CK adoption study.
3. MITRE. MITRE ATT&CK® (attack.mitre.org) and MITRE ATT&CK Advisory Council announcement, February 2026.
4. FAIR Institute. Factor Analysis of Information Risk (FAIR) standard.
5. National Institute of Standards and Technology. NIST Special Publication 800-30: Guide for Conducting Risk Assessments.

Frequently Asked Questions