Model | Design | Threat Assessment | Threat Modeling
Benefit
Identification of architectural design flaws in your applications
Activity
Threat modeling is a structured activity for identifying, evaluating, and managing system threats, architectural design flaws, and recommended security mitigations. It is typically done as part of the design phase or as part of a security assessment.
Threat modeling is a team exercise, including product owners, architects, security champions, and security testers. At this maturity level, expose teams and stakeholders to threat modeling to increase security awareness and to create a shared vision on the security of the system.
At maturity level 1, you perform threat modeling ad-hoc for high-risk applications and use simple threat checklists, such as STRIDE. Avoid lengthy workshops and overly detailed lists of low-relevant threats. Perform threat modeling iteratively to align to more iterative development paradigms. If you add new functionality to an existing application, look only into the newly added functions instead of trying to cover the entire scope. A good starting point is the existing diagrams that you annotate during discussion workshops. Always persist the outcome of a threat modeling discussion for later use.
Your most important tool to start threat modeling is a whiteboard, smartboard, or a piece of paper. Aim for security awareness, a simple process, and actionable outcomes that you agree upon with your team.
Question
Do you identify and manage architectural design flaws with threat modeling?
Quality criteria
You perform threat modeling for high-risk applications |
You use simple threat checklists, such as STRIDE |
You persist the outcome of a threat model for later use |
Answers
No |
Yes, some of them |
Yes, at least half of them |
Yes, most or all of them |
Benefit
Clear expectations of the quality of threat modeling activities
Activity
Use a standardized threat modeling methodology for your organization and align this on your application risk levels. Think about ways to support the scaling of threat modeling throughout the organization.
Train your architects, security champions, and other stakeholders on how to do practical threat modeling. Threat modeling requires understanding, clear playbooks and templates, organization-specific examples, and experience, which is hard to automate.
Your threat modeling methodology includes at least diagramming, threat identification, design flaw mitigations, and how to validate your threat model artifacts. Your threat model diagram allows a detailed understanding of the environment and the mechanics of the application. You discover threats to your application with checklists, such as STRIDE or more organization-specific threats. For identified design flaws (ranked according to risk for your organization), you add mitigating controls to support stakeholders in dealing with particular threats. Define what triggers updating a threat model, for example, a technology change or deployment of an application in a new environment.
Feed the output of threat modeling to the defect management process for adequate follow-up. Capture the threat modeling artifacts with tools used by your application teams.
Question
Do you use a standard methodology, aligned with your application risk levels?
Quality criteria
You train your architects, security champions, and other stakeholders on how to do practical threat modeling |
Your threat modeling methodology includes at least diagramming, threat identification, design flaw mitigations, and how to validate your threat model artifacts |
Changes in the application or business context trigger a review of the relevant threat models |
You capture the threat modeling artifacts with tools used by your application teams |
Answers
No |
Yes, for some applications |
Yes, for at least half of the applications |
Yes, for most or all of the applications |
Benefit
Assurance of continuous improvement of threat modeling activities
Activity
Threat modeling is integrated into your SDLC and has become part of the developer security culture. Reusable risk patterns, comprising related threat libraries, design flaws, and security mitigations, are created and improved, based on the organization’s threat models. You regularly (e.g., yearly) review the existing threat models to verify that no new threats are relevant for your applications.
You optimize your threat modeling methodology. You capture lessons learned from threat models and use these to improve your threat modeling methodology. You review the threat categories relevant to your organization and update your methodology appropriately. From time to time, you evaluate the quality of your threat models independently.
You automate parts of your threat modeling process with threat modeling tools. You integrate your threat modeling tools with other security tools, such as security verification tools and risk tracking tools. You consider “threat modeling as code” practices to integrate threat modeling artifacts with application code.
Question
Do you regularly review and update the threat modeling methodology for your applications?
Quality criteria
The threat model methodology considers historical feedback for improvement |
You regularly (e.g., yearly) review the existing threat models to verify that no new threats are relevant for your applications |
You automate parts of your threat modeling process with threat modeling tools |
Answers
No |
Yes, but review is ad-hoc |
Yes, we review it at regular times |
Yes, we review it at least annually |
Stream Guidance
- SAMM team guidance Google Doc
- Community guidance Google Doc
Want to contribute?
Complete this Google Form with guidance for this Stream.
To learn more about Stream guidance for the SAMM model, see the Stream guidance page.