Montag, 4. Januar 2010 22:49In the SDL Threat Modeling Tool manual, the instructions for Hierarchical Diagrams states (on page 23) "For each data flow element, right-click on the element and select Do not auto generate threats". The result is the data flows over the trust boundary (commands, responses) no longer have threats autogenerated. This does not make sense to me, since threats across trust boundaries should be analysed in greater detail than those that are NOT across trust boundaries.
Can someone please explain why the example in the manual disabled autogeneration of threats on the data flows across the trust boundary?
- Verschoben Hengzhe Li Dienstag, 21. Juni 2011 12:03 Forum Consolidate (From:Microsoft Security Development Lifecycle (SDL) - Threat Modeling)
Dienstag, 5. Januar 2010 06:24Hey Matthew,
In a hierarchical diagram you drill down into the individual processes which may have more detail at different levels within the same threat model (TM), or may be in an entirely different TM. In my mind, the reason you would not want to generate threats at that level is it belongs in the child diagram where you can explore it in more detail. So in that example, if you want to explore the threats at the trust boundary, what you really care about is how the inputs affects each process, and how you deal with it. Remember that from the standpoint of the STRIDE by element modeling a trust boundary is nothing more than a separator/interface between two items where untrusted data crosses. And more recently, Microsoft changed their attitude (or should I say Adam swallowed his pride) and trust boundaries no longer are limited to intersections across data flows as it used to. Now it can represent logical separations between processes or data stores. That means at times, you really need to address the threats at the process level, which may be someone elses responsibility entirely in more complex systems which you have no control over their threat model.
I would expect that you would want to generate the threats as you go deeper in the hierarchy. As such, it would be duplicating effort to generate the same threats for the same inputs higher up in the DFD tree. The reverse can also be said. You may decide to generate the threats at the primary Context Level DFD and not duplicate it in the children. If you read the steps in that example they are asking you to copy the elements into the child, which means you may have already covered the threats elsewhere.
I will admit the documentation isn't clear enough to say where it IS evaluated. In my opinion the choice is really yours. Microsoft may disagree with that, and I encourage them to express why. But as far as I can see, as long as you address those threats somewhere in the model, you are ok. Where do you feel more comfortable in doing that? Personally I try to leave the Context DFD alone, and deal with the data flow details where it actually impacts the element under review. But that's just me.
- Als Antwort markiert Matthew Theobald Dienstag, 5. Januar 2010 17:26
Dienstag, 5. Januar 2010 17:25Thanks for your detailed explanation - much appreciated.
The problem is that if you copy the data flows from the Context diagram to the child diagram (as per the manual), and then disable auto generation of threats for the data flow on the child diagram, then auto generation of threats is also disabled for the data flow on the Context diagram! I'm not sure if this is intended functionality or if it is a bug in the Threat Modeling Tool.
However, after a little experimentation I found that if I created a new data flow on the child diagram with the same name as the data flow on the Context diagram (a "brute-force" copy), and then disabled auto generation of threats for the data flow on the child diagram, auto generation of threats is not disabled for the data flow on the Context diagram.
Long story short, I have a means to generate or disable auto generation of threats where I need to.
Freitag, 10. Dezember 2010 04:01
We havw found that IGNORING the suggestion in the help manual to select "Do not auto generate threats " is not a good approach. This removes all the threats for those elements from the entire TM and not just the child. Generally a bad idea IMHO.
If you copy and paste elements, so your Child Diagram will have elements as in the Parent, things seem to work fine. The copy process does not seem to create copies in the threat list or in the reports, but rather just separate views of the same elements. For example, if I copy Process123 from the contect diagram to the child diagram, there is only one Process123 in the Threats windwo, the Reports or in the resulting XML in the TM file.
Eric Byres P.Eng Chief Technology Officer Tofino Security Inc. Tel 250 390 1333 | firstname.lastname@example.org Makers of Tofino™ | tofinosecurity.com Visit our blog: Practical SCADA Security Follow Eric Byres on Twitter