Blogger: Trent Henry
Burton Group’s Catalyst Conference is in the rear-view mirror now, but we continue to get questions from clients about some of the talks we gave. One that I delivered was called “Security, Audit, and Compliance in Virtual Environments.” (If you’re dying to see me actually wander the stage in full-motion video, check it out at Catalyst Replay: www.catalystreplay.com [pay site].)
Generally speaking, auditors are in the early stages of figuring out the implications of virtual environments, whether VMware, Citrix XenServer, Solaris Containers, or even mainframe LPARs (although they tend not to worry about mainframes—IT auditors have history and comfort with them). PCI DSS is causing the first set of issues, because of two requirements. First, “Implement only one primary function per server.” Virtual machines muddy the interpretation of this:
Some QSAs take a strict interpretation, and don’t feel that any application processes should coexist on a physical host. Others believe the hypervisors offer a meaningful level of isolation, and therefore applications running in separate guest OSes are not problematic. The PCI Security Standards Council has created a special interest group to clarify guidance here, and virtualization vendors have joined the group to weigh in. The second troubling requirement is “install and maintain a firewall,” but more on this in a moment.
As I spoke with auditors and clients about virtualization security, a number of questions arose. None of these has been consistently addressed by the industry, but we could be at loggerheads soon:
System separation is a particularly galling concern, because the notion of “firewall” can be quite different in a virtual machine than on a copper-connected network. Is a virtual security appliance sufficient? Can host-based firewalls serve in lieu of network ones, especially to protect peered hosts that share intra-VM traffic on the same physical server (that is, only the virtual switch is used for communication)? Must we employ software that taps hypervisor privileged APIs like VMsafe or Xen Introspection? Or should we backhaul traffic from virtual switches to traditional network firewalls? (Yikes.)
A final consideration is something I call “controls on the move.”
The beauty of virtualization is the flexibility it provides, especially in moving workloads from underutilized machines to help with power management (green computing, and all that…) But notice in the graphic that when we rely on a virtual security appliance to protect guests, in-motion workloads can cause some problems of control inconsistency. Namely, if not every machine in a cluster is configured with the same security controls (e.g., IDS, firewall, monitoring), a guest OS could find itself dynamically moved and effectively stripped of some of its protection: That makes both auditors and security teams unhappy. The answer is to ensure good cluster configuration management—that all machines have a common set of protections. But not every vendor or every enterprise has managed that. An alternative is to focus on host-based controls, so each guest OS has its own security detail no matter where it travels. But this has issues, too, not the least of which is licensing cost.
There’s more to discuss, but this is a starting point. The bottom line is that virtualization is a wonderful technology but has to be approached with balance: audit and security, not only flexibility, are important.
You raise some good issues here. But I think most of these are solvable problems. Of course, I'm biased.. I work at Altor Networks and we make a virtual firewall that addresses virtualization security concerns.
We use VMsafe to integrate into the hypervisor. Being embedded into the platform allows us to wrap each VM in a firewall policy to address the intra-VM communications within the hypervisors. You get the per-machine policy of a host firewall, without all the disadvantages (OS support limits, exposure to malware in the machines, lack of separation between security & sysadmin, etc.)
As for the 'policy on the move' issues, in our model the policy and session state table follow the VM as it migrates. Typically the firewall is deployed on all the hypervisors in the cluster that a VM can migrate to -- with an automated installer that simplifies this process. But, if there were some misconfiguration and a VM migrates to a non-firewalled hypervisor, the administrator has chosen whether this results in blocking traffic to ensure security or allowing connections to maintain availability.
There are certainly challenges in securing a virtual infrastructure. But, being able to embed into the hypervisor, hook into the management layer, and automate security deployment gives some huge advantages over what can be done in physical network security.
Posted by: Todd Ignasiak | August 21, 2009 at 08:19 PM