Microsoft Threat Modeling Tool (MS TMT) is a free threat modeling tool offered by Microsoft. In this article, I would like to draw very basic diagrams and compare the generated analysis output to show how MS TMT logic works. It makes it easier to work on your own models, once you know the logic behind. Of course, this is a reverse engineering approach. You are also welcome to read STRIDE related books and documents.
One more note before we begin: One of the heroes behind this tool is Adam Shostack, the master of “Threat Modeling”. I highly recommend his book about Threat Modeling. It’s a lovely and fascinating book, I guarantee that you will not get bored while reading those 600+ pages. I bet you will also read Appendix sections for the first time in your life.
(Note: The person in the picture below is not Adam Shostack, it’s auto-picked by hyperlink generator. Sorry about that!)
1. Two Elements with Same Attributes
When you model, you need to drag elements from “Stencils” window. The names of elements are easy to interpret, but sometimes you get confused and cannot decide. Here, I will try to demonstrate how they differ (or not), so that we make better decisions next time.
I will use OS Process and Thread from “Generic Process” group and compare their analysis output. I am using the regular “SDL TM Knowledge Base” template.
We will draw the simplest diagram for each stencil and then compare the output. Each one has a request and a response flow to a Web Server, and they both have an Internet Boundary. Below, you see how our diagrams look like in each case:
And let’s also see Element Properties side by side. You will see that the only difference are the element type and name (i.e. “OS Process” and “Thread”). Please take your time to look what kind of “attributes” are presented. They are really important to train yourself on STRIDE methodology and perspective:
When we look at above element properties, we can make an initial guess that the analysis output will be same. Is it correct? Ask yourself, think, and keep reading.
To see this, we switch our View to “Analysis View”. We get all the results, but we want to diff the output. In order to this, I saved the analysis output as “CSV” file (by clicking the button at the bottom of the related window), then used Excel’s “Text to Columns” option. The initial outcome was like below:
I decided to just use Title column and compare two outputs by sorting against Title column. To make it easier, I decided to replace “Thread” and “Web Server” with “<PLACEHOLDER>” for both outputs, such that, sorting will not differ due to name of the elements.
After string replacement and sorting, I put Title columns side by side, and checked if they differ. Here is the result of our “highly technical and complex”(!) analysis:
Result: Analysis outputs are same. The reason is, of course, based on having the same attributes and same analysis rules behind the scene. So, we can conclude that “physical appearance is not everything”.
We can keep analyzing the MS TMT logic by changing a single attribute and see how it affects the analysis output. Let’s begin…
2. The Same Element with Different Attributes
This time we will use OS Process element, but play with one of its attributes, namely Code Type. Code Type has 3 options “Not Selected | Managed | Unmanaged”. We will set each option while keeping all other attributes same and then compare how analysis output changes according to our changes.
Here is our very simple diagram:
Just like the first analysis above, I collected analysis outputs as CSV files and copied Title column to compare what has changed. Let’s come to the end result:
Results:
Unmanaged option gives us an additional threat “Web Server Process Memory Tampered”. Here is the description:
Tampering for “Response” interaction: If Web Server is given access to memory, such as shared memory or pointers, or is given the ability to control what OS Process executes (for example, passing back a function pointer.), then Web Server can tamper with OS Process. Consider if the function could work with less access to memory, such as passing data rather than pointers. Copy in data provided, and then validate it.
It’s important to note that “Not Selected” and “Managed” give same results. So, we should NOT assume always that threat modeling tool produces this additional tampering thread when we don’t specify the attribute explicitly. Normally I would expect that this additional threat was also listed when the attribute was “Not Selected” even if it would be “false positive”.
The reason behind this behavior comes from the template rules. Actually, the whole analysis output is based on the template rules. Here is a screenshot from our template showing why we have this additional threat:
As you see above, the threat is generated based on the Include rule. Template Editor is a hidden gem to dig and explore. We might look into basic of template editor in another blog.
But, for now, we can conclude and say: Keep your eyes on the element attributes and customize your element attributes as much as possible.
In this article, we tried to observe analysis changes in our threat list depending on the element types and attributes. The aim was to see the logic of the tool - in a very limited analysis. When we want to go to the next stage, it will bring us to the “Templates”. It’s a long topic to discuss in this article.
Threat Modeling Tool is really easy to use tool. The most time demanding part is developing expertise on threat modeling itself.
I hope this article was useful!
