Threat Modeling Again, What does STRIDE have to do with threat modeling?
In my last couple of posts, I've talked about the STRIDE categories. As I mentioned, STRIDE provides a convenient classification mechanism for threats, and threat modeling is all about trying to identify the threats to your feature/component/whatever.
When we first started threat modeling, we already had the idea of STRIDE categories, but we really didn't know how to apply them. We'd go into the big threat modeling meeting and look at each of the pieces of our diagram and ask "what is the spoofing (or tampering, or whatever) threat against this component"? We were thinking about the STRIDE categories as discrete elements, not as categories in which to collect threats.
After a while, it became obvious that not only doesn't this work (again, it's very adhoc), but it's missing the point. The point is to identify the threats and put them in the appropriate bucket so you can help to understand how to mitigate the threat.
One of the interesting aspects of threats is that they are permanent. For a given design, the threats against that design are static, for any data flow diagram, you have a static set of threats that apply to that data flow diagram. There may be more than one threat in a particular category for a particular element, but every element is subject to certain threats.
Once we had this mindset shift, we started thinking about how the STRIDE categories applied to various elements, and we came to an interesting realization.
It turns out that some STRIDE threats only apply to particular types of elements. If you think about it, it makes sense - for instance, an Elevation of Privilege threat doesn't apply to data stores (since a data store simply holds data, it operates at no privilege level).
Remember that we consider four types of elements in a threat model: External Entities, Processes, Data Stores and Data Flows. For each element type, the following threats are considered valid:
External Entities: Spoofing, Repudiation. Since an external entity could be anything, including the human being interacting with the component, Tampering, Information Disclosure, Denial of Service and Elevation of Privilege threats don't really make sense). On the other hand, you can absolutely spoof a human being, and human beings can repudiate operations.
Processes: Processes are subject to all of the STRIDE threats (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege).
Data Stores: Tampering, Information Disclosure, Denial of Service (as I mentioned above, EoP etc don't really apply to static stores), and repudiation.
Data Flows: Tampering, Information Disclosure, Denial of Service.
Repudiation threats against data stores require special mention. Data stores often come under attack to allow for a repudiation attack to work (if you have a log located in a data store, the attacker might try to flood the data store with log entries to enable a repudiation attack. In addition, logs held in data stores are almost always the mitigation against a repudiation threat.
And with that final realization, all the pieces have been brought together to describe Microsoft's current methodology for threat modeling, which we call STRIDE-per-element.
Next: STRIDE-per-element.
Comments
Anonymous
September 07, 2007
The comment has been removedAnonymous
September 10, 2007
As I mentioned the other day , we had three huge big realizations as we've been doing more and more threatAnonymous
September 10, 2007
As I mentioned the other day , we had three huge big realizations as we've been doing more and moreAnonymous
September 12, 2007
Adam Shostack here. I've been meaning to talk more about what I actually do, which is help the teamsAnonymous
October 02, 2007
I want to wrap up the threat modeling posts with a summary and some comments on the entire process. Yeah,