Referencing Threat Models

Sometimes it's necessary to refer to existing threat models into other models.  You may need to nest your own models into others, or other teams may want to include your threat model in theirs.  This article is written from the perspective of you creating a threat model that will be consumed by another user (the consumer from now on).

IriusRisk offers two methods to achieve this:

• Method 1: Templates:  Where your entire model is copied into their model verbatim.
• Method 2: Custom Components: Where you create a custom component that represents your threat model, but only include the threats and countermeasures that are relevant to the consumer of your model.  This is essentially the public facade of your threat model written from the perspective of the consumer of your model.  This is usually the preferred method for most use-cases.

Both methods allow you to make changes centrally to your model, and push those changes out to all consumers who have imported your model.  Which method is better depends on the following factors:

1. How much detail should the consumer of your threat model see in their own model?
2. How should the threats in your model affect theirs?

Method 1: Templates

A template is a verbatim copy of your model, inserted into their model.  This means that the consumer will see all of the components, threats and countermeasures in your model and those threats will contribute to the average risk and countermeasure completion status of their model.  They will be able to make changes to their copy of this content because it exists in their model, but they won't automatically be able to change the original template, unless they have the correct permissions.

Use this when:

• Consumers of your model should see all its details, including components, data flows, threats and countermeasures.
• Threats and countermeasures in your model should significantly change the overall risk posture of the consumer's model.

Method 2: Custom Components

In this method you essentially have two threat models.  One model is your actual detailed threat model that represents the real threats to the service or application you're working on.  You would treat this as a normal threat model ("Product") in IriusRisk.

Then you would create a custom Component Definition with threats and countermeasures that represents what the outside world should see when they use your model.  This allows you to hide detail that isn't useful to other teams like your internal threats; and allows you to specify new threats and countermeasures that do affect consumers of your model.  I.e. what do they need to be aware of when using your service/application?

Consider a hypothetical example where you are building a new SAML IdP from scratch, called ACME SAML IdP, and need to threat model it.  You'd create the model as a new Product in IriusRisk and draw the diagram, data flows and manage the threats and countermeasures following the usual process:

Your new IdP has a number of components, services, data stores and data flows and from your perspective as the person modeling this system those components and their corresponding threats are what concern you and your team. 

However, once your IdP is live and ready to be used by the rest of the organisation (or the world!), they would only interact with a part of it and they would only have control over how they talk to your "External API" interface for example.  

From their perspective, your internal threat model is only partly relevant to them, because they have no control over how they respond to some of the threats.  Therefore, it is up to you the original threat model creator to design a new Component Definition that encapsulates the Threat Model that they should see when using your component.

The process to create this is:

1. Analyse your internal threat model and identify the threats that should be exposed to a consumer of your service.

2. Create Countermeasures appropriate for consumers of your service.  This would typically be actions that they can take to mitigate their risk.  Sometimes, you may have internal threats that can't be mitigated by the consumer - only by the team that implements the service itself.  In these cases, it would be an organisational decision as to whether you expose that threat to the consumer, or whether you keep it internal to your model.

3. Create a new library in IriusRisk to hold the above threats and countermeasures in a Risk Pattern

4. Create a new Component Definition that includes the risk pattern(s) just created and provide a good description of the component so that other teams and consumers know what this represents.

Which can be used in the diagram, and consumers would choose your component in their threat models:

There will also be a periodic updating process, where changes to your internal threat model, may have to affect the consumers of your model.  This process would be:

1. Identify in which risk patterns that you've already created for your Component need to be updated.  And make those changes.
2. Select the library you created and choose the "Apply to Products" option.  This will apply your changes to all threat models that have included your original risk patterns.