This is Part 2 of my “Risk-based Compliance” series of articles - how to move security from Compliance-based Risk to Risk-based Compliance.
Part 1 Summary – Why move cybersecurity to Risk-based Compliance
In Part 1, "Why Move Cybersecurity from Compliance-based Risk to Risk-based Compliance," I discussed the value and limitations of Compliance-based Risk, and why you would consider moving to Risk-based Compliance.
Compliance-based Risk management refers to risk management that is treated as just another requirement needed to meet a compliance or regulatory framework certification or attestation. It’s typically done once a year with just enough effort to be accepted by an auditor. Minimal qualitative analysis is adequate.
Risk-based Compliance refers to a risk management process that is the overarching driver of an organization’s cybersecurity program. While compliance frameworks are still used, CISOs orient the security program to the strategic cyber risks of concern to business leaders using a quantitative process. This enables CISOs to justify control investments in terms of business risk reduction in dollars.
Risk Registers Drive Risk Management
Risk Registers are the centerpiece of risk management. Therefore, if risk management is going to drive a cybersecurity program, as in Risk-based Compliance, it must be formally structured around risks. But risk registers built for Compliance-based Risk too often contain a mixture of Loss Events and what we call Control Deficiencies.
Loss Events are actual incidents that have a financial impact on the organization such as Business Disruption due to Ransomware or Exfiltration of Sensitive Information. During the last five years we have researched and developed a comprehensive list of Loss Event Types – the Monaco Risk Loss Event Taxonomy. It turns out, so far, there are only 16 loss event types!! This includes for example Business Email Compromise which can be purely financial in nature and not related to data confidentiality, integrity or availability.
Contact me via LinkedIn if you would like to receive a copy of our Loss Event Taxonomy.
Control Deficiency is our umbrella term for vulnerabilities, misconfigurations, audit findings, pen test issues, and compliance non-conformities. It complements our use of the term Control, which is any technical or administrative activity that reduces risk. Controls improvements address Control Deficiencies.
The Risk Register for Risk-Based Compliance
As discussed in Part 1, Why, Monaco Risk uses a three-step process for risk management:
Define the loss events of concern to business leadership
Baseline current cyber posture in the context of those loss events
Evaluate and prioritize alternative risk mitigation investments
The Risk Register is the tool to document and manage Loss Events. Therefore, if the Risk Register contains a mixture of Loss Events and Control Deficiencies, it must be restructured to fulfill the first step of our risk management process. There are three tasks to this step:
a) Separate Loss Events from Control Deficiencies
b) Identify the Loss Events of concern to business leadership
c) Expand Loss Events into complete Loss Event Scenarios
What follows is an explanation of each of these three tasks.
a) Separate Loss Events from Control Deficiencies
Loss Events and Control Deficiencies are often mixed in two ways. First, there are individual items that are just Control Deficiencies. Second the same Loss Event appears multiple times associated with different Control Deficiencies.
Control Deficiencies by themselves are not risks. Risks are defined by the probability and impact of Loss Events by actors scoped to business processes and/or assets. As important as Control Deficiencies are, they cannot be individual items in a Risk Register. They have to be moved to a separate list.
Repeating Loss Events with different Control Deficiencies leads to an overly long list of items and hides the relationship between Loss Events and Control Deficiencies. You need a clear picture of the relationship between Loss Events and Control Deficiencies in order to prioritize and justify control improvements to mitigate risks.
Loss Events and Control Deficiencies need to be linked. The relationship between them is “many-to-many” in the sense that a Loss Event can result from threats that exploit many different Control Deficiencies and one Control Deficiency can cause more than one Loss Event.
Note that Control Deficiencies of the same type can be grouped together. For example, there may be multiple vulnerabilities related to a web application that is part of a revenue-generating business process. Therefore, improving the web application patching cadence ought to be considered as a mitigation investment. In general, grouping and analyzing Control Deficiencies related to a specific risk and across risks provide clues to alternative mitigation investments.
b) Identify Loss Events of Concern to Business Leaders
Prioritizing Loss Events is the next step after moving Control Deficiencies out of the Risk Register to its own list. While there are 16 Loss Event Types in our taxonomy, in our experience business leaders in an organization are concerned about a smaller number that would have a material impact. Note that after discussing cyber-related business risks with business leaders you may need to add Loss Events that were not already in the Risk Register.
It is critical for CISOs to understand which Loss Events are of concern to business leaders because only those drive control investment decisions. Put another way, there is a higher likelihood of getting budget approval for control investments that reduce the risk of loss events of concern to business leaders.
c) Build Loss Event Scenarios to Provide Context for Loss Events
The type of Loss Event only tells part of the risk story. It doesn't provide enough context for business leaders or security teams, i.e., the financial analysis that connects control efficacy to business risk reduction in financial terms.
To continue the Risk Register restructuring process, there are three other pieces of information that need to be added to each Loss Event to create what we call Loss Event Scenarios. They are Business Scope, Threat Actor, and Financial Loss Components. Each item in the Risk Register is a Loss Event Scenario.
Business Scope is the business activity, organizational unit, or asset class that is affected by the Loss Event. It ties the cyber event to the business. In addition, the Business Scope helps identify the risk’s business owner.
Upon completion of the risk assessment with the probability and related financial results generated, it is ultimately the business owner who decides on the risk treatment – accept, avoid, mitigate, transfer. If the treatment is mitigation, the business owner collaborates with the CISO to decide on the choice of mitigation investments based on risk reduction in dollars and Return on Investment.
Actor Type, such as External Attacker or Malicious Insider, affects the tactics, techniques, and attack paths used and therefore the types of controls that can reduce the likelihood and/or impact of the Loss Event.
Financial Loss Components is the third element of a Loss Event Scenario. They can be categorized in different ways – First Party and Third Party, hard and soft costs, insurable and uninsurable. Financial Loss Components are included in our Loss Event Taxonomy.
In summary, business leaders who consider cyber risk a strategic business risk motivate CISOs to move from Compliance-based Risk to Risk-based Compliance. This means focusing on the cyber-related Loss Event Scenarios (risks) of concern to business leaders. The first step is to restructure the Risk Register so that it contains only Loss Event Scenarios. Control Deficiencies still need to be documented, but in a separate table and related back to Loss Event Scenarios.
Please let me know if you have any questions about Risk-based Compliance in general or Monaco Risk’s process in particular.