What Is Vulnerability Prioritization: How To Prioritize

What is Vulnerability Prioritization?

Vulnerability prioritization is the process of organizing the vulnerabilities that impact your company into an ordered list of issues to address.

While any vulnerability poses a risk to your business, some vulnerabilities carry a more significant risk and should be addressed as a priority.

Your organized list of issues could start with the most critical risks, which are considered to have the biggest detrimental impact on your organization and conclude with issues of lower severity.

Why Carry Out A Vulnerability Prioritization Process?

Where your organization conducts vulnerability scanning, penetration testing, or other activities, you can quickly find a long to-do list building up as more and more vulnerability data is identified.

Depending upon your company size, there may be dozens or hundreds of tasks that need to be carried out to resolve vulnerabilities and improve your security.

• The process of addressing vulnerabilities can be time-consuming,
• It is important to focus on the most critical vulnerabilities that have the greatest impact
• Creating a vulnerability prioritization program allows you to effectively assess a vulnerabilities real impact,
• A prioritization program allows you to address the real risks that impact your assets,
• You can effectively allocate resources to your security teams for remediation efforts.

Not All Vulnerabilities Represent A Critical Risk

An important part of an effective vulnerability management process is to prioritize your real risks because a vulnerability can be identified and reported for many different reasons.

• Some vulnerabilities can lead to the complete compromise of a device and all its sensitive data,
• Other lower-risk vulnerabilities may only lead to the partial compromise of non-critical information.
• Some vulnerabilities may result in no real-world impact on your systems or data

Given the different impacts that vulnerabilities can have, treating all equally doesn’t make sense, instead, vulnerabilities should be prioritized based on the real risk they can represent to your organization’s assets.

How to Prioritize Vulnerabilities

There are multiple factors to consider when creating a prioritized list of vulnerabilities and ranking vulnerabilities based on the real risk they present to your business, such as:

• What Is The Severity Of The Vulnerability
• How Critical Is The Device Impacted
• How Is The Vulnerability Exploited
• Where Is Your Asset Located
• Is There A Known Exploit Method Available
• Is The Vulnerability Part Of A Known Attack Pattern
• Are There Any Regulatory Compliance Requirements To Meet

Prioritize Vulnerabilities Using The Severity Rating

What Is The Severity Of The Vulnerability

When security risks are identified and reported, it is typical to rank vulnerabilities based on the Common Vulnerability Scoring System (CVSS).

The grading process takes into account some key factors regarding how the vulnerability is exploited and what the vulnerability may impact.

This process produces a severity rating for vulnerabilities using Critical, High, Medium, Low, and None, to represent how impactful the vulnerability will be to an affected system.

Where there are multiple security issues, a simple method to prioritize vulnerabilities is to arrange your vulnerabilities from highest to lowest severity.

Prioritizing Multiple Critical and High Vulnerabilities

It can often be the case that a large amount of critical and high-risk vulnerabilities will be identified when conducting a vulnerability scan or penetration test.

To effectively prioritize high-severity vulnerabilities and create an ordered list of multiple issues, it is necessary to take into account more factors than just the high-severity label as with traditional vulnerability management approaches.

Prioritize Vulnerabilities Using The CVSS Score

The Common Vulnerability Scoring System (CVSS)

CVSS is a common method that is used to rate the severity of vulnerabilities using Critical, High, Medium, Low, and None.

These severity ratings are also represented by a severity score ranging from 0 to 10 with the following allocations:

• Critical severity is represented by a score between 10 – 9.0
• High severity is represented by a score between 8.9 – 7.0
• Medium severity is represented by a score between 6.9 – 4.0
• Low severity is represented by a score between 3.9 – 0.1
• None is represented with a score of 0.0

Creating a more refined and ordered list of vulnerabilities can therefore make use of the CVSS score rather than the severity rating, as this will differentiate between multiple Critical Vulnerabilities which have a score ranging between 9 and 10.

Updates To CVSS Versions

The CVSS scoring system has undergone several changes over the years in an attempt to keep up with new types of vulnerabilities and to more accurately reflect the severity of vulnerabilities.

The current implementation is CVSS v4, however, many older vulnerabilities have not been updated to this yet, and it is common to still see CVSS versions 2 and 3.

CVSS v4 takes into consideration four separate categories when evaluating a vulnerability.

• The Base Metrics, only take into account specific information about the vulnerability.
• Environmental Metrics, which can account for your specific device and information that is impacted.
• A Threat Metric considers if there is currently any known method of exploitation for the vulnerability.
• Supplemental Metrics, which provide additional contextual information about the vulnerability and can help guide your decisions for a prioritized list.

This information can be useful to understand for effective vulnerability prioritization as greater business context and considerations for a real-world risk landscape can be taken into consideration.

Using CVSS Exploit Metrics For Vulnerability Prioritization

A CVSS Score is calculated using multiple metrics which can be important to understand when prioritizing vulnerabilities, for example, the Base metrics are separated into two categories for how the vulnerability is exploited and what the vulnerability impacts.

Exploitability Metrics

Exploit metrics represent the specific conditions of how a vulnerability is exploited:

• The Attack Vector (AV), represents the position an attacker would need to be in to exploit a vulnerability. Being able to exploit a vulnerability over the internet, should be considered higher risk, than vulnerabilities that require an attacker to be physically in front of a device.
• The Attack Complexity (AC), takes into consideration whether there are any compensating security controls in place that an attacker would need to evade. Where an attacker needs to work around security systems and heavily customize their attack, this can be considered a lower-risk vulnerability compared to a trivial exploit method.
• The Attack Requirements (AT), outlines how reliable the attack can be. With some types of attack, there can be a dependence on specific conditions or perfect timing for the exploit to work, which would be considered of lower risk. Whereas other vulnerabilities do not have these conditional requirements and can be expected to work every time.
• The Privileges Required (PR), defines the level of authentication an attacker would need to have to exploit a vulnerability. Some types of vulnerability require an attacker to already be authorized to a system to access the necessary content or functions to exploit a vulnerability. Where authentication is required the vulnerability can be considered of lower risk, than a vulnerability that requires no prior authentication for an attacker to exploit.
• The User Interaction (UR), takes into consideration whether a vulnerability needs the interaction of another person to work. The interaction that is necessary may be something simple such as visiting a webpage that has been manipulated by the attacker, or could be more interactive such as opening a file attachment or connecting a compromised device. Where no additional interaction is required by a person and an attacker can freely exploit a vulnerability at any time, this would be considered of higher risk.

Impact Metrics

Impact metrics represent what is affected by the vulnerability:

• The Confidentiality (C) metric considers the attacker’s ability to access information on the affected systems. Where the attacker has the ability to access all of the system’s data, this would be considered of greater impact than an exploit with only partial access or no access to a system’s information.
• The Integrity (I) metric accounts for an attacker’s ability to make changes to information within an affected system. If an attacker can modify all the data which is used by a system this will be considered much more impactful, than only being able to manipulate a portion of data or no data at all.
• The Availability (A) metric reviews an attacker’s ability to affect another’s access to data. Where an attacker can deny access to an entire system’s content this is considered to be of higher risk, whereas an attacker who can only deny access to specific content is considered of lower risk.

Vulnerable System and Subsequent System

The Impact Metrics can be further refined to reflect the impacts on a vulnerable system and the impacts that may extend beyond this to subsequent systems.

Vulnerable System

For example, where an attack targets a website, it may have impacts that change and modify how the website is interacted with, this is an Integrity (I) impact on the website, the Vulnerable System.

Subsequent System

This may have knock-on effects that change the website’s intended functionality and alters the information that is requested from a database via the website. This now results in a Confidentiality (C) impact on the database, which is the Subsequent System.

Each impact metric can be separated into these two categories, Vulnerable System and Subsequent System. As a vulnerability extends into more subsequent systems, it should be considered of greater risk than a vulnerability that is contained to just the vulnerable system.

Prioritizing Vulnerabilities Using Business Context

For any reported vulnerability it is important to consider what exactly is the business impact.

You may have conducted a vulnerability assessment against all of your assets, and a number of vulnerabilities have been identified in a device you consider critical for your day-to-day business operations.

This should be considered of greater urgency than a vulnerability that impacts a non-critical device that is rarely used and doesn’t store or process any sensitive data.

Using Environmental Metrics

The CVSS Environmental Metrics provides a method for organizations to better contextualize individual vulnerabilities in relation to their own specific business, assets, and data.

The Environmental Metrics are essentially the same as each of the Base Metrics but are intended to allow companies to refine the context of the vulnerability:

• This can be in line with how critical a system is, or how vital the data is which may be impacted.
• A vulnerability can be categorized using a Base Metric for Confidentiality and may have been graded as having a partial impact on the affected data.
• The Environmental Metric may then recategorize this as having No Impact on Confidentiality if it is known that there is no vital business data that is accessible by the affected system.

Adding this greater level of context to your list of vulnerabilities will refine the CVSS scores, to be more specific to your organization and provide a more contextualized list of vulnerabilities to address.

Effectively Prioritize Vulnerabilities Using Asset Location

How your business is set up and your network structured may change the context of a vulnerability. Environmental Metrics are available to modify the Base Metrics of a vulnerability.

Your company may have several devices which are disconnected from all other assets in your organization, but happen to be affected by a vulnerability that could be exploited across different networks.

• This would create a Base Metric for the vulnerability with an Attack Vector (AV) of Network (N) access.
• As the devices are disconnected from all other assets in your organization, there is no practical way to exploit the device in this manner
• The only way to access the device would be to physically stand in front of it.
• This information can be applied to the Environmental Metrics, and provide a Modified Attack Vector (MAV) of Physical (P).

This process provides a more accurate representation of how this vulnerability would be exploited and allows you to better contextualize the vulnerability for your organization.

Prioritize Identified Vulnerabilities Using Known Exploit Methods

The CVSS Exploit Metrics allow businesses to make more informed decisions for vulnerabilities depending upon

• Whether there is currently a known exploit method available for the vulnerability, and also,
• If there is an ongoing set of attempts to target this vulnerability in an accessible system.

Responsible Disclosure

As vulnerabilities are identified and reported to vendors, there is often a phased release of information related to the vulnerability.

• This is typically referred to as Vulnerability Disclosure or Coordinated Vulnerability Disclosure.
• This process allows vendors to be privately informed about the specifics of a vulnerability,
• New vulnerabilities are often reported by individuals or a vulnerability research team and provide vendors an opportunity to conduct development work and release updates to their products to address the issue.
• After a period of time has elapsed for updates to be distributed and applied, the vulnerability information may then be made publically available,

This process ensures that users of the products are informed about the vulnerabilities which can affect them, but provides the vendors time to address issues, in an attempt to avoid mass exploitation of a vulnerability.

Current Threat Intelligence Feeds

As vulnerability information and methods to exploit an issue become publically known, attackers will often develop automated tools to target as many affected systems as possible.

The Exploit Maturity (E) metric, allows a business to make more informed decisions related to vulnerability remediation, as a Critical vulnerability that has no known exploit method, may be considered of lower priority than a High-risk issue that is currently being targeted by attack groups.

Organizing Vulnerability Prioritization Using Exploit Probability

The CVSS Severity, Score, and Metrics can be a useful method for accurately organizing vulnerabilities into an ordered list for remediation efforts.

However, there is some context, related to the vulnerability which is not always accurately captured within the CVSS Metrics.

• The type of vulnerability,
• How likely the exploit is to be attempted,
• How likely it is to be successful,
• How long the exploitation process may take

These are several contextual factors that are worth considering when prioritizing vulnerabilities. This can create a secondary method to organize vulnerabilities based on likelihood or probability in addition to severity.

Organizing Vulnerabilities Using Likely Methods Of Exploitation

As an example, there is a type of vulnerability referred to as a Man-in-the-Middle attack.

With this type of vulnerability, the attacker would be able to intercept communications that are transferred between devices. It is likely they would need to carry out this activity over a prolonged period of time and also need to decrypt the communications so that information can be read.

Another type of vulnerability may allow an attack to directly interact with a device and to extract information, which may be instantly readable or may require decryption.

For the two described vulnerabilities:

• The attacker may need to be in a position to have direct network access to the devices,
• The end result for both vulnerabilities is for the attacker to access information.

However, the vulnerability that allows direct access to information can be considered more of an immediate risk to your organization than the Man-in-the-Middle attack.

By understanding the context around a vulnerability, such as how it is exploited it is possible to create a more refined list of vulnerabilities to resolve, taking into account the likelihood or probability of exploitation as well as the impact severity.

Accounting For Vulnerabilities In Inactive Functionality

Where vulnerability scanning tools are used to identify vulnerabilities, there can be a list of reported vulnerabilities that impact a single piece of outdated software you have in use.

Vulnerability scanning tools often find these types of issues by identifying the version of the software in use and comparing the version against a database of known exploited vulnerabilities that impact that version.

• While this can be an efficient process to identify vulnerabilities, it can also return results that are not relevant to your specific systems.
• In many instances the software you use may have multiple features, functions, and additional components, however, you may only be making use of one of two specific features of the software.
• An identified vulnerability may exist in one component that you don’t make use of and have never set up or enabled.
• In this scenario, while the reported vulnerability is valid, it only represents a theoretical threat to your systems, as the components needed to exploit the vulnerability are not present or enabled.

At a later point in time, this may change, or the exploit method for the vulnerability may impact other functions that are used for the software.

However, the initial identification of the vulnerability can be categorized as a low probability for exploitation, even though the theoretical severity may still be high.

Vulnerability Prioritization With Compliance Requirements

Where your organization maintains a compliance standard related to cyber security such as PCI DSS, ISO 27001, or Cyber Essentials, there can be requirements to conduct vulnerability scanning or penetration testing on a regular basis and to resolve vulnerabilities that are identified.

• For example, the PCI DSS compliance requirements outline a requirement for regular external vulnerability scanning where there can be no vulnerabilities with a CVSS score of 4.0 or higher.
• These compliance requirements can override the logic of any other prioritization strategy as there is now a requirement to address the identified vulnerabilities.
• A Medium severity vulnerability within an external asset could now have greater priority than that of a High vulnerability on a different system, as the Medium issue now threatens your organization’s PCI DSS compliance.

In this type of scenario, Medium-impact issues that impact your external assets may need to be placed at the top of the priority queue when managing multiple vulnerabilities.

Vulnerability Prioritization Using Attack Chains

When vulnerabilities are exploited it is often not a single stand-alone action. The information and the access obtained with one vulnerability can be used to target other systems and exploit more vulnerabilities.

This combination of vulnerabilities is often referred to as an Attack Chain or Kill Chain. An attacker may start with a single compromised device, such as a user workstation, and continue to spread their access and elevate their privileges until an entire organization is compromised.

• These attack chains can be a common and sometimes automated process used by attack groups to escalate their access and permissions.
• Several automated tools make attempts to replicate and visualize this process, and manual penetration tests may also aim to replicate potential attack chains.
• As an attack chain within an organization is more fully understood, it can become apparent that resolving a single low or medium-severity vulnerability in one device cuts off the chain preventing attackers from reaching your critical assets.

In this scenario, it can be worthwhile prioritizing vulnerabilities based on the attack chain, even if the severity is lower than critical vulnerabilities that directly impact your critical assets, as the critical vulnerabilities would not be accessible to an attacker by cutting off the attack chain.

Vulnerability Prioritization And Acceptable Risks

While vulnerability prioritization can be an important part of your vulnerability management process, it is not intended as a method to overlook or minimize the potential impact of lower-severity vulnerabilities.

• Any vulnerability that is identified within your systems should be carefully considered, and a remediation plan and timeline put in place to address the issue in a timely manner.
• Organizations may choose to categorize vulnerabilities as acceptable risks, based on their low likelihood of exploitation, low impacts on other areas of their organization, and several other factors.
• Lower-risk vulnerabilities have been shown to form part of attack chains and future developments in exploitation methods may change the vulnerability prioritization.
• Other factors can also change the risk landscape and demonstrate that a vulnerability should only be de-prioritized in relation to other more critical issues, rather than accepted as an issue that will always impact your systems.

Remediation efforts to resolve a vulnerability can sometimes outweigh the cost and risk of exploitation, making acceptance of a vulnerability understandable. However, as technology changes and new solutions become available, this may present new opportunities to resolve a long-standing vulnerability.

Additional factors can also be taken into account, such as a change in existing compliance standards, or the requirement to obtain a new standard. These new compliance standards may present a requirement to resolve previous vulnerabilities that were once considered an acceptable risk.

Vulnerability Remediation and Vulnerability Prioritization

The steps involved in resolving a vulnerability and the knock-on impacts on other systems shouldn’t be overlooked when creating a prioritized list of vulnerabilities.

• While many vulnerabilities have a relatively straightforward remediation process, others can require configuration work, further development, new products, or new solutions to be set up and installed.
• The time and cost to address some vulnerabilities can quickly escalate, however, this shouldn’t halt the remediation work for other vulnerabilities that are of lower priority and have a simpler resolution process.
• Instead, lower-priority issues can be addressed first, where they can be addressed in a timely manner and will have limited impacts on other business assets.
• Once vulnerabilities are put into priority order, it is useful to review the list with the remediation process in mind, to determine an estimated time to address the issue, and any potential impacts to other systems.

This process can further refine the list of vulnerabilities so that more urgent issues that can be quickly addressed are resolved, and a timeframe and action plan to address other issues can be put in place.

Vulnerability Prioritization Tools

There are dedicated vulnerability prioritization tools available as well as scanning tools that offer a prioritization feature as part of their vulnerability reporting.

However, many of the prioritization options for these tools will only take into account known factors, such as severity, exploitability, and emerging threats.

As business context can be unique to every organization, it will still be required for you to add your own level of context to your assets, your sensitive data, and any compliance standards that need to be met.

Conclusion

A vulnerability prioritization strategy is a useful process for security teams when a business is faced with addressing high-severity vulnerabilities and are unsure of where to begin resolving their security gaps.

Unfortunately, there are still a large number of data breaches that continue to impact organizations and can have detrimental impacts on both businesses and customers.

Implementing an effective vulnerability prioritization process can help resolve security issues based on current cyber threats, real-world scenarios, and their business risk, to help secure companies and protect sensitive data.

Where you have any further questions regarding different cybersecurity solutions, our consultants are available to address any concerns you may have.