In The Boscombe Valley Mystery by Arthur Conan Doyle, Sherlock Holmes comments that, “There is nothing more deceptive than an obvious fact.” When it comes to risk, it’s obvious that companies should want to remove or reduce risk as much as possible. But the process – how you actually carry out the actions to eliminate risk, and how you collaborate to make that risk reduction work across the business – is not obvious. To improve this, we have to look at how we consider risk across the whole organization. This requires a Risk Operations Center, or ROC.
Chief Risk Technology Officer for Qualys.
What’s in a name?
When CISOs hear the phrase “Risk Operations Center” they invariably ask, “How is a ROC different from a Security Operations Center?” Let’s begin answering this question with a concise definition for what a ROC aims to achieve: A ROC orchestrates risk elimination.
I can hear risk purists objecting, “You can never eliminate risk – only control it!” I have two responses. First, I was being purposefully terse as a means of easing readers into a fuller definition. Second, I suspect objections stem from not completely aligning on terms. Let’s fix that by defining what I mean by risk and elimination.
For the definition of risk I will turn to How To Measure Anything In Cybersecurity Risk: “Risk is a state of uncertainty where some of the possibilities could lead to loss, catastrophe, or some other undesirable outcome.” Here is a thought experiment: If you completely remove your uncertainty, have you eliminated risk?
Imagine I am driving an SUV. I’ve just been told there is a small tunnel ahead. I don’t know what small means in this context. I just know I’m driving a high occupancy vehicle full of children and my spouse. I’m now uncertain if my vehicle will fit. As I approach the tunnel I see a sign overhead that says the tunnel is twenty feet by twenty feet – and I can also clearly see that my SUV will fit. Using “measurement” I just eliminated my state of uncertainty about possible future “loss, catastrophe or some other undesirable outcome.”
Risk measurement moderates our uncertainty. We define risk measurement as, “A quantitatively expressed reduction of uncertainty based on one or more observations.” In the case of tunnel versus SUV, my state of uncertainty was reduced 100%. Unfortunately, in business environments, not all risks are this cut and dry or easy to understand with one fact. This is why we need to clarify what elimination means.
For elimination I’m using its “risk oriented” word origin. In Latin, elimination is “ex limine.” The “ex” means “off or out.” And “limine” is limit or boundary. In short, to eliminate risk is to set a boundary or limit that should not be exceeded. This ties nicely with the concept of a cyber insurance limit and risk tolerance. Indeed, a limit is a mathematically unambiguous and contractually binding expression of business risk tolerance.
With our terms defined I can expand my overly pithy ROC definition to something acceptable even by the most ardent of risk purists: “A ROC continuously orchestrates the remediation, mitigation and or transfer of cybersecurity risk that may exceed business tolerance.”
What differentiates a ROC to a SOC is that the SOC is specifically focused on security alerts and managing responses to issues within the technology stack. A ROC, conversely, takes all that information and provides it to the whole business, including finance and compliance leaders, so the organization can manage and understand risk mitigation in that wider context.
What’s a ROC platform?
I have the unique pleasure of engaging with CISOs and their teams around the globe on all things cybersecurity risk management. A growing majority of enterprise level CISOs are attempting to stand up DIY ROCs, because they have to put risk into that wider business context. Perhaps you are one of these CISOs. How might you know?
One of the first tells for this approach is that you are aggregating comprehensive “Risk Data” into a data lake, so you can make sense of that data for risk purposes. This includes a complex approach to handling data so that it can be used, from de-duplicating IT asset records to consuming full-stack vulnerability data and rationalizing disparate scores for those assets over time. This includes integrating multiple threat intelligence feeds and correlating compensating controls for risks that cannot be fixed immediately. Alongside this, you may look at how to use this data to trigger automated mitigation and remediation actions, whether that is through patching or deploying best practice deployment frameworks.
If you answered yes – even in part – then you are likely embarking on your own ROC journey. It’s a non-trivial DIY proposition. Consider that the average enterprise level firm has 76 security tools deployed, according to Panaseer. Getting each stage of this process right with each investment would most likely be out of reach, even for those with outsized budgets.
It is also essential to distinguish risk data from security data, as they should be purposefully thought of differently. I distinguish “risk data” from threat oriented “event data” that materializes in your SOC. SOC event data consists of streams of arrival time stamps with light weight meta-data. Due to its volume and millisecond velocity it’s invariably light on context. Event data is best persistent and modeled via time series data structures and related analysis. This is similar to what is used in real-time trading and network analysis. It’s for specific IT security decision making around threats.
Risk data is the other end of the spectrum when it comes to context. Consider all the rich content and context that you are putting in place around those IT security signals so that other teams can use it, and how it turns into understandable metrics for the board.
At the same time, all this analysis and reporting is usually done in some form of OLAP structure enriched with high context graph connected data. Indeed, graph comprehension is a must as cloud native data and other ephemeral “assets” aren’t IP addressable. The days of first and third party assets always being tied to a machine – and its IP – are fading. It would seem that the only thing the industry can agree on when it comes to assets is that they are probably nouns.
You can still do time series analysis with ROC data. You would do this to baseline metrics and do other forms of change analysis. The event grain for ROC data is not meant to duplicate log aggregation and/or observability solutions that back-end SOC systems create and consume. The ROC – and the data it provides – will carry out sophisticated analysis around potential risks and responses, but that complexity will be hidden from view so that the emphasis is on protecting value and reducing potential loss.
What’s different around risk?
The ROC actually sits at the nexus of value and loss exposure. Consider that a successful business is in the business of exposing more value, to more people, through more channels with higher velocities. In other words, businesses want to make more revenue and more profits. You can call this “digital and AI transformation,” but it is a process that every business will go through in the pursuit of growth. At the same time, any new venture or investment increases the potential risk back to the organization. In this sense, successful businesses are risk exposure machines.
The ROC is in the center of risk flowing into and out of your “risk surface” where value flows in and losses flow out. The ROC controls the “loss exposure” portion of that flow. It does that using both sentient and or artificially intelligent means of risk analysis. That analysis in turn automates actions (or enables workflows) for remediation, mitigation and risk transfer. Remediation and mitigation are controlled within the attack surface domain.
Alongside these technology elements, there are other controls that you would implement, like cyber insurance to transfer potential risk response outside the business, which is within the broader risk surface domain. This combination of security measures and cyber insurance for response is where you can take practical, proactive steps as a defender and invest in capabilities for controlling loss.
Are you ready to ROC?
The ROC is not your SOC. They work together but at different levels of your overarching risk surface. The SOC exclusively operates on event data within the attack surface domain. And the ROC? It continuously orchestrates the remediation, mitigation and or transfer of cybersecurity risk that may exceed business tolerance.
The interesting news is that enterprises are already feeling their way towards this concept of the ROC as they try to implement more effective risk controls. The challenge is that implementing a ROC is still at the early stages of development, where DIY approaches are still nascent and partial compared to what companies actually need. Assembling ROC will depend on collaboration between those within companies – CISOs, CFOs and compliance in particular – but also between peers and vendors.
According to the Risk Management Association, cybersecurity risk is the number one issue that companies face in the coming years. The rise of cyber risk quantification continues to help in this process, yet many of these projects will fail because they do not get the right support or deliver effective risk data that the business can use. To overcome this challenge, ROC deployments ensure that risk data can be used to control and respond to risk as part of that wider business approach. Where the SOC should deliver insight for security operations, the ROC should deliver risk operations that cover the whole business.
We’ve featured the best encryption software.
This article was produced as part of TechRadarPro’s Expert Insights channel where we feature the best and brightest minds in the technology industry today. The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: https://www.techradar.com/news/submit-your-story-to-techradar-pro