CHAPTER 7

Translating Cyber Risk into Business Risk

A ship is safe in harbor, but that's not what ships are for.

— John A. Shedd

Opportunity

If anything resonates with the C-suite and the board, it's the Almighty Dollar in both making it (revenue) and saving it (reducing costs/operational efficiency).

Technology adoption brings about a tremendous growth opportunity for businesses (e.g., revenue). According to the World Economic Council, more than 50% of the world's population is now online, approximately one million people go online for the first time, ever, each day, and two-thirds of the global population own a mobile device.¹ Additionally, technology adoption can reduce costs by automating existing manual processes, enable mobility so that an employee is no longer chained to their desk, and reduce human error.

Now, couple technology adoption by organizations with the rapidly increasing cyber threat landscape. Per IBM, the average cost of a data breach in 2020 is $3.86 million.² In their annual 2021 Data Breach and Investigation Report, Verizon identified that external attackers accounted for about 80% of breaches, which is up from 70% in 2020.³ This statistic goes against conventional wisdom that the internal threat is the largest cyber threat an organization faces; however, that is not to say that external attackers did not use unknowing internal employees or contractors to help their cause. 2020 will forever be known as the year of the COVID-19 global pandemic. The pandemic forced many companies to shift from a mainly in-the-office work culture to a 100% remote work culture almost overnight. The speed of technology adoption required of many firms to support the new “normal” workforce was mindboggling, leaving cybersecurity teams struggling to keep pace.

The statistics mentioned above are only an appetizer for this chapter's main course, which outlines how to translate technical cyber risk to business-level risk. The good thing is that C-suite executives and the boards of directors are open to that conversation now more than ever before.

Principle

Chapter 6 – Cybersecurity: A Concern of the Business, Not Just IT discussed establishing a cyber risk management program's foundation using the first two risk management components of COSO, Governance and Culture, and Strategy and Objective Setting. In this chapter, we will expand upon those foundations and focus on the execution of the cyber risk program and how to roll-up cyber risk into a portfolio view of enterprise risk that executive leaders, and the board, can use to make business decisions. To do this, we will align with the final three risk management components of COSO: Performance, Review and Revision, and Information, Communication, and Reporting. This chapter may be one of the longest of this book, but this topic is a large premise around which we felt the need to write this book.

Foundational to this chapter is an equation you may have seen many times in studying other cybersecurity materials. Still, we will define it here again, so we can set the table stakes. It is the simple risk equation, but this simple, little equation permeates every topic in this chapter:

Where:

Impact	=	the loss expectation if a risk event occurs
Likelihood	=	the probability that a risk event occurs

This equation, which is continuously beaten into our heads from the time we can spell “cybersecurity,” is a gross oversimplification of risk (kind of like how E=mc2 is a gross oversimplification of Albert Einstein's Theory of Relativity). Still, it does isolate two ways to reduce risk. Either you can reduce the likelihood of a risk event to the business or reduce the impact of a risk event on the business.

Businesses are increasing their dependency on technology, not decreasing it. Digital transformation promises to increase that dependency, more than during any other time in history. As such, the digital threat landscape continues to grow, which means that a cyber incident's potential impact on business also increases. The likelihood that an organization will have a cyber incident also increases as their dependency on technology grows. The rush to adopt new technology often outpaces how cybersecurity teams can put proper security controls in place. All of this amounts to – you guessed it – increased risk exposure to the organization, which means that the responsibility and accountability for implementing appropriate security controls lie across the entire organization rather than only the cybersecurity team. For example, if your organization develops software with one cybersecurity person per 50 developers, it is impractical and inefficient for that single cybersecurity person to ensure the code is secure. Instead, it becomes the cybersecurity team's role to provide assurance that others (in this case, the developers) are doing their job.

Performance

The key to minimizing risk is pulling on the two levers of likelihood and impact by identifying and prioritizing risk events and measuring how risk treatment plans are performing. Just don't forget, if a technology stack fails and it does not (materially) impact the business outcome, nobody in the C-suite cares.

Minimizing cyber risk requires identifying, assessing, and responding to risk that may impact the organization's ability to achieve its business goals. Cyber risks could affect an individual business unit or the organization as a whole, and they may cascade up and down the organization accordingly. Significant investment may be required to mitigate risk. Alternatively, the organization may try to transfer the risk or ultimately accept the risk.

An organization will never be able to “secure all things all the time.” More importantly, it should not attempt to do so because that will lead to an ineffective allocation of capital. The organization must ultimately assess the risk and determine the best course of action after factoring in business goals, the criticality of assets, risk appetite, and risk tolerance.

Bubbling up cyber risks to the ERM team (which may just be your Executive Leadership Team in a smaller or privately held company) in a manner that can easily align to other enterprise risks to provide a common view of risk across the organization will:

· Identify conflicting risks

· Highlight, correlate, and aggregate common risks across business units

· Create a risk taxonomy followed across the organization

For instance, the C-Suite will ignore any talk about a CVSS score, which measures the severity of a vulnerability. However, the C-Suite will certainly listen when you can paint a picture of how that vulnerability, along with the likelihood of it being exploited, can lead to a material impact on the company's financials and reputation. Presenting risks in this manner allows executives to evaluate cyber risks alongside other risks that the organization faces.

This component of COSO concentrates on how the organization considers risk while executing on strategy and achieving business goals. The five COSO principles for performance are:⁴

1. Identifies risk

2. Assesses severity of risk

3. Prioritizes risk

4. Implements risk responses

5. Develops portfolio view

Identifies Risk

Oddly enough, minimizing risk starts with first identifying the risk.

Mind-blowing, mic-drop, and end-of-book.

In all seriousness, identifying risk is easier said than done. Much like how an organization identifies new, emerging, and changing risks in achieving its strategic objectives, cybersecurity teams must do the same for cyber risks which can impact those strategic objectives. There is an argument to be made that cyber risks should be evaluated more frequently than traditional enterprise risks due to the fast-changing nature of the cyber threat landscape. Table 7.1 highlights how COSO categorizes when to trigger cyber risk assessments when new, emerging, and changing risks arise and some examples of how assessing cyber risks may apply.

TABLE 7.1 When New, Emerging, or change in risks occur

COSO Statement	Need for Cyber Risk Assessment
Change in business objectives	Digital transformation increases the risk exposure as critical business processes become more dependent on technology and automation.
Change in business context (i.e., changes in consumer preferences lead to the launch of a new product or service.)	New product or service offerings often include new approaches to sales, marketing, operations, and technology that all introduce cyber risk.
New business context	New regulations, such as GDPR or CCPA.
Previously unknown risks	Discovery of new vulnerabilities (or previously unknown assets) that are being exploited by attackers that are directly applicable within your organization's technology environment.
Changes in previously identified risks due to a change in risk appetite, or supporting assumptions	Refer to the beverage company example in Chapter 4. The organization decided to pursue an integrative and diversified growth strategy, in conjunction with cost reduction goals, through the use of new marketing AI and robotic process automation.

It is impossible to identify every possible risk, but it is possible to identify the most likely risks that impact an organization's goal of meeting its objectives. However, paying attention to the items listed in Table 7.1 allows an organization to take a long-term risk approach. It also gives the organization time to assess the potential severity of the risks and develop the necessary treatment plans. For instance, organizations had almost two years from when the General Data Protection Regulation (GDPR) passed the European Parliament until they had to comply.

From a cyber risk perspective, risk identification comprises four primary inputs:

1. Inventory and value of assets

2. Identifying potential threats

3. Identifying successful attack scenarios

4. Evaluating potential consequences

INVENTORY AND VALUE OF ASSETS

Any risk assessment must first understand your organization's digital and physical assets and their value to the organization. Organizational value always breaks down to dollars and cents, but it is not always easy to translate it to those terms. For instance, risk to revenue may be easy to calculate. If a revenue generating system becomes unavailable, you can assign a value to lost revenue based on prior sales patterns. Assigning a monetary value to the risk to safety or the risk to reputation is much more challenging to accomplish. Cyber risk management is not always about protecting intellectual property and an organization's revenue. Intellectual property and revenue may be the drivers for industries such as financial services and technology, but in the utility industry, the most significant risk to the organization is likely the risk to the safety of employees who are working within the power plant, water treatment facility, or natural-gas plant. In these environments, a networked system such as a supervisory control and data acquisition system (SCADA) is connected to the organization's network and can control physical processes such as a valve controlling flow and pressure.

Officially, a business impact analysis (BIA) allows you to accomplish the goal of understanding the importance of assets to your organization. The BIA assesses the amount the organization stands to lose when there is business disruption. The BIA assumes worst-case scenarios and involves understanding the type and rate of expected loss under fixed conditions. BIA is used to recognize the magnitude of financial and operational impacts derived from disruptions, failed legal compliance, or failed regulatory compliance. The BIA should produce the following:

· Impact types and criteria relevant to the organization

· Activities that support the provision of products and services

· Assessment of the impacts over time resulting from the disruption of these activities by using the impact types and criteria identified above

· The time frame within which the impacts of not resuming activities would become unacceptable to the organization (maximum tolerable period of disruption)

· Prioritized time frames within the maximum tolerable period of disruption for resuming disrupted activities at a specified minimum acceptable capacity (recovery time objective)

· Prioritized activities based on the analysis above

· Resources that are needed to support prioritized activities

· Dependencies, including partners and suppliers, and interdependencies of prioritized activities

Assessing digital and physical assets' business impact is necessary to differentiate between critical (urgent) and noncritical (nonurgent) services, technologies, or processes. A service, application, or process may be considered critical if the implications resulting from loss or disruption are regarded as unacceptable. For this reason, an organization cannot conduct the BIA in a vacuum. It must be undertaken and driven by senior management throughout the organization.

Ironically, determining the criticality of assets is often “the missing link.” There are many resources available for determining the criticality of assets, but they largely have to do with the discipline of reliability engineering of physical processes (e.g., a manufacturing plant floor). These models are difficult to adapt to information assets, but NIST published “NISTIR 8179 Criticality Analysis Process Model: Prioritizing Systems and Components,” which specifically addresses analyzing the criticality of information assets. The goal of the model is to provide a structured method of prioritizing programs, systems, and components based on their importance to the organization's mission and the risk that their ineffective or unsatisfactory operation or loss may present to the mission. The model is structured to logically follow how organizations typically design and implement projects and systems and can be adapted to fit organizations' unique practices.

The Model consists of five main processes:⁵

1. Define Criticality Analysis Procedure(s) where the organization develops or adopts a set of procedures for performing a criticality analysis.

2. Conduct Program-Level Criticality Analysis where the program manager defines, reviews, and analyzes the program to identify key activities that are vital to reaching the objectives of the program and for reaching the overall goals of the organization.

3. Conduct System/Subsystem-Level Criticality Analysis where the system designer reviews and analyzes the system or subsystem from the point of view of its criticality to the overall organizational goals.

4. Conduct Component/Subcomponent-Level Criticality Analysis where the system or component engineer reviews and analyzes component or subcomponent from the point of view of its criticality to a specific system or subsystem of which these components and subcomponents are a part.

5. Conduct Detailed Review of Criticality for Processes B, C, and D where the program manager or a collaborative group analyzes baseline criticality analysis results to create final criticality levels for Systems/Subsystems and Components/Subcomponents.

The workflows for the above processes can be found at www.CISOEvolution.com.

There are many resources available for conducting a complete BIA, of which determining asset criticality is a crucial part. Some resources include ISO 22301: Societal security – Business continuity management systems – Requirements and NIST Special Publication 800-34r1: Contingency Planning Guide for Federal Information Systems. There is an example of a completed BIA at www.CISOEvolution.com.

IDENTIFYING POTENTIAL THREATS

Per NIST, a threat is “any circumstance or event with the potential to adversely impact organizational operations (including mission, functions, image, or reputation), organizational assets, or individuals through an information system via unauthorized access, destruction, disclosure, modification of information, and/or denial of service. Also, the potential for a threat-source to successfully exploit a particular information system vulnerability.”⁶

If we peel that back a little, we can break this down into two parts. The first and obvious part is that a threat needs to have the ability to harm the organization. The second is that a threat also needs to consider the likelihood that it can exploit a vulnerability. If we reference the risk equation from earlier in the chapter, a threat with zero likelihood of exploiting a vulnerability equates to zero risk.

As mentioned above, threats exploit vulnerabilities. Vulnerabilities can come in the forms of software bugs, flaws in system logic, missing patches, or misconfigurations. Many organizations use automated scanning tools to identify these vulnerabilities, but these only address known vulnerabilities in hardware and software. Cybersecurity goes beyond that. Vulnerabilities may exist in other areas such as business continuity, training, utilities, supply chain, and physical access.

There are numerous sources of available cyber threat information, ranging from paid subscriptions to free sources, such as the Cybersecurity and Infrastructure Agency (CISA). Several threat modeling techniques are available for analyzing these threats. These techniques focus on two approaches: top-down and bottom-up. A top-down approach is an asset view that evaluates critical assets for what could potentially go wrong. A bottom-up approach is a threat view that assesses the potential impact of a given set of defined threat scenarios. Some examples of each type of approach are:

· Software Engineering Institute (SEI) Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE®) (top-down): Helps organizations tie together assets that are critical to achieving organizational objectives. The threats to those assets and the vulnerabilities those threats may exploit.

· Microsoft STRIDE (bottom-up): STRIDE stands for Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Escalation.

· MITRE's ATT&CK™ (bottom-up): A globally accessible knowledge base of adversary tactics and techniques based on real-world observations.

An example STRIDE threat model can be found at https://www.logicworks.com/blog/2020/02/security-risks-in-public-cloud/. However, no matter which method you use, it is vital to consider them in the context of the threat actors (e.g., script kiddies versus nation-states) and their impact as the result of their actions.

IDENTIFYING POTENTIAL ATTACK SCENARIOS

Now that we understand how to identify threats, we need to determine how they can exploit our environment's weaknesses. Again, a threat cannot become a risk unless there is a weakness that the threat can exploit. That is where our traditional understanding of vulnerabilities come in. As we mentioned earlier, vulnerabilities may exist in areas such as business continuity, training, utilities, supply chain, and physical access, so it is essential to understand vulnerabilities across more than just the traditional Common Vulnerabilities and Exposures (CVEs) that an automated scanner can identify. On the flipside, a vulnerability is not a risk unless a threat is willing to exploit it.

Here is another example of why understanding business context is essential. Attack scenarios will differ for your type and size of organization. A Fintech startup will have vastly differing attack scenarios than a nuclear power plant. Take the time to identify the attack scenarios that attackers are most likely to use in your environment.

You can use many methods to identify attack scenarios for your organization, but our preferred method is to directly look at the organization. No data is more relevant than looking at yourself in the mirror. The three primary approaches to do so are penetration testing, red teaming, and threat hunting. No matter which method you use, the Mitre ATT&CK™ framework (https://attack.mitre.org) is a great resource for identifying attack scenarios for many environments, including on-premise enterprise, cloud, and industrial control systems. Figure 7.1 highlights the similarities and differences between each.

A penetration test (pentest) “is an authorized simulated cyberattack on a computer system, performed to evaluate the security of the system.”⁷ A penetration test aims to find and exploit as many vulnerabilities as possible that can lead to a compromise. Of the three approaches we describe, this is more of a “spray and pray” approach vs. a more targeted approach. Pentests typically only focus on compromising a vulnerable application or service to gain access to the network. A goal is usually defined, but the pentest team is generally not concerned with remaining hidden. This approach is akin to a burglar testing all of the windows and doors to a home in broad daylight. The organization's security operations team may or may not know the pentest is occurring, so security defenses and controls can be tested, to an extent.

FIGURE 7.1 Penetration Testing, Red Teaming, and Threat Hunting Overlap

A red team assessment “is similar to a penetration test in many ways but is more targeted.”⁸ This assessment aims not to find as many vulnerabilities as possible but to test the organization's detection and response capabilities. A red team not only evaluates technology, but it evaluates people and processes, as well. Instead of merely scanning the external network for vulnerabilities and trying to exploit a vulnerable service to gain access to the network, a red team will use a combination of external attacks. Tactics might include a social engineering phone call, replicating employee badges to gain physical access to an office, or trying to breach physical safeguards at a remote facility, such as a power utility substation. The red team will try to get in and access sensitive information in any way possible, as quietly as possible. A red team is more akin to the burglar trying to get into your home at night and doing everything they can to avoid triggering any alarms.

Finally, threat hunting “is the process of proactively and iteratively searching through networks to detect and isolate advanced threats that evade existing security solutions.”⁹ A security analyst evaluates data from their tools and uses their “insider” knowledge of the network to develop hypotheses about potential threats. They look through the network for potential incidents and reverse engineer how the incident may have occurred. Any new information gleaned, such as indicators of compromise (IOC) or tactics, techniques, and procedures (TTP), is fed back into the organization's capability to prepare or mitigate risks. Threat hunting is an internal effort that is iterative.

EVALUATING POTENTIAL CONSEQUENCES

Now that we understand the potential threats and attack scenarios, we need to evaluate the potential consequences the threats and attacks, or incident scenarios, may have on our identified assets.

A consequence can be loss of effectiveness, adverse operating conditions, loss of business, reputation, damage, etc. that our identified incident scenarios may have on our organization.¹⁰

The impact of the incident scenarios must consider our business context (refer to Chapter 6 – Cybersecurity: A Concern of the Business, Not Just IT Through the BIA), assets should have assigned values based on their financial cost and business consequences if they are damaged or compromised.

Some consequences to factor in are:

· Health and safety (particularly in operational technology environments)

· Investigation and repair time

· Work time lost

· Opportunity cost

· Costs to bring in outside help for remediation activities

· Image reputation and goodwill

Assesses Severity of Risk

Use the lessons learned from identifying risk to inform the risk register and risk treatment plans (see www.CISOEvolution.com). Once risks are documented in the risk register, it is now time to assess the severity of each risk's potential to disrupt the organization's ability to meet its business objectives and strategic goals. A risk register is an inventory of identified risks. A risk register is used to track risk exposure (including likelihood and impact), risk owners, risk treatment decisions, action plans, and residual risk. Residual risk is the amount of risk that is left over after the risk treatment is applied. Risk registers can be as simple as a basic spreadsheet, or be incorporated into more complex governance, risk, and compliance software to create and track risk management controls and workflows.

Management cannot address or mitigate all risks due to constraints such as budget and resources; therefore, management decides on how to allocate resources to a given risk based on the assessment of the risk to ensure that the residual risk remains within the organization's risk appetite (see Chapter 6 – Cybersecurity: A Concern of the Business, Not Just IT).

Methods for assessing risk fall into two buckets:

1. Qualitative: Qualitative analysis is subjective. You will often see risk scales described as low, medium, or high. Information from international standards, industry best-practices, or prior risk assessments is used to inform a qualitative analysis. Qualitative analysis is helpful when there is not much quantitative data available or intangible risks, and benefits need to be considered. Qualitative analysis techniques include risk factor analysis, the Delphi technique, and SWOT analysis (strengths, weaknesses, opportunities, and threats).

2. Quantitative: Quantitative analysis is objective. Numeric data, such as annualized loss expectancy (ALE) and probability, are used to assign impact and likelihood of a risk being realized. The quality of the analysis is only as good as the data that goes into it. The most well-known quantitative analysis technique applied to cybersecurity is Open FAIR™.

Do not pigeon hole yourself into one of these two camps. There is room in our lives for both (much like the Star Wars vs. Star Trek debate – just stop it). I have witnessed CISOs fail because they only used qualitative analysis with no hard data backing their assessment of risk severity. I have also witnessed CISOs fail because they only used quantitative analysis without considering any qualitative factors, such as an organization's commitment to sustainability or rolling out a new product or service on-time. A complete and defensible risk analysis depends on both qualitative and quantitative considerations.

Both methods have a likelihood and impact component. Likelihood is the probability that a risk will occur. It may be expressed as a set of probabilities assigned to a set of possibilities, “There is a 20% chance that we will experience a data breach in the next five years” (quantitative), or as a scale, “low, medium, high” (qualitative). Impact is usually described as a set of possibilities each with a probability and dollar value (quantitative), “We believe there is a 10% chance that a data breach will result in a legal liability exceeding $10 million,” or as a scale (qualitative).¹¹ Many considerations go into impact, such as the server's criticality, the timing of the risk event (e.g., at the end of a quarter for a financial system), or system redundancy.

Some techniques for estimating the likelihood that a risk will occur include:¹²

· Decomposition: A model that breaks large, ambiguous problems into smaller, more digestible subproblems.

· Bayesian Analysis: A model that improves upon a prior probability as more evidence or information becomes available. In other words, how we update prior likelihoods with new information.

· Monte-Carlo: A simulation model that uses a computer to generate many scenarios based on probabilities for inputs. For each scenario, a specific value is randomly generated for each of the unknown variables, and then the model would generate an output based on these variables. The process is iterative and can go through thousands of rounds.

Tracking risks and their potential consequences in a risk register enables you to integrate these risks in an ERM program more efficiently. Remember, when evaluating the likelihood and impact of risks, it is not only about the controls your organization is missing. You must also consider existing security controls. Do they compensate for the risk? If so, how much? Once a treatment plan for the risk is determined, make sure also to document the residual risk. Be sure to use the same method to calculate residual risk as you did for the original risk to make sure you are comparing apples-to-apples.

Prioritizes Risk

Now that cyber risks have been identified and documented in the risk register, your organization must go about the critical task of prioritizing risks. Again, all risks cannot be fully addressed all the time. That would not be an efficient allocation of capital and resources.

Does the exposure of the cyber risk fall within your organization's risk appetite and risk tolerance? If so, chances are your organization will accept the risk. If the cyber risk falls outside of your organization's risk appetite and risk tolerance, then a decision needs to be made to respond to, or treat, the risk. Suppose the cyber risk is likely to impact the organization's ability to accomplish its strategic goals. In that case, the risk is escalated up to the ERM team to be incorporated in the enterprise risk register in order to be evaluated and prioritized alongside other enterprise risks.

Each organization's ERM team will use different factors to prioritize risk, but these factors will include:

· A determination of overall risk exposure based on impact and likelihood

· A cost/benefit analysis of implementing a given risk response (don't spend a dollar to save a dime)

Given the above, be mindful of biases. Individuals tend to be overconfident in their estimates. Consider “calibration training” to improve subjective estimates.¹³

You have likely seen a version of a likelihood and impact matrix to determine overall risk exposure, as depicted in Table 7.2.

The formula for calculating risk exposure is:

Impact is calculated through the BIA process mentioned earlier in this chapter, and likelihood is the probability that the risk will happen. Table 7.3 shows an example of how I frequently see impact, likelihood, and risk exposure placed into their scales.

TABLE 7.2 Likelihood and Impact Matrix

Likelihood	Impact
	Very Low	Low	Moderate	High	Very High
Very High	Very Low	Low	Moderate	High	Very High
High	Very Low	Low	Moderate	High	Very High
Moderate	Very Low	Low	Moderate	Moderate	High
Low	Very Low	Low	Low	Low	Moderate
Very Low	Very Low	Very Low	Very Low	Low	Low

Source: Ross, R. S., Guide for Conducting Risk Assessments. Special Publication (NIST SP) – 800-30 Rev 1, September 2012, 95. https://doi.org/10.6028/NIST.SP.800-30r1.

It is important to note three things:

1. The monetary values are specific for each organization and are usually set by the board's risk committee or by the executive leadership team at a smaller organization.

2. The likelihood scales may shift according to the organization's risk appetite and may look like a bell curve where most of the range will fall in the “moderate” category.

3. A specific metric often qualifies the impact (e.g. $5 million negative impact to EBITDA, or $2.5 million total cost to recover from the risk event).

TABLE 7.3 Impact, Likelihood, and Risk Exposure Scale

Scale	Impact	Likelihood	Risk Exposure
Very High	> $5M	> 0.8	> $4M
High	$2.5M to $5M	0.6 – 0.8	$1.5M – $4M
Moderate	$1M to $2.5M	0.4 to 0.6	$400K – $1.5M
Low	$500K to $1M	0.2 to 0.4	$100K – $400K
Very Low	< $500K	< 0.2	< $100K

Work with your ERM team to determine the thresholds of your measurement scales, and to ensure they prioritize cyber risks at the business unit level and the enterprise level using the same methodology. The scales may change at the unit level, but the same methodology should always apply.

Calculating risk exposure allows the organization to prioritize risks accordingly. The simplest form is to rank the risks from the highest risk exposure to the lowest. The organization may take other internal and external factors into account, such as regulations, sustainability commitments, and additional corporate social responsibility.

Finally, speaking the same language of risk across the organization and ensuring your cybersecurity team follows suit has four primary benefits:

1. Creates a risk taxonomy across the organization.

2. Enables an aggregated and prioritized enterprise risk register that informs executives and the board of critical risks.

3. Facilitates the cost/benefit analysis of implementing risk responses.

4. Elevates the cybersecurity team's profile within the organization by demonstrating an understanding of cybersecurity's position within the enterprise's entire risk profile.

Implements Risk Responses

After prioritizing the risks, the organization must evaluate and implement treatment for each risk. The organization will strive to ensure that a risk is within its risk appetite and risk tolerance in the most cost-effective way. In other words, the objective in deciding the amount of investment to treat risk is mostly the same as all other organizational investments: to maximize the return on investment (see Chapter 2 – Business Strategy Tools, the section on Measure Business Performance Relative to Risk). A cost/benefit analysis is usually done on various risk treatment options to determine an optimal and effective solution.

The same should be done within individual business units, and in your case, likely the cybersecurity team. The ERM team will likely lean on you to help identify cost-effective yet impactful solutions to treat a risk. This risk treatment not only includes cyber risk, but it will probably include technology risk, in general. More and more, cybersecurity teams are also involved in privacy conversations (have you had your daily dose of GDPR or HIPAA today?). These conversations are yet another opportunity to elevate the cybersecurity team's role within the business. Too often, we, as cybersecurity professionals, love purchasing the shiny new toy without understanding the full context of the risk the toy intends to treat. For example, do you really need the Lamborghini of that bleeding-edge Identity and Access Management (IAM) solution, or will the Honda suffice? Is your organization even ready to invest in a full IAM solution, or does it have to do some data cleanup and implement some foundational processes and standardized workflows first?

There are generally four types of risk responses an organization can take:

1. Avoid: Change the strategy to avoid the risk. Avoiding risk is usually considered when there is no cost-effective method for reducing the cybersecurity risk to an acceptable level as defined by the unit's or the organization's risk acceptance and tolerance.

2. Mitigate: Apply risk treatment that reduces the threats, vulnerabilities, likelihood, or impact of a given risk so that the residual risk is within the unit's or the organization's risk acceptance and tolerance.

3. Transfer: Most organizations consider sharing a part of the risk with another organization in two main scenarios:

· The organization does not have full control over the implementation of security controls, such as an Infrastructure as a Service or a Software as a Service provider.

· The organization wants to minimize the financial consequences of a risk, such as in the case of purchasing cyber insurance.

4. Accept: Accept the risk as-is because the risk falls within the unit's or the organization's risk acceptance and tolerance but continue to monitor the risk if the risk falls outside of approved tolerance.

There are a variety of security controls that can be applied when deciding to mitigate a risk. A good inventory and taxonomy of controls can be found in standards NIST SP 800-53 (free) and ISO/IEC 27002:2013 (licensed). The controls accomplish one of the following goals:

· Prevent: Reduce the likelihood of an incident by mitigating a vulnerability.

· Deter: Reduce the threat by discouraging a threat actor from acting upon a vulnerability.

· Detect: Identify when an incident is occurring or has occurred.

· Correct: Applied after an incident to reduce the likelihood of a similar incident occurring again.

· Compensate: Apply one or more controls instead of a primary control because the primary control is not feasible due to technical, resource, or cost constraints.

Once a determination is made of the risk treatment and security controls, the organization should develop a corrective action plan. A corrective action plan is a step-by-step plan of action with defined milestones that risk owners will follow to treat the risk. If the risk register represents the “what,” a corrective action plan represents the “how and when.” Not every risk requires a corrective action plan. There is no reason to write a corrective action plan for an accepted risk. Some companies only write corrective action plans for risks that are deemed “high” or “very high.” The development and use of corrective action plans should be part of the organization's risk management strategy and standardized across the organization, but this requires buy-in as it will inevitably generate work for other teams. Get this buy-in by identifying how work is surfaced in other teams' workstreams. If the only projects that get attention are those that get talked about in a weekly scrum meeting, then make sure your initiatives are included there. A completed corrective action plan can be located at www.CISOEvolution.com.

Develops Portfolio View

A portfolio view allows management and the board to consider the type, severity, and interdependencies of risks and how they may affect performance. Using the portfolio view, the organization identifies severe risks at the organizational and business unit level. These may include risks that arise at the organizational level and transactional, processing-type risks that could disrupt the organization as a whole.¹⁴

Business unit risk registers need to be aggregated and normalized into an enterprise risk register to align enterprise risk. Then risks can be evaluated and prioritized across business units into an enterprise risk profile. It is important to remember that there are other risk inputs across the organization than cybersecurity. Assessing cyber risks alongside other risk inputs and overall business objectives enables a proactive and mission-oriented view of risk and allows effective risk decisions by company leadership. Figure 7.2 depicts a process by which risk decisions and decision flows at each level of an organization roll up into an enterprise portfolio view of risk.

FIGURE 7.2 Cyber Risk Portfolio View Rollup

Step 1, ERM Guidance, involves risk direction from the top of the organization. Corporate boards and executive leadership teams consider the relative importance of various external and internal factors alongside its strategy and business context, as discussed throughout this and the previous chapter. Organizational leaders can use these factors to determine risk acceptance levels and balance resource allocations for risk treatment across the organization. Operational leaders pass down the resulting resource and financial guidance to the business unit level.

In step 2, cyber risk assessments are conducted at the business unit level. Understanding the guidance from step 1 allows cybersecurity teams to help operational managers frame, assess, manage, respond to, and report cyber risks within the business unit and in alignment with organizational strategy. Security controls can then be selected for the desired cybersecurity risk treatment outcomes to ensure cyber risk is operating within the approved risk appetite and risk tolerance.

In step 3, risk treatment and monitoring results are reported to organization stakeholders. The risk determinations, decisions, and status are conveyed through the enterprise risk register and adjusted as necessary.

In step 4, the ERM team collects, aggregates, and normalizes risk register information. This process allows the ERM team to:

· Report understanding of actual and potential risks from threats and system failures to enterprise information and technology.

· Create a risk taxonomy and normalize risk management across the organization.

· Inform risk mitigation activities at the business unit level and relate these to organizational strategy and budgetary guidance to prioritize and implement risk responses.

· Produce enterprise-level risk disclosures for required reporting, public filings, and hearings. Corporate 10-K filings require risk disclosures. Regulations, such as HIPAA and CCPA, have defined reporting requirements in the event of a data breach. Major security incidents, such as the one that affected Equifax and its customers, have led to Congressional subpoenas and testimonies.

Adjustments made to risk priorities, risk appetites, and budgets are iterated as inputs back into step 1.

Review and Revision

After a football game, a football team will review its game film and performance and make any adjustments they need to ensure success before their next game. A cybersecurity team must do the same for all of its processes, but especially for risk management. An organization reassesses its ERM program over time as its business objectives change. In conjunction with a constantly evolving technology and threat landscape, this reassessing requires cybersecurity teams to reassess and revise their risk management practices continuously. This includes removing security controls, if necessary (the horror). Our experience suggests that it's rare to see security teams remove controls – even when they become outdated. Signature-based detection, anyone?

Managing enterprise risk is a balancing act between organizational strategy, the costs and impacts of a risk, and its benefits. As an input into ERM, cybersecurity risk must be continuously monitored to help organizations evaluate the right formula to maintain the optimal mix of strategy/cost/benefit. Continually reassessing cyber risk management practices ensures cybersecurity teams remain aligned to organizational objectives and can continue to identify and manage risks associated with new threats and vulnerabilities. Our challenge as cybersecurity leaders is to do this faster and more efficiently to keep up with the pace of innovation and digital transformation throughout our organizations. The three COSO principles for Review and Revision are:¹⁵

1. Assesses Substantial Change

2. Reviews Risk and Performance

3. Pursues Improvement in Enterprise Risk Management

Assesses Substantial Change

The cybersecurity threat landscape is constantly changing; therefore, cybersecurity risks need to be continuously monitored to ensure they remain within the organization's risk acceptance and tolerance. Stay aware of the changing cybersecurity risk landscape through sources such as subscriptions to free community alerts. Some examples include:

· CISA Automated Indicator Sharing (https://www.cisa.gov/automated-indicator-sharing-ais)

· InfraGard (https://www.infragard.org/)

· SANS Internet Storm Center (https://isc.sans.edu/)

· National Council of ISACS: Member ISACS (https://www.nationalisacs.org/member-isacs)

By establishing a methodology to monitor risk continuously, a new risk assessment, or at a minimum, the review of an individual risk, can be triggered to determine if risk priorities have changed. Keep in mind that it is also important to monitor risks that were previously accepted. This measurement is done using key risk indicators, which we will review in the next section (Reviews Risk and Performance). Continuous risk measurement also helps drive a strong security culture throughout the organization.

Why would you continuously monitor risk if there were no assigned accountabilities for risk throughout the organization? Of course, you wouldn't. It would be foolish to waste time and resources if there were no accountability for actually doing anything about the newly identified or reprioritized risks. Doing a one-time risk assessment or an annual risk assessment provides a snapshot of your organization's cyber risk profile. It is easy to get buy-in once a year to “get things fixed.” It is much harder to get buy-in to respond to risk throughout the year continuously. This buy-in is another reason why the cybersecurity steering committee, described in Chapter 6, is so essential to establish. The roles and responsibilities for managing and responding to risk can be assigned and communicated at that level with buy-in across all key business units.

The cybersecurity steering committee can discuss necessary resource changes, or schedule changes, as the result of identifying or re-prioritizing a risk before rolling up to ERM. A plan can be determined, with the risk owner agreeing to key performance indicators (KPIs) for measuring milestones in the progress of treating the risk. By measuring these KPIs, the organization can measure appropriate strides in treating the risk. When the residual risk falls within an acceptable risk acceptance, the resources used in treating that risk can be released and shifted with the focus now moving towards maintenance and measurement.

Reviews Risk and Performance

Key risk indicators (KRIs) are the tactical application of a risk appetite statement.¹⁶ They are used to provide an early indication that a risk is increasing and approaching a risk tolerance threshold.

Many organizations focus heavily on KPIs rather than KRIs. Recall from Chapter 2 – Business Strategy Tools, often KPIs are lagging indicators, KRIs are leading indicators, so in reality, they need to be considered in conjunction and complement each other. An example of a KPI can be “100% of crown jewel critical patch deployments within SLA.” If only the KPI is reported, ERM may interpret that risk from vulnerabilities being exploited is reduced by 100%. That is, clearly, a false notion. This metric does not measure actual risk reduction. However, linking a KRI to a KPI, as suggested by the McKinsey & Company whitepaper “The Risk-based Approach to Cybersecurity,”¹⁷ provides ERM with a better picture of risk and risk reduction. In our example, the “crown jewel” assets identified by ERM can be the KRI, and tying the KPI to the percentage of “crown jewel” assets covered will give ERM and executives a better view of how risk is trending towards, or away, from, risk tolerances.

Developing and choosing KRIs requires a solid understanding of organizational goals and risks that impact the achievement of those goals. A useful set of KRIs pinpoint appropriate metrics that call out potential risks that may affect the organization's ability to achieve its goals. There must be a connection of risks to strategic initiatives so that the KRIs capture the most relevant information that can inform you, ERM, and executive leadership when a risk may exceed the organization's risk tolerance. Figure 7.3 highlights the linking of organizational goals to strategies to risks to KRIs.

FIGURE 7.3 Linking Objectives to Strategies to Risk to KRIs

Source: Beasley, M.S., Branson, B.C., Hancock, B.V. and Landes, C., “Developing Key Risk Indicators to Strengthen Enterprise Risk Management,” COSO – Thought Leadership in ERM, 2010, 1–20. papers2://publication/uuid/A17DB7CA-6EC5-4F23-84FE-DB4996794C37. All rights reserved. Used with Permission.

Measure both inputs and outputs of the risk processes. The inputs in this case are risk-reduction efforts (e.g., updating antivirus signatures – the KPI). The output is the actual reduction in enterprise risk (e.g., reducing the risk that critical systems will be taken offline or that there will be a data breach due to malware – the KRI). The thresholds set for KRIs and KPIs should be aligned to risk tolerance. One way to think about KRIs and KPIs is to think about the relationship between altitude and trajectory. The McKinsey paper gives a great example of the relationship between KRIs and KPIs:

A KRI gives the current risk level of the enterprise (the “risk altitude”) while the KPI indicates the direction toward or away from the enterprise-risk-appetite level (“risk trajectory”). An enterprise may not yet have arrived at the leadership's KRI target but a strong KPI trajectory would suggest that it will soon. Conversely, an enterprise may have hit the desired KRI threshold, but the KPIs of the run activity may be backsliding and give cause for concern.¹⁷

When creating KRIs, keep the following tips in mind:

· Link KRIs to specific risk scenarios.

· Ensure they are complete, accurate, and specific.

· Do not have too many KRIs. Select a handful that are specific and applicable for your organization.

· Measuring KRIs is challenging. Ensure you have the appropriate measurement mechanisms in place for the KRIs you develop.

· Aggregate, compare, and systematically interpret KRIs at an enterprise level.

Table 7.4 outlines how organizations can link KRIs, KPIs, and potential business impacts.

TABLE 7.4 Linking KRIs with KPIs Source

KPI (Input)	KRI (Output)	Implication/Business Impact
Number of identified regulations, policy, or process violations	Percentage of incidents involving customer personal data	This indicates a failure to meet compliance obligations and might lead to scrutiny from regulators or media, which can adversely impact the reputation of the organization.
Number of security-related service downtimes	Number of services canceled or delayed as a result of security-related service downtimes	Security incidents impacting critical systems potentially cause service interruption or degradation.
Number of business applications/systems not supported by a backup plan	Percentage of business applications/systems not supported by a backup plan	Lack of data backup for business applications/systems leads to data loss and adversely affects service continuity in case of any interruption.
Percentage of nonconformities detected in security tests/audits, but not resolved within the timeframe planned	Number of nonconformities detected in security tests/audits remaining unresolved beyond the planned time frame	Delay in remediating vulnerabilities detected in security tests/audits makes the organization an easy target for malicious attacks.
Inadequate third-party management	Number of security incidents attributed to vulnerabilities in third-party systems/employees	The organization's information can be exposed to risk by third parties with inadequate information security management.
Lack of adequate time frame for scheduled downtime of systems	Number of systems without up-to-date patches	Delay in patching the systems makes the organization an easy target for malicious attacks.
Lack of review of risk management processes	Lack of effective reporting of key risk	In the absence of a review of risk management processes, these processes might continue to be ineffective, resulting in nonidentification of vulnerabilities/risk.

Source: Tammineedi, R.L.S., “Integrating KRIs and KPIs for effective technology risk management,” ISACA Journal 4 (2018): 19–23. All rights reserved. Used with Perimission.

Linking KRIs and KPIs helps bring clarity to the fog of complex and conflicting metrics. Doing so elevates the cybersecurity team's profile by showing that it can engage executives in substantial conversations around which cyber risks are within tolerances, which are not, and why.

Pursues Improvement in Enterprise Risk Management

A robust cybersecurity risk management program must strive for continuous process improvement that reinforces effective processes, identifies ineffective processes, and adjusts accordingly. While all should be responsible and held accountable for any negligent activity, there is value in fostering a community that pursues opportunities within risk appetite levels while also being prepared for and continually thwarting threat actors that would exploit vulnerabilities.

Six Sigma is a recognized process improvement standard in the manufacturing world. Jack Welch, former chairman and CEO of General Electric, is one of the world's most renowned business leaders. He defines Six Sigma as “a quality program that, when all is said and done, improves your customer's experience, lowers your costs, and builds better leaders.” Six Sigma is a data-driven discipline that eliminates defects in any process to improve quality and profitability.¹⁹ We are not advocating that you run out and get a Six Sigma blackbelt; however, there are approaches in Six Sigma that can be applied to improve cybersecurity and cybersecurity risk management, particularly DMAIC (Define, Measure, Analyze, Improve, Control). Villanova University does a good job at describing each phase of DMAIC, but we have molded it to fit a cybersecurity project intended to reduce risk around an immature vulnerability management program.²⁰

· Define: The main objective of this stage is to outline the borders of the project:

· Stakeholders agree on the parameters that will define maturing the vulnerability management program.

· Scope and budgetary items, as well as organizational goals, are aligned with project goals.

· Team development takes place as the project begins to take shape.

· Measure: The main objective is to collect data pertinent to the scope of the project:

· Project leaders collect reliable baseline data on the vulnerability management program to compare against future results to measure improvement.

§ A vulnerability assessment solution is in place, and scans are ad-hoc.

§ System patching is inconsistent.

§ Basic processes.

§ No metrics.

· Teams create a detailed map of all interrelated business processes to clarify areas of possible improvement.

§ Outline critical systems and data flows.

· Analyze: The main objective is to reveal the root cause of process inefficiencies:

· Analysis of data reveals areas where the implementation of change can provide the most effective results.

§ Scheduled vulnerability scanning.

§ Scan-to-patch life cycle.

§ Patching priority is driven by system and vulnerability criticality.

· Groups discuss ways that the data underscores areas ripe for improvement.

· Improve: At the end of this stage, the main objective is to complete a test run of a change before it is widely implemented:

· Teams and stakeholders devise methods to address the process deficiencies uncovered during the data analysis process.

§ Scan-to-patch service level agreements.

§ Allowable windows to scan and patch.

§ Allowable downtime for patching.

§ If downtime is not feasible (e.g., a highly active eCommerce website), develop redundancy for the systems mapped out in the “Measure” phase.

· Groups finalize and test a change aimed at mitigating the ineffective process.

· Improvements are ongoing and include feedback analysis and stakeholder participation.

· Control: The last stage of the methodology's objective is to develop metrics that help leaders monitor and document continued success:

· Develop KPIs and KRIs (see Table 7.4).

· Adjustments and implement new changes as a result of the completion of this first cycle of the process.

DMAIC is an iterative process. Once the improvements are in place, the process owner monitors the KPIs and KRIs and repeats this method as needed to ensure the process is operating efficiently. The ability to improve managing cybersecurity risk supports broad organizational goals as part of ERM.

Information, Communication, and Reporting

The twenty-first century has welcomed exponential growth in technology that has led to a deluge of data. Businesses can use that data to make better and faster business decisions. The volume and velocity of data challenge some organizations and may cause “paralysis-by-analysis.”

This data describes stakeholders, products, markets, and competitor actions. Now, we must harness the promise of business intelligence and digital transformation to enrich business decisions with in a risk context. We must prepare to utilize the same data and techniques to help identify risks that could affect business performance. For example, cybersecurity incidents can impact this data's integrity and reliability, eroding the value of an investment intended to give an edge. The impact can be especially damaging if the incident is not detected and resolved quickly.

The three COSO principles for Information, Communication, and Reporting are:²¹

1. Leverages Information and Technology

2. Communicates Risk Information

3. Reports on Risk, Culture, and Performance

Leverages Information and Technology

As mentioned above, organizations leverage data to make better and faster business decisions. Threats, such as ransomware, have become prevalent over the past several years and have significantly impacted an organization's critical data availability and reliability. Threats like ransomware not only have internal repercussions, but also, if customer data is exposed or revenue generating services are taken offline, may result in significant reputational impact or noncompliance (e.g., HIPAA, CCPA, NERC CIP). Organizations may also use internal information systems for critical financial reporting and decision-making support.

Recovering from ransomware, or any cybersecurity incident, for that matter, can be extremely expensive; however, since ransomware has become so prevalent, we will focus on some statistics that should drive the point home:

· Cybersecurity Ventures predicts that a business will fall victim to a ransomware attack every 14 seconds in 2019 and every 11 seconds by 2021.²²

· The NotPetya ransomware cost FedEx $300 million in Q1 2017.²³

· The City of Atlanta, Georgia, was affected by the SamSam ransomware in March 2018. The city did not pay out the ransom, but recovery costs are estimated at $17 million.²⁴

· Norsk Hydro was attacked in March 2019 that forced it to fall back to manual processes. The company did not pay out the ransom, but it is estimated that the attack could cost the company up to $75 million in the first half of 2019.²⁵

These threats may also impact internal tools used to aid in cyber risk management and reporting, such as governance, risk, and compliance (GRC) systems that track and report risks using automated workflows. SIEMs and SOAR platforms can act on the big data that security tooling generates to facilitate alerting, reporting, and response to security events. Take particular care in protecting the integrity of these systems. Otherwise, a cascading effect may leave executive leadership blind to material threats and risks facing the organization.

Communicates Risk Information

An organization must emphasize its capability to communicate items that can affect cyber risk to internal and external partners. This facilitates the organization's ability to quickly address emerging threats and prevent or mitigate the impact of a cyber incident. Communication channels are often defined in the organization's general information security policy or its incident response plan. They are designed to notify employees when there is the potential of a cyber incident occurring, when a cyber incident is currently occurring, or when a cyber incident has occurred. Efficient communication provides situational awareness throughout the workforce. Such notifications can range from a warning about a phishing email to an alert for employees to not turn on their computers because there is a wide-spread ransomware incident that is ongoing.

Most of the time, the organization will use email to communicate; however, in the case of a wide-spread ransomware event, employees may be greeted with locked doors and paper notes warning them to avoid turning on their computers. This is exactly what Norsk Hydro employees encountered at their headquarters when they arrived for work on March 19, 2019 (Figure 7.4).

FIGURE 7.4 Notes employees of Norsk Hydro encountered when arriving to work at their HQ in Norway on March 19, 2019

Source: TERJE PEDERSEN / AFP / Getty Images.

The ability to communicate cyber risk concerns with external partners is also vital. Security regulations worldwide have different reporting requirements from HIPAA and CCPA in the United States to GDPR in the European Union. Failure to disclose cyber incidents with appropriate depth, response, and timeliness may result in significant fines from multiple entities. Other external communications include bi-directional communications with third-party service providers, especially when they are hosting critical data and they have encountered a major incident that may put that data at risk. Pre-scripted Public Relations communication plans to support disclosing a major cybersecurity incident to the public are a must.

Reports on Risk, Culture, and Performance

Organizations need to stay abreast of cybersecurity-related regulatory reporting requirements. High profile breaches such as Equifax, Uber, and Verizon, and the privacy concerns raised by the Facebook/Cambridge Analytics scandal, have lawmakers calling for stricter regulations to protect user data and minimize the impact of such incidents. In the United States, as of 2020, Congress has failed to pass any meaningful, comprehensive cybersecurity regulation, so organizations have to contend with a hodge podge of overlapping laws and standards at both the industry and state level. For instance, HIPAA regulates the healthcare industry, and the FERC/NERC CIP standards regulate the power grid (via the Energy Policy Act of 2005).

At the state level, just about every state and the District of Columbia have passed their own data breach notification laws. Finally, there is now GDPR, the legal framework that governs data security and privacy for EU citizens at a global level. Although GDPR is a European- based regulation, every company that collects data from an EU citizen, regardless of whether it is based in the EU, is in scope. The Securities and Exchange Commission has released various regulations and guidance for public organizations. With all of these different laws, regulations, and standards flying around, it is just about impossible for an organization to keep track of them all. Unfortunately, we do not anticipate a consolidation of these laws and regulations soon, so be sure to cozy up with your legal teams to stay in front of it all!

Organizations must implement a process for relevant and timely reporting of pertinent cybersecurity risks at all levels. These levels may include the cybersecurity team, the ERM team, horizontal business units, the executive leadership team, the board of directors, external third parties, and external regulators.

Many crisis communications publications state that crisis communications should contain the “Five W's” (Who, What, When, Where, and Why). Each of the “W's” may not be practical every time. For instance, at the beginning stages of a cyber incident, you may not know exactly “who” is affected, but you want to communicate regardless proactively. The point is to have a communications plan. Having these communications plans in place before the communication needsto occur is an important, yet often overlooked, part of an organization's ERM program. Sample communications can be found at www.CISOEvolution.com.

Application

One of my clients services the energy sector. There was a new CIO on-board and mostly new company leadership. The new CIO had three major concerns:

1. Sensitive information leaving the company

2. Inadequately protected industrial control systems

3. Convincing his boss (the CEO) and the board of the risks

After an initial assessment of the situation, we immediately established a cybersecurity steering committee. We developed a charter and had the CEO sign it, which legitimized the steering committee with support from its top executive. It also demonstrated the new leadership's commitment to establishing a strong security culture.

As a result of the CEO's executive endorsement, we swiftly leveraged the CIO's “new guy card” to bring in people from different business units. We were even able to recruit a representative from operations, which was vital to overcome previously fractured organizational collaboration. In this context, the operations team is the team that was responsible for the organization's industrial control systems (ICS). At the first steering committee meeting, we established the NIST Cybersecurity Framework as the foundation of the cybersecurity program. Consequently, we asserted clear expectations for IT, cybersecurity, and the various business units. We expected engagement and input, which we already considered a small victory, given that everyone showed up to the first meeting!

Once we established the ground rules, I launched two efforts in parallel. The first was a security awareness campaign to make people aware of best practices, expectations from a cybersecurity standpoint, and explain the cybersecurity implications in the context of business performance. The second effort was conducting an assessment to benchmark the organization's cybersecurity capabilities. This benchmark was important because it allowed us to eventually establish the measures we would use to track and communicate improvement. Part of this initial benchmarking also included conducting a business impact analysis (BIA) to understand the areas where a cybersecurity incident would have the most significant impact. This process brought clarity to the business units where we should focus our efforts. It also highlighted areas where the organization previously deprioritized for the wrong reasons, including corporate politics. As an unbiased outsider, I was able to elevate this discrepancy to the steering committee and integrate these neglected areas into our efforts.

I then dug into the risk assessment. The organization never completed a cyber risk assessment before now, so I did not have a previous risk inventory upon which to build. My understanding of the industry and the organization's business context allowed me to work with key areas to conduct a threat modeling exercise. The CIO used our initiatives to politically free up some funding for an external red team exercise. This funding was hugely beneficial as the combination of the red team exercise and threat models informed the risk inventory.

After we established the risk inventory, we embarked upon prioritizing the risk based on the resulting risk exposure. Now, we encountered a wrinkle. The organization had never established risk appetite or risk tolerance down to the unit level. There was a general understanding that the organization was not particularly risk averse. Unfortunately, that “gut” feeling did not help us draw the line at which risks to avoid, mitigate, transfer, or accept, so we had to go back to the CEO, who then worked with the board to establish a risk appetite statement with some loose risk tolerances we could use. With these guardrails, we could conduct a cost/benefit analysis to determine the best risk treatment plan for each risk and develop a “right-sized” 24-month roadmap with cybersecurity investment recommendations and associated corrective action plans (CAPs). We then determined the appropriate KRIs and KPIs that we could use to measure the effectiveness of our risk treatment decisions. Eventually we would be able to demonstrate improvements in a measurable way to communicate back to the executive team what they were getting in return for their investment.

We worked with each business unit's representative on the steering committee to frame, assess, and report cyber risk in the context of their unit. We were able to work with the individual business units to normalize cyber risks with their unit-level risks and then report those risks to the higher-level ERM group. Once we did that, the cyber risk trends across the business became apparent, so we were able to work with the ERM group to aggregate and prioritize those risks in the context of the broader enterprise risk register. Before we knew it, we developed a portfolio view of risk for the organization that, for the first time, included cyber risks.

Now, we had to get funding from the board, and we did, for most of the items in the roadmap. Everything is a negotiation, right? Alongside the CIO, we presented our case to the board in terms they could digest – which, by the way, DOES NOT include talking about how the latest zero-day attack can embed itself into the control system firmware to do bad things.

Because we could speak in terms of risk to the business and show that we had the support of every business unit, we received funding and resources to allow the CIO to start executing on the roadmap. It turned out the CIO was right. We were able to demonstrate that, in fact, sensitive information was leaving the organization and that the industrial control systems were inadequately protected. Most importantly, we were able to secure the funding to mitigate both of those risks, among a host of others.

For this organization, we successfully used the COSO framework to enable exponential growth in their cybersecurity capabilities from a people, process, and technology perspective. We were also able to provide a method to measure the effectiveness of cyber risk investments, develop a framework for continuous process improvement, foster better partnerships across IT and other business units, particularly operations, and ingrain a security culture across the organization.

Key Insights

· Understand how and when to trigger the evaluation of risk. The BIA is foundational to a complete evaluation of cyber risk as the valuation of assets and key dependencies are key considerations of the risk assessment.

· Determine the right mix of qualitative and quantitative risk assessment approaches for your organization. Don't get paralyzed by this as you can always add quantitative analysis to a qualitative analysis later. Consider your audience and culture.

· What does your ERM team already do?

· Are there opportunities to improve?

· Do you have the political capital to challenge the status quo?

· Work with your ERM team to prioritize risks but be mindful of biases that may skew your estimates.

· Use the cost-benefit analysis methodology covered in Chapter 5 – Cyber Business Case Development to determine the appropriate risk response, the most cost-effective risk treatment to minimize residual risk, and the appropriate security controls to design and implement to accomplish the desired risk response.

· Work with organizational leadership to get ownership buy-in and accountability for continuous risk management and mitigation.

· Have small, in-person conversations with potential advocates, explain to them your goals, and work with them to make them feel empowered and part of the process.

· Score quick wins. What does a minimal viable product look like for continuous risk management within your organization? Is there a specific business-unit, product, or process you can focus on first? Execute your plan successfully to gain broader support.

· Develop KPIs and KRIs that allow you to monitor risks and then leverage the relationships that you build with organizational leadership to communicate those risks with risk owners to ensure risks remain within the organization's acceptable risk appetite.

· Understand your organization's strategic goals and make risks from the risk register that directly impact the ability of your organization to meet those goals.

· Take lessons from well-known process improvement methodologies, such as Six Sigma, to iteratively measure and improve cyber risk management practices.

· Identify how and when to communicate cyber risk information to internal and external stakeholders by understanding cybersecurity regulatory reporting and disclosure requirements for your organization. Develop a tailored crisis communication plan before it is needed. Drill your crisis communications plan through designed and scheduled exercises.

Notes

1. 1 World Economic Forum, The Global Risks Report, 2019, 1–114. http://wef.ch/risks2019.

2. 2 Ponemom, I., Cost of a Data Breach Report 2020, IBM, 2020. https://www.ibm.com/security/digital-assets/cost-data-breach-report/#/pt.

3. 3 Verizon, 2021 Data Breach Investigations Report, 2021. https://www.verizon.com/business/resources/reports/dbir/.

4. 4 COSO, Enterprise Risk Management – Integrating with Strategy and Performance, Committee of Sponsoring Organizations of the Treadway Commission, 2017.

5. 5 Paulson, C., Boyens, J., Bartol, N., and Winkler, K, “NISTIR 8179 Criticality Analysis Process – Model Prioritizing Systems and Components,” NIST Internal Report 8179, 2018.

6. 6 “Managing Information Security Risk,” NIST Special Publication 800-39, 2011. https://doi.org/10.1108/k.2011.06740caa.012.

7. 7 “Penetration Test,” Wikipedia. Accessed October 7, 2020. https://en.wikipedia.org/wiki/Penetration_test.

8. 8 “Red team,” Wikipedia. Accessed October 7, 2020. https://en.wikipedia.org/wiki/Red_team.

9. 9 “Cyber Threat Hunting,” Wikipedia. Accessed October 9, 2020. https://en.wikipedia.org/wiki/Cyber_threat_hunting.

10. 10 Sanchez, R., and Enrique, J., ISO/IEC 27005:2018 Information Technology – Security Techniques – Information Security, 2018.

11. 11 Hubbard, D.W. and Seiersen, R., How to Measure Anything in Cybersecurity Risk, John Wiley & Sons, 2016.

12. 12 Hubbard, D.W. and Seiersen, R., How to Measure Anything in Cybersecurity Risk, John Wiley & Sons, 2016.

13. 13 Hubbard, D.W., Calibrated Probability Assessments: An Introduction, 2019. http://www.hubbardresearch.com/wp-content/uploads/2019/06/Introduction-to-Calibrating-Probability-Assessments-Hubbard-Decision-Research.pdf.

14. 14 COSO, Enterprise Risk Management – Integrating with Strategy and Performance, Committee of Sponsoring Organizations of the Treadway Commission, 2017.

15. 15 COSO, Enterprise Risk Management – Integrating with Strategy and Performance, Committee of Sponsoring Organizations of the Treadway Commission, 2017.

16. 16 Bresnahan, E., “Map Your Cyber Risks to Business Outcomes with KRIs,” https://www.cybersaint.io/blog/map-your-cyber-risks-to-business-outcomes-with-kris.

17. 17 Boehm, J., Curcio, N., Merrath, P., Shenton, L., and Stähle, T., “The Risk-based Approach to Cybersecurity,” McKinsey Insights, October 2019. https://www.mckinsey.com/business-functions/risk/our-insights/the-risk-based-approach-to-cybersecurity.

18. 17 Beasley, M.S., Branson, B.C., Hancock, B.V, and Landes, C. (2010), “Developing Key Risk Indicators to Strengthen Enterprise Risk Management,” COSO – Thought Leadership in ERM, 1–20. papers2://publication/uuid/A17DB7CA-6EC5-4F23-84FE-DB4996794C37.

19. 19 Thomas, J., “The Value of Linking Six Sigma to Your Sales Process – Training Industry,” 2017. https://trainingindustry.com/articles/sales/the-value-of-linking-six-sigma-to-your-sales-process/.

20. 20 Villanova University, “What Is DMAIC Methodology and Why Is It Important to Six Sigma?” Accessed October 23, 2020. https://www.villanovau.com/resources/six-sigma/six-sigma-methodology-dmaic/.

21. 21 COSO, Enterprise Risk Management – Integrating with Strategy and Performance, Committee of Sponsoring Organizations of the Treadway Commission, 2017.

22. 22 Morgan, S., “Global Cybercrime Damages Predicted to Reach $6 Trillion Annually by 2021,” 2017. https://cybersecurityventures.com/cybercrime-damages-6-trillion-by-2021/.

23. 23 Johnson, E.M., “Cyber Attack, Hurricane Weigh on Fedex Quarterly Profit,” Reuters, 2017. https://www.reuters.com/article/us-fedex-results/cyber-attack-hurricane-weigh-on-fedex-quarterly-profit-idUSKCN1BU2RG.

24. 24 Olenick, D., “Atlanta Ransomware Recovery Cost Now at $17 Million, Reports Say,” SC Media, 2018. https://www.scmagazine.com/home/security-news/ransomware/atlanta-ransomware-recovery-cost-now-at-17-million-reports-say/.

25. 25 Ashford, W., “Norsk Hydro Cyber Attack Could Cost Up to $75m,” 2019. https://www.computerweekly.com/news/252467199/Norsk-Hydro-cyber-attack-could-cost-up-to-75m.