A few hours ago Google announced that Google Cloud Platform is now certified for compliance with PCI-DSS. Payment Card Industry – Data Security Standard are security standards built by the Payment Card Industry Council to minimize the credit card frauds. These standards are applicable to organizations who deal with payment cards including credit cards and debit cards and have to ensure that cardholder’s data is completely protected from misuse of their personal information. Compliance with this standard enables customers to hold, process, or exchange cardholder information from any branded credit card.

Amazon Web Services works upon a shared security responsibility model where AWS responsibility is to secure the underlying infrastructure and it is your responsibility to secure any connection made to and any data put upon that infrastructure. For example, it is AWS’s responsibility to ensure the security of their physical infrastructure, facilities, virtual infrastructure while when it is client’s responsibility when it comes to OS patching, data encryption, and of course the application itself.



AWS has already achieved PCI-DSS compliance for shared hosting providers and has successfully validated for Level-1 service provider under PCI-DSS version 3.0. In this post, we will see how you can achieve PCI-DSS compliance for your infrastructure on top of AWS. In any case, you should always ask for an independent Quality Security Assessor (QSA) to validate that your environment is PCI-DSS compliant. Nevertheless, the following 12-item checklist can really help you harden your infrastructure and protect your customers from frauds.

Make your application compliant with PCI-DSS on AWS: a 12-items checklist

1- Install and Maintain a Firewall configuration to protect cardholder data

Ensure your environment is configured under Virtual Private Cloud (VPC) where components are segregated into public and private subnets, the former acting as DMZ zones.

Ensure all critical data (like cardholder data) is stored in private subnets, not directly accessible from the Internet.

Use a correct combination of security groups and network ACLs.

Limit access to critical components.

Ensure that along with ingress and egress rules for security groups and network ACLs are also controlled for critical components.

Use Unified Threat Management (UTM) tools in DMZ zones as an additional layer of security.

Enable a formal process of approval to all changes made to network configuration, security groups, network ACLs, etc.

2- Do not use vendor-supplied defaults for system passwords and other security parameters

One primary function per instance, that is: using a single instance for multiple functions (like a web server, plus an SFTP, plus a database server, etc) lowers the security level for your environment. The functions with lower security levels will introduce security weaknesses for other functions.

Remove unwanted packages, services, and scripts from your instances.

Enable additional security measures on required services like passphrases on SSH key pairs or implement passwords for restarting services.

3- Protect stored cardholder data

Encrypt Cardholders Data at rest: If cardholder data is stored on a database on EC2, the client can leverage full disk encryption to encrypt the data. There are multiple tools available on AWS Marketplace which helps us to encrypt root and additional EBS volumes. If cardholder data is stored on a database on RDS, the client can either leverage on transparent data encryption (TDE) or encrypt data over SQL queries. Oracle and SQL server on RDS supports transparent data encryption. If you are using MySQL or PostgreSQL, you have to rely on SQL queries to encrypt data.

Ensure only minimal required cardholder data is stored.

Define policies for sensitive data retention period and processes for secure deletion of sensitive data.

Rotate encryption keys and store at fewest possible locations.

There are multiple ways to store your encryption keys: using key-encrypting keys – do it yourself rely on AWS partner solutions on AWS Marketplace use the recently launched AWS Key Management service which integrates with S3, EBS, and Redshift use AWS CloudHSM

Limit cardholder’s data access to necessary individuals only.

4- Encrypt transmission of cardholder data across open, public networks

It is important to encrypt sensitive information during transmission over public networks. To enable secure transmission over public networks, you need to use the appropriate certificates on EC2 instances or ELB.

AWS Elastic Load Balancers provides support for SSL certificates which allow you to perform SSL termination at the load balancing layer.

5- Maintain a Vulnerability Management Program

Configure anti-virus softwares on EC2 instances and ensure all of them are timely updated.

Use vulnerability scanners in your AWS environment. They help you to prepare for PCI-DSS audits too.

6- Develop and Maintain secure systems and applications

Ensure all security patches are reviewed, tested and timely applied on your EC2 instances and other AWS resources.

Keep looking at AWS related security bulletins.

Develop your internal and external software according to PCI-DSS guidelines.

It is a best practice to segregate your development, staging and production environment.

Use IAM groups, roles, and users. Ensure there are no test IAM users.

Enable MFA for IAM users with a strong password policy.

Rotate IAM users access key and secret access key on regular intervals.

Enable Cloudtrail logs and integrate them with Cloudwatch. Setup alerts on Cloudtrail activity. For example, send an alert email for failed user login after 3 attempts.

If you are serving web application, ensure common coding vulnerabilities (SQL injection, Cross site scripting, directory traversal, etc) are taken care at the application level or use a web application firewall in front of your web servers.

Any changes made to your environment has to be approved and documented.

Perform a regular security audit of your environment.

Avoid manual deployment. Leverage on automation.

7- Restrict access to cardholders data

Use strict IAM user policies – limit AWS services access to individuals whose job requires such access.

If your organization supports SAML, you can enable single sign-on (SSO) and let users of your organization directly authenticate to AWS management console without having IAM identities.

8- Identify and authenticate access to system components

Ensure that everyone (even administrators) access the AWS management console via IAM accounts. Root account credentials shouldn’t be used in any case.

Enable two-factor authentication for AWS accounts. AWS has support for virtual and hardware MFA devices. For virtual MFA devices, you need to install apps on your mobile phone. It supports iPhone, Android, Windows and Blackberry phones.

There shouldn’t be any shared credentials. Assign unique IDs to individuals. This holds true for IAM accounts and EC2 instances.

Build production ready AMI’s and launch them without key pairs. This way no one will be able to login into your instances.

9- Restrict physical access to cardholder’s data

AWS is already PCI-DSS compliant, so that removes the burden of physically securing your cardholder’s data. No action needed here.

10- Regularly monitor and test networks

Perform regular audits of your Cloudtrail logs to identify login details, creation, and deletion of resources, etc.

Deploy intrusion detection and prevention systems which helps us to monitor instance login details, security events, file integrity, change detection, etc.

Ensure all instances and resources are in the same time zone and synchronized with the same NTP server.

11- Regularly test security systems and processes

Perform vulnerability scanning, penetration testing, file integrity monitoring, log inspection, etc. on your environment at regular intervals. It is necessary to inform AWS before performing penetration testing.

Perform third party audit of your environment.

12- Maintain a policy that addresses information security for all personnel