Threat modeling is the security process by which we can identify, categorize, and analyze the threats. Generally, threat modeling is done at an early stage in the software development lifecycle but it can be performed at any stage whenever there is some change in the architecture or design. The purpose of threat modeling is to come up with the solution for potential harm, probability and to reduce the risk due to the threats. Before we dive deep, let’s start with some questions and some basics. Do we perform threat modeling in our day to day life? Do we know how to perform threat modeling already? The answer is YES. When we are heading out for work, school, or a day out with friends, we check the weather, temperature, to see whether it would be windy or cold or there’ll be chances of rain and prepare ourselves. These are examples of Threat Modeling in our daily lives. We can perform threat modeling if we know the potential threats for a system. Here, the system was a human body, and the threats were the conditions of weather, which may affect the human body.
What is threat modeling for an application?
Threat modeling is a technique that we can use to identify, communicate, and understand threats, attacks, vulnerabilities, and mitigations within the context of protecting software, an application, or a system.[1] It can be used to add security to the design of an application. It enables us to analyze the security at the application design level, though it can be done at any stage of development. The first step in the Software Development life cycle is to embed security. We can also say that security in SDLC starts with Threat Modeling, and this happens even before writing a single line of code.
There are so many ways to perform threat modeling, but the main goal would be to find potential threats within applications, enterprises, and systems.
A threat model includes:
- A design (diagram) of the system; the more detail, the better it is for Threat Modeling
- A methodology that includes a list of assumptions that can be checked. Some of the popular methodologies are STRIDE, PASTA, Trike and VAST
- A list of threats and controls for mitigation
- A way to validate the model and threats, and verification of success of the actions taken
Why Should We Perform Threat Modeling?
Threat modeling can help with the following:
- Build a secure architectural design
- Enact an efficient investment of resources; appropriately prioritize security, development, and other tasks
- Act as a connection between the security and development team
- Identification of the threats
- Putting the security controls in place for the identified threats
- Documenting the threats and controls
- To calculate the cost of control vs quantitative risk
- Threat modeling can provide the assurance for the protection of the business
- Identify security test cases/security test scenarios to test the security requirements
The simplest way to start threat modeling is to answer these four questions:
Most threat model methodologies answer one or more of the following[2] questions:
1. What are we building?
This is the information gathering phase. Here you try to find information related to the product you are building or the system. To do this, you can either use architecture diagrams or you can also start with a team on a whiteboard in one of the meeting rooms. Even though threat modeling only begins at this phase a focus on information gathering helps define scope and bound problems.
Key points of this phase:
- Architecture diagrams
- Data Flow diagrams
- Data classification
- The gathering of people from different roles with sufficient technical and risk awareness to agree on the framework to be used during the Threat Modelling exercise.
- Brainstorming with technical architects to understand the system
- Defining the scope
2. What can go wrong?
We have gathered information in the previous phase. We also have Architecture details and diagrams, and now we can start thinking of what can go wrong. Anyone can perform threat modeling, but we should know the kinds of threats which might affect any given system. This is a research activity in which you want to find the main threats that may apply to your application. There are many ways to approach the question, including brainstorming or using a methodology to help think it through. Some of the Threat Modeling methodologies are STRIDE, PASTA, Kill Chains, CAPEC, and others.[3]
Key points at this phase:
- Try to think of all possible threats
- Research on potential threats to the technologies you are planning to use
- Note down all the threats
- Don’t ignore any threats for the time being
3. What are we going to do about that?
In this phase, we will try to figure out the mitigations for the threats found in the previous stages. We should strive to find protection against each and every potential threat. There are four kinds of actions we can take against identified threats:
A. Mitigate the Threat
Mitigating the threat means implementing some control so that the threat cannot be exploited. Here is an example: You don’t want everyone to utilize some part of a website, so you put a strong authentication mechanism in place to avoid everyone gaining access
B. Eliminating the threat
Elimination of threats is defined as completely removing something that you think cannot protect by any mechanism. For example, let’s say there is an Admin function for your website. Even after putting a strong authentication in place, you feel that the threat is still there, and you don’t want to take a chance. In that case, you will just remove admin access to the website from the web.
C. Transferring the threat
In this step, you transfer your risk to someone or something else.
D. Accepting the Risk
Here you just accept the risk as it is. There can be many reasons for this, like budget issues, or maybe the cost of addressing the threat is way more than the expected loss. So you accept the risk and move on.
4. Did we do a good enough job?
Now it is the time to ensure that every control is in place to address all the threats. This is the time to go through everything once again and check the data flow, control flow, threats, and the way to address them.
Key points:
- Ensure that there have been no alterations in the architecture diagram
- Ensure that all the threats discussed are there on the report
- Ensure that all the controls that are discussed displayed on the threat model
- Go through the whole flow and architecture diagram once again with the respective stakeholder
- Test your model again
References:
- Threat Modeling Designing for Security by Adam Shostack
- OWASP Application Threat modeling https://owasp.org/www-community/Application_Threat_Modeling
- Threat Modeling : 12 available methods https://insights.sei.cmu.edu/sei_blog/2018/12/threat-modeling-12-available-methods.html