Soon after initiating a vulnerability management program, enterprises often find themselves facing an intimidating avalanche of data about network security vulnerabilities. Scan results may show hundreds or even thousands of vulnerabilities distributed across a wide variety of systems and applications.
How should security professionals tackle this mountain of risk? In this tip, we examine a three-prong prioritization program that incorporates external criticality assessments, data sensitivity and the existing control environment to help organizations successfully rank vulnerabilities and, in turn, prioritize remediation efforts.
This three-step process assumes that you have access to
Step 1: Determine vulnerability severity
The first data element you will need 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 upon the potential damage that a successful exploit might cause. For example, a vulnerability that allows 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.
For the purposes of our model, we will assume that you are using a product that uses a five-point vulnerability rating system, with vulnerabilities that have the highest risk of a damaging exploit receiving a 5 rating.
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 your 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 impact 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 fairly 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 our information security 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 of 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 that your organization is willing to disclose to the general public, such as product literature, data shared on your public website and released financial statements.
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. Systems processing highly sensitive information are 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 are rated 1 on data sensitivity.
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 upon the particular 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 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 of this information, you may use it to assess the vulnerabilities that show up on your reports. And, once you have it all consolidated in one place, perform this simple calculation for each vulnerability that exists on a system:
If you chose five-point scales for each measure, 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 25 (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 create a database that contains data sensitivity and control status information for all of your server assets.
Similarly, scripts can parse vendor reports to automatically extract vulnerability severity information, pull relevant information from the database and calculate the risk score.
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.
This was first published in January 2014