This How To describes an approach for creating a threat model for a Web application. The threat modeling activity helps you to model your security design so that you can expose potential security design flaws and vulnerabilities before you invest significant time or resources in a flawed design and/or problems become difficult to reverse. This How To provides prioritized vulnerability categories and a threat list to make the threat modeling activity easier.
Threat modeling is a structured activity for identifying and evaluating application threats and vulnerabilities. This How To presents a question-driven approach to threat modeling that can help you identify security design problems early in the application design process. This approach allows you to quickly create a basic threat model for your application scenario. Then you can use this threat model to help refine your application's design early and for communication among team members.
The threat modeling approach presented here focuses on identifying and addressing vulnerabilities. The security objectives, threats, and attacks that you identify in the early steps of the activity are the scoping mechanisms designed to help you find vulnerabilities in your application. You can use the identified vulnerabilities to help shape your design and direct and scope your security testing.
Before You Begin
Use this module to quickly create an effective threat model for your application. When using this module, keep the following in mind:
Do not get blocked on steps or implementation. Focus on the approach. If you do get blocked on a particular step, skip ahead to step 4, "Identify Threats." The primary objective of the activity is to improve security design, not to model for the sake of modeling.
Use scenarios to scope the modeling activity. Identify scenarios that are out of scope to help limit your threat modeling activity. What are you not going to talk about? For example, are operational practices out of scope?
Use your existing design documents if you have them. Use items such as documented use cases or user stories, data flow diagrams, architecture diagrams, and other design documentation if you have them.
Start with a whiteboard. It can be easier to get started by modeling on a whiteboard before you start capturing information in documents or getting lost in details. A helpful technique is to use a digital camera or whiteboard with print capability to document and distribute the information from the whiteboard.
Use an iterative approach. Add more detail and evolve your threat model as you continue design and development. Use ongoing modeling to reduce risk and to inform your design decisions. For example, when early in the design process, you may have only basic use cases, an initial deployment topology, and an idea of how you will layer your application. By using an iterative approach, you become familiar with the modeling process and can evolve your threat model to examine "what if" scenarios as more information becomes available to you.
You might choose to adopt a more formal approach and identify milestones for revisiting your model. What is most important is that you revisit the model when you need to make an engineering decision, as you introduce new levels of risk, and when you contemplate significant design choices.
Review and use the Template: Web Application Threat Model. Use the companion template while creating your threat model. The template includes exit criteria for each step described in this How To.
- Adapt the activity for your situation. If you are new to threat modeling, consider reading this document and then reading the companion walkthrough, "Walkthrough: Creating a Threat Model for a Web Application," to become more familiar with the approach. If you have existing applications, you can use the threat and vulnerability identification approaches in steps 4 and 5. With this information, you can determine where to focus your efforts.
Obtain input about host and network constraints from your system and network administrators. To be able to draw and understand your end-to-end deployment scenario, you need to have information about the host configuration, firewall policies, allowed protocols and ports, and so on. Obtain this information by talking to your system and network administrators.
The following input is useful for threat modeling:
- Use cases and usage scenarios
- Data flows
- Data schemas
- Deployment diagrams
Although all of these are useful, none of them are essential. However, you do need to have knowledge of your application's primary function and architecture.
The output of the threat modeling activity is a threat model. The main items captured by the threat model include the following:
- A list of threats
- A list of vulnerabilities
Summary of Steps
The five major threat modeling steps are shown in Figure 1.
Figure 1. The iterative threat modeling process
These steps are:
Identify security objectives. Clear objectives help you to focus the threat modeling activity and determine how much effort to spend on subsequent steps.
Create an application overview. Itemizing your application's important characteristics and actors helps you to identify relevant threats during step 4.
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.
Identify threats. Use details from steps 2 and 3 to identify threats relevant to your application scenario and context.
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.
You add progressively more detail to your threat model as you move through your application development life cycle and discover more details about your application design. Because key resources identified in threat modeling are also likely to be key resources from a performance and functionality perspective, you can expect to revisit and adjust your model as you balance all of your needs. This is normal and is a valuable outcome of the process.
Step 1: Identify Security Objectives
Security objectives are goals and constraints related to the confidentiality, integrity, and availability of your data and application. They include:
- Confidentiality. This includes protecting against unauthorized information disclosure.
- Integrity. This includes preventing unauthorized information changes.
- Availability. This includes providing the required services even while under attack.
Security-specific objectives are a subset of project objectives, and you should use them to guide your threat modeling efforts. You may find it helpful to think of security objectives in terms of constraints. Consider the question, "What do you not want to happen?" For example, an attacker must not be able to steal user credentials.
By identifying your key security objectives, you can determine where to focus your efforts. Identifying your objectives also helps you to understand the goals of potential attackers and concentrate on those areas of your application that require closer attention. For example, if you identify customer account details as sensitive data that needs protecting, you can examine how securely the data is stored and how access to the data is controlled and audited.
To determine your security objectives, consider the following questions:
- What client data do you need to protect? For example, does your application use user accounts and passwords, customer account details including personalization information, financial history and transaction records, customer credit card numbers, bank details, or travel itineraries?
- Do you have compliance requirements? Compliance requirements may include security policy, privacy laws, regulations, and standards.
- Do you have specific quality of service requirements? Quality of service requirements include availability and performance requirements.
- Are there intangible assets that you need to protect? Intangible items include your company's reputation, trade secrets, and intellectual property.
The following are examples of some common security objectives:
- Prevent attackers from obtaining sensitive customer data, including passwords and profile information.
- Meet service-level agreements for application availability.
- Protect the company's online business credibility.
Adapted from Microsoft patterns & practices guidance.