Security content creation phases

In this section we’ll highlight the main phases involved in the creation process for a new security library in IriusRisk.

Analysis of the technology/standard

We analyze the technology or the standard to better understand the security structure for the library. The point is having a set of threats, weaknesses and countermeasures that apply to the selected technology.

Components & Risk patterns definition

We think about the number of components needed to create a visual representation of the architecture that is going to be modeled. Some of the components required could be already present in IriusRisk but it may be necessary to create new components for this new library.

The final process for this phase will be to link each of these components with the right risk patterns (only to define what they are, not their content).

Review library design

We should review the library design to get feedback and capture additional requirements that will be useful in the following steps. 

Component questionnaire design

Each component will have a questionnaire that allows to better define the conditions to select the security content needed for each use case. To do that we’ll use the IriusRisk internal rules engine based on Drools. 

This phase may be optional depending on the characteristics of the component and the threats and countermeasures that apply. For example, in our Azure CDN component we do not ask any questions, there is just a static set of threats and countermeasures always associated with it.

In this phase we need to list the necessary answers to import the list of risk patterns.

NOTE: Answers to the questionnaire shouldn't filter one specific countermeasure. We want user answers about the product architecture in the questionnaire to import reusable risk patterns.

An example table for IoT questions could be seen below:

Selection and mapping for the countermeasures

IriusRisk has its own security countermeasures in its internal knowledge base so we need to assess which controls from the standard can be mapped with current security countermeasures and which of them require the creation of new countermeasures.

Create and populate risk patterns with threats, weakness and countermeasures

In this phase we expect to obtain the structure for each of the identified risk patterns. Risk patterns are reusable collections of use cases, threats, weaknesses and countermeasures that can be imported into a threat model as a unit. They are the basic building blocks of threat models in IriusRisk.

IriusRisk includes the latest CAPEC and CWE libraries as published by MITRE. We use them to help in the categorization of countermeasures inside risk patterns. This will allow you to choose the CAPEC library to search through and add the attack as a new threat.

The CWE library is loaded at application startup and the content can be accessed in a similar way to CAPEC. But instead of using the "Add Threat from Existing...", you would use the "Add Weakness" option from the Action menu of a specific threat in the threat table. 

These are the more relevant steps that must be followed to translate a Security Standard into IriusRisk patterns:

1. Group countermeasures together based on the weakness/vulnerability that they mitigate.
2. Create the weakness name and description that is appropriate.
3. Group weaknesses together under a threat
4. Create the threat name and description and impact ratings. 
5. Divide into risk patterns:
   1. Review the threats and countermeasures and ask “under which circumstance would this threat not be relevant?”. This can help figure out which pattern should be created for this threat. 
   2. Create the risk pattern name, ref and description. In the description, describe what the rationale for this pattern is, i.e. under which circumstances does this pattern apply. For example, in our GDPR library, there were a number of countermeasures that were related to displaying information to the user like a privacy policy, data retention policy and giving them the ability to delete all of their data. These countermeasures only apply if the end user can interact with the component. If the component has no UI that the end user can interact with, then none of them are relevant for that component. So we created a risk pattern specifically for “Component exposes UI to end user” and we do not import that risk pattern if the component is a database, or a backend web service with no UI.
6. Group threats together under a Use case. For example, “networking”, “authentication”, “general”.
7. Do not create too many threats - where possible and where it makes sense, group countermeasures together under a single threat. 

This way we can create an specific classification of threats, weakness and countermeasures inside each of the selected countermeasures for the library, as can be seen in the following figure:

Add references and test steps

We try to incorporate external and trusted references for threats, weakness, countermeasures and test steps to verify the right implementation of the countermeasure.

Create a new standard (if needed)

After the content is already implemented in the library we could be in the position of creating a new IriusRisk standard for the added countermeasures. To do that we should map the countermeasures with the right references inside the selected standards. 

QA & Language review

In this phase we test the library in an IriusRisk test instance to find implementation bugs and language typos.