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:

  • Which vulnerabilities are more urgent and need to be patched first?

  • Is a reported vulnerability truly serious or is it being overhyped?

  • How does the severity of Vulnerability X compare to Vulnerability Y?

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:

  1. Attack Vector (AV): How the vulnerability can be exploited

  2. Attack Complexity (AC): The complexity and conditions required to exploit the vulnerability

  3. Privileges Required (PR): The privileges or access level an attacker needs to exploit this vulnerability

  4. User Interaction (UI): Whether user interaction is required for successful exploitation

  5. Security Scope Impact (S): Whether a compromised component impacts resources beyond its scope

  6. Confidentiality / Integrity / Availability Impact (CIA): The impact to confidentiality, integrity, and availability of systems and data if the vulnerability is exploited

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

Cvss V3 1 Base Metrics

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:

Value Abbreviation Score
Network N 0.85
Adjacent A 0.62
Local L 0.55
Physical P 0.2

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.

See also  How to Fix CVE-2023-22515- A Critical Privilege Escalation Vulnerability in Confluence Data Center and Server?

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:

  • Direct physical connections to uncover flaws

  • Special equipment attached to interface buses

  • Access to locally connected hardware peripherals

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:

Value Abbreviation Score
Low L 0.77
High H 0.44

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:

  • Specific system configuration or deployment environment

  • Mitigating controls that must be bypassed

  • Specialized setup steps needed to uncover exploitable conditions

  • Dependence on social engineering methods

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:

  • Detailed technical knowledge of a target system is generally not required

  • No mitigating controls need to be bypassed to launch an attack

  • Only widely available or custom tools and scripts are necessary

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:

Value Abbreviation Score
None N 0.85
Low L 0.62
High H 0.27

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.

See also  How To Protect Your macOS From New AdLoad Adware?

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:

Value Abbreviation Score
None N 0.85
Required R 0.62

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:

  • Open a weaponized file attachment

  • Navigate to an attacker-controlled site

  • Install unwanted apps/programs

  • Enable content in browser

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:

Value Abbreviation
Unchanged U
Changed C

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:

  • Confidentiality

  • Integrity

  • Availability

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

Confidentiality Impact

Measures potential data disclosure or unauthorized access.

  • None (N): No impact to data confidentiality

  • Low (L): Partial unauthorized data access possible

  • High (H): Widespread unauthorized access to sensitive data

Integrity Impact

Value Abbreviation Score Description
High H 0.56 Total loss of integrity: Any files can be modified, or critical files can be modified
Low L 0.22 Some data can be modified, but it is not critical in nature
None N 0.0 No loss of integrity

Measures potential corruption, manipulation, or destruction.

  • None (N): No impact to integrity of systems or data

  • Low (L): Limited manipulated or disruption possible

  • High (H): Widespread destruction or manipulation likely

Availability Impact

Value Abbreviation Score Description
High H 0.56 Total loss of availability: total loss of access to affected system component
Low L 0.22 Performance degradation is experienced: may include inermittent outages.
None N 0.0 No loss of availability

Measures potential disruption to access and performance.

  • None (N): No impact to availability

  • Low (L): Degradation of performance likely

  • High (H): Total loss of access possible

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:

  • AV:N– Attack vector is Network (remotely exploitable)

  • AC:L– Attack complexity is Low (little barrier to exploit)

  • PR:N– Privileges required are None (no privileges needed to exploit)

  • UI:N– No user interaction is required for successful exploit

  • S:C– Impacts resources beyond vulnerable component’s scope

  • C:H– Highly impacts confidentiality (data exposure)

  • I:H– Highly impacts integrity (corrupts systems/files)

  • A:H– High availability impact (disrupts access to resources)

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!

Leave a Reply

Your email address will not be published. Required fields are marked *