What Is Threat Modeling?
Threat modeling identifies security risks during system design before they become vulnerabilities.
How Threat Modeling Works
The most widely used threat modeling framework is STRIDE, developed by Microsoft. STRIDE identifies six threat categories: Spoofing identity — attackers claiming to be someone they are not; Tampering with data — unauthorized modification of data; Repudiation — denying actions that were performed; Information Disclosure — exposing data to unauthorized parties; Denial of Service — degrading or denying service availability; Elevation of Privilege — gaining capabilities beyond what is authorized. STRIDE systematically applies these threat categories to every component of the system architecture being modeled.
The PASTA methodology — Process for Attack Simulation and Threat Analysis — is a risk-centric approach that incorporates attacker perspective and business impact assessment. MITRE ATT&CK-based threat modeling applies specific attacker techniques documented in the ATT&CK matrix to identify the most relevant threats based on real-world adversary behavior.
What Threat Modeling Produces
A threat model produces a list of identified threats, each evaluated for likelihood and impact, with prioritized mitigations that address the highest-risk threats. The mitigations may be architectural decisions — separating components, adding encryption, implementing authentication — or operational controls — monitoring requirements, access reviews, incident response procedures. The threat model becomes a reference document that guides both initial development and ongoing security assessment of the system.
Threat Modeling in DevSecOps
Threat modeling is most impactful when conducted early in the development lifecycle — during architecture and design rather than after development is complete. A threat identified during design costs nothing to mitigate through a different design decision. The same threat discovered post-development may require significant rework. Mature DevSecOps programs conduct threat modeling as a standard component of the design review process for any new system or significant architecture change.
Related Reading
What is threat modeling?
Threat modeling is a structured process for identifying and prioritizing the threats that apply to a system, application, or business process before attackers exploit them. It typically involves diagramming the system, enumerating potential threats against each component, assessing their likelihood and impact, and designing controls to mitigate the highest priorities. Done well, threat modeling shifts security work upstream from reactive incident response to proactive design.
How does threat modeling differ from risk assessment?
Risk assessment evaluates threats and vulnerabilities at a broad organizational level, often as a compliance exercise. Threat modeling drills into specific systems or features and enumerates concrete attack scenarios against them. A risk assessment might note that web applications are exposed to attack; a threat model would identify SQL injection in the login flow and missing rate limiting on the password reset endpoint. Both are valuable; threat modeling produces more actionable engineering output.
What are the most common threat modeling methodologies?
STRIDE, developed by Microsoft, categorizes threats as Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege. PASTA focuses on attacker motivation and business impact. LINDDUN addresses privacy threats specifically. The Trike methodology is risk-based. Most mature teams combine elements from multiple frameworks rather than rigidly applying one.
What tools and platforms support threat modeling?
Microsoft Threat Modeling Tool offers structured STRIDE-based modeling and is free. IriusRisk and ThreatModeler provide enterprise platforms with automation, integration into development workflows, and library-based threat enumeration. OWASP's pytm enables threat modeling as code. Many teams start with collaborative drawing tools like Miro or Lucidchart combined with structured threat checklists.
How do organizations integrate threat modeling into development?
Mature programs require threat models for new features above a complexity threshold, conducted during design before code is written. Security champions embedded in development teams facilitate the modeling sessions. Outputs feed into security requirements, test cases, and architecture decisions. The cadence varies from per-feature for high-stakes systems to quarterly architectural reviews for lower-risk ones.
What does threat modeling cost in time and money?
A focused threat modeling session for a single feature typically takes two to four hours including the engineering team. Enterprise platforms range from free open-source options to $50,000-plus annually for IriusRisk and ThreatModeler. The bigger investment is cultural: training development teams to think adversarially and integrating modeling into existing rituals like design review.
What is the first step in starting threat modeling?
Pick a single high-value system, run a STRIDE-based session with the engineering team, and demonstrate that the output produced security improvements that would have been missed otherwise. That proof of concept makes the case for broader adoption far better than a top-down mandate. Train one team to do this well before scaling.
Real-World Example: Threat Modeling Prevents Healthcare API Exposure
A Cloudskope threat modeling engagement for a PE-backed digital health company identified a design decision that would have exposed patient health records through a poorly scoped API. The development team had designed an API that returned complete patient records when queried by appointment ID, planning to filter sensitive fields on the client side. The threat model identified that client-side filtering is not a security control — any client with valid API access could bypass it and access complete records. The design was revised before development, eliminating a HIPAA compliance vulnerability that would have required significant remediation post-deployment.
The cost differential between fixing a security vulnerability identified during threat modeling versus fixing the same vulnerability after deployment — the economic foundation of the 'security by design' principle that threat modeling operationalizes.