All about Virtualization and Cloud Security | Recent Articles:

In this post, I’ll focus on Infrastructure providers (IaaS), though these points may be relevant to platform and software providers as well.

Infrastructure providers tend to be very good at providing security inside the infrastructure. However, not all providers go beyond infrastructure security. Instead, the model is to have a shared security where responsibility for security beyond the infrastructure is in the hands of end-customers.

In the simplest example, the provider sets-up a virtual instance running, say, Windows, but everything that runs within that instance, including operating system and applications, is the responsibility of the end-customer. On the IaaS side, this is completely reasonable theoretically, but it has potentially damaging results if the end-customer isn’t taking further steps to protect the OS or the apps.

Best interests and the role of security

The driver behind server virtualization is clearly cost savings, while agility and flexibility also have value. This well-known return on investment is achievable because servers have fairly predictable workloads, tend to be rather static in their workloads (an Exchange server tends to stay an Exchange server).

Also, the number of servers that can be run on each CPU across a datacenter tends to be low because, generally speaking, they need more horsepower than an end-user system.

Virtualized desktops are quite different. The number of desktops per-CPU across a Virtual Desktop Infrastructure (VDI) is much higher than with servers. The environments tend to be highly dynamic, with instance being instantiated and destroyed at a high rate.

Naturally, trying to lead with cost savings as a primary goal of a VDI deployment is problematic. Instead, agility and flexibility are key.

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.