The Problem with Bolt-On Security for Virtual Environments

What’s the problem with bolt-on security for virtual servers and virtual environments? Too many people forget that VMware Virtual Infrastructure 3 (VI3) is the entire virtual environment (VE). Granted the core is VMware ESX, VMware ESXi, and can include VMware Server, but it is much more than that. Let’s consider the many pieces of your enterprise that must be examined as you secure virtualization.

VI3 includes VMware Clustering, and independent hosts incorporating such items as VMware Dynamic Resource Scheduling (DRS), VMware High Availability (HA), VMotion, and Storage VMotion.

Then there’s the storage technology in use in your enterprise, whether it’s local storage or remote storage such as iSCSI, NFS over NAS, or SAN physical devices, or the Lefthand Networks Virtual SAN Appliance. Once we discuss storage, we need to discuss how virtual machines access the storage, whether using virtual machine disk files, using raw disk maps to logical units (LUNs) presented to the virtualization host, using iSCSI initiators within the VM, accessing a NAS or SAN directly via the network, or using Fibre Channel N_Port ID Virtualization.

If a network is involved, which is almost always the case, we need to discuss the networks involved and how VMs are accessed. Are the virtual machines accessed via a DMZ? Via production, administrative, or test networks? Are the VMs communicated with using some form of special application, VPN, SSL Tunnel, RDP, Virtual Desktop Infrastructure (VDI), or the remote console over the web of the VMware Virtual Infrastructure Client?

In order to create and manage VMs, we now add into the mix the question of how you manage the entire environment, whether via something that uses the VMware SDK, VIC connected to Virtual Center, or even a single host, VMware Lab Manager, VMware Life Cycle Manager, or via the remains of the full service console.

All of this is just a brief view of what comprises the virtual environment, whether you’re using technology from VMware or other vendors. Virtualization security is needed every step of the way. It is possible to bolt-on security after the environment is deployed, but that is just a stop gap solution at best. Security should be considered from the very beginning of a virtual infrastructure deployment.

Remember, virtual security applies not only to the virtual environment but also to what touches or interfaces with the environment, including firewalls, routers, gateways, intrusion detection and prevention systems (IDS/IPS), storage and switch fabrics. Included in switch fabrics are VLANs and NPIV.

Virtualization security planning done at every step of design and implementation will help you handle key issues including data comingling, network attack prevention, forensics, auditing, disaster recovery, and business continuity.

That’s why when you think virtual security, you must think far beyond ESX server.

Virtualization expert Edward L. Haletky is the author of “VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers,” Pearson Education (2008.) He recently left Hewlett-Packard, where he worked in the Virtualization, Linux, and High-Performance Technical Computing teams. Haletky owns AstroArch Consulting, providing virtualization, security, and network consulting and development. Haletky is also a champion and moderator for the VMware discussion forums, providing answers to security and configuration questions.