The Payment Card Industry (PCI) Security Standards Council (SSC) recently released a document, "Information Supplement:...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
PCI DSS Cloud Computing Guidelines," that should be on the radar of any organization that has the PCI Data Security Standard (DSS) in its regulatory scope, be it a cloud customer, a cloud services provider (CSP) serving clients that may need to be PCI-compliant, or any other party involved in the payment lifecycle working within a "cloudified" environment.
Sometimes organizations learn after the fact that a PCI-relevant system has been moved into the cloud.
To help organizations that might be struggling with PCI compliance, we've distilled the most salient points from that document: specific things that organizations should have in mind as they approach the document, how to discuss it with their service providers or customers, and what they might need to do as next steps. Since the document is lengthy (50 pages), a thorough summarization of every point isn't practical; by covering some of the key themes, which we'll do in this tip, organizations will have a leg up on how to use the document and incorporate it into their planning.
Putting the cloud guidance in context
Many organizations struggle to understand the effect of cloud computing on their compliance with the PCI DSS. One might think that this wouldn't be an issue: After all, shouldn't organizations have a plan that is well thought through before moving some or all of a cardholder data environment (CDE) to the cloud? The information supplement, of course, recommends that they do, but it turns out that (as a practical matter) sometimes use of cloud in the CDE is less overtly planned than one might assume. For example, consider an Infrastructure as a Service (IaaS) migration. Will every enterprise know with 100% certainty which machines store, process or transmit cardholder data before migrating them to the cloud? Not always. This means that sometimes, organizations only learn after the fact that a PCI-relevant system has been moved into the cloud. As a consequence, guidance around this is clearly needed -- particularly for merchants.
In fact, the SSC's 2011 document, "Information Supplement: PCI DSS Virtualization Guidelines," contained some material (section 4.3) that specifically focused on cloud. While mostly from an IaaS perspective (given the virtualization focus of the document), it did establish a few things: that compliance in a cloud context was at least possible (not a universally held opinion a few years ago) and that compliance in the cloud could be a joint effort between customer and service provider. As a consequence, much of the groundwork for how to establish PCI compliance with cloud assets has already been laid.
Making use of the guidance
While the PCI cloud computing supplement provides a fairly thorough overview of cloud computing generally (a necessary level set), the real meat of the guidance is in sections 4, 5 and 6 ("PCI DSS Considerations," "PCI DSS Compliance Challenges" and "Additional Security Considerations," respectively). This material will have a different effect on various types of organizations, depending on whether they are merchants (users of cloud services), service providers (providers of cloud services) or assessors.
For merchants: In the context of the guidance, many merchants wish to understand how cloud computing changes their compliance efforts. In this case, they'll be on familiar ground since it's very much akin to DSS compliance overall: First determine scope, and then determine how and where to apply specific controls. Merchants should pay particular attention to discussions on scoping (section 4.5), the effects of CSP validation efforts (section 5.1) and responsibility assignment for specific controls (section 4.2 and Appendix A).
From a scope standpoint, the guidance explicitly states that expansion of the CDE includes the cloud environment when cardholder data is included in that environment. This can be a big deal, since that means compliance scope will include controls that may be operated by a service provider instead of their internal team. The guidance recognizes this and outlines several possible strategies for scope minimization: removing card data from the cloud, minimization of the controls the CSP is responsible for, as well as the use of cryptography (provided the cloud customer retains control of the keys) to selectively limit scope.
For the controls themselves, the guidance underscores the need to assign responsibility for specific controls between the client and the service provider organization. While no two use cases are the same, the guidance offers examples of how to do this across common Platform as a Service, Software as a Service and IaaS deployment scenarios. For merchants that are currently in a customer relationship with one or more cloud providers, the responsibility assignment matrices can be a useful starting point for detailed discussions and agreement on who does what.
For service providers: From a service provider's point of view, it's obviously useful to understand how their clients will scope their CDE: specifically, the factors that inform how scope is determined. However, the more useful material, in my opinion, is the discussion about verification of service provider compliance and controls (sections 5.1 through 5.3), as well as the responsibility assignment material (sections 4.1 and 4.2, and Appendix A.) This material establishes what customers (be they internal customers of a private cloud or external customers of a public cloud) need to look for when verifying a service provider's environment. Why is that helpful? Because this should give the service provider an indication of what customers -- and, by extension, their assessors -- look for to validate the service provider's compliance.
In terms of specific controls, service providers should also familiarize themselves with the responsibility assignment examples and supporting materials outlined in the document. Why? Because these are the controls that customers will ask for (most of the time) from their providers in terms of controls. So, if you are a service provider and you don't currently implement those specific controls, you might wisely expect pushback from customers about why and what you might do instead to make their compliance more feasible. Also, savvy service providers might anticipate that these specific requirements will soon find their way into requests for proposals and specific contractual discussions, so having a ready answer can help them prepare from a sales standpoint.
If you are in some way involved with PCI compliance in a cloud context, this is a must-read document, and no summary will do it justice. However, as you do so, pay special attention to the sections I highlighted: for merchants, the sections on scoping and service provider validation; for service providers, the sections on compliance validation; and for both, the sections on responsibility assignment. While the entirety of the document is useful, these are the areas of the highest likelihood of impact to your compliance efforts.
About the author
Ed Moyle is currently director of emerging business and technology for ISACA. Moyle previously worked as senior security strategist for Savvis and as senior manager with CTG. Prior to that, he served as vice president and information security officer at Merrill Lynch Investment Managers.