Companies that handle credit cardholder data should pay close attention to the new PCI DSS 2.0 guidelines, which outline 12 virtual infrastructure components that need protection. The
Any organization that accepts credit cards is subject to the Payment Card Industry Data Security Standards (PCI DSS), which historically covered only physical IT infrastructures. But PCI DSS 2.0 and the recently released PCI DSS Virtualization Guidelines (PDF) supplement now offer best practices for securing credit card data in virtual infrastructures as well.
Twelve VMware security areas to harden for PCI DSS
Even though the PCI DSS Virtualization Guidelines aren’t mandatory, it would be wise to follow them, because you can bet that they will become requirements eventually. Below are brief overviews of the 12 PCS DSS requirements and their accompanying VMware security recommendations:
1. Use of firewalls
Virtual firewalls filter network traffic to and from virtual machines (VMs). With them, you can control who and what has access to critical virtual machines and appliances. If you don’t use virtual firewalls in your VMware infrastructure, look at products such as VMware vShield Zones or Juniper Networks Inc.’s Virtual Gateway.
2. Use of passwords
This recommendation should be a no-brainer, but don’t use default, vendor-supplied passwords. Many people just don’t change the default passwords, which opens the door to unauthorized access of PCI data. ESX and ESXi do not have default passwords for their management consoles, but many VMware companion products do, such as the vCenter Mobile Access and vShield Manager appliances.
3. Encrypting cardholder data
The PCI DSS Virtualization Guidelines suggest that you encrypt virtual disks at the virtualization layer, but that’s not possible with Virtual Machine File System data stores. At some point VMware may add this feature, but for now, all you can do is restrict access to the virtual disks as much as possible. Most PCI auditors understand this technology limitation and won’t penalize you as long as you attempt to secure the virtual disks.
4. Encrypting data over public networks
There isn’t a virtualization mechanism that encrypts network traffic, so applications and operating systems must encrypt data before it is transmitted. You can also use a physical network device with Internet Protocol Security to encrypt traffic, for example.
5. Antivirus software
This suggestion applies more to hosted hypervisors , because you can’t run antivirus on the ESXi management console. It is possible to install Linux-based antivirus software on the ESX service console, but this practice is highly discouraged. VMware never intended for anyone to install software -- especially antivirus tools, which are very resource intensive -- on the service console. If you ran antivirus software on the ESX service console, it could steal resources from VMs, causing them to slow down. Antivirus software could also crash the service console, which would bring down the entire host.
6. VMware security patches and host segregation
You should regularly install VMware patches and updates, even if PCI DSS 2.0 doesn’t apply to your organization. If you handle cardholder data, you should also place test and development VMs and production VMs on different hosts with different access levels. For example, developers should access only the development environment.
Host segregation is important because test and development servers often aren’t as secure as their production counterparts. This arrangement also provides better security in the event that the test and development environment is compromised.
7. Cardholder data access
In VMware infrastructures, you must restrict access to multiple layers, including the application, OS and hypervisor levels. This segregation ensures that the unessential personnel don’t access sensitive infrastructure areas, which can lead to cardholder data being compromised.
To do this, restrict access to VMs that contain cardholder data at the management consoles, shared-storage devices and other management components, including vCenter Server. Tools such as the HyTrust Appliance, for example, can make this process much easier at the virtualization layer. But properly securing your storage devices is also critical. If someone has direct access to a VM's disk file at the storage layer, he or she can copy and mount it somewhere else to steal the VM’s data.
8.Unique login accounts
Each users should have his or her own login credentials. This arrangement improves VMware security because you can assign granular controls to individual accounts and track changes made to the infrastructure.
9. Physical access to cardholder data
Many methods for securing physical infrastructure apply to virtual infrastructures as well. For example, make sure that the hosts and storage are located in a data center with a lock and logging mechanism. Additionally, you should lock down access for out-of-band management boards that provide remote access a data center.
10. Resource monitoring
Typically, this process entails the saving of data logs from vCenter Server and hosts. It doesn’t actively protect cardholder data but the logs provide an audit trail (e.g., who did what, and when), just in case a breach occurs.
You can implement a robust logging solution -- such as LogLogic or the HyTrust Appliance -- to centrally manage virtualization data logs.
11. VMware security testing
As with physical infrastructures, you need to routinely test your VMware security. It’s also worth noting that you should use security tools, such as VMware vShield, that are specifically developed for virtual infrastructures. After all, not all physical infrastructure security tools are virtually aware, and they may not provide the same levels of protection.
12. Information security policies
Document and update your organization’s security policies, and provide training to those who maintain the infrastructure. (You should already do this with your physical infrastructure.)
This was first published in August 2011