Can Amazon Cloud Be PCI Compliant? Not Likely
Written by Peter SpierPeter Spier, CISSP, CRISC, CISM, PMP, QSA, PA-QSA is Manager of Professional Services at Fortrex Technologies.
Amazon’s higher end Web cloud offering is often considered one of the more secure cloud options. But a careful read of Amazon’s FAQ raises very serious compliance questions.
Let’s start with PCI’s own virtualization guidelines from June 2011: “In a public cloud environment, additional controls must be implemented to compensate for the inherent risks and lack of visibility into the public cloud architecture. A public cloud environment could, for example, host hostile out-of-scope workloads on the same virtualization infrastructure as a cardholder data environment. More stringent preventive, detective, and corrective controls are required to offset the additional risk that a public cloud, or similar environment, could introduce to an entity’s CDE. These challenges may make it impossible for some cloud-based services to operate in a PCI DSS compliant manner. Consequently, the burden for providing proof of PCI DSS compliance for a cloud-based service falls heavily on the cloud provider, and such proof should be accepted only based on rigorous evidence of adequate controls.”
That seems pretty clear. In a public cloud environment—such as AWS—the retailer must be able to examine credible evidence, demonstrating that all elements of the environment are secure, and not simply rely on a third-party’s word. That includes the virtual private cloud (VPC) alternative, because even its isolated network space relies on an AWS-based infrastructure. Therefore, to effectively support merchants and service providers who choose to use their services, Amazon should readily be prepared to be forthcoming and supportive of QSA validation, right? Not quite.
This is from Amazon’s FAQ: “A merchant can obtain certification without a physical walkthrough of a service provider’s data center if the service provider is a Level 1 validated service provider (such as AWS). A merchant’s QSA can rely on the work performed by our QSA, which included an extensive review of the physical security of our data centers.”
Amazon takes this position despite PCI DSS version 2.0 requirement 9 validation requirements, which instruct that the QSA verify physical controls and that both the QSA and the merchant/service provider annually verify storage location security.
Perhaps compliance is still possible, if we assume the following is provided by Amazon. For example, Amazon would have to provide report on compliance (ROC) content completed within a reasonable period of time from the date of assessment, given that PCI assessments must reflect a specific point of time. Amazon would also need to detail specific control evaluations, in addition to detailing how each control applies to merchant/service provider-defined cardholder data environment scope.
But what are the odds of this happening, given that Amazon won’t permit a simple walkthrough, let alone a customer site visit?
Then again, as Amazon states on its AWS Security and Compliance Center page, “Only those within Amazon who have a legitimate business need to have such information know the actual location of these data centers.” Therein lies perhaps the most puzzling of questions for cloud service adoptees: Where exactly is your data? We can only assume, based on Amazon’s documentation, that the secrecy is “a security thing.”
In fact, datacenter providers have long grumbled at having QSAs complete walkthroughs of their facilities, and yet it happens everyday without any known case of malicious security incident. So, is Amazon to be treated as a case of some datacenters being more equal than others? Not if the merchant QSA is adhering to the ROC Reporting Instructions.
Amazon continues: “The AWS environment is a virtualized, multi-tenant environment. AWS has effectively implemented security management processes, PCI controls, and other compensating controls that effectively and securely segregate each customer into its own protected environment.”
Hmmm. OK. Well, we know that compensating controls are used when a PCI DSS requirement cannot be met due to identified constraint and that they must also meet the intent and rigor of the original control. Notice how there is no mention of compensating control worksheets being included in the PCI Compliance Package? Perhaps if the merchant asks nicely.
Amazon is indeed offering some documentation about how its QSA has approved what Amazon has done. But what’s missing is documentation—and access—so your QSA can do the same for you.
Disagree? Would love to hear from you, either with a comment below or you can zap me an E-mail.
-Marc
July 10th, 2012 at 11:57 pm
Isn’t this whole article missing the point of PCI 12.8.x? If the merchant is using a service provider (Amazon) then all the merchant needs to do is follow 12.8.x regarding the relevant PCI controls. I’m not sure I see the issue the article purports is present.–lyalc
July 11th, 2012 at 8:31 am
Indeed, 12.8 applies to service providers. However, the entirety of the DSS applies to the assessed entity’s cardholder data environment’s applicable scope. As such, all system components which process, store, or transmit cardholder data within a defined network segment are in scope of assessment. Further, in a virtualized or cloud hosted environment, those system components which serve as a hypervisor must also be assessed. Finally, all system components or processes requiring privileged access to the cardholder data environment or providing management services in support of compliance must be assessed in scope of those services offered, e.g., management zone segmented log repositories should still restrict access to the log data and retain logs for one year.
July 12th, 2012 at 2:29 pm
So are you saying that you contend that cloud providers in general (AWS in this case) have most likely not assessed all components that should be considered as “in scope” to have an accruate ROC and Level 1 Service Provider attestation?
July 12th, 2012 at 2:35 pm
Ted, I’ll let Peter speak for himself, but my read on the column was that he wasn’t saying that at all. The point of the piece was not that cloud providers haven’t adequately performed assessments, but that retailers using those cloud sites might not be able to sufficiently prove their own compliance.
July 12th, 2012 at 5:54 pm
Correct, Evan!
Ted, I fully believe that each cloud provider determined to be PCI compliant as a service provider by a QSA was compliant at the point in time of the assessment and should be sufficiently maintaining their environments so as to support similar findings in future assessments.
However, as many service providers such as AWS do not themselves store cardholder data, the scope of their assessment is limited. Further, their compliance, while it may support service provider/merchant efforts to become compliant during the use of their services, does not constitute an inherited or automatic compliance for the service provider/merchant. In fact, when the compliant service provider does not provide sufficient information and support to those service providers/merchants who choose to use their services for cardholder data processing, storage, and/or transmission; it is their ability to demonstrate compliance that is harmed. It is this latter point that is the focus of the article.
July 15th, 2012 at 4:23 pm
Peter,
I think that your article is missing the point of PCI DSS and service providers, namely that using a service provider is not about compliance, it is about risk. Organizations need to determine under what circumstances they might use a service provider, and what is required.
I’ve worked with several different large service providers, and many are getting sick of having the same audits performed by different companies. The whole process is to establish a trust framework of service providers, merchants, and assessors, and the reduce the waste that people spend on QSA’s doing things for the sake of compliance that don’t provide much risk protection. Should merchants be paying QSA’s to do physical walk throughs of service providers that are already validated? I don’t see much value in it. Why stop at physical walk throughs and not just assess the entire service providers against all PCI controls, since the merchant is ultimately responsible?
The bottom line is that no merchant is required to use a service provider, but if they do it is up to them to define their expectation (12.8) and if they believe there are high risk areas where they do not feel comfortable leveraging another QSA’s work, then to write it into the contract.
However, we need to recognize that the PCI assessments don’t just cost the merchant’s money, they cost the service provider money and time as well, which translates into higher costs for merchants.
My recommendation is for any merchant to review their current risks and business processes and make a risk-based decision. For some, their risk tolerance and the nature of their business will not work for the Amazon’s of the world. However, there are several PCI compliance merchants using Amazon who are at less risk than their previous non-cloud implementations.
For the non-PCI folks of the world, I use a banking analogy. If you want to keep all your hard earned money and bury it in your backyard and fortify your house, go ahead. You will have more control, and no one stops you from doing it now. If you want to put it into a bank, there is some protection (like FDIC insurance), but as we’ve seen with the melt down, our financial systems brings along new risks with the benefits. Its not about what is right and what is wrong, compliant/non-compliance. It has to do with risk management and business strategy.
July 15th, 2012 at 10:17 pm
Hi, Tom. Thank you for your feedback. You make many excellent points. Indeed service provider risk and overall best practice risk management processes should be integrated into every organization’s approach to information and payment card security. Risk assessments conducted on at least an annual basis are, in fact, required by PCI DSS v2.0 requirement 12.1.2. However, the DSS and its assessment procedures are established by the SSC, required by the card brands, and enforced by the card brands and their acquirers. As such, required validation and scoping processes apply to Amazon the same as all other service providers and merchant. Further, merchant and service provider reporting requirements as defined by the card brands according to level must be completed according to documented assessment procedure and be attested to without exception to demonstrate compliance. The point made in the article is that there are several challenges when doing so in an Amazon AWS-based environment. Finally, I also suggest that compliance risk should be considered in the course of any risk assessment.
July 18th, 2012 at 6:46 pm
hi Peter, Tom and Evan
I agree totally with the points made by Peter and Evan. There is security, there is risk and there is compliance. Some of these objectives can be synonymous and some are not. PCI DSS is very stringent on what is required to be divulged as the breakdown between a service provider and a merchant as part of their own assessment utilizing the service provider. The onus is on the merchant and the QSA to establish that they understand the scope of the controls being provided by the service provider vs the controls that the merchant is responsible for.
I personally would not necessarily expect a physical review unless there were reasons to distrust the physical facilities, but I would never sign off on a ROC if there was inadequate evidence that the service provider was providing the required security controls.
My suggestion in this instance would be to de-scope PCI data from that environment and replace them with tokens and store the data in a PCI compliant environment where all controls could be validated, thereby leveraging the elasticity and cost savings of the cloud whilst ensuring associated risks and compliance are also covered. As Peter points out, a compliance risk assessment is essential when compliance is required and not just security.