Before we jump in, I want to let you know that I am very supportive of the increased levels of education.  As you may have read in my 3 Habits of Highly Effective Regulation, education is #1 on my list.  There is plenty of information on my old blog PCI Answers, my old PCI forum, the PCI SSC website, and Visa Alerts.

The PCI SSC Special Interest Groups (SIGs) have and will continue to release information that, although it does not trump the PCI standards, helps to clarify the interpretation and implementation of them.  The following is an “un-boxing” of the PCI Reference Architecture for the PCI DSS 2.0 Compliant Clouds as published by Cisco, VMware, HyTrust, Savvis and Coalfire.  The tagline used is that these companies are “all core members of the PCI [SSC] Virtualization Special Interest Group (vSIG)”.  It is important to note two things:

  1. The PCI Reference Architecture is created by many, many vendors.  As much as I love industry bodies weighing in, I would love to have seen a non-vendor name on the cloud architecture.  There is something very postured about a document made up entirely of vendors.  “Here, I have this thing called a PCI-Cloud, that if you configure in my data center, with my products, assessed by my QSA all will be OK!”
  2. The PCI Reference Architecture is NOT an official document released under the Virtualization SIG by the PCI SSC.

The 19 page paper poses some interesting questions and makes some casual comments.  Let’s deconstruct the document, through the lens of a practitioner, educator, and analyst.

First, in the opening paragraphs they violate my “standards are technology agnostic” rule by bringing up that somehow guidance is needed before one can assess compliance in the cloud.

The terms “virtualization” and “cloud computing” do not exist in PCI DSS Version 1.2.1. This version of DSS does not provide specific advice about whether CDE system components need to be physical. This is of no surprise as it was developed before virtualization technologies gained wide spread adoption. In PCI DSS Version 2.0 „System Components‟ include virtualization technology (hypervisors) and virtual system components such as virtual machines, virtual switches, routers and networks, virtual appliances, virtual applications and desktops.

It is important to remember when reading this and other documents, that data security (and compliance) is highly dependent on the use cases.  For example, we all thought we understood scope using network segmentation of physical systems, but how do we define scope in a virtualized world?  How does the scope for a distributed call center differ from that of a brick-and-morter retail environment?  What are the scope considerations of Virtual Terminals or administrative and management systems?

One could just as easily have said that version 1.2.1 of the PCI DSS did not use the terms “call center”, “data warehouse”, “pre-authorization”, “data aggregation” or a plethora of other terms, and as such the shroud of mystery exists as to how PCI compliance applies to these areas.

Furthermore, neither do the terms Tandem, voice response unit (VRU), or cell phones exist in the PCI DSS and as such one may not have clear guidance on how to assess these environments.  Taking this approach is simply defeatist – but this is where the clarification documentation corrects these false assumptions, which I applaud.  Even though the paper outlines an arguably biased use case, it does explore the efficacy of it and as such adds to the pool of possibilities.

3 Challenges

The document presents us with three “challenges” of PCI compliance in the cloud, all of which are valid and important points:

  1. If an in-scope CDE system component is virtualized, can it be adequately protected to meet all the PCI DSS requirements? What else becomes within scope?
  2. How can virtualized system components within a CDE be co-mingled with virtualized system components (servers, network components, security components, management and monitoring components, and such) used for non-CDE functions? Can CDE virtual system components reside on the same physical system as non-CDE virtual system components and still achieve PCI DSS compliance?
  3. How can adopters of emerging technology satisfy the intent of PCI DSS and adequately protect cardholder data without any specific guidance?

Remember that there are no precise answers to the above questions, only rather accurate answers with a relative probability density.  Which is to say, the answer is highly dependent on the use case.  Still, it is may times more important to know the right questions than to know the right answers to the wrong questions.

Let’s quickly answer question #3.  The intent behind the PCI DSS is to prevent the electronic and paper theft of payment card data. Regardless of technology, all architecture and guidance documentation should keep this mantra in mind.  Emerging technology can satisfy the intent of the PCI DSS as long as it is properly configured and maintained to achieve the the goal of payment card data security.

Operational Issues

The case studies base their configuration and environment on a list of assumptions that they enumerate.  In this sanitized case study all the proper controls are in place.  For example:

Hosts are hardened according to VMware‟s hardening best practices using the HyTrust Appliance. They are also routinely assessed for configuration drift, and automatically remediated depending on policy.

Pardon? I don’t thing many companies do this in their current environment, much less after having moved to a cloud based architecture.  I understand they listed the assumptions to focus on the architecture, but I want the reader to turn those assumptions into a TO DO or ACTION ITEM list.  All too often we make assumptions.

What is one of the most common assumptions many people make when moving to the cloud? People assume that the cloud provider will handle all roles and responsibilities related to data security and compliance.  Hey, since nobody defined who has to harden the servers let’s just assume the cloud provider is, since after all they are PCI compliant, right?  Wrong!

Before engaging a cloud provider, even one that validated their service offering as PCI compliant, make sure you understand the delineation of information security roles and responsibilities.  Again, the architecture is a framework but the use cases dictate security measures.


My favorite part of the paper is that it concludes by reminding you that IT IS POSSIBLE TO BE PCI COMPLIANT IN THE CLOUD!

Multi-tenancy and mixed-mode: CDE VMs and non-CDE VMs can be co-mingled on a cluster of hypervisors as long as adequate controls are implemented and validated to ensure proper isolation. Network controls and communication must be tested in the same or similar fashion as physical environments to demonstrate segmentation.

Update (per feedback from @Beaker):

A more complete conclusion is to remember the following when building/selecting a PCI compliant cloud:

  • Yes, you can be PCI compliant in the cloud, but not every cloud is PCI compliant.
  • This PCI Reference Architecture is just one of the many ways one can be compliant in the cloud
  • The type of data you retain (payment card data vs personal health information) and the use case of your environment (call center vs single location office) will determine what configurations are required for adequately protecting that data according to industry standards
  • Using a PCI compliant cloud provider will not make you PCI compliant