What is Threat Modelling?

An important first step in learning about and performing threatmodelling within your (DevOps) team is to know what threatmodelling is (and to be able to answer the ‘what is threat modelling’ question).

Threat modelling is an activity, which you usually perform within a (DevOps) team, to systematically think about security of a system (i.e. an application, a network, a hardware device, a process, etc.), including its threats, weaknesses and countermeasures.

The goal of threat modeling is to improve the security of an application or system through better understanding of security as a team, and to understand potential gaps which should subsequently be mitigated through (additional) countermeasures.

Key concepts and characteristics of threat modelling:

- It can be applied to applications, hardware, software or pretty much anything that requires security measures. Even fancy things such as Internet of Things, AI, or classic business processes can be threat modelled.

- The activity results in a ‘threat model’, which contains the understanding and learnings of the activity. The threatmodel should be stored somewhere so it can be re-used and improved upon in sessions.

- It is an ongoing activity that should be performed periodically or with major changes to the object in scope (i.e. an application).

- It is a team activity that works best when multiple points of view are considered. Think about input from business owners, product owners, developers and operations / DevOps members, security specialists, test specialists, risk specialists and whoever else is ‘on the team’ within your business.

- It can be relatively high level (where security concepts are thought about at a high level) or low level (which is very technical with very specific security threats and countermeasures).

‍

Threat Model Object in Scope

Threat Modelling can be performed on a wide range of objects. Typically, it is used on (web) applications, apps and distributed systems.

But it can be performed on pretty much anything that requires security. This includes things like Artificial Intelligence (AI) models and usage, Internet of Things objects or solutions, business processes or processes in general, technical products, non-technical products, and more.

It is important to clearly define and understand the object in scope, and to even describe it clearly in a threat model. This helps all team members involved in the threat modelling to understand this (which is important because it’s a team activity).

The type of object in scope (e.g. whether it’s a web application, or an app, or a distributed system) will have a big impact on the threatmodel by virtue of the security concepts being very dependent on the specifics of the object.

Threat modelling is very context specific, meaning that you can understand the specifics of security within your application and the application space, and that’s also exactly the added value of performing threat modelling. Think about the security concepts you need to think about if you are protecting an internet banking application versus a social media application. As you can imagine, they should differ a lot (although they can share security concepts as well).

‍

What is a Threat Model?

A threat model is something you create during the activity of threatmodelling. Or put another way, a threat model is the output of threatmodelling.

Key concepts and characteristics of threat models:

- A threat model relates to the object in scope (e.g. your application, your system, etc.).

- A threat model contains information about the object in scope, such as a diagram, which components are in scope, which threats have been identified, which countermeasures have been identified, etc.

- A business, a business unit, or a team can (and should) have multiple threat models related to various applications, processes, etc., that are relevant to the company.

There isn’t a single definition or single way to produce a threat model. So different companies and different teams may have different ways of creating a threat model. There’s no right or wrong way to create a threat model. A good threat model will be able to ‘answer’ the key security questions related to your ‘object’ in scope.

‍

Threat Modelling is an Ongoing Exercise

Threat modelling, and the associated threat model is never really finalized. Rather, it’s a living and breathing model that changes as your understanding of security and your application changes (or grows).

Another way to look at it: consider threat modelling as a part of your development lifecycle, also known as Software Development Lifecycle (SDLC). Software development has a lifecycle and security (with the help of threat modelling) should be a part of it from start to finish.

It’s up to the team to decide when specifically threat modellingshould occur. The following should be considered:

- Threat modelling should occur periodically, e.g. every month or quarter.

- Threat modelling should occur whenever a major change is planned (prior to making the change).

‍

Threat Modelling is a Team Activity

Typically, (DevOps) teams are responsible for applications, systems or processes. And teams are made up of individuals with different roles. A typical team may include a business owner, a product owner, a developer, an operations person, a tester, a security person, and so on. All these various roles and people have different points of view, and crucially they may know different things about the application or system in scope of threat modelling.

These different views provide input into the threat modelling process. It is best to have as many different points of view working together to build a threat model, rather than to rely on one or two points of view.

For example, if only a developer and an operations person were to work on threat modelling, you would likely end up with a very technical exercise that may not capture business input and insights. Therefore, the threat model would miss critical information and would be ‘incomplete’.

Furthermore, threat modelling as an exercise helps to spread information within the team with regards to security.

‍

Level of Detail can Vary

The level of detail and granularity of threat modelling can vary greatly.

For example, you could have a threat model that is very high level which focuses on general security concepts related to the object in scope. Or, you could have a threat model that is very detailed and technically focused, with many potential threats and countermeasures.

There’s no right or wrong answer with regards to detail. And considering that threat modelling is a process that continues as the development lifecycle continues, it could change in detail as time goes on.

‍

What does a Threat Model Include?

A threat model should include a number of key pieces of information:

- A high-level description of the object in scope (could be a description of the application, system or process). An outsider, such as a future pentester, should be able to understand what the object in scope does, why it exists, etc.

- A list of potential threat actors relevant to the object in scope. This doesn’t have to be an exhaustive list, rather it should focus on the most likely people ‘to do bad things’ to your application, system or process.

- A list of targets or valuables that an attacker would want to gain or manipulate. This describes the things that a potential attacker (as described by your threat actor list) would want to go after and attack.

- An overview of assumptions that apply to the threatmodel. The assumptions help you to scope the exercise and to focus on what’s important. For example, you could assume that an application is only available on an internal network for employees. Therefore, you don’t have to pay attention to all the threats and countermeasures that are related to keeping an unwanted individual from accessing the internal network (hopefully other parts of the business would focus on that).

‍

Threat Modelling Tools

Threat modelling can be performed using little or no tooling at all. In that case you would probably use only a white board (or digital equivalent), and you would focus on following a methodology/threatmodelling process.

There are many threat modelling tools that help in performing threatmodelling. Examples include IriusRisk and ThreatModeler. There are many advantages in using a threat modelling tool, including:

- Availability of templates for common architectures and scenarios, which leverages prior common knowledge (such as common threats and countermeasures).

- Integration of productivity tools such as Jira and Azure Boards, which allows developers to create actions and stories as follow up from threat modelling insights and learnings.

- Integration of code review tools, meaning that learnings from various tools can be integrated into the threatmodelling process, as well as tracking/remediation of identified weaknesses.

- Easily saving and storing threat models so that teams can access them at later stages (or whenever work is continued on the threat model).

- Easily involve many different people in the process, such as pentesters, security and risk specialists, etc.

‍

Threat Modelling Methodology

There are many threat modelling methodologies available. These methodologies help to ‘systemically’ perform threat modelling as opposed to freely thinking about threat modelling (which may lead to gaps in the process).

Threat modelling methodologies include:

- STRIDE

- Trike Threat Modelling

- OCTAVE

- VAST

- P.A.S.T.A.

Choosing the right threat modelling methodology can help to improve the quality of the threat modelling process and result.