Prepare your PCI-DSS journey on AWS

PCI-DSS is one of the most important certifications in cloud computing. This certification proves that your platform is following the best practices in order to manage credit card data. It is about enforcing standards to apply, but not the tools to use which is a client‘s choice.

Payment Card Industry Data Security Standard (PCI-DSS) compliance is a requirement for any business that stores, processes, or transmits cardholder data.

There are four PCI compliance levels, which are determined by the number of transactions the organisation handles each year. Here is a detailed explanation that can be found here.

• Level 1: Merchants that process over 6 million card transactions annually.
• Level 2: Merchants that process 1 to 6 million transactions annually.
• Level 3: Merchants that process 20,000 to 1 million transactions annually.
• Level 4: Merchants that process fewer than 20,000 transactions annually.

This article is a set of flashcards that will explain our experience to design a PCI-DSS compliant platform on AWS, without involving too much detail. I will highlight the main points to consider for AWS environment design, the services thatIi’ve used and how to enforce this design by external tools to feed certification requirements.

I suppose that you already have good knowledge of AWS services in order to have a good understanding of this article. I am going to mention the AWS services only and how to use them. I am inviting you to see the full description of these services on AWS official website.

AWS Environment Design:

“Good things start from the beginning”, it is very important to have a robust AWS organization design from the beginning. AWS recommends to use a multi-account architecture for different reasons to ensure:

• security and governance to minimize the blast radius of breaches
• administrative Isolation
• flexible Billing and Costing Options
• … and more advantages that are detailed here.

Someone may ask, what does this have to do with PCI-DSS? Yes sure!! The multi-account is not a requirement itself, but environment (dev, staging, prod) isolation is!!! If we look into details, isolation is about separating network environments from each other, which can be done by using different AWS VPCs. But, I recommend the multi-account architecture to ensure, not only isolation, but also leaves the doors open for future development, cost saving and fast remediation if needed.

However, the following points are recommended to consider for AWS environment design:

• Transversal account: AWS recommends separating development, staging and production environments into different AWS accounts. Hence, for most use cases, these environments may have to share some services. The transversal account groups these shared services and makes them available for other AWS accounts. Let’s take the AWS SES example, this service is used to send emails using valid domains. The validation step requires some configuration in SES and the hosted DNS zone to be able to send emails from this specific domain. Having this service in one place allows you to have only one validation to do, and the service can be shared via IAM with the rest of AWS Accounts. Also, when using a third party tool that you need to pay a licence for, using a shared account allows you to pay only one licence for all of your environments.

There are many examples of shared services, here is a not limited list:

• AWS S3 for tfstates, AWS Dynamodb to centralize Terraform builds
• AMI configurations and Builds
• AWS GuardDuty, in order to centralize continuous threat detection
• AWS SES to send emails using specific domains
• AWS ECR as a common Docker image registry
• Vulnerability scanner
• CI/CD tool
• … etc
• Centralized logs and metrics: PCI-DSS requires the collection of all log access, at API and system levels for all AWS accounts. Having these logs in a centralized collection point helps you to perform a better management. AWS provides Cloudtrail which allows you to send all the API actions to one data collection point. These log files can be signed up using the AWS CloudTrail Log File Integrity feature to avoid any kind of alteration.

For system logs and metrics, the AWS VPC Peering can be used to collect them at data collection point, while remaining private.

The logs and metric centralization can be done in the same transversal account, or another monitoring account. Feel free :), I just recommend you not to use the same account as for your application environments (dev, staging, prod).

• Different Level Access: it is highly recommended to have multiple access levels for users on AWS environment. This allows to guarantee the least privilege for users. You can use different profiles like: AWSMaster, AWSAdmin, AWSDevelopper, AWSSecurityAuditor, AWSCostManager, …This can be ensured by using AWS IAM roles and policies. However, PCI-DSS requires that these access levels are well documented and explained, with the list of users and their profiles.
• Enforce Authentication: PCI-DSS requires all the developers that have access to AWS environment, to use MFA authentication enforcement. In addition, there are also some password requirements, it must:
• Be changed each 90 days
• Respect a minimum number of characters (>=9)
• Respect a minimum characters variety

Moreover, the user must be locked out after 5 failed (maximum) authentication attempts. AWS IAM or AD can ensure these requirements. This can be ensured using an authentication account to manage only this process, and centralize all the accesses to the platform.

AWS offers Landing Zone and ControlTower that allow you to address all the mentioned constraints and recommendations constraints. AWS recommends ControlTower which is an implementation of AWS best practices, simple to use and more user friendly. In addition AWS is about to abandon the Landing Zone which will be replaced by ControlTower .AWS recommendations can be found here.

AWS Infrastructure Design:

PCI-DSS does not require a specific infrastructure model to implement, but it demands the presence of some elementary components. AWS well-architected framework (AWF) can be used as a reference of best practices to design your infrastructure. Take into consideration the following points:

• OS Hardening: there are different kind of hardening standards that can be implemented: CIS, ISO, SANS, NIST …etc. PCI-DSS requires you to choose one of them and apply it to the infrastructure. AWS Inspector can be used to check the compliance of Linux servers against CIS standard. This agent can be scheduled to run a security assessment on a server and produces a detailed list of security findings.

The hardening of an OS is time consuming, especially when you have more than 4XX findings to fix. AWS Marketplace provides CIS hardened system Images available, which can be used to save your time.

The Auditor will ask you to provide the security assessment report to check on the compliance. Sometimes we cannot fix all the findings due to some technical requirements. For example in the case of a container orchestrator using Docker, you need to keep the iptable rules open, so the orchestrator can work properly. Thus, these explanations must also be provided to the auditor in order to accomplish his final report.

• Container Hardening:

A container image embeds much of what typically defines a system, so the rules of hardening apply to it the same. Ideally, container images should be signed to ensure their integrity. AWS does not provide a service for this task, and you must use third-party tools like Notary.

This is an example of a hardening guide for Docker.

• Secrets and data protection: Data Encryption is mandatory. The encrypted data and its secret should not reside within the same location. Ensure that you can rotate the secrets and update them at least once a year, this is a PCI-DSS requirement. AWS KMS, HSM provide you with a way to store secrets and rotate them automatically with an AWS lambda. For the reminder, AWS KMS is a multi-tenant service in contrast with AWS HSM which is not.
• Data Loss Protection (DLP): There are different AWS services which integrate encryption features, to prevent data from loss, for example: AWS S3, EBS, KMS, RDS, Secrets Manager … etc. PCI-DSS requires to scan in addition the outgoing data, and prevent the loss of sensitive ones like payment card numbers. AWS relies on third party tools to accomplish this functionality.
• SSL/TLS everywhere: The SSL must be used to encrypt data in transit, inside or outside the system. AWS ACM could be used to provide valid certificates that can be used within AWS load balancers to encrypt the incoming data. For internal communications, they also have to be encrypted, even if you are using container orchestrators technologies like: Kubernetes, Nomad …, the TLS mode should be activated.
• Network restriction and filtering: This is one of the most important aspects in PCI-DSS. All the ingoing and outgoing traffic must be restricted and filtered through.

AWS provides Security Group and NACL to restrict the network traffic using different criteria like: network protocol, port, source/destination ip addresses. AWS WAF helps to protect your web applications or APIs against common web attacks.

However, AWS does not yet provide a service for outgoing traffic filtering and domain whitelisting. Thus, the use of third party tools is required, for example Squid suggested on AWS blog.

The auditor will ask you to provide the detailed network design, and the explanations for the opened ports and protocols in the infrastructure. He will also do some checks in the AWS environment to validate the documentation that you’ve provided.

• Vulnerability scan: PCI-DSS requires the use of a vulnerability scanner to prove that your platform is compliant. AWS provides many services to enforce AWS environments security like IAM, VPC, Config, GuardDuty, WAF, and Inspector. The latter operates only on system level, which makes it a non complete vulnerability scanner service for the moment.

In this case you should rely on third party tools to accomplish this requirement, for example: Qualys, Rapid7, Beyond Security. These tools can run deep infrastructure scans, for the network, system and applications. And returns a very detailed report about its state.

This report will be asked during the audit to approuve the infrastructure. But before that, all the high level (5*) findings must be closed before the audit ends, and for the rest (4,3,2,1) they must be treated as soon as possible after.

• Server Antivirus Scan: The certification requires an antivirus agent running and scanning the system continuously. AWS Marketplace offers many choices of agents that can be used to cover this topic. Also, open source projects like: ClamAV, Comodo Antivirus, RootKit Hunter …. and more.
• Pan / Credit Card Scan: The goal here is to prove that the server filesystems do not store any sensitive information like credit card numbers. The auditor may ask you to checkout this point by running a pan/credit card scanner on the servers. There are OpenSource projects that can be used for this purpose: CCSRCH, Pantastic, …

AWS Administration Design:

Administration access on AWS can be separated on two levels. Access to AWS services, which can be ensured by AWS IAM, SSO or AD. And server access, it can be ensured by a bastion host, or AWS SSM and EC2 Connect.

• AWS services access restriction and tracing: I’ve introduced the restriction point in “AWS Environment Design, Different Level Access” section, I will focus on tracing in this part. AWS Cloudtrail logs all the AWS API actions made by a user. These logs can be archived and stored on AWS S3 bucket for analyzes and investigations. AWS CloudTrail can be strengthened by AWS GuardDuty which allows to monitor the API logs and detect the malicious activities, like unauthorized behavior on IAM authentication.
• Server access restriction and tracing: All the server accesses must be restricted to only designated users, and all the system actions must be traced and archived. AWS EC2 connect and SSM provide the ability to log all the session actions to a cloudwatch group.

Beside tracing, PCI-DSS requires also that all the system logs to be collected in a SIEM to detect any malicious activity on the servers. For the moment AWS does not provide a service to ensure this, that’s why we need third party tools that we can find in the marketplace or outside AWS. In addition, the system logs must be preserved in format that we can identify which user made which action on which server, at which time.

AWS IaC Design:

“Automation lives matter” yeaaah !!!. Many automation languages (IaC: Infrastructure As Code ) can be used to code the entire infrastructure. This is a not limited list that we can mention here: AWS CloudFormation, AWS CDK, terraform, cdktf, Pulimi, Ansible … and many more. The use of any of these previous tools is not a PCI-DSS requirement, BUT it is highly recommended, it allows you to remediate easily, more efficiently and fastly during the audit period. However, the other benefits are detailed here.

You have to consider the way that you are implementing the IaC. It can be used as a proof for the auditor that your environments are identical. Also, secrets should not be hardcoded. You can use AWS Secret Manager or Parameter store secrets to store these secrets in a safe place, and use them directly in your applications.

GitOps practices are highly recommended and also appreciated by the auditor. It shows the ability to manage the IaC by operation team, using developers practices and tools namely git. The use of git branches and merge requests (MRs) allows to manage the IaC more efficiently. The MRs must be validated by another team member in order to approve the piece of code before applying it to the infrastructure.

Documentation Design:

The point here is about highlighting the importance of documentation especially for the PCI DSS Audit.

Make sure that the Auditor will not get involved in all your infrastructure details, but it helps to have clear documentation that explains how it works. He will check the coherence against reality during the audit. Also, a big part of this documentation will serve as proof for the auditor, and avoid for you last minute work during the audit.

There is no requirement about the format, but it must be clear enough for the auditor, like using schemas, tables, graphs, text … etc. There are many tools that can be used, I can mention: lucidChart, Draw.io, CloudMapper…etc

The following points are recommended to prepare before the audit:

• AWS Organization Scheme, explain how the environments are separated from each other.
• AWS System Infrastructure Scheme
• AWS Network flows, including: AWS VPCs, Subnets, Route Tables, NatGateway, InternetGateway, VPC endpoints …
• AWS network ports and protocols configuration in NACLs, SGs
• Data flow, to show how data is routed within your infrastructure, and how services are talking to each other..
• AWS account authentication, and user management, you should explain how to Add, Update and Delete a user.
• AWS Root Account access, it should be delegated to only one identified person in the company.

During the audit, the auditor may ask you to provide additional proof, to validate the compliance of the AWS infrastructure. These are some points to give you an idea:

• AWS CloudTrail Logs
• AWS SSM session logs
• AWS AD / IAM configuration screenshots
• AWS Inspector scan reports
• Internal and external vulnerabilities scan reports
• Pan / Credit card information, filesystem scan reports

Conclusion:

PCI-DSS on AWS is one of the most challenging projects that I’ve released in my career with the help of my team. I have learned a lot and done a lot of awesome things on AWS. Special thanks for my colleagues at Wescale, for reviews, suggestions and fixes to improve the content of this article.

I conclude this article with some advice, and recommendations to summarize the different points that I’ve addressed earlier in this article.

REMEMBER:

• Good things start from the beginning, having a good design (organization, system infrastructure, IaC) allows you to remediate faster during the Audit
• Automation Lives matter, I can say it is a must have especially for large scale infrastructures
• AWS Well-Architected framework is your guide for good practices during the journey
• Take care of documentation, and start it from the beginning. It should be included in the “Definition Of DONE”
• Prepare an answer for each point that is not compliant and cannot be fixed for some technical reasons
• Be aware that, unfortunately in some cases, AWS relies on third party tools to accomplish PCI-DSS requirements
• Checkout all the PCI SSC Cloud Computing Guidelines and version improvements here.
• Checkout the certification details on AWS web site.
• And last but not least, PCI-DSS is about configuring only what you need, and not letting doors open in your infrastructure

And most important of all: enjoy what you are doing and good luck. :-)

References to go further

• Specification PCI-DSS
• PCI-DSS Compliance Levels
• Notary
• [AWS Blog — Set up outbound proxy with domain whitelisting](https://aws.amazon.com/blogs/security/how-to-set-up-an-outbound-vpc-proxy-with-domain-whitelisting-and-content-filtering/)
• Security best practices for AWS IAM
• Data loss prevention and strategies
• Practical Linux hardening guide
• Docker hardening guide
• AWS Control Tower vs AWS Landing Zone
• 6 Benefits of adopting an AWS multi-account strategy