HOW-TO GUIDE | APPLICATION SECURITY
Active Threat11 min read

Threat Modeling Guide: STRIDE, PASTA, and Practical Implementation

64%
Of security vulnerabilities are design flaws, not implementation bugs
30x
More expensive to fix a security flaw in production than in design
2 hrs
Typical time investment for a lightweight sprint threat model
85%
Of OWASP Top 10 vulnerabilities are detectable via threat modeling

Most security vulnerabilities are not bugs introduced during coding — they are design flaws that could have been identified and fixed before a line of code was written. Threat modeling is the practice of systematically identifying security-relevant design decisions and their failure modes early in the development lifecycle, when changes are cheapest and most effective.

The challenge is making threat modeling practical for engineering teams working in agile cycles with two-week sprints, not the six-month waterfall design phases where formal threat modeling methodologies were originally developed. This guide covers the methodologies, tooling, and lightweight integration approaches that make threat modeling sustainable in modern development environments.

Free daily briefing

Briefings like this, every morning before 9am.

Threat intel, active CVEs, and campaign alerts — distilled for practitioners. 50,000+ subscribers. No noise.

STRIDE: The Foundation Methodology

STRIDE is a threat classification framework originally developed at Microsoft that provides a structured approach to identifying threats by category. Each letter represents a threat class:

Spoofing: Impersonating users, services, or systems (e.g., an attacker claiming to be an authenticated user). Defense: authentication, signatures. Tampering: Unauthorized modification of data (e.g., altering data in transit or in storage). Defense: integrity controls, hashing, access controls. Repudiation: Denying having performed an action (e.g., a user denying a fraudulent transaction). Defense: audit logging, non-repudiation mechanisms. Information Disclosure: Exposing data to unauthorized parties (e.g., verbose error messages revealing stack traces). Defense: encryption, access controls, data classification. Denial of Service: Making a system unavailable (e.g., overwhelming a rate-limited API endpoint). Defense: rate limiting, resource quotas, redundancy. Elevation of Privilege: Gaining higher permissions than intended (e.g., a regular user accessing admin functions). Defense: least privilege, authorization checks.

Apply STRIDE by drawing a data flow diagram of your system and systematically asking each STRIDE category question at every trust boundary, data store, process, and external entity. The value is in the systematic coverage — STRIDE ensures you do not forget to ask about repudiation or denial of service, which teams often skip in informal security reviews.

Building Useful Data Flow Diagrams

A Data Flow Diagram (DFD) is the foundation of threat modeling. It maps how data moves through your system, which components process it, where it is stored, and — most importantly — where trust boundaries exist. Trust boundaries are the lines in a DFD where data crosses from a higher-trust context to a lower-trust context (or vice versa), and they are where most threats manifest.

DFD components: External entities (users, third-party services, data sources that are outside your trust boundary), processes (code that transforms or routes data), data stores (databases, caches, files, message queues), and data flows (the movement of data between components). Trust boundaries are drawn as dashed lines separating zones of different trust levels.

Practical DFD guidance: Start at the right level of abstraction. A Level 0 DFD shows your entire system as a single process interacting with external entities — useful for scoping. Level 1 DFDs break the system into major components and show the flows between them — the right level for most threat modeling exercises. Level 2 DFDs show individual functions within components — appropriate for deep dives on specific high-risk areas. Do not over-engineer the diagram; a whiteboard sketch that captures trust boundaries is more useful than a perfect Visio document delivered after the sprint.

PASTA: Process for Attack Simulation and Threat Analysis

PASTA is a risk-centric, seven-stage threat modeling methodology designed for enterprise-scale application security programs. Where STRIDE focuses on threat classification, PASTA focuses on business risk and attacker motivation — it asks not just 'what threats exist' but 'which threats are most likely to be exercised by real attackers given the value of this asset.'

PASTA's seven stages: (1) Define business objectives — what are the business and compliance requirements for this application? (2) Define technical scope — application architecture, data flows, dependencies. (3) Application decomposition — similar to DFD construction in STRIDE. (4) Threat analysis — what threat actors would target this application and what are their capabilities? (5) Vulnerability and weakness analysis — what design and implementation weaknesses exist? (6) Attack modeling — map specific attack patterns to identified weaknesses using attack trees or CAPEC. (7) Risk and impact analysis — score residual risk against business context and prioritize remediation.

PASTA is more thorough than STRIDE but requires more time and security expertise to execute. It is most appropriate for high-risk applications (payment processing, health data, authentication infrastructure) where the additional rigor is justified. For most sprint-level feature reviews, a STRIDE-based approach with DFDs is more practical.

Integrating Threat Modeling into Agile Development

The most common reason threat modeling fails in organizations is that it is treated as a heavyweight gate rather than a lightweight, continuous practice. The goal is not a perfect threat model — it is threat modeling as a habit that improves the security posture of every feature shipped.

Lightweight integration approach: (1) Trigger threat modeling on new features, architecture changes, and security-sensitive modifications (authentication, authorization, data storage, external integrations) — not every ticket. (2) Timebox the exercise to two hours maximum for a sprint-level threat model. (3) Use a structured but minimal template: a sketch DFD, a STRIDE walkthrough at each trust boundary, and an output list of threats with assigned owners and remediation status. (4) Track findings in your existing issue tracker alongside functional requirements — not in a separate security database that no one looks at.

Tooling: OWASP Threat Dragon is a free, open-source threat modeling tool that generates DFDs and automatically maps STRIDE threats to data flow elements. Microsoft Threat Modeling Tool is free and includes built-in templates for common Azure architectures. IriusRisk is the most capable commercial option for organizations that need to automate threat model generation from architecture descriptions at scale.

Subscribe to unlock Remediation & Mitigation steps

Free subscribers unlock full IOC lists, remediation steps, and every daily briefing.

The bottom line

Threat modeling is the highest-leverage application security activity available to development teams — it finds design-level flaws before they become production vulnerabilities, at a fraction of the cost of post-deployment remediation. STRIDE with DFDs is the practical starting point for most teams. The goal is consistency at the sprint level, not comprehensiveness at the release level. Any team that does threat modeling on every significant feature ships more secure software than a team that does a comprehensive threat model once a year.

Frequently asked questions

Who should participate in a threat modeling session?

The most effective threat modeling sessions include the architect or senior developer who designed the system (to answer technical questions accurately), a security engineer (to guide the STRIDE/PASTA methodology and identify threats the development team might miss), and ideally a representative from the business or product team (to provide context on data sensitivity and business risk). Sessions with more than five people tend to become unproductive — keep it small and focused.

What is the difference between STRIDE and PASTA?

STRIDE is a threat classification framework that helps teams enumerate threats systematically by category. PASTA is a complete risk-based threat modeling process that incorporates business objectives, attacker modeling, and risk quantification. STRIDE is easier to learn and execute quickly; PASTA is more thorough but requires more expertise and time. Most teams start with STRIDE and graduate to PASTA for their highest-risk applications.

Should threat modeling be done before or during coding?

Ideally before coding begins for new features — the earlier in the development lifecycle, the cheaper the fix. For ongoing development, threat modeling should trigger at the design review phase before significant architectural changes are implemented. Retrofitting threat models onto existing systems is still valuable but is more of an audit exercise (identifying accumulated design debt) than a proactive control.

What is an attack tree and how does it relate to threat modeling?

An attack tree is a hierarchical diagram that represents the ways an attacker could achieve a specific goal (the tree root). Each branch represents an alternative method or sub-goal. Attack trees are a complement to DFD-based threat modeling — where DFDs identify where threats could manifest, attack trees detail how specific threats could be executed. They are particularly useful in PASTA's attack modeling stage and for analyzing complex, multi-step attack scenarios like account takeover or data exfiltration.

Sources & references

  1. OWASP Threat Modeling Cheat Sheet
  2. Microsoft STRIDE Threat Modeling
  3. NIST SP 800-154: Guide to Data-Centric System Threat Modeling

Free resources

25
Free download

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.

No spam. Unsubscribe anytime.

Free download

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.

No spam. Unsubscribe anytime.

Free newsletter

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.

Eric Bang
Author

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.

Daily Briefing

Get briefings like this every morning

Actionable threat intelligence for working practitioners. Free. No spam. Trusted by 50,000+ SOC analysts, CISOs, and security engineers.

Unsubscribe anytime.

Get tomorrow's threat briefing before your inbox does.