How PCI DSS 2.0 affects virtualization compliance

The new Payment Card Industry Data Security Standard has been released, and it offers a more guidance on virtualization compliance. But PCI DSS 2.0 still leaves a lot of room for interpretation.

By Eric Siebert, Contributor

The Payment Card Industry Data Security Standard (PCI DSS) 2.0 is hot off the presses, and the question everyone's asking is, "Does it cover virtualization compliance?"

Well, kind of.

Two years in the making, PCI DSS 2.0 offers additional guidance and clarifies portions of the previous PCI DSS 1.2 standard. Virtualization compliance is mentioned, but only generally, and there are no specific virtualization security recommendations. In fact, the major change in version 2.0 is that PCI Security Standards Council brought the virtualization layer into the scope of the standard, which governs organizations that handle credit card information.

Previously, virtualization was completely ignored, so the move is a step in the right direction. But without firm guidance on how to ensure virtualization compliance, the standard is still ineffective. And the council doesn't plan to update PCI DSS 2.0 for another three years, so it will be quite a while before we get more detail about protecting credit card information in virtual infrastructures.

What's new in PCI DSS 2.0?
The changes to the standard are so minor that I would call this version PCI DSS 1.3 instead of 2.0. (You can download the summary of PCI DSS 2.0 changes and the full PCI DSS 2.0 document as PDFs from the council's website.)

Doing a search on the word virtualization in the PCI DSS 1.2 document returned zero results; in PCI DSS 2.0, the search returns three results. The first mention of the word virtualization just specifies that virtual machines (VMs), switches, routers, appliances, applications and desktops, as well as hypervisors, fall under the scope of the standard.

The final two instances of the word virtualization occur in requirement 2.2.1, which says the following:

Implement only one primary function per server to prevent functions that require different security levels from co-existing on the same server. (For example, web servers, database servers, and DNS [Domain Name Server] should be implemented on separate servers.)

Note: Where virtualization technologies are in use, implement only one primary function per virtual system component.

This new requirement clarifies the previous version, which said, "Implement only one primary function per server." If you interpreted server to mean virtual server, you could not use virtualization at all. Now, we know you can -- with limitations. PCI DSS 2.0 further explains this part in the two subsections of requirement 2.2.1:

2.2.1.a For a sample of system components, verify that only one primary function is implemented per server.

2.2.1.b If virtualization technologies are used, verify that only one primary function is implemented per virtual system component or device.

These subsections say it's OK to use virtualization, but you need to limit each virtual machine to one primary function. Don't put a database server and an application server on a single VM, for example.

Ensuring virtualization compliance with PCI DSS 2.0
These requirements are the only changes PCI DSS 2.0 has changed concerning virtualization, but a companion PDF document, Navigating PCI DSS, helps explain the intent of the requirements -- and there's an entire section on virtualization.

First and foremost, this section telling us that if you use virtualization, and even one VM deals with cardholder data, your entire virtual infrastructure must comply with the standard. (Previously, only the servers that dealt with cardholder data fell under its scope.)

Why the change? VMs can easily move from one host to another, and they also share hosts, storage devices and networks. If a single component is compromised, it can allow access to other components in the infrastructure -- sometimes without you even realizing it. Your entire infrastructure better be well documented and mapped out if you want to ensure virtualization compliance with PCI DSS 2.0.

Navigating PCI DSS also explains requirement 2.2.1 in greater detail. It says not only that you should implement one primary function per VM and treat VMs as physical servers but also that you must segregate functions and networks with different security levels. On a vSwitch, for example, it is common to have many VLANs using 802.1Q VLAN tagging. But under requirement 2.2.1, you may not be able to retain this structure if VLANs have different functions or security levels. You may need to create more vSwitches to isolate traffic.

Another potential problem is that you cannot share production environments with test and development environments. Virtualization makes it easy to have test and dev VMs running on the same hosts with the same storage devices as production VMs, but PCI DSS 2.0 does not allow that. For larger organizations that have dedicated production environments, that may not be a problem. But for smaller data centers, this requirement can prove costly. In addition, you cannot use devices that could be shared among VMs, such as USB devices that are attached to the host.

The final portion of the Navigating PCI DSS section on virtualization deals with proper documentation and access controls. The major requirement is that you should provide only the level of access needed for someone to perform his job and no more. For example, if you assign someone access to manage a VM, don't allow that person to move it to another vSwitch. Just give him the specific permissions needed for that task. Fortunately, VMware vCenter Server makes access control easy because its granular permissions allow for role-based access control.

Also, you shouldn't allow people to directly access a hypervisor. This privilege should be extremely limited. Instead, make users go through vCenter Server, or whatever management console you use, to ensure virtualization compliance.

Preparing for PCI DSS 2.0 virtualization compliance
In PCI DSS 2.0, the wording regarding virtualization is vague, and its interpretation can vary. Enforcement will really come down to the interpretation of individual auditors. There is not much detail on how you can meet the requirements in your virtual infrastructure, but the Navigating PCI DSS guidelines and existing virtualization security best practices should help you.

PCI DSS 2.0 will have major impact on how you architect your virtual infrastructure, and providing the proper segregation between virtualization components is critical. One way to minimize the effects is to build an isolated environment solely for VMs that handle cardholder data so that they don't mix in with your other VMs.

PCI DSS 2.0 goes into effect Jan. 1, 2011, and annual audits that occur after that date will be subject to the new requirements. If you are subject to PCI DSS 2.0, you would be wise to start preparing your infrastructure now, so you won't have to do as much remediation after the audit. Most PCI DSS requirements are basically just common-sense security practices focused on establishing a well-secured infrastructure to protect cardholder data. Now that PCI DSS has finally found its way into the

Eric Siebert  

About the expert
Eric Siebert is a 25-year IT veteran with experience in programming, networking, telecom and systems administration. He is a guru-status moderator on the VMware community VMTN forums and maintains, a VMware information site.

This was last published in November 2010

Dig Deeper on VMware basics

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.