AWL meets VirtSec: More of the same, just faster

Given the intense industry focus on cloud and virtualization and the perception that security is a huge impediment to adoption for both - let's take a look this month at the hype vs. the reality of the so-called VirtSec.

Since this is intelligentwhitelisting.com, we'll obviously look at VirtSec within the prism of application whitelisting. That means we won't discuss the impact of virtualization on network security, but remember that too is important because how you provision firewalls, IDS/IPS, and network monitoring must change in a virtualized data center.

From a host-centric perspective, we first need to think about the attack vectors of a virtualized environment and how that differs from the physical counterpart. For those of you hiding under a rock for the last three years, the concept of virtualization is to have a software abstraction layer run on each physical server, called the hypervisor, which coordinates the running of multiple "guest" operating systems on that server. The guest can be any OS that supports running on a virtual machine, but practically that means Windows or Linux.

The advantage of running a virtualized environment is the flexibility of being able to provision and de-provision new "servers" at will (called virtual machines or VMs), as well as move the VMs around to different physical servers as necessary. But the technology does add some additional attack surface in that the hypervisor can be attacked, and if it's compromised the attacker would gain access to all the guests on that machine or perhaps within the entire virtualized environment.

The guests that run on the hypervisor are just like any other server operating system. That means most organizations can (and should) use their existing security controls, including patch, configuration, anti-malware and application whitelisting on each guest, just as if it was a regular server. That means if the use-case calls for a locked down server, then application whitelisting would be a good fit, just like in the physical world.

Here's the rub: Everything happens faster in the virtualized world. You can spin up servers quickly. You can move them from place to place. You can clone them with a few clicks of the mouse. For better or worse, this creates a situation where weaknesses in the control sets of these servers will be exacerbated under a virtualized scenario. This makes the case for application whitelisting on the virtual servers more compelling.

Why? You tend not to have a lot of new applications added to a machine frequently in the data center. A server will have a purpose (application, database, domain controller, email, etc.) and typically many operational environments separate duties, so you won't have servers in a multiple-use scenario (domain controller + database). This means you have a very good idea of what executables should be running on each server and can configure a whitelist appropriately to make sure unauthorized executables run.

One of the major perceived issues with application whitelisting is how it impacts the user experience (and not in a good way). Unless your data center is self-aware, this shouldn't be a problem on your virtualized servers. If your datacenter is nicknamed SkyNet, you probably have bigger problems than maintaining the whitelist, but I digress. Thus, spinning up a virtual database server, with application whitelisting on the master DBMS image, using a policy allowing the specific (and only those) executables required by the DBMS can provide adequate lockdown for servers that can come and go quickly.

Of course, whitelisting doesn't address any kind of hypervisor vulnerabilities. So you'll want to ensure you've built some threat models to understand how a hypervisor attack will be handled by your existing controls and deal with the gaps. But it's not like you'll be given a choice here. Virtualization is happening, so you need to get out ahead of it. I'm a big fan of locking down these virtual devices where possible using application whitelisting.