There’s been a lot of recent hype about security risks with the rise of virtualization, but much of it is vague and short on specifics.  There is also an assumption that all the security available on a physical server simply disappears when it migrates to being a virtual machine.  This is not true.  A virtual server is the same server it was before it was P2V’d from a physical server. IS authentication, access control, audit, and network controls remain as active as before.  The virtual server sits on hosts and SANs in the same datacenter as did the physical server .  So what has changed?  What are the new risks?

The risks are in the virtualization infrastructure layer…

Some questions to consider:  how secure are the host, the storage and the host control server? How secure are the ESX/ESXi hosts, the SANS and the vCenter servers?  Those are the real concerns.  Now that a new layer has been inserted between the guest operating system and the hardware, that layer’s immediate components and other components upon which it depends (the Active Directory forest to which the vCenter servers belong) need the same security controls. Virtualization security is even more critical in some respects because a low level access is equivalent to physical access to every guest server and its data, and may compromise the system.

Recent audits show that some areas of security and control of virtualization components can be immature and do reflect concern about how critical the virtualization layer is to security.

Much is made about network security risks associated with virtualization but this concern may be unfounded.  Most servers are not behind internal firewalls or on heavily restricted network segments in the first place, so moving them to an ESX/i host on a virtual switch doesn’t expose the server to new network risks. Physical servers with such controls can be set up exactly the same with virtual switches and firewalls. There are more advanced attack scenarios involving a compromised VM where the attacker can break out of that VM, into the host and possibly back up into other VMs, but at this point, most security teams are vigilant enough to deter such an attack.

The other area of network security is the protection of the visualization infrastructure itself

Unless IT shops totally ignore virtualization best practices, they will implement multiple network cards on ESX/i hosts that allow for completely separate guest, live migration (aka vMotion), storage and management (connections from VMWare vCenter and clients to the host) traffic.  In audits I’ve performed, SANs and the management interfaces on hosts are isolated from rest of the organization’s internal LAN.

There are areas of virtualization where serious risks do exist: privileged access, Active Directory and auditing.  Allowing administrators (especially multiple administrators!) to use the built-in root or admin account on operating system is bad practice and risky. Everyone needs his or her own account.  The principle is emphatically true for virtualization hosts.  However prior audits reveal that many hosts are managed by the built-in root account which is shared among multiple administrators.  With a virtualization host, the risk of shared and insecure root accounts is multiplied by number and criticality of all the guest VMs on that host.  The best practice is to lock down ESX/i hosts so that even admins don’t directly access them and are required to go through the central management server (called vCenter in the case of the VMware environment).  vCenter doesn’t share the same prevalence of insecure root access because vCenter integrates with Active Directory and allows an organization to leverage the AD accounts admins already possess.

Another prevalent risk associated with the dependence of virtualization infrastructures is situated with the Active Directory

Directory integration and unified authentication is definitely the way to go, but there are risk factors to consider as well.  First, virtualization management servers like vCenter tend to be members of the main AD.  For example: a Windows server belonging to a domain is exposed to any and all risks in Active Directory and all domain controllers within that forest (remember the security boundary in AD is the forest not the domain).  A vCenter server is the “boss” of all the ESX/i hosts connected to it.  Thus, everyone with domain admin authority anywhere in the AD forest and anyone who compromises a domain controller in the AD forest can take the vCenter server and compromise the virtualization infrastructure (and ultimately any guest VM and its data.  Any outstanding risks from previous AD audits must be carried forward to the virtualization infrastructure audit too.

For example, at one financial institution, an excessive number of IT folks had domain admin authority to the main AD forest.  That was problem enough as a risk to AD and the Windows systems within that forest.  But with the virtualization management server as a member of that forest, now every virtual machine – even those running Linux and Windows servers in other forests are now accessible to that same excessively large group of AD admins.  Worse, in this organization remote access was widely available with no strong authentication, so the entire virtualization infrastructure and the countless servers were vulnerable to compromise by a successful password based attack against any one of many AD admins.

The solution?  First, think about the AD forest(s) that hold either your virtualization management servers (e.g. vCenter) or those user accounts with privileged access to the virtualization infrastructure (i.e. users with the Administrator role in vCenter).  Those forests, including each domain and domain controller within them, must be locked down and secure to a level appropriate for the virtualization infrastructure itself. Organizations with outstanding AD security issues with no resolution in site should really look at implementing a small, separate AD forest for providing directory and authentication services to their infrastructure including virtualization, storage and network components.  This small AD forest would be much more locked down and protected and careful thought should be given before implementing synchronization or trust relationships between it and other forests.  This may be at the price of maintaining additional user accounts for infrastructure admins but that is the price of security in this instance.  If trust is implemented it should such that the infrastructure forest is trusted by the other forests not vice versa.   If synchronization is implemented, password changes or other authentication data should not flow from other forests or directories into the infrastructure forest.

The final risk area in newly virtualized organizations is a lack of auditing and log management for virtualization infrastructure components

Virtualization management servers (e.g. vCenter) and hosts (e.g. ESX/i) can generate audit logs.  It is crucial to enable this feature and subsequently collect, archive alert and report on this log data the same as is necessary with any other security critical components on your network.  Virtualization hosts like ESX/i are simple to accommodate since they can send events via syslog, but  management servers like vCenter are more problematic.  vCenter creates a number of text log files named vpxd-1 through 9 but my research has proven them to omit very important data and fail to resolve other key ID codes.  This is not to say the audit trails aren’t there.  They are but they are trapped inside database tables.  In the case of vCenter the audit trail is stored in VPX_EVENT and VPX_EVENT_ARG tables within the vCenter SQL database. Incomprehensibly command line interfaces like Get-VIEvent that pull data from these leave out critical event arguments as well as the name or ID of the event itself!  So the final option seems to be direct query of the SQL tables themselves with the necessary resolution of foreign keys to rows in related tables.  This presents an opportunity to log management and SIEM vendors to distinguish themselves with enhanced support for collecting enriched audit trails from virtualization infrastructures.

Are there risks in the typical virtualized data center?

Absolutely.  But it’s important to identify the real risks.  In most environments, the risk is less among the virtual machines and more with the basic security controls of the infrastructure itself as well as risks resulting from poorly understood security dependencies between the virtualization infrastructure and the directory used for identity and authentication.  Make sure virtualization infrastructure components are properly isolated.  Follow the same best practices for securing root access on hosts as we’ve had to apply to normal servers for decades.  And include audits trails from virtualization infrastructure in all log management efforts.