Managing the VirtSec Problem: Plan Today
What should enterprise IT departments be doing today to protect themselves from current and future virtualization security threats? First and foremost, they should analyze their risk level with their particular use of virtual platforms. It's critical to know how this architecture change will impact existing security management systems. They should also make both tactical and strategic security plans before migrating to or implementing new virtual machines. This is achieved through a combination of assessing existing virtual security threats while also planning for future security threats against the virtual platforms. Planning coupled with small changes in architecture and security management today can help guard against future hypervisor and platform-level virtualization attacks.

In general, IT departments should focus on three virtualization areas as part of their entire virtualization security architecture:

1. Segmentation of VMs by location
2. Segmentation of VMs by service type
3. Proactive security management throughout the VM lifecycle

These three areas will help IT departments protect their virtual infrastructure against current threats as well as help mitigate the threat of future attacks.

Segmentation by Location
One of the most frequently discussed topics in virtsec is the use of virtual platforms in the DMZ. It is somewhat typical to see a single physical VM host running both public and private VMs in the DMZ with the segmentation between the two security realms occurring at the software switch level. While practical, this architecture is slightly more insecure than the same architecture in the physical world because of the shared running environment. In the physical world, where public machines might be plugged into the same switch and VLAN'd off from the private machines, there is a separation in compute resources (CPU, RAM, bus, network). With virtual platforms, this compute segmentation is gone; all VMs on a single host share CPU, RAM, bus, and network resources. In theory, this shared VM architecture provides a direct line of attack from the public network to private virtual machines, thus increasing the risk of an external attack. This is the equivalent of putting all your DMZ eggs in one basket; everything on the virtual platform is shared and managed by the same software. The software that controls VLAN segmentation also controls the IP stack for the host. A software exploit against the IP stack on the host puts the entire guest network at risk.

The solution to security threats against shared DMZ resources is to physically segment public VMs from private VMs, running and managing them on separate hosts. All public-facing VMs should reside on public-facing host servers that are cabled into physically segmented networks. For larger scale implementations using tools such as VMware's vCenter, it's also critical to segment public and private resource clusters (groups of host machines clustered into single-management pools by resource). VMware's DRS, for example, can dynamically move VMs between hosts within a cluster. If public and private hosts are shared within a single cluster, it could be possible for a DRS event to move a private VM to a public host server based on resource need, thus nullifying any resource segmentation benefits.

Segmentation by Service
Once virtual resources are segmented by location, the next step is to separate virtual machines by role or service - in other words, keep all web server VMs in one resource pool and cluster, and keep all application VMs in another resource pool and cluster. Like location segmentation in the DMZ, this architecture is designed to limit the risk associated with a virtual platform compromise. If an attacker is able to compromise a guest VM, it should be assumed the other guests running on the same physical host are compromised due to the shared running environment. If all of the VMs running on a single host are identical and performing the same task, then there is less exposure across systems - an attacker has no benefit in exploiting 10 VMs rather than one.

If, on the other hand, a single host server is running all application tiers (the web server, the application server, and the database server), an attacker can gain access to the back-end database server by exploiting the front-end web server and using a guest escaping attack. The database is now more at risk simply because it's running on the same host as the web server and sharing the same resources. Segmentation by service helps mitigate this risk by isolating VM applications and keeping them bound to singular hardware resources and clusters. An exploit against one type of VM role won't directly place other VM roles at risk.

Proactive Security Management Throughout the VM Lifecycle
One of the primary benefits of virtual machines and platforms is the ease in creating, moving, and destroying VMs. When new services are needed, VMs can be created or pulled from the archives and provisioned by demand. As demand increases, VMs can be cloned and/or dynamically allocated to additional hardware resources. As demand decreases, these VMs can be de-provisioned so they are no longer consuming resources. The VM creation, mobility, and destruction processes comprise the VM life cycle.

At each step in the life-cycle process, the VM is vulnerable to security threats. When creating new VMs from scratch, it's important to make sure they are current with security patches and software. When cloning images and moving them around, it's critical to maintain a "state level" on each VM asset to know if it's currently patched or if it needs to be updated. It's all too easy to repeatedly clone a patched "gold" image and end up with various VMs at various patch levels over time. As images are stored unused for long periods of time, they may become out of date and require offline patching between usage to guarantee they are as secure as possible when they next boot. Like migratory VMs, asset management is important for VM destruction and protection against rogue VMs floating around the data center, providing an unknown threat vector.

Conclusion
The most important fact to remember about virtual platforms is that although they introduce an additional layer of management and security risk, their level of risk is one that we deal with every day. It is possible to implement a successful virtual infrastructure migration if these virtualization technologies are factored into the security plan before, during, and after the virtualization roll-out or migration. Planning ahead today by pushing data center security best practices onto the virtual platforms and managing security from day one can lead to a successful virtual deployment, one that can be more secure than its physical counterpart. Security best practices in the physical data center are just as applicable as in the VDC: network segmentation by VLANs on the software switch; isolated management between segments based on proper authentication and authorization; expert level support for troubleshooting; and diagnosing problems on the virtual platform and network levels. While there will ultimately be a thriving virtsec market specifically for virtual deployments, all those virtsec tools will be rooted in solid security practice and implementation. Although the lay of the land might have changed, implementing security in the virtual data center will come down to the same core tenets that have contributed to the success of physical-world counterparts: knowledge of the IT environment, informed risk management, and adaptive planning before, during, and after deployment.

Reference
1. Forrester Research, Enterprise and SMB Hardware Survey, North America and Europe, Q3 2007