Hi there.

Welcome to the November edition of Threat Modeling Insider!

Again, we have a diverse line-up for you, containing some blog posts, learning materials, podcast and even a new community:

• Guest blog: Five tips to improve your threat model, by our guest blogger Simone Curzi
• Curated Content. “How to threat model digital applications in Cloud”, by Jeevan Singh, Director of Product Security at Twilio.
• Curated Content: “Threat Modeling the right way for Builders Workshop”
• Curated Content: Kubernetes Threat Model and Risk Management webinar
• Christmas comes early this year…
• Toreon tip: Threat Modeling Connect, a new community

Happy reading!

Seba, Steven, Thomas

What makes a threat model great

Many know what a Threat Model is; some have already done a few of them, but few understand what makes a Threat Model great. The problem is that Threat Modeling is a complex process based on a few deceivably easy steps. One of the best descriptions of those steps is summarized within the Threat Modeling Manifesto with Adam Shostack’s four questions model:

1. What are we working on?
2. What can go wrong?
3. What are we going to do about it?
4. Did we do a good enough job?

For example, the first question requires you to understand the system under scrutiny. What does this understanding entitle? Is it enough to draw a diagram? What degree of detail is needed?

Most approaches nowadays tend to favor the creation of a diagram and rely on some automation to analyze it piece by piece. By doing that, they miss two essential parts: the understanding of the business implications of the solution in scope and a comprehensive view of the solution, which means that the analysis is not holistic and misses the threats exploiting the system as a whole.

The situation is so severe that we are starting to see Business teams at various organizations questioning Threat Modeling because it fails to provide significant value for the cost, particularly when compared with what can be achieved by other means, like SAST, DAST, or penetration tests.

The most obvious answer to this issue is to further accelerate the Threat Modeling process, typically by relying on automation to reduce costs and get a more favorable return on the investment.

I do argue that this is not the right approach. By doing that, we are reducing the Threat Models’ value to the point that it may become marginal. But what does value mean for Threat Models? It may be defined as the ability to provide enough information to drive decisions and prioritize the implementation of the necessary mitigations.

During many years of experience as a Threat Modeler, I have identified a few essential practices to improve the quality of the results and provide tangible value to the development teams and business decision-makers. I have collected five of them here.

(There is so much more we can do, though! For starters, you may want to read a paper I have written with fellow experts, which is freely available.)

Two different approaches to Threat Modeling

Before starting to discuss those practices, included here in the form of tips, it is essential to clarify that there is no single way to perform Threat Modeling. On the contrary, there are many. For our purposes, it is enough to introduce two main categories:

The first one can be referred to as Cooperative Threat Modeling. With this category, development teams are directly involved in performing the Threat Model. They do the Threat Model during sessions held every Sprint and involving the whole team. This approach works better with small Agile teams and is discussed in Izar Tarandach and Matthew J. Coles’s Threat Modeling Book.

Another approach is the one I call Expert-led Threat Modeling. It is based on having an expert who uses interviews and documentation to analyze the system and produce the Threat Model. This approach is discussed in various places, including a book titled Designing and Developing Secure Azure Solutions which I have co-authored with Michael Howard and Heinrich Gantenbein.

Tip 1: Prepare yourself

In the good old days, it was relatively simple to analyze systems. You could choose between limited technologies and architectures, and interactions between systems were relatively rare. Nowadays, things are much more complex. So much that even after years of experience, almost all projects introduce something new. Therefore, you need to organize your work accounting for the need to prepare. This typically means that you must have an initial call with the Architects to gather some basic information about the system in scope and the involved technologies. Then, you should identify gaps in your preparation and fill them before the following steps. You should also include some time during the Threat Modeling exercise to explore eventual open points further.

Tip 2: Do multiple sessions

The second tip is linked to the first one. During the interactions with the team, you will gather information. Sometimes this will be about details you ignore. In other situations, you will get discording answers. And, more often than not, you cannot cover all the required scenarios. The bottom line is that you will need to plan for multiple meetings on different days. I usually interval them by one or two days to give me time to analyze the answers and identify further questions for the following discussion.

Tip 3: Be (self-)critical

Threat Modeling is not dissimilar from investigating a crime. For example, if someone from the team tells you that something is secure because they are using some third-party software, you shall not accept that as an absolute truth. As a Microsoft employee, I have seen this sort of statement too many times to count. It all depends on how you are using it. Adopting a library may be fine for a scenario and a mistake for a different one. Understanding that is not easy. It requires being critical and asking questions to get enough clarity.

It is also essential to recognize our shortcomings. We do not know everything, and even what we know as truth may be considered wrong six months from now. Nowadays, technology changes so fast that it is a frequent occurrence.

You can find more details in a blog post I published a few years ago.

Tip 4: Clearly define the scope

One of the most frequent issues with Threat Modeling is that the target system is evolving. If you are analyzing a Product under development, should you examine how it is now or how it will be in the future? The correct answer varies case by case, but you need to clearly state what is in scope at the start of the activity and then stick with it for the duration of the analysis. If you do not do that, the result will be confused and confusing.

For example, suppose you are Threat Modeling a system developed with an Agile methodology. In that case, you may want to focus on the capabilities developed during the Sprint.

Tip 5: Understand the business need

Finally, it is essential to ensure that the Threat Model considers the Business implication of the solution in scope. This is because the threats depend on the data managed by the solution and their severity depends on the Business scenario. A web portal has very different characteristics than an OT system. Still, in most cases, severities are based on abstract scenarios, with the result that the security investments may be focused on marginal issues while significant ones are left unmitigated.

Conclusions

Threat Modeling has the potential to be the single most effective approach to security. Michael Howard said about 20 years ago that “if we had our hands tied behind our back (we don’t) and could only do one thing to improve software security… we would do threat modeling every day of the week”. This still stands, but we are facing new challenges due to the increasing awareness of security and its costs. Automation remains essential to contain costs, but it’s not enough. We also need to improve the quality to deliver to the Business and the development teams the value they need.

Podcast: How to threat model digital applications in Cloud, by Jeevan Singh, Director of Product Security at Twilio

Course: Threat Modeling the Right Way for Builders workshop

As a valued reader of our newsletter we have a special gift for you.

The goal of our hybrid Threat Modeling Practitioner training is that you will learn to create and update your own threat models.

Register or refer a friend (*) to the training and get your early Christmas gift:
the great book “Threat Modeling: A Practical Guide for Development Teams” by Izar Tarandach and Matthew Coles.

Grab this unique offer and register now with code TMI-BOOK!

On November 17th, the Threat Modeling Connect, a new TM community, officially launched. The community will facilitate events, articles, and forum discussions on threat modeling. Join now!

We aim to make this a community-driven newsletter and welcome your input or feedback. If you have content or pointers for the next edition, please share them with us.

Kind regards,
Sebastien Deleersnyder
CTO, Toreon