The module - in brief

This module introduces you to the final steps in the risk management process, which combines insights obtained in previous steps and allows you to prioritise where to spend effort in mitigating threats.
 
The module is intended for a reader without prerequisite knowledge of risk assessment for data security, but who has read the previous modules in the risk management process.

Risk analysis, evaluation and treatment

After having performed asset analysis and threat analysis, these insights can be combined in a final risk analysis, which can then be used for prioritisation.

The purpose of risk analysis, evaluation and treatment

This module introduces the final steps in the risk management process, where the insights gained from the asset and threat analyses are combined to generate a risk score
 
These steps are the final part of the risk management process:

1. Risk analysis
   Based on the identified assets and threats, calculate the overall risk score considering both impact and likelihood.
2. Risk evaluation
   Decide if the identified risk should be treated or accepted.
3. Risk treatment
   Implement suitable risk mitigations for the risks needing treatment.

Practical information

The 3 tasks described in this module have different practical requirements:

The risk analysis itself is a fairly simple process and can be done by a single person or in some cases be completely automated. The activity does not need a workshop, but the output should be distributed to the relevant stakeholders.

Risk evaluation is essentially deciding which risks to treat and which to accept. As such, it is essential to involve people with the power to make such decisions, i.e. the product / risk owners. As mentioned before, this activity does not need a workshop, however if there are multiple stakeholders involved, a workshop can be beneficial to align the acceptable risk level.

Risk treatment involves investigating how a risk can be handled. As such, it requires both decision-making power and personnel with a technical understanding of the topic. The risk treatment will in most cases be delegated to a small (technical) team, who will come up with potential solutions. The risk owner will then have to approve the proposed treatment.

Step by step guide

1) Risk analysis

Before risk analysis can be performed, the previous two processes, i.e. Asset analysis and Threat analysis must be completed:

The asset analysis will have produced a document describing the important assets (i.e. data) and their security requirements, (i.e. how important it is to protect confidentiality, integrity and availability of each asset).

The threat analysis will have produced a list of threats against the system, an assessment of their likelihood of success, and which assets would be impacted (and how) should the threat manifest itself.

Risk analysis is the process of combining this information into a single risk score, which can then be used for prioritisation. This score is often calculated as a product of the likelihood and the impact, i.e. likelihood * impact = risk, however other operations like addition can also be used. The different choices of mathematical operator have an impact on the risk score, e.g.:

• If using multiplication, the range of the score will be larger, e.g. 1-16 compared to 2-8 when using addition (assuming a 4-point scale is used).
• If using addition, a very high likelihood or impact will result in a relatively higher risk, e.g. 5/8 compared to 4/16 when using multiplication (assuming an impact of 4 and likelihood of 1)

This means that using addition better reflectis the importance of essential threats, such as a risk with an impact rated as ‘Very high’, and a likelihood rated as ‘Very unlikely’. On the other hand, using multiplication will give a larger spread between low and high risks and is the most used approach.

This approach can be visualised using the risk matrix below:

"Risk Matrix" by CyPro under license CC BY-SA 4.0

Risk Matrix
Printable version of the tool in large format 

The simplest approach to do risk analysis is to simply iterate over the list of identified threats and for each threat compute the risk as the threat impact * likelihood. The threat impact can be found by looking at the threat violation type, the affected assets and the security requirement of the affected assets. For example, if a threat would violate the confidentiality of two assets with confidentiality security requirements of 2 and 4, respectively, the overall impact would be 4 (the highest of the two impacts). If the same threat had a likelihood of 2, the risk would be 8 = (2 * 4).
 
As the threat analysis may have identified many similar threats, it can make sense to group these into a single category, e.g. many threats may result in denial of service, so these could be grouped into a single “Denial of Service” risk. When doing this, the highest individual risk score should be used.
 
It is important to notice that it is not necessary to calculate the overall risk score as ‘neatly’ as shown in the example. If there are uncertainties in the previous asset analysis and threat analysis, e.g. the impact estimated to be 2-3, this can be propagated to the overall risk, which will become a risk range instead of a single value.

2) Risk evaluation

After the risks scores have been calculated, the next step is to discuss what needs to be improved. This intends to ensure that the threats will be properly addressed in a similar manner and an acceptable risk level is achieved.
 
The process is fairly simple, as it is just a matter of iterating over the identified risks and determining if the risk score is over or below the threshold of acceptable risk:

• If the risk score is above the threshold (the critical risks), a person responsible for treating that risk should be appointed.
• If the risk score is below the threshold, the risk is accepted.

During Context establishment, stakeholders were identified, and management levels were mapped to risk levels. This makes it easy to identify who should be notified of the results and who has the authority to accept a risk at a certain level.

3) Risk treatment

Once the critical risks have been identified, the next and final step is to discuss and decide on a suitable treatment. In general, there are four risk treatment strategies, presented and described in the figure below. Note, since risk mitigation is an ongoing process, it is very important that management sets a clear goal for achieving sufficient security and an acceptable risk level.

"Risk strategies" by CyPro under license CC BY-SA 4.0

The most common starting point is to attempt risk modification. During mitigation it is considered if there are security controls (or other changes) that can be implemented, which will reduce the risk to a level that is acceptable to the team and the organisation. Generally, preventive measures, e.g. stronger authentication or cryptography, reduce the likelihood of an incident, while detective measures, such as log monitoring, can reduce the consequences of an incident. 
 
Risk sharing can be an option, especially in relation to hosting, where companies often select a cloud provider or other sub-supplier to be responsible for operations. It is important to notice that the risk does not disappear but rather is changed to something the organisation is better at handling, e.g. the risk changes from a technical issue to a contractual issue. 
 
For the risks where the risk score is within the risk acceptance level, risk will commonly just be accepted. There are also instances where a high risk is accepted. In these cases, there might not be cost-beneficial mitigations, but the potential gains are worth the risk. When accepting a risk, the decision should be re-evaluated when the conditions change. In this case it is important to assign someone to be responsible to monitor the conditions and raise a flag once it changes. 
 
Avoiding risk consists of avoiding the risk entirely. This can be seen as an alternative to risk acceptance, where the potential gain of an un-mitigatable risk is not worth the risk. In this case, the root-cause of the risk, e.g. a problematic interface, functionality or activity, is completely removed/avoided. 
 
Once a suitable risk treating action has been determined, it is just a matter of implementation. Depending on the concrete treatment, this can be done in different ways, involving different people. Once completed, or if issues occur, the appropriate stakeholders should be notified.

Outcome

The output of the risk analysis and evaluation steps is a list of the identified threats, their likelihood, impact and combined risk, the appointed risk owner and the decision of whether or not the risk should be treated or accepted.
 
The risk treatment step considers how a risk can be treated and is mainly informational, without producingany concrete output. It does, however, offer strategies that the risk owners can use in their treatment of the risk.

Expert advice

Throughout the entire process, especially the first time, it is a good idea to be somewhat sceptical with regard to the results. If something appears incorrect or inconsistent, e.g. a risk seems much lower or higher than expected, the cause should be identified and the underlying assumptions re-validated.

It is common that the first choice of methodology (during context establishment) will result in risks appearing too critical or trivial compared to the risk-acceptance level. It may therefore be a good idea to reassess these values after finalising the assessment. Furthermore, it is important to remember that in most cases, the relative risk scores are more important than the absolute risk scores, i.e. focus should be on treating the highest risks, no matter what the concrete risk score is.

Next step

When the appropriate risk treatments have been decided, they have to be implemented, which can be done in different ways depending on the organisation. The module Development process describes how to manage the agile process. 

The contents described above have been developed in the project:

’CyPro – Cybersecure manufacturing in Denmark’ by Aarhus University, Alexandra Institut, DAMRC, UGLA Insights and FORCE Technology funded by The Danish Industry Foundation. Material from the project is published under Creative Commons.

CyPro