bluebay2014 - Fotolia

Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

CVSS v3.0: What does Oracle's move mean for vulnerability assessment?

Oracle has moved from using a modified version of CVSS v2.0 to CVSS v3.0. Expert Michael Cobb explains criticism of the old version, and the changes in vulnerability scoring in v3.0.

With a recent patch update that addressed 136 different vulnerabilities, Oracle moved to the Common Vulnerability Scoring System version 3.0. The company had been using a modified version of CVSS v2.0, which some experts criticized. What are your thoughts on using modified versions of the CVSS, and what does Oracle's move to CVSS v3.0 mean?

Network administrators are inundated with software patches and updates. Prioritizing which patches are installed on which devices first is a key element of information security, particularly in today's fast changing threat landscape. The Common Vulnerability Scoring System (CVSS) provides a standardized methodology that captures the principal characteristics of a vulnerability and produces a numerical score reflecting its severity. It also creates a common reference language for security professionals, and makes it easier to share data across different vulnerability and security tools. Scores range from 0.0 to 10.0, with 10.0 being the most severe, and are calculated based on a formula that depends on several metrics used to approximate ease of exploit and the impact of the vulnerability.

CVSS helps prioritize risk and removes much of the confusion that arises when a vulnerability is assigned an arbitrary score by a third party. Since its initial release in 2005, CVSS has enjoyed widespread adoption. In September 2007, CVSS v2.0 was adopted as part of the Payment Card Industry Data Security Standard; merchants processing credit cards must demonstrate that none of their computing systems have vulnerabilities with a CVSS score greater than or equal to 4.0. Also in 2007, NIST included CVSS v2.0 as part of its Security Content Automation Protocol, and in April 2011, CVSS v2.0 was formally adopted as an international standard for scoring vulnerabilities.

A problem Oracle and other vendors face with CVSS v2.0 is accurately scoring vulnerabilities that would fully compromise their software, but only partially affect the host operating system, as vulnerabilities are scored relative to the host operating system. To overcome this shortcoming, Oracle has always provided severity ratings for bug fixes released in Critical Patch Updates and Security Alerts, using a proprietary "Partial+" metric value for when a vulnerability "affects a wide range of resources, e.g., all database tables, or compromises an entire application or subsystem." Oracle felt that in cases where a host's main purpose is to run a single application, a total compromise of that application warrants a higher score than it would be awarded under CVSS v2.0. While Oracle's scoring may better reflect the severity of a vulnerability and make prioritization of Oracle's patches against each other easier, it also made comparison -- and therefore prioritization of patches from other vendors -- less straightforward.

Version 3.0 of the CVSS standard addresses the partial+ problem with a new metric called Scope, so a software vulnerability's score can more accurately reflect an ability to impact a separate software, hardware or networking component. From April 2016, Oracle will be using CVSS v3.0 as it more closely matches its previous scoring methodology. As a result of this change Oracle expects v3.0 scores to be higher than under v2.0, as scores will be relative to the vulnerable component, not just the target host. Oracle's first Critical Patch Update using CVSS 3.0 also included v2.0 scores but future updates won't; there's more information about how Oracle uses CVSS here. The Forum of Incident Response and Security Teams, which is responsible for CVSS, provides a user guide and a CVSS Version 3.0 calculator.

CVSS is designed to assist with the prioritization of patches by scoring the criticality of a vulnerability, but no scoring system is flawless and no scoring system can replace common sense. Other factors have to be taken into account when scheduling and prioritizing patches, particularly system criticality -- the relative importance of the applications and data the system supports to the overall business, reboot requirements and patch installation complexity. Unfortunately, CVSS v3.0 has yet to see widespread adoption, and until it does, administrators will still find it difficult to directly compare the criticality of Oracle's patches with those from other vendors.

Next Steps

Learn how to rank enterprise network vulnerabilities for remediation

Compare the top vulnerability management tools for your organization

Find out the best practices for conducting an information security assessment

This was last published in September 2016

Dig Deeper on Microsoft Patch Tuesday and patch management