All about Virtualization and Cloud Security | Recent Articles:

In my last blog post I began a conversation about virtual patching. In this post, I’ll further the discussion by talking about why effective virtual patching at the network is so difficult.

The story really begins by considering context, or really, the lack thereof. If a vulnerability exists in an application (a web application, or a browser) there is a certain context associated with the application that is difficult to be aware of at a point outside of the application. The simplest example is a session. A web application may create a session when a user logs-in, destroying the session after a period of inactivity, or when a user logs-out (and when was the last time you logged-out instead of just closing the browser window?).

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.