GRC Tuesdays: Integrating Cybersecurity and Enterprise Risk Management

[T_Frenehard]

No sooner had I just released a short blog GRC Tuesdays: Why Cybersecurity Should be on Your Risk Map that I received an email from a colleague driving my attention to a publication by the National Institute of Standards and Technology (NIST): Integrating Cybersecurity and Enterprise Risk Management (ERM) that goes much further than my blog and – more importantly – does so much more convincingly.

This document is now in its second revision, the first draft having been released in March 2020 and this second version having been released in July 2020 for comments.

Let’s assume that my previous blog was the appetizer and that we can now move on to the main meal. I’d like to share some of the content of this publication and provide suggestions of my own.

The intent highlighted in this report is to help “high-level executives and corporate officers understand the challenges that cybersecurity professionals face when providing them with the information they are accustomed to getting for other types of risk” – hence it’s not about making cyber-experts out of company executives, but give them sufficient information that they can steer the ship.

To do so, the report explains how cybersecurity risks can be rolled-up to the wider Enterprise Risk Management (ERM) program and, as such, be included in the overall decision-making process. And to do so, NIST suggests using a risk communication channel that I am pretty sure you already know if you are in the GRC area: the risk register.

NIST defines the risk register as “A critical risk document used to track and communicate risk information” that “provides a formal communication vehicle for sharing and collaborating cybersecurity risk activities as an input to ERM decision makers”. In a nutshell, an extract from the more complete risk universe.

What does a cybersecurity risk management cycle look like?

 

Cybersecurity risks can lead to a potential exposure, like any other risk the company faces. But also, like any other risk typology, they have their specifics that need to be documented if the risk is to be understood.

Interestingly, NIST has mapped different risk management frameworks – including NIST’s and ISO31000, and the good news (but that’s not really a surprise, is it?) is that the sequencing and the steps correspond:

Source: National Institute of Standards and Technology Interagency or Internal Report 8286

As a result, like for any other risks in the ERM framework, the process below can be followed – but needs to include specifics for Cybersecurity:

Plan	“Context is the environment in which the enterprise operates”, and, in Cybersecurity probably even more so than for other risks, the detailed context is crucial to understand the root causes. In this particular risk typology, the context relates to the asset(s) associated to a potential threat. The Cybersecurity Framework describes assets as “the data, personnel, devices, systems, and facilities”. In case you are not in a cybersecurity team and wondering where you could find a list of these assets, they are most certainly listed in the Disaster Recovery Plan.
Identify	Here, as for any risk category, the intent is to document the scenario that could prevent the company from achieving its objectives. At this stage, we’re referring to the objectives defined for the cybersecurity practice. Once rolled-up to the ERM picture and an aggregated exposure be provided, then the corporate objectives will get in the picture as these are the ones the executives follow closely. Once the scenario has been described, it can be categorized (what type of risk) and most importantly, the ownership of the risk can be established. A risk without owner is a potential crisis in the making: it won’t be properly reported and won’t be monitored so will go unnoticed. As a result, this goes well beyond accountability.
Analyze	As I have already discussed in many of these GRC Tuesdays blogs, different risk practices will have different assessment methods. But, at the end of the day, they all sum up to: how often could it happen (likelihood), what would be the consequences in case it happens (impact) and then, taking both these criteria into account and maybe some additional ones (velocity, etc.) what would be the exposure for the organization. This is often a qualitative ranking so as to enable comparability.
Respond	In my opinion, a risk response should always be documented with the information about the cost and benefits expected. Overcovering a risk (i.e.: having a mitigation strategy that costs more than the inherent cost of the risk occurring) is unfortunately not uncommon. As a result, balancing the cost benefit ratio is one of the key tasks of the risk owner. This explains why, in some cases, accepting the risk is really the only option if the company needs to keep the activity/asset in place for strategic reasons but that no response can be applied – or whose cost would simply be prohibitive.
Monitor and Report	Risk management is not a linear process. It’s a continuous improvement cycle. Keeping an eye on the risks, its progression including related incidents and near-losses will make sure that this is a successful living process.

 Note: the above relates to the negative aspects of a risk. But, just as ISO31000, the NIST report acknowledges that the risk management process is about providing executive leaders with an understanding of sources of uncertainty, therefore both the positive outcomes (opportunities) and the negative ones (threats). As a result, the very same process should be applied to the opportunities to enhance their chances of success.

What should be included in a cybersecurity risk register?

 

Now cybersecurity have been documented in their own universe following the same risk cycle as other risks, it’s time to include them in the ERM map.

Once again, NIST has provided an illustration of a cybersecurity risk register – i.e. what they have described as the “communication vehicle for sharing and collaborating on cybersecurity risk activities”:

Source: National Institute of Standards and Technology Interagency or Internal Report 8286

What needs to be included is a summary of the information recorded during the entire risk management process described above.

In short:

• The description of the scenario, risk category and owner all come from the Identify phase


• Information about the latest assessment comes from the Analyse phase


• Information about the mitigation strategy comes from the Respond phase


• Status (or progress) that is an indicator of where the risk is in its lifecycle comes from the Monitor and Report phase

Depending on your approach, the priority is either documented during an Analyze or more likely during a Monitor and Report phase as it is documented in the context of other risks.

As for when other risk typologies are included in the ERM framework, only the ones material enough are reported. I believe the very same should apply here – and hence why the prioritization is not, in my opinion, the only decision criteria for this purpose.

Where I’d like to add a small precision relates to the risk identifier (ID column). NIST suggest that this should be a “sequential numeric identifier for referring to a risk in the risk register (e.g., 1, 2, 3)”.

That’s good, but if it doesn’t relate back to the cybersecurity risk universe, it will be a source of problem.

Let’s take the following scenario: cybersecurity risks have been reported in the ERM map and one executive has concerns about one of these events and would like to get more information.

If the risk identifier doesn’t relate back to the cybersecurity risk universe, then it won’t be easy to get the full details on the risks, including the related assets, historical analysis, etc.

Someone will need to do a manual search in the cybersecurity risk universe, and this might actually find few records with the same names… So they would then need to investigate further. Not a value-added task if you ask me.

If, on the other hand, the identifier is unique throughout the entire cycle it will be much more straightforward. Even better, if the cybersecurity and the ERM universe are not manually updated by Excel uploads but automatically integrated, then executives would be able to drill-down directly into the event questioned and display the most up to date data. Talk about real time decision making!

What about you, are your cybersecurity risks reported to your ERM map? I look forward to reading your thoughts and comments either to this blog or on Twitter @TFrenehard