As I mentioned in my previous three posts, Create a Threat Model - Step 1, Create a Threat Model - Step 2, and Create a Threat Model - Step 3, there are five major threat modeling steps, as shown below in Figure 1. This article explains the fourth step, Identify Threats.

Figure 1. The iterative threat modeling process

Step 4: Identify Threats

In this step, you identify threats and attacks that might affect your application and compromise your security objectives. These threats are the bad effects that could happen to your application. To conduct this identification process, bring members of the development and test teams together to conduct an informed brainstorming session. Use a whiteboard to identify potential threats. Ideally, the team consists of application architects, security professionals, developers, testers, and system administrators.

You can use two basic approaches:

Start with common threats and attacks. With this approach, you start with a list of common threats grouped by application vulnerability categories. Next, apply the threat list to your own application architecture. While doing this, use the data you gathered. For example, use the identified scenarios to review data flows, paying particular attention to entry points and where trust boundaries are crossed. You will be able to eliminate some threats immediately because they do not apply to your application and its use cases. Use the "Cheat Sheet: Web Application Security Frame" as a starting point.
Use a question-driven approach. A question-driven approach can help you identify relevant threats and attacks. The STRIDE categorization includes broad categories of threats, such as spoofing, tampering, repudiation, information disclosure, and denial of service. You can use the STRIDE model to ask questions related to each aspect of the architecture and design of your application. This is a goal-based approach, where you consider the goals of an attacker. For example, could an attacker spoof an identity to access your server or Web application? Could someone tamper with data over the network or in a data store? Is sensitive information disclosed when you report an error message or log an event? Could someone deny service?

While identifying threats, examine the application tier by tier, layer by layer, and feature by feature. By focusing on vulnerability categories, you focus on the areas where security mistakes are most frequently made. The threats identified at this stage do not necessarily indicate vulnerabilities. Identify potential threats and the actions that an attacker might try to use to exploit the application.

During this step, you perform the following tasks:

Identify common threats and attacks.
Identify threats along use cases.
Identify threats along data flows.

The next sections describe each of these.

Identify Common Threats and Attacks

There are a number of common threats and attacks that rely on common vulnerabilities. As a starting point, use the companion document, "Cheat Sheet: Web Application Security Frame." The cheat sheet will help you identify threats and attacks relevant to your application.

Web Application Security Frame

The following vulnerability categories were developed 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. This section identifies a set of key questions to ask for each category.

Authentication

Review authentication by asking the following:

How could an attacker spoof identity?
How could an attacker gain access to the credential store?
How could an attacker mount a dictionary attack? How are your user's credentials stored and what password policies are enforced?
How can an attacker modify, intercept, or bypass your user's credential reset mechanism?

Authorization

Review authorization by asking the following:

How could an attacker influence authorization checks to gain access to privileged operations?
How could an attacker elevate privileges?

Input and Data Validation

Review input and data validation by asking the following:
How could an attacker inject SQL commands?
How could an attacker perform a cross-site scripting attack?
How could an attacker bypass input validation?
How could an attacker send invalid input to influence security logic on the server?
How could an attacker send malformed input to crash the application?

Configuration Management

Review configuration management by asking the following:

How could an attacker gain access to administration functionality?
How could an attacker gain access to your application's configuration data?

Sensitive Data

Review sensitive data by asking the following:

Where and how does your application store sensitive data?
When and where is sensitive data passed across a network?
How could an attacker view sensitive data?
How could an attacker manipulate sensitive data?

Session Management

Review session management by asking the following:

Do you use a custom encryption algorithm, and do you trust the algorithm?
How could an attacker hijack a session?
How could an attacker view or manipulate another user's session state?

Cryptography

Review cryptography by asking the following:

What would it take for an attacker to crack your encryption?
How could an attacker obtain access to encryption keys?
Which cryptographic standards are you using? What, if any, are the known attacks on these standards?
Are you creating your own cryptography?
How does your deployment topology potentially impact your choice of encryption methods?

Parameter Manipulation

Review parameter manipulation by asking the following:

How could an attacker manipulate parameters to influence security logic on the server?
How could an attacker manipulate sensitive parameter data?

Exception Management

Review exception management by asking the following:

How could an attacker crash the application?
How could an attacker gain useful exception details?

Auditing and Logging

Review auditing and logging by asking the following:

How could an attacker cover his or her tracks?
How can you prove that an attacker (or legitimate user) performed specific actions?

Identify Threats Along Use Cases

Examine each of your application's key use cases that you identified earlier, and examine ways in which a user could maliciously or unintentionally coerce the application into performing an unauthorized operation or into disclosing sensitive or private data.

Ask questions and try to think as an attacker would. Examples of the types of question you should ask include the following:

How can a client inject malicious input here?
Is data being written out based on user input or on unvalidated user input?
How could an attacker manipulate session data?
How could an attacker obtain sensitive data as it is passed over the network?
How could an attacker bypass your authorization checks?

Identify Threats Along Data Flows

Review the key use cases and scenarios, and analyze the data flows. Analyze the data flow between individual components in your architecture. Data flow across trust boundaries is particularly important. A piece of code should assume that any data from outside the code's trust boundary is malicious. The code should perform thorough validation of the data.

When identifying threats associated with data flows, ask the following questions:

How does data flow from the front end to the back end of your application?
Which components call which components?
What does valid data look like?
Where is validation performed?
How is the data constrained?
How is data validated against expected length, range, format, and type?
What sensitive data is passed between components and across networks, and how is that data secured while in transit?

Note Use existing documentation if you have it. For example, data flow diagrams (DFDs) and Unified Modeling Language (UML) sequence diagrams can help you to analyze your application and identify data flows.

Explore Additional Threats by Using Threat/Attack Trees

The previous activities have helped you to identify the more obvious and pervasive security issues. You can now explore additional threats and attacks. (It is helpful to set a time limit so that you do not become blocked by this activity.)

Attack trees and attack patterns are the primary tools that many security professionals use. They allow you to analyze threats in greater depth, going beyond what you already know to identify other threat possibilities.

The categorized lists of known threats only reveal the common, known threats. Additional approaches, such as using threat/attack trees and attack patterns, can help you identify other potential threats.

An attack tree is a way of identifying and documenting the potential attacks on your system in a structured and hierarchical manner. The tree structure gives you a detailed picture of various attacks that the attacker uses to compromise the system. By creating attack trees, you create a reusable representation of security issues that will help to focus your threat and mitigation efforts. Your test team can use the trees to create test plans that validate security design. Architects or developer leads can use the trees to evaluate the security cost of alternative approaches. Developers can use the trees to make informed coding decisions during implementation.

Attack patterns are a formalized approach to capturing attack information in your enterprise. These patterns can help you identify common attack techniques.

Creating Attack Trees

When creating an attack tree, assume the role of the attacker. Consider what you must do to launch a successful attack and identify goals and sub-goals of the attack. You can use a hierarchical diagram to represent your attack tree, or you can use a simple outline. What is important is that you construct something that portrays the attack profile of your application. Then you can evaluate security risks and use the appropriate countermeasures to mitigate them, such as correcting a design approach, hardening a configuration setting, and other solutions.

Start building an attack tree by creating root nodes that represent the goals of the attacker. Then add the leaf nodes, which are the attack methodologies that represent unique attacks. Figure 3 shows a simple example.

Figure 3. Attack tree example

You can label leaf nodes with AND and OR labels. For example, in Figure 3, both 1.1 and 1.2 must occur for the threat to result in an attack.

Attack trees like the one in Figure 3 have a tendency to become complex quickly. They are also time-consuming to create. An alternative approach is to structure your attack tree using an outline, such as the following.

1. Goal One
 1.1 Sub-goal one
 1.2 Sub-goal two2
2. Goal Two
 2.1 Sub-goal one
 2.2 Sub-goal two

Note In addition to goals and sub-goals, attack trees include methodologies and required conditions.

The following is a more complete example of the outline approach.

Threat #1 Attacker obtains authentication credentials by monitoring the network
 1.1 Clear text credentials sent over the network
 AND
 1.2 Attacker uses network-monitoring tools
 1.2.1 Attacker recognizes credential data

Adapted from Microsoft patterns & practices guidance.

Create a Threat Model - Step 4