CVSS 3.1 Still Misses the Point for OT/Critical Infrastructure
Published on : Wednesday 25-09-2019
Recently, the FIRST organisation published the Common Vulnerability Scoring System or CVSS 3.1 standard and guidelines outlining a number of changes that were rumoured to have an improved focus for Operational Technology (OT) and Critical Infrastructure. I admit that as a realistic cybersecurity enthusiast I was truly hesitant regarding the CVE/CVSS format and have pre-conceived notions that 3.1 would remain be inappropriate for industry environments.
Regardless, I went into discovery mode and attempted to keep my opinion out of the review, and moved to see how the new standard could be applied; especially in convergent environments where the most laudable changes in CVSS3.1 were by transitioning from risk-based scoring to one based on severity, and demonstrated considerations for improved respect for Environmental aspects [e.g., Operational Technology (OT) and the critical infrastructure space]. Given that OT environments have a number of considerations that are critical to be understood, most of the scoring framework’s improvements were tailored largely for the IT/Enterprise side.
Based on my interpretations when reading through the specification and user-guide, here is a synopsis of the currently released publications. Unfortunately, more expansive examples that may clarify particular use-cases will be updated later during 2019.
From an IT/Enterprise perspective, FIRST should be commended that they have created a standardised metric to score vulnerabilities for organisations such that they can be triaged, prioritised and engaged to be patched. For OT, patching is still an important part of any Vulnerability Management (VM) program, but many of these vulnerability scorings and the vulnerabilities themselves are quite difficult for asset owners to discern actual risk and efforts to remediate. With respect with FIRST, I’ll start with what I believe FIRST got right/sort of:
CVSS now looks at Severity vs. Risk – “the base score is clearly intended to be used to represent intrinsic characteristics of a vulnerability, which are constant in time &
environments”. Ignoring the negatives of looking solely at severity or assuming that a vulnerabilities criticality is constant over time, this is a double edged sword in the OT world.
The standard has updated definitions in relation to Attack Vector & Modified Attack Vector. While still not as impressive as MITRE's ATT&CK, in a world of grey areas and hybrid technologies – this is good news at least for cybersecurity professionals and risk management.
Scoring assumes vulnerable configurations by Default – As a primary position, this is an interesting and positive move towards removing some of the ambiguity surrounding CVEs. Nobody/no vendor can now say well if X system is configured this way, then this should lower the score because they SHOULD be following best practices... Worst-case is best-case at least at the numbers level, and PROPER risk management should account for “how do we handle this”.
Standard documentation expands guidance for vulnerabilities in libraries – Again another positive step towards handling edge-cases and managing vulnerabilities in an increasingly open/library driven development world. However, statically compiled binaries, especially in IoT/IIoT land may complicate this further and need to be expanded on.
Improved guidance for multiple CVSS scores and scope changes – Again, another idea from the FIRST camp that lends some credence to the standard’s scoring mechanism, however, I suspect that this would confuse asset owners, and while with best intentions, I think it can cause more harm/fatigue in environments with scant resources.
Improved definitions regarding Local vs. Network/Adjacent exploits – Self-explanatory, but the language in these sections doesn't bode well for chained vulnerabilities and properly examining risk. Proper Risk Management and multiple levels of compensating controls will need to be mentioned and considered (somehow).
Standard CVSS Extensions Framework – Another great addition, BUT, it is still mostly guidance... This feature might actually be among the most important and relevant for OT realm, but why can't this extension pattern be utilized today by an ISA/IETF working group. This represents a good opportunity for asset owners, researchers/academia government agencies and product owners to collaborate and standardise further.
Availability (from the CIA triad) acknowledges "operation of the service" – which could be potentially morphed into Operation of the process itself. While this blurs the lines of the standard’s guidance and definitions, it can lend some flexibility for convergent environments and offers a tipping of the hat to the needs of OT environments.
As with any framework or technology, the following bullet points outline several points that are generally considered negative:
CVSS 3.1 assumes detailed knowledge of a system by attackers – Given the various reasons for limiting controls and assumptions, this is a poor way to do so given the simplification and weaponification of exploits that can be easily provided to lay persons to execute.
Sarcastically, I didn't know that if someone is able to package and simplify a “complicated” exploit with various countermeasures that “Detailed Knowledge” is required. Of course we should assume script kiddies and copycats can easily exploit a variety of environments without detailed knowledge (and as we know, time to react to an incident is often astronomically high).
Environmental Security Requirements – In practice, this section is still too limited and does not lend itself well to the Potential to render consequences for Safety-Reliability-Productivity (SRP). Seems too driven for GDPR/privacy and healthcare data related items to me.
Scoring limits the scope too early in the CVSS Exploit Lifecycle – Ending the impact merely at “a successful exploitation of a vulnerability” is child's play; the reality is that at least one (1) or more vulnerabilities are combined in a chained/multi-staged attack. I understand the challenges, but I guess pawning it off onto Risk management is the solution.
CVSS is only for stand-alone vulnerabilities – Analysts are still required to understand how vulnerability A interacts with vulnerability B. There is far too much importance and burden to be placed on individuals involved in making adequate decisions in the critical environments (I sense another product/research opportunity here).
CVSS does not consider advancements and aging of scores – While some may say a CVE's score may not change over time, I'll disagree. As research/progress plough onwards and forwards, so do potential malicious actors. If a CVE is medium risk today, in three (3) years a particular score could be actually rated as high, but it was not updated to reflect such a change. In OT environments and where infrastructure cannot be updated regularly (or at all), this assumption is false.
Still doesn't work well for OT across the board unless at the fringes – End of story.
Overall, it was a solid incremental change, but for OT environments CVSS is still not the end all score to be used to adequate assess risk in control systems, process and infrastructure.
Fortunately, there exists some other great examples on considering CVE-like scores for ICS/OT by industry legends Billy Rios, Clint Bodungen and Art Manion, which is available on Youtube (S4x19 presentation “A New CVSS For ICS Vulnerabilities”). Conclusively, if you are an asset owner, or cybersecurity professional that works within the OT realm, understanding concrete and relevant vulnerability/risk scorings is paramount and requires copious amounts of tribal knowledge. For that, no single framework or score can be used as a sole source of understanding cyber risk of a vulnerability – it is only complementary and to be used as a guide for the appropriate individuals and teams.
Ron Brash is a Director of Cybersecurity Insights at Verve Industrial Protection, where he corroborates and injects cybersecurity knowledge trifold within 
the organisation, product and industry. Recently, he was a manager and SME at Deloitte LLP as part of their Canadian Cyber Risk Advisory practice based out of Montreal, Quebec, Canada, and focused on providing technical knowledge in the aviation security domain, selected ICS/SCADA topics, and advised on a number of technical areas ranging from technical risk assessments, security architecture review, OT SIEM integrations, and controls review. He was also an Embedded Developer at Tofino Security, a technology consultant for embedded ICS security devices, technical creator of the watershed S4 ICS Detection Challenges (x2) and is a cyber-threat researcher.
