Vulnerability Management is a Never-Ending Chase
The hot new CVE is out, which enables remote code execution with no (or minimal) authentication, affecting nearly all devices in the network, and to make matters worse, there is already a POC code available out in github. Sounds an awful lot like PrintNightmare?
And once again you start the chase.
The board has enough on their table, a ransomware attack or security breach is the last thing they need to worry about. The CISO is pushing for hourly progress reports from the vulnerability management team who are struggling to test, deploy and validate the latest patch.
So, after persuading business stakeholders on the importance of disrupting their service to deploy a patch, pulling favors from IT, and several sleepless nights, it’s finally done…. At least until next time.
Anyone who is in security, especially in vulnerability management, is familiar with this scenario. This is not only true for high-profile CVEs, but there are also dozens of new CVEs which require patching almost every month, forcing the vulnerability management team to chase down innumerable vulnerabilities in a never-ending cycle.
While we all agree that a patched system is better than a non-patched one, we must ask ourselves- what are the costs of chasing CVEs?
The Costs of Chasing CVEs
Patching often comes with high costs, and has several serious drawbacks:
- Discovering and patching vulnerabilities costs money. Even with the finest vulnerability management products, the process still requires a specialized team to operate.
- Patching takes time, according to one report it takes an average of 38 days to fully patch a vulnerability.
- Patching is disruptive and prone to error. Some applications might be incompatible with new patches or even worse, it might BSOD some of your machines.
Despite all these issues, enterprises still have to hire whole teams to patch vulnerabilities.
But what if there is a better way?
What if we have been treating the symptoms instead of the cause?
No Attack Surface, No Problems
As it happens, there is a better way to handle CVEs – ignoring them ;).
Or more accurately, handling them calmly, when it is convenient. Reducing – or even eliminating – the attack surface which exposes the CVE in the first place is the best approach. A remote code execution vulnerability cannot be exploited remotely if there is no network access. Man in the middle attack, denial of service, and many more attacks are mitigated with this approach.
To better understand this, let us consider several CVEs that made the headlines in the past years: EternalBlue, SMBGhost, BlueKeep and the recent HTTP RCE.
EternalBlue and SMBGhost are both vulnerabilities effecting the SMB protocol. While EternalBlue affected SMB version 1, SMBGhost applied to the new feature of SMB version 3. Consider this- the vast majority of assets don’t even need to expose their SMB service to the network. So, what if instead of patching every Windows 10 (and most Windows server machines) you could simply block all unnecessary SMB traffic, while only enabling it for your file servers? Wouldn’t this make life easier?
“Sure, but BlueKeep and HTTP RCE are a different story, because these affect protocols (RDP, HTTP and WinRM) which have to be accessible.” You may say. But, who doesn’t need to keep RDP open for remote connections or WinRM for remote administration? What if you could enforce Just In Time network access to these protocols, only after MFA is applied? That would immediately eliminate the risk from such attacks, or at the very least significantly reduce it as attacks are no longer “wormable”.
Stop Chasing, Start Protecting
With the Zero Networks Access Orchestrator, reducing the attack surface is as easy as protecting assets. Once an asset is protected, all network traffic is blocked except for required business activity. Privileged services (such as RDP, SSH, WinRM, RPC etc.) can be protected with Just In Time network access.
For example checking the attack surface of possibly vulnerable asset (or a group of assets) to EternalBlue can be done by looking at the network access rules, after applying the filter for port 445. For example, in our network (yes, we do eat our own dog food) the only asset with an exposed SMB port is our SHARE server, all other SMB traffic is blocked:
In this case, if there is a new SMB vulnerability, only one host needs to be patched instead of patching all of your hosts.
Additionally, the Access Orchestrator can ingest vulnerability data, which can be used to prioritize assets for protection. For example, our integration with Microsoft Defender for Endpoint (AKA Microsoft Defender ATP) allows the user to immediately put assets with CVEs, which are remotely exploitable, into protection:
Zero Day - The Impossible Patch
There are threats for which no patch exists, namely the dreaded zero days. While you can't patch for an unknown bug in a service, limiting the initial network access to services (through microsegmentation) significantly reduces the risk from unknown threats. Considering some of the examples we have already discussed, if services such as SMB and RDP are not network accessible, than you are protected from the next EternalBlue or SMBGhost.
Summary
In conclusion, security teams can greatly benefit from reducing the attack surface, especially when they are trying to reduce costs of vulnerability management and mitigate “wormable” attacks such as ransomware.
If you are also tired of chasing CVEs, we would be happy to hear from you!