As I mentioned in my previous two posts, Create a Threat Model - Step 1, and Create a Threat Model - Step 2, there are five major threat modeling steps, as shown below in Figure 1.  This article explains the third step, Decompose Your Application.

Figure 1. The iterative threat modeling process

Step 3: Decompose Your Application

In this step, you break down your application to identify trust boundaries, data flows, entry points, and exit points. The more you know about the mechanics of your application, the easier it is to uncover threats and discover vulnerabilities. To decompose your application:

• Identify trust boundaries.
• Identify data flows.
• Identify entry points.
• Identify exit points.

The next sections describe each of these.

Identify Trust Boundaries

Identify your application's trust boundaries to help focus your analysis on areas of concern. Trust boundaries indicate where trust levels change. You can think of trust from the perspective of confidentiality and integrity. For example, a change in access control levels in your application where a specific role or privilege level is required to access a resource or operation would be a change in trust level. Another example would be at an entry point in your application where you might not fully trust the data passed to the entry point.

To help identify trust boundaries:

• Start by identifying your outer system boundaries. For example, your application can write to files on server X, it can make calls to the database on server Y, and it can call Web service Z. This defines your system boundary.
• Identify access control points or the key places where access requires additional privileges or role membership. For example, a particular page might be restricted to managers. The page requires authenticated access and also requires that the caller is a member of a particular role.
• Identify trust boundaries from a data flow perspective. For each subsystem, consider whether the upstream data flow or user input is trusted, and if it is not, consider how the data flow and input can be authenticated and authorized. Knowing which entry points exist between trust boundaries allows you to focus your threat identification on these key entry points. For example, you are likely to have to perform more validation on data passed through an entry point at a trust boundary.

Some example trust boundaries are:

• A perimeter firewall. The firewall is likely to be the first trust boundary. It moves qualified information from the untrusted Internet to your trusted data center.
• The boundary between the Web server and database server. Your database may or may not be included in your application's trust boundary. Often the Web servers act as a second firewall to the databases. This significantly limits network access to the databases and thereby reduces the attack surface. Describe the network topology within your data center. Do any other applications write to the database? If they do, do you trust those applications? If you trust the applications that write to the database, you may still not want to trust the database—is it protected?
• The entry point into a business component that exposes privileged data (data that should be available to only particular users). In this case, you need an access check to ensure that only the appropriate callers are allowed access. This is a trust boundary.
• The boundary between your application and a third-party service. Do you trust the service's identity? Can you trust the data returned from the service?

Identify Data Flows

Trace your application's data input through the application from entry to exit. You do this to understand how your application interacts with external systems and clients and how internal components interact. Pay particular attention to data flow across trust boundaries and how that data is validated at the trust boundary entry point. Also pay close attention to sensitive data items and how these flow through your system, where they are passed over a network, and where they are persisted.

A good approach is to start at the highest level and then deconstruct the application by analyzing the data flow between individual subsystems. For example, start by analyzing the data flow between your Web application, your middle tier servers, and your database server. Then consider page-to-page and component-to-component data flows.

Identify Entry Points

The entry points of your application also serve as entry points for attacks. Entry points can include the front-end Web application listening for HTTP requests. This entry point is intended to be exposed to clients. Other entry points, such as internal entry points exposed by subcomponents across the layers of your application, may exist only to support internal communication with other components. However, you should know where these are and what types of input they receive in case an attacker manages to bypass the front door of the application and directly attack an internal entry point. Additional levels of checking provides defense in depth but may be costly in terms of money and performance.

Consider the trust levels required to access an entry point and the type of functionality exposed by the entry point. Early in the threat modeling activity, focus your attention on entry points that expose privileged functionality, such as administration interfaces.

Identify Exit Points

Identify the points where your application sends data to the client or to external systems. Prioritize the exit points where your application writes data that includes client input or includes data from untrusted sources, such as shared databases.