What is Threat Modeling?
Threat modeling is the process that helps engineers and security specialists anticipate potential attacks on a system by building models using the software design or already implemented software. Its main goal is to identify the most probable attacks and define mitigations or remediations for them. After building the model we apply the threats to it. A model is the architecture of a system/software/process. Threat models help identify security problems and look at them with a bigger picture rather than just the code itself. It helps to identify issues in software or systems that aren’t built yet and anticipate the threats that can affect the system and the business. The purpose of threat modeling is to increase awareness about the way a system works. It should be done in the early stages of development when potential threats can be detected and mitigated fast, preventing a bigger cost for the later fix. This process is broken up into three steps: data collection (External Dependencies, Entrypoints, Assets, Trust Levels, Data Flows), analysis, and remediation.
Most of the threat modeling methods answer these four questions (OWASP, 2020, ref.8 ):
What are we developing?
First of all, the scope of the threat model should be determined. To be able to do that there should be a good understanding of the system or application that is built. It can be done by creating some architecture diagrams, data flow diagrams, and consulting with people that have expertise in the field.
What can go wrong?
In order to answer this question, research is performed to find the main threats of the application. There are many methodologies like STRIDE, P.A.S.T.A., Trike, VAST, etc. that can help in a structured way to identify potential threats.
What are we going to do about that?
The answer to this question is the remediations that we are planning to do to defend against the threats.
Did we do a good enough job?
In this phase, we evaluate our work by checking the quality, feasibility, etc
Addressing threats
There are four ways of addressing threats: mitigation, elimination, transfer and acceptance.
The mitigation means that we make things harder to take advantage of the threat, for example, by creating password policies that will make the password brute-forcing a lot harder.
Threat elimination usually means the elimination of the feature.
Threat transfer means that we are transferring the risks and responsibilities to somebody else, for example, using authentication from social media instead of building our own.
Accepting the risks is the last approach to addressing threats. Usually, if the company is using third-party libraries, like pandas or software like SAP, they accept the risks because of the budget and time constraints. They assume that third-party dependencies are secure and their vendors already did the threat modeling for them.
The picture below represents the circle of risk or it can also be called the circle of threats. This is the process of how threats are identified and mitigated. It is done continuously in a loop.
A threat is materialized by an attack that exploits a vulnerability. A vulnerability exposes the system and the business to risks. Risks are mitigated by countermeasures that protect the assets. Assets are compromised by threats.
Threat modeling should be done with the development team by creating workshops. During the workshops, you are brainstorming with the team about potential threats of the system by looking at the architecture, data flow, or process diagrams. Threat modeling should be done every time a new feature is developed if the company is doing DevSecOps.
