Threat modeling for web application security

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 cybersecurity 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 posture and what you can 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 potential attackers would. It makes you ask yourself questions such as What do you have that is worth attacking? How can it be attacked? Where 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 the burglar would want to steal, how they would try to enter your house to steal it, and what you could 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 many threats, and threat modeling will be useless.

Sponsorships Available

Sponsorships Available

Sponsorships Available

Who should perform threat modeling?

Threat modeling is most effective if it involves as many stakeholders as possible, not just the security experts. People in different positions within the business bring a unique perspective and may help you notice details 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? Development teams could remind you that your application source code is valuable because it contains not just open source but also proprietary 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. The IT system administrators may remind you to cover not just the desktops and servers but also IoT devices.

When and where to perform threat modeling?

Threat modeling processes should begin when you start designing the application, and they should never end, becoming an integral part of information security risk management. Security teams should think of exploitability 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 using various countermeasures, 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 throughout all of DevOps.

Your systems are constantly evolving, 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 consider auditing your users, 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 initial diagrams are ready, all the parties involved may look at them from an attacker’s point of view and begin brainstorming 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, for example, building attack trees and designing security controls. Verification lets you make sure that mitigation is effective.

For example, when gathering threat intelligence for web applications, one of the key threat types that must always be identified and mitigated is potential web application vulnerabilities. During threat enumeration, you note that any web application is potentially open to OWASP Top 10 attacks such as SQL injection, 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 automatically prioritizing and managing issues to check whether they were resolved. While such an automation-focused tool will not cover all threats and it is recommended to follow up with penetration testing, it is one of the essential elements of cyber threat enumeration and mitigation for web applications.

What threat modeling approaches to use?

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.), the size of your organization, business processes, and 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 with 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 objectives, requirements, and more, automated 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.

THE AUTHOR

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.