Threat Modeling
A structured process for identifying potential threats, attack vectors, and vulnerabilities in a system design—enabling security controls to be built in during design rather than bolted on after deployment.
Full Definition
Threat modeling is a proactive security engineering practice that systematically identifies potential threats, attack vectors, and security weaknesses in a system at the design stage—before code is written or infrastructure is deployed. By identifying and addressing security vulnerabilities during design rather than after deployment, threat modeling dramatically reduces the cost of security: fixing a vulnerability during design costs approximately 1x; fixing it in code review costs 6x; fixing it in testing costs 30x; and fixing it in production costs 100x or more. The "shift left" security philosophy—moving security engagement earlier in the development lifecycle—is implemented primarily through threat modeling integrated into the software design process. Several threat modeling methodologies provide structured approaches for different contexts. STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) is the most widely used developer-friendly methodology, providing a threat category checklist that teams apply to each system component and data flow. PASTA (Process for Attack Simulation and Threat Analysis) is a more comprehensive, risk-centric framework aligned with business objectives and attacker simulation. MITRE ATT&CK provides a knowledge base of real-world adversary tactics and techniques that can be used as a threat reference for modeling attacks against specific system types. The choice of methodology depends on the team's security sophistication and the system's risk profile. Effective threat modeling requires cross-functional collaboration: software architects who understand the system design, security engineers who understand threat landscapes and attack techniques, and product managers who understand the business context and acceptable risk levels. Threat modeling sessions that include all three perspectives produce more complete threat inventories than purely technical assessments that miss business context (what data is sensitive from a regulatory perspective?) and more actionable mitigations than purely business assessments that miss technical implementation details (how is authentication actually implemented?).
FAQs
When in the development process should threat modeling occur?
Threat modeling should occur at the design phase of new features or systems—before code is written. For agile development teams, this means threat modeling should be part of the design/discovery phase of a feature, ideally triggered by any story that: introduces new data flows, modifies authentication or authorization, adds new external integrations, or processes sensitive personal or financial data. Some organizations require threat modeling sign-off before sprint planning for qualifying features, embedding it as a standard workflow step rather than an optional security review.
Who should be trained to conduct threat modeling?
All software engineers and security engineers should have basic threat modeling training (the STRIDE methodology can be taught in 2-4 hours). Security engineers and architects should have deeper methodology training to facilitate complex threat modeling sessions and maintain methodology consistency across the organization. Application security teams often provide threat modeling as a service—facilitating sessions for development teams on request—while simultaneously training development teams to conduct basic self-service threat modeling for lower-risk features.
Relevant Executive Roles
The Crimson Bench · Est. 2002 · Founded in New York City
Deploy an Executive in 48 Hours
Verified corporate accounts only. Ivy League-educated. Flat-rate pricing. 14-day no-cause cancellation.
25,000+ Ivy League Executives · 150,000+ Global Consultants · 48-Hour Deployment