Humans have been measuring risk since the dawn of time. “I’m hungry, do I go outside my awesome cave here and forage for food? There might be something bigger, scarier, and hungrier than me out there…maybe I should wait?” Successfully navigating through life is a series of Risk/Reward calculations made each and every day. Sometimes, ideally, the choices are small (“Do I want fries with that?”) while others can lead to catastrophic outcomes if the scenario isn’t fully thought-through and proper mitigations put into place.

Several years ago, Red Hat began publishing a CVSS score along with our own impact rating for security flaws that affected Red Hat products. CVSS stands for Common Vulnerability Scoring System and is owned and managed by FIRST.Org. FIRST is a non-profit organization based in the United States, and is dedicated to assisting incident response teams all over the globe. CVSS provides a numeric score of a vulnerability ranging from 0.0 up to 10.0. While not perfect, it is additional feedback that can be taken when trying to evaluate the urgency with which a newly-delivered patch must be deployed in your environment. The v2 incarnation of the system, while a nice move in the direction of quantitative analysis, had many rough edges and did not accurately depict many of the more modern computing scenarios under which our customers deploy technology.

Last year, in 2015, the FIRST organization, stewards of the CVSS scoring system (along with several other useful assessment tools) published the next generation of CVSS: version 3. v3 gives a security practitioner better dials and adjustments to get a more accurate representation of a risk presented by a software flaw. Using CVSS v2, it was challenging to express how software was vulnerable when the underlying host/operating system was only partially/minimally impacted. CVSS v3 addresses this issue with updates to improve the possible values for impact metrics and introduces a new metric called Scope.

An important conceptual change in CVSS v3 is the ability to score vulnerabilities that exist in one software component (now referred to as the vulnerable component) but which impact a separate software, hardware, or networking component (now referred to as impacted component).

It is important to note that Red Hat uses CVSS scores solely as a guideline and we provide severity ratings of vulnerabilities in our products using a four-point scale based on impact. For more information specific to how Red Hat rates flaws (which also illustrates how we use CVSS as a guideline) please see: https://access.redhat.com/security/updates/classification/ .

CVSS v3 now also provides a standard mapping from numeric scores to severity rating terms: None, Low, Medium, High and Critical. These numbers are very useful in starting to understand the risks involved, but ultimately they are one of several factors that goes into Red Hat’s severity rating, which may not always dictate what the final rating is.

The Base Metrics now are:

• Attack Vector (AV) – Expresses the “remoteness” of the attack and how the vulnerability is exploited.
• Attack Complexity (AC) – Speaks to how hard the attack is to execute and what factors are needed for it to be successful. (The older Access Complexity metric is now split into Attack Complexity and User Interaction.)
• User Interaction (UI) – Determines whether the attack require an active human to participate or if the attack is automated.
• Privileges Required (PR) – Documents the level of user authentication required for attack to be successful (replaces older Authentication metric).
• Scope (S) – Determines whether an attacker can affect a component that has a different level of authority.

It’s important to note that User Interaction is now separate from Attack Complexity. In CVSS v2 it was not easy to determine if there was any user interaction required from the attack complexity metric alone, but with CVSS v3, it’s scored as a separate metric, making it more explicit what part of the scoring metric is related to user interaction.

One question that must always be answered is, what kind of damage can be done if an attack is successfully executed? This is still measured by the CIA triad (Confidentiality, Integrity, Availability) however the values are now “None” to “Low” to “High” rather than “None” to “Partial” to “Complete” as they are in CVSS v2.

• Confidentiality (C) – Determines whether data can be disclosed to non-authorized parties, and if so to what level.
• Integrity (I) – This measures how trustworthy the data is and how far it can be trusted to not be modified by unauthorized users.
• Availability (A) – This metric is concerned with data or services being accessible to authorized users when they need to access it.

The CVSS v3 standard also has in it the ability to measure compensating controls that might exist in an environment, or based off of the timeline of the attack. These are measured in the Temporal and Environmental metrics. Red Hat cannot speak to countermeasures that may or may not exist in a customer’s network, and therefore will not publish scoring based on these dimensions. To truly measure the residual level of risk in your environment you may also desire to use those metrics to communicate vulnerabilities within your organizations.

Complete descriptions of the new metrics can be found at: https://www.first.org/cvss/user-guide.

When using these new criteria, Red Hat will continue to evaluate the risks that vulnerabilities bring based off of the context of how the flaw adversely affects the component in relation to other products. Sometimes Red Hat CVSS v3 scoring may differ from that of other organizations’ ratings. For open source software shipped by multiple vendors, the CVSS v3 base scores may vary for each vendor’s version, depending on the version they ship, how they ship it, the platform, and even how the software is compiled. This makes scoring of vulnerabilities difficult for third-party vulnerability databases, such as NVD, who can give only a single CVSS v3 base score to each vulnerability. More details can be found by reading CVSS v3 Base Metrics

To illustrate some of the differences between the old method and the new method, we provide the following examples:

Flaw type	CVSS v3 Metrics	CVSS v2 Metrics (for comparison)
Many XSS, CSRF	6.1/CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N	4.3/AV:N/AC:M/Au:N/C:N/I:P/A:N
NULL dereference	C:N/I:N/A:L	C:N/I:N/A:P
info leak	C:L/I:N/A:N	C:P/I:N/A:N
tempfile/symlink	C:N/I:L/A:N	C:N/I:P/A:N
most wireshark flaws	6.5/CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H	2.9/AV:A/AC:M/Au:N/C:N/I:N/A:P
most browser ACEs	7.3/CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L	6.8/AV:N/AC:M/Au:N/C:P/I:P/A:P
local kernel null ptr -> root	8.4/CVSS:3.0/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H	7.2/AV:L/AC:L/Au:N/C:C/I:C/A:C
local kernel DoS	5.5/CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H	4.9/AV:L/AC:L/Au:N/C:N/I:N/A:C
local network kernel -> root	8.1/CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H	8.3/AV:A/AC:L/Au:N/C:C/I:C/A:C
local network kernel DoS	6.5/CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H	6.1/AV:A/AC:L/Au:N/C:N/I:N/A:C
local kernel infoleak	3.3CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N	1.9/AV:L/AC:M/Au:N/C:P/I:N/A:N
remote kernel -> root	9.8/CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H	10.0/AV:N/AC:L/Au:N/C:C/I:C/A:C
remote kernel DoS	7.5/CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H	7.8/AV:N/AC:L/Au:N/C:N/I:N/A:C
wireshark buffer overflow	6.3/CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L	5.4/AV:A/AC:M/Au:N/C:P/I:P/A:P
wireshark null ptr deref	4.3/CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L	2.9/AV:A/AC:M/Au:N/C:N/I:N/A:P
root password leak	C:H/I:N/A:N	C:P/I:N/A:N
SSL cert verification issues	3.7/CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N(typical, I:L)	4.3/AV:N/AC:M/Au:N/C:N/I:P/A:N (typical, I:P)
Java deserialization RCE	7.3/CVSS:3.0/AV:N/AC:L/PR:N:UI:N/S:U/C:L/I:L/A:L	7.5/AV:N/AC:L/Au:N/C:P/I:P/A:P

For the JBoss Middleware suite, most scoring will be unaffected as the scoring for JBoss Middleware in CVSS v2 always related to the JBoss Middleware product itself, not the overall operating system. That won’t change with the introduction of the scope metric in CVSS v3. The scope of a vulnerability’s impact will be related to all things authorized by the system user running the JBoss Middleware product, not the Java Virtual Machine, or a specific application deployed to the product.

It is important to highlight, however, that with CVSS v2 other Red Hat products were scored based on the impact to the entire product, and not individual components. This is a very obvious change in CVSS v3 that will cause scores for products like Red Hat Enterprise Linux to be higher, sometimes substantially so, than they would have been rated using CVSS v2. This will result in our scores being closer to those published by other vendors or organizations, however differences (as outlined above) are still taken into account and may cause some slight variation.

Further information on Red Hat impact ratings and how CVSS v3 is used can be found on our Issue Severity Classification page. CVSS v3 base metrics will be available for all vulnerabilities from June 2016 onwards. These scores are found on the CVE pages (linked to from the References section of each Red Hat Security Advisory) and also from our Security Measurements page.

So now, forewarned being forearmed, you can feel just a little bit safer crawling out from your cave to venture forth. With a clearer understanding of the risks that could occur, you can journey out into the big, wide world better prepared!