Threat trees seem to be missing - How can we create multiple vulnerabilites on a single STRIDE threat?

Question

If we look at Michael's book on SDL we see (chap22) the concept of threat trees.  For example on tampering with the data flow on an end node there is a table of vulnerabilites like replay, collisions, etc. each of which result in different tests and potentially different bugs with different mitigations. How can the TMT be used to accommodate this concept.

Answer 1

Hey Tom,

The SDL Threat Modeling tool is designed to provide a STRIDE by element modeling approach. If you look closely at how Chaper 22 is laid out in the SDL LifeCycle book that you are referring to, Mike explains how when you find a threat in your model you should refer to that chapter to explore the threat tree pattern for the given element. This is because there is a correlation between the security-related preconditions for each STRIDE category, as applied to each DFD element. Over time as the SDL has matured, there have been common patterns that have bubbled up that allows the SDLTM to assign STRIDE category to DFD elements based on historical review of such things. In other words, the patterns end up looking the same across DFD elements. And in many cases, it means the mitigations you can apply are usually quite similar.

If I understand correctly what was written in that chapter, what they are getting at is that while you generate threats in your model and you look at each element, reflect on the threat tree for possible exposure. Then you can address each item, one by one, in the model. If the threat is not directly created by the SDLTM autogeneration subsystem, you can always add a new threat manually. Very useful if you are playing Elevation of Privilege (EoP) with your team and during discussion you decide you have found something not previously covered in the existing threats.

In short, the SDLTM doesn't create threat tree patterns for you. The patterns have come to play from experience that SDL has exposed to those who do threat modeling, and are quite common across DFD elements, and therefore items in your architecture. I believe that the table under each pattern is pretty much what the SDLTM exposed to you for each element in the tool.

If you find you have different bugs that you want to address on an element, it makes sense to break that out and specifically model it. That is EXACTLY what the "Add Threat" link is for.  

HTH. YMMV on how you approach it. But to me, threat tree patterns are pre-defined in that chapter, getting us to ask ourselves (and our teams) deeper questions than what the autogenerated threats will do.