Threat Modeling is critical to achieving design goals for system security and data privacy.
This document provides a catalog of capabilities to help you cultivate value from your Threat Modeling practice.
We have identified the following threat modeling capabilities to help you create or refine a roadmap for your threat modeling program and understand where your program is.
We feel that organizations that implement these capabilities will meet their secure design objectives and avoid many pitfalls and challenges when performing threat modeling.
What is a threat modeling capability?
A capability delineates what an organization does. Capabilities do not attempt to explain how, why, or where they are used.
Where you start the threat modeling process depends on your organization. Note that implementing capabilities is typically not a linear process. Some capabilities are easier for some organizations to implement, while others are harder. Start by understanding your circumstances, biggest problems, and best and most cost effective opportunities.
This document serves as a catalog of capabilities; use them as Lego pieces to help you build a threat modeling program. Although these capabilities are very simple, the more of them you implement, the better your program becomes.
Each capability describes something measurable and/or provable, but is always an actionable objective. A capability identifies a goal at a particular state and is defined as a measurement, not the quantity that’s been measured.
We have grouped capabilities into the following seven process areas:
- Creating Threat Models
- Acting on Threat Models
- Program Management
Each capability supports the area's objectives. The existence of a capability is not a measure of maturity by itself. Having more capabilities in one process area makes that area more complete, not necessarily more mature.
Each process area introduces a common objective. Capabilities are practical stepping-stones towards these goals.
Threat modeling is an organization-wide practice differentiating from the anti-pattern of hero threat modelers. Strategy should prioritize and highlight the importance of threat modeling.
Documentation exists requiring or mandating that threat modeling occur. Actions are taken by leadership to encourage threat modeling. Goals are set to ensure proper analysis of threat models.
Life Cycle Integration
Threat modeling is incorporated into organizational processes such as the development life cycle or an SDLC and is a prerequisite for critical life cycle phases.
Teams commit the appropriate amount of time, people, and money to perform threat modeling.
People should learn how to perform threat modeling according to the Values and Principles of the Threat Modeling Manifesto. “A journey of understanding over a security or privacy snapshot” requires that learning provides ongoing support to participants in threat modeling. Training is available easily and always for anyone who wants to learn.
Threat modeling training is part of the organization’s curriculum. Stakeholders assign resources so that everyone in their organization can learn.
Role-based training presents information and instruction based on the job responsibilities of each individual.
Practitioners use experiential learning to develop threat modeling skills by performing hands-on threat modeling.
A support structure is in place to strengthen the performance of threat modeling. Examples include providing mentoring, coaching, or peer-to-peer insights. Developers are encouraged to learn about security and privacy concepts.
Training is informed by and reflects organizational practice and customs factors such as how to threat model; tools used; how to get support; what success looks like. Infuse locality of organizational culture into threat modeling.
People are encouraged and supported in becoming aware of new classes of threats; manifestations of threats; threat actors; new security features of their environment and how to best apply them. New information is put into an accessible and up-to-date form for participants to evolve their threat modeling skills.
Creating Threat Models
Ideally, threat modeling occurs at the beginning where ideas take form, but may occur at any time during a system’s life cycle. The threat model creation process is effective according to the organization.
Practitioners with proven threat modeling experience and process facilitators are either part of the process or available to the team.
Support mechanisms are in place to encourage and improve threat modeling practices. The organization facilitates diversity of people’s job functions through inclusive threat modeling participation.
All teams own and are accountable for doing threat modeling. Threat modeling might include the team that implements the system/feature and with the help of a facilitator.
Organizations evaluate all of their in-scope systems to decide in which order to execute threat modeling.
System and Threat Comprehension
Analysis, as part of the creation process, is informed by ingesting system architecture. Conclusions are enriched by utilizing outside threat knowledge.
Product-specific threats and mitigations are identified and reused. Emerging knowledge is considered in later rounds to refine the threat modeling process.
The organization promotes uniformity of threat models. Predefined templates of threat models can be used to ensure completeness.
Threat modeling is iterative, and changes to the system or its environment trigger analysis of previous threats and mitigations.
Threat models are versioned to maintain a historical record.
Threat Model Distribution
The organization provides a mechanism for sharing and discovering threat models. Access to threat models should be available to relevant stakeholders. Optionally, threat models are shared with other teams, organization-wide, or externally.
Tool Assisted Process
Tools are integrated into processes to support the generation of threats, countermeasures, or diagrams. They can either produce new documents or add to existing ones. More capable tools can be used for advanced system modeling and threat elicitation.
Acting on Threat Models
Once a threat model is complete, follow up on the threat model process to address the findings.
Definition of Done
Criteria exist to indicate when threat modeling outputs have met objectives for security and privacy.
Threat modeling outcomes influence the implementation or operational workflows. For example, guiding testing in the SDLC.
The organization uses metrics to identify ways to enhance outcomes in the next round.
Teams use threat modeling to understand and appropriately quantify risk. The organization uses threat modeling to inform and adapt its risk profile. Some organizations have separate risk management processes that can potentially be informed by threat modeling.
Threat modeling requirements, progress, measurements, and impact are communicated to stakeholders and decision makers. Productive discussions occur amongst threat modeling people.
Value propositions based on threat modeling outcomes are communicated to leadership, stakeholders, and participants. The organization celebrates successes in threat modeling and learns from failures.
Foster influence and communication, active listening, and collaboration skills. Threat modeling facilitators learn and practice these soft skills to ensure favorable acceptance and performance of threat modeling.
The organization is receptive to and proactively supports input from stakeholders at each step of the threat modeling program.
The organization facilitates peer-to-peer collaboration and productive dialogue to share knowledge, experiences, frustrations, and encouragement.
Listen To Diverse Viewpoints
Ideas from various positions contribute to threat modeling discussions. Internal viewpoints can focus on results and external ones on the method and program.
Metrics help determine if threat modeling is effective and meets organizational objectives. Some example indicators might be the effort needed in performing an activity and changes to security and privacy posture.
Return on investment compares the effort put into threat modeling against its effectiveness. This valuation can be used to show improvement and consider changes before you move forward.
Dashboards and metrics are used to show the impact of outcomes and invite feedback. These metrics may indicate either progress or regression.
Quantified Risk Management
The organization uses threat modeling generated metrics to understand, measure and complement risk management.
As with everything, the organization should not aim for perfection of security and privacy; “reasonable” is the goal. The program should meet organizational objectives and influence the security and privacy posture. These capabilities focus on defining and managing the program within the organization.
The threat modeling program is managed, structured, and defined at an organizational level and provides recognizable value.
The threat modeling program evolves in manageable chunks to provide simplicity and value.
Threat modeling programs promote flexibility in modeling and analysis methods to support different business and technological contexts.
Measurement through reporting informs program governance and the threat modeling exercise itself. The adoption of threat modeling capabilities is monitored, and the program is refined accordingly.
Collaborative Program Development
The organization internally exchanges knowledge and best practices to nurture a threat model program. Practitioners should build on each other’s experiences to codify the optimal way to apply threat modeling. At the widest organizational scope, an example could be a community of practice.
A cohesive team of threat modeling practitioners came together to create the Threat Modeling Manifesto in 2020. Our intention in creating the Threat Modeling Manifesto is to share a version of our collective threat modeling knowledge in a way that informs, educates, and inspires other practitioners to adopt threat modeling and thereby improve security and privacy during development. We feel that we captured the essence of threat modeling.
After a break of a few years, the team decided to reconvene and move the practice of threat modeling forward again. The idea for this document, Threat Modeling Capabilities, was born out of a search for the next challenge in threat modeling after what we offered in the Threat Modeling Manifesto. We chose to define capabilities in an effort to support modernization and potentially standardization (or at least consistency) of the practice. We considered a maturity model and a set of capabilities and landed on capabilities as the outcome providing the quickest path to organizational value.
The creation of the capabilities project took place over most of 2023. It consisted of regular meetings, brainstorming sessions, editing reviews, and civil conversations about the best path forward for those creating or enhancing a threat modeling program. The conclusion of all this effort is the document you are reading now.
While the group collectively has a few hundred years of threat modeling experience, that doesn't mean we have all the answers. We welcome reviews and feedback from others in the threat modeling community. Please provide us feedback via an issue on GitHub, and we will consider the feedback and decide how best to apply it against the growing list of threat modeling capabilities.
You can always find the current version of this capabilities at https://www.threatmodelingmanifesto.org/capabilities/.
This work is licensed under a Creative Commons Attribution 4.0 International License.
The working group of the Threat Modeling Capabilities consists of individuals with years of experience in threat modeling for security or privacy. We had some new people join the group, and some of the original manifesto team could not continue the journey with us for this project.
- Kim Wuyts
- Matthew Coles
- Sarah-Jane Madden
- Avi Douglen
- Zoe Braiterman
- Izar Tarandach
- Adam Shostack
- Robert Hurlbut
- Irene Michlin
- Stephen de Vries
- Fraser Scott
- Sebastien Deleersnyder
- Jonathan Marcil
- Brook S.E. Schoenfield
- Chris Romeo
The working group would like to thank Sheila Kamath for her technical edit review and expert feedback on the document content and structure.
On the web version of this document, we have tooltips on many words to notate the text. Here's a table with all those notes in order of appearance.