Execution Mode visibility.

Standard and Threat Event Mitigations have associated a Strength.

Strength can typically be set to one of the following values:

  • Maximum, which indicates mitigations that could be considered strong enough to make the residual risk for the Threat Type negligible, even when it is not combined with other mitigations.
    Bottom line: Maximum Strength should be used sparingly, for those situations that are clearly addressed by the Mitigation, like Backup for a Threat like “Data can be destroyed irrevocably due to lack of a tried backup strategy”.
  • Strong should be used for Mitigations that are almost but not quite enough for making the residual risk for the Threat Type negligible.
  • Average, which is to be used for Mitigations that have a significant impact on the Threat, but not so much as the Strong ones.
  • Low should be used for Mitigation which have some effect, even if minor.
  • Negligible is thought for being used for Mitigations that have an extremely limited effect on the associated Threat Type.
    Bottom line: it is typically used for Mitigations that are thought to have an effect, to indicate that in reality that effect is minimal. Avoiding to associate the Mitigation would not do, because it would not be possible to discriminate between this situation and one where you would not have included the Mitigation because you haven’t thought about it.

Threats Manager Studio (TMS) provides a tool to edit the Severities, called Strength List. This tool is available from the View ribbon.

The View ribbon.

If you open the Strength List, you can see the list of all Strength defined in the Threat Model.

The Strength List is rarely edited, but in case of problems, there is a button in the ribbon to restore the original Strengths.

The Strength List and its ribbon.

Why the ID is important

The ID is used by TMS to calculate the risk of Threat Types and Events in a qualitative way. Some functions like the Roadmap use it to calculate the risk of the Threat Model at a specific moment.

For example, it is possible to calculate the Severity of the Threat Model at a later stage as the sum of the IDs assigned to the Severities for each Threat Event, minus the effect of the Strengths of the implemented Mitigations. If we have three Threat Events, “A” with Severity Medium, “B” with Severity Info and “C” with Severity “Low”, we may calculate the total Risk for the Threat Model as the sum of the IDs of the Severity for each Threat Event, which would be 76, in this case. Therefore the current Severity would be 76. If we say that a Weak strength Mitigation has been implemented for Threat Event “A”, then the new Severity for that Threat Event as a result of the application of that Mitigation will be

[Current Severity of “A”] * (1 – [Strength of the Mitigation] / 100) = 50 * (1 – 25/100) = 37.5

Therefore, the total Risk for the Threat Model after the implementation of said Mitigations, will be 63.5, because the other two Threat Events have not been affected.

This represents a Qualitative approach even if it expresses the Severity as a number, because the original evaluations are qualitative. As a result, it does not allow to compare total Severities of different Threat Models, but it can be used to visualize the impact of the Mitigations defined within the Roadmap.

One of the most important characteristics of TMS is to be extensible. This allows to adopt Extension libraries to add support for some Quantitative approach like FAIR.