Threat Modeling for Web Applications

Threat modeling in cybersecurity is a way of identifying, listing, prioritizing, and mitigating potential threats in order to protect systems and data. There are many different threat modeling processes and the threats themselves can include anything from specific attack vectors and actors to weak or missing safeguards. This article shows how threat modeling works and how it applies to web application security.

What is Threat Modeling?

The idea of anticipating threats is as old as the world itself, but systematic threat modeling is a relatively new approach. In the realm of software security, threat models describe specific threats to systems and data, ranging from technology-specific threats such as web vulnerability exploits to broader risks such as unauthorized system access or insecure physical data storage. You can perform threat analysis and modeling at any level, from very narrow scenarios to a company-wide threat model that combines risks and remedies across the entire organization. Threat modeling can be considered the next practical step after a broader risk assessment. Once you’ve identified security risks that can affect your operations and business processes, security experts (in this case threat modelers) define specific threat models for each risk factor. A threat model is simply a set of parameters that define a threat, such as the underlying risk factor, identified threat actors, potential attack vectors, business impact, and remedies. For example, you might start with the risk of unauthorized information disclosure and create a threat model that defines the threat of a rogue employee obtaining and disclosing valuable intellectual property.

Formal and Informal Approaches to Threat Modeling

As with risk assessment, you can approach threat analysis and modeling in many ways, from informal brainstorming to rigorous formal frameworks. In the realm of IT security, one of the first modern threat modeling techniques was the use of threat trees – tree diagrams that show the different ways that an asset can be attacked. Data flow diagrams (DFDs) are also commonly used in threat analysis to illustrate trust boundaries between different systems and architectural components. In the late 1990s, Microsoft developed a more systematic method of anticipating and modeling threats, called the STRIDE threat model. Originally created for Windows development, STRIDE is a mnemonic to help developers and security analysts remember the key ways in which attackers can exploit a threat: Spoofing identity, Tampering with data, Repudiation, Information disclosure, Denial of service, and Elevation of privilege. In this approach, each threat violates one desirable property of the targeted system. There are at least a dozen other threat modeling methods to choose from, including such delightful acronyms as PASTA (Process for Attack Simulation and Threat Analysis), VAST (Visual, Agile, and Simple Threat modelling), and OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation). Your choice of methodology (if you choose to use one at all) depends on what you need to secure, why you are preparing a threat model, and how comprehensive you want the results to be. For example, Trike focuses on risk management based on identified requirements, while PASTA provides an attacker-centric view of the target application or system.

Defining Threat Models for Web Application Development

Web applications don’t exist in a vacuum but rely on and interact with many other systems, resources, and data stores. An effective web application threat model should take the big picture into account, because – as always in security – an attacker only needs one gap to get through. This is why you can’t build a threat model that only focuses only on one aspect, for example, web application vulnerabilities. A real-life attacker has the whole attack surface to play with: the web server, the network infrastructure, data storage, external cloud services, and much more. In fact, it doesn’t even have to be an external attacker – weak passwords and the actions of rogue admins can also pose critical threats, even if they have nothing to do with application development. This is why it’s important to involve a wide variety of stakeholders in the threat modeling process. Threat modeling can be done by anyone and at any stage of development. The method you use depends on your needs and capabilities, but here are 5 basic steps as an example:

1. Define security requirements so you know what to protect from threats and what these threats could target.
2. Map out the application structure to get an idea of all the data flows and actors involved. A data flow diagram is the usual way of doing this.
3. Identify threats and threat categories that could pose a risk to your application based on defined security criteria. This is the main threat identification and analysis step.
4. Mitigate threats to ensure that identified risks can’t translate into real-life attacks. After all, the purpose of the exercise is it improve security, not just paint a picture.
5. Check that threats have been mitigated to make doubly sure that everything specified in your threat model is now a purely theoretical risk.

To be effective, a threat model should be an integral part of the software design and development process. Ideally, the threat model for a web application should be defined and maintained from the very start of development, but it can also be added to an existing application. Just like test suites, the threat model should reside close to the code and be rigorously updated every time the security conditions change. For example, if an application switches from using a local database to cloud storage, this may introduce new threats and require changes to the threat model.

Threat Modeling Tools

The Microsoft threat modeling tool was the first widely available product for software threat modeling and still provides a good starting point (plus it’s free). Microsoft advocates using it as part of its Security Development Lifecycle approach to integrate security into the software development lifecycle (SDLC). One downside is that the tool is Windows-only and heavily focused on Microsoft systems and platforms, which limits its usefulness in many web deployments. The open-source OWASP Threat Dragon is another free threat modeling tool focused on development, featuring close integration with GitHub. Like the Microsoft tool, it provides a visual representation of threats, processes, data stores, actors, and other components, allowing you to create data flow diagrams for threat analysis. Threat models are saved as JSON files.

Why You Should Use Threat Modeling

When dealing with IT security, each specialist will tend to focus on their area of expertise, so for a web developer, security will mean web vulnerabilities, a network engineer will think mainly about network security, and for a workplace admin, security will be all about malware, phishing, and unauthorized private devices. The big advantage of threat modeling is that it provides a high-level view of potential security issues by focusing on threats, not weaknesses. For example, if your security requirement is to protect confidential data in company systems, your threat model will need to include everything that could lead to a compromise of this information. Making sense of security realities is always tricky, especially under time pressure, so having a solid threat model in place can be a great help for security decision-making. By looking at a valid and up-to-date model, you can get a good picture of the real threat environment and make your plans and decisions accordingly. This is especially important in DevOps and other agile development environments where you don’t have the time or resources for a full security review every time you plan a sprint or release. Simply put, threat modeling is a more formal way of thinking about what can go wrong in your systems and applications. By focusing on threats rather than weaknesses, you can zoom out of your technical niche and get a wider view of your web application security posture.