According to a recent announcement by IT research firm Gartner Inc., through 2012, 60% of virtualized servers will be less secure than the physical servers they replace. Gartner has identified the six most common server virtualization security risks, along with advice on how to address each issue:
Risk 1: Information security isn't initially involved in server virtualization projects
Many server virtualization projects are undertaken without involving the information security team in the initial architecture and planning stages. Security professionals need to realize that it's not possible
to manage risk that isn't acknowledged and communicated. They should start by looking at extending their security processes, rather than buying more security, to address security in virtualized data centers.
Risk 2: A compromise of the virtualization layer could result in the compromise of all hosted workloads
Like any software written by human beings, the server virtualization layer inevitably contains embedded and yet-to-be-discovered vulnerabilities that may be exploitable. Hackers have already begun targeting the server virtualization layer to potentially compromise all hosted workloads. This layer must be patched, and configuration guidelines must be established.
Gartner recommends that organizations treat this layer as the most critical x86 platform in the enterprise data center. It's best to keep it as thin as possible, while hardening the configuration to unauthorized changes. Server virtualization vendors should be required to support measurement of the hypervisor/VMM layer on boot-up to ensure it has not been compromised. Above all, organizations should not rely on host-based security controls to detect a compromise or protect anything running below it.
Risk 3: Internal virtual networks created for VM-to-VM Communications can result in lack of visibility and controls
For efficiency in communications between virtual machines (VMs), most virtualization platforms include the ability to create software-based virtual networks and switches inside of the physical hosts. This traffic will not be visible to network-based security protection devices such as intrusion prevention systems. Organizations require the same type of monitoring they place on physical networks, so that they don't lose visibility and control when workloads and networks are virtualized.
Risk 4: Workloads of different trust levels are consolidated onto a single physical server
More critical systems and sensitive workloads are being targeted for server virtualization. It can become an issue when these workloads are combined with other workloads from different trust zones on the same physical server without adequate separation.
Enterprises should require the same type of separation required in physical networks for workloads of different trust levels, and treat hosted virtual desktop workloads as untrusted, and strongly isolate them from the rest of the physical data center. Enterprises are advised to evaluate the need for point solutions that are able to associate security policy to virtual machines' identities and prevent the mixing of workloads from different trust levels on the same server.
Risk 5: Adequate controls lacking on administrative access to the hypervisor/VMM Layer
Because of the critical support that the hypervisor/VMM layer provides, administrative access to this layer must be tightly controlled. However, this is complicated by the fact that most server virtualization platforms provide multiple paths of administration for this layer. Gartner recommends restricting access to the virtualization layer and favors virtualization platforms that support role-based access control of administrative responsibilities to further refine who can do what within the virtual environment.
Risk 6: Potential loss of separation of duties for network and security controls
When physical servers are collapsed into a single machine, it increases the risk that both system administrators and users will inadvertently gain access to data that exceeds their normal privilege levels. Another area of concern is about which group configures and supports the internal virtual switch. The team which is responsible for the configuration of network topology (including virtual LANs) in the physical environment should be responsible for this in virtual server environments as well. They should favor virtualization platform architectures that support replaceable switch code, so that the same console and policies span physical and virtual configurations.