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.
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.
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.
Build one or more threat trees for each threat target, as appropriate.
Use a threat ranking method to determine the security risk for each threat tree.
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 threatsour 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 problematicmany 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 optionpull 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 solutionremedy the problem with technologycan 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
- Tamperingstrong authorization techniques
- Repudiationdigital signatures, timestamps, secure logging
- Information Disclosurestrong encryption and key management, and strong access techniques
- Denial of Servicestrong authentication and authorization, packet filtering
- Elevation of Privilegedon'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 securethe 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.