What You Should Know About the CVSS Base Metrics?

The Common Vulnerability Scoring System (CVSS) is an industry standard for assessing the severity of software vulnerabilities. The CVSS base metrics are a key component for calculating the base score, which rates the intrinsic characteristics of a vulnerability that do not change over time or across environments.

In this comprehensive blog post, we will take a deep dive into the CVSS base metrics – understanding how they work and how they factor into the overall CVSS score.

Why Do the CVSS Base Metrics Matter?

The CVSS base metrics allow analysts to quantitatively score and prioritize vulnerabilities based on severity. They provide a standardized way to convey vulnerability severity that works across vendors, industries, and geographies.

Instead of relying on vague or qualitative assessments like “high risk” or “critical vulnerability”, CVSS base scores assign an objective 0-10 rating. This clears up discrepancies and miscommunications over things like:

By grounding vulnerability management in data-driven CVSS scores, security teams can focus on fixing the most dangerous vulnerabilities first. They can also effectively communicate risks within their organization based on the universal language of CVSS base metrics.

Over time, the NIST National Vulnerability Database (NVD) has adopted CVSS scoring. So most publicly disclosed vulnerabilities will already have CVSS metrics and base scores assigned.

However, understanding the key components of CVSS is crucial for interpreting these standardized scores. The base metrics also allow analysts to manually score vulnerabilities that are newly discovered or have limited public information.

The Core Components of CVSS Base Metrics

The CVSS base metrics examine six intrinsic aspects of a vulnerability:

The CVSS Base Formula

These metrics fit into an overall formula that generates the final CVSS base score:

Base Score =  f(AV,AC,PR,UI,S,C,I,A)

Essentially, the base score rates a vulnerability’s ease of exploitability along with its potential impact. Higher scores indicate greater severity vulnerabilities that are easier to exploit and have bigger impacts.

Note: The CVSS v3.1 specification outlines the exact formula –  but thankfully security analysts don’t need to worry about the complex math behind it! The key is understanding conceptually what each metric means and how to accurately assess the characteristics of a vulnerability.

CVSS v3.1 Base Metrics in Detail

Now, let’s do a lightning round overview of the metrics and values that factor into CVSS base scoring:

Attack Vector (AV)

The Attack Vector (AV) metric is a key component of the CVSS base score that classifies how a vulnerability can be exploited. Specifically, it measures the context or proximity from which a vulnerability can be successfully leveraged by an attacker.

AV helps assess a vulnerability’s remoteness and accessibility to adversaries. Flaws that require physical access or specialized permissions may be less exposed compared to those directly reachable over a network.

There are four possible values for the Attack Vector metric:

Network (N)

A vulnerability with a Network attack vector means it can be remotely exploited by attackers over the network stack. For example, a web application flaw or buffer overflow in an internet-facing service would qualify.

Network vectors represent the highest risk values in CVSS since no attacker proximity or access to systems is required. Any vulnerability reachable over a LAN, WAN, or the public internet can potentially fall under this category.

Adjacent (A)

The Adjacent attack vector indicates a vulnerability is limited to adjacent network access zones rather than remotely over the internet. Attackers would need privileges within a local subnet, wireless network, or limited virtual network segment to exploit it.

While not as severe as remote network attacks, adjacent vulnerabilities can still enable lateral movement between closely networked systems.

Local (L)

Local vulnerabilities can only be leveraged if an attacker already has local access to a vulnerable system first. For example, by gaining physical access to a device, or remote shell (RSH) access within an organization’s internal network.

The additional step limits exposure to some extent compared to remote flaws. However, vulnerabilities granting elevated privileges or opportunities for lateral movement still carry risk, even if exploitation starts from an established local presence.

Physical (P)

The Physical attack vector represents vulnerabilities only exploitable with physical access to a system’s hardware components. For example requiring:

Since gaining hands-on access to servers or endpoint devices is incredibly difficult, physical vectors have the lowest level of exposure. However, highly sensitive systems may still classify physical hardware access as a serious security risk.

Attack Complexity (AC)

The Attack Complexity (AC) metric measures the relative level of effort required for an attacker to exploit a vulnerability after gaining access.

Essentially, it represents the ease and probability an attack will succeed against a target.

AC has two possible values:

High (H)

A High rating means that exploitation requires conditions beyond the attacker’s direct control to be present. Successful attacks depend on factors like:

For example, a vulnerability may only be exposed during a small time window each day when backups run. Or it requires bypassing IP whitelist protections by stealing an approved source IP address first.

The dependence on hard to control external variables reduces the overall likelihood an attack will work. And in turn, the risk rating is decreased in CVSS for high complexity flaws.

Low (L)

A Low attack complexity means the vulnerability can be easily exploited with a straightforward attack, once an attacker has gained access as dictated by the Attack Vector (AV).

Low ratings assume the following characteristics:

For example, a vulnerable input field that allows JavaScript code execution would have low complexity, since simple script injection attacks are highly reliable.

With straightforward exploitation, attackers have a high probability of success. Thus, low complexity vulnerabilities directly translate to higher risk in CVSS ratings.

Privileges Required (PR)

The Privileges Required (PR) metric captures the level of privileges an attacker would need before exploiting the vulnerability.

Essentially, it measures the access level on the vulnerable component itself that’s necessary to perform the attack.

PR has three possible values:

None (N)

A PR rating of None means the vulnerability can be exploited by any user without requiring privileges. This represents the highest risk value and is common with remote network flaws.

For example, a vulnerability could allow any anonymous internet user to retrieve sensitive server data. Since no special access is needed, any attacker can be successful.

Low (L)

A Low PR rating means standard unprivileged system access is necessary to exploit the vulnerability. For example, access with a normal user account that has limited permissions in the OS or application.

This presents a lower hurdle for attackers compared to privileged roles. However, some degree of initial access is still necessary increasing the effort to exploit compared to none.

High (H)

The High PR value represents cases where the attacker requires higher levels of privileges on the vulnerable system before exploitation is possible.

For example, administrator, root, or service accounts on a local machine. Or privileges to access accounts and resources across federated identity systems.

Since significant permissions are required before attacks can get off the ground, high PR vulnerabilities pose the lowest level of risk according to CVSS.

User Interaction (UI)

The User Interaction (UI) metric measures the requirement for human participation in order for a vulnerability to be successfully exploited.

Essentially, UI rates whether user actions are essential for an attack campaign to progress and compromise assets after initial access requirements defined by AV and PR metrics are met.

There are two possible values:

Not Required (N)

A value of N means the vulnerability can be leveraged by attackers without any user interaction at all. For example, remote code execution flaws or always-on services with vulnerable features.

UI Not Required is the higher risk value. With no dependency on victims’ behavior, attackers can automate and scale attacks rapidly.

Required (R)

A value of R indicates that a user must take specific actions in order for exploitation to be possible. For example, getting victims to:

Successful attacks strictly rely on social engineering methods to persuade user behavior. Since users can also be educated to recognize threats, risk decreases compared to fully automated UI not required attacks.

Security Scope Impact (S)

The Security Scope (S) metric captures whether a vulnerability in one software component can impact resources or functionality unrelated to that component.

Essentially, it measures if exploitation allows attackers to only compromise the directly vulnerable component, or if it potentially spreads impact to the broader environment.

There are two possible values:

Unchanged (U)

This rating means that a vulnerability can only compromise the security properties of the vulnerable component itself (confidentiality, integrity, availability).

For example, a flaw in a web server that could allow information disclosure only from that server. Or a denial of service vulnerability that only makes that resource unavailable.

Unchanged is the lower risk value in CVSS scoring. Since impact is restricted, risks to the overall environment are reduced.

Changed (C)

A Changed rating indicates that attacks against one vulnerable component could actually compromise other components or systems as well.

For example, local privilege escalation attacks may allow attackers to fully compromise underlying server operating systems. Or attacks may move laterally from a compromised endpoint to backend databases.

Changed scope represents higher risk scenarios in CVSS. Successful attacks have potential impact beyond just the isolated vulnerable component or system.

In essence, Security Scope helps capture risks where vulnerabilities may represent pivot or pivot points rather than just isolated threats. Even if one component is patched, underlying systems could still be jeopardized.

Confidentiality / Integrity / Availability Impact (CIA)

The CIA metrics capture the potential impact successful exploitation has on the core security properties of a vulnerable system or component:

Each property is scored independently on a scale to model overall potential impact.

Confidentiality Impact

Measures potential data disclosure or unauthorized access.

Integrity Impact

Measures potential corruption, manipulation, or destruction.

Availability Impact

Measures potential disruption to access and performance.

Scoring each metric individually allows analysts to capture risks across multiple dimensions when considering a vulnerability’s total potential impact. For example, a loss of availability may be the main risk concern rather than confidentiality for a particular component.

In essence, while some vulnerable components may only pose threats in selective areas, flaws compromising multiple CIA properties simultaneously can have widespread consequences. The CIA metrics help quantify risks across impact dimensions.

Putting the Metrics Together: The CVSS Vector String

So how does an analyst actually assign values and calculate a CVSS base score? Here is where the CVSS vector string comes in handy.

The vector string essentially encodes all the different base metric values into a shorthand format. Here is an example:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

By breaking down each component, we can understand exactly how this hypothetical vulnerability is scored:

Even without calculations, this vector string gives us a model for scoring vulnerabilities in a standardized format. By selecting the accurate metric values, an analyst can reliably score vulnerabilities, prioritize production systems, and communicate severity.

Level Up Your Vulnerability Management with CVSS

Whether you are a security analyst at a Fortune 500 company or an IT admin at a 50 person firm, understanding CVSS base metrics is crucial for assessing and communicating vulnerability risks.

Standardized base scoring helps cut through the noise to identify truly dangerous software flaws in your environment. It also informs smart mitigation decisions around which vulnerabilities get prioritized and patched first.

As public vulnerability databases and scan tools have broadly adopted CVSS, its metrics create a common language around severity – no matter which systems, vendors, or stakeholders you interface with.

Hopefully this post has helped demystify some concepts around CVSS base scoring and metrics. Feel free to reference the key metrics and examples as a handy cheat sheet. And stay tuned for an upcoming deep dive specifically around tailoring CVSS environmental metrics to your organization’s unique infrastructure, assets, and tolerance to risk exposure!

We hope this post helped in learning about the CVSS base metrics. Thanks for reading this post. Please share this post and help secure the digital world. Visit our website, thesecmaster.com, and our social media page on Facebook, LinkedIn, Twitter, Telegram, Tumblr, Medium, and Instagram and subscribe to receive updates like this.  

You may also like these articles: