Most ransomware gangs gain their foothold in an organization by taking advantage of at least one vulnerability. The vulnerability may be on a user workstation after the criminal has gained initial access through a phishing campaign, or it may be on a firewall that has a vulnerability that has not yet been fixed. Managing vulnerabilities should be a focus of your security program to ensure that the most dangerous vulnerabilities are remediated as quickly as possible.
The term “vulnerability” in the context of cybersecurity can mean many things. Vulnerability management is NOT patching, although patching is part of vulnerability management. A required patch that has not been installed on a system is a vulnerability. A system which has reached its end of life is a vulnerability. A misconfiguration of a system that leaves it open to an exploit is a vulnerability. In short, any weakness in a system can be a vulnerability.
As important as vulnerability management is, it is just as important to know that your organization will NEVER get to a point where it has no vulnerabilities. That is because new vulnerabilities are found as quickly (or sometimes more quickly) than an IT department can remediate them. It is not uncommon for a medium-sized company with a healthy vulnerability management practice to have thousands of vulnerabilities on their dashboard. When I look at a vulnerability management program, I want to make sure that the number of outstanding vulnerabilities trends down or flat. If the vulnerability count trends upward for more than three months, I know that there is work to be done.
The focus of any vulnerability management program should be to remediate from the outside in, and to remediate the most dangerous vulnerabilities first. What I mean by “outside in” is that any vulnerability on an “edge device” (a device that has an IP address directly accessible from the Internet) should be knocked out first. Attackers are very tuned into any vulnerability published for firewalls, VPN appliances, web portals, email servers, and any other system that by its very nature needs to be visible on the Internet. It is not uncommon today to see attacks start within minutes of a vulnerability being announced. If you hear of a new vulnerability on an edge device, you need to remediate it or somehow mitigate the risk as soon as possible. There should ideally be no vulnerabilities found in an external scan (that is, a scan of the company’s public IP addresses from the Internet), and if there are any, they should be low-risk vulnerabilities, they should be reviewed, and the risk should be formally accepted.
Once vulnerabilities on edge devices have been addressed, internal vulnerabilities need to be prioritized. One way of prioritizing vulnerabilities is based on a risk score provided by the vulnerability management system. Most systems provide CVSS scores, which are a standard way of rating vulnerability risk that can be a good starting point. CVSS scoring is on a 1 – 10 scale, and any vulnerability rated a 7 or up should be dealt with first. CVSS has its problems, however, as anyone who has had a penetration test fail because of a vulnerability rated as a “5” can tell you, so many vulnerability management systems also provide their own risk-scoring system. Regardless of the scoring system you choose, you should also learn which are the moderate-risk vulnerabilities that are most often used in penetration tests and make sure those are remediated as if they were high-risk. If you do not know what these vulnerabilities are, speak with the auditors who do your penetration testing and they would be happy to tell you!
Vulnerabilities that are scored by CVSS in the 4 – 6 range are normally (except for the vulnerabilities discussed earlier) less harmful and can be generally dealt with after the higher-risk vulnerabilities, and those that are scored in the lower 1 – 3 range normally do not represent much risk at all. Still, you should look at them to make sure.
Besides focusing on vulnerabilities based on risk, I also urge IT departments to also look at vulnerabilities grouped by vulnerability, by age, and by asset, as doing so will help identify pockets of larger numbers of vulnerabilities that can be addressed through single actions. It is not uncommon to find a single workstation which has missed multiple months of patches have hundreds of vulnerabilities. Patching a few of these systems can result in a significant drop in your vulnerability count. Likewise, you may be able to find a moderate-risk vulnerability with a thousand instances that can easily be remediated by deploying a simple global policy. You get a lot of bang for your buck by grouping!
Finally, make sure that you establish some metrics and goals for vulnerability management. The simplest metric is the number of outstanding vulnerabilities, usually broken down by risk level. The goal here should not be a certain number but should instead be for there not to be more than two months of upward trend in any of the risk levels. If your system supports it, another good measure is the number of overdue vulnerabilities based on the date the vulnerability was first detected and on the risk level of the vulnerabilities. High-risk vulnerability remediation may be due within 30 days, moderate-risk within 60 days, and low-risk within 90 days.
If your institution has problems managing its vulnerabilities, we have a lot of other good ideas! Please reach out to us at support@bedelsecurity.com!