Cloud computing poses some unique challenges for building and maintaining secure systems. Whenever somebody says they’re using “the cloud”, what they’re really saying is that they’re using “someone else’s computer”. When you remember that the cloud is really just someone else’s computer, it drives home how difficult security can be.
In this new model, nobody is responsible for security of the entire system. Instead, this responsibility is split across the provider and their customer (you!). Amazon AWS have a helpful diagram that illustrates this split within their environment, but most cloud services are similar.
Many companies do overcome the challenges and achieve PCI DSS compliance with cloud computing. Business doing so range across the payments spectrum from issuer processors to merchants. The PCI SSC released guidelines on cloud computing for PCI DSS compliance some time back, which is a really positive step. Unfortunately they’ve not yet released a version of the standard itself that fully embraces the cloud.
Contents
Solid Foundations
For any project to succeed on time and on budget, it really helps to start off building on a solid foundation. What does that mean for PCI DSS in the cloud? Use a cloud provider who already has their own PCI DSS AOC.
When you deploy into the cloud, you don’t have any visibility into the physical security of that environment. If the cloud provider doesn’t have an AOC covering at least physical security, you will really struggle to be compliant. I’m sure someone will find a way to disprove this with a willing cloud provider, but it’s choosing to make your life much harder going that route.
AOC Limitations
But you also need to be aware of the limitations of depending on the AOC. Just because a provider is PCI DSS compliant does not automatically mean whatever you do in that environment is also compliant. You will still be certified in your own right, but you are able to hand off responsibility for certain aspects to the cloud provider. The areas where that hand off is possible are spelled out in the AOC.
Cloud Provider AOC
Any AOC you review will list which services and facilities are and are not in scope for the assessment which generated the AOC.
When dealing with cloud providers, the AOC can have page after page just for the facilities which are covered. Typically all provider facilities will be in scope for the assessment, unless they are clearly advertising regionally differentiated services. It makes sense for cloud providers to build all facilities with a common model. It means clients can depend on similar capacity and features in all regions, and really is a testament to the infrastructure engineering capabilities of these companies.
Cloud provider AOCs will also list which services are included in the scope of the assessment. This will generally be a list of brand name products, such as ‘AWS S3‘ or ‘AWS EC2‘. You are unlikely to find more detailed descriptions of any service configurations which were tested in the AOC itself.
When designing a PCI DSS-compliant environment for a cloud deployment, you must choose which cloud services you use very carefully! The list of services which are covered by the AOC are long, but they are not exhaustive. There are plenty of cloud services at well known providers which are not in scope for their annual PCI assessment – these would create issues if you were to use those services to store or process card holder data.
Early in your planning you should request AOCs from your candidate cloud providers, and review carefully for the in scope regions and services.
How does the QSA know which services, and even which aspects of those services, are the responsibility of the cloud provider or their customer? Service providers in the PCI DSS space publish what’s known as a Shared Responsibility Matrix. At a high level, this is a document mapping PCI DSS requirements to who is responsible for them.
An example such matrix from Twilio, a telecommunications service provider, is shown below:
Each entry in the Shared Responsibility Matrix is marked as one of the following:
- Service Provider Responsible
- Customer Responsible
- Shared
If you are making use of service providers, one of the first things a QSA will typically request is the Shared Responsibility Matrix for the provider. This allows the QSA to quickly understand what is already covered by an AOC, vs. what they need to assess themselves.
Service Provider Responsible
For those items marked ‘cloud provider only’, you can comfortably assume that the QSA will look to the cloud provider AOC to assess whether you’re compliant. Your QSA may still ask you questions around that issue, to understand whether everything in scope for that test is performed in the cloud.
The classic example here is physical security: where a cloud provider can impact your physical security, they are exclusively responsible for it. However, the QSA will still need to understand if your only in-scope physical security needs are for your cloud infrastructure. If you have a physical office which processes or stores CHD, it will be assessed separately to the cloud.
Customer Responsible
For those in the matrix which are client responsibility only, you will be subject to a process like a traditional assessment.
Joint
Items where responsibility is shared are where the real interest lies. This is also where most of the items in the matrix will typically be. The reason for this is simple: most services provided by a cloud provider require client configurations. Cloud providers maintain and regularly update their systems and infrastructure components as they want to maintain a secure environment for clients to build on. But their PCI responsibility stops at the point they hand a configuration interface to a customer.
Consider a cloud-based network load balancer. The cloud provider provisions the load balancer, but the client can have a choice of SSL policy based on their needs. Even at AWS, as of writing, the default load balancer SSL policy isn’t PCI compliant because it allows earlier protocol versions than TLS v1.2. So you need to look carefully at security-impacting defaults that you are accepting. Just because a configuration works does not mean it meets the requirements.
Likewise, cloud firewalls. Cloud providers all typically offer some kind of stateful inspection packet filtering, which meets the requirement for PCI DSS firewalls. However, the actual policy of which traffic is allowed through the firewall is defined by the client. It’s hardly the cloud provider’s fault if a client opens up the telnet port to the whole Internet!
Choose the right QSAC
Cloud computing has been around for a few years now, and most companies are looking to move at least some workloads to the cloud. Because of this trend it’s becoming more common to meet QSAs who have actually conducted assessments of cloud infrastructure. But not all QSAs have, so when you are looking to select a QSAC, be sure to understand the cloud awareness of the firm and ideally your account team too.
Also remember that each public cloud is its own private ecosystem. In networking, Cisco and Juniper produce devices with similar functionality, but very different ways of configuring them. Even for the basics such as IP routing, there can be major gaps between the two platforms: Cisco defined EIGRP and has all of the proprietary pieces available; not all competitors have this level of support.
Likewise, in the cloud you’ll find all providers give you access to storage, compute, and networking. On top of this they layer management and security components. Your individual QSA is going to have to do in-depth reviews of some of this configuration, and it helps if they’ve actually seen a cloud environment like yours before. Going in, knowing how the AWS IAM roles and the multi-account deployment model (a current AWS best practice) interact can avoid a lot of potential confusion in understanding your deployment model.
Make Good Choices
You can really streamline your implementation and certification by making good choices at the start:
- select cloud provider(s) who are already PCI compliant and can demonstrate this
- use only services which are included in the scope of the providers’ AOC
- work with QSAs who are familiar with the brave new world of enterprise cloud computing