Introduction to Threat Modelling

I recently attended an AWS Security GameDay which is a gamified learning event that challenges participants to use AWS solutions to solve real-world technical problems in a team-based setting. Part of this was learning about threat modelling and how to do it, so I thought I’d share my learnings & experience.

Our Team at the AWS Security GameDay

Before we start, here are some important definitions:

Threat: a potential event that could cause harm or damage

Threat actor: an entity with motive to carry out malicious activity to achieve specific goals

Prerequisites: a condition that must be true for the threat to be achieved

Threat Impact: the extent or severity of damage that could result from a successful threat

Impacted Goal: an outcome that may be affected by potential threats such as reduction in information security principles — confidentiality, integrity or availability.

Impacted Assets: resources, system, data or infrastructure within an organisation that may be affected by threats or vulnerabilities

Threat Statement: a concise description of a potential threat

A threat statement typically looks like:

An actor with prerequisites can threat which leads to threat impact resulting in reduced impacted goal of impacted assets

Mitigation: a measure/action taken to reduce the risk of a potential threat of vulnerability, typically you can devise this from threat actor, prerequisites, and threat

Vulnerability: a weakness or flaw in a system/software/process that can be exploited by threat actors

What is Threat Modelling?

Threat modelling is an iterative process which identifies security requirements, threats and vulnerabilities. This information is then used to quantify the criticality of threats and vulnerabilities for you to prioritise remediation methods and mitigate against potential attacks.

Why Use Threat Modelling?

• Identifying Vulnerabilities: threat modelling helps identify potential vulnerabilities that could be exploited by attackers
• Mitigation Planning: threat modelling improves security controls to mitigate against potential attacks or threats
• Risk Management: by identifying threats & vulnerabilities, you can prioritise remediations and efforts to the most critical risks
• Early Detection: threat modelling allows you to address security threats early in the lifecycle of a system/application, which will reduce the risk, cost & effort required to fix security issues later in the development process. Ideally you should threat model early, do it often, and it’s never too late to start.
• Improve Security Practices & Collaboration: threat modelling allows teams to better understand the security implications of design decisions, helping architects, developers and security to improve security knowledge and practices across teams/organisations
• Compliance and Regulatory Requirements: threat modelling helps organisations meet requirements by identifying security risks & implementing appropriate controls to address them
• Continuous Improvement: threat modelling is iterative and evolves with changes in the system or as threats emerge, which helps organisations adapt to threats and vulnerabilities

How to Threat Model:

1. Decompose:

Can we break this down into smaller parts?

The portion you are threat modelling should be aligned to what you are delivering in your project increment, for example in your current sprint. If we look at things in smaller sections we are more likely to look at it in more detail. This allows us to uncover more areas of improvement where we can mitigate additional threats — and also stops the task from seeming overwhelming if we have a complex architecture!

This step also allows you to reuse sections of the threat model, for example if you are threat modelling a tool which is used across different applications, decomposing will allow you to reuse this threat model.

Finally, looking at mitigations for every decomposed area, we are likely to end up mitigating the same threat at multiple points of our application, in other words defence in depth. By adding multiple layers of security measures, you create a more resilient and robust defence against potential threats. Each layer adds an additional barrier, making it harder for attackers to exploit vulnerabilities and penetrate the system.

2. DFD: Data Flow Diagram

What are our data flows?

This is a process whereby you identify what the entry points are, where the data is stored/processed, where the data leaves the system, and ultimately allows you to identify critical points in the system. The focus here is how data moves through the system and what happens to the data as it is moved.

3. Identify a list of threats

What can go wrong?

Understanding what can go wrong requires collaboration between all members of the team, not just security specialists, to understand the entire process, it’s purpose and the potential vulnerabilities.

There are different methods to help identify threats, here are some of the more commonly used methods:

• STRIDE: an acronym used to categorise different types of threats. Each letter in “STRIDE” represents a different category of threat:

1. Spoofing: Pretending to be someone or something else.
2. Tampering: Unauthorised modification of data or systems.
3. Repudiation: Denying involvement in an action.
4. Information Disclosure: Unauthorised exposure of sensitive information.
5. Denial of Service (DoS): Disrupting availability for legitimate users.
6. Elevation of Privilege: Being able to perform operations you aren’t supposed to be able to do, for example violating authorisation.

• Using an existing threat list: for example, you can use OWASP Top 10 or your organisations threat catalogue
• Think about your threat actors: could they be internal/external, what are their goals, what are their motivations

4. Identify mitigations per threat

What are we going to do about it?

A key theme across threat modelling is collaborating with the wider team, and again is important here to understand all the inputs to identify threats, actors and areas of improvement. Consider your own code & code dependencies and what you could put in place to mitigate against the threats.

Who is responsible for doing something about it?

In terms of AWS, AWS Services offer security controls like log monitoring, data protection and identify and access management. It’s important to think about the shared responsibility model & what you are responsible for compared to AWS – as AWS would say, “AWS is responsible for the security OF the cloud, users are responsible for security IN the cloud”

Example:
During the AWS GameDay we went through the example below.

What are we building?

A connected vehicle solution that will be used for fleet management.

Can we break this down into smaller parts?

As you can see, the architecture is fairly complex and it can be overwhelming to try to tackle a threat model in one go; threats & vulnerabilities could easily be missed & subsequently exploited.

Let’s take a smaller section:

Here, we have a web browser that will be used by a fleet manager.

What are our data flows?

We expect here for a fleet manager to open a web browser to input vehicle data:

1. AWS Amplify which will contain static assets (for example HTML, Javascript, CSS) to render the webpage.
2. Amazon Cognito authenticates the user
3. The fleet manager inputs a vehicle registration which goes through Amazon API Gateway to interact with the backend created by Lambda to store data in DynamoDB & an S3 bucket

It’s important to note that there might be additional data flows which would include logging data such as CloudWatch logs or CloudTrail which you would need to include if you are using them.

What can go wrong?

An example here of what could go wrong would be a potential DDOS attack (Distributed Denial-of-Service where an attacker floods a server with internet traffic to prevent users from accessing connected online services and sites).

You could then put together a threat statement with all this information:

You would repeat the thought exercise until you have a long list of threat statements, which can then be prioritised to decide which to mitigate first. It’s again important to collaborate with the wider team, so make sure to include a mix of product owner, architects, developers and security subject matter experts (SMEs).

What are we going to do about it?

There are 4 potential options to explore; mitigate, avoid, transfer or accept the risk. You should use your threat statement to help identify potential mitigations.

If we take our example threat statement:

We could potentially add a Web Application Firewall (WAF) to restrict access to our offices and enable AWS Shield Advance.

How do you know if you’ve done a good enough job?

The level of detail from your threat model should match your design documentation. A good place to start is the worst case scenario, and to work backwards from there. Finally, iteration should mean that you continue to build threat scenarios related to your system.

For more information that I found helpful on threat modelling, AWS have some great resources which include this training available on AWS skill builder, this article on threat modelling or this video from AWS Summit 2021. You can even check out threat composer which is a tool to help you build your threat statements.

Thanks AWS for a great GameDay, and I would highly recommend others to try it out — happy threat modelling!