Threat Modelling an Application as a Dev Team

What is threat modelling?

Threat modelling is the process of identifying, communicating and understanding threats and mitigations within the context of a software application. It is essentially a structured representation of all the information that affects the security of an application. Threat modelling enables informed decision making about application security risk.

In a nutshell, it is the process of drawing a data flow diagram to represent your application, then taking each of the elements and interactions within the diagram and identifying security risks.

Ultimate Goal = Security risk reduction

Why should you use threat modelling?

The reason threat modelling is so valuable compared to other risk reduction strategies like Architectural Risk Analysis, Source Code Analysis, Vulnerability scanning or Penetration Testing is that it is:

• A Proactive Approach
• Very efficient
• Easy to prioritise issues raised
• Greatly improves wider team understanding of the application due to the creation of data flow diagrams

When to perform threat modelling?

As part of shifting your testing efforts left, security testing techniques such as threat modelling should come as early in the process as possible.

The initial threat model is likely going to be drawn up during your design phase, which will possibly lead to some security requirements.

As you move through the agile process (assuming you are working in an agile environment), threat modelling should be conducted on a sprint by sprint basis. These threat modelling exercises make sure that security remains central to the development process throughout the whole life cycle.

The development team as a whole will generally be involved in the threat modelling exercise.

What are the core approaches to threat modelling?

There are three core approaches to threat modelling, although there are many methodologies within each of these. The three approaches are:

• Asset-Centric or Risk-Centric Approach - where you focus on the assets you want to protect
• Attacker-Centric Approach - where you use the attackers mindset to threat model. This is closely coupled with traditional penetration testing and usually requires team members skilled in security to be effective
• Application-Centric Approach - this revolves around the application you are developing. When working on development teams without a security specialist or where the team does not have vast security knowledge this approach is seen as the most effective. It focuses on the application itself and identifying the risks within it.

On a high level the Application-Centric approach works as follows:

1. Create one or multiple Application Diagrams (data flow diagrams etc.)
2. List the threats for each element/ interaction
3. Rank the threats identified using a classification system (in this case we will be using STRIDE)

How to perform Application-Centric Threat Modelling?

Microsoft Threat Modelling (STRIDE)

Using Microsoft’s Threat Modelling framework, we are able to create a better understanding of our application whilst simultaneously reviewing the security threats in our application. This framework is one of the most widely adopted approaches to threat modelling and is lightweight and easy to follow.

For more info see https://www.microsoft.com/en-us/securityengineering/sdl/threatmodeling

Microsoft has also provided a free to use threat modelling tool which supports diagram creation and can be downloaded from their website. This tool is great for speeding up your process but also has lots of added extras which can add value.

Steps:

1. Firstly, list all of the Assets of your application, including things like servers, databases, APIs etc.
2. Set which of these assets are in scope and which are not. For example, your current project may use assets of which you have no control over as a project team, therefore, you may consider this asset out of scope. The scope entirely depends on how your team want to approach the modelling and can often change over time. Although, it is important to avoid scope creep. There is rules as to scope, however, it is generally easier to start higher level as data flow diagrams in the next step can become complex very quickly.
3. Draw data flow diagrams which match the items in scope. Identify what the application is and what it does as well as the technology used. These diagrams should be easy for others to pick up and understand. Using the microsoft tool here can help make this step a lot quicker and easier. These diagrams can also become very useful for other activities not related to the threat modelling process.
4. Analyse the target application and write a security profile. A security profile asks questions such as Which security standards apply to the application based on organisation standards? Are these standards met? etc.
5. Identify the threats using the STRIDE model on each element/ interaction. By going through each you should be able to identify some threats. This is likely something your team will become better at over time so don't get frustrated in the intial stages. Can you spot any opportunities for an attacker to carry out any of the following:

• Spoofing - impersonating something or someone else i.e. stealing as session id
• Tampering - changing a request in flight or changing data without authorisation
• Repudation - ability to deny you have done something
• Information Disclosure - seeing data you are not authorised to see
• Denial of Service - preventing authorised users from using the service by taking down a web server for example
• Elevation of Privilege - gaining access to system privileges you should not have access to

6. Once you have a list of threat identified, the next stage is to document them. You should provide at least three bits of high level information about the threat. These include the Target of the attack, the Attack Technique and the Countermeasure you would put in place to mitigate the threat. Add any other relevant info you deem necessary.

Once you have completed this exercise you should now have a list of well documented threats.

7. Finally, you need to rate the threats. By using the DREAD risk assessment model you can clearly identify which of those risks are actionable immediately, and which of those your team may not be too worried about. Go through each of the following and give a rating of Low = 1 point, Medium = 2 points, High = 3 points.

•  Damage potential - how bad would an attack be?
•  Reproducibility - how easy is it to reproduce the attack?
•  Exploitability - hwo much work is it to launch the attack?
•  Affected Users - how many people would be impacted by the attack?
•  Discoverability - how easy is it to discover the threat?

Once you have completed these all of the threat modelling steps you should have a list of Assets, a Data Flow diagram for the application, a list of threats identified, and threats rated by risk. These can now be organised into requirements or bugs to fix. Note that not all threats will be considered worth actioning but it is still worth documenting these to show that they have at least been considered.