As I mentioned in my previous post, Create a Threat Model - Step 1, there are five major threat modeling steps, as shown below in Figure 1.  This article explains the second step, Create an Application Overview.

Figure 1. The iterative threat modeling process

Step 2: Create an Application Overview

In this step, you outline what your Web application does. Your goal is to identify your application's key functionality, characteristics, and clients. This will help you to identify relevant threats during step 4.

Note   Remember that threat modeling is an iterative process. Do not let this step block your progress. Identify as much detail as you can and then add more detail as your design evolves. For example, if you are in the middle of your design and have not tackled physical deployment, you can still perform this step, although with less data. Itemize what you can as soon as you can.

To create an application overview:

• Draw the end-to-end deployment scenario.
• Identify roles.
• Identify key usage scenarios.
• Identify technologies.
• Identify application security mechanisms.

The next sections describe each of these.

Draw the End-to-End Deployment Scenario

Use a whiteboard to draw the end-to-end deployment scenario. First, draw a rough diagram that describes the composition and structure of your application, its subsystems, and its deployment characteristics. Add details about the authentication, authorization, and communication mechanisms as you discover them. Remember that you may not have all of the details early in the design process.

Figure 2 is an example of an initial whiteboard diagram that shows the application architecture with some details.

Figure 2. Example whiteboard drawing depicting an application architecture

Your deployment diagram should generally include the following:

• End-to-end deployment topology. Show the layout of the servers and indicate intranet, extranet, or Internet access. Start with logical network topologies, and then refine this to show physical topologies when you have those details. You can add or remove threats depending on your choice of specific physical topologies.
• Logical layers. Show where the presentation layer, business layer, and data access layers reside. Refine this to include physical server boundaries when you know them.
• Key components. Show the important components within each logical layer. Refine this to include actual process and component boundaries when you know them.
• Key services. Identify any important services. Show these as processes when you know them.
• Communication ports and protocols. Show which servers, components, and services communicate with each other and how they do it. Show the specifics of inbound and outbound information packages when you know them.
• Identities. Show the main identities used for the application and any relevant service accounts if you have this information.
• External dependencies. Show the dependencies that your application has on external systems. Later in the modeling process, this will help you identify vulnerabilities that can arise if any assumptions you make about the external systems are false or if the external systems change in any way.

Note   As your design evolves, you should regularly revisit the threat model to add more detail. For example, you might not know all of the components initially. Subdivide your application as necessary to get enough detail to find your threats.

Identify Roles

Identify your application's roles: that is, identify who can do what within your application. What can your users do? What higher-privileged groups of users do you have? For example, who can read data, who can update data, who can delete data?

Use role identification to determine both what is supposed to happen and what is not supposed to happen.

Identify Key Usage Scenarios

What are the important features of your application? What does it do? Use your application's use cases to derive this information. Identify the dominant application functionality and usage, and capture the Create, Read, Update, and Delete aspects.

Key features are often explained in the context of use cases. They can help you and others to understand how your application is intended to be used and how it can be misused. Use cases help you identify data flows and provide focus when you identify threats later in the modeling process.

Avoid attempting to list every possible use case. Instead, start by identifying the main use cases that exercise the predominant Create, Read, Update, and Delete functionality of your application. For example, a self-service, employee human resources application might include the following use cases:

• Employee views financial data.
• Employee updates personal data.
• Manager views employee details.
• Manager deletes employee records.

In these cases, you can look at the possibilities of the business rules being misused. For example, consider a user trying to modify personal details of another user. You often need to consider several use cases happening simultaneously to perform a complete analysis.

Also identify what scenarios are out of scope, and use your key scenarios to constrain the discussion. For example, you might decide that operational practices, such as backup and restore, are out of scope for the initial threat modeling exercise.

Identify Technologies

Where you can identify them, list the technologies and key features of the software and technologies that you use. Identify the following:

• Operating systems
• Web server software
• Database server software
• Technologies used in the presentation, business, and data access layers
• Development languages

Identifying technologies helps you to focus on technology-specific threats later in the threat modeling activity. It also helps you determine the correct and most appropriate mitigation techniques.

Identify Application Security Mechanisms

Identify any key points that you know about the following:

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

The purpose of this effort is to identify interesting details and be able to add detail where necessary, or to identify where you might need to learn more.

For example, you might know how your application is authenticated by the database or how your users are authorized. You might know the other areas where your application performs authentication and authorization. You might also know certain details about how input validation is to be performed. Highlight these and other key elements of your application security mechanisms.

Adapted from Microsoft patterns & practices guidance.