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 economic activity to bake security into the SDLC early on in the process. Additionally, many design decisions are made at the pre-seed stage. Since these decisions can be difficult to change in later stages, it's important that they are considered 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 to visualize any risks in your prospective design, which will allow for brainstorming of possible mitigations before you’re actually required to implement them.

How to Create a Threat Model

There are three 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 based application (SPA)
• A set of external APIs that are called mainly from the SPA
• Application server that performs all the data processing
• A database server which 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 a lot of assets that attackers are after such as financial, healthcare, or any other PII.
2. Your source code. Source code is not only intellectual property but also it can contain keys, secrets and other credentials to back end systems.
3. Your servers. Application servers are a very good way to gain access to any of the 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 looking whether there is a realistic threat to these assets. Most often, development teams focus on the house front door (the obvious threat) and ignore the house backdoor (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 through 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 to it, an attacker can dump all the data.

Again, at this point you are just enumerating all potential attack surfaces without any regards to whether it is realistic or not.

3. Determine potential attacks

At this step, you can begin to enumerate all the possible attacks (or bad things) that could happen against the assets through the attack surface which were both identified in the previous step.

Let’s enumerate some attacks here. For example:

1. Attackers can try to get access to your users via a cross-site scripting attack.
2. Attackers can try to access the data through unauthorized through the API layer
3. An authenticated user can try to steal the data through a 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 use an open port on the server and escalate their privilege to admin.
6. An attacker can use database administration page to take over the database

4. Determine your mitigation controls 

Now, the next step is to identify mitigations for each of the attack scenarios. Some are going to be easier than others. In this step, sometimes you will have multiple controls. So for example, to mitigate SQL injection attacks, you can use an ORM (assuming you are in a place to change your technology stack) or you can use a prepared statement. In this case, try to choose controls that can tackle multiple attacks at the same time. Also, try to choose controls that are more automatic and do not suffer the human-error effect. So an ORM would automatically mitigate SQL injections and does not allow for a human-error as much as forcing prepared statements, where it 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 in the SDLC before writing the first line of code. The process described above is a very simplified process to illustrate the concept. There are some industry approved methodologies such as DREAD, STRIDE, PASTA, VAST, Trike, OCTAVE, and NIST if you wish to go deeper into the topic.

[convertful id="175854"]