Virtual patching is the process of addressing a security vulnerability by blocking an attack vector that could exploit it. Let's explore the origin of this term and take a look at the manner in which virtual patching could be implemented.
Origins of Virtual Patching
I first heard the term virtual patching around 2003, when Internet Security Systems integrated its vulnerability-scanning tool with its intrusion detection/prevention products to block exploits that targeted identified vulnerabilities. The usage of the term persisted. Later, it began appearing in the context of network and host-level IPS as well as database and web application security products:
- TippingPoint (now a part of HP) introduced the Digital Vaccine feature to create a virtual patch "within the network to protect downstream hosts from attack" as part of its network intrusion prevention system.
- Hedgehog vPatch (now a part of E-SPIN) security product for databases began offering a way to "protect the database against exploits without actually patching the DBMS kernel."
- Qualys’ vulnerability management service was integrated with Trend Micro tools to help customers "accurately prioritize remediation activities and take action to keep data safe" in part through virtual patching.
- Web application vulnerability scanner WhiteHat Sentinel was integrated with F5 BIG-IP web application firewall (WAF) to make it easier to identify and "fix the problem with the click of a button" using virtual patching.
- In another WAF example, Imperva SecureSphere was integrated with Qualys to implement virtual patching so that its customers can "quickly mitigate against discovered vulnerabilities."
The concept of virtual patching gained an especially strong foothold among web application firewalls (WAFs) and started being emphasized by most WAF vendors even if they didn't use this term. For a good overview of how WAFs can be used to implement virtual patching, see Michael Shinn's article Virtual Patching for Web Applications with ModSecurity.
The Usefulness of Virtual Patching
The desire to implement virtual patching stems from the challenges organizations encounter when trying to keep up with the deployment of security updates to custom and off-the-shelf applications. Vulnerability management is a bear that few enterprises have tamed due to the numerous technological and business reasons that I won’t get into here.
Applying a virtual patch through the use of an IPS or a WAF buys the organization time to develop, test and install the fix to the underlying vulnerability. That is very valuable and is, in my mind, the reason why we’ll continue to see the increase in the adaption of virtual patching practices.
The Dangers of Virtual Patching
The biggest limitation of virtual patching is that it addresses some, but not all, ways in which the vulnerability might be exploited. For instance, a custom rule implemented on a WAF to block access to a particular vulnerable web page might not address an issue on another web page that makes use of the same vulnerable code.
The danger of virtual patching is that with the virtual patch in place, the organizations has few incentives to move forward with fixing the underlying vulnerability despite the limitation outlined above. Virtual patching encourages complacency and is risky for the enterprise in the long term.
A virtual patch is a temporary band-aid. It might be well-suited to address a particular threat vector; however, it rarely offers the long-term benefit of actually fixing the problem that exposes the affected system or application.