RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Threat Modeling : Page 2

You cannot build secure systems until you understand your threats. Threat modeling is essential to a secure enterprise. Microsoft has adopted threat modeling, and now no product design is complete without a threat model. In this article, Microsoft's Michael Howard uses his experience to explain the process of threat modeling and how to use it in any organization.

The Process
Analyzing threats can be a great deal of work, however, it's cheaper to find a security design bug at this stage and remedy the solution before coding starts. You must also keep the threat model current, reflecting new threats and mitigations as they arise.

Here is the threat-modeling process:

  • Assemble the threat-modeling team.
  • Decompose the application.
  • Determine the threats to the system.
  • Rank the threats by decreasing risk.
  • Choose how to respond to the threats.
  • Choose techniques to mitigate the threats.
  • Choose the appropriate technologies for the identified techniques.
You might need to perform the process a couple of times because no one is clever enough to formulate all the threats in one pass. In addition, changes occur over time, you learn new issues, and the business, technical, and vulnerability landscape evolves. All of these have an impact on the threats to your system.

Let us look at each part of this process.

Assemble the Threat-Modeling Team
Gather members of the development group to perform the initial threat analysis process. Have one person lead the team; generally, this person is the most security-savvy person of the team. By "security-savvy" I mean that this person can look at any given application or design and work out how an attacker could compromise the system. The security person may not be able to read code but they should know where other products have failed in the past. This is important because threat modeling is more productive when people have an appreciation of how to attack systems.

Make sure at least one member from each development discipline is at the meeting, including design, coding, testing, and documentation. You'll get a broader view of the threats and mitigation techniques with a broader group. If you have people outside your immediate team who are good with security, invite them—fresh eyes and questions about how things work often lead to interesting discoveries. However, don't have more than ten people in the room or the meeting will slow to a standstill and you'll make little progress. I've also found it useful to invite a marketing or sales person, not only to get input but also to educate.

Before the threat-modeling process is under way it's important to point out to all team members that the goal is not to solve problems at the meeting but to identify the components of the application and how they interact and, eventually, to find as many security threats as possible. The design and code changes (and arguments) are made in later meetings. Some discussion of mitigation techniques is inevitable; just don't let the conversation get too far into the details.

Also, the first meeting should use a whiteboard and should later be transcribed to an electronic form for further analysis and review.

Formally Decomposing the Application
If you have never performed threat analysis on your application, you probably have another category of security bugs you never knew you had!
Applications are built from individual features and each feature can be attacked. It is therefore important that you understand the components of the application. In my experience both data flow diagrams (DFDs) and UML activity diagrams make a useful decomposition technique for threat analysis. (Microsoft Visio Professional 2002 includes a Data Flow Diagram template and many UML templates.)

It is not the purpose of this article to teach you how to create DFDs or how to use UML. There are plenty of good reference books on the subject.

The guiding principle for DFDs is that you can decompose an application or a system into subsystems, and you can decompose subsystems into still lower-level subsystems. This iterative process makes DFDs useful for decomposing applications.

In the first phase of decomposition you'll determine the boundaries or scope of the system that you're analyzing as well as the boundaries between trusted and untrusted components. If you do not define the scope of the application you'll end up wasting a great deal of time discovering threats that are outside your scope and beyond the control of your application. Once you've completed this phase you'll drill down to lower levels by using level-0, level-1, and level-2 diagrams, and so on.

When you define the scope of the DFD, consider the following points:

  • Ignore the inner workings of the application. At this stage it does not matter how things work; you want to define scope, not functional details.
  • To what events or requests must the system respond? For example, a stock market Web service could receive requests for a stock quote based on a ticker symbol.
  • What responses will the process generate? In a stock quote example, the Web service could provide a time and a quote, including current ask and bid prices.
  • Identify the data sources as they relate to each request and response. Some data sources are persistent (files, registry, databases, etc.), and others are short-lived or ephemeral (cache data).
  • Ascertain who/what receives each response.
Eventually you'll get to a point where you understand the composition of the application. Generally, you should have to dive down no more than four levels deep if all you are doing is threat modeling.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date