PCI DSS 3.0 has a few areas that can make this already complex situation a bit more so.
Merchants will recognize that PCI DSS compliance in the cloud has long been a complicated and challenging topic -- so much so that the PCI Security Standards Council published an entire document specifically about using the cloud in a PCI context. However, PCI 3.0 has a few areas that can make this already complex situation a bit more so. This isn't because version 3.0 has new language or requirements that address cloud specifically (it doesn't), or because it supersedes the prior guidance document referenced above (that's not in there either). Rather, the confusion is because some of the new requirements have implications that are quite complex to both address and maintain when dealing with cloud.
What's different in PCI DSS 3.0?
There are three new requirements in PCI DSS 3.0 that warrant underscoring as being most relevant to the use of cloud technologies in a PCI-regulated infrastructure:
- Req. 2.4: "Maintain an inventory of system components that are in scope for PCI DSS."
- Req. 1.1.3: "[Maintain a] current diagram that shows all cardholder data flows across systems and networks."
- Req. 12.8.5: "Maintain information about which PCI DSS requirements are managed by each service provider and which are managed by the entity."
Note that these are not the only new requirements -- nor are they the only requirements that have an effect on PCI in a situation where cloud technologies are used. However, for an organization that is using cloud and has developed a PCI compliance posture to address that usage within the CDE, these are the three requirements that are likely to cause the most chaos in the months to come. Understanding why requires delving into each one with a bit more depth.
Inventorying and IaaS
The first requirement that enterprises utilizing the cloud must be aware of is the inventorying of system components. The PCI DSS standard outlines what it means by a "system component" on page 10 of the PCI 3.0 document, but the salient point for our purposes is that it specifically includes virtual machines. Organizations that have tried to keep a reliable inventory of any virtual environment know how difficult this can be, but keep in mind that in a cloud deployment -- specifically Infrastructure as a Service (IaaS) -- it may be a bit more complicated than in a virtual environment that the enterprise controls directly, particularly when or if it is supported by a service provider. Consider for a moment the impact of helpful service provider support staff that decides to clone an instance on the fly to help test patch compatibility -- or that relocates images dynamically in response to a performance bottleneck. This means that customers must now be more diligent in tracking the creation and destruction of instances within the CDE to keep inventories current.
To prepare for this, organizations have a few options. Worst case, most IaaS vendors will supply a raw list of images in their environment for billing purposes or via their control panel. While this list might not be everything an enterprise wants (e.g., it might not indicate the purpose of the image or what software is on it), at least it's a start. If your organization has specific technical personnel from the service provider assigned to support your account (i.e., if you're a big fish with a particular provider), consider enlisting the provider's help in the creation of the inventory. If you're not a big fish or if your cloud service provider isn't amenable (or is too costly), consider employing automation capabilities to help; including a pre-configured inventorying agent in your virtual "golden image," for example, might help catch new instances or clones you don't expect.
More on PCI DSS 3.0
PCI 3.0: New requirements cover pen testing, service providers
PCI DSS version 3.0: The five most important changes for merchants
The history of the PCI DSS standard: A visual timeline
Data flow and SaaS
The next challenge area has to do with the mapping of data flows in certain cloud contexts, particularly Software as a Service (SaaS). Unlike Platform as a Service (PaaS) and IaaS, remember that in a SaaS context, the application itself is a "black box," meaning the SaaS customer is deliberately shielded from the underlying mechanics of how the application operates. For example, when you log in to LinkedIn or Facebook, do you know what specific servers your user ID travels over or how many different databases it connects to inside back-end environments? Do you care? Probably not, so long as it logs you in correctly. Now imagine addressing the requirement to not only understand how but to specifically document the exact path that data takes.
Now, bear in mind that nowhere in the standard does it say that data flow diagrams have to "know the unknowable," so going down to this level of detail when an enterprise doesn't have full transparency into the remote infrastructure isn't always realistic. On the other hand, a diagram with one single arrow on it pointing to the Internet saying, "PAN sent to remote billing provider," won't cut the mustard with many assessors, so a middle ground will need to be found that is thorough enough to satisfy assessors but not so onerous that an organization can't produce it or keep it current. Instead, start by documenting what you do know and engage vendors to help round out the rest. If they are unable (or unwilling) to assist in drilling down and getting more granular, be sure to document this fact for posterity. Providing an assessor evidence of a best effort attempt on your part to gather more specific data can help establish that you've thought the requirement through.
Service provider matrices
PCI has always required that enterprises keep tabs on the PCI compliance status of their service providers, but now it also requires organizations to document specifically which PCI requirements vendors are responsible for versus those the organization is responsible for.
While this might at first sound like an easy task, keep in mind that cloud providers (regardless of SaaS, PaaS or IaaS deployment) fall under this category as well as more traditional service providers. This means that enterprises must now map out who is responsible for particular PCI DSS controls: the organization or the vendor. While some service providers (particularly those that service the merchant community frequently) will have ready-made lists of the controls they provide, others may not entirely agree with how any given enterprise views the breakdown of responsibility. This means there could be some negotiation and back and forth to create a mutually agreeable list.
Again, it is important to note that these three requirements aren't the only changes that PCI DSS 3.0 introduces for merchants that employ cloud. They are, however, the areas where savvy security and compliance practitioners may wish to do some preparation and pre-planning to get ready for rolling out the new standard.
About the author:
Ed Moyle is the director of emerging business and technology at ISACA. He previously worked as senior security strategist at Savvis Inc. and as senior manager at Computer Task Group. Prior to that, he served as vice president and information security officer at Merrill Lynch Investment Managers.
This was first published in January 2014