Understanding the Common Vulnerability Scoring System (CVSS): Part 1

Hi, this is Eric Maurice again!


Following the release of the October CPU (CPUOCT2007), it became clear that there was still a certain level of confusion and misunderstanding about CVSS and how it was implemented by Oracle.  Given this situation, I thought it might be helpful to further talk about CVSS, and specifically, the vulnerability scoring metholodgy implemented in the standard. 


The Common Vulnerability Scoring System (CVSS), initially announced in February 2005 on the U.S. Department of Homeland Security�s web site, is designed to �provide open and universally standard severity ratings of software vulnerabilities�.  Oracle was one of the first software vendors to adopt CVSS to provide a standard-based indication of the severity of the vulnerabilities fixed in its products.  Oracle has provided CVSS Base Scores in the risk matrices of the CPU documentation since the October 2006 Critical Patch Update (CPUOct2006).  In June 2007, FIRST (Forum of Incident Response and Security Teams) published the second version of the standards: CVSS 2.0, which was implemented by Oracle with the October 2007 Critical Patch Update (CPUOct2007).  Note that in this discussion, we will address the new CVSS 2.0 Scoring System if not otherwise noted


Since Oracle implemented CVSS, we periodically receive questions about how the CVSS base metrics scores are calculated.  Specifically, some people find it surprising that vulnerabilities deemed to be particularly critical receive a CVSS base score between 6.5 and 7.5 out of an absolute scale of 10.0.  Understanding the CVSS scoring system requires going back to the objectives of CVSS, and understanding the formulas behind the scores themselves.  In the first part of this blog series, we will be discussing the objectives of CVSS and how it affected the scoring of vulnerabilities


The CVSS web site states that the objective of CVSS is to provide a severity rating for all software vulnerabilities. 


This means that CVSS is designed to provide a numeric value (the score) indicative of the relative criticality of a given vulnerability regardless of the type of software it affects, whether it is an Operating System, antivirus, database, mail server, desktop or business application, etc.  As a result of this wide scope of applicability, the standard is intentionally designed to require a complete compromise at the Operating System layer for a given vulnerability to be given a base score of 10.0.  In other words, a vulnerability with a CVSS Base Score of 10.0 typically signifies a complete compromise of the system, that typically results in allowing the attacker full control, including administrative or �root� privileges at the OS layer.  An example of the impact of such a vulnerability in a third party product is reported on the National Vulnerability Database as �The attacker could then install programs; view, change, or delete data; or create new accounts with full user rights. 


Due to the nature of the Oracle bugs, vulnerabilities that could result in a complete compromise of the underlying server are rather rare.  In fact, since the CVSS scoring was implemented by Oracle, the highest-ever CVSS Base Score assigned by Oracle to a vulnerability addressed in the CPU would have been 7.5 if it had been scored under the CVSS 1.0 scoring system.  Note however that CVSS deals with single vulnerabilities, and does not completely account for �blended threats�, that is the combination of attack methods/vectors that could ultimately result in such a very extensive compromise.  It is therefore very important for organizations to patch all vulnerabilities as soon as possible, as leveraging various vulnerabilities across IT layers may result in a more complete compromise of the targeted system.


The CVSS system includes three types of score � Base, Temporal and Environmental.  Each is designed to measure different attributes of the vulnerability.  Oracle provides the �Base Score� in the CPU documentation.  It is characterized by the following aspects:

-         The Base Score is specific to a given vulnerability.

-         It does not change over time.  This is where the �Temporal Metrics� come into play to measure, for example, additional exposure resulting from the availability of exploit code. 

-         It is not specific to a customer�s technical IT environment.  This is where the �Environmental Metrics� come into play, to measure, for example, the likelihood of collateral damages to other systems and applications.


The CVSS documentation states that computing the Temporal and Environmental Metrics scores is optional.  While computing all three scores can provide a granular risk rating (specific to a given vulnerability in a specific environment at one point in time), most customers find this process to be too cumbersome, and they rely exclusively on the Base Score to assess the criticality of vulnerabilities and the priority given to patching them. 


Next week, we will be looking into more details on how the Base Score is computed using the �Base Equation� of CVSS.


For more information, see:

-         Oracle MetaLink Note 394487.1 (subscription to MetaLink required) explains Oracle's implementation of the CVSS standard

-         Oracle MetaLink Note 394486.1 (subscription to MetaLink required) provides a detailed explanation of Oracle�s risk matrices

-         The Critical Patch Updates and Security Alerts page on Oracle Technology Network provides detailed information about previously released CPUs and Security Alerts

-         The Guide to the Common Vulnerability Scoring System version 2.0 is available online, and it includes the scoring formulas set forth by the standard.



Post a Comment:
Comments are closed for this entry.

This blog provides insight about key aspects of Oracle Software Security Assurance programs.


« July 2016