How to rank and prioritize security vulnerabilities in 3 steps

Step 1. Determine vulnerability severity

The first data element needed is an assessment of the severity of each vulnerability that exists in your environment. In many cases, this severity information is provided through data feeds from your vulnerability management tools.

The severity assessment should be based on the potential damage that a successful exploit might cause. For example, a vulnerability that enables an attacker to gain administrative access to a system is much more severe than one that causes a DoS. Severity information might also take into account the real-world existence of exploits; a theoretical vulnerability with no known exploits is less severe than one used by a virulent piece of malware.

Today, most products support the use of CVSS, a risk score used by the National Vulnerability Database (NVD). CVSS enables the consistent description and severity ranking of vulnerabilities from product to product. In this system, all vulnerabilities are rated on a 10-point scale using a series of formulas that take the likelihood and impact of an exploit into account. Vulnerabilities are then categorized as in Figure 1.

Using this type of consistent scale helps security teams quickly react to new vulnerabilities as they arise. For example, when the SolarWinds vulnerability became publicly known, NVD quickly assigned it a high vulnerability score of 8.8.

Step 2. Identify data sensitivity

The risk a vulnerability poses is magnified by the sensitivity of the information processed on systems containing that vulnerability. For example, systems containing Social Security numbers or credit card data should be handled with much more care and concern than systems containing only publicly available information.

This does not mean that only systems containing sensitive information should be well managed; a compromise of a public-facing website could cause just as much reputational damage to an organization as a disclosure of sensitive information. However, the presence of sensitive information certainly magnifies the effects of a successful attack.

Gathering information on data sensitivity can be tricky depending on the maturity of your organization's information classification program. If you're just getting started, try using a simple model that divides data into categories based on the following degrees of sensitivity:

• Highly sensitive information is either heavily regulated or would be extremely damaging to the organization if inadvertently released. The crown jewels of infosec programs contain data elements, such as credit card numbers, protected health information and bank account details.
• Internal information is every piece of information that does not fit the highly sensitive definition but should not be publicly released. This category might seem overly broad; it is also the hardest to define. If you don't have a data classification program, lumping all this data into a single category is the most expedient way to get started. If business needs dictate, consider subdividing this category at a later date.
• Public information is anything your organization is willing to disclose to the general public, such as product literature, data shared on your public website and released financial statements.

As you get started with your classification program, you get the most return on your investment of time by focusing your work on highly sensitive information. Work with security and functional experts to determine the most critical pieces of information your organization handles and identify where they are stored, processed and transmitted. That gets you off to a great start.

When it comes time to assign data sensitivity ratings to systems, base your evaluation on the highest level of information stored or processed by a system. Here, you might use a five-point scale. Systems processing highly sensitive information should be assigned a data sensitivity rating of 5, while those processing internal information might receive a rating of 2, 3 or 4, depending on the degree of sensitivity. All other systems can be rated 1 on data sensitivity. For example, a web server that handles customer credit card information or an HR system that handles Social Security numbers should have a sensitivity rating of 5. At the other extreme, a server that contains only public web content might be rated as a 1. Other systems, such as those that process customer transactions, facilitate manufacturing processes and perform other tasks, fit somewhere in the middle.

Step 3. Evaluate existing controls

The final step of the process is to evaluate the existing controls that protect potentially vulnerable systems from compromise. The method you use to assign these ratings varies depending on the controls your organization requires. For example, if you have a highly secured network used for extremely sensitive systems, you might assign these systems a 5 rating on a five-point control scale. Similarly, a system with a public IP address that is accessible from the internet hosting a web application but is not protected by a web application firewall might be assigned a 1 or 2 rating. Choose a rating scale that accurately reflects the expected controls in your environment, and assign higher ratings to systems that have strong security controls.

Starting to rank security vulnerabilities

Once you've gathered all this information, use it to assess the vulnerabilities that show up on your reports. Once you have it all consolidated in one place, perform the simple calculation in Figure 2 for each vulnerability that exists on a system.

If you use the 10-point CVSS scale for vulnerability severity and five-point scales for data sensitivity and existing controls, this results in a vulnerability rating that ranges from a minimum of 0.2 for a low-severity vulnerability in a well-controlled system containing only public information to a maximum of 50 for a high-severity vulnerability in a system lacking security controls containing highly sensitive information.

While this might seem like a lot of data to gather and math to perform, you can find ways to automate the process and feed your vulnerability prioritization efforts. For example, you might adopt automated patching strategies that address vulnerabilities as they arise. You might also use advanced capabilities of your vulnerability management system to automatically remediate simple issues and integrate with your IT service management platform for tracking more complex problems. Security orchestration, automation and response platforms facilitate the automation of workflows as well.

There are many ways to customize a network security vulnerabilities prioritization system for an organization. Regardless of the tweaks you make, an effective vulnerability management program based on risk-based prioritization decisions is a must for any organization looking to reduce IT security risk. Simplifying the process used to perform vulnerability risk analysis makes it much easier to begin and sustain such a program.

You might also consider deploying a risk-based vulnerability management (RBVM) program to more proactive identify vulnerabilities and their potential impact. An RBVM program can improve threat intelligence capabilities, incorporate more risk metrics, help you better understand your organization's security posture and enable you to reduce your organization's attack surface.

Editor's note: This article was written by Mike Chapple in 2021. TechTarget editors revised it in 2024 to improve the reader experience.

Mike Chapple, Ph.D., CISA, CISSP, is a senior director of IT with the University of Notre Dame.