Threat Modeling Web Applications

patterns & practices Library

J.D. Meier, Alex Mackman, Blaine Wastell

Microsoft Corporation

May 2005

Summary

This guidance presents the patterns &practices approach to creating threat models for Web applications. Threat modeling is an engineering technique you can use to help you identify threats, attacks, vulnerabilities, and countermeasures that could affect your application. You can use threat modeling to shape your application's design, meet your company's security objectives, and reduce risk.

Contents

Modules
Approach
Getting Started
What Is Threat Modeling?
Why Use Threat Modeling?
Terminology
Key Concepts
Web Application Security Frame
Tools Integration
Feedback
Contributors and Reviewers

Modules

This guidance includes the following modules:

• At a Glance: Web Application Threat Model
• How To: Create a Threat Model for a Web Application at Design Time
• Cheat Sheet: Web Application Security Frame
• Walkthrough: Creating a Threat Model for a Web Application
• Template: Web Application Threat Model
• Template Sample: Web Application Threat Model

Approach

The five major threat modeling steps are shown in Figure 1. You should progressively refine your threat model by repeatedly performing steps 2 through 5. You will be able to add more detail as you move through your application development life cycle and discover more about your application design.

Figure 1. The iterative threat modeling process

The five threat modeling steps are:

• Step 1: Identify security objectives. Clear objectives help you to focus the threat modeling activity and determine how much effort to spend on subsequent steps.
• Step 2: Create an applicationoverview. Itemizing your application's important characteristics and actors helps you to identify relevant threats during step 4.
• Step 3: Decompose your application. A detailed understanding of the mechanics of your application makes it easier for you to uncover more relevant and more detailed threats.
• Step 4: Identify threats. Use details from steps 2 and 3 to identify threats relevant to your application scenario and context.
• Step 5: Identify vulnerabilities. Review the layers of your application to identify weaknesses related to your threats. Use vulnerability categories to help you focus on those areas where mistakes are most often made.

Getting Started

Table 1 identifies a number of common usage scenarios and identifies the appropriate resources that you should use in each case.

Table 1: Scenarios and Associated Resources

What Is Threat Modeling?

Threat modeling is an engineering technique you can use to help you identify threats, attacks, vulnerabilities, and countermeasures in the context of your application scenario. The threat modeling activity helps you to:

• Identify your security objectives.
• Identify relevant threats.
• Identify relevant vulnerabilities and countermeasures.

Why Use Threat Modeling?

Use threat modeling to:

• Shape your application design to meet your security objectives.
• Help make trade-offs during key engineering decisions.
• Reduce risk of security issues arising during development and operations.

Terminology

Threat modeling uses the following terms:

• Asset. An asset is a resource of value. It varies by perspective. To your business, an asset might be the availability of information, or the information itself, such as customer data. It might be intangible, such as your company's reputation. To an attacker, an asset could be the ability to misuse your application for unauthorized access to data or privileged operations.
• Threat. A threat is an undesired event. A potential occurrence, often best described as an effect that might damage or compromise an asset or objective. It may or may not be malicious in nature.
• Vulnerability. A vulnerability is a weakness in some aspect or feature of a system that makes an exploit possible. Vulnerabilities can exist at the network, host, or application levels and include operational practices.
• Attack (or exploit). An attack is an action taken that utilizes one or more vulnerabilities to realize a threat. This could be someone following through on a threat or exploiting a vulnerability.
• Countermeasure. Countermeasures address vulnerabilities to reduce the probability of attacks or the impacts of threats. They do not directly address threats; instead, they address the factors that define the threats. Countermeasures range from improving application design, or improving your code, to improving an operational practice.

Key Concepts

The patterns & practices threat modeling approach is optimized to help you identify vulnerabilities in the context of your application scenario. With this approach, you incrementally identify what you know, what you do not know, and what you need to know next. Your security objectives help define success and scope your efforts.

Using a pattern-based approach lets you organize vulnerabilities in a more systematic and repeatable manner. It also helps you leverage community knowledge and avoid reinventing wheels.

The type of application you are building, along with its scenario and context, are important aspects for relevancy. For example, vulnerabilities for an Internet-facing Web application may not be the same as vulnerabilities for a reusable component in an intranet line of business application.

The key concepts associated with this threat modeling approach are summarized in Table 2.

Table 2: Key Concepts

Web Application Security Frame

The Web Application Security Frame defines a set of vulnerability categories for Web applications. These categories are areas where mistakes are most often made and they represent those areas where you should focus most attention.

The categories defined by the Web Application Security Frame have been derived by security experts who have examined and analyzed the top security issues across many Web applications. They have been refined with input from Microsoft consultants, product support engineers, customers, and Microsoft partners.

Table 3 summarizes the categories within the Web Application Security Frame.

Table 3: Web Application Security Frame

You use the frame to help identify threats and vulnerabilities. During threat identification, you use it to help identify common threats pertinent to your own application architecture. To help identify vulnerabilities, you proceed in a similar way by reviewing your application layer by layer, considering each of the vulnerability categories in each layer.

Tools Integration

Threat modeling and other security engineering activities can be supported by design and development tools. Tools support for the patterns & practices threat modeling activity is provided by:

• Visual Studio Team System Integration. The MSF Agile Software Development process integrates the patterns & practices threat modeling approach into Microsoft Visual Studio Team System. For more information, see the MSF process guidance or on the MSF Web site.

Feedback

If you have comments on this guide, send e-mail to secguide@microsoft.com. We are particularly interested in feedback regarding the following:

• Technical issues
• Usefulness and usability issues
• Writing and editing issues

Contributors and Reviewers

• External Contributors and Reviewers: Andy Eunson; Anil John, Johns Hopkins University - Applied Physics Laboratory; Brian Cowan; Brian Gran, Ascentium Corporation; Darren Simmonds, Ascentium Corporation; David Raphael, Foundstone Professional Services; Jan Drake, Ascentium Corporation; ; Keith Brown, Pluralsight LLC; Manoranjan M Paul; Mark Curphey, Foundstone Professional Services; Michael Panciroli, Ascentium Corporation; Mrinal Bhao, Infosys Technologies Ltd; Pete Coupland, VMC Consulting Corporation; Rudolph Araujo, Foundstone Professional Services;
• Microsoft Services and PSS Contributors and Reviewers: Kate Baroni; Maarten Van De Bospoort
• Microsoft IT Contributors and Reviewers: Shawn Veney
• Microsoft EEG Contributors and Reviewers: Corey Ladas
• Microsoft Product Group Contributors and Reviewers: Don Wilits; Randy Miller; Rico Mariani
• Microsoft patterns & practices Contributors and Reviewers: Edward Jezierski; Jason Hogg; Jonathan Wanagel; Larry Brader; Naveen Yajaman
• Test team: Sivanthapatham Shanmugasundaram (Infosys Technologies Ltd).
• Edit team: Sharon Smith (Linda Werner & Associates Inc), Tina Burden McGrayne (Linda Werner & Associates Inc).

Next