Maximising the utility of the cyber risk register
This article will discuss the cyber risk register. For some organisations, this is looked at only because the Risk/Audit Committee requires it and, in most cases, it only gets attention a few days before the mandated deadline for submission and is promptly forgotten soon after.
For some, the whole exercise is not worth it and distracts from more ‘meaningful work’ and never given the respect it deserves.
I hope to show that, when the cyber risk register is the output of a proper cyber risk management process it can be beneficial for organisations, in achieving the following objectives which are key for the cybersecurity function:
- Bridging the divide between the cybersecurity teams and executive-level governance bodies.
- Driving strategic and operational decision making for the cybersecurity team and the broader technology business unit.
The aftermath of most adverse cybersecurity incidents usually involves a back and forth between technology teams and executive-level governance bodies about ‘what went wrong’, given ‘all the money we are already spending on security’?
Technology teams will usually argue that they are not well-resourced and that senior executives do not understand technology and are therefore not well placed to make the right budgetary decisions concerning cybersecurity. While this may be true, what is also true is that technology teams do not communicate cyber risk in an understandable language to the senior executives.
There is usually a lot of technical jargon needlessly thrown into the discussion instead of simple scenarios that describe what the impact (Rand amount, considering the applicable business loss forms for a scenario) could be on the business should a specific scenario be realised. Understanding what the likelihood (expected number of occurrences for a scenario within a unit of time – preferably annualised) of that scenario taking place is. A cyber risk quantification framework such as OpenFAIR, can assist with deriving fairly (pun alert) good ‘3-point’ estimates (Minimum, Most Likely and Maximum) for each risk scenario, allowing for more objective discussions.
In general, the cyber risk management process lifecycle will have the following activities:
- Identify key organisational objectives.
- Identify technology-related threat scenarios that could hinder the achievement of these objectives and what their impact (considered together with the scenario likelihood; this becomes an inherent risk level for the scenario) could be.
- Create a mapping of the core and supporting technology assets connected to the business objective.
- Evaluate controls for the technology assets in scope.
- Derive the residual risk level for each applicable scenario.
- Make a risk treatment decision for each scenario (further mitigation, transfer, avoidance, acceptance).
- Track the implementation of the approved risk treatment action.
Now that we have briefly covered some elements on how the cyber risk management process that is used to derive the cyber risk register, should be, let us look at how this information can be used effectively.
Bridging the divide
It is clear, that if sufficient effort has gone into generating the cyber risk register, it will not be difficult to gain common understanding with the executive-level governance bodies. The following examples illustrate how this information can be used to bridge the divide between the cybersecurity team and the executive-level governance bodies:
- Explaining why there is a line-item in the cybersecurity budget for a relatively expensive file integrity monitoring solution for that public-facing eCommerce server through which 40% of all business revenue is derived.
- Why there is a request for a storage upgrade for the event log collector so that workstation events can also be centrally aggregated for improved threat detection.
- Why the technology team is reporting back to the executive-level governance body, on the aggregate vulnerability exposure window (total time taken to remediate disclosed vulnerabilities) for a certain tier of technology assets. Furthermore how this information can be used to infer if any risk thresholds have been exceeded, thereby triggering required corrective actions.
From the few examples above, I hope that the benefits of having a proper cyber risk register and its use as a tool for communicating the point-in-time cyber risk posture of the organisation are apparent.
Driving Strategic/Operational Decision Making
Strategic and operational decision-making can also be improved for technology teams by leveraging the cyber risk register in the following ways:
- The cyber risk register is a key source for quickly identifying the technology assets with a higher risk exposure which my need more comprehensive (and potentially more expensive) controls compared to others, instead of relying on the ‘clout’ of the asset owner.
- A process can be established to ensure vulnerability assessment or penetration test findings that are not immediately remediated are added to the cyber risk register, so that they get the required visibility and do not get lost in the ‘noise’. This could result in a reduction of repeat findings.
- Some changes in the business, for example acquisitions or new partnerships could result in a material increase of PII (Personally Identifiable Information) stored and processed by a technology asset already referenced in the cyber risk register. This could trigger a review of the inherent/residual risk ratings for the applicable scenario(s) and possibly an out-of-band review of the corresponding controls.
- Most cybersecurity incident management processes require the creation and maintenance of quick-reference response playbooks for the organisation's key threats. The cyber risk register provides an objective source of this information, instead of relying on the current cyber breach headlines from the many news sources available.
- With a functional cyber risk register, regular reporting of KRIs (Key Risk Indicators), becomes an issue of considering the KCIs (Key Control Indicators) that apply to the assets which are already referenced in the scenarios contained in the cyber risk register. Major shifts would be easy to pick, and corrective actions can be quickly defined and implemented.
No posts found