You may have heard of threat modeling as a structured activity for identifying and managing threats. Threat modeling can be applied to a wide range of things, including software, applications, systems, networks, IoTs and business processes.

Threat modeling’s motto should be, “The earlier the better, but not too late and never ignore.” Without threat modeling, your security is a gamble—and in today’s business environment, you are sure to lose.

When you design an application, you will face several security issues during different phases of the software development life cycle (SDLC), and so having threat modeling in the development life cycle from the beginning can help to safeguard that applications are being developed, with security built in.

Simply put, threat modeling is a procedure to identify threats and vulnerabilities in the earliest stage of the development life cycle to identify gaps and mitigate risk, which guarantees that a secure application is being built, saving both revenue and time.

Threat modeling is a procedure for optimizing application security by identifying objectives and vulnerabilities, and then defining countermeasures to prevent, or mitigate the effects of, threats to the system. In this context, a threat is a potential or actual adverse event that may be malicious (such as a denial-of-service attack) or incidental (such as the failure of a storage device), and that can compromise the assets of an enterprise.

The key to threat modeling is to determine where the most effort should be applied to keep a system secure. This is a variable that changes as new factors develop and become known, applications are added, removed, or upgraded, and user requirements evolve. Threat modeling is an iterative process that consists of defining enterprise assets, identifying what each application does with respect to these assets, creating a security profile for each application, identifying potential threats, prioritizing potential threats, and documenting adverse events and the actions taken in each case.

Why Threat Modeling?

It is better to find security flaws when there is time to fix them.

It can save time, revenue and the reputation of your company.

To build a secure application.

To bridge the gap between developers and security.

It provides a document of all the identified threats and rated threats.

It offers knowledge and awareness of the latest risks and vulnerabilities.

How To Do Threat Modelling

Many people think only security engineers can do threat modelling. That’s not true. Anyone, from developer to software project manager, can threat-model. In fact, it is recommended that they should all know a little bit of threat modelling as part of their work.

Let’s look at the elements of threat modelling:

Assets: What valuable data and equipment should be secured?

Threats: What the attacker can do to the system?

Vulnerabilities: What are the flaws in the system that can allow an attacker to realize a threat?

Steps to Threat Modeling

Step 1: Identify the assets (database server, file servers, data lake stores, Active Directory, REST calls, configuration screens, Azure portal, authenticated and anonymous web user, Azure AAD client apps, database users, DB administrators)

Step 2: Outline details of architecture on which the valuable asset is being processed. It may include the software framework, version and other architectural details (ASP.net web application connection to cloud data stores and third-party services using JWT tokens).

Step 3: Break down the application regarding its process, including all the sub-processes that are running the application. Create a data flow diagram (DFD).

Step 4: List and identify threats in a descriptive way to review to process further.

Step 5: Classify the threats with parallel instances so that threats can be identified in the application in a structured and repeatable manner.

Step 6: Rate the severity of the threat.

A very popular threat modeling tool is the so-called STRIDE, which model that is described below.

STRIDE - Uses application-centric approach

Spoofing
Most security systems rely on the identification and authentication of users. Spoofing attacks consist of using another user’s credentials without their knowledge. Typical spoofing threats target weak authentication mechanisms, for instance those using simple passwords, like a simple 4 digits number, or those using personal information that can be easily found, like date or place of birth.

Tampering
Only authorised users should be able to modify a system or the data it uses. If an attacker is able to tamper with it, it can have some consequences on the usage of the system itself, for instance if the attacker can add or remove some functional elements, or on the purpose of the system, for instance if important data is destroyed or modified.

Repudiation
Attackers often want to hide their malicious activity, to avoid being detected and blocked. They might therefore try to repudiate actions they have performed, for instance by erasing them from the logs, or by spoofing the credentials of another user.

Information disclosure
Many systems contain confidential information, and attackers often aim at getting hold of it. There are numerous examples of data breaches in the recent years. Information can also be leaked or disclosed if exceptions are not handled properly. Attackers always try to force an error and they analyse error messages very carefully.

Denial of service
A system is usually deployed for a particular purpose, whether it is a banking application or an integrated media management on a car. In some cases, attackers will have some interest in preventing regular users from accessing the system, for instance as a way to blackmail and extort money from the owner of the system (e.g., with ransomware).

Escalation of privilege
Once a user is identified on a system, they usually have some sort of privileges, i.e., they are authorised to perform some actions, but not necessarily all of them. An attacker might therefore try to acquire additional privileges, for instance by spoofing a user with higher privileges, or by tampering the system to change their own privileges.

The out come of a STRIDE activity should be table in which each asset’s risk and the severity of the risk are listed. The colour coding of the X’s could represent severity. You can actually collect data and quantify the risk associated with each asset with regards to the threats that it faces.

	S	T	R	I	D	E
Data Store		X		X
Process	X	X	X	X	X	X
File Store			X	X	X

When to use Threat Modelling

In simple words, at the early stages of the SDLC, perform threat modeling:

Every time there is a change in the system’s architecture.

After a security incident has occurred or new vulnerabilities are introduced.

As soon as the architecture is ready.

It is not a must to perform threat modelling at the early stages of the SDLC; you can still pick up threat modelling at any stages even if it is close to deployment.

Threat models are continuously changing, and the models you prepared today may not be sufficient or efficient tomorrow. And it is difficult to say that you are covered from all the threats. But if you have performed threat modelling and done whatever it takes to minimize your exposure to security risks, at least the impact of something very bad happening will be manageable (again, hopefully, but not a guarantee).