# PASTA Threat Model
PASTA (Process for Attack Simulation and Threat Analysis) is a seven-stage, risk-centric threat modeling methodology that connects business objectives to attack simulation through a structured, evidence-based process. It exists because most threat modeling approaches answer the wrong question first: they catalog what could go wrong technically before establishing what matters to the business. PASTA corrects that sequence. By anchoring every stage of analysis to business impact, compliance obligations, and attacker motivation, PASTA produces threat models that security teams, executives, and auditors can all read from the same page. The methodology was developed by Tony UcedaVelez and Marco Morana and documented in "Risk Centric Threat Modeling," published in 2015. It is particularly well-suited for regulated industries and mature security programs that require traceability from individual vulnerabilities to quantified business risk.
---
PASTA is a process framework, not a threat taxonomy. That distinction matters. STRIDE is a taxonomy: it tells you what categories of threat to consider. PASTA is a process: it tells you in what order to think, what evidence to gather at each step, and how to connect technical findings to business consequences. The two are not mutually exclusive. Many practitioners apply STRIDE within PASTA's Stage 4 as one input to threat identification.
PASTA operates across seven defined stages, each producing artifacts that feed the next stage. The methodology is explicitly risk-centric, meaning every threat is evaluated not only for likelihood and technical severity but also for business impact. This makes it compatible with risk quantification frameworks such as FAIR (Factor Analysis of Information Risk) and with compliance regimes including PCI DSS, HIPAA, and SOC 2.
PASTA is not a vulnerability scanner, a penetration testing methodology, or a compliance checklist. It is a structured thinking process that uses outputs from those tools as inputs. It does not replace SAST, DAST, or threat intelligence platforms. It organizes and contextualizes what those tools produce.
Variants exist primarily in scope: PASTA can be applied at the application level, the system level, or the enterprise level. Application-level PASTA is most common and produces the most granular output. Enterprise-level PASTA is used during architecture reviews or large-scale digital transformation programs where the risk surface spans multiple interconnected systems. There is no abbreviated or "lite" version formally recognized in the methodology; organizations that skip stages produce incomplete risk pictures, not faster models.
---
PASTA's seven stages progress in a deliberate sequence. Skipping stages or running them in parallel degrades the output quality because each stage depends on artifacts from the previous one.
Stage 1: Define Business Objectives. The process begins before any technical analysis occurs. Security engineers meet with business owners, product managers, and legal or compliance teams to document what the application does for the business, what data it handles, what regulatory frameworks apply, and what the organization's risk appetite is. The output is a business impact profile. For a healthcare patient portal, Stage 1 would document HIPAA obligations, the sensitivity classification of patient health information, the financial and reputational consequences of a breach, and the acceptable risk threshold for availability disruptions.
Stage 2: Define Technical Scope. The technical environment is mapped: application architecture, hosting model (cloud, on-premises, hybrid), third-party integrations, authentication mechanisms, network segmentation, and the full technology stack. This stage produces an architectural overview that becomes the reference document for all subsequent stages. In the patient portal example, Stage 2 would document the web application tier, the API gateway, the EHR integration endpoints, the cloud-hosted database, and the identity provider.
Stage 3: Application Decomposition. Data flow diagrams (DFDs) are constructed to trace how data moves through the system, where trust boundaries exist, and what entry and exit points are available to both legitimate users and attackers. Use cases and abuse cases are written in parallel: for every legitimate action a user can take, analysts document the corresponding abusive action an attacker might attempt. For the patient portal, an abuse case might be: an unauthenticated attacker submits crafted input to the password reset endpoint to enumerate valid usernames. The decomposition stage reveals the attack surface in concrete, navigable terms.
Stage 4: Threat Analysis. With the attack surface defined, analysts identify threat agents: who might attack this system, what capabilities they have, and what their motivations are. This stage draws on threat intelligence sources including MITRE ATT&CK, industry-specific threat reports (such as Verizon's Data Breach Investigations Report), and internal incident history. Threat scenarios are constructed that describe the attacker, the attack path, the targeted asset, and the anticipated impact. For the patient portal, a realistic threat scenario might describe a financially motivated threat actor using credential stuffing against the login endpoint to access patient records for sale on criminal marketplaces.
Stage 5: Vulnerability and Weakness Analysis. Known vulnerabilities in the application's components are correlated with the threat scenarios developed in Stage 4. This stage uses SAST tool output, DAST scan results, dependency analysis, CVE data, and architectural design review findings. The critical task is correlation, not enumeration. A vulnerability matters in PASTA only if it is reachable by an identified threat agent via a documented attack path. An unpatched library in an internal admin tool with no external network exposure is assessed differently from the same vulnerability in an internet-facing API.
Stage 6: Attack Modeling. Attack trees or attack graphs are constructed to model how identified threat agents would chain together the vulnerabilities and weaknesses found in Stage 5 to achieve their objectives. This stage simulates the attacker's decision-making process. In the patient portal scenario, an attack tree might model the path from initial credential stuffing success through multi-factor authentication bypass (if weak MFA is present), to API enumeration, to bulk data extraction. Attack modeling is where PASTA earns its name: the simulation produces a prioritized list of attack paths ordered by feasibility and impact.
Stage 7: Risk and Impact Analysis. Each attack path is evaluated for business risk using the impact profile established in Stage 1. Controls are recommended for each high-priority attack path, and residual risk is documented. The output is a risk register entry that a CISO can present to a board, a compliance report that maps findings to regulatory controls, and a prioritized remediation backlog that engineering teams can act on. In the patient portal case, Stage 7 output might show that credential stuffing combined with weak MFA presents a high likelihood, high impact risk requiring immediate implementation of adaptive authentication and rate limiting.
A complete PASTA engagement for a moderately complex application typically takes two to four weeks with a cross-functional team. The artifacts produced persist as living documents that should be updated when the application changes materially.
The methodology requires specific expertise at different stages. Stage 1 business objective definition works best when led by someone with compliance and risk management background. Stages 2 and 3 require application architects or senior developers who understand the system's technical design. Stage 4 threat analysis benefits from threat intelligence expertise. Stages 5 and 6 need application security professionals who can read vulnerability scan output and construct attack scenarios. Stage 7 risk analysis requires someone who can translate technical findings into business language and quantified risk metrics.
Tool support varies by stage. Stage 3 application decomposition often uses Microsoft Visio, Lucidchart, or specialized threat modeling tools like Microsoft Threat Modeling Tool or OWASP Threat Dragon. Stage 4 threat analysis draws from commercial threat intelligence platforms, MITRE ATT&CK Navigator, or industry reports. Stage 5 vulnerability analysis consumes output from SAST tools (Checkmarx, Veracode, SonarQube), DAST tools (Burp Suite, OWASP ZAP), and dependency scanners (Snyk, WhiteSource). Stage 6 attack modeling may use attack tree software or general diagramming tools. Stage 7 risk analysis often feeds into GRC platforms (ServiceNow, Archer, MetricStream) or risk quantification tools that implement FAIR methodology.
---
Without a structured threat modeling process, security teams default to checklist-based security review: they verify that encryption is present, that authentication exists, that logging is configured. Checklists confirm the presence of controls. They do not evaluate whether those controls address the most probable attack paths against the specific application. The result is security theater: organizations can demonstrate compliance while remaining vulnerable to predictable, well-documented attacks.
PASTA matters because it inverts the failure mode. By starting with business context and attacker motivation before examining controls, PASTA identifies misalignment between what controls exist and what threats they actually face. Organizations that have conducted formal PASTA engagements consistently discover that their highest-priority remediation items were not flagged by automated scanning tools because they involved architectural weaknesses, not patchable software vulnerabilities.
A concrete consequence of skipping structured threat modeling can be seen in the pattern of API breaches documented in the 2023 Verizon Data Breach Investigations Report, which identified web application attacks as the leading breach pattern across most industries. The majority of these incidents involved API endpoints that were architecturally exposed but not covered by the organization's existing vulnerability scanning scope because the endpoints were undocumented or considered internal. A Stage 3 application decomposition in PASTA explicitly requires mapping all entry points, including internal and partner-facing APIs. Organizations that performed this step would have identified the exposure before attackers did.
The financial impact of this gap is measurable. The 2023 IBM Cost of a Data Breach Report shows that organizations with mature threat modeling practices (defined as formal, documented processes updated regularly) experienced average breach costs 30% lower than organizations without such processes. The cost difference stems primarily from faster detection and containment, not from prevention alone. When security teams understand their attack surface and have mapped likely attack paths, incident response becomes targeted rather than exploratory.
A common misconception about PASTA is that it is only appropriate for large enterprises with dedicated security architecture teams. This is incorrect. The methodology scales. A small development team conducting a two-day abbreviated PASTA workshop on a new application will produce more actionable risk information than a team that runs automated scans and calls the output a security review. The critical elements are the sequence and the cross-functional participation, not the headcount.
A second misconception is that PASTA replaces penetration testing. It does not. PASTA informs penetration testing by defining which attack paths are highest priority for validation. Penetration testers who receive a PASTA output as a scoping document produce more targeted, higher-value findings than those working from a bare IP range or URL list. The combination is more effective than either approach alone.
---
CDA approaches PASTA within the Planetary Defense Model (PDM) primarily through the RGA (Risk Governance and Assurance) domain, with material connections to VSD (Vulnerability and Security Design) and TID (Threat Intelligence and Detection). The connection to RGA is direct: PASTA's output is a risk register, and risk governance without structured threat modeling is opinion, not analysis.
CDA's methodology, Perpetual Compliance Assurance (PCA), operates on the principle that compliance is not an event; it is a state. This directly shapes how CDA positions PASTA engagements. Most organizations treat threat modeling as a project activity: something done before launch, documented in a PDF, and filed. CDA treats the PASTA artifacts as persistent, versioned documents that are updated in response to defined triggers: significant architectural changes, new regulatory requirements, material changes in the threat landscape, or integration of new third-party components. This transforms threat modeling from a point-in-time assessment into a continuous assurance function.
Operationally, CDA implements PASTA with three modifications to the standard methodology. First, Stage 1 business objectives are explicitly mapped to control frameworks (NIST CSF, CIS Controls, applicable regulatory standards) so that the risk profile and the compliance profile are unified from the beginning rather than reconciled at the end. Second, Stage 4 threat analysis is performed using current threat intelligence inputs refreshed on a defined cycle, not static reference documents, ensuring that threat scenarios reflect the actual threat actors active against the client's industry vertical. Third, Stage 7 outputs are formatted as structured risk register entries that integrate directly with the organization's GRC platform, making threat model findings visible to governance processes rather than confined to security team documentation.
CDA's PCA model also requires that PASTA findings be reviewed at defined intervals even when no material change has occurred. Quarterly reviews verify that threat scenarios remain current and that remediation commitments have been met. This cadence ensures that the threat model remains a living instrument rather than an artifact of a past project.
---
---
---