How to apply PCI DSS guidance to virtualisation technology

Learn how to apply best practices from the recently released PCI DSS virtualisation guidance to your virtual environment.

It's a common refrain: C-level executives want their organisations to reduce costs, improve efficiencies and ensure continuity of business. By the same token, IT security pros must ensure their companies comply with legal and industry security frameworks such as the EU Data Protection Directive and the PCI Data Security Standard.

The key questions regarding virtualisation: Is virtualisation technology PCI DSS friendly, and does it reduce or increase scope?

The PCI Security Standards Council, the group behind the PCI DSS, released its information supplement, entitledPCI DSS Virtualization Guidelines” (.pdf), and, as the cost savings and ease of implementation that virtualisation offers have wooed so many companies, it comes at a good time. The PCI DSS guidance is a good beginner’s guide to virtualisation. It provides an overview of virtualisation technology, associated infrastructure, benefits and generic risks, but does it help organisations become or remain compliant if they move their cardholder data (CHD) to a virtualised environment?

PCI DSS applies to any organisation transmitting, storing or processing card holder data (CHD), as well as to the in-scope systems used to do so. Any network component used in the process is considered in-scope and, by association, any other component physically or logically connected to in-scope components is also in-scope and must therefore be protected by implementing the control points in PCI DSS 2.0. Because PCI DSS requires a mix of complex technical settings, policies, procedures and user training, organisations that need to comply with PCI DSS focus on reducing scope. Thus come the key questions regarding virtualisation: Is virtualisation technology PCI DSS friendly, and does it reduce or increase scope?

With virtualisation, one can technically host PCI DSS data and non-PCI DSS data on the same physical machine but on different virtualised OSes and/or applications. This is known as "mixed mode." Sensitive data such as CHD can sit in a virtual OS next to another virtual OS that hosts non-sensitive data on the same physical machine.

Section 3.4 of the PCI DSS guidance on virtualisation (not to be confused with requirement 3.4 of PCI DSS 2.0) covers the challenge of potential compromises of “one virtual system function [that] could lead to a compromise of other functions on the same physical system. A compromised VM could use the virtualisation-layer communication mechanisms to launch attacks on other VMs on the same host or even hypervisor.”

Best practices for how to address mixed-mode threats to CHD are available in section 4.2 of the information supplement, which states: “It is recommended […] that VMs of different security levels are not hosted on the same hypervisor or physical host.” It goes on to state, “The principle should also be applied if in-scope and out-of-scope virtual systems are to be located on the same host or hypervisor […] it may not be possible to achieve an appropriate level of isolation, or segmentation, between in-scope and out-of-scope components located on the same host or hypervisor.”

Clearly, whether or not virtualisation is PCI DSS friendly depends on each enterprise's own environment and how its administrators assign rights, segregate duties, log activity and monitor for suspicious events. The advice of the PCI Security Standards Council (PCI SSC) on how to ascertain these particular answers? Ask your Qualified Security Assessor (QSA).

QSAs, however, may not understand VMs, and it can be argued that the advice provided in the information supplement does not enable either the entity or the QSA to make a call on what’s best. Indeed security auditors, not just QSAs, are often dubious about how a virtualised environment can be secure, especially in a mixed mode. How can you, at a click of a button, generate reports about traffic from, to and within your virtualised environment that auditors will both understand and  accept as demonstrating compliance with PCI DSS?

Best practices for addressing virtulisation traffic challenges
The best way to address the virtualisation traffic challenge is to go back to the basics and map out your security ecosystem and CHD flow within it. Then demonstrate physical as well as logical segmentation using VMs and detail what additional security is in place; e.g. software-based firewalls on virtual networks, antimalware, anti-spam, file integrity monitoring and any other products mandated by PCI DSS. In addition, document access rights, user segregation of duties, and how logging and monitoring are applied. The guidelines cross-reference CIS, NIST, ISACA, ISO and SANS for more detailed information, so turn to those resources as needed.

Cloud deployments are also mentioned in the supplement. The PCI SSC states that, in some cloud environments, “challenges make it nearly impossible for some cloud-based services to operate in a PCI DSS compliant manner.” The advice is to check that the cloud provider is indeed providing appropriate levels of PCI DSS compliance. In that respect, it would appear that, at this point, private cloud is the best approach for using virtualisation where CHD is at stake.

In the end, there are two angles for using the guidance document.

First, if yours is a green-field site for virtualisation, you can use the PCI SSC paper to structure your virtualised environment and associated security solutions, processes and admin training. You can stipulate to your virtualisation vendor or cloud provider that they must follow the guidance and so demonstrate compliance. Bear in mind that you are making a major change to your environment, and you will need to perform a full pen test on the new structure as per requirements of PCI DSS.

Second, if you have already started down the virtualisation road, things can be more complex. You can use the guidance as a benchmark to see if you are in a position to demonstrate compliance within your virtualised environment. However, you will need to update your ecosystem and CHD flow diagrams to ensure you are in control of user rights and are monitoring traffic, etc. You may need to retrofit the guidance into your environment. If you have not done so, you will need to perform a full pen test, because the move to a virtualised environment is a major change.

Wider ramifications of virtualisation and PCI DSS
The PCI SSC's virtualisation guidance document is a good starting point, but it must evolve and become more prescriptive to be effective. Enterprises need more specific guidance on how to choose, deploy and manage virtualisation technology and still remain PCI DSS compliant. It specifically needs to drill deeper into virtualisation risks. For instance, there is hardly any mention of encryption of traffic within the virtualised environment. Whilst this is currently not mandatory, it probably should be, at least for mixed environments (which, from a security practitioner's viewpoint, are altogether questionable as a secure way of doing business).

Another element needing more attention is storage of data within virtualised environments. Companies should not store CHD unless necessary. However, if they do store CHD and do so on VMs, the attack surface increases yet again. This is a point that organisations need to consider. Security auditors may also argue that there is not enough emphasis on policies and procedures or admin user training around how to design, implement and maintain security within a virtualised CHD environment. As the guidance matures, I expect and eagerly await updates from the SSC regarding these points.

About the author:
Mathieu Gorge is the CEO and founder of consultancy VigiTrust. He specialises in PCI DSS, HIPAA and ISO 27001, and speaks regularly at international security conferences.

Read more on Application security and coding requirements