Template:Web Application Threat Model
- J.D. Meier, Alex Mackman, Blaine Wastell
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.
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
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
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
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
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
- 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
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
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
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
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
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
You should be able to answer the following questions:
- Have you considered the common vulnerabilities?
- Have you considered vulnerabilities at each application layer?
