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


Threat Modeling : Page 6

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.

Going Over the Threat-Modeling Process One More Time
Let's review the threat-modeling process one more time to make sure it's well understood.

Step 1
Decompose the application into threat targets by using an analysis method such as data flow diagrams. In the case of DFDs, the threat targets are every data source, process, data flow, and interactor or actor.

Step 2
Using STRIDE, identify threats for each of the threat targets. These serve as the roots for the threat trees, there is one tree per threat goal.

Step 3
Build one or more threat trees for each threat target, as appropriate.

Step 4
Use a threat ranking method to determine the security risk for each threat tree.

Step 5
Sort the threats in order from highest to lowest risk.

Once you've done this, your next step is to determine how you deal with the threats—our next topic!

Choose How to Respond to the Threats
You have four options when considering threats and how to mitigate them.

Option One: Do Nothing
Doing nothing is rarely the correct solution because the problem is latent in the application, and the chances are greater than zero that the issue will be discovered and you will have to fix the problem anyway. It's bad business and bad for your clients because you might be putting your users at risk. If you decide to do nothing, at least check whether the feature that is the focus of the threat can be disabled by default. That said, you ought to consider one of the following three options instead.

Option Two: Warn the User
Inform the user of the problem and allow the user to decide whether to use the feature. Like doing nothing this option can be problematic—many users don't know what the right decision is. The decision is often made more difficult by convoluted text, written by a technical person, appearing in a warning dialog box. Users will ignore warnings if they come up too often and they don't have the expertise to make a good decision.

If you decide to warn the user about the feature in your documentation, remember that users don't read documentation unless they must!

Option Three: Remove the Problem
I've often heard development teams say that they have no time to fix a security problem, so they have to ship with the security flaw. This decision is wrong. Here's one last drastic option—pull the feature from the product. If you have no time to fix the problem and the security risk is high enough, you should consider pulling the feature from the product. If it seems like a hard pill to swallow, think of it from your user's perspective. Imagine that it was your computer that just got attacked. Besides, there's always the next version!

Option Four: Fix the Problem
The most obvious solution—remedy the problem with technology—can also be the most difficult because it involves more work for the designers, developers, testers, and, in some cases, documentation people. You can determine mitigation categories based on the threat category. The following list shows some example techniques:

  • Spoofing - strong authentication
  • Tampering—strong authorization techniques
  • Repudiation—digital signatures, timestamps, secure logging
  • Information Disclosure—strong encryption and key management, and strong access techniques
  • Denial of Service—strong authentication and authorization, packet filtering
  • Elevation of Privilege—don't run code as elevated accounts
The full list of potential mitigation techniques and technologies is beyond the scope of this article but you should always ask the question, "Does this mitigate the threat, or reduce the risk to an acceptable level?"

I strongly believe that threat modeling is a design necessity.. Without a threat model in place you cannot know if you have mitigated the most pressing threats. Simply playing Buzzword Bingo by liberally scattering security technologies around your application will not make it secure—the technologies might be inappropriate and fail to mitigate threats correctly. I also have no doubt that if you expend the effort and build up-to-date and accurate threat models, you will deliver more secure systems. Experience shows that about half of the security flaws will be discovered from threat modeling because they find different threats than those found through code review.

The process is simple: assemble the team, decompose the application (for example using DFDs), determine the threats to the system using threat trees and STRIDE, rank the threats, and then choose mitigation techniques based on the STRIDE category.

Threat models are a critical component of a sound security development process. At Microsoft, we mandate threat models as part of the design phase sign-off criteria.

Michael Howard is a Security Program Manager in the Secure Windows Initiative team at Microsoft. He is the author of "Designing Secure Web-based Applications for Microsoft Windows 2000" and the co-author of "Writing Secure Code," both from Microsoft Press. The latter book is mandatory reading at Microsoft. He also wrote the "Best Defense" column for DevX. His job is simple: help people build secure software. Ok, it's not that simple!.
Email AuthorEmail Author
Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date