I just received an invitation for a Webinar on Virtualization and PCI compliance. My friend, John Kindervag is one of the panelists and, no, this is not an unpaid advertisement for anyone to attend even though I have provided the link to register. For an hour they will be discussing this topic because now the PCI DSS v2.0 references virtualization. Let us be very clear, while the PCI DSS prior to v2.0 never explicitly discussed virtualization, QSAs were instructed on how to approach virtualization security. And as you will see, virtualization security is no different than any other operating system security.
In my very humble opinion, virtualization is a one minute security issue, if that long. Let us cut to the chase, as small an attack vector virtualization can be, it is still a potential attack vector, so you need to secure it. Is that clear enough? The real issue is how to secure a virtualized environment.
There are two different forms of virtualization. There are stand-alone hypervisors (what NIST refers to as “bare metal”) like VMware vSphere, VMware ESXi, Microsoft Hyper-V and Citrix XenServer. Bare metal hypervisors are what we typically run into the most in our PCI compliance engagements, but not necessarily a guarantee. There are also VMware Server, VMware Desktop and Microsoft VirtualPC (what NIST refers to as “hosted”) that require a host OS to run on as an application no different than Microsoft Word. Obviously, the attack vectors are wildly different for each type of virtualization.
For whatever reason, it seems that a lot of IT professionals do not recognize that a hypervisor is an operating system. Yes it is a very specialized operating system, but it is an operating system just like Linux or Windows. Most hypervisors are based on Linux or UNIX and have a few security hardening similarities. But given a hypervisor’s specialization, they have significantly different security hardening requirements from their Linux or UNIX counterparts. As such, hypervisor vendors typically provide a security hardening standard for each of their hypervisor operating systems. All you need to do is go to the hypervisor vendor’s Web site and download the security hardening guide for your version of hypervisor. Which brings up a good point, if your hypervisor vendor does not provide a security hardening guide, then you need to find a different hypervisor.
For bare metal implementations, the only thing you have to secure is the hypervisor itself. However, with hosted virtualization, you need to secure the host operating system as well as the hypervisor. In addition to the hypervisor, you will need to follow the host operating system vendor’s security hardening guide to ensure that the host OS is also secure.
But hardening your virtualized operating system is not the end of the job. You need to properly implement your virtualized environment securely as well and that is more than just hardening the hypervisor. The most obvious security item that needs to be done is that any guest operating systems implemented need to also be securely hardened. It still surprises me the number of IT professionals that somehow seem to think that because they are implementing Windows or Linux as a virtual machine that there is something different about security and you can totally skip or skimp on hardening. Security hardening procedures need to be completely followed regardless of whether the guest OS is stand-alone or in a virtual machine.
The next area that seems to get the short shrift is infrastructure security. This is particularly true of the management of the hypervisor environment. Most implementations I have seen do a good job of securely connecting the virtual machines, but the hypervisor infrastructure environment leaves a lot to be desired from a security perspective. The first mistake I see is that the hypervisor management environment is not segregated from other networks. In the first scenario I commonly see, the production network and the hypervisor management network are on the same segment. If an attacker compromises any virtual machine, they gain access to the hypervisor management environment and can therefore gain access to the virtual cardholder data environment. In the other scenario, the corporate network and hypervisor network are one and the same and therefore everyone that is on the corporate network can also gain access to the hypervisor management network. The way to fix both of these situations is to put the hypervisor management network on its own network segment. I also recommend to organizations that they dedicate a NIC to only that segment. However, if an organization already has an operations management network segment separate from other networks, I have no problem having the hypervisor management network in that segment as well.
The other scenario I frequently see is virtual machines from the cardholder data environment (CDE) intermingled with virtual machines that are not part of the CDE. The problem here is that in the event of a compromise of a non-CDE virtual machine, CDE virtual machines may be accessible because of the configuration of the virtualization environment. The best way to use virtualization for PCI compliance is to isolate your CDE virtual machines in a physically separate virtual environment from your non-CDE virtual machines.
For the truly paranoid, you can also fiddle with parameters such as physical/logical NIC assignments as well as SAN configurations. While these sorts of configuration changes can provide additional security to the equation, I have my doubts as to the significance of these changes from a security perspective. In my years of dealing with virtualization, these sorts of configuration changes have been more for performance reasons and enhanced security was just a nice byproduct.
Finally, there is the maintenance aspect of virtualization. I think everyone gets the fact that virtualized or not, the guest operating systems need to be maintained and patched just like their stand-alone brethren. However, when you ask organizations how often they patch their hypervisor; some will say to you very honestly, “You have to patch it?” Earlier on I stated that a hypervisor is also an operating system and, as such, it needs to be patched just like any other operating system. Granted a hypervisor does not usually get patched every month like Windows, but there are patches issued every so often by hypervisor vendors.
Best of luck to John and the round table that are presenting this month on virtualization and PCI compliance. Hopefully this post will help explain what they will be discussing as well as lead to more insightful questions on the topic.
