Template: Web Application Threat Model

 

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.

Threat Modeling Web Applications

J.D. Meier, Alex Mackman, Blaine Wastell

Microsoft Corporation

May 2005

See the "patterns & practices Security Guidance for Applications Index" for links to additional security resources.

Home Page for Threat Modeling Web Applications

Summary: This provides a template that shows you the type of data to gather as part of the threat modeling activity, together with relevant exit criteria for each step in the activity. The threat model can be used as input for deriving security test plans or test cases.

Contents

How to Use the Template
Application Name and Description
Owners, Authors, and Stakeholders
Revision History
1. Security Objectives
2. Application Overview
3. Application Decomposition
4. Threats
5. Vulnerabilities

How to Use the Template

Use this template to capture output from the threat modeling activity described in the document, "How To: Create a Threat Model for a Web Application at Design Time." The template contains instruction text, examples, and checkpoint criteria for each step in the activity.

You should review and update the output document (the threat model) generated from this template at regular intervals throughout the application life cycle. As your application design develops, you should be able to progressively add more detail to the output document.

Application Name and Description

<<Insert application name and brief description>>

Owners, Authors, and Stakeholders

Owners	Authors	Stakeholders

Revision History

Name	Change	Date

1. Security Objectives

List the goals and constraints that affect the confidentiality, integrity, and availability of your data and application.

<<Insert security objective 1>>

<<Insert security objective 2>>

<<Insert security objective 3>>

Examples

The following are examples of typical security objectives:

• Prevent an attacker from obtaining sensitive customer data, including their passwords and profile information.
• Meet predefined service level agreements for application availability.
• Protect the company's online business credibility.

Checkpoint

Before you finish this step, you should be able to answer the following questions:

• Do you know the key security criteria influencing your application's design?
• Have you identified what you do not want to happen from a security perspective? For example, you do not want an attacker to steal a user's password.
• Have the assets that you have identified helped you prioritize and focus your efforts?

2. Application Overview

Identify your Web application's end-to-end process flow and what your application does.

<<Insert brief application description>>

End-to-End Deployment Scenario

Describe your application's end-to-end deployment scenario. Explain the following:

• Deployment topology
• Presentation, business, and data access logic layers
• Key components and services within each logical layer

Include any relevant figures or diagrams.

<<Insert description of end-to-end deployment scenario>>

Checkpoint

Before you finish this step, you should be able to answer the following questions:

• Can you identify the application's physical deployment topology, logical layers, key components, and services?
• Is it clear which servers, components, and services communicate with each other and how they do it?
• Can you identify any external systems your application depends on?

Roles

Identify who can do what within your application.

<<Insert role 1>>

<<Insert role 2>>

<<Insert role 3>>

Examples

The following are example roles:

• Users can read data and update their own data.
• Managers can update their staff data.

Checkpoint

Before you finish this step, you should be able to answer the following questions:

• Is it clear who the different groups of people are who access your application?
• Do you know the higher privileged groups of users and what they can do?
• Do you know who is not allowed to do what?

Key Scenarios

Identify the key features of your application and usage scenarios.

<<Insert key scenario 1>>

<<Insert key scenario 2>>

<<Insert key scenario 3>>

Examples

The following are examples of key scenarios:

• User creates new account.
• User logs on.
• User searches product catalog.

Checkpoint

Before you finish this step, you should be able to answer the following questions:

• Is it clear what the key features of the application are?
• Do you know the important scenarios and use cases?

Technologies

List relevant technologies and key features of the specific technologies that you use.

<<Insert operating system details>>

<<Insert Web server software>>

<<Insert database server software>>

<<Insert technologies used in presentation, business, and data access layers>>

<<Insert development languages>>

Application Security Mechanisms

Identify any key points that you know about how the following security mechanisms:

• Input and data validation
• Authentication
• Authorization
• Configuration management
• Sensitive data
• Session management
• Cryptography
• Parameter manipulation
• Exception management
• Auditing and logging

<<Insert security mechanism 1>>

<<Insert security mechanism 2>>

<<Insert security mechanism 3>>

Examples

The following are examples of application security mechanisms:

• Application performs custom authentication for access to a database.
• Application uses roles to authorize access to business logic.
• Administrator must physically log on to the server to perform administration tasks. No remote administration access is permitted.

Checkpoint

Before you finish this step, you should be able to answer the following questions:

• Can you identify the application's physical deployment topology, logical layers, and key components and services?
• Is it clear which servers, components, and services communicate with each other and how they do it?
• Do you know which external systems your application depends on?
• Do you know the relevant technologies that will be used?
• Do you know the important scenarios and use cases?
• Have you identified your application's key security features?

3. Application Decomposition

In this step, you analyze your application to identify trust boundaries, entry points, exit points, and data flows.

Trust Boundaries

Identify your application's trust boundaries. A trust boundary is a location where the level of trust changes. Identify the systems, subsystems, and identities that your application trusts.

<<Insert trust boundary 1>>

<<Insert trust boundary 2>>

<<Insert trust boundary 3>>

Examples

The following are examples of typical trust boundaries:

• The perimeter firewall.
• The database server trusts calls from the Web application's identity.
• The data access components trust the business components to pass fully validated data.

Data Flows

For your main data flows, identify where the data comes from, where it goes, and who can input data. Also identify what good data consists of: its length, range, format, and type. Highlight the key authorization mechanisms used during the data flow. If you have UML sequence diagrams or data flow diagrams, use them.

<<Insert data flow 1>>

<<Insert data flow 2>>

<<Insert data flow 3>>

Example

The following is an example of a data flow description:

• An anonymous user submits a search string. The search string is accepted by the home page and is validated by a regular expression. The search string must be less than 50 characters in length and may include any combination of letters or numbers. The search string is passed to the data access component. The data access component calls a stored procedure, passing the search string as a single parameter.

Checkpoint

Before you finish this step, you should be able to answer the following questions:

• Did you prioritize data that crosses trust boundaries?
• Do you know where sensitive data items originate?
• Do you know what good data is (length, range, format, and type)?
• Do you know the authorization mechanisms along the way?
• Did you trace the data from entry to exit?

Entry Points

List the entry points into your application where users and external applications supply data and call functionality. Also identify internal entry points used for cross component communication.

<<Insert entry point 1>>

<<Insert entry point 2>>

<<Insert entry point 3>>

Examples

The following are examples of entry point descriptions:

• Logon page. Accessible to all Internet users. Validated by using client-side and server-side validation controls, together with common validation library.
• Amend customer details page. Accessible to authenticated users only. Validated by using client-side and server-side validation controls, together with common validation library. The page is used to update customer details.
• GetCustomerDetails stored procedure. Can be called by the application's trusted service account only. Data validation is performed by upstream caller (trusted Web application business logic). The procedure invokes code that retrieves customer details.

Checkpoint

Before you finish this step, you should be able to answer the following question:

• Can you list your entry points, particularly those at the trust boundaries?

Exit Points

Identify the points in your application where data is sent to the client. Prioritize the exit points where you write data from client input or from untrusted sources such as shared databases.

<<Insert exit point 1>>

<<Insert exit point 2>>

<<Insert exit point 3>>

Checkpoint

Before you finish this step, you should be able to answer the following question:

• Do you know where your application writes data using untrusted input?

4. Threats

List the threats and attacks that could affect your application. Threats are the potential bad things that might happen.

<<Insert threat 1>>

<<Insert threat 2>>

<<Insert threat 3>>

Examples

The following are examples of threats:

• Attacker obtains a user's name and password by monitoring the network between Web browser and Web server.
• Attacker submits malformed input as part of a database query.
• Attacker(s) create a denial-of-service situation, making the application unavailable. As a result, application availability-related security objectives are not met.

Checkpoint

Before you finish this step, you should be able to answer the following questions:

• Have you considered common or well known threats?
• Have you explored threats that could affect your scenarios beyond those that are commonly known?
• Where possible, are the potential targets of such threats identified in your descriptions?
• Have you considered non-malicious threats that compromise confidentiality, integrity, and availability, such as a valid user inadvertently accessing restricted data?
• Have you considered threats that could affect your security objectives?

5. Vulnerabilities

Identify weaknesses in your application design to help shape security decisions and dictate the scope of testing.

<<Insert vulnerability 1>>

<<Insert vulnerability 2>>

<<Insert vulnerability 3>>

Examples

The following are examples of vulnerabilities:

• Over-privileged Web process account can result in increased damage potential if the Web process is compromised.
• Unrestricted Web process account in the database can result in increased damage potential in the event of a SQL injection attack.
• Clear text credentials are passed between the Web server and database server.

Checkpoint

Before you finish this step, you should be able to answer the following questions:

• Have you considered the common vulnerabilities?
• Have you considered vulnerabilities at each application layer?

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