Threat Modeling with TMS: Quality and Communication

Threats Manager Studio (TMS) is a Threat Modeling tool that provides superior efficiency and effectiveness. But how can you practically use it to create your own Threat Models? This article is the fourth in a series to answer this question, by showing a complete process since the diagramming phase. The previous article is available from here.

With the previous three articles, we prepared a first diagram of our sample system and we have shown how to use Templates to automatically create Threats and assign Mitigations. We have seen the activities you are supposed to do, to update the severity of the Threat Events and the status of the Mitigations. We have also discussed how you should use the Threat Event List and the Mitigation List to ensure that all the various evaluations of Severity, Strength and Status are aligned among the various Threat Events and Mitigations. Finally, we have used our experience as Threat Modelers and the STRIDE approach, to identify additional Threats and Mitigations.

We are now in the last steps of the Threat Modeling process with TMS, which may can be summarized with the validation of the threat model, and then with the preparation of the additional material required to communicate to the Business Stakeholders and to the Product Owners and Managers the results of the Threat Model.

Validation of the Threat Model

The first activity is related to the validation of the Threat Model. The simplest way to do that, is to install the Quality Extension library. After you install it, you will be able to see a new tab in the Ribbon: Review.

If you click the Quality Dashboard button, it will open a new page showing an evaluation of the quality of the Threat Model.

It is possible to see that the Quality is considered Sufficient, but we can do better. For instance, you can click the Azure Key Vault item you can see in the second line. This shows in the blank area in the right the details of that object. If you move the pointer on the related header, you can see that the problem is that Azure Key Vault is a partially connected Data Store. In other words, secrets are consumed by nobody put secrets in. This is a clear indication of the need to complete the model, for example with a secrets provisioning process, which may be part of the CI/CD. You could do so, by adding a new diagram to the Threat Model, or you may decide that this is not in scope for your analysis. If your choice is to go with the latter, you can open the context menu on Azure Key Vault, by clicking the right mouse button on it, then select Set False Positive. You will need to specify a reason, but then the warning will disappear and the evaluation will be improved to Good. At any moment, you will be able to open the list of False Positives, to check what was identified, when, by whom and why.

Continue looking at the other quality findings, to get an even better result.

Communication

The second task is a little more complicated. In fact, you need to prepare a representation of the Threat Model that is useful for Business Stakeholders, Product Owners and Product Managers. What they need is to grasp three different aspects:

• What is the risk represented by the current situation?
• What could be done to improve it?
• How would the risk change as a result of the selected actions?

The Roadmap

The Roadmap is the main tool to get those questions answered. To use it, you have first to open it from the Analysis ribbon, then you have to configure a Risk Estimator with the definition of acceptable risk. This is typically done by defining a Bug Bar, which means to specify the maximum number of Critical, High Severity, Medium Severity, Low Severity and Info level Threat Events that are considered acceptable. Typical values are 0 for Critical and High Severity Threat Events, 5 for Medium Severity and 10 for the rest. Of course, it really depends on the project and on the Risk Appetite of the Organization. Organizations requiring to have less residual risk must be prepared to shell out more money to secure their solutions.

After having selected the Bug Bar, you have to drag & drop the various mitigations to the respective buckets: Short Term, Mid Term, Long Term and No Action Required. The first three define the phases of the Roadmap. More specifically, the first phase lists activities that are quick wins or that require an immediate implementation, because they are very urgent. The second phase lists activities that can be done right after the first group. Finally the third phase lists activities that are supposed to be done even at a later stage. The last bucket is reserved for activities that are not necessary, because they are already covered by the solution or because they are considered as an alternative to others, and therefore they are not required in this case.

The Roadmap page guides you in this selection, by providing details related to the selected Mitigation, in the lower left quadrant of the page. It also provides you with details related to where the mitigation is applied, in the lower central quadrant. And finally, thanks to the configuration of the Risk Estimator, it provides an evaluation of the relative effectiveness, by color-coding the Mitigation:

• Darker green background with white text identifies a Mitigation which, if implemented, would have an higher effectiveness.
• Lighter green background with black text identifies a Mitigation which, if implemented, would have an average effectiveness.
• White background with black text identifies a Mitigations which is already implemented or that, if implemented, would have a lower effectiveness.

The lower right quadrant shows an histogram of the projected residual risk at each phase. The goal would be to make at least the rightmost of those bars green, by moving enough Mitigations to make the risk acceptable. Further details are available in the Learning section.

The Overview Dashboard

After the preparation of the Roadmap is complete, it is possible to open the Overview Dashboard. This Dashboard is the main tool to show Business Stakeholders and the like the risk represented by the solution and how it changes as a result of the identified Roadmap.

The upper part of this page is what typically provides the most information for Business Stakeholders:

• The upper left quadrant shows the current risk, by enumerating the Threat Types by Severity. For example, if a Threat Type is assigned a standard Severity of High and has in the Threat Model two associated Threat Events, one of Severity Medium and one Low, then the resulting Severity shown in the chart is Medium, that is the maximum value assigned to the associated Threat Events.
• The upper middle quadrant shows the same histogram shown in the Roadmap. This highlights the effect of the Mitigations identified in the various phases and highlights when the residual risk will eventually be acceptable.
• The upper rightmost quadrant shows the projected risk, by enumerating the Threat Types by Severity estimated after the various phases of the Roadmap. In fact, using the buttons at the sides of the quadrant, it is possible to move from a view specialized for the Short Term Mitigations, to the one for Mid Term and then Long Term.

Conclusions

The Overview Dashboard is very useful, because it allows to clarify that it is not possible to achieve the mythical “zero risk” situation: in fact, even implementing all Mitigations you will still have some Residual Risks. It is not rare to get a situation where the Residual Risk after the Long Term activity would be not acceptable: in fact, it entirely depends on the definition of Acceptability, and thus of the Bug Bar.

Moreover, the Business Stakeholder really understands that there is a cost to fixing those issues. Most often than not, this understanding starts a very necessary discussion about the alternative Mitigations, and that leads to the definition of a plan that makes sense for the Organization.

In a nutshell, such a Threat Modeling process brings a lot of good to the receiving Organization:

• First of all, Threat Modeling allows to get a good awareness of the risks of the solution in scope. This helps you to get better decisions.
• This awareness allows the Organization to invest its budget for security in the right way, maximizing its impact. Without this awareness, the Organization would spend the budget blindly, simply because someone else did that. But the approach or repeating someone else’s choices may represent a mistake, because even admitting that the original choice was really good in the original scenario, it is not necessarily true that it would be ok for any other scenario. As a result, a blind decision made on such a weak basis may even put your Organization in a worse position.
• Secondarily, but not for importance, Threat Modeling allows to create a remediation plan to address the identified risks. Having a remediation plan in place is something that has proven more than once as being highly effective, to mitigate many potential indirect losses in case of security incidents. In fact, if you suffer a breach but you are able to demonstrate that you know what you are doing, so much that you already had a plan in place to address some of the root causes, you would suffer much lower fines than if you are caught completely unaware. Moreover, being prepared lowers the reaction time, which is another important way to reduce the potential losses due to fines.

With that, we have arrived at the end of our excursus on Threat Modeling with TMS, but the story does not finish here! In fact, there are a lot of other ways to get more value from the tool: for instance, you can create Word Reports or generate Excel files with the details of the Threat Model. And even more functionalities are in the workings. So, stay tuned.

And this is not the end of this series either. The next post is a sort of a bonus, because it will not be on TMS, but it will introduce the early stages of the Threat Modeling process, when TMS is not required. The focus will be on an Interview approach that has demonstrated to work well. You will get some tips and tricks on how to get an effective experience, and how to maximize the value of the time you will spend with the various Stakeholders for the project, to get the information required to design the Threat Model.