Virtual Patching is What, exactly?

I have read quite a bit about virtual patching over the years. Asking Google for a definition and going with one of the first hits I found this reasonable explanation from OWASP:

“A security policy enforcement layer which prevents the exploitation of a known vulnerability.”

 

Really, it’s something on the network or on an endpoint that inspects traffic, most often HTTP(s) for signs of an attempt to exploit a vulnerability (usually in a web application). 

Things other than web applications can be protected, but robust protocol decoding is important, else trying to find an exploit attempt is like hunting for deeper meaning in a book written in a language you don’t understand. Most often, IDS/IPS and Web Application Firewall vendors talk about virtual patching. Reversing the HTTP stream, it can also be used to protect end-user systems from some exploit attempts.

Organizations like the idea of virtual patching because it, theoretically, can protect something from exploit until it is properly patched (as-in, remove the vulnerability). In the case of custom web applications that an organization has built in-house, it can be complicated and costly to fix the application. 

 

The limitations of Web Applications Firewalls

It all sounds great, but there are some limitations. In the case of web applications, WAFs need to get pretty sophisticated (read, complicated) because the web applications they are protecting are pretty complicated. Also, the difference between a valid exploit attempt (true positive), something that looks kind-of like an exploit attempt but isn’t (false positive), and something that doesn’t look exactly like an exploit attempt but really is one (false negative) can be hard to pin-down.

Those fine differences are also very hard to pin-down on the client side of HTTP. Web browsers are designed to be forgiving when parsing web pages, because that’s what end-users and web developers want. Web applications also often push some parsing to web browsers (JavaScript navigation menus, for example), pushing to make the application friendlier.

This complexity often leads organizations to run virtual patching in detect mode, rather than risking business disruption. While this provides some information, someone has to look through the available information and try to figure-out if detections are true or just false positives. This, of course, doesn’t account for false negatives. 

 

The time and money trade-off

As with many things in security it becomes a trade-off. The complexity of implementing protection via virtual patching means there is cost, especially in time and effort. For third-party applications, is likely simpler, and therefore less expensive, to just patch the application. In rare cases, a robust (which rhymes with “expensive”) WAF can be a good option. Those rare cases involve horribly complex web applications where the time and effort of patching, especially emergency patching, is greater than the time and effort of the WAF.

Protection which inspects information at, or preferably below, operation of the mechanism that is vulnerable seems to make more sense. If it’s a web application that has a SQL injection vulnerability, permissions at the datastore level (down to the record or object level, if possible) can solve many issues. If it’s a vulnerability in the operating system or application on a client or server, inspecting the behavior of that process from a lower level than where the vulnerability runs is a better method than looking at the input to that process. For example, examining the behavior of a user-mode application from kernel-mode is better than inspection from equal privilege, though there are exceptions such as inspecting activity in a database.

Simply put, moving protection higher in the stack, or farther from the source (in the case of perimeter inspection), forces that protection to be broader. For this reason, network-based virtual patching is, at the very best, a temporary, and flimsy, method of protection. At worst, it’s an easily bypassed method of producing massive numbers of logs. It’s all in the implementation, of course. I will post further entries that get into some details and examples.

Stay tuned for more on this topic and our upcoming Paper about Active Virus Control (AVC), our approach to Host Intrusion Prevention (HIPS).