Why Your Threat Model Needs More PASTA?

Aastha Thakker
Dec 27, 2025
4 min read

Merry Christmas! While most of us are busy eyeing that plump fruitcake, everyone knows the real truth, Aastha loves Pasta. Since it’s the season of full filling, let’s serve up something a bit more than your standard security checklist. We’re talking about the PASTA threat model. It’s a bit more “fine-dining” and far less mainstream than the usual STRIDE or DREAD frameworks you see everywhere.

If you’re still catching up on the basics like what Cyber Threat Intelligence (CTI) actually is or how STRIDE and DREAD work, check out my previous blog here.

So, what exactly is PASTA?

It stands for Process for Attack Simulation and Threat Analysis. It was cooked up back in 2015 by Tony UcedaVélez and Marco M. Morana because they realized most security models were too technical and ignored the one thing bosses actually care about: The Business.

It shifts the focus from “What is broken?” to “What matters most to the business?”

Why PASTA? (Process for Attack Simulation and Threat Analysis)

In the field, we often get stuck in a “check-the-box” mentality. PASTA reverses the priority. It’s a risk-centric framework, meaning it doesn’t just look at what could go wrong; it looks at what matters to the business.

It consists of seven stages that align technical threats with business objectives:

1. Define Objectives:

What are we protecting and why? Before we talk about firewalls, we talk about money and reputation. If you’re a bank, it’s the vault. If you’re a hospital, it’s patient lives.

This phase identifies:

Business processes
Crown jewels (critical assets)
Regulatory obligations (PCI-DSS, HIPAA, RBI, GDPR)
Acceptable risk thresholds

2. Define Technical Scope:

Mapping the attack surface.

Here, the entire attack surface is mapped, including:

Applications (web, mobile, APIs, microservices)
Infrastructure (cloud/on-prem, networking layers)
Third-party integrations
Identity systems
Data stores & external trust boundaries

You can’t defend what you can’t see.

3. Application Decomposition:

Breaking the app down to see how data flows. We map out how data travels from the user’s thumb to the database.

This stage breaks the application into:

Components and microservices
Trust boundaries
Data flow diagrams (DFD)
Authentication and authorization points
Data classification paths (PII, financial, confidential)

4. Threat Analysis:

This stage leverages:

Cyber Threat Intelligence (CTI)
MITRE ATT&CK mapping
Known attack campaigns
Industry-specific threat landscapes

Questions asked:

Who are the threat actors?
What capabilities do they have?
What attack vectors are most realistic?

This ensures we are not imagining threats — we are modeling threats attackers are actually using in the real world.

5. Vulnerability Detection:

Now we connect threats to real technical weaknesses, using:

SAST / DAST
API security testing
Cloud misconfiguration scans
Penetration testing
Configuration audits

The result is evidence-backed weaknesses such as:

weak authentication controls
insecure session handling
API exposure
misconfigured cloud storage
unpatched components

This turns theory into exploitable technical reality.

6. Attack Modeling:

Here we construct:

Attack trees
Kill chains
Exploitation sequences
Multi-step threat paths

Example thinking: "If an attacker has stolen credentials AND there is weak MFA AND APIs are unrestricted → what is the maximum blast radius?”

This converts vulnerabilities into practical attack scenarios, reflecting how adversaries chain weaknesses instead of using them in isolation.

7. Risk & Impact Analysis:

Finally, we quantify:

Technical impact
Financial loss projections
Operational disruption
Legal exposure
Reputational consequences

Risk is evaluated using measurable metrics such as:

likelihood vs impact
potential monetary loss
compliance penalties
downtime severity

This allows leadership to prioritize fixes not emotionally, but strategically, ensuring resources address the threats that can truly cripple the organization.

The PASTA Table: Who’s Sitting Where?

One of the biggest hurdles in cybersecurity is getting different departments to speak the same language. PASTA solves this by giving every stakeholder a specific “seat at the table” with clear benefits.

Business Managers: They stop seeing security as a “cost center” and start seeing it as a way to bake in requirements that protect the bottom line.
Architects: Instead of guessing, they get a blueprint of design flaws and see exactly how their countermeasures shield the organization’s data assets.
Developers: They gain a realistic view of how their code is exposed, making “secure coding” a tangible goal rather than a vague instruction.
Testers: They can move beyond generic scans and use abuse cases to run targeted tests that mimic real-world exploitation.
Project Managers: Security defects are no longer “surprises” at the end of a sprint; they can manage and prioritize them efficiently throughout the lifecycle.
CISOs: They get the high-level data needed to make informed risk management decisions that they can actually defend to the board.