How to Prioritize Your System’s Security Vulnerabilities

By Kevin Beaver

Prioritizing the security vulnerabilities you find is critical because many issues might not be fixable, and others might not be worth fixing. You might not be able to eliminate some vulnerabilities because of various technical reasons, and you might not be able to afford to eliminate others. Or, simply enough, your business may have a certain level of risk tolerance. Every situation is different.

You need to factor whether the benefit is worth the effort and cost. On the other hand, spending a few weeks of development time to fix cross-site scripting and SQL injection vulnerabilities could be worth a lot of money, especially if you end up getting dinged by third-parties or lose potential customers. The same goes for mobile devices that everyone swears contain no sensitive information.

You need to study each vulnerability carefully, determine the business risk, and weigh whether the issue is worth fixing.

It’s impossible — or at least not worth trying — to fix every vulnerability that you find. Analyze each vulnerability carefully and determine your worst-case scenarios. So you have cross-site request forgery (CSRF) on your printer’s web interface? What’s the business risk? Perhaps FTP is running on numerous internal servers. What’s the business risk? For many security flaws, you’ll likely find the risk is just not there.

With security — like most areas of life — you have to focus on your highest payoff tasks. Otherwise, you’ll drive yourself nuts and probably won’t get very far in meeting your own goals. Here’s a quick method to use when prioritizing your vulnerabilities. You can tweak this method to accommodate your needs. You need to consider two major factors for each of the vulnerabilities you discover:

  • Likelihood of exploitation: How likely is it that the specific vulnerability you’re analyzing will be taken advantage of by a hacker, a malicious user, malware, or some other threat?

  • Impact if exploited: How detrimental would it be if the vulnerability you’re analyzing were exploited?

Many people often skip these considerations and assume that every vulnerability discovered has to be resolved. Big mistake. Just because a vulnerability is discovered doesn’t mean it applies to your particular situation and environment. If you go in with the mindset that every vulnerability will be addressed regardless of circumstances, you’ll waste a lot of unnecessary time, effort, and money, and you can set up your security assessment program for failure in the long term.

However, be careful not to swing too far in the other direction! Many vulnerabilities don’t appear too serious on the surface but could very well get your organization into hot water if they’re exploited. Dig in deep and use some common sense.

Rank each vulnerability, using criteria such as High, Medium, and Low or a 1-through-5 rating (where 1 is the lowest priority and 5 is the highest) for each of the two considerations. Following is a sample table and a representative vulnerability for each category.

Prioritizing Vulnerabilities
High Likelihood Medium Likelihood Low Likelihood
High Impact Sensitive information stored on an unencrypted laptop Tape backups taken offsite that are not encrypted and/or
password protected
No administrator password on an internal SQL Server system
Medium Impact Unencrypted e-mails containing sensitive information being
Missing Windows patch on an internal server that can be
exploited using Metasploit
No passwords required on several Windows administrator
Low Impact Outdated virus signatures on a standalone PC dedicated to
Internet browsing
Employees or visitors gaining unauthorized network access Weak encryption ciphers being used on a marketing website

The vulnerability prioritization shown is based on the qualitative method of assessing security risks. In other words, it’s subjective, based on your knowledge of the systems and vulnerabilities. You can also consider any risk ratings you get from your security tools — just don’t rely solely on them, because a vendor can’t provide ultimate rankings of vulnerabilities.