Practical App

Virtual Clouds: Top 4 Security Concerns

Using virtual machines within the context of a cloud computing infrastructure poses some interesting security challenges. Here's what you need to be aware of before implementing any cloud project.

• By Vic Winkler
• 02/01/2012

Adapted from "Securing the Cloud" (Syngress, an imprint of Elsevier)

Virtualization is transitioning from the technology that drives server consolidation and datacenter operations to a key ingredient in creating a flexible, on-demand infrastructure -- another way of describing cloud computing. While there are certain issues to address when adopting virtualization in any environment, there are additional security concerns that arise when using virtualization to support a cloud environment.

When adopting virtualization for cloud computing, it becomes evident that the management tools used in a physical server-based deployment won't suffice in a highly dynamic virtualized one. To begin with, in a physical server deployment model, provisioning automation is generally not as heavily used unless there's a significant enough number of server OSes to warrant doing so.

The typical strategy for provisioning physical servers involves repetitive steps. In a heavily virtualized environment like the cloud, OS provisioning will rapidly transition to being a highly automated process.

A New Threat
Virtualization alters the relationship between the OS and hardware. This challenges traditional security perspectives. It undermines the comfort you might feel when you provision an OS and application on a server you can see and touch. Some already believe this sense of comfort is misplaced in most situations. For the average user, the actual security posture of a desktop PC with an Internet connection is hard to realistically discern.

Virtualization complicates the picture, but doesn't necessarily make security better or worse. There are several important security concerns you need to address in considering the use of virtualization for cloud computing.

One potential new risk has to do with the potential to compromise a virtual machine (VM) hypervisor. If the hypervisor is vulnerable to exploit, it will become a primary target. At the scale of the cloud, such a risk would have broad impact if not otherwise mitigated. This requires an additional degree of network isolation and enhanced detection by security monitoring.

In examining this concern, first consider the nature of a hypervisor. As security consultant and founding partner of Nemertes Research Group Inc. (nemertes.com), Andreas Antonopoulos has observed, "Hypervisors are purpose-built with a small and specific set of functions. A hypervisor is smaller, more focused than a general purpose operating system, and less exposed, having fewer or no externally accessible network ports.

"A hypervisor does not undergo frequent change and does not run third-party applications. The guest operating systems, which may be vulnerable, do not have direct access to the hypervisor. In fact, the hypervisor is completely transparent to network traffic with the exception of traffic to/from a dedicated hypervisor management interface.

"Furthermore, at present there are no documented attacks against hypervisors, reducing the likelihood of attack. So, although the impact of a hypervisor compromise is great (compromise of all guests), the probability is low because both the vulnerability of the hypervisor and the probability of an attack are low."

Storage Concerns
Another security concern with virtualization has to do with the nature of allocating and de-allocating resources such as local storage associated with VMs. During the deployment and operation of a VM, data is written to physical memory. If it's not cleared before those resources are reallocated to the next VM, there's a potential for exposure.

These problems are certainly not unique to virtualization. They've been addressed by every commonly used OS. You should note, though, the initial OS may terminate in error before resources are cleared. Also, not all OSes manage data clearing the same way. Some might clear data upon resource release, others might do so upon allocation.

The bottom line: Control how you use storage and memory when using a public cloud. Clear the data yourself, carefully handle operations against sensitive data, and pay particular attention to access and privilege controls. Another excellent security practice is to verify that a released resource was cleared.

A further area of concern with virtualization has to do with the potential for undetected network attacks between VMs collocated on a physical server. Unless you can monitor the traffic from each VM, you can't verify that traffic isn't possible between those VMs.

There are several possible approaches here. The first is that the VM user can simply invoke OS-based traffic filtering or a local firewall. There's one potential complication to doing this if you need multiple VMs communicating and cooperating. These VMs may be dynamically moved around by the service provider to load balance their cloud. If VM Internet Protocol (IP) addresses change during relocation (which is unlikely, but possible) and absolute addressing is used for firewall rules, then firewall filtering will fail.

In essence, network virtualization must deliver an appropriate network interface to the VM. That interface might be a multiplexed channel with all the switching and routing handled in the network interconnect hardware.

Most fully featured hypervisors have virtual switches and firewalls that sit between the server physical interfaces and the virtual interfaces provided to the VMs. You have to manage all these facilities as changes are made to VM locations and the allowable communication paths between them.

Traffic Management
Another theoretical technique that might have potential for limiting traffic flow between VMs would be to use segregation to gather and isolate different classes of VMs from each other. VMs could be traced to their owners throughout their lifecycle. They would only be colocated on physical servers with other VMs that meet those same requirements for colocation.

This approach could include some form of VM tagging or labeling akin to labeling within multilevel OSes (such as Trusted Solaris or SE-Linux). You could also use the configuration management database to track tenant requests for application isolation.

In all these examples, however, the problem occurs "when the tenant also needs the application components to have maximal separation from common mode failures for availability. It's not that such a scheme couldn't be made to work, it's that the cost of all the incompatible and underutilized server fragments (which can't be sold to someone else) has to be carried in the service cost," says Bill Meine, software architect and cloud expert at Blackhawk Network.

One actual practice for managing traffic flows between VMs is to use virtual local area networks (VLANs) to isolate traffic between one customer's VMs from another customer's VMs. To be completely effective, however, this technique requires extending support for VLANs beyond the core switching infrastructure and down to the physical servers that host VMs. This support is now almost universal with VM technology.

The next problem is scaling VLAN-like capabilities beyond their current limits to support larger clouds. That support will also need to be standardized to allow multi-vendor solutions. It will also need to be tied in with network management and hypervisors.

Certification Matters
Finally, in considering the security issues with VMs, it's important to recognize that this technology is not new. Several products have undergone formal security evaluations and received certification. What this means in practical terms is that several VM technology vendors have taken pains to obtain independent and recognized security certification.

Virtualization absolutely complicates infrastructure management, but with the cloud, this simply must be automated if you are to use this technology at cloud scale and cloud elasticity. The bottom line with virtualization risk is that using this technology must be better planned and managed.

By automating virtualization management with cloud computing, you can achieve multiple benefits -- better security included. Further, the end of the ad hoc use of virtualization is a positive trend for security. It represents a return to infrastructure control