PCI DSS: Virtualization Ready?

The PCI Security Standards Council published its latest PCI guidance in the form of PCI DSS 2.0, but quickly followed up with the document Navigating the PCI DSS v2.0. The Navigating document is very important to those who have virtual systems as it contains the basic guidance about virtualization while PCI DSS 2.0 does not provide anything specifically geared towards virtualization. However, there is an adjunct document that does layout PCIs thoughts on virtualization. This is stated within the Navigating the PCI DSS (v2.0) document.
The section on Virtualization is quite thin and have in effect four bullets to aid auditors and everyone else in where PCI is going with virtualization guidance.

1. All elements/components of virtualization are considered in scope for a review.
2. The virtual environment must meet the intent of all PCI requirements.
3. Virtualization management protocols, interfaces, etc should be included in all system documentation.
4. Roles and permissions, authentication and authorization requires special care and are in scope.

So what does this mean?
It means that whether or not to treat a virtual environment as a black box is no longer valid. All components are now in scope and are to be properly audited. In addition, while a PCI requirement may not specifically mention virtualization, the virtual environment must meet the intent of the requirement.
Intent is very difficult  to measure within a virtual environment. If ‘separation’ is required, is that even possible within the segregated virtual environment? This still leaves the decision up to the auditor, as the auditor gets to interpret intent.
The last two items are a boon to certain vendors within the virtual environment, such as HyTrust and others who are working on similar technology. In essence, the virtualization management network becomes a major issue for all who must adhere to PCI. It is already a major security issue for most companies, but now is part of compliance. The document states that there must be separation of duties within the management layer such that network roles and permissions are separate from, for example, the ability to manage virtual machines. How much separation is required is not defined.
Furthermore, those users who authenticate to the hypervisor should not then be able to authenticate to the Guest within a VM. This is a good point, implying that you should have separate users for hypervisor management and for virtual machine management. However, how does automation APIs such as VIX fit into this environment where it is the hypervisor authenticating to automate guest operating system actions without user involvement? Perhaps judicious use of service accounts?
While these statements are brief and to the point, they still leave quite a bit to interpretation. Intent is a great thing to say; Sort of the “Spirit of the Law” approach. However, how are auditors going to do the mapping from the PCI requirement to the specifics of a virtual environment?
Auditors will need to gain more knowledge of the virtual environment, work with the virtualization administrators and perhaps experts to provide this mapping for each hypervisor in use. This increases in complexity when multiple hypervisors are in use within an enterprise, or if hypervisors are run within hypervisors.
PCI still has quite a bit of work to do, and should provide specific mappings for each hypervisor, but I expect it will still be a general mapping of PCI requirement to general virtual environment functionality. Given this, be forewarned, being PCI compliant does not imply you are secure, and being secure does imply you are compliant.