I am finally allowed to announce that the Payment Card Industry (PCI) Security Standards Council (SSC) has published a 39 page guideline to virtualization and cloud computing.

Two members of K3DES worked on the Special Interest Group (SIG) that wrote the document.

…the information supplement helps merchants, service providers, processors and vendors understand how PCI DSS applies to virtual environments including:

• Explanation of the classes of virtualization often seen in payment environments including virtualized operating systems, hardware/platforms and networks
• Definition of the system components that constitute these types of virtual systems and high-level PCI DSS scoping guidance for each
• Practical methods and concepts for deployment of virtualization in payment card environments
• Suggested controls and best practices for meeting PCI DSS requirements in virtual environments
• Specific recommendations for mixed-mode and cloud computing environments
• Guidance for understanding and assessing risk in virtual environments

The supplement also includes an appendix that provides examples of virtualization implications for specific PCI DSS requirements and suggested best practices for addressing them.

Customers will be pleased to find on page 23 that if they use a Software as a Service (SaaS) provider they do not have responsibility for software, operating systems, databases, virtual infrastructure, hardware and physical access…er, actually, wait the note below the diagram has a massive disclaimer:

Cloud service offerings should be individually reviewed to determine how responsibilities between the cloud provider and cloud customer are assigned

It can be difficult to define responsibility, let alone clearly assign it to a cloud provider for PCI DSS compliance. The list of challenges to cloud compliance really start on page 23 and conclude on page 24 with the customer still holding responsibility for everything “not covered by the provider”.

The hosted entity should be fully aware of any and all aspects of the cloud service, including specific system components and security controls, which are not covered by the provider and are therefore the entity’s responsibility to manage and assess.

The bottom line is that the PCI SSC holds an entity responsible and transfer of responsibility can not be based on trust alone; verification of controls (e.g. validated service provider status) is required for compliance. DSS Requirement 9 to restrict physical access to cardholder data, for example, still requires the on-site and in-person review by a QSA even for a cloud environment, as stated on page 36 of the Guidelines.

• Providing physical access to a single host or hypervisor explicitly grants the equivalent of physical access to all the virtual machines and components running on that host/hypervisor, and potential access to other connected physical systems.
• Due to the potential impact of unauthorized physical access, additional authentication and monitoring of physical access may be needed—for example, requiring dual-factor authentication and a supervised escort for all physical access to the data center.

But let me put this back in perspective of what’s changed for virtual environments. The Guidelines’ Section 3.8 VM Images and Snapshots on page 13 has the following warnings.

Special attention must be paid to the preparation of VM images and snapshots, as they may capture sensitive data present on the system at the time the image was taken, including contents of active memory. This could result in the inadvertent capture, storage, or even deployment of sensitive information throughout the environment.

Additionally, if images aren’t secured and protected from modification, an attacker may gain access and insert vulnerabilities or malicious code into the image. The compromised image could then be deployed throughout the environment, resulting in a rapid compromise of multiple hosts.

A physical firewall disk was protected by physical controls; access was restricted by doors, walls, badges, cameras, case, rack, etc. and so in a compliant environment it was highly unlikely someone could mount a firewall disk within a case, within a rack, behind walls, inside a building and edit it without getting through many layers of prevention and detection.

A firewall running inside the virtual environment, however, has a disk that is virtual — accessible via numerous network paths. It can be mounted by another virtual machine. An auditor has to ask what would prevent a user of VMware vSphere, for example, from mounting an existing virtual disk in a datastore that is for a VMware vShield (e.g. vse-###) firewall. Once a firewall disk is mounted a user would only need to run a few short commands to install backdoor network access.

First, read the root password hash from the shadow file, add a new user, etc.

# vi etc/shadow

Second, disable the host-based firewall

# vi root/vSEdge/vse_mgr.pl

Search for “# set up iptables” and put a comment tag (#) in front of all seven lines of that section.

Third, enable a SSH daemon for remote administration

# vi etc/inittab

Just add a line with ” id : runlevel : action : process ” to the end of inittab

ssh1:2345:once:/etc/rc.d/init.d/sshd start > /dev/null 2>&1

Now the firewall will start with a network service listening for ssh connections. Will staff managing the environment notice when their firewall disk is mounted, locked for modification, changes are made, the firewall restarts, the firewall has a port open, or remote connections are made to the firewall? Those are not questions specific to virtual environments yet they may be more relevant to compliance of virtual environments.

Logical and physical access to storage always has required monitoring and tracking but virtualization extends those control requirements to a new generation of powerful software and utilities for administration of resources. The ease of creating and modifying images, snapshots and disks means preventing, monitoring and tracking access to storage is essential to virtual environment compliance with PCI DSS.