Threat Modeling for Applications: STRIDE, PASTA, and ATT&CK
Most application security programs focus on finding vulnerabilities in code that has already been written. Threat modeling finds the design-level flaws that created those vulnerabilities before a single line of code exists — making fixes orders of magnitude cheaper and more complete. A buffer overflow patched in production is fixed in one place; an authentication design flaw identified before implementation is fixed everywhere it would have appeared. This guide covers the three most widely used threat modeling methodologies, how to run a threat modeling session, and how to make it a routine part of the software development lifecycle without creating a compliance theater exercise.
When to Threat Model: The Right Points in the SDLC
Threat modeling delivers the most value when it influences design decisions — not after architecture is locked. The right trigger points are:
New system or significant new feature
Any new user-facing feature, API endpoint, or system integration is a threat modeling trigger. The session scope is the feature's data flows and trust boundaries, not the entire system.
Infrastructure or architecture changes
Moving from monolith to microservices, adding a cloud component, changing authentication flows, or introducing a new data store are architecture changes that require updated threat models.
Third-party integrations
Integrating with an external API, SDK, or vendor service introduces a new trust boundary. Threat model the integration before building it: what data crosses the boundary, what happens if the third party is compromised.
Threat landscape changes
New attack techniques relevant to your technology stack — even without code changes — can change the risk profile of existing systems. Periodic review of existing threat models against current threat intelligence is the mature practice.
STRIDE: Structured Threat Categories for System Design
STRIDE is a mnemonic developed by Microsoft for systematically categorizing threats against a system design. Each letter represents a threat category mapped to a violated security property. Applied to each component and data flow in a system diagram, STRIDE ensures comprehensive coverage without relying on analyst intuition alone.
S — Spoofing (violates Authentication)
Can an attacker impersonate a user, service, or system component? Examples: forged JWT tokens, session hijacking, ARP spoofing, DNS cache poisoning. Mitigations: strong authentication, certificate pinning, mutual TLS.
T — Tampering (violates Integrity)
Can an attacker modify data in transit or at rest? Examples: SQL injection, parameter tampering, man-in-the-middle modification, insecure deserialization. Mitigations: input validation, cryptographic integrity checks, digital signatures.
R — Repudiation (violates Non-repudiation)
Can a user deny performing an action without the system being able to prove otherwise? Examples: no audit logging, log tampering, anonymous operations on sensitive resources. Mitigations: comprehensive audit logging, tamper-evident logs, digital signatures on critical operations.
I — Information Disclosure (violates Confidentiality)
Can an attacker access data they should not? Examples: IDOR, verbose error messages leaking stack traces, unencrypted sensitive data, directory traversal. Mitigations: encryption at rest and in transit, proper access controls, minimal error response verbosity.
D — Denial of Service (violates Availability)
Can an attacker disrupt service availability? Examples: resource exhaustion, amplification attacks, lock-out attacks, unthrottled API endpoints. Mitigations: rate limiting, circuit breakers, resource limits, WAF rules.
E — Elevation of Privilege (violates Authorization)
Can an attacker gain permissions beyond what they were granted? Examples: BOLA/IDOR, JWT algorithm confusion, path traversal to privileged files, insecure direct object references. Mitigations: authorization checks on every action, principle of least privilege, deny-by-default access control.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
PASTA: Risk-Centric Threat Modeling
Process for Attack Simulation and Threat Analysis (PASTA) is a seven-stage, risk-centric methodology that aligns threat modeling output to business risk rather than technical vulnerability cataloging. PASTA is more comprehensive than STRIDE but requires more time investment — appropriate for high-value systems or compliance-driven programs.
Stage 1 — Define business objectives
Identify what the application does, what business processes it supports, what data it handles, and what the business impact of a breach would be. This stage grounds the threat model in business risk rather than abstract technical concerns.
Stage 2 — Define technical scope
Enumerate application components, infrastructure dependencies, data flows, and trust boundaries. Create the data flow diagram (DFD) that subsequent stages will analyze.
Stage 3 — Application decomposition
Break down the application into subsystems, APIs, data stores, and external services. Identify entry points, exit points, assets, and trust levels.
Stage 4 — Threat analysis
Using the application decomposition, identify threats relevant to each component. Reference threat intelligence sources and vulnerability databases for threats applicable to the technology stack.
Stage 5 — Vulnerability analysis
Map identified threats to specific vulnerabilities in the application design. This stage produces the specific weaknesses that need to be addressed — not abstract threat categories.
Stage 6 — Attack modeling
Develop attack trees for the most significant threat-vulnerability pairs. Attack trees model how an attacker would chain multiple steps to reach a high-value target.
Stage 7 — Risk and impact analysis
Score each identified risk by likelihood and business impact. Prioritize remediation by risk score. Produce output tied to business impact that stakeholders can act on.
ATT&CK-Based Threat Modeling
MITRE ATT&CK provides a third approach: using known adversary TTPs as the threat catalog rather than abstract threat categories. ATT&CK-based threat modeling asks 'which techniques would a relevant threat actor use against this system?' rather than 'what abstract threats apply to this component?'
Threat actor profiling
Identify threat actors relevant to your industry and application type. ATT&CK Groups profiles document which techniques each threat actor group has used. A financial services application should consider FIN7, APT38, and Scattered Spider; a defense contractor should consider Volt Typhoon and APT10.
Technique mapping to application components
For each application component, identify which ATT&CK techniques could be applied to it. An authentication endpoint is a target for T1110 (Brute Force), T1078 (Valid Accounts), and T1566 (Phishing). An admin API is a target for T1548 (Abuse Elevation Control Mechanism) and T1190 (Exploit Public-Facing Application).
Defensive control mapping
Map existing and planned security controls to the identified techniques. Gaps — techniques with no mitigating control — become the remediation backlog. This approach produces threat model output that directly maps to detection requirements for the SOC.
When to use ATT&CK-based modeling
ATT&CK-based modeling is most appropriate for high-value targets with known threat actor interest, red team planning, and detection engineering. STRIDE remains faster for routine feature-level threat modeling in development teams.
Running a Threat Modeling Session
A threat modeling session is a structured workshop that produces actionable security requirements and a prioritized list of threats to mitigate.
“A threat model that does not produce work items is a document, not a security program. The session output must be tracked to closure.”
Adam Shostack, Threat Modeling: Designing for Security
Participants
The essential participants are: a developer or architect who understands how the system works, a security engineer who knows threat categories and mitigations, and a product owner who understands business context. Additional participants (QA, ops) add value but four to six people is the productive maximum.
Start with the data flow diagram
Begin the session by drawing or reviewing the system's data flow diagram. The DFD shows processes, data stores, external entities, and data flows between them, with trust boundaries marked. The DFD is the artifact that the STRIDE analysis is applied to. Spend the first 20-30 minutes of the session achieving consensus on the DFD before any threat analysis.
Apply STRIDE to each element
Systematically work through each process, data store, and data flow in the DFD, applying each STRIDE category. Generate threats using the question format: 'An attacker could [STRIDE category] by [specific attack].' Record every threat generated, even implausible ones — prioritize after generation.
Rate and prioritize
Score each threat by likelihood (how feasible is the attack given current controls?) and impact (what is the business consequence if it succeeds?). Use DREAD scoring or a simple High/Medium/Low matrix. Focus remediation effort on High/High threats.
Assign mitigations and track
For each prioritized threat, assign a mitigation (specific control or design change), an owner, and a deadline. Feed unmitigated threats into the security backlog as user stories. The threat model is only valuable if it produces tracked work items.
Integrating Threat Modeling into the SDLC
Threat modeling done as a one-time activity produces diminishing returns as the system evolves. Integration into the SDLC makes it continuous.
Threat model as a design document gate
Require a threat model (even a lightweight one-page version for small features) before a new feature enters the development sprint. Security review at design time is faster than code review and prevents fundamental flaws from being built.
Automated threat modeling tooling
Microsoft Threat Modeling Tool, OWASP Threat Dragon, and IriusRisk provide diagram-based threat modeling environments that apply STRIDE automatically from DFD inputs. These tools lower the barrier to threat modeling in development teams that do not have a dedicated security engineer.
Threat model updates on significant changes
Treat the threat model as a living document. When the architecture changes, the authentication system is updated, or a new integration is added, update the threat model. Stale threat models provide false confidence.
Security requirements from threat models
Convert threat model findings directly into testable security requirements. 'The authentication endpoint must enforce rate limiting of 10 requests per minute per IP' is a testable security requirement derived from a Denial of Service threat. This bridges threat modeling output to security test cases.
The bottom line
Threat modeling is the highest-leverage application security activity because it identifies and fixes design-level flaws before they are implemented. STRIDE provides systematic coverage for feature-level sessions; PASTA provides business-risk-aligned output for high-value systems; ATT&CK-based modeling connects threat models to detection requirements and red team planning. The key to making threat modeling stick is integration into the development workflow — not as a compliance checkbox, but as the design review that every significant feature receives before implementation begins.
Frequently asked questions
What is threat modeling?
Threat modeling is a structured process for identifying and prioritizing potential security threats to a system before they are built in or exploited. It involves creating a model of the system (typically a data flow diagram), identifying threats against each component using a methodology like STRIDE, assessing the risk of each threat, and defining mitigations. The goal is to find design-level security flaws when they are cheap to fix — at design time — rather than after implementation.
What is the difference between STRIDE and PASTA?
STRIDE is a threat category mnemonic (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) applied systematically to a system data flow diagram. It is fast, structured, and accessible to development teams. PASTA (Process for Attack Simulation and Threat Analysis) is a seven-stage risk-centric methodology that aligns threat model output to business risk and produces attack trees. PASTA is more comprehensive and appropriate for high-value systems or compliance programs; STRIDE is more practical for routine feature-level threat modeling in agile development.
Who should participate in a threat modeling session?
Core participants: a developer or architect who knows how the system works, a security engineer who knows threat categories and attack patterns, and a product owner who understands business context and data sensitivity. Additional participants (QA, operations, data privacy) add value. Keep sessions to four to six people maximum — larger groups slow the process without proportionate benefit. The session facilitator is typically the security engineer.
How long does a threat modeling session take?
A focused threat modeling session for a single feature or API typically takes 2-4 hours. A full system threat model for a new application can take 1-2 days across multiple sessions. The largest time investment is usually building consensus on the data flow diagram — the analysis moves faster once the diagram is accurate. For ongoing programs, feature-level threat models in agile teams should fit within a 2-hour timebox.
What is a data flow diagram (DFD) and why is it important for threat modeling?
A data flow diagram shows how data moves through a system: external entities (users, third-party services), processes (application components, APIs), data stores (databases, caches, file systems), and the data flows connecting them. Trust boundaries — lines where security assertions change, such as the boundary between the internet and internal network — are marked on the DFD. The DFD is the object that STRIDE analysis is applied to; without it, threat modeling produces generic threats rather than specific, actionable findings tied to the actual system design.
How does threat modeling integrate with agile development?
In agile development, threat modeling is applied at the feature level rather than the system level. Each significant new feature (new API endpoint, authentication change, data integration) triggers a lightweight threat modeling session during design — before the development sprint begins. The session produces security requirements as user stories added to the sprint backlog. Larger architectural changes trigger more comprehensive threat modeling sessions. The key is making it a routine gate in the design process, not an exceptional activity.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, weekly, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals weekly.
The Mythos Brief is free.
AI that finds 27-year-old zero-days. What it means for your security program.