Security considerations for virtual environments

The cost benefits of virtualization are well-documented, allowing enterprises to significantly reduce the space and electrical power required to run data centers and streamline the management of an ever-growing number of servers.

Virtualization also provides means for expedient scalability. Given today's economic climate and cost-cutting mandates, it is not surprising that analyst firm Gartner recently predicted that 50 percent of workloads will run inside virtual machines by 2012.

What many organizations fail to understand, according to Amir Ben-Efraim, CEO of virtualization security provider Altor Networks, is that collapsing multiple servers into a single one with several virtual machines inside eliminates all firewall, intrusion detection, and other protections in existence. Physical security measures literally become "blind" to traffic between VMs, since they are no longer in the data path.

This echoes comments made by Gartner analyst Neil MacDonald, who wrote in a recent presentation titled "Securing the Next-Generation Virtual Data Center" (subscription required), that "most virtual machines you deploy will be less secure than the physical systems they replace," and that "virtualization will radically change how you secure and manage computing environments."

VMware recently launched a partner program to help ISVs develop solutions certified as "VMsafe." VMsafe provides API sharing through a secure container, enabling partner companies to access virtual environments. This virtual security technology provides fine-grained visibility over virtual-machine resources, including monitoring every aspect of the system with the ability to address previously undetectable viruses, rootkits, and malware before they can infect a system.

I spoke to Ben-Efraim to better understand the issues around VM security and for what users should be on the lookout. According to him, there are two common approaches that use existing methods to secure virtual-network traffic: using VLANs to separate and control communication between VMs; and taking software-based firewalls and running them as agents on each VM. Unfortunately, both of these approaches fall short.

VLAN segmentation extends the notion of LAN resource segmentation to include VMs. The approach essentially requires that VMs, which can naturally be grouped (i.e. by function or user base), be isolated from other VMs by use of virtual switches and routing (i.e. the human resources VLAN contains HR-serving VMs). However, VLAN segmentation is not a permanent solution to securing environments because of networking complexities, performance degradation, and security limitations of the approach, Ben-Efraim said.

The use of VLANs requires routing VM traffic out of the ESX host (the VMware virtualization solution) and directing it to a physical firewall, Ben-Efraim said. This not only introduces performance-affecting latency, but also requires some fairly complex networking in order to support dynamic resource pooling and live migration. Despite all of the effort invested with VLAN-based segmentation, VM-to-VM communication is not comprehensively secured. Malware, for instance, which infects one VM, can't be stopped from spreading to other VMs on the same VLAN, he said.

Implementing software-based firewalls used as agents that run on each virtual machine also seems like a reasonable approach because it lets users buy a familiar product. But as the number of VMs increase, so, too, does the number of agents that must be managed, creating an extremely costly solution, in terms of both price and management complexity.

Security too, is less than optimal with the agent-based model in that there is no protection for the hypervisor (i.e. the virtualization operating system), so attacks that strike by turning "off" VM-based services can bypass agent-based protection.

Virtual networks have many unique features and functionality, compared to a physical server environment, and they thus require a security solution that is architected specifically for protecting inter-VM traffic without detracting from virtualization's value, Ben-Efraim said. He gave me a few examples of things to look out for when deploying a virtualized environment. (Note: I asked him to focus on VMware solutions, as they are the most prevalent in today's data centers, and Altor recently became VMsafe-certified.)

• VMs have Internet Protocol and MAC addresses (for each virtual-network adapter), but those change when a VM moves or goes to a different physical host. Any security policy that has been explicitly defined to protect a VM must be adhered to the VM by its, in the case of VMware, Universally Unique Identifier (UUID), rather than the MAC address; otherwise the security "breaks" during VM migration.
• VMs can move from ESX host to ESX host, in order to take advantage of capacity and memory that will optimize performance. Traffic flowing through this VM should not be impeded. So if, for instance, a virtual firewall is statefully handling a session into and out of a VM, the session should continue, as should the application of the security inspection, without disruption. Security policies can carry over as well, provided that they are not tied to a specific address.
• Rather than having IT personnel prepare and connect a physical server, they can simply clone an existing VM, and have it up and running in minutes. The new VM will simply inherit the settings of the parent. However, the inheritance needs to include the security policies and applications in existence for a VM of that type.

When implementing virtualized networks, system architects need to take security into account from start to finish. A solution that's not secure compromises not just one server, but potentially hundreds of virtualized instances.