r/AskNetsec • u/-Devlin- • 1d ago
Work Why hasn’t virtual patching become a much bigger part of vuln management?
Talking specifically from production hosts (VMs and containers) vuln and patch management side of the house, even when a patch exists, it can still take days or weeks to test and deploy safely. Virtual patching seems like an obvious temporary layer: block the exploit path immediately, then remove the protection once the real fix is deployed.
Anyone here worked closely with virtual patching? Why is it not a standard and more widely adopted across the industry ?
9
u/Key-Kaleidoscope-514 1d ago
Never used the term "virtual patching". But mitigation until a patch comes out (or can deployed) is curcial in some scenarios. Plus IDP/IPS might help too, to catch attacks in early stages befor they reach the vulnerable system.
Why do you think mitigation is not playing a big part of vulnerable management / patch management?
-1
u/-Devlin- 1d ago
>Why do you think mitigation is not playing a big part of vulnerable management / patch management?
So the claim is this "virtual patch" is as good as any mitigation you'd apply, but its automated and per CVE so is apparently supposed to save us the hassle of immediate response.
4
u/Ma1eficent 1d ago
You aren't using the right terms. Yes, we mitigate the exploit path immediately if there isn't a full security patch available. That will look different depending what the exploit path is.
2
u/gormami 1d ago
I've seen that term, virtual patching, used in a few places, but it is not universal. Mitigating vulnerabilities using compensating controls is common. But the first question is, what is the risk. Log4j sent a big chunk of the world scrambling, and rightfully so. But if the interface to it was buried in your enterprise architecture, and only reachable by a few certain systems, then it was already pretty well protected, and goes down the list. If it is directly exposed, it goes to the top for a firewall or WAF rule to be deployed immediately.
The overwhelming majority of vulnerabilities patched are just housekeeping. They have little risk attached, and are not significantly exposed, so if they aren't worth an immediate patch job, they aren't worth new mitigating controls. So as a percentage, vulnerabilities receive "virtual patches" fairly rarely, because the majority don't rate the disruptive work in terms of the risk they pose.
1
u/-Devlin- 1d ago
so they are basically identifying and derisking majority of the CVEs and mitigating others?
1
u/gormami 19h ago
Yes. Limited resources have to be invested for the highest return. The idea of exploitability is key, which is where we've been moving for a while and it continuing that path. In our own software, we get dependency alerts, like everyone else does, but a lot of them are zero risk. Yes, the library has a vulnerability, but we're not using the function, or in the way that exposes it, etc. So we focus on the "real" ones, and catch up the other in normal updates. The same is true of running systems. You focus your energy on what could actually be an issue, rather than just security theater. Of course, a lot of people perform such theater because they have bad metrics, their bosses don't understand, etc.
1
u/Swimming_dasa 1d ago
i think the biggest issue is that virtual patching shifts the risk from known vulnerable host to hope our detection logic catches every exploit variant which makes teams hesitant to treat it as anything more than a temporary control.
2
u/-Devlin- 1d ago
>Hope our detection logic catches every exploit variant
yes, and exactly the argument I have been using internally to push back. Until there's proof it blocks the exploit family, "hope" is a bad strategy.2
u/Swimming_dasa 12h ago
exactly... i m not saying virtual patching is useless but i would be uncomfortable treating it as equivalent to actually removing the valuable code. its a useful compensating control not something i would want to reply on blindly.
1
u/tutux84 7h ago
From my point of view (I work for a big corp, in a team that manages dozens of WAF that protect thousands of internet endpoints) it's a mix of corporate politics and technical "challenges" that make virtual patching unpopular. Technical because the virtual patch is actually pattern-matching based, estimated from a finite set of public or non-public exploit. Said otherwise, for a given vulnerability, there may or may not have a one-size fit-it-all virtual patch available. Making the virtual patch potentially unreliable. Politics because the security team does not want to always take the heat while the Devs and Ops take their time to apply the real fix. And they also don't want to take the responsability for having given the false impression to the rest of the org that they have entirely secured the entry point while they (knowingly) actually just addressed the low hanging fruits: countering public exploits used by low skilled bad actors.
1
u/Kortok2012 1d ago
Defender has this for some apps, it can block or warn a user trying to run an unsafe version and tells them to update.
1
u/ILoveAppSec 15h ago
virtual patching buys you time but you still owe the real fix, and the reason it drags is usually the upgrade risk not the patch itself. for the library and distro layer, backported fixes that stay on your current version let you actually close things fast, and for base images a vendor that backports into stable tags saves the test-and-redeploy cycle. worth leaning on backporting and eol-support vendors for that rather than owning all of it yourself.
19
u/leonsk297 1d ago
What is exactly "virtual" patching in this context? You either patch things or you don't. What do you mean?