If there ever was a hot topic these days it would be “The Cloud” and, in particular, the Amazon cloud. And that discussion inevitably leads to how are the Amazon cloud offerings are PCI compliant? A lot of this discussion has to do with the very limited amount of information regarding the Amazon service offerings. For some very bizarre reason, Amazon puts organizations interested in their PCI compliant services in a Catch-22 situation. Unless you sign up for one or more of the services, you cannot obtain the information on how the Amazon service offerings are PCI compliant. As a result, there is a lot of mis-information running around regarding the Amazon cloud. So to debunk all of the myths running around, I thought I would explain what the Amazon cloud is and is not and how it ends up PCI compliant and what you need to understand when deciding to use the Amazon cloud.
And before I get calls from someone at AWS about the fact that I am somehow singling them out or I am being unfair. I do not have a problem with AWs or anyone organizations’ cloud service offerings. What I have an issue with is how some service providers use obfuscation and confusion about their services in ways that make customers unsure of whether they are getting something that is PCI compliant. As I see it, the AWS service offerings seem to be PCI compliant, but there are things that possibly should be further explained so that everyone understands how that compliance is achieved.
The first part of the mythology revolves around what PCI compliant services Amazon Web Services, LLC (AWS) is actually providing. According to AWS’s Attestation Of Compliance (AOC), AWS is a Hosting Provider for Web and Hardware. The AOC calls out that the following services have been assessed PCI compliant.
- Amazon Elastic Compute Cloud (EC2);
- Amazon Virtual Private Cloud (VPC);
- Amazon Simple Storage Services (S3);
- Amazon Elastic Block Store (EBS);
- Amazon Relational Database Service (RDS);
- Amazon Elastic Load Balancing (ELB); and
- Amazon Identity and Access Management (IAM).
The AOC lists nothing for software provided through any of their services. As a result, a big myth that gets busted right off the bat is that AWS is providing software. At the end of the day, all AWS’s services are offering is Infrastructure as a Service (IaaS). As a result, how AWS is PCI compliant is fairly easy to figure out. They have totally minimized their responsibility on the PCI compliance front.
In addition to the AOC, AWS provides customers with a document entitled “AWS PCI DSS Controls Responsibility Summary” (CRS). This document explains the various services and the responsibilities a customer organization has when using these services.
The first piece of infrastructure used by AWS is virtualization in the form of Xen as their hypervisor. Because of the way AWS has implemented Xen, every virtual instances created by EC2 acts like an individual physical server in that there are no connections to any other server unless the organization defines such connections. This is referred to in the CRS as instance isolation. Finally comes the firewall. EC2 includes a firewall that is managed by the customer. Access to the firewall is controlled by an X.509 certification and access credentials provided through IAM. In addition to utilities to manage the cloud environment, AWS provides various application programming interfaces (API) to manage the AWS cloud environment.
The bottom line is that, at a minimum, an organization needs to subscribe to EC2, VPC and S3 in order to build a basic platform capable of computing (i.e., server, connectivity and storage). The need for other services outside of these will depend on what the organization is attempting to accomplish, whether or not they need the flexibility and scalability provided by AWS and other business factors.
From a PCI compliance perspective, the CRS categorizes the 12 PCI requirements into those that are AWS’s responsibility, shared responsibility between AWS and their customer and those requirements that are solely the customer’s responsibility.
In the AWS is responsible category falls requirement 9 or physical security and environment controls. Since AWS is providing the facilities to operating the underlying physical hardware, it is solely responsible for this requirement.
In the shared responsibility category falls requirements 1, 10 and 11. For requirement 1, AWS acknowledges that this is a shared compliance responsibility between AWS and their customer. However, AWS’s responsibility is only to provide a firewall and ensure that it segregates their customers from one another. The remainder of the responsibility for complying with requirement 1 is left to the customer.
For requirement 10, AWS indicates that they are responsible for:
- Maintaining log files for EC2 and S3 customer management operations (e.g. creation, modifications and deletion of these environments) for at least a year.
- Maintaining logs for the underlying software that provides the various services for at least a year.
This log information is monitored at least daily and is available to customers for their particular environment should it be necessary. All other parts of requirement 10 are the responsibility of the customer.
For requirement 11, AWS indicates that they are responsible for ensuring the security of their environment including ensuring wireless security. Customers are responsible for ensuring the security of the environments they construct using AWS’s services.
All of the remaining requirements, 2, 3, 4, 5, 6, 7, 8 and 12 are solely the responsibility of the customer.
So after all of this rigmarole, what is the advantage to be gained? Not much near as I can tell. The bulk of responsibility for PCI compliance still falls on the organization using the AWS services. So organizations looking to offload as much of their PCI compliance responsibilities as they can to AWS are looking in the wrong place.
But it does not end there. We are seeing more and more startup service providers that are using AWS services to avoid the capital costs of hardware and software of a 24/7/365 operation. Where this becomes tricky is when you have a service provider providing PCI compliant services effectively using AWS for their “data center.” In some cases, these service providers are trading on the fact that because AWS is PCI compliant, then their services must also be compliant. However, what these service providers forget is that once they start going beyond the IaaS model and offer services in the Platform as a Service (PaaS) and Software as a Service (SaaS) realm, they are now responsible for portions of PCI compliant that Amazon is not. As a result, organizations need to conduct due diligence on vendors using other cloud providers to provide their services to ensure that everyone is PCI compliant.
So do I think your organization should rush right out and sign up for AWS? Maybe if you have the right business case. But I do have some concerns regarding AWS’s service offerings and the statements surrounding how they are PCI compliant.
My first concern is in regards to requirement 1.2.3. This requirement is one of the few that is not allowed to be marked ‘Not Applicable’. As such, the QSA is required to document what procedures they conducted to ensure that any existing wireless is either not in-scope or that there is wireless in-scope and how it is secured. To document this, AWS’s QSA has written:
“[AWS] maintain this control for all internal and external services that it provides. In EC2 and VPC environments, this includes the network at the hardware and management level networks, which are not exposed to customers.”
This statement says nothing of what procedures were conducted to ensure that wireless was not visible to customers as well as the controls AWS maintains to ensure wireless stays out of scope. Essentially, we are asked to trust AWS that wireless is not on any customer networks. Now, to be fair, AWS is operating secured data centers comprised with racks of hardware all virtualized, so the likelihood that wireless would exist in such an environment on any one customer’s network is remote at best. . However, the PCI assessment process is all about verifying such statements, not just accepting them at face value as fact. As a result, I am concerned that what is supplied as evidence for complying with this test leaves much to be desired. What should be documented here are the procedures the QSA used to confirm that the controls AWS has in place are adequate to ensure that rogue wireless does not end up in their data centers.
Related to requirement 1.2.3 is requirement 11.1. As with 1.2.3, 11.1 is also not allowed to be marked as ‘Not Applicable’ regardless of whether wireless is implemented or not. For all of the tests under 11.1, the following statement is made.
“[AWS] maintain[s] this control internally.”
So what exactly does AWS do to ensure that their data centers remain wireless free or that wireless does not end up on the customer side of the network? No idea. I would like to assume that AWS is doing the right things in this regard, but, again, the PCI assessment process does not allow for assumptions, they require proof and this just does not pass muster. At a minimum, there should be a discussion of the procedures used by AWS to ensure wireless is not an issue.
While we are discussing requirement 11, we should cover vulnerability scanning, penetration testing, intrusion detection and critical file monitoring. All of which are the customer’s responsibility, not AWS’s. Again, AWS is providing IaaS and nothing else, so any such controls will need to be provided by the customer.
When reviewing the detailed responses in requirement 9, it was interesting to see that AWS is responsible for ensuring that for the portion of any customer’s cardholder data environment (CDE) that exists in AWS, AWS ensures that destruction of hardcopy materials are properly destroyed so to be unrecoverable. This begs the question, “Why would AWS have any hardcopy to destroy in the first place if they do not have access to customers’ environments?” No further explanation is given, but one would guess it was their lawyer’s idea just in case AWS might somehow come into contact with CHD on hardcopy.
The next area I have issue with is not related to the service, but related to how an organization contracts for the service. In an effort to fully automate things, unless you are a Fortune 50 looking to put your entire computing environment in AWS’s data centers, you can forget about negotiating a contract. When you sign up for any AWS service, you either accept their contractual terms and conditions by checking the ‘Accept’ box and clicking Okay, or you don’t get to use AWS. I know of a number of organizations that had real issues with that approach and, as a result, backed away from a more aggressive use of the AWS environment or decided they just could not accept the terms and did not go to the cloud at all. While the AWS contract does cover PCI compliance, but it essentially makes the customer the one legally responsible for compliance with AWS providing support when necessary.
So that is AWS in a nutshell. Not a bad thing, but something an organization needs to go into with their eyes wide open and understanding that they still have significant responsibilities even though they are now in “The Cloud.”
