How should an organization approach PCI compliance in the cloud?? We’ll answer this question and address key concepts for implementing and maintaining cloud environments that live up to the PCI DSS standards!
PCI Compliance in the Cloud
Overview and Context
How does my AWS or Azure environment impact my PCI Compliance efforts?
How should I think about meeting PCI requirements that appear to be written for legacy infrastructure scenarios?
Does building on AWS make me PCI-compliant automatically?
These are all great questions! The purpose of this blog post is to address important key concepts in implementing and maintaining PCI compliance in the cloud.
For purposes of this blog post, we are going to assume that you have a basic understanding of the Payment Card Industry Data Security Standard (PCI DSS). If that is an invalid assumption, you can find a summary of the basics of PCI DSS in our Learning Center or our PCI DSS Basics video.
The following are the key concepts that we will address in this post:
- Applicability of the PCI DSS to the Cloud
- The Shared Responsibility Model
- PCI SSC’s Guidance and Examples
- Utilizing your QSA
- Use of Compensating Controls
- Maintaining Compliance in the Cloud
Applicability of the PCI DSS to the Cloud
Bottom Line Up Front (BLUF): If your organization processes, stores, and/or transmits cardholder data, the entirety of the PCI DSS applies to your cardholder data environment, regardless of whether your infrastructure is onPrem, hosted in a datacenter, or built on one of the big cloud services providers, such as AWS, GCP or Azure.
This is true whether you have a containerized environment or are subscribing to SaaS, PaaS, or IaaS. Now, that blanket statement is nuanced, but as a starting point, that is PCI’s stance on the matter.
As a side-note, if you are wondering what a cardholder data environment (CDE) is, how to scope a CDE, or reduce the scope of your CDE through the implementation of segmentation controls, check out this blog postas well.
The Shared Responsibility Model
Between Your Service Providers and Your Organization
In practice, while the whole of the PCI DSS applies to your defined cardholder data environment (less any requirements that are truly N/A), there may be one or many service providers that your organization subscribes to, such as AWS, that play a role in – and have responsibility for – meeting specific PCI DSS requirements on your behalf.
This is where the idea of Shared Responsibility comes into play.
For example, depending on your level of subscription in AWS, as a PCI DSS Compliant Level 1 Service Provider, AWS will operate some of the security controls on your behalf, per the contract and service level agreement. The most common example would be physical security of, and access to, servers and other system components.
AWS manages this on behalf of its customers, and during a PCI assessment, this would be something that your organization would rely on AWS (via their PCI DSS Attestation of Compliance (AOC)) to meet on your behalf. Because AWS is PCI DSS Compliant and is operating security controls to meet these requirements, your organization can ‘inherit’ these controls and reduce the scope of PCI DSS requirements over which your organization will be assessed.
How would you know that AWS does this on your behalf, and, just as importantly, how would you know what AWS does NOT do? AWS, as well as the other cloud service providers, specifies the requirements it meets on behalf of its customers in something called a Responsibility Management Matrix, which breaks down each PCI DSS requirement and delineates whether the operation of respective security controls is AWS’ responsibility, AWS’ customers’ responsibility, or shared responsibility.
It is important that all organizations that subscribe to AWS and need to be PCI compliant familiarize themselves with this document, as it is critical to understanding who is responsible for what PCI DSS requirements. This document is available to AWS customers through the AWS Management Console.
Further, depending on the level of service subscribed to within AWS and the tools implemented, AWS may take on additional roles in helping your organization maintain its PCI Compliance.
For example, if your organization subscribes to AWS Fargate, AWS will also manage the security of the underlying operating systems for the servers on which your environment is built. Instead of having to worry about patch management, AWS does this on your behalf, providing your organization with fewer requirements to worry about.
Between Your Organization and Your Customers
If your organization is a service provider and seeking to be PCI compliant, your organization will also need to provide such documentation to your customers delineating your organization’s responsibility for meeting PCI requirements on behalf of your customers vs. what your customers are responsible for (see PCI DSS 12.9 – Additional requirement for service providers).
PCI SSC’s Guidance and Examples
The PCI Security Standards Council (PCI SSC) has acknowledged that clarification is needed around how to apply the PCI DSS to different technologies and environments, such as virtualization, cloud, and containerized environments.
In 2011, the PCI SSC published PCI DSS Virtualization Guidelines, and in 2018 it published PCI SSC Cloud Computing Guidelines, both of which seek to clarify how organizations should apply the PCI DSS to the modern tech stack. Additionally, PCI SSC publishes periodic FAQs to clarify its stance on certain questions that arise from members of the PCI community.
Of note, the PCI SSC Cloud Computing Guidelines are particularly helpful in applying the PCI DSS to the cloud environment, and the following sections are worth noting and reading:
- Section 4.5.2 – Scoping Examples for Different Cloud Deployment Models (p. 22)
- Appendix C: Sample PCI DSS Responsibility Management Matrix (p. 51)
- Appendix E: Technical Security Considerations (All)
- 7 0 Containers (p. 65)
Utilizing Your QSA
If you are unfamiliar with the PCI DSS or unfamiliar with how to apply the standard to the cloud, you are not alone, and you should not have to figure this out on your own. Should your organization need to be PCI compliant, a key partner in your compliance journey will be your Qualified Security Assessor (QSA). QSA firms are external assessors, such as risk3sixty, trained and authorized by the PCI SSC to conduct PCI assessments for certification purposes.
Your QSA is constantly assessing different environments against the PCI DSS and should be able to help you think about how to apply the standards to your unique environment. They will be able to discuss best practices, how they have seen other companies approach difficult situations, and whether the use of compensating controls may be appropriate when PCI DSS requirements cannot be met, as written.
Alternatively, if your QSA is not familiar with the PCI SSC’s cloud guidelines and your technology stack, you may need to work with your QSA and educate them. In any event, ideally, you should be able to work collaboratively with your QSA to appropriately assess your environment and find answers to the difficult questions.
Use of Compensating Controls
The PCI SSC makes a provision available for when companies cannot meet a PCI DSS requirement, whether that is due to technical, legal, or business constraints. This provision introduces what are known as ‘compensating controls’.
Compensating controls must meet the following criteria and are a way for companies to address the risk around a specific PCI DSS requirement while doing so in a way that makes sense for the business (reference PCI DSS Appendix B).
Compensating controls must
- Meet the intent and rigor of the original PCI DSS requirement
- Provide a similar level of defense as the original PCI DSS requirement, such that the compensating control sufficiently offsets the risk that the original PCI DSS requirement was designed to defend against
- Be ‘above and beyond’ other PCI DSS requirements (e.g., being in compliance with other PCI DSS requirements is not a compensating control)
- Be commensurate with the additional risk imposed by not adhering to the PCI DSS requirement
Applied properly, compensating controls are a great way to be compliant with the PCI DSS while taking into account the reality of technology and business constraints. For example, implementing anti-virus on containerized infrastructure can be challenging and result in performance (and cost) issues.
As long as a compensating control is designed to address this requirement while satisfying the above criteria, a company may choose to not install anti-virus on containerized infrastructure and still be PCI DSS compliant.
Maintaining Compliance in the Cloud
Once your organization has achieved PCI compliance for your cloud-based CDE, congrats! That is not an insignificant undertaking. Now, about maintaining that compliance over time…
There is a body of recurring PCI DSS requirements that require periodic action to be taken, e.g., daily log reviews, quarterly ASV scans, etc.
Here are a few best practices for maintaining compliance as well as a link to another blog post addressing the recurring PCI DSS requirements:
- Assign PCI DSS requirements to respective stakeholders within your organization.
- Conduct quarterly PCI DSS assessments to ensure that all security controls are operating effectively and no PCI DSS requirements are falling through the cracks.
- Create calendar reminders for all the recurring PCI DSS requirements to help remind persons responsible and ‘leave no doubt’ that your program is operating effectively.
- Consider leveraging a GRC tool, such as Phalanx GRC, to reduce the audit burden and manage your ongoing compliance more effectively.
Conclusion
Implementing PCI compliance in the cloud can be challenging. While the PCI SSC endeavors to evolve the PCI DSS with the changing technology landscape, the reality is that technology moves much faster than compliance and security standards.
Finding right-sized solutions to meet compliance obligations requires understanding, collaboration, and appropriately applying standards to the modern tech stack, all while not unduly burdening the business.
Risk3sixty’s PCI Practice is focused on helping high-growth technology companies build, manage, and certify their PCI Compliance programs. If your organization is looking for a knowledgeable and collaborative PCI QSA partner, we would love the opportunity to work with you!
Leave A Comment