Threat Modeling: STRIDE, Attack Trees, and DFDs
Threat modeling is the proactive practice of identifying and prioritizing potential security threats during system design — before vulnerabilities reach production. Microsoft’s Security Development Lifecycle (SDL) mandates threat modeling for all feature work; the 2025 CISA Secure by Design pledge requires software manufacturers to publish threat models for their products. This guide covers the major threat modeling methodologies — STRIDE, PASTA, attack trees — along with data flow diagrams, risk assessment frameworks, and tooling.
STRIDE Methodology
STRIDE, developed by Microsoft in the 1990s, is the most widely taught threat modeling framework. The acronym categorizes six threat types.
Spoofing
Spoofing is impersonating a user, process, or system. Threats include: email spoofing (lack of DMARC/DKIM), IP address spoofing, session token theft, biometric presentation attacks. Mitigations: strong authentication (FIDO2, MFA), mutual TLS, session binding to TLS, and origin validation.
Tampering
Tampering is unauthorized modification of data or code. Threats include: SQL injection modifying database records, file descriptor manipulation, cache poisoning, and firmware modification. Mitigations: cryptographic integrity verification (digital signatures, HMACs), input validation, integrity monitoring (file integrity monitoring, WAF rules), and immutable infrastructure.
Repudiation
Repudiation occurs when a user denies performing an action without the system having evidence to prove otherwise. Threats include: performing unauthorized transactions without audit trail, deleting logs, and timing attacks on audit systems. Mitigations: tamper-proof audit logging (write-once storage, cryptographic log chaining), digital signatures on transactions, and continuous monitoring.
Information Disclosure
Information disclosure leaks data to unauthorized parties. Threats include: error messages revealing stack traces, verbose API responses exposing internal IDs, DLL side-loading reading configuration files, side-channel attacks (timing, power analysis). Mitigations: data classification and access controls, output encoding, consistent error handling, and constant-time cryptographic operations.
Denial of Service
Denial of service exhausts system resources, making it unavailable. Threats include: resource exhaustion (CPU, memory, disk, network), algorithmic complexity attacks (hash DoS), XML bomb (billion laughs attack), and amplification attacks (NTP, DNS). Mitigations: rate limiting, resource quotas, auto-scaling, CDN/WAF filtering, and input size validation.
Elevation of Privilege
Elevation of privilege allows an attacker to gain higher permissions than intended. Threats include: path traversal leading to arbitrary file access, logical privilege escalation in API authorization checks, kernel exploit via unpatched driver, and container escape via shared kernel. Mitigations: principle of least privilege, defense-in-depth, regular patching, and sandboxing (SELinux, AppArmor, seccomp).
STRIDE Per Element
STRIDE is applied to each element in a data flow diagram: external entities (spoofing), processes (all STRIDE categories), data stores (tampering, repudiation, information disclosure, DoS), data flows (tampering, information disclosure, DoS), and trust boundaries (elevation of privilege crossing boundaries).
Data Flow Diagrams
DFDs are the foundation of threat modeling — they visually represent system architecture and data movement.
DFD Elements
DFDs use four symbols: external entities (rectangles) — users or external systems; processes (circles/rounded rectangles) — application components that process data; data stores (parallel lines) — databases, files, caches; data flows (arrows) — data movement between elements. Trust boundaries (dashed lines) delineate zones of different trust levels: an internet → DMZ → internal network boundary, or a browser → API → database boundary.
Drawing Effective DFDs
DFDs should be drawn at multiple levels of abstraction. Level 0 (context diagram) shows the system as a single process with external entities. Level 1 decomposes the system into major processes. Level 2+ further decomposes specific processes. Each trust boundary crossing is a potential threat location. Tools: draw.io, Lucidchart, Microsoft Threat Modeling Tool (free, STRIDE-based), and OWASP Threat Dragon (open-source).
Attack Trees
Attack trees systematically model attacker goals and the steps required to achieve them.
Tree Structure
The root node is the attacker’s goal (“Exfiltrate customer database”). Child nodes are sub-goals (“Compromise database server” AND “Bypass network egress controls”). OR conditions represent alternative paths; AND conditions represent dependency chains. Leaf nodes are atomic actions the attacker must take. Attack trees help identify which attack paths are cheapest or most likely, guiding control prioritization.
Quantifying Attack Trees
Each node can be assigned attributes: cost (monetary, computation, time), skill level required, detection probability, and exploit difficulty (based on CVSS metrics). The root node’s overall feasibility is computed by combining child node values along AND/OR paths. Attack trees integrate with PASTA’s risk scoring.
PASTA — Process for Attack Simulation and Threat Analysis
PASTA (VerSprite, 2012) is a risk-centric threat modeling methodology with seven stages: define objectives, define technical scope, decompose application, threat analysis, vulnerability analysis, attack enumeration, and risk and impact analysis.
PASTA vs STRIDE
STRIDE is threat-centric — enumerate threats for each system element. PASTA is attack-centric — simulate attacker objectives and chain attacks. STRIDE is simpler and faster, suitable for agile teams. PASTA is more comprehensive, suitable for high-security systems (financial services, healthcare). Many teams use STRIDE for lightweight modeling and PASTA for critical components.
Threat Modeling Tools
Microsoft Threat Modeling Tool
Free, based on STRIDE. Generates DFDs from stencils and automatically surfaces STRIDE threats with suggested mitigations. Limited to .NET-focused templates but usable for any software architecture. Outputs threat models as HTML reports.
OWASP Threat Dragon
Open-source, web-based and desktop. Supports STRIDE and custom threat taxonomies. Can be integrated into CI/CD pipelines — generate threat model from OpenAPI/Swagger spec.
IriusRisk
Commercial platform for automated threat modeling and risk management. Integrates with architecture tools (Sparx EA), issue trackers (Jira), and CI/CD. Generates threat models from architecture diagrams and assigns risk scores automatically.
Threat Modeling in CI/CD and Agile
Integrating threat modeling into agile development requires lightweight processes that keep pace with rapid iteration.
Threat Modeling Sprints
The Threat Modeling Sprint pattern allocates time for security design review within each sprint. Before coding begins, the team reviews the user story for security implications — does this feature handle sensitive data? Cross a trust boundary? Expose a new API? If yes, a 30-60 minute threat modeling session follows. The output is a lightweight threat model document: key actors, data flows, trust boundaries, identified threats (STRIDE-per-element), and assigned mitigations. Tools like OWASP Threat Dragon and the Microsoft Threat Modeling Tool produce machine-readable threat models that can be checked into the repository alongside code.
Threat Modeling as Code
Treating threat models as code enables version control, CI/CD integration, and automated review. Threagile is an open-source tool that parses YAML-based architecture descriptions and generates threat models with risk scoring. Integration points: run Threagile in CI/CD on every architecture change, comparing results to baseline to detect new risks; gate deployments on unresolved critical threats; and auto-generate Jira issues for identified threats. LINDDUN (privacy threat modeling) and LINDDUN GO provide lightweight privacy threat modeling that integrates into the same workflow.
Threat Intelligence Integration
Threat modeling should incorporate current threat intelligence to remain relevant. MITRE ATT&CK provides a comprehensive taxonomy of adversary tactics and techniques. When threat modeling a new feature, review relevant ATT&CK techniques for similar systems and verify existing controls would detect or prevent them. The Cyber Threat Framework (CTF) from OASIS and the ATT&CK-based Threat Modeling Framework from MITRE Engineering provide structured approaches. The 2025 SANS Threat Modeling Survey found that teams integrating ATT&CK into threat modeling identify 40% more applicable threats than teams using STRIDE alone.
LINDDUN for Privacy Threat Modeling
Privacy threats require a distinct modeling approach. LINDDUN (Linkability, Identifiability, Non-repudiation, Detectability, Disclosure, Unawareness, Non-compliance) extends threat modeling to privacy. It applies privacy threat categories to DFD elements: data flows (linkability, identifiability), data stores (disclosure, non-repudiation), processes (detectability), and actors (unawareness, non-compliance). Mitigations include anonymization, pseudonymization, encryption, data minimization, and privacy notices. GDPR Data Protection Impact Assessments (DPIA) map naturally to LINDDUN outputs. The LINDDUN GO variant provides a lightweight card-based approach for rapid privacy threat modeling workshops.
Threat Model Management
Version-controlled threat model repositories with automated linting ensure consistency. The OWASP Threat Model Cookbook provides templates and examples. Commercial platforms — IriusRisk, ThreatModeler, SD Elements — provide: automated threat generation from architecture diagrams, Jira integration, compliance framework mapping, and reporting dashboards. For teams without budget, the Microsoft Threat Modeling Tool (free) or OWASP Threat Dragon (open-source) provide capable alternatives.
FAQ
When should threat modeling be performed? During design phase — before code is written. Threat modeling is most effective when it influences architecture decisions. Revisit threat models on major feature additions, infrastructure changes, or at least annually.
What is the minimum threat modeling I should do? Draw a data flow diagram, identify trust boundaries, apply STRIDE to each element crossing a trust boundary, and document mitigations. A half-day workshop per feature is standard.
Do I need threat modeling software? For small teams, whiteboard + photos + wiki documentation works. For regulated environments or complex systems, dedicated tools provide traceability, versioning, and audit trails.
How do I integrate threat modeling into agile development? Include threat modeling in sprint 0 (architecture spike). For user stories, add a threat modeling task for stories touching trust boundaries. Keep models at the feature level, not story level.
What is the difference between threat modeling and risk assessment? Threat modeling is design-specific — what threats exist for this particular system? Risk assessment is organization-wide — what risks does the organization face regardless of system? Both are complementary.
For foundational security knowledge, read our Security Guide. Apply threat modeling findings to Security Testing. For compliance-related risk assessment, see Security Compliance.