Threat Modeling Web Applications

07/14/2010

10 minutes to read

In this article

Retired Content

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

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.

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 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.

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

Concept

Description

Modeling to reduce risk

Threat modeling is performed to identify when and where more effort should be applied. There are many possible vulnerabilities, threats, and exploits; it is unlikely that your application will encounter all of them. It is also unlikely that your company would need to address all of them. Threat modeling helps you identify where your organization needs to apply effort.

Incremental rendering

Threat modeling is iterative. You should not be too concerned about missing details in any single iteration—just make each iteration productive. You iterate:

By increasing the detail of your model whenever new environmental facts become known.

While you develop, as design and implementation decisions reveal new facts.

Through the application lifetime (including after it is in production and being maintained by the operations team), as uses and configurations of the application appear.

Incrementally render the information as it becomes available to you and keep identifying what you now know and what you need to know next.

Context-precision

Context-precision provides relevancy. Context precision means being specific about the context, application type, and application scenario to increase information relevancy. Because different application types, application usage, and roles can yield different threats and vulnerabilities, you need to look at application use cases and roles to truly identify threats and actual vulnerabilities.

Boundaries

Establishing boundaries helps you to define constraints and goals. Boundaries help you Identify what must not be allowed to happen, what needs to happen, and what is nice to happen.

Entry and exit criteria

By defining entry and exit criteria, you establish tests for success so you know when your threat model is complete (good enough) and to ensure you spend the right amount of time on the activity.

Communication and collaboration tool

Your threat model is a communication and collaboration tool and should be used to improve shared knowledge and understanding. Threat modeling is used to focus efforts and decisions in design, development, test, operations, and the business. By documenting threats and vulnerabilities (even if they are already addressed), you help everyone understand them and avoid accidentally undoing something.

Pattern-based information model

By using a pattern-based information model, you can identify the patterns of repeatable problems and solutions and organize them into categories. Then you can use these categories to break down your application for further analysis and identify vulnerabilities for your application associated with each category. Organizing vulnerabilities in this manner allows you to identify and act on vulnerabilities in a more systematic manner and helps you leverage community knowledge. In short, you will not have to start from scratch or be a subject matter expert. Using categories also helps promote information reuse and effective communication. You can use these pattern-based categories to organize and share principles and practices.

Key engineering decisions

A good model exposes your high risk engineering decisions and design choices. These high risk choices are good candidates for focusing prototyping efforts.

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.

How do you know that the input that your application receives is valid and safe? Input validation refers to how your application filters, scrubs, or rejects input before additional processing.

Authentication

Who are you? Authentication is the process where an entity proves the identity of another entity, typically through credentials, such as a user name and password.

Authorization

What can you do? Authorization is how your application provides access controls for resources and operations.

Configuration Management

Who does your application run as? Which databases does it connect to? How is your application administered? How are these settings secured? Configuration management refers to how your application handles these operational issues.

Sensitive Data

How does your application handle sensitive data? Sensitive data refers to how your application handles any data that must be protected either in memory, over the network, or in persistent stores.

Session Management

How does your application handle and protect user sessions? A session refers to a series of related interactions between a user and your Web application.

Cryptography

How are you keeping secrets (confidentiality)? How are you tamper-proofing your data or libraries (integrity)? How are you providing seeds for random values that must be cryptographically strong? Cryptography refers to how your application enforces confidentiality and integrity.

Parameter Manipulation

How does your application manipulate parameter values? Form fields, query string arguments, and cookie values are frequently used as parameters for an application. Parameter manipulation refers to both how your application safeguards tampering of these values and how your application processes input parameters.

Exception Management

When a method call in your application fails, what does your application do? How much do you reveal? Do you return friendly error information to end users? Do you pass valuable exception information back to the caller? Does your application fail gracefully?

Auditing and Logging

Who did what and when? Auditing and logging refer to how your application records security-related events.

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:

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.