Cybersecurity Uncovered: Understanding the Potential of CVSS-B

Introduction

In the broad expanse of the digital realm, where hazards lurk around every virtual corner, having a reliable standard is critical. Common Vulnerability Scoring System (CVSS) serves as a standard for scoring, prioritizing, and mitigating vulnerabilities based on their likelihood of being attacked and the impact they would have on organizations if attacked successfully. Its purpose is to evaluate and communicate information regarding the seriousness of vulnerabilities in security across networks and computer systems. It provides a standardized method for evaluating and prioritizing vulnerabilities, helping effectively to manage and address potential threats. In regards to Software as a Medical Device (SaMD), CVSS serves as a method of assigning scores to security vulnerabilities to rank them in order of severity. The main technical features of vulnerabilities found in software, hardware, and firmware are recorded in CVSS.

With the introduction of version 1 in 2005, CVSS has undergone changes throughout time; having the latest version as CVSS version 4.0. The system is maintained by the Forum of Incident Response and Security Teams (FIRST).

The score assigned to a vulnerability using CVSS guidelines ranges from 0 to 10, depending on the metrics evaluated while analyzing the vulnerability. This score indicates the level of severity of vulnerability having low risk at 1 to critical risk at 10.

Metrics for evaluating vulnerability:

CVSS comprises four metric groups: Base, Threat, Environmental, and Supplemental.

Base Metrics (CVSS-B):

Since the base metric provides fundamental analysis of intrinsic characteristics, this metric forms the foundation for calculating CVSS score. Hence, here we will be discussing the same in detail:

• Exploitability Metrics: It relies on the characteristics of the vulnerable thing, which we technically refer to as the “vulnerable system.” E.g. Software application, operating system, module, driver, etc. Here’s a brief description of each sub-metric:
  • Attack Vector (AV): It describes how an attacker can exploit the vulnerability to compromise the confidentiality, integrity, or availability of the affected system. The wider the possible attack sources, higher the severity and ultimately the CVSS score. Criteria is as described below:
    • Physical (P): The attacker requires physical access to the vulnerable component.
    • Local (L): Attack is committed via local application/ attacker is able to login locally.
    • Adjacent (A): The attacker needs to be in the same network as the target. The attack relies on vulnerabilities or weaknesses within the communication protocols used in a system. E.g. Bluetooth, Wi-Fi, etc.
    • Network (N): Vulnerability exploited via remote networks. E.g. Across the internet.
  • Attack Complexity (AC): It measures actions an attacker must take to evade security conditions and create a functional exploit. This metric captures security mechanisms without taking into account the amount of time or tries needed. Criteria is as described below:
    • Low (L): The attacker has capability of exploiting vulnerability reliably anytime.
    • High (H): Attack will fail unless built-in security-enhancing controls are overcome.
  • Attack Requirement (AT): It captures prerequisite conditions of the vulnerable system enabling the attack. These conditions emerge during system deployment and execution. Criteria is as described below:
    • Present (P): A successful attack will be difficult unless specific conditions are met.
    • None (N): Attack will fail unless built-in security-enhancing controls are overcome.
  • Privileges Required (PR): It describes the degree of access rights required for an attacker to successfully exploit a system. The resulting score is highest when no privileges are required. Criteria is as described below:
    • High (H): Administrator or system level access required.
    • Low (L): User access required.
    • None (N): An unauthorized attacker.
  • User Interaction (UI): It captures whether a human user, other than the attacker, is needed for a successful compromise. The severity score is highest when no user interaction is necessary. Criteria is as described below:
    • Active (A): Requires target user to perform specific interactions.
    • Passive (P): Requires limited interaction by user.
    • None (N): Attack can be accomplished without any user interaction.
• Impact Metrics: It evaluates the effects of a vulnerability that has been effectively exploited. It includes an impact on the susceptible system as well as a downstream impact on what is commonly referred to as the “subsequent system(s)”. Here’s a brief explanation of each sub-metric:
  • Confidentiality (VC/SC): It measures the impact of a successful exploit on the confidential information of a system. A higher score indicates a greater loss to the system’s confidentiality. Criteria is as described below:
    • None (N): No information is disclosed.
    • Low (L): Some information obtained but the attacker does not have control over the degree of obtained information.
    • High (H): All or some critical information is disclosed to the attacker.
  • Integrity (VI/SI): It assesses the effect that a successful exploit would have on the system’s integrity. This refers to the trustworthiness of information, and a higher score signifies a more severe impact to the system. Criteria is as described below:
    • None (N): No integrity loss.
    • Low (L): Some information can be modified but the attacker does not have control over the degree of information to be modified.
    • High (H): All or some critical information can be modified by the attacker.
  • Availability (VA/SA): It measures the effect on the impacted system’s availability after exploitation. This metric focuses on the accessibility of the system itself, like a networked service. A higher score indicates a more significant impact to the system’s availability. Criteria is as described below:
    • None (N): No impact on availability of data.
    • Low (L): The affected resource is non-critical, but may lead to reduced performance or intermittent operation.
    • High (H): The affected resource is either entirely inaccessible or the attacker can selectively disrupt its availability. However, the loss of data availability poses a significant and direct threat to the vulnerable system.

Let’s understand the CVSS-B scoring using a case study:

Scenario: The medical image processing software utilizes VirtualBox as its platform to host and manage virtual machines (VMs). These VMs are responsible for storing sensitive medical images and patient data. However, a vulnerability has been discovered in VirtualBox that could be exploited by an attacker with high privileges on the virtualization infrastructure.

Explanation: The medical image processing software relies on VirtualBox as its platform to manage VMs, which are used to store sensitive medical images and patient data. A vulnerability has been identified in VirtualBox which could potentially allow an attacker to exploit flaws in security mechanisms, enabling them to gain unauthorized access to the underlying infrastructure. The attacker in this scenario possesses high privileges on the virtualization infrastructure where VirtualBox is executed. This means that they have elevated access rights, potentially allowing them to gain unauthorized access to critical data like sensitive medical images, patient records, diagnostic information, and other confidential healthcare data.

CVSS score will be 5.9 which has associated severity rating of Medium and CVSS-B metric scoring for the same will be:

Conclusion:

Thus, overall CVSS provides consumer detailed information to understand the amount of risk associated with vulnerabilities and helps to prioritize vulnerabilities. This way, they can protect their systems and data better from cyber threats.

References:

Common Vulnerability Scoring System version 4.0: Specification Document

Common Vulnerability Scoring System version 4.0: User Guide

Common Vulnerability Scoring System version 4.0: Examples