The Common Vulnerabilities and Exposures (CVE) database from MITRE had some 12,174 entries for 2019 alone. You may well know that the CVE is a dictionary of publicly known information security vulnerabilities in software.
Why so many? Software development is not a perfect process. Programmers work hard and fast to meet deadlines and may be challenged to find each bug or error in code, leading to a vulnerability, or a software flaw, that can be exploited.
Patch me if you can
Software vendors (hopefully) release a patch or software update to fix the vulnerability as soon as they can, keeping the window of vulnerability to a minimum so attackers have less chance of success.
All things being equal, organizations that use vulnerable software will do their best to deploy the newly available patch.
However, it isn't always that simple. Rebooting servers in a data center supporting key business applications is not always feasible right away – even when a patch becomes available. You may have to test the patch, which takes some time. Teams responsible for patching must often engage with other departments, delaying patching.
ServiceNow recently examined the time it takes to patch and found it takes some 16 days to patch the most critical vulnerabilities.
What happens when very old software is no longer supported by the vendor? It can't be patched, representing a healthy amount of security risk. We often see that in manufacturing or industrial plants running older, though still functional, operating systems or software that are now out of support from vendors.
So then what?
We have software vulnerabilities that can be targeted for at least a couple of weeks before organizations patch, combined with older software that is tough to update. Where does that leave us?
It leaves us looking for an accurate picture of risk coupled with the need for compensating controls to mitigate vulnerability risk while teams work to patch.
See and control vulnerability risk
We have long used vulnerability management to assess vulnerabilities and understand the associated risk. But as we've established, we cannot always patch immediately so we must find a compensating control – and this is where segmentation comes in.
A segmentation solution that works with vulnerability management tools should enable you to visualize vulnerability risk and exposure, but also take action by using segmentation to reduce the attack surface by removing all unnecessary pathways in an environment.
Vulnerability risk scores
With Illumio, you can overlay vulnerability score data from Rapid7, Qualys, or Tenable (or any vulnerability scanner) to see the risk score for an entire application and risk for each application workload. Using workload, application, and connectivity context, you also see the exposure score for East-West traffic. The score is calculated based on how many workloads can potentially exploit the vulnerabilities on any given workload. The lower the score, the smaller the chance that a bad actor can exploit it.
We combine these two scores to give you a Vulnerability Exposure Score, showing highest risk workloads considering both vulnerability criticality and "reachability" in an environment. This shows teams where to begin patching.
Automated segmentation as a compensating control
If patching is not available, the optimal way to reduce exposure is to use segmentation to reduce the number of workloads that can connect to it.
Using our Policy Generator, you can automatically create policy recommendations to further tighten segmentation based on new vulnerability risk information.
With the risk visualized, making segmentation a compensating control to reduce the attack surface is possible in a few clicks.
Vulnerability risk scores after using segmentation as a compensating control
These tools working together can be a powerful solution to reduce risk.