Vulnerability Management: Prioritize, Prioritize, Prioritize

Over the past 30 years or so, there have been nearly 180,000 vulnerabilities identified and assigned Common Vulnerabilities and Exposures (CVEs). On top of that, we are averaging over 75 new CVEs per day so far in 2022, and it looks like we may set a record for the volume of new CVEs. If historic trends continue, we can expect about 10-15% of new vulnerabilities to have a (Common Vulnerability Scoring System (CVSS) score of 9.0 or higher and be classified as “critical.”

Additionally, organizations are facing staffing shortages, and dynamic business requirements that expect them to be agile – requiring fast reactions to changing environments and requirements.  Organizations are being forced to do more with less.

How do you balance requirements in such a high-paced, dynamic environment?

Prioritize.

Simply put, you can’t do everything. The old saying goes “If everything is important, then nothing is.” And the reality is, some things really are more important.

You must remember this when reviewing the results of a penetration test, your staff is likely already busy. They are probably working at, or above, a reasonable capacity before they are handed the results of a penetration test and told to fix everything. So, you must ask yourself, “do they really need to fix everything?”

Given unlimited resources and time, the answer is “yes, fix everything”. But no one has unlimited resources and time, so the better answer is to prioritize the things that need to get done. Even if you can get to everything, prioritize the most important first.

The balance in managing the results of a penetration or application test is that prioritizing is not a simple answer, but a balance of decisions, based on available information. To make those decisions as clear as possible, it is important to maximize the clarity and conciseness of information about the vulnerabilities. There are several factors a penetration test should help with to better enable effective prioritization:

1. Priority of the vulnerability. You need to prioritize the relative criticality of the vulnerability itself. This can often be measured by the CVSS of the vulnerability. Simply put, the higher the CVSS score, the more important the vulnerability tends to be. Many organizations rely on the CVSS score to prioritize – but keep in mind this is often not the complete answer.

2. Priority of the affected system(s). You need to know your assets where they live. This starts with understand which system(s) are affected by the vulnerability. Does the vulnerability affect many systems, or a single system? Is the affected system a critical system, or one that could provide access to critical organizational information? For instance, is the affected system in your PCI environment? You might be able to remove a single test node in a prototype environment, but could you remove the server cluster for your entire web-application server and database? Some systems are more important to your continued operations, and you need to consider the impact successful exploitation could have on each affected system.

3. Priority of the nature of the risk. For some organizations, and in some environments, a denial of service (DoS) attack could be a disaster. In others, it may not be as important. A privilege escalation vulnerability requiring local access is bad, but not as bad if an attacker cannot get local access to begin with. A vulnerability that leaks private data is likely significant. An exploit leading to system compromise and control is the Holy Grail for an attacker, especially if the exploit can be performed remotely, without authentication. The easier it is for the attacker to gain and maintain access, the more important it is to address the vulnerability.

4. Priority of the complexity of a fix. Some patches or mitigating controls are more easily accomplished than others. Some “fixes” may just be a simple system update for a single system an admin can accomplish in a matter of minutes. Some remediation requires patches across many systems – applying to one system might take 10 minutes, but if you have 200 systems to patch, it quickly becomes more complex. If the “patch” requires firmware updates, that is likely even more complex. If remediation actions require addressing your entire set of operational applications, including patched libraries and improved programming techniques, it is not something you are doing in a matter of minutes, or hours, or even days. And always keep in mind you can choose whether your organization can fix the vulnerability or if you apply other mitigating controls. You should absolutely consider setting higher priorities for vulnerabilities that are easier to remediate or mitigate.

The most important element in effective prioritization is getting the information you need to make intelligent decisions about your remediation or mitigation actions.

‍