Threat Model

Threat Modeling is a process to understand potential Threat Events to a system, determine risks from those threats, and establish appropriate Mitigations.

With Threat Events, we indicate potential attack scenarios to the system. An example of a Threat Event is “The request sent from the User to the Front-End Web Application may be intercepted by a man in the middle and its content may be disclosed”. As such, Threat Events apply to parts of the Threat Model: in the example, it would be the flow between the User and the Front-End Web Application.

Who performs those attack scenarios is called Threat Actor.

Threat Events may cause a potential loss, which we refer to as the Risk. The Risk is preferably expressed in monetary terms.

Mitigations are the actions that may decrease the Risk associated to a Threat Event.

The goal of a Threat Model is to understand the risk represented by a system and identify potential mitigations. The intent is to enable the identification of a number of mitigations which, if implemented, would reduce the overall residual risk to an acceptable level.

Tips & Tricks
The intent is not to get zero risk, but to make the risk acceptable.
Do not try to force your Business Stakeholders to implement all your ideas, but help them to identify what needs to be done!

The Threat Modeling process is based on the following steps:

• Analysis of the solution, by reviewing the available documentation about its design and by conducting interviews.
• Drawing of a diagram representing the acquired knowledge. Traditionally, Microsoft’s approach is to use Data Flow Diagram (DFDs). Threats Manager Studio (TMS) uses a diagramming language derived from DFDs.
• Identification of the potential attacks to the solution, using the previous diagram as a reference.
• Identification of the possible mitigations.

Threats Manager Studio (TMS) allows defining Roadmaps, which are prioritized lists of the recommended Mitigations. Even if the user of the tool may provide recommendations through the Roadmap tool, the ultimate determination of the best approach to address the identified risk is ultimately the responsibility of the System Owners.

The approach to address the various identified risks can be defined choosing among a number of options, including those listed below or a combination of them: for example, applying some mitigations and then accept the residual risk.

• Applying one or more Mitigations.
  It is recommended to favor standard, well-known mitigations over invented ones.
• Redesign
  The risk can be totally averted if the feature is removed.
• Transferring the Risk
  It can be achieved by informing the users ad let them decide, or by taking an insurance.
• Accepting the Risk
  Can be decided only by the owner of the System. It is typically a result of an Exception Management process.

The risk represented by the solution after having applied the selected approach is called Residual Risk.

Threat Model Properties

TMS provides a page where you are meant to specify the details related to the Threat Model: Threat Model Properties.

The Threat Model Properties are accessible from the Home ribbon.

You can specify in that page the following information:

• The Name of the Threat Model, which in in picture below is “Default Threat Model”.

Tips & Tricks
It may not be obvious, but the Threat Model Properties page is based on an Item Editor. The Item Editor shows the name of the object in the header, right below the type of the object, and next to its icon. The name is editable, even if there is no border to highlight that.

• The Description of the Threat Model.
• The Owner of the Threat Model.
• A list of the additional Contributors.
• The Assumptions for the Threat Model.

Tips & Tricks
Assumptions are used to indicate conditions or information that you are using as part of the Threat Model. They are particularly important, because the Threat Model relies on them to be true. In other words, if they are false, then the Threat Model would be in whole or in part be false. An example of such Assumptions is “Services provided by the Cloud Provider are built securely”. This assumption means that you are relying on those services to be secure. You know that they are not absolutely secure, because any solution has a risk of compromise, but still you cannot extend your analysis to those third-party components, for many reasons. You use assumptions to track this situation.
It is important to note that the assumption above does not mean that you can forget those Cloud Services, because there are still misconfiguration issues you need to take care of, and you may know that there are specific risks you may want to address still.

• Dependencies, like specific technological components you rely on.
• Threat Events applying to the whole solution.