Threat Modeling Methodologies
STRIDE STRIDE categorizes threats into six types: Spoofing identity, Tampering with data, Repudiation of actions, Information disclosure, Denial of service, and Elevation of privilege. Each threat type maps to security properties (authentication, integrity, non-repudiation, confidentiality, availability, authorization) 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. STRIDE works well for technical teams familiar with security concepts, providing comprehensive threat coverage through systematic enumeration. However, STRIDE can become mechanical box-checking without considering actual adversary capabilities and motivations. PASTA Process for Attack Simulation and Threat Analysis (PASTA) provides seven-stage, attack-centric methodology with business impact alignment. PASTA stages include defining objectives, defining technical scope, application decomposition, threat analysis, vulnerability analysis, attack modeling, and risk/impact analysis. 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. TRIKE focuses on acceptable risk levels for different assets, with threat enumeration driven by asset value and acceptable risk thresholds. TRIKE’s asset-centric approach aligns well with data classification and protection requirements, making it suitable for systems handling sensitive data with clear classification schemes. OCTAVE Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE) provides organization-centric threat modeling useful for aligning non-technical stakeholders. OCTAVE focuses on organizational risk rather than technical vulnerabilities, making it suitable for enterprise risk management. OCTAVE workshops involve business stakeholders in threat identification, building shared understanding of security risks and organizational impact. Attack Trees Attack trees decompose adversary goals into subgoals and attack steps, creating hierarchical representations of attack paths. Leaf nodes represent atomic attack steps, while intermediate nodes represent subgoals that can be achieved through multiple paths. Attack trees help prioritize defenses by identifying critical nodes whose mitigation blocks multiple attack paths. Cut set analysis identifies minimum sets of mitigations that block all attack paths to a goal. Attack trees complement other methodologies by providing visual representation of attack paths and enabling quantitative risk analysis through probability and cost assignment to nodes. Data Flow Diagrams Data Flow Diagrams (DFDs) model system components including external entities, processes, data stores, and data flows. Trust boundaries on DFDs indicate where data crosses security boundaries, highlighting where security controls are needed. DFDs provide the foundation for most threat modeling methodologies, enabling systematic analysis of how data moves through systems and where threats may occur. DFD creation forces explicit documentation of system architecture and trust assumptions.Embedding Threat Modeling in SDLC
Triggering Events Threat modeling should be triggered by architectural changes rather than calendar schedules. Triggering events include new services or endpoints, data classification changes, third-party integrations, authentication or authorization changes, and significant architectural modifications. Automated triggers in development workflows ensure threat modeling occurs when needed rather than being forgotten. Pull request templates, architecture decision record processes, and design review checklists can include threat modeling requirements. Threat Modeling Artifacts Threat modeling produces several artifacts including context diagrams showing system boundaries and external entities, data flow diagrams with trust boundaries, threat lists with likelihood and impact assessments, proposed mitigations, and residual risk documentation. Artifacts should be stored in version control alongside code, enabling tracking of threat model evolution and ensuring threat models remain accessible. Threat models as code using YAML or domain-specific languages enable automation and integration with CI/CD pipelines. Ownership and Review Product teams should author threat models with security team review and guidance. This ownership model ensures threat modeling scales beyond security team capacity while building security knowledge in product teams. Security teams provide threat modeling training, templates, and review rather than creating all threat models themselves. Security review validates threat model completeness and mitigation appropriateness. Decisions and risk acceptances should be recorded in Architecture Decision Records (ADRs) with expiration dates for exceptions. Time-limited risk acceptances ensure periodic review rather than permanent acceptance of unmitigated risks. Automation and Tooling Storing threat models as code enables automated validation, checklist generation, and integration with CI/CD pipelines. Automated checks ensure threat models are updated when architecture changes, preventing stale threat models. Generated security test checklists from threat models ensure that identified threats are tested. Integration with security testing tools enables automated validation of mitigations.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. Reference classes including prior incidents, MITRE ATT&CK techniques, and cyber kill chain stages provide realistic attack patterns. Learning from actual attacks produces more relevant threat models than purely theoretical analysis. Risk-Based Prioritization Prioritize threats by blast radius and ease of exploitation rather than treating all threats equally. High-impact, easy-to-exploit threats require immediate mitigation, while low-impact, difficult-to-exploit threats may be accepted. Fold threat model findings into organizational risk registers with documented risk treatments. Risk register integration ensures threat model findings receive appropriate attention and tracking. Mitigation Acceptance Criteria Define acceptance criteria for mitigations before implementation, including security tests, policies, and metrics that validate mitigation effectiveness. Acceptance criteria prevent checkbox security where mitigations are implemented without validation. Mitigations should be testable, with automated tests that continuously validate their effectiveness. Untestable mitigations may provide false security without actual protection.Threat Model Outputs to Security Controls
Identity Controls Threat modeling identifies authentication and authorization requirements including stronger authentication mechanisms, step-up authentication for sensitive operations, and appropriate token scopes. Confused deputy problems where services misuse delegated authority are common threat model findings. Data Protection Controls Data-focused threats drive encryption boundary decisions, data minimization requirements, and integrity verification mechanisms. Tamper-evident logging prevents repudiation threats by providing cryptographic proof of actions. Network Controls Network threat analysis drives segmentation requirements, egress control policies, and Server-Side Request Forgery (SSRF) protections. Trust boundary analysis identifies where network controls are needed. Application Controls Application-level threats require input validation, output encoding, secure deserialization, and rate limiting. Threat modeling identifies specific input validation requirements based on data flows and trust boundaries.Review Cadence and Maintenance
Regular Review Triggers Threat models should be reviewed at design phase before implementation, pre-general availability before launch, post-incident after security incidents, and annually for critical systems. Material architectural changes trigger threat model updates. Stale threat models provide false security by documenting mitigations for outdated architectures. Regular review ensures threat models remain accurate and relevant. Continuous Improvement Threat modeling effectiveness should be measured through metrics including percentage of projects with threat models, threat model coverage of critical systems, and security issues prevented through threat modeling. Post-incident reviews should evaluate whether threat modeling would have identified vulnerabilities, improving threat modeling processes based on lessons learned.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
- Microsoft STRIDE Threat Modeling
- PASTA Threat Modeling Methodology
- MITRE ATT&CK Framework
- OWASP Threat Modeling Cheat Sheet
- Threat Modeling: Designing for Security (Adam Shostack)