Threat modeling is an activity that helps you identify and mitigate threats. It’s very important because it makes you look at security risks top-down, focus on decision-making and prioritize security decisions, and consider how you can use your resources in the best possible way. There are many approaches to threat modeling but all of them have the same goal. They are tools to help you figure out what can potentially harm your security and what can you do about it.

Threat modeling is a form of risk assessment that models aspects of the attack and defense sides of a particular logical entity, such as a piece of data, an application, a host, a system, or an environment. The fundamental principle underlying threat modeling is that there are always limited resources for security and it is necessary to determine how to use those limited resources effectively.
(NIST SP 800-154 publication)

How Is Threat Modeling Performed?

In general, threat modeling helps you think as an attacker would. It makes you ask yourself questions such as What do you have that is worth attacking? How can it be attacked? What would the attacker start from? It also uses visual aids that let you see threats more clearly and figure out attack vectors easily.

If you were to use threat modeling to protect your real estate, you would start by creating drawings of each floor of your house, then draw where the windows and doors are. Then you would try to figure out what would the burglar want to steal, how would they try to enter your house to steal it, and what could you install to avoid this (locks, alarm systems, safes, etc.). This is very similar to how you perform threat modeling for software development, including web applications.

Web application security threat modeling is just a part of threat modeling as a whole and it should not be considered a separate exercise. Web applications are always interconnected with other system elements: web servers, application servers, data stores, operating systems, and these in turn with other assets. Therefore, if you focus on modeling just for the web, you will miss out on a lot of threats and threat modeling will be useless.

Who Should Perform Threat Modeling?

Threat modeling is most effective if it involves as many people as possible, not just the security experts. People in different positions within the business bring a unique perspective and may help you notice details that you would otherwise miss. In some cases, threat modeling even enlists the help of subcontractors, business partners, or customers.

Ask your colleagues to pretend that they want to attack the business. What do they think is worth stealing or compromising? How would they go about it? A developer could remind you that your application source code is valuable because it contains unique algorithms. A marketing manager could remind you that if someone defaces your webpage it may lower your brand value. An office administrator may help you realize that it’s very easy for a stranger to enter your offices and the server room key is easy to steal.

When and Where to Perform Threat Modeling?

Threat modeling processes should begin when you start designing the application and they should never end. You should think of and model potential threats as soon as you start thinking about your application. The earlier you catch potential threats, the easier you can figure out how to protect yourself, for example, by redesigning parts of the system. Therefore, you must include threat modeling in your software development lifecycle (SDLC) from the earliest stages of the drawing board.

Your systems are constantly evolving and so threat modeling can never stop. Every change to your environment should be associated with reevaluating potential threats. Even a very small modification may introduce a very serious new threat that you have to mitigate. At the same time, threat modeling should not only be limited to your own assets. For example, you might need to include your users, your business partners, and more. If your systems are part of a bigger whole, threats to your systems may be indirect.

What Are the Stages of Threat Modeling?

According to threat modeling theory, it is usually based on four key stages:

  • What are we working on? (Diagramming)
  • What can go wrong? (Threat enumeration)
  • What are we going to do about it? (Mitigation)
  • Did we do a good job? (Verification)

Threat modeling begins with diagraming because it is the easiest way to communicate with others about how your system is built. Diagrams are also easy to understand by most people. The most popular diagrams used for threat modeling are data flow diagrams (DFD). They focus on data which is one of the key elements of threat modeling and they let you easily figure out trust boundaries.

Once the diagrams are ready, all the parties involved may look at them from an attacker’s point of view and try to find the security issues. Detailed threat enumeration/mitigation involves multiple tools and techniques that help you cover all threat categories and meet your software security requirements. Verification lets you make sure that mitigation is effective.

For example, when threat modeling for web applications, one of the key threat types that must always be identified and mitigated are potential web application vulnerabilities. During threat enumeration, you note that any web application is potentially open to SQL Injection attacks, Cross-site Scripting, and more, but also that users may use weak passwords, exposing the system to attack.

You may then use a web application vulnerability scanner to think like an attacker and attempt to find vulnerabilities. In the mitigation and verification stages, a complete web security solution such as Acunetix may additionally help you by managing issues to check whether they were resolved. While such a tool will not cover all threats, it is one of the essential elements of threat enumeration and mitigation for web applications.

What Methodologies to Use for Threat Modeling?

There are several methodologies that you can use for threat modeling. The most popular one is STRIDE created by Microsoft in 1999. The name stands for six key aspects that you should consider when threat modeling: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privileges. Additionally, there are methodologies such as PASTA (Process for Attack Simulation and Threat Analysis), Trike, VAST (Visual, Agile, and Simple Threat modeling), and many more.

You must select the methodology depending on many factors. For example, on the software development processes and methodologies that you use in your company (Scrum, Kanban, Waterfall, etc.), on the size of your organization, on business processes, on the scope of your environment. Therefore, to select the right methodology you must do detailed research that goes way beyond the scope of this article. You may start for example from a very useful article by the Carnegie Mellon University Software Engineering Institute, which introduces you to 12 methodologies.

What Tools to Use for Threat Modeling?

Just like threat modeling methodologies depend on your system’s architecture, business approach, requirements, and more, threat modelers depend on the selected methodology. However, among the plethora of threat modelers available on the market, one tool is often mentioned because it is very easy to use and free of charge: the Microsoft Threat Modeling Tool. The advantage of using it is the number of training resources available online.

Tomasz Andrzej Nidecki
Sr. Technical Content Writer
Tomasz Andrzej Nidecki (also known as tonid) is a Senior Technical Content Writer working for Acunetix. A journalist, translator, and technical writer with 25 years of IT experience, Tomasz has been the Managing Editor of the hakin9 IT Security magazine in its early years and used to run a major technical blog dedicated to email security.