top of page
brencronin

Vulnerability Management - Vulnerability Prioritization

Updated: Nov 10

In a prior article, I introduced a vulnerability management program framework known as P.I.A.C.T., developed by SANS instructors Jonathan Risto and David Hazar. The P.I.A.C.T vulnerability management program framework helps organizations assess key vulnerability management functions through the lens of a Capability Maturity Model.

  • Planning

  • Identification

  • Analyze/Assess

  • Communicate

  • Treat

When you conduct successful vulnerability scans, you are primarily focused on the "I" (Identify) aspect. However, it's crucial to emphasize that an essential component of effective vulnerability management is Analyzing and Assessing these vulnerabilities, represented by the "A" in the P.I.A.C.T. framework.



Problems with assessing vulnerabilities


A significant challenge in vulnerability assessment is relying solely on the interpretation of scanner generated CVSS scores as the definitive risk assessment for the organization. It's important to remember that CVSS scores serve as an initial point for analysis rather than the ultimate determinant of the vulnerabilities' risk to the organization.


The "Because the scanner said-so!" problem


Numerous individuals simply glance at the scanner's generated report and conclude, 'Well, the scanner says it, so that's it.'

To grasp the information provided by the scanner, it's essential to have a good grasp of the CVSS standard. The CVSS standard consists of various metric categories that, when integrated, create a Vector String and yield a calculated CVSS score for the vulnerability. These metric categories in the CVSSv3 standard are:

  • Base metrics

  • Temporal metrics

  • Environmental metrics

Each metric area comprises the individual metrics that contribute to the assessment of the vulnerability.

Every vulnerability is assigned a vector string, which begins with the Base metric group and is determined by the characteristics specific to that vulnerability.

Each metric component within the metric group contains distinct characterization values for the vulnerability. As an illustration, consider AV, which represents "Attack Vector" and encompasses the following values:


AV:P - Physical Access Needed

AV:L - Local Access Needed

AV:A - Adjacent Access needed

AV:N - Network Access Needed (i.e., the vulnerability is exploitable over the network)


You can explore a handy interactive tool for manipulating the metric groups and observing their influence on the overall CVSS score on First.org's website. It's available at: https://www.first.org/cvss/calculator/3.1. To illustrate this, let's consider the example CVE-2022-22954 with a Vector String of /AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H in CVSS 3.1, as displayed below.

As an illustration, if we alter the AV (Attack Vector) from "N" (Network) to "P" (Physical), the vulnerability rating drops to a medium level. This shift occurs because gaining physical access to a system is significantly more challenging for an attacker compared to obtaining network access. This example serves to demonstrate how the various metrics influence the overall CVSS vulnerability score, while also underscoring how effective mitigations can reduce the actual CVSS risk rating of the vulnerability.

There are certain challenges in how the CVSS system is commonly interpreted:

  • The vulnerability scanner lacks knowledge of your specific environment, and as a result, Environmental Metrics are not considered.

  • Considering Temporal Metrics requires additional effort and "Cyber Threat Intelligence" CTI research, which is frequently not done.

In a hypothetical scenario, a firewall was implemented to safeguard the system, rendering the AV (Attack Vector) only exploitable through physical access. This represents a modification to the Base Metric within the Environmental Metric Group.


The CVSS standard explicitly emphasizes that its proper use entails augmenting the base score with both temporal and environmental scores.


"Consumers of CVSS should supplement the Base Score with Temporal and Environmental Scores specific to their use of the vulnerable product to produce a severity more accurate for their organizational environment. Consumers may use CVSS information as input to an organizational vulnerability management process that also considers factors that are not part of CVSS in order to rank the threats to their technology infrastructure and make informed remediation decisions." ( https://www.first.org/cvss/v3.1/specification-document )


Meanwhile, a growing mountain of vulnerabilities looms, leaving cybersecurity engineers and system administrators grappling with a critical question: 'Amidst this deluge of vulnerabilities, which should we prioritize for immediate patching?'

Prioritizing Vulnerabilities


Prioritizing vulnerabilities remains a significant challenge in the cybersecurity community, prompting ongoing initiatives to assist cybersecurity and IT leaders in this endeavor. Some of these initiatives include:

  • Incorporating Temporal metrics as a consistent factor in vulnerability prioritization.

  • Leveraging CISA's "Known Exploited Vulnerabilities" (KEV) database.

  • Identifying and safeguarding your organization's critical assets, often referred to as 'crown jewels.'

  • Adhering to the CVSSv4 standard for vulnerability assessment and scoring.


Consistently factoring in Temporal Metrics - Example Vulnerability Priority Rating (VPR)


To augment their value proposition, scanning companies aim to uncover more extensive details about vulnerabilities. This includes factors such as the presence of available exploits and the extent to which the vulnerability is actively being targeted. For example, one method to gain deeper insights into vulnerability exploits is by utilizing Cyber Threat Intelligence (CTI) to scour dark web forums for exploit-related information and activity associated with the vulnerability.

As an illustration, of this concept in action is, Tenable's Vulnerability Priority Rating (VPR) system, which enriches the context of vulnerabilities by assigning them a distinct VPR score, separate from the traditional CVSS. You can explore further details about Tenable's VPR system at this link: https://www.tenable.com/blog/what-is-vpr-and-how-is-it-different-from-cvss


For a comprehensive understanding of the factors influencing Tenable's VPR score, refer to the following resource: https://developer.tenable.com/docs/vpr-drivers-tio


CISA "Known Exploited Vulnerabilities" (KEV)


The CISA "Known Exploited Vulnerabilities" (KEV) project involves CISA's research into the exploits used by attackers in real-world attacks and data breaches. Subsequently, CISA compiles and shares a public catalog of the most frequently exploited vulnerabilities. The KEV catalog functions as a prioritized list of vulnerabilities that demand immediate attention and patching. You can access the KEV catalog online here: https://www.cisa.gov/known-exploited-vulnerabilities-catalog



The below search of CVE-2022-22954 shows that it is in the KEV and is actively being exploited by Ransomware campaigns.


Knowing Your Own Crown Jewels


This example illustrates that while the same vulnerability may exist across multiple systems, the associated risk can vary based on the specific system or data affected by the vulnerability. Consequently, it underscores the importance of maintaining comprehensive hardware and software asset management. One of the key advantages of such management is the capability to assign a risk categorization to each asset.


Furthermore, the implementation of a robust system for data classification proves to be crucial for the organization. This facilitates the tracking of an organization's most valuable assets, often referred to as its 'crown jewels,' and helps in identifying their precise locations.





CVSSv4 standard


The CVSSv4 standard, currently under public review as of October 2023, introduces an expanded approach to assessing vulnerability risk. Notably, it introduces a distinct metric group known as the "Threat Metric Group," which includes metrics for "Exploit Maturity" that contribute to the overall CVSS score.


Furthermore, the CVSSv4 standard includes a "Supplemental Metric Group" that incorporates additional scoring metrics such as "Safety." These metrics account for heightened risks associated with vulnerabilities in information technology systems that pose safety concerns if exploited. This becomes particularly valuable in quantifying the heightened risks in domains where safety considerations, such as those found in "Operation Technology" (OT) systems, are a significant factor. For a detailed reference to the CVSSv4 standard, please visit the following link: https://www.first.org/cvss/v4.0/specification-document


Back to "Assess/Analyze" in P.I.A.C.T


Relating to the P.I.A.C.T vulnerability management maturity model, we can delineate the various processes and procedures necessary for an organization to progress along the continuum towards a more robust vulnerability management program.

  • In the CMM 'Initial' stage of vulnerability assessment, organizations typically rely solely on out-of-the-box CVSS scoring.

  • Advancing to the CMM 'Managed' stage, organizations begin to factor in additional risk-related information such as 'Exploit Code Maturity,' similar to Tenable's VPR.

  • In the CMM 'Defined' stage, the assessment process becomes more sophisticated by incorporating the prioritization of systems and information, especially identifying and protecting the organization's 'crown jewels.'

  • Moving into the CMM 'Quantitatively Managed' phase, organizations extend their assessment process by considering 'Cyber Threat Intelligence' (CTI) sources like CISA's KEV project.

  • Finally, in the CMM 'Optimized' stage, organizations establish their specific CTI programs tailored to their unique needs and risk landscape.


Assessing/Analyzing Vulnerabilities and 'Root Cause Analysis'


An equally crucial aspect of vulnerability analysis also involves implementing processes and procedures to assess the root causes that give rise to vulnerability exposure in the first place. This includes investigating why a system was deployed with vulnerabilities, how these vulnerabilities were introduced to the system, and the speed at which they were identified and assessed.













11 views0 comments

Commentaires


Post: Blog2_Post
bottom of page