STRIDE finds threats bottom-up from a diagram; PASTA works top-down from business risk, and attack trees decompose a single goal. Learn when each fits and how to map the full attack surface.
PASTA (Process for Attack Simulation and Threat Analysis) is a seven-stage methodology that starts from business objectives and ends at prioritized, evidence-backed risk. Where STRIDE is a fast per-element checklist, PASTA is a heavier process you reach for on high-stakes systems (payments, health, critical infra) where you must connect technical threats to business impact for leadership.
PASTA — 7 stages, business -> attacker -> risk:
1. Define objectives what the business needs to protect
2. Define tech scope the actual architecture + dependencies
3. Decompose the app DFDs, trust boundaries (same as STRIDE)
4. Threat analysis threat intel: who attacks systems like ours
5. Vulnerability analysis map threats to real weaknesses (CVEs, flaws)
6. Attack modeling attack trees — how they'd chain it together
7. Risk & impact prioritize, tie each to business impact
Use STRIDE for speed on most features; escalate to PASTA when the
blast radius justifies the cost.An attack tree takes a single attacker goal as the root and breaks it into the alternative ways to achieve it (OR nodes) and the steps each requires (AND nodes). It is the right tool when you want depth on one scary outcome — "steal the signing key," "move money" — rather than breadth across a diagram. Leaves become the specific controls you must test.
GOAL: Read another user's private photo
├── OR Guess/enumerate the object URL
│ └── AND public bucket + predictable key
├── OR Abuse the API's authz
│ └── AND valid session + API doesn't check ownership (IDOR)
├── OR Compromise the CDN cache
│ └── AND cache key ignores auth + poison a shared entry
└── OR Get the storage credentials
└── OR leaked in git OR over-broad IAM role on the worker
Each leaf is a test case: "does the API check ownership?", "is the
bucket public?", "is the IAM role scoped?" — that's your pen-test plan.Attack surface mapping is the inventory step: enumerate every reachable entry point and rank by exposure. A threat you never mapped is a threat you never modeled. Combine architectural knowledge (the DFD) with discovery tooling so the map reflects reality, including the endpoints nobody documented.
Enumerate every place untrusted input/actor can reach the system:
Network public IPs, open ports, load balancers, exposed admin panels
App every route/endpoint, params, headers, file uploads, webhooks
Identity auth flows, password reset, OAuth callbacks, API keys
Supply dependencies, base images, the CI/CD pipeline itself
Cloud public buckets, over-broad IAM, metadata endpoints (SSRF)
Discovery that keeps the map honest (authorized scope only):Use lightweight discovery to validate your map against what is actually exposed — always within a system you own or are explicitly authorized to test. These are reconnaissance basics that overlap with the Penetration Testing course; here the goal is completeness of the model, not exploitation.
Authorization required — Only run scanning/discovery against assets you own or have written permission to test. Unauthorized scanning is illegal in most jurisdictions.# What ports/services does this host actually expose?
nmap -sV --top-ports 1000 app.internal.example.com
# What routes does the app expose? (from your own OpenAPI / route table first)
curl -s https://app.example.com/openapi.json | jq '.paths | keys'
# Subdomain / asset sprawl you forgot about (own domains only)
# (many teams find a staging box with prod data this way)
dig +short app.example.com
# TLS + headers posture in one shot
curl -sI https://app.example.com | grep -iE 'strict-transport|content-security|x-frame'