Author: Jacob Teale, Customer Success Technologist @ IriusRisk
At IriusRisk, we leverage draw.io’s capabilities for the diagramming of threat models. This guide surrounds the ease of creating Nested Components using IriusRisk and draw.io.
What are Nested Components?
A Nested Component, as the name suggests, is the state of a component existing inside that of a parent component. It is a powerful and quick way to place component(s) inside one another, both visually and semantically. Utilising draw.io’s drag and drop functionality, Nested Components are straightforward to create, enabling rapid creation of sophisticated threat models.
Note: We also have a useful video on Nested Components here.
At IriusRisk, we are always introducing new and powerful features, often informed by the feedback and requirements of our customer base. If you are a customer and would like to suggest enhancements to this feature/product, please raise a support ticket, or reach out to your account team.
How to Create Nested Components?
In this example, we want to create a Google Cloud Platform Environment containing two Google Cloud Virtual Machines.
Using the draw.io canvas (underArchitecture view of a given product), we will follow the below steps:
As with normal placement of a standalone component, place a component inside a Trust Zone.
Resize the component so that it is large enough to be the parent of another component(s); see the below animation for an example:
You can now expand and collapse the Nested Components, as shown below:
If you navigate to the Threats tab, notice how Nested Components are represented as sub-components of the parent component.
A More Complicated Example of Nested Components
In the above example, we learnt how to create a simple Nested Component using Google Cloud Platform as an example. We can use this same approach to create intricate and complex threat models with no limit of depth. The below diagram illustrates how we can model AWS EC2 Instances inside a VPC, and nest Docker Containers inside the EC2 instance itself, in addition to being as specific to defining what type of services exist within the container itself, as shown below:
Any one of these parent components can be minimised for easy and clean visibility of threat models, for example, some teams might not be too concerned what exists within the EC2 instances themselves.
Under the Threats tab, you will notice how depth of groups can be expanded and collapsed in succession:
Nesting Availability Zones
Although not a common approach to Threat Modelling with IriusRisk, some teams may choose to nest Trust Zones.
Note that there are important considerations to nesting Trust Zones, see step 3.
To nest a Trust Zone, we use the exact same approach as nesting components. This section describes an example scenario and how the threat model is subsequently influenced.
Imagine the following example: we choose to place our VPC in the Public Cloud Trust Zone, which has a trust score of 60, however we have an Availability Zone (AZ 2) which has a known threat surface due to an exposed ACL. Another basis could be we care more about the assets stored in AZ 2, and so we treat it with high sensitivity, hence the trust score of 1.
A parent Trust Zone does not affect any of the Trust Zones within it. The trust score is independent of itself.
So, with this in mind, we create the appropriate Trust Zone Definitions with the appropriate scores in the Configuration menu:
With the example scenario, we draw our diagram as required (EC2 -Public Cloud) is for comparison purposes only):
Below you will see, with the above diagram in mind, how the Nested Components are affected by nesting Availability Zones, specifically how the presence of a parent component is lost in the example of EC2 - AZ 1 and EC2 - AZ 2 once they are placed in AZ 1 and AZ 2 Trust Zones respectively (this is a caveat of nested Trust Zones, and should be taken into consideration):
See below how the EC2 threat score category changes based on where they were placed in accordance with the Trust Zones created earlier: