Keep it simple: how to avoid drowning in cyber risk information

Jack Freund is senior manager, cyber risk framework at TIAA.

A solid operational risk management programme must involve integration of activities between the first, second and third lines of defence. But too often the focus is on separating these duties instead – meeting the letter if not the spirit of the model, and harming efforts to monitor and manage operational risks. In cyber risk, in particular, such cursory first-line risk management practices are not sufficient.

Asset-level risk assessments

When conducting technology risk assessments, one’s first thought might be to enter everything that is discovered into an enterprise risk register. But there are typically a very large number of things in IT that need fixing and placing all of them in an enterprise issue register is rarely productive. Successful integration of a second-line operational risk management framework and a cyber risk framework depends on maintaining parity; the level of detail that is being unearthed at the technology layer should be at the same level of decomposition as at the other parts of your business. This kind of mismatched reporting makes it difficult to make good comparisons of key risk indicators and key performance indicators and would create lopsided issue finding and reporting.

In order to maintain parity with the rest of the organisation, a solid risk taxonomy is essential.

But because that detailed data is also valuable, it is critical to consider maintaining separate registers and issues lists for IT and the rest of the business. These registers will be integrated using the taxonomy strategy outlined below.

The first question to address is: what form should the entries in the IT risk register take? Far too often, important risk terminology gets confused when discussing technology risk. Basic concepts such as risk, threat and vulnerability are frequently used interchangeably (especially within IT departments). The IT risk register should focus on statements of the loss or damage the organisation would incur under a given scenario. A risk statement that begins with “Lack of…” or “Missing…” is really describing a control that should be in place and does not identify the risk that will befall the organisation. For technology risk, these risk statements typically relate to losses associated with the failure to maintain the confidentiality, integrity or availability of data (the so-called CIA triad). A full risk syntax for IT would look something like this:

to cause

An example of this in practice could be:

Cyber criminals attacking customer databases to cause confidentiality loss

Taxonomy and depth

When creating risk taxonomies for your technology risk concerns, they should focus on the major CIA triad impacts, and decompose events at the lower levels in an IT risk register. The overarching idea is that we want to illustrate big picture cyber risk for the board and senior leadership, but have supporting risks at the lowest level that allow granular risk management and assignment of controls.

For example, if we list the following risk scenarios in a board-level report, we risk bogging down discussions with minutiae that are irrelevant to their management goals:

• Cyber criminals use ransomware to infect general ledger application resulting in missed regulatory filings
• Malicious insider destroys data in general ledger application resulting in missed regulatory filings
• Cyber criminals manipulate data in general ledger application causing integrity issues with regulatory filings
• Malicious insider manipulates data in general ledger application causing integrity issues with regulatory filings

There are clearly many actors who have many ways to achieve their malicious goals, and these are important to cyber security professionals. For instance, the controls we would use to protect against and repel ransomware differ from those that we would use to prevent insider attacks. That distinction is too fine-grained for high level reporting, so risk register items that might appear in an enterprise risk register could look like this:

• Unavailability of critical accounting applications
• Compromised integrity of critical accounting applications

But even that may be too granular for certain levels of reporting. When building a risk reporting hierarchy, it’s always critical to consider the organisational level to which the taxonomy levels correlate. A typical reporting hierarchy that you might employ could look like this:

• Level 0 - CEO/Board of directors
  • Level 1 - Chief information officer (CIO)
    • Level 2 - Chief information security officer (CISO)
      • Level 3 - IT CRO/Head of IT risk

Your level of decomposition will naturally vary as your reporting lines may differ. At each layer of decomposition, you introduce additional layers of detail about the scenarios, and directly address information risk issues that are the most concerning to the leadership at the corresponding level.

For instance, at the CEO/Board level, questions you might be posed include the following:

• Are we keeping our customers’ information safe?
• Are we protecting our customers’ money?
• Are we complying with rules and regulation?
• Will our systems be there when our customers need us?

These can be expanded depending on your specific business (financial institutions may want to add “Are we managing our customers’ money well?” to the list). As a result of considering these questions, we have the first level of decomposition in our risk hierarchy:

• Safeguard our customers’ data
• Safeguard our customers’ money
• Comply with regulations
• Be available for our customers

In some ways, these risk categories can reflect corporate values, and serve as a tool to integrate risk into company culture. Further, you will note that this format does not comport with the risk syntax presented above. This is on purpose, as the higher in the taxonomy one goes, the further away from a fully qualified risk syntax one gets. Also note that these categories serve as natural language categories for risk questions. For instance, they make it easy for executive to ask, “What is our cyber risk associated with safeguarding customer data?” The answer to which would best be expressed as a quantitative monetary value (eg, $6 million).

Let’s decompose to the next layer for the first entry in our list. At this level, we are hoping to provide better insight for the CIO to understand their risk exposure. As a result, we might create the following layers of decomposition under the first CEO/Board level risk taxonomy entry:

• Safeguard our customers’ data
  • Malicious insiders compromise customer data
  • Cyber criminals compromise customer data
  • Human error compromises customer data
  • System failure compromises customer data

As you can see, the detail increases as we move to addressing issues at the CIO level. Namely, we’ve fully articulated the threat communities that could cause that loss to occur. As expected, moving one layer down to the CISO level gives us a yet more granular picture of cyber risk by articulating the event, or attack vector, for the risk scenario:

• Safeguard our customers’ data
  • Malicious insiders compromise customer data
    • Malicious insiders utilise excessive/inappropriate privileges to compromise customer data
    • Malicious insiders utilise system/application control weaknesses to compromise customer data
    • Malicious insiders commandeer another user account to compromise customer data
    • Malicious insiders utilise social engineering to compromise customer data

We are almost at the bottom of the hierarchy at this point. All that is left is to ensure that the CISO-level risk entries adhere to the fully qualified risk syntax and we have the final level of decomposition (the IT CRO/head of IT risk-level risk statements):

• Safeguard our customers’ data
  • Malicious insiders compromise customer data
    • Malicious insiders utilise excessive/inappropriate privileges to compromise customer data
      • Malicious insiders utilise excessive/inappropriate privileges to compromise customer data causing confidentiality losses

This deepest layer does not subdivide the CISO-level risk so much as fully articulate it by adding the specific CIA impact type that would be recognised. This is an important step for the quantification of this risk scenario as it facilitates the use of risk rating tables. In this scenario you would use rating tables that cover malicious insiders (threat event frequency) and confidentiality (loss magnitude) to quantify this risk. Depending on the organisation you are in, it may be useful to collapse the cyber risk and CISO level risks into a single catalogue that can be used to manage risk for the organisation. Other considerations might include the need to subdivide these risk scenarios by business lines or affiliates. For instances, you may have risks that look like this:

• Safeguard our customers’ data
  • Malicious insiders’ compromise customer data at business line/affiliate X
    • Malicious insiders utilise excessive/inappropriate privileges to compromise customer data at business line/affiliate X
      • Malicious insiders utilise excessive/inappropriate privileges to compromise customer data causing confidentiality losses at business line/affiliate X

…and so on for other business lines and affiliates.

The subdivision can happen higher or lower in the taxonomy depending on how your company is organised.

Demarcation between first and second line cyber risk functions

It is not in the scope of this article to offer arguments as to whether the cyber risk function in your organisation should be designated as a first or second line function (or as some organisations call them, the 1.5 line of defence). Instead, what follows is a discussion of where to draw a line of demarcation in the taxonomy to give autonomy to the first line to manage their risk, while still enabling the requisite second-line risk reporting.

It may be useful to some risk professionals to use alternative language to manage these levels of decomposition in their organisations. For instance, some organisations have risk management policies that explicitly indicate that there should only be a single risk register for the entire company. As such, organising risk at levels of decomposition necessary for good cyber risk management can be challenging. In these cases, it could be beneficial to identify the lowest levels of the risk taxonomy as a risk ‘catalogue’ or alternatively risk ‘drivers.’ An example of this kind of demarcation that supports cyber risk as a first-line function looks like this:

• Safeguard our customers’ data (second line of defence)
  • Malicious insiders compromise customer data (second line of defence)
    • Malicious insiders utilise excessive/inappropriate privileges to compromise customer data (first line of defence)
      • Malicious insiders utilise excessive/inappropriate privileges to compromise customer data causing confidentiality losses (first line of defence)

The key to determining the correct breakpoint for your organisation will be a mix of reporting structures and aligning the risk taxonomy for the rest of the organisation at a commensurate level. Once you’ve determined a proportional risk-reporting level in the taxonomy, it becomes easy to align the cyber taxonomy to the rest of the organisation.

Risk visibility for asset owners and senior leadership

Cyber risk is operational risk and it benefits the organisation to have a risk management framework that allows the management of risk at two levels. The first is the ability for IT asset owners (those responsible for managing applications, servers, databases, etc.) to understand the risk they face as they make decisions about control states. The second is the ability for business process owners to understand how those IT decisions affect their businesses. It is through a taxonomy like the one identified above that you can unite these two similar yet disparate views of cyber risk. It also provides a strong bottom-up approach in support of an evidence-based, defensible risk posture.

Jack Freund is the coauthor of Measuring and managing information risk: A FAIR approach and contributed to Operational risk perspectives: Cyber, big data and emerging risks, published in 2016 by Risk Books.