Skip to main content
Threat modeling systematically converts system architecture into adversary-informed risk assessments and security controls, enabling proactive security design rather than reactive vulnerability remediation. Security engineers establish threat modeling as a continuous practice integrated into architecture decisions and software development lifecycle rather than one-time security workshops that produce documents nobody reads. Effective threat modeling identifies threats before implementation, when addressing them is cheapest and easiest. Threat models:
  • Inform security control selection based on identified attack vectors
  • Guide security testing priorities and coverage requirements
  • Provide shared understanding between security and engineering teams
  • Document risk decisions and mitigation strategies
  • Enable compliance with frameworks like NIST Cybersecurity Framework and ISO 27001

​
Threat Modeling Methodologies Overview

The following table compares major threat modeling methodologies to help select the appropriate approach for different contexts:

​
STRIDE

STRIDE categorizes threats into six types, each mapping to security properties and corresponding mitigations: STRIDE provides systematic threat enumeration by examining each system component for each threat type. Data flow diagrams with trust boundaries enable structured STRIDE analysis, identifying where data crosses trust boundaries and what threats apply. Strengths and limitations:
  • Works well for technical teams familiar with security concepts
  • Provides comprehensive threat coverage through systematic enumeration
  • Can become mechanical box-checking without considering actual adversary capabilities
  • Pairs effectively with Microsoft Threat Modeling Tool

​
PASTA

Process for Attack Simulation and Threat Analysis (PASTA) provides a seven-stage, attack-centric methodology with business impact alignment:
  1. Define objectives — Establish business and security objectives
  2. Define technical scope — Document application architecture and dependencies
  3. Application decomposition — Create data flow diagrams and identify entry points
  4. Threat analysis — Research threat intelligence and attack patterns
  5. Vulnerability analysis — Identify weaknesses using CVE databases and CWE
  6. Attack modeling — Build attack trees and simulate attack scenarios
  7. Risk/impact analysis — Quantify business impact and prioritize mitigations
PASTA excels for high-risk features requiring deep threat analysis with business context. The methodology explicitly connects technical threats to business impact, enabling risk-based prioritization and stakeholder communication. PASTA’s comprehensive approach requires significant time investment, making it suitable for critical systems rather than routine feature development.

​
TRIKE

TRIKE provides risk-based threat modeling with asset-centered authorization models:
  • Focuses on acceptable risk levels for different assets
  • Drives threat enumeration by asset value and acceptable risk thresholds
  • Aligns well with data classification and protection requirements
  • Suitable for systems handling sensitive data with clear classification schemes
TRIKE uses a requirements model that defines acceptable actions for each actor-asset-action combination, generating threats from any deviation from acceptable behavior.

​
OCTAVE

Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE), developed by Carnegie Mellon’s SEI, provides organization-centric threat modeling:
  • Focuses on organizational risk rather than technical vulnerabilities
  • Suitable for enterprise risk management and compliance requirements
  • Involves business stakeholders in threat identification
  • Builds shared understanding of security risks and organizational impact
OCTAVE variants include OCTAVE Allegro for streamlined assessment and OCTAVE FORTE for enterprise-wide risk management.

​
Attack Trees

Attack trees decompose adversary goals into subgoals and attack steps, creating hierarchical representations of attack paths:
  • Root node — Represents the attacker’s ultimate goal (e.g., “Exfiltrate customer data”)
  • Intermediate nodes — Represent subgoals achieved through child nodes
  • Leaf nodes — Represent atomic attack steps that can be directly assessed
  • AND/OR logic — Defines whether all children or any child achieves the parent goal
Key benefits of attack trees:
  • Prioritize defenses by identifying critical nodes whose mitigation blocks multiple paths
  • Enable cut set analysis to identify minimum mitigations blocking all attack paths
  • Provide visual representation for stakeholder communication
  • Support quantitative risk analysis through probability and cost assignment
Attack trees complement methodologies like STRIDE by visualizing how individual threats combine into attack scenarios.

​
Data Flow Diagrams

Data Flow Diagrams (DFDs) model system components and provide the foundation for most threat modeling methodologies: DFDs force explicit documentation of system architecture and trust assumptions. Trust boundaries indicate where data crosses security zones, highlighting where security controls are required.

​
Embedding Threat Modeling in SDLC

Integrating threat modeling into the software development lifecycle ensures security analysis occurs at design time rather than after implementation.

​
Triggering Events

Threat modeling should be triggered by architectural changes rather than calendar schedules: Automated triggers in development workflows ensure threat modeling occurs when needed:
  • Pull request templates with security review checkboxes
  • Architecture Decision Record (ADR) processes requiring threat assessment
  • Design review checklists with threat modeling requirements
  • OWASP Threat Dragon integration for diagram-based modeling

​
Threat Modeling Artifacts

Effective threat modeling produces artifacts that inform development and testing:
  1. Context diagrams — System boundaries and external entities
  2. Data flow diagrams — Trust boundaries and data movement
  3. Threat register — Identified threats with likelihood and impact ratings
  4. Mitigation matrix — Proposed controls mapped to threats
  5. Residual risk documentation — Accepted risks with justification
  6. Security test requirements — Test cases derived from threat scenarios
Artifacts should be stored in version control alongside code, enabling tracking of threat model evolution. Threat models as code using YAML or domain-specific languages (e.g., Threagile) enable automation and CI/CD integration.

​
Ownership and Review

Establish clear ownership models for threat modeling scalability:
  • Product teams author threat models with domain knowledge
  • Security teams provide training, templates, and review guidance
  • Architecture review boards validate alignment with security standards
  • Risk committees approve risk acceptances above defined thresholds
Decisions and risk acceptances should be recorded in Architecture Decision Records (ADRs) with expiration dates. Time-limited risk acceptances ensure periodic review rather than permanent acceptance of unmitigated risks.

​
Automation and Tooling

Leverage tooling to scale threat modeling across engineering teams: Automated checks ensure threat models are updated when architecture changes, preventing stale documentation. Generated security test checklists ensure identified threats are validated through testing.

​
Threat Modeling Techniques

​
Adversary-Centric Analysis

Enumerate abuse cases and adversary objectives before cataloging generic threats. Understanding what attackers want to achieve focuses threat modeling on realistic attack scenarios rather than theoretical possibilities. Key resources for adversary-centric modeling:
  • MITRE ATT&CK Framework — Catalog of adversary tactics, techniques, and procedures
  • Cyber Kill Chain — Attack lifecycle stages from reconnaissance to objectives
  • CAPEC — Common Attack Pattern Enumeration and Classification
  • Industry-specific threat intelligence (FS-ISAC, H-ISAC, etc.)
Learning from actual attacks produces more relevant threat models than purely theoretical analysis. Prior incident data and threat intelligence inform realistic attack scenarios.

​
Risk-Based Prioritization

Prioritize threats using a structured approach rather than treating all threats equally: Fold threat model findings into organizational risk registers with documented risk treatments. Use frameworks like FAIR (Factor Analysis of Information Risk) for quantitative risk assessment.

​
Mitigation Acceptance Criteria

Define acceptance criteria for mitigations before implementation:
  1. Security tests — Automated tests validating control effectiveness
  2. Policies — Configuration requirements and compliance checks
  3. Metrics — Observable indicators of control operation
  4. Monitoring — Detection mechanisms for control bypass
  5. Recovery procedures — Response plans if controls fail
Acceptance criteria prevent checkbox security where mitigations are implemented without validation. Untestable mitigations may provide false security without actual protection.

​
Threat Model Outputs to Security Controls

Threat modeling directly informs security control selection across multiple domains:

​
Identity Controls

Threat modeling identifies authentication and authorization requirements:
  • Stronger authentication mechanisms for sensitive operations
  • Step-up authentication based on transaction risk
  • Appropriate token scopes and lifetime limits
  • Confused deputy mitigations for delegated authority

​
Data Protection Controls

Data-focused threats drive protection requirements:
  • Encryption boundary decisions based on trust boundaries
  • Data minimization to reduce disclosure impact
  • Integrity verification for tamper detection
  • Tamper-evident logging for non-repudiation (see OWASP Logging Cheat Sheet)

​
Network Controls

Network threat analysis informs architecture decisions:
  • Segmentation requirements based on trust boundaries
  • Egress control policies limiting outbound connections
  • SSRF protections for server-side request handling
  • Internal API authentication requirements

​
Application Controls

Application-level threats require defense-in-depth controls:
  • Input validation based on expected data types and ranges
  • Output encoding appropriate to rendering context
  • Secure deserialization with allowlists
  • Rate limiting based on abuse scenario analysis

​
Review Cadence and Maintenance

​
Regular Review Triggers

Establish a consistent review cadence for threat models: Stale threat models provide false security by documenting mitigations for outdated architectures. Regular review ensures threat models remain accurate and relevant.

​
Continuous Improvement

Measure threat modeling effectiveness through key metrics:
  • Coverage — Percentage of projects with current threat models
  • Timeliness — Threat models completed before implementation
  • Effectiveness — Security issues prevented vs. discovered post-deployment
  • Velocity — Time from trigger event to completed threat model
Post-incident reviews should evaluate whether threat modeling would have identified vulnerabilities. Feed lessons learned back into threat modeling processes, templates, and training.

​
Conclusion

Threat modeling methodologies provide structured approaches to identifying security risks and designing appropriate controls. Security engineers establish threat modeling as continuous practice integrated into software development lifecycle, with clear ownership, automation, and regular review. Success requires treating threat modeling as engineering practice rather than security ceremony, with practical outputs that inform design decisions and security testing. Organizations that invest in threat modeling fundamentals build more secure systems while reducing costly post-deployment security remediation.

​
References