In December 2014, Google announced the Google Cloud Platform (GCP) is now PCI DSS-compliant. This means merchants...
and application developers can now utilize the GCP in ways that intersect their cardholder data environment -- i.e., the portion of their computing infrastructure that stores, processes or transmits cardholder information.
For those who develop and sell payment and payment-related applications, clearly there are benefits; they can now utilize the Google Cloud Platform to do just that. In fact, the Google announcement itself cited WePay as an example of one such use case.
But what about the impact to merchants? Does this change the game? Can and should merchants make use of the GCP within the cardholder data environment (CDE) now that PCI compliance is on the table? The implications of this announcement from a merchant PCI compliance point of view can be no less significant than for software vendors -- they just might be a little harder to see at first blush.
What has changed?
First and foremost, the abbreviated version of the news is that Google has updated the GCP environment for merchant PCI compliance. This means that now, like its competitors Microsoft (via the Azure platform) and Amazon (via Amazon Web Services), the GCP environment can be used in a manner that traverses the cardholder data environment.
There are two caveats to put forth before we delve into how this might forward a merchant's compliance program, though. First, a merchant doesn't "automagically" become PCI-compliant just by using a PCI-compliant cloud such as the Google Cloud Platform. You, as the merchant, are ultimately responsible for your own compliance. To do that, you need to ensure any tools you're using -- even those that are maintained outside your firm by a service provider -- are being used in a compliant way. For example, if you were to use the Google App Engine to create an application that posts cardholder data to Facebook, you'd be just as non-compliant after the announcement as before. Stated simply, how you use the platform matters.
The second caveat to note is that the scope of the announcement applies specifically to the Google Cloud Platform. The GCP includes a wide array of Google service offerings, including the Google App Engine, the Google Compute Engine and a number of others. It's important to note that not everything offered by Google or hosted on its website is part of the GCP. For example, this announcement doesn't mean it's suddenly a good idea to start using Gmail to email credit card numbers around.
To GCP or not to GCP?
Caveats out of the way, this announcement could have some pronounced implications from a merchant PCI compliance point of view because merchants -- particularly those in larger environments -- have historically struggled when it comes to PCI; environments are complex and the requirements prescriptive.
Adding cloud to the mix can make PCI compliance even more of a struggle. Despite how carefully merchants scope the PCI cardholder data environment, using the cloud can make the CDE more porous. For example, bursting scenarios -- where public cloud instances are brought online in response to outages or increased demand -- can be problematic for workloads within the CDE. Likewise, the portability of virtual images can make it easier for admins to accidentally rehome virtual images from inside the CDE to an outside provider -- with a corresponding compliance impact when that happens.
These points beg the question of whether embracing GCP -- now that the option's there to do so -- within the CDE is a good idea. On the one hand, some organizations might find employing a PCI-compliant cloud platform can alleviate some of the pain associated with keeping on-premises infrastructure in line with PCI DSS requirements. On the other hand, some might find using an external provider complicates compliance; for example, by needing to supply different evidence to assessors as part of the review process. Making the determination about which will be the case in your particular shop is the difference between potentially making PCI DSS compliance easier or harder to accomplish.
One way to approach the decision is to start with a look back at your last PCI assessment. For larger merchants, take a look back at your last Report on Compliance; for smaller merchants, go back to your last Self-Assessment Questionnaire. Compare what would change on a requirement-by-requirement basis if you were using the GCP. Consider, as you do this, legacy compensating controls you may have, how you supplied evidence and what you're actually doing to meet each requirement. Would using the GCP or other provider make each of those things easier or harder to do? Does moving to the GCP mitigate the need for a compensating control? Or does it mean you'd need to re-architect a process or automated tool you're using to gather evidence? If you have complicated patch management, logging or administrative monitoring processes, would using a cloud provider make that better or worse? The answer will change both from environment to environment, and from requirement to requirement.
Looking at the requirements in this way, you may find the decision is more complex than a simple binary "yes" or "no" and the answer is different for certain applications, processes and environments. You may decide, for example, that a billing system with lots of compensating controls is more conducive to an external environment, while a vendor-managed virtual terminal is better the way it is. Keep a note of which ones fall into the "better fit" category versus which ones don't. This list can help you decide whether or not to embrace public cloud. Moreover, should you decide to take the plunge, the "better fit" items might become your shortlist of test or pilot cases.
Google's decision to embrace PCI DSS compliance within the GCP can be a boon or a hardship depending on your unique circumstances and might vary from situation to situation. By approaching the decision in a systematic and thoughtful way, you can ensure the decision you make is a strategic one.
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.
Don't miss SearchCloudSecurity's guide to PCI and the cloud