Introduction

The security requirements for your virtual environment depend on your organization’s risk appetite and external factors such as regulation and compliance needs.

These requirements also depend on where your virtual environment is placed: within a co-location facility, within a private cloud, or hosted within your corporate network. Differing locations present different risk profiles. For example, a co-lo facility may present risks from other tenants but may be better resourced to provide dedicated, round-the-clock security monitoring. In contrast, in many enterprise environments internal threats may not be as significant. Consequently, efforts to secure internal guest networks might be a lower priority.

Many of the same security principles and techniques that apply to physical environments also apply to the virtual ones. Since the hypervisor is protecting every VM from every other VM, it is important that a hypervisor is designed with security from the ground up.

Approach

When planning a hypervisor environment, you need a particular focus on security design. This is because you not only have to protect the virtualization layer itself, but also the virtual machines running above. Both layers may be complex and large-scale with differing lifecycles and administrators. You need to meet not only your security expectations and governance, risk management, and compliance (GRC) needs but also those of the VMs running on your infrastructure. A large number of VM types, usages, and policies exacerbates the challenge.

In many deployments, different parts of the organization share services and may share computing resources. Separation between these groups must usually be achieved virtually rather than physically. This use of virtualization should be secure by design.

Recommendation:

We recommend that you clearly understand and document:

• The traffic flow between different components, including hypervisors, switches, and guest traffic.
• All components in the environment, including hypervisors, workloads, networks, management consoles, and physical hardware components.
• Communications and data flows between hosts.
• Any other potential communication channels for components, whether enabled or not.
• What is expected not to change and what is expected to be reconfigured as differing organizational groups join, expand, shrink, or leave.
• RBAC roles and the individuals to whom they are assigned.
• Any removable hardware components, such as USB drives and removable disk drives.
• The details, including assigned IP addresses, of management interfaces and how they are physically configured for network connectivity (switches, ports, and so on).

Planning Your Virtual Environment

Your virtual environment is structured as three layers, as shown in the diagram that follows:

1. Network layer, also including storage
2. Hypervisor (host) layer
3. Virtual machine (VM) layer

This document provides security guidance in corresponding chapters following this introductory chapter.

This illustration shows the different layers that people can secure in virtual environments, including the virtual machine layer, the hypervisor layer, and the network layer. The network layer, represented in gray, effectively straddles the hypervisor and virtual machine layers since there are networking aspects in all of these layers.

Many of the standard ways in which you secure physical environments apply to virtual environments. For example, it is possible to secure the virtual machine layer the same way as you normally secure an operating system, such as hardening Microsoft Windows.

Recommendation:

• We recommend that you secure guest operating systems in accordance with the standard practice of your organization’s security policy.

• We recommend that you secure networks in accordance with the standard practice of your organization’s security policy. In particular, protect networking passwords, and also configure digital certificates accordingly.

• We recommend that you manage access to the XenServer control domain carefully. The control domain provides administrative access to a pool and the VMs executing on it. The following chapters will provide you with recommendations on how to control users and isolate networks to restrict access.