Secure software development requires a ‘shift left’ — paying attention to security and privacy early in the life cycle. Threat modeling is a very useful activity for achieving this goal, but for a variety of reasons, organizations struggle to introduce it.

Last year, a group of industry and academy experts got together with the goal of looking at the current state of threat modeling and putting together a threat modeling manifesto — what we consider to be a good practice and how to get there. One challenge we set ourselves was to be brief: it should be printed as one page and displayed in a team space. To achieve brevity, we had to omit some details, of course. In the five months since we published this, many interesting questions have appeared online.

To answer some of these questions, I am going to go over the guidance from the Threat Modeling Manifesto and fill in some of the details and rationale behind the values, principles and patterns.

Values of Threat Modeling

If you are familiar with Agile Manifesto, you know how it works: while there is value in the items on the right, we value the items on the left more.

A Culture of Finding and Fixing Design Issues Over Checkbox Compliance

Compliance is important. There is nothing wrong with starting from the point of ‘I need a threat model to keep my auditors happy.’ But there is much more that threat modeling can do for you. It’s one of the aspects that contribute to the overall security culture that everyone wants to have, but few get to enjoy. So you should not stop with compliance, but leverage threat modeling to shift left.

People and Collaboration Over Processes, Methodologies and Tools

The manifesto is intended to be agnostic on all the items on the right. If you get the relevant people together and find a way for them to work together, they will align on all of these. Picking a methodology or a tool before building up the culture of teamwork will force you to obey its quirks and limits, rather than knowing what works and choosing the tools and methods that will make this work easier.

A Journey of Understanding Over a Security or Privacy Snapshot

We talk about threat modeling rather than threat models, and the distinction is much more than a point of grammar. If you want to get deep, the journey itself is more important than any destination.

Doing Threat Modeling Over Talking About it

Is it a value or an anti-pattern? Either way, it comes from the knowledge of almost all the authors of the manifesto: time spent deciding the ‘right’ way to do threat modeling would be much better spent doing it.

Continuous Refinement Over a Single Delivery

This is something I don’t tire of repeating to anyone who will listen: do threat modeling once, and you just have an expensive piece of documentation. Most of the value comes from changing the model and evolving it together with the software it represents.

Principles of Threat Modeling

The best use of threat modeling is to improve the security and privacy of a system through early and frequent analysis.

Does this mean that on an existing system, if we didn’t start early, we’ve missed the boat and there is no point to start now? Certainly not! In one of the Open Web Application Security Project summits, we came up with an answer to the question, ‘When is the best time to perform threat modeling?’ The answer: ‘The sooner the better, but never too late.’

On any given day, most development teams in the world are working on changes to existing software, not starting a greenfield project. It is essential they introduce threat modeling instead of waiting for the next project or even the next major release.

Frequent analysis allows you to tackle small chunks without becoming overwhelmed. It also helps you to keep the work time-limited, which is essential for fitting it into modern software development. Remember the benefits of ongoing integration? Not doing threat modeling often is the same as sitting on a long-lived isolated feature branch.

Threat modeling must align with an organization’s development practices and follow design changes in iterations that are each scoped to manageable portions of the system.

This question pops up all the time: tell me the best way to organize the threat modeling process. And the only honest answer is that it depends on how you organize other processes. I think anyone who promotes the one best way that suits everyone is missing the point.

The outcomes of threat modeling are meaningful when they are of value to stakeholders.

What are the ‘correct’ outcomes of a threat modeling session? Maybe you’ve guessed the answer by now — it depends. Who are the stakeholders and what do they need to gain value from the exercise? For some, the prioritized list is a must. For others, the threat modeling feeds a higher-level risk management process, and putting it first here would be a waste. Some teams will be happy with a high-level threat description. Other teams need to bring it to life with an attack tree tailored to their tech stack.

If it’s useful for you, then it is a good outcome. One typical sign of a low-value outcome of threat modeling is that it doesn’t influence any decisions further down the line of the process. If nothing ever is changed in the design, no other test cases are written, and no other controls are added, what are you gaining?

Dialog is key to establishing the common understandings that lead to value, while documents record those understandings and enable measurement.

Finding the right amount of documentation for your threat models will take time. Don’t add formality before you need it, but equally don’t spurn the idea of documentation. Common knowledge might be easy to maintain with a small co-located team, but you don’t want it lost or diluted as the team grows or shifts to remote work.

Patterns and anti-patterns are hopefully less abstract and easy to apply in a practical way. I want to highlight just one of them.

The Right People for the Job

Varied Viewpoints: Assemble a diverse team with appropriate subject matter experts and cross-functional collaboration.

This pattern helps to put the right set of people in the (maybe virtual) room. Who needs to be involved in a threat modeling session? At the very least, you need enough subject matter experts (SMEs) to answer the four questions for threat modeling. Consider the following (not exhaustive) list of what is useful to have (assuming you are modeling a software solution):

• Understanding of the architecture
• Knowledge of the current (or planned) technical stack
• Security knowledge — general for the problem space (web? mobile? Internet of Things?) and specific for the history of attacks on your solutions
• The production environment and the pipeline to get there
• Business context
• Privacy needs for the data you handle
• QA  — how can you test the threats you come up with?

The exact list of SMEs will vary depending on the structure you have and the overall development life cycle. In the approach to threat modeling we use with our clients, we combine defensive and offensive perspectives, bringing consultants from our application security practice and pen testers from X-Force Red.

We hope you now have a better picture of what is required to get started and how to sustain threat modeling to get the best benefit.