What is Threat Modeling?

Threat modeling is a structured approach to identifying, quantifying, and addressing security threats to systems by analyzing architecture, data flows, and trust boundaries.

What is threat modeling?

Threat modeling is a structured analytical process for identifying and prioritizing potential security threats to a system during the design phase. By examining system architecture, data flows, trust boundaries, and entry points, threat modeling reveals vulnerabilities before code is written. It answers four key questions: what are we building, what can go wrong, what are we going to do about it, and did we do a good job.

What threat modeling methodologies exist?

Major threat modeling methodologies include STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) developed by Microsoft, PASTA (Process for Attack Simulation and Threat Analysis) focusing on business impact, LINDDUN for privacy threat analysis, VAST (Visual Agile Simple Threat modeling) for agile environments, attack trees for hierarchical threat decomposition, and OCTAVE for organizational risk assessment.

When should threat modeling be performed?

Threat modeling should be performed during the design phase of new systems or features, before significant architectural changes, when integrating new components or third-party services, after security incidents revealing design weaknesses, and as part of regular security review cycles. Early threat modeling prevents costly redesigns. Agile teams should incorporate lightweight threat modeling into sprint planning for new features affecting security-relevant components.

How does STRIDE threat modeling work?

STRIDE systematically analyzes system components against six threat categories: Spoofing identity through authentication bypass, Tampering with data integrity, Repudiation of actions through inadequate logging, Information Disclosure through unauthorized data access, Denial of Service through availability attacks, and Elevation of Privilege through authorization bypass. Each system element is evaluated against applicable STRIDE categories to identify specific threats requiring mitigation.

What are data flow diagrams in threat modeling?

Data flow diagrams (DFDs) visually represent how data moves through a system, identifying processes, data stores, external entities, and data flows. DFDs establish trust boundaries where security controls should be placed. In threat modeling, DFDs serve as the foundation for systematic threat identification by highlighting where untrusted data enters the system, where sensitive data is stored, and where privilege transitions occur.

How do you prioritize identified threats?

Prioritize threats using risk-based approaches combining likelihood and impact assessments. The DREAD model (Damage, Reproducibility, Exploitability, Affected users, Discoverability) provides structured scoring. Map threats to attack patterns and known vulnerabilities for realistic likelihood estimation. Consider existing controls, business criticality of affected assets, and compliance requirements. Focus remediation on high-risk threats while documenting accepted residual risks.

What tools support threat modeling?

Threat modeling tools include Microsoft Threat Modeling Tool for STRIDE-based DFD analysis, OWASP Threat Dragon providing open-source diagramming and threat generation, IriusRisk for automated threat modeling at scale, Threagile for infrastructure-as-code threat modeling, and draw.io for manual DFD creation. Emerging tools incorporate AI-assisted threat identification and integrate with CI/CD pipelines for continuous threat assessment during development.

How does threat modeling fit into DevSecOps?

Threat modeling integrates into DevSecOps by embedding security design analysis into development workflows. Lightweight threat modeling during sprint planning identifies security requirements for new features. Architecture decision records include threat considerations. Automated threat modeling tools analyze infrastructure-as-code changes for security implications. This shift-left approach ensures security is designed into systems rather than bolted on after implementation.