Feb 17, 21 2:23 pm

Was this post helpful?

What Is Threat Modeling & Why Is It Underestimated

Feb 17, 2021
| by:
Sherif Koussa

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

java script icon, api icon, application server icon, database server icon

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.

previous icons with possible OWASP risks below each

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.

mitigation controls listed for each java, api, application server, and database server icon

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"]

Was this post helpful?

About the Author

Sherif Koussa
Sherif Koussa is OWASP Ottawa Chapter Co-Leader, Software Developer, Hacker, and founder and CEO of Software Secured and Reshift. In addition to contributing to OWASP Ottawa for over 14 years, Sherif contributed to WebGoat, and OWASP Cheat Sheets. Sherif also helped the SANS and GIAC organizations launch their GSSP-Java and GSSP-NET exams and contributed to a few of their courses. After switching from the software development field to the security field, Sherif took on the mission of supporting developers shifting security left, and ship more secure code organically.
Share This Post

Leave a Reply

Your email address will not be published.

Related Post

May 24, 2023 by Sherif Koussa

SOC 2® Reports and Penetration Tests

Read more

Was this post helpful?

May 11, 2023 by Cate Callegari

How to Overcome the Biggest Barriers to Selling Security Internally

Read more

Was this post helpful?

May 5, 2023 by Sherif Koussa

4 Ways Security Leaders Uses Penetration Testing to Elevate Their Security Programs

Read more

Was this post helpful?


301 Moodie Dr. Unit 108
Ottawa ON K2H 9C4

Designed by WP Expert
© 2023
Software Secured