PCI DSS 2.0 discussed on The Virtualization Security Podcast

In the last Virtualization Security podcast on 12/2 we had with us members of the PCI DSS Virtualization Special Interest Group (SIG). Kurt Roemer of Citrix and Hemma Prafullchandra of HyTrust joined us to discuss the differences to the PCI DSS 2.0 with respect to virtualization. In essence, PCI DSS explicitly calls out the need to bring virtualization, people, and processes into scope.
As we discussed in a previous article, the PCI DSS 2.0 does not state exactly what needs to be assessed within the virtual environment, or even what part of the virtual environment is a concern of each aspect of the PCI DSS. What the PCI DSS 2.0 does do is change the language, however subtle, that technologies employing shared resources are now acceptable. We started the panel off be discussing what changed within the PCI DSS 2.0 from previous versions. In essence, the necessary language changes as well explicitly calling into scope people and business processes. This expands the role of the auditor quite a bit. However, the language used also makes it possible for auditors to follow the intent of the compliance and not necessarily the explicit word. Which has been the case for some auditors.
Speaking specifically of hardware, we started with the discussion of blades. If Virtualization was never in scope (which actually it was always in scope due to the intent of the PCI compliance), then how could any shared infrastructure be in scope. Many auditors approve blades often but since blades make use of shared resources (backplanes, converged network adapters, flexible networking, and storage) how is this different from virtualization?
From the PCI DSS specific, use of blades with shared interconnects and virtualization are not all that different. Why shared interconnects? Because that is where many companies are heading, IO Virtualization reduces cabling which reduces the cost of installing a new device. Pass thru interconnects are no longer the norm for blades. Continuing our build up, we moved from blades to hypervisor based virtualization.
PCI DSS is all about common sense with respect to card holder data. What is in scope, is in regards to this. In addition, the companies involved in PCI DSS compliance are those who not only do the processing of the transactions but those who outsource this to other companies. The ultimate responsibility of the protection of card holder data is the one who owns the transaction not necessarily the one who is doing the transaction. Yes both are involved but the responsible party is the owner of the transaction. For these companies, perhaps the self-assessment is all that is required, but for the companies too which you outsource a full audit is required.  This ownership and responsibility defined by the PCI DSS 2.0 standard also implies who is responsible for auditing within the cloud.
Cloud and PCI was not discussed on this podcast but the ground work has been laid.
Soon (within a few months at least) the PCI Virtualization SIG will publish a general mapping of PCI DSS 2.0 to hypervisor functionality and member companies are working on specific mappings between PCI DSS 2.0 elements and each hypervisor. I look forward to that mapping with interest.
For now, virtualization is and always has been in scope for any PCI audit. As with any new technology however, you may need to educate your internal and external auditors in the intricacies of the technology. If an auditor is unwilling to learn about the new technology then find a new auditor. It is important that auditors understand all technologies involved and that  auditors and companies work together. The auditor is not the enemy, they are your partner. For Internal auditors PCI has its own set of classes they offer, yet for external auditors there are other classes.
HyTrust, ISACA,  and others have published new whitepapers about PCI DSS 2.0. All are worth a read. PCI DSS 2.0 with virtualization in scope implies a need for more education in the area of virtualization.