CVSS Scores: Is it effective for ICS Vulnerabilities in OT?

The usefulness of CVSS (Common Vulnerability Scoring System) is widely debated across the Operational Technology (OT) community because of its weaknesses in assuming detailed knowledge, environmental security requirements, depth of impact, inability to update over time, and focus on single vulnerabilities, as opposed to the effects vulnerabilities have on each other.

CVSS scores in OT environments

While the industrial industry relies on decades of progressive technology, it also has a stringent focus on Safety-Productivity-Reliability and financial feasibility. So, where does CVSS fit in, and how can we make it work for cyber security in a field dominated by OT?

A stronger standard metric for scoring vulnerabilities does not exist.  Whether you feel a CVSS score is useful or useless, it should be supplemented with additional techniques and mechanisms to improve the application of a score by security teams. Let’s take a look at the advantages and disadvantages of CVSS scores and CVEs when managing both IT and OT systems.

Benefits of CVSS scores

• Defines vulnerability vocabulary, nomenclature, and scoring. At a minimum, CVSS scoring is one of the few global practices that does not have multiple implementations. We should be thankful we can converse in the same language when discussing a flaw, at the basic level, regardless of region.
• Dictates a standardized practice and base metric across communities. Common best-practices state organizations and qualified professionals should provide guidance on severity and applicability of any reported vulnerability scores.
• Provides indicators of existing risks that need mitigation. Whether or not remediation is possible for any of the noted vulnerabilities (CVEs), their presence points to risks that should not be ignored, fixed/patched, mitigated with compensating controls, and at a minimum, managed/recorded in a registrar.
• Allows a glimpse into the world of software and systems development. The more applications, legacy Operating Systems, and configurations, the more conscious and vigilant an asset owner becomes when considering and managing risks.
• Provides extensive metrics for systems that transitioned from IT to OT. Given that many commodity systems have enabled OT to be more effective, or deemed appropriate for whatever reason, CVSS is another convergent metric that helps bridge the gap between the two worlds

Disadvantages of CVSS scores

CVSS downfalls are largely related to the differences in environments and how they are operated, engineered, and staffed. For example, to update a virtualized and distributed server in IT, a brief outage is scheduled and applied to the OEM patch during non-operational hours with a reasonable amount of caution.

In OT environments, physical servers require waiting until a scheduled downtime or site maintenance window to test and apply patches with a rigorous level of caution, if the patch is feasible at all. If an OT environment has strict compliance and regulatory needs, patches may need to be applied within a specific window of time, If a patch is applied, the environment may need to be re-certified, costing hundreds of thousands of dollars or a disruption that affects the site’s SRP.

A software fix or patch for a vulnerability reported as a CVE becomes operationally challenging unless using a solution appropriate to OT environments. But don’t forget, many devices and pieces of software have vulnerabilities, but they are undisclosed because they are unknown (zero-days) or neglected.

 CVSS scores do not account for the age of a vulnerability, nor its usage in a chain of exploits. A CVSS score is not concrete over time.

Patching concerns used to be dictated by the vendor and their ability to approve the fix. Today, solutions exist and work in many critical environments, largely solving the technical hurdle of patching OT hosts.  However, if vulnerabilities are reported constantly, how do we categorize, triage, and prioritize vulnerability management campaigns?

Let’s start with an example of a recent vulnerability from ICS CERT:

Several vulnerabilities are grouped together for this advisory, and it contains a CVSS 3.0 score of 9.8, which is very high and trivial to exploit remotely. Several mediations are offered, and there is insight into which systems were affected.

Vulnerability scores in IT vs. OT

A CISO in an IT organization, constantly combatting malware threats, phishing, and cloud/Internet-facing systems, would likely be worried and in need of a hastened response. But a site owner in an OT organization would question:

• What is the immediate need to patch? Does it fix an issue that affects the stability of my processes or the SRP of my assets? Or is it a nice-to-have at a later date, if I deem it necessary to patch at all
• Is this fix part of a cumulative fix (e.g., Windows 7/2008 onwards) and if so, will this patch rollup be entirely blacklisted if a single patch is incompatible? This is a huge unanswered question by vendors, integrators and application developers. If one update has thirty patches, but one is incompatible with X HMI software, what do you do? Do you blacklist all thirty fixes in the rollup because a single one does disqualify the rest?
• What are the negative affects of the patch? Do I need to re-certify, re-test, and schedule an outage if a patch even exists?
• What about unknown or undisclosed vulnerabilities? Devices running similar OS and software stacks have the same vulnerabilities seen elsewhere. The question becomes: Am I at risk of zero-days, or pre-existing exploits that are easily migrated to other devices, even if from different vendors?
• Is a high CVSS score relevant if I have a number of compensating controls in place? This could mean that the asset is behind several firewalls, access is highly restricted, systems are hardened, remote access is denied, etc…

The last point is the most important and most common to resonate with asset owners. Patch where you can, especially on commodity systems, and do so with relative ease. After all, most attacks come through applications and commodity Operating Systems.

The key question site owners should consider when managing the flood of vulnerabilities is the application of the vulnerability, the criticality of the host system, and the host system’s risk exposure.

We’ve shared resources on balanced risk exposure and quantifying risk in OT when numbers are scarce, but the next thing to calculate is the score of a vulnerability when prioritizing which vulnerabilities to patch.

You may calculate vulnerability scoring with a formula such as:

F(x) = (CVSS score) * (criticality of an asset to the org/process) * (potential impact to the org) * (exposure to potential exploitation) * (compensating controls)

• CVSS score – the score of the vulnerability between 0-10
• Criticality of an asset – a value between 0-1 that describes how critical the asset is to operations or to the organization
• Potential impact of an incident if exploited – a value between 0-1 that describes the level of impact severity it may cause to the organization if exploited successfully, by applying a fix, or having it fail and needing to “roll-back”
• Exposure to exploitation – a value between 0-1 that describes the level of risk an asset may have, e.g., lots of users, has access to email, limited network access control, legacy OS etc…
• Compensating controls – a value between 0-1 that attempts to quantify the existence of controls used to provide protections on an asset where vulnerabilities or threats are applicable

Using the resulting score, assuming it is not zero, (you should not use a minimum value of zero as no risk will ever fully disappear) map it to pre-defined criteria, matching ranges to a label.  (E.g., 0-3 is low, 4-5 medium, 6-7 high, 8-10 critical).

This may come across as an academic exercise, but this vulnerability scoring formula provides a foundational premise to build lists of assets classified by criticality. It also creates lists of patches to apply to hosts as part of a campaign or to determine mitigation measures for implementation.

Effective common vulnerability scoring systems

No common vulnerability scoring system will ever be perfect, but this is where additional advanced formulas, combined with tribal knowledge of the organization, become valuable. This is a good start to making CVSS scores work in OT as part of your vulnerability management program.

Asset owners should work with their teams to arrive at realistic CVSS scores that are consumed and prioritized when using a scoring framework augmented by a well-described algorithm. It is repeatable when parameterized correctly and appropriately tailored to your organization.

There is an upcoming opportunity to programmatically implement elements of this formula as part of a technology-assisted vulnerability management component for your cyber security program. Reach out to us learn more about making CVSS scoring less complicated and less work for your teams.