Why to we need to create custom components?
Typically because a component is not included as part of the default IriusRisk security content. There may be several reasons why this is so, possibly you are exploring a new cloud service, an on-premise service, a 3rd party commercial off the shelf or an Open Source project service, you may need to reference a bespoke component that you manage and/or maintain within your own technology stack.
The common thread here is that these components are commonly used in one or more service or system that you wish to threat model, so where do you start?
The workflow below provides some guidance on the decisions that you will typically need to make
Option 1) Reuse an Existing Component
Take an existing component, that closely resembles the functionality of the component that you need. Review the risk patterns (threats/weaknesses/countermeasures), to see if they are aligned with the service that you wish to work with.
If they are, then you can use the existing component within the diagram, for example we use a WAF but not the AWS WAF, but from a Threat Model perspective, its good enough
right click on the component,
Edit the details, and provide your own unique name for the component.
Option 2) Reuse an existing component, but
the risk patterns aren't quite right, they need amending.
Adding or removing risk patterns to a component via the component editor is a straight forward operation, if they already exist within the library content, but this will affect those projects referencing the original component, which means that we really should create a New Component.
As a short term solution, especially if this component is not required across the product portfolio, we could follow option (1), and then manually update the threat model within our project, add/delete threats via the threat view UI/UX.
But if this is require across more projects, then perhaps we do need to go to option (3).
Option 3) Create a new Component
Take a look at this knowledge base article on the mechanics of creating a new component. In order to create a new component you need to have information pertaining to the component that you want to create,
-
name (well if you dont know what to call it, then we are really struggling),
-
category, you can use an existing category which may be appropriate for the component you are creating, or you can assign your own category. There are no limited as to the number of categories you can create, but having custom categories may help your users find components which are specific to your industry, project, team etc.
-
unique Reference ID; initially this is derived from the component name, but you can change it as needed, such as a reference to a CMBD.
-
Visible; a tick box that makes the component visible to the users. One of the benefits of being able to make a component visible or not, is that you can decide at which point the component can be consumed by users. This can be done at anytime. So, even if you do not include a source of threats, then the component can still be used (if visible).
-
Source of threats; this allows you to map one or more risk pattern to the component, so by default when including the component as part of a diagram, then those risk patterns are included
One of the benefits of being able to make a component visible or not, is that you can decide at which point the component can be consumed by users. This can be done at anytime, so you decide when it is ready to go....
If you have already threat modelled the component, then this is great. The output of your threat model should include the possible threats but also the countermeasures (security controls) that would be appropriate to mitigate that threat. These can be easily translated into a custom library within IriusRisk and documented as part of a risk pattern and appropriate Use Cases. This can then be associated with your component, either by default (they appear when you drop the component into the diagram) or could be injected automatically by a Rule, determined by particular conditions within a diagram.
If not, you need to threat model the component; in which case this article provides guidance on how IriusRisk can help.
Note - should you change the source of threats, either add or remove risk patterns, then these changes will be reflected in projects which reference the component, when the threat model is updated.
Option 4) Project Component
There are other methods within iriusrisk to create a reference-able component. So, if the system or service is complex, i.e. it is made up of multiple parts (components). Then you may want to consider a project component, this allows you to create a threat model, and then reference it in other threat models. Take a look at this article to find out more about creating and using your own project component.
Comments
0 comments
Article is closed for comments.