Mathias Rosenthal - Fotolia
Amazon Web Services (AWS) is becoming an increasingly popular infrastructure as a service. While AWS can help improve enterprise flexibility and availability, and can reduce cost and labor expenditures, before adopting, it is critical to understand how an AWS deployment will affect an enterprise's PCI compliance certification.
AWS PCI compliance: The responsibility split
AWS infrastructure is certified to be PCI-compliant for level 1 merchants -- the top tier of PCI compliance -- and is therefore also PCI-compliant for all merchant levels below.
However, this does not tell the full story; responsibility for PCI compliance is shared between the infrastructure provider and the client. The key point here is to understand where that responsibility split lies.
Taken from Amazon's documentation on PCI compliance, enterprises "will still be required to satisfy all other PCI compliance and testing requirements, including how you manage the cardholder environment that you host with AWS." This means that while the AWS infrastructure itself is PCI-compliant, the enterprise is responsible for servers within the cardholder data environment.
A very important area where AWS makes PCI compliance easier for businesses is with meeting requirement 9, which states that enterprises must "restrict physical access to cardholder data." The data center environments that AWS uses have all been certified to be compliant with this section. This is often a major enterprise expense in achieving PCI compliance, as it can involve upgrading physical security systems if servers are onsite, or assessing data centers. However, once a PCI QSA sees AWS is in use, he or she will be able to mark this section as compliant since Amazon has already been assessed in this area.
PCI responsibilities enterprises must be aware of
Enterprise PCI compliance responsibilities lie with the state of the servers hosted within the AWS infrastructure. This includes patching and monitoring of AWS security advisories, antimalware controls, identity and access management (including multifactor authentication), management of backups leaving the AWS environment, and documentation of processes and procedures for the cardholder environment.
In the case of identity and access management, enterprises are responsible for managing which users and services have access to the AWS console, the password policy and their rights as defined in security policies.
To demonstrate the responsibility split, let's look at the example of patching. All Amazon infrastructure that supports AWS will be patched regularly, as defined by the company's compliance procedures.
However, note that Amazon does not manage the operating systems and virtual machines enterprises deploy to the service, and can therefore not be in charge of patching these servers. Consequently, it is the organization's responsibility to keep these servers patched, and it will need to be able to demonstrate this to a QSA.
Enterprises are also responsible for PCI requirement 11, which states that enterprises must "regularly test security systems and processes." With the changes in PCI DSS 3.0, this not only includes vulnerability scanning, but also penetration testing. Amazon allows the installation of vulnerability scanning devices -- such as those from Qualys Inc. or Tenable Network Security -- within the AWS environment, which can then be used to run the required quarterly scans and rescans. The output of these tests can be shown to the QSA to satisfy requirement 11. Note that penetration testing must be agreed upon beforehand by first requesting permission from Amazon and then defining the times when the testing will take place.
Overall, AWS is a useful service for complying with multiple sections of PCI DSS, and can save enterprises both time and money.
However, organizations using AWS must ensure that both the servers they deploy within the AWS service are compliant, and that all relevant policy and procedure documentation is present.
About the author:
Rob Shapland is a penetration tester at First Base Technologies, where he specializes in Web application security. He has used his skills to test the websites of companies that range from large corporations to small businesses using a wide variety of Web technologies. He is a firm believer that all penetration testing should have manual techniques at their core, using automated tools to support these skills. He is also involved in network testing and social engineering.
Don't miss SearchCloudSecurity's PCI and cloud compliance guide
Explore three key requirements to help maintain cloud PCI compliance