Threat Modeling Made Easy

Published: May 21, 2013

Author: Dan Griffin, Founder of JW Secure and Enterprise Security MVP

How Do You Know What's Secure?

During consulting engagements, customers often ask for assurance for the security of the solutions my company implements. It is satisfying for us that we have methods in place to give those assurances. We always recommend that the project budget include a threat model and an analysis of the final deliverable against the findings of that threat analysis.

Managing risk in the enterprise is of utmost importance. The good news is that threat modeling is easier than most people think and is an effective process for systematically identifying and mitigating risk. The objective is to consider the potential impact of external attacks against sensitive data, as well as the risk posed by insider and advanced persistent threats.

Threat Modeling

The JW Secure threat modeling process evolved from two resources. The first is
Threat Modeling, the book by Swiderski and Snyder. The second is the
SDL Threat Modeling Tool from Microsoft. After thoroughly investigating the concepts, we evolved them to work well in simpler projects that target a single point solution.

The first step in modeling any system is identification of the data assets that need to be protected. Once you know what you need to protect, it is necessary to track the flow of that data throughout its lifecycle. The next step is to focus on the part of the data flows that will be impacted by the project. The best representation of the model is a data flow diagram (DFD) than can be used to identify the different security zones where the data will transit or be stored.

The preceding figure is a DFD representing a typical cloud-based, three-tier line of business application (for example, the kind that is created with Ruby on Rails or ASP.NET MVC). There are three trust zones in this DFD and the boundaries between them are represented as dashed red lines. In this example, each trust zone has a single entity with bilateral communications links to the next. The goal of the DFD is to enumerate the places where sensitive data is accessible and where it is vulnerable to attack. More complete diagrams would include entities that authenticate users and authorize access to the data.

Once the DFD exists, the project team uses it to enumerate the threats. The DFD and threat list are then used as guidance by the project architects. One advantage of having the threat model at this early stage is that it can be used to system architecture and implementation decisions when changes are relatively inexpensive to make.

Threat Analysis

The Threat Analysis phase begins after the code development and testing has started. A key to hardening any software project against external attacks is an analysis of the deliverables of the project against a threat model as described above. The developers and testers of a software component are the subject matter experts and it is precisely those individuals that need to be involved in the analysis of the threats. Typically, a technical program manager takes ownership of the threat model and schedules the analysis session. The architect, developer, and tester should be present and each threat should be discussed in turn. Some threats will be determined to have little impact on the security of the data, while others will be mitigated by changes to be implemented by the development team. Any residual risks should be escalated for management review to determine if an unmitigated threat is acceptable to the project as a whole.

The entire development team benefits by engaging in the threat modeling process. This involvement leads to heightened awareness of the security ramifications of design and implementation decisions. Additional benefits, often overlooked, include higher overall code quality as well as greater management visibility into the benefits of instituting security processes that can otherwise be difficult to quantify.

Call to Action

In summary a security review should be enabled using the following steps:

Create a data flow diagram for the project.

Enumerate the threats using the templates provided in the references at the end of this overview.

Review the design with the project architects.

Enumerate potential threat mitigations.

Make what changes are necessary to design, implementation, configuration, or documentation.

Ensure that management understands the residual risk.

I welcome questions and feedback about the JW Secure threat modeling process. Please reach out to me at
dan@jwsecure.com.