How to rank enterprise network security vulnerabilities

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 the vendors that provide 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 denial of service. Severity information may 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 the Common Vulnerability Scoring System (CVSS), a scoring approach 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 the accompanying table.

Using this type of consistent scale helps organizations quickly react to new vulnerabilities as they arise. For example, when the SolarWinds vulnerability became publicly known in February 2021, 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 generally 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 the 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, you may wish to use a simple model that divides data into categories based on their degree 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 may 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'll 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 that your organization handles and identify where they are stored, processed and transmitted. That will get 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, would 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 will vary 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.

Pulling it all together

Once you've gathered all this information, you may use it to assess the vulnerabilities that show up on your reports. Once you have it all consolidated in one place, perform the accompanying simple calculation 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 will result 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 may 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.