While working on the Product Development team, I never once heard about Threat Modeling. Then a couple of months after I joined the Application Security team, a colleague introduced me to the term — which I mistakenly pronounced “Thread Modeling” after years of dealing with the Java Concurrency model. Threat Modeling itself is intriguing and creates interesting challenges when you consider applying it on a large scale.

What is Threat Modeling About?

Threat Modeling is a methodology that involves systematically analysing system designs. The objective is to identify security risks and come up with possible mitigations. As computing software evolved, so did the need to protect IT systems from malicious individuals trying to exploit security vulnerabilities.

From the first attempts to protect software from cyber-attacks in the early 1960s, to a formal introduction of the concept in 1994, Threat Modeling has been on a long journey to reach its current stage of maturity. Nowadays, many big books are dedicated to the topic, and the community of practitioners is well established.

In November 2020, the Threat Modeling Manifesto was published by a group of 15 community leaders to provide clarity on the subject, as the key principles of Threat Modeling are commonly misunderstood.

Key Principles

Threat Modeling is a collaborative and frequently creative process executed by a group of people involved in the creation of an application. This process includes asking four questions:

• What are we working on?
• What can go wrong?
• What are we going to do about it?
• Did we do a good enough job?

At TWS, we are working towards making Threat Modeling common practice. I’ll now explain what our sessions have looked like so far.

Threat Modeling at TWS

Once the initial preparation of the project is finalised and everyone has a good understanding of what is going to be built, we gather for a brainstorming session. The group of participants might include Architects, Software and Quality Engineers, Product Managers, Business Analysts and AppSec team members. We usually start by reviewing the system architecture and establishing a common understanding of the feature being built, as well as the key flows and assets.

The next step is to elaborate on our Doomsday scenarios. They are hypothetical situations: the worst thing that could happen for an application and for a business. Having people of different roles in the group helps to produce a diverse set of situations. It is important to write down all the ideas.

The process then involves in-depth technical analysis of potential threats and ways to address them. It usually requires several sessions to produce meaningful and actionable outcomes. Making Threat Modeling an incremental and continuous process, adjusting details while the project evolves, is the foundation for success.

STRIDE

Up until now, I haven’t experienced any two Threat Modeling sessions to be alike. Every time the conversation evolves down its own unique path. The moment when we start to identify threats is special, as the audience isn’t always productive in identifying and enumerating risks. It usually requires a lot of practice to develop a sharp security-critical mindset. Fortunately, there is a useful and rather easy approach to use called STRIDE, which helps to drive the conversation.

STRIDE is a model of threats that helps structure the thinking process during Threat Modeling sessions. I always use the following cheat sheet to remind myself of what each part of STRIDE is about:

Tools

Tools are very important, and there are various options available to choose from, such as:

• Diagramming tools, like OWASP Threat Dragon and Microsoft Threat Modeling Tool
• Advanced platforms, providing threat intelligence and rich sets of features, like IriusRisk and Cairis
• Elevation of Privilege (EoP) card games, like Elevation of Privilege

For example, the following diagram was generated using IriusRisk tool:

The Way to Adoption

On the one hand, introducing Threat Modeling in the SDLC seems natural, as considering security risks and protecting a system from threats is absolutely necessary for every application. On the other hand, we see that achieving useful results requires significant time and mental efforts not only from the AppSec team, but also from the engineering teams. The classic challenge of maximising value generated while minimising effort is very relevant to Threat Modeling.

From what we’ve learned in our initial sessions, we’d suggest the following:

• Carefully choose time and audience to kick the process off
• Prepare well before the session and bring some pre-prepared threats with you
• Ensure to have a Leader and a Scribe, i.e. someone to drive the session and someone to take notes

Findings from a Threat Modeling session tend to be varied. Some are very standard, like TLS everywhere. For other findings, we discover well established protections, like 2FA and anti-bot mechanisms. The most interesting group of threats are the ones we do not yet have experience in mitigating. They are also the hardest to address as they demand more time.

One way to make Threat Modeling effective is to build a library of standard security protections. This approach provides engineering teams with a toolset to apply in every project, while the AppSec team can focus on finding solutions to new risks.

Want to try Threat Modeling out? Starting is easy, just ask yourself this key question: “What can go wrong?”