Part II - Choosing Cyber Battles 

Blog Series - Clearing Obstacles to Risk Accountability 

This blog series is a four-part discussion on observed challenges businesses will face in understanding and addressing cybersecurity risk. This is Part II - Choosing Cyber Battles. 

*No AI was used to generate this content. 

Risk Workflow 

There’s an easy way to perform a quick risk assessment. It won't meet your compliance requirements, but it will help put things into context. A risk assessment may take months to complete, but what if you could get most of the way there in a few seconds? Try this out.  

In simple terms, a risk assessment is an exercise that determines what goals and objectives are most important to a business and what systems support the achievement of those goals and objectives. Also, it accounts for the quantity and sensitivity of data generated within the systems. Finally, it determines what is in place to protect the data, system, and ultimately business objectives.  

We can quickly get to an understanding of what is most important by answering the following questions. 

1. What are my most critical business processes? 
   1. What information system(s) support the business processes? 
2. What type of data is generated for this business process? 
   1. Are data and system confidentiality needs high?  
   2. Are data and system integrity needs high? 
   3. Are data and system availability needs high? 
3. How much data is stored and processed through the most critical systems? 
4. Who may access this system and does the data sprawl to other systems?  
5. What cybersecurity best practices have I implemented to protect the confidentiality, integrity, and availability (CIA) of the system and data?

Consider the attributes of a high-risk system: Business critical, high CIA needs, non-public information, user sprawl, data sprawl, and missing cybersecurity protections. 

Weighing Options 

There are four scales of measurement for statistical analysis. In the purview of risk, we want to achieve risk awareness in the Interval Scale and Ratio Scale. The Interval Scale allows for the quantification of risk scores and the Ratio Scale measures the qualification of risk values against each other. Risk is considered on a sliding scale, where our actual risks are clear in value and relative position.  Interval is a determination of where on the chart risk falls and Ratio measures which one is more significant than the others. Use the heat map below as a visual example. We can see three risks where one is more significant and on the higher end of the risk scale than the others. We'll want to place our time, attention, and resources here. 

Level of Effort vs Return on Investment 

With a clear picture of where a risk falls on a sliding scale, we can start making informed decisions to reduce it. However, implementing cybersecurity best practices to reduce risk comes later in risk treatment. Before remediation, considerations should be made regarding the efforts needed, resource allocation, prioritization, and the return on investment.

After prioritizing, the enterprise should determine who will own the risk. The enterprise should determine if risk can be mitigated internally or by a third party. For many companies, it’s efficient to find risks that can be reduced internally and to avoid adding additional costs to their bottom line. 

Common sense says we’ll pick the highest-risk items with the lowest level of effort to mitigate. Through this process, a company will realize this approach is useful until it’s not. Eventually, the internal Level of Effort will become inverse to the Return on Investment.  

Here’s why: 

• Remediating a risk may require a high level of technical proficiency that does not exist internally in the company. 
• Remediating a risk may require a consistent process to implement adequately. Inconsistency will result in unrealized and neglected risks. 
• Remediating a risk may require the implementation and maintenance of systems and software. This comes with associated costs and resource allocation for management of the system. 
• Remediating a risk may become a distraction to business goals and objectives. 
• Remediating a risk may create a material impact on the company's bottom line and economically it becomes unviable. 

Compliance Doesn’t Care 

Compliance does not care when a business arrives at this point, however, risk is forgiving. We can use a risk-based approach to address this issue. The National Institute of Standards and Technology (NIST) Special Publication 800-39 (Managing Information System Risk) discusses the concepts of risk tolerance and acceptance after risk treatment has been applied. Risk treatment allows for risk transfer and sharing. Here, we arrive at a place where the most difficult, time consuming, costly, and frustrating risks can be offhanded to a capable third party. As a side note, modern day compliance frameworks like CMMC do not take this approach. There is no room for risk tolerance and every control must be implemented to become compliant. 

Risk Transfer & Sharing Fallacy 

NIST Special Publication 800-39 gently alludes to a risk transfer fallacy, but the quick nod doesn’t do it justice. The framework mentions that risk transfer is an entire transfer of risk, but this is not possible. It allows for the transfer of a piece of the whole, but in practice, risk managers may mistakenly transfer the entire risk pie. This action produces undesired results, such as a lack of risk clarity, unrealized risks, and neglected risks. “They are doing it for us, right?”  

Risk Sharing is the better option because it ultimately empowers the company. Whereas unclarity of risk creates uncertainty and the inability to mitigate effectively. When a company shares risk with a capable third party they take the risk back at the end of the mitigation cycle. What does this look like? 

1. The company has access and insight into 3rd party actions and risk-reducing activities. 
2. The company understands the outcomes of how risk has been mitigated. 
3. The company determines if the risk mitigation strategies of the 3rd party are effective and sufficient. 
4. The company chooses to continue the relationship or terminate the relationship depending on the above.  
5. The third party conceptualizes, visualizes, and communicates risk reduction and residual risk with stakeholders.  
6. The company accepts risk or implements plans to further mitigate the risk. 

Risk transfer skips all these steps. Thus, the fallacy expresses itself through a lack of due diligence.  

Advice for Sharing Risk 

As a company’s cybersecurity program matures, it will eventually reach a point where offloading risk to a third party may be the best option. Compliance does not care or instruct on how to manage this scenario. Luckily, risk is forgiving, and guidance is well documented in NIST’s industry-standard documentation outlining the management of risk for information systems. NIST suggests risk transfer and/or sharing. Sharing is the better option because it empowers the company to make effective decisions regarding their risk. Whereas transfer often results in neglected and unrealized risk.  

When a company uses risk sharing, they can ask questions to ultimately own the risk.  

• How will I know if the provided services are effective? 
• What is our communication frequency? 
• What reports, stats, or outcomes can I expect? 
• Who is your best conversationalist who can help me understand? 
• How can software be leveraged to communicate the effective reduction of risk? 

How does RADICL address the Risk Sharing Fallacy? Full and utter transparency into the work and actions performed on behalf of your enterprise. We use end-to-end case management which contains all work performed, analysis notes, evidence, and conclusions based on an investigation. That’s just the vSOC core service, every feature and extension of the platform is built off this concept – Harden, Aware, Hunt, and Comply. You have the right to know. Stack a little AI on top of that and you've got an informed support assistant that can provide quick insights into what is happening on your behalf.  

Up Next 

We just learned that risk-based decision making is the best way forward for a cybersecurity program. In the next blog post, we'll discuss what happens when risk is not the driving factor. Up next - Expressions of Fear-Based Cybersecurity.