Threat Models Template: Tips & Tricks

Welcome to the fifth and last chapter of our trip to discover how to create your own Templates with Microsoft Threat Modeling Tool 2016.

The first article of the series, where I introduced how to create your own Template, can be found in Threat Modeling Templates: how to start your own. The second article, dedicated to the definition of your own Entities, can be found in Threat Modeling Templates: the Stencils. The third article, on the definition of Threats, is published in Threat Modeling Templates: the Threats. The fourth article, on the Threat Properties, can be found in Threat Models Template: the Properties.

The current article focuses on the Workflow related to the Templates, and gives some final tips on what you should expect and what to do.

Let’s start discussing the Workflow.

Since the very first article, it has been clear that Templates are characterized by two specific properties, which are used to regulate how Templates are applied: the Id and the Version.

Let’s say that we want to start a new template, Azure v1, by deriving it from the default template. To do that, we would copy and rename the template provided out of the box with Microsoft Threat Modeling Tool 2016, which is called default.tb7; then, we would change the value of those properties with an editor like Notepad. Please note that approach is technically feasible, but it is unsupported.

Now we can create new versions of the Template, by modifying and saving it as necessary. Typically, we would want to derive other templates from the default one, instead of starting from scratch, because it would be more efficient in most cases.

At this point, let’s imagine that we have already defined our template, and that we have correctly assigned to it a specific ID and version 1.0.0.0. Those details are embedded in the document itself, and are used by the Microsoft Threat Modeling Tool 2016 to control and limit how the updates are applied. In fact, the Threat Modeling Tool implements a process to update a template to a newer version, but does not allow to migrate a document from a template to another (that is, the ID must be the same), and does not allow to return to a previous version (that is, the Version must be greater than the current one).

The Microsoft Threat Modeling Tool enforces this behavior, first of all by maintaining the same ID every time you save the Template, and secondarily because it checks those values every time you update the Template to a document, and refuses it if the Template ID does not match with the one stored in the document, or if the Version is lower or equal to the current one.

You can perform the update implicitly, by replacing the old Template and by opening the document: the Microsoft Threat Modeling tool will show a message asking to confirm the update, and highlighting potential problems, like the removal of entities that have been deleted from the Template.

The other way is an explicit update, by using the related voice in the File menu of the Tool. The final outcome is similar: a confirmation message for the update will be shown, highlighting the potential problems.

Talking about the problems, the question is what should you expect depending on the various changes you can do to the template. The answer depends on what you are changing.

If you are modifying a Stencil, Base or Derived, you have to consider that the changes could impact the Threat Types that are associated to it; those Threat Types must be modified manually as required. In the model, the updates are propagated to the items that have been generated from that Stencil. This means that all customizations that have been done on the items are overridden by the new configuration; the only exception is the Title, which remains unchanged.

If you are deleting a Base Stencil, upon confirmation all items of this type and of the derived types are deleted.

If you are deleting a Derived Stencil, all items of this type are switched to the base type.

Changes to Threat Categories are propagated to the model.

On the other end, deleting a Threat Category means that associated Threat Types in the Template are removed upon confirmation; in the Model, if required all threats belonging to this category are removed.

Changing a Threat Type does apply the changes to the Description only if the Threat has not been modified. Therefore, it is necessary to delete the Threat to ensure that the new definition is applied.

If a Threat Type is deleted, the unmodified Threats are removed; on the other end, threats that have been customized are left untouched.

In the case of Threat Properties, if the property is a List and one of its values is changed or removed, it is not recognized anymore and the Threats with this value will have that property unassigned, that is empty.

Removing a Threat Property means that the Property is removed from all Threats.

We have reached the end of the series, and I hope that it has given you a good introduction to the Templates of the Microsoft Threat Modeling 2016. The potential is huge: I have seen, for example, a brilliant example of how Templates can be used for very different goals. One of the most illuminating, has been based on a template which generates questions on the modeled system, instead of Threats.