Threat Modeling Web Applications

 

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.

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

Scenario	Resource
You are new to threat modeling.	"At a Glance: Web Application Threat Model" "How To: Create a Threat Model for a Web Application at Design Time"
You want to start quickly.	"How To: Create a Threat Model for a Web Application at Design Time"
You want to prepare for a threat modeling meeting.	"Walkthrough: Creating a Threat Model for a Web Application"
You need a template or example.	"Template: Web Application Threat Model" "Template Sample: Web Application Threat Model"
You need reference material to help identify threats and vulnerabilities.	"Cheat Sheet: Web Application Security Frame"

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.

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

Table 3: Web Application Security Frame

Category	Description
Input and Data Validation	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:

• 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

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.