What Is Threat Modeling & Why Is It Underestimated

For pre-seed companies, threat modeling is the most underestimated and underutilized security technique. ​​With limited budgets at the pre-seed level, access to additional resources and commercial tools is likely unavailable. Threat modeling is the most cost-effective way to embed security into the SDLC early in the process. Additionally, many design decisions are made at the pre-seed stage. Since these decisions can be difficult to change later, it's important to consider them for security through threat modeling.​ Understanding what threat modeling is early on will help companies build a secure application from the ground up.

What is threat modeling?

Threat modeling is the ultimate shift left approach. It can be used to identify and eliminate potential vulnerabilities before a single line of code is ever written. Employing threat modeling methodologies should be your first step toward building networks, systems, and applications that will be secure by design.  

‍

“Threat modeling is a structured approach of identifying and prioritizing potential threats to a system, and determining the value that potential mitigations would have in reducing or neutralizing those threats.”  - OWASP Cheat Sheets.

‍

Threat modeling helps you visualize risks in your prospective design, allowing you to brainstorm possible mitigations before you’re actually required to implement them.

How to Create a Threat Model

There are four steps of an effective Threat Modeling exercise:

1. Define assets

An asset is anything of value that an attacker would be interested in, including sensitive data, servers, files, users, etc. For example, simple modern architecture would include:

• A JavaScript single-page application (SPA)
• A set of external APIs that are called mainly from the SPA
• An application server that performs all the data processing
• A database server that contains all the data

Enumerating Assets

Enumerating your assets is part of defining them. To do so, you need to consider at least these four areas:

1. Data in the database. More often than not, the database contains many assets that attackers are after, such as financial, healthcare, or other PII.
2. Your source code. Source code is not only intellectual property; it can also contain keys, secrets, and other credentials for back-end systems.
3. Your servers. Application servers are a very good way to access other assets, such as the database or your source code. Since most applications run in an admin/root context, this makes it more attractive to hackers. 
4. Access to your users. Their identities, information, or even their browsers are all attractive assets to an attacker.

While there are many other areas to cover, these four areas are a good starting point. At this stage, you are just enumerating all possible assets without checking whether there is a realistic threat to them. Most often, development teams focus on the front door (the obvious threat) and ignore the back door (the easier threat).

2. Determine the attack surface

Your attack surface is any input point in the application that can lead an attacker to your assets. For example, APIs that retrieve users' data.

Let’s take a stab at enumerating your attack surface, which may include:

1. The APIs. This is probably your biggest attack surface since they are meant to be public and accessible.
2. The server. The first thing here is that the server shouldn’t be accessible to anybody, but that’s exactly the point behind this exercise.
3. The database. Again, similar to the server. With direct access, an attacker can dump all the data.

Again, at this point, you are just enumerating all potential attack surfaces without regard to whether they are realistic.

3. Determine potential attacks

At this step, you can begin enumerating all possible attacks (or bad things) that could occur against the assets through the attack surface identified in the previous step.

‍

Let’s enumerate some attacks here. For example:

1. Attackers can try to gain access to your users' accounts via cross-site scripting.
2. Attackers can try to access the data through unauthorized means through the API layer.
3. An authenticated user can try to steal the data through an SQL injection attack.
4. A low-privileged user can escalate their privilege to an admin user who has access to all data.
5. An attacker can exploit an open port on the server to escalate their privileges to admin.
6. An attacker can use the database administration page to take over the database.

‍

4. Determine your mitigation controls 

The next step is to identify mitigations for each attack scenario. Some will be easier than others. In this step, sometimes you will have multiple controls. For example, to mitigate SQL injection attacks, you can use an ORM (if you can change your technology stack) or prepared statements. Try to choose controls that can handle multiple attacks simultaneously. Also, try to choose controls that are more automated and do not suffer from human error. So an ORM would automatically mitigate SQL injection and reduce human error as much as forcing prepared statements, which is easier to forget.

Summary on What Threat Modeling Is

Threat modeling is one of the most underappreciated techniques in your security toolbox. Additionally, it is the ultimate shift-left approach, as you can integrate it into the SDLC before writing the first line of code. The process described above is a simplified illustration of the concept. There are industry-approved methodologies such as DREAD, STRIDE, PASTA, VAST, Trike, OCTAVE, and NIST if you wish to go deeper into the topic.