Article

Top 10 Tips for Building an Enterprise Threat Modeling Program

  • 9 November 2022
  • 1 reply
  • 284 views

Userlevel 4
Badge

Introduction

Threat modeling has taken center stage in many programs over the past few years. With the release of the Threat Modeling Manifesto and an industry-wide movement towards the power of considering security in the design, Threat Modeling has earned a seat at the table in most Enterprise discussions.

Now the fun begins, as teams must take this threat modeling charter and transform it into an actionable threat modeling program. Consider ten tips for how to build a proper foundation for a threat modeling program in the Enterprise.

Tip #1: Choose a solid process

The first tip is to choose a solid process. For example, you could adopt @Adam Shostack’s four-question framework for threat modeling. The four-question framework is excellent but isn’t a threat modeling process. When thinking about the Enterprise, we need more depth, as we will magnify this process across tens, hundreds, or thousands of Engineers, depending on your organization's size.

A simple process with more detail considers Scope, Draw, Analyze, Mitigate, and Document. With Scope and Draw, you answer Adam’s question, “What are we building?”. The Scope step allows you to help Engineers understand the level of effort involved in a threat model up front and ensures that they are not trying to bite off too large of a chunk per model. Next, Draw leads the Engineer into the Data Flow Diagram representation, based on polling of the Threat Modeling Communities worldwide, and appears to be the most prevalent representation that folks utilize.

Analyze answers the question, “What can go wrong?”. Analyze is the process step where the Engineer considers the potential threats by iterating through a diagram using a methodology like STRIDE.

Mitigate answers the question, “What are we going to do about it?”. In this step, focus on applying mitigations to the identified threats.

Conclude the process with Document, maintaining a copy of the threat modeling output. Storing the work ensures that there is a starting point for consideration when revisiting a model in the future.

Tip #2: Embrace STRIDE

The second tip is to embrace the STRIDE methodology. It is a simple mnemonic methodology (Spoofing, Tampering, Repudiation, Information Disclosure, and Elevation of Privilege). STRIDE is powerful because it is easy to understand and internalize. Use it as a starting point to teach your teams how to threat model and then graduate to more complex methodologies.

Tip #3: Embed Threat Modeling in the SDL well

Threat modeling in the Enterprise is about repeatability. If there is one excellent threat model, ten mediocre threat models, and seven-hundred applications never modeled, the value of threat modeling to the organization is limited.

Embed Threat Modeling as a defined activity within your Secure Development Lifecycle. First, document the process at a high level and mandate the placement of the threat modeling artifacts inside existing deliverables (if they exist). Then, integrate threat modeling into the systems the teams use daily, whether Jira, Asana, or some other tracking tool.

Tip #4: Focus on the mitigations

Getting caught up in the thrill of the hunt regarding threats can be easy. Focus your Enterprise program and your teams on the mitigations. A threat model is only as good as its mitigations.

Measure the mitigations created within all the threat models across the organization. Mitigations are the key to measuring the ROI of threat modeling.

Tip #5: Threat modeling quality checks and governance

Institute a quality control check for each threat model. The security team can perform only some of the quality checks. Utilize your security champions to assist and lower the amount of work this requires for security.

Ask these questions for each threat model. Did the team that created the model follow the defined threat modeling process? Were interesting threats discovered? Did the team properly apply mitigations to those threats? Was the model documented correctly? If the answer to most of these questions is yes, this model gave value to the organization. The answers are not a statement of model quality. Instead, they are an acknowledgment that all models offer value. Don’t be judgmental or harsh; build a strong security culture with your feedback.

After threat modeling reaches a level of maturity inside the Enterprise, extend the SDL to have a governance angle to threat modeling. Mandate the production of threat models at a predetermined scoping level. Enforce threat modeling at the user story level for all new features and refresh threat models every three months when changes exist to the component.

Tip #6: Build a diverse collection of threat modeling champions

The Threat Modeling Manifesto calls out the value of building a diverse group of threat modeling champions. Each role within a team has a different perspective and set of experiences. Product Managers see a feature differently than developers or testers. Embrace a diverse collection of folks, and the quality of your threat modeling outputs will soar.

Tip #7: Workshop the teaching of threat modeling

To deploy threat modeling across the Enterprise, tens to thousands of future threat modelers must prepare. One of the best approaches to teaching threat modeling is the workshop method.

Threat modeling is better caught than taught. The workshop method introduces the concepts of threat modeling at a high level and then dives into performing exercises that put threat modeling into action.

Tip #8: Threat modeling coaches

Threat modeling coaches are security team members or security champions working with groups for a limited time to teach the threat modeling process alongside the team. Coaches are a powerful construct because they magnify the threat modeling process across a long organization, one unit at a time.

Tip #9: Adapt with the additional threat sources

After internalizing STRIDE across the organization, look to other sources of threat to deploy. Additional sources provide more context and fodder for the teams as they consider how to go deeper into the threat modeling discipline.

Application Security Verification Standard (ASVS) from OWASP is one source that gives threat modelers additional threats to consider. Another trustworthy source is Common Weakness Enumeration (CWE) from MITRE.

Tip #10: Adopt the right tool sets at the right time

Tools are essential, but they do not replace the internalization of the threat modeling essence. Threat modeling is a state of mind that the program must teach. After threat modelers grasp why they threat model and how the process works manually, they are ready to embrace threat modeling tools.

Conclusion

Threat Modeling in the Enterprise can seem like an impossible charge. Take the tips, and build or adapt your program to transform every team member into a successful threat modeler.


1 reply

Userlevel 3
Badge

All of these are great points,but I've found Tip 4-6 particularly insightful, especially if you think about them together with 10: it is all too easy to get lost in architectural or other details while modeling with a tool...just to drawn then the teams with zillions of findings. I wish modeller tools (including IR) would have a "beginner mode" with an intentionally limited level of detail of both components and of findings.

That would imho ease new member / beginner on-boarding , while still retaining all the benefits of an enterprise grade tool...

Reply


V2