Tech Support
Documentation
Login
Contact Us
Live Patching vs Virtual Patching
Joao Correia
November 18, 2022 - Technical Evangelist
There are many different ways to improve upon traditional patching, so it’s easy to get confused about how each patching approach works. In the past, we’ve looked at traditional patching vs live patching, but we’ve also received questions about virtual patching and how it stacks up.
In this blog post, we’ll explore the differences between live patching and virtual patching, describe the situations in which each is most useful, and help you decide which is the best choice for your own environment.
Live Patching
Let’s start with live patching: it’s the process of patching a running application directly as it is running, in memory. The files on the disk are not touched, but every instance of the application or library that is currently running will be updated to reflect the latest patched version. If you restart the application, it will restart as what is currently on disk and any live patches will be reapplied by your live patching application after it launches. TuxCare’s KernelCare Enterprise solution is a perfect example of this.
The main benefit is that patching becomes a non-disruptive action, and patches can therefore be applied more often – enabling you to respond faster to new threats.
Live patching can, when implemented correctly, protect a system from many different types of vulnerabilities, irrespective of such vulnerabilities being remotely exploitable or local-only. This protects against vulnerability-chaining, that is, when a local-only exploit is deployed after another vulnerability allows remote access (or even through a compromised valid remote access).
Virtual Patching
Now let’s take a look at virtual patching. Virtual patching is the process of blocking a known exploit at the network level. It operates at the firewall level, either locally to protect a single system or at the perimeter firewall level to protect the systems behind the firewall.
Virtual patching specifically targets remote-only exploitable vulnerabilities, so if a malicious actor compromises the remote login of a valid user and then deploys a local-only exploit to gain privilege elevation, virtual patching would not protect against it. In fact, virtual patching does not actually “patch” anything – it simply prevents the attacker from remotely exploiting some vulnerabilities.
Virtual patching relies on known network “signatures” or profiles, and can thus be defeated if the attacker adds additional encryption layers or changes some part of the known-attack path. It’s best considered an additional layer inside the firewall rather than a true patching solution, similar to what application-level firewalls do.
However, if the attacker manages to bypass the firewall, then the protection will not work at all. In fact, if multiple systems rely on that firewall for protection against vulnerabilities, then bypassing the firewall (either through encryption, remote access, or changing the attack signature) means that all systems will be at risk.
When it blocks an attack, to an outside actor it will simply appear as if it has not worked, so that actor might assume the system being targeted is not vulnerable or has indeed been patched (hence the name). As with live patching, at no point are any files updated.
Conclusion
Additional layers of security are always desirable. That’s why we have firewalls, patching, anti-virus, and a series of other tools to elevate the security profile of a system or environment – but virtual patching does not replace live patching. Each class of patching mechanism has different goals and operates at different levels in an IT infrastructure.
If you’re concerned about keeping systems running securely and want to close the most amount of security issues, either locally or remotely exploitable, then live patching is the best solution for your situation.
If, on top of that, you want to add virtual patching, consider it as a network level protection – not system-level patching.
