OT/ICS Cybersecurity

Over the past few years, Hexagon has conducted numerous vulnerability assessments across various sectors. This has included the metals, mining & minerals, oil & gas, power generation, pulp & paper, and chemical industries. Within these fields’ operating facilities, we've analyzed millions of unpatched vulnerabilities. Here, some common themes have emerged: there's no shortage of vulnerabilities, resources are insufficient to address them, and there’s often no clear ownership or process to triage and prioritize mitigation and remediation efforts. This leaves operators with tens to hundreds of thousands of vulnerabilities but no clear strategy on where to focus. As a result, many customers default to using the CVSS score as the sole means of prioritizing actions.

I've written extensively about how the primary goal of any security program is to mitigate risk to an acceptable level. I've also discussed how traditional patch management—driven by vendor bulletins—often results in a lot of work with minimal actual risk reduction. When applying the basic risk equation, Risk = Likelihood x Consequence, it's clear that too much energy is spent on tasks that don't significantly reduce risk, while processes that could make a real impact are neglected. This is the truth, yet as an industry, we're still struggling to see the bigger picture—we can’t see the forest for the trees. The sheer volume of vulnerabilities blinds us to the actual risks. 

So much time is spent identifying, evaluating and prioritizing vulnerabilities, yet at the end of the day, many go unaddressed. I've seen this in various forms, from one extreme to another. On one end, there's the owner operator who tries to evaluate every CVE in their environment, only to find that the pace at which they can address them is slower than the rate at which new CVEs emerge. On the other end, some owner operators  do all the evaluation work but ultimately only implement vendor patch bulletins, generating lots of work with minimal risk reduction. If your approach is limited to following vendor patches, then a vulnerability assessment is pointless if you're not going to focus on reducing real risk. Conversely, if you're trying to keep up with every CVE, you're setting yourself up for failure.

Focus On What Matters 

I could share quotes like "It's not the load that breaks you down, it's the way you carry it" by Lou Holtz, or "The secret of getting ahead is getting started" by Mark Twain, or perhaps "Don’t be afraid to give up the good to go for the great" as said by John D. Rockefeller. But the best advice I can give you is to find the right balance. It's about applying 'broad strokes’—a general overview without getting bogged down in details—while recognizing that “different strokes for different folks" means what works for one situation may not work for another.

In other words, focus on what truly matters for your specific environment, and don't get caught up in the details that won't make a difference. You might be wondering, "This sounds good, but how do I actually put it into practice? How do I apply broad strokes for different folks?" It starts by using broad strokes to eliminate the things you know you won’t work on, freeing up time and energy to focus on actions that will genuinely reduce risk.

For those just beginning their journey, it’s easy to outline what you hope to achieve, but few actually get there. Yet, for those who have been on this journey for a while, it's often easier to define what they don’t want to become or do than to pinpoint exactly what they will do. For example, ask a child what they want to be when they grow up, and you'll get answers like "doctor" or "astronaut." Ask that same child in high school, and you’re likely to hear, “I don’t know.” However, if you ask that high schooler what they don't want to be, you’ll get very clear answers. 

ICS Vulnerability Strategies to Consider 

With that in mind, here are some recommendations for those who have been on this journey for a while.

• Patch Management: If you're only applying patches as recommended by vendors, acknowledge this upfront and suppress all vulnerabilities that require patches beyond those guidelines. This will save you time and effort on risk assessments for issues you won't address until the OEM advises. It’s not practical to evaluate the risk of something you’re not planning to change outside the usual patching process.
• Upgrade Strategy: If you lack defined budgets and processes for hardware and software upgrades in sync with your turnarounds or outages, be honest and suppress all vulnerabilities that require upgrades. This will eliminate a significant number of vulnerabilities tied to outdated browsers and obsolete technology. If updates aren't feasible, there’s no point in exhausting resources on vulnerabilities that won’t be resolved.
• CVE Prioritization: If you don’t intend to address CVEs with low or medium base scores, acknowledge it and suppress those vulnerabilities. If the base score alone disqualifies the work, there's no need to keep them visible. Most discussions around contextualizing vulnerability risk scores focus on reducing rather than increasing them. If you’re not going to act on it, it’s only cluttering your view and potentially hiding real risks.
• Isolated Equipment: For isolated equipment with CVEs that you don’t plan to address, be upfront and suppress those vulnerabilities, especially if the attack vector is network-based. The risk is relatively low, and the effort required is often disproportionate due to connectivity challenges and the absence of automated processes. The time-to-value comparison usually doesn’t justify the effort.
• Resource Constraints: If you have limited bandwidth and are struggling to avoid overburdening site resources, admit it and suppress all vulnerabilities without known exploits. Reducing risk takes effort, and it’s pointless to identify, evaluate and prioritize risks if no one acts on the data. With limited resources, it makes sense to focus on vulnerabilities that are actually known to have been exploited, which account for about a small percentage of the total vulnerabilities in OT/ICS environments. This approach dramatically reduces noise and allows your team to address real, actionable problems. 

I’m not necessarily suggesting you adopt all of these strategies in your ICS environments, but we need to start being honest about our capabilities, resources, and processes, and tailor our efforts accordingly. I understand the hesitation in generalizing about vulnerabilities or suppressing them—you might worry about missing a critical vulnerability on a key device, leading to significant risk. However, you're probably already overwhelmed with the massive task of assessing every CVE in your environment. The sheer volume of vulnerabilities in ICS environments means you’re likely overlooking or misjudging real risks while being bogged down by tasks you’ll never fully complete. This makes effective risk reduction nearly impossible. 

By using broad strokes to exclude the things you aren’t going to work on, you gain the clarity needed to properly identify, evaluate and prioritize the risks that truly matter—the ones that pose the most significant threats to your environment and that you are likely to address. As you start managing this volume of risk, you can begin adjusting your perspective on what you’re willing to tolerate and gradually expand your focus.