Planning PCI in the Cloud

Planning PCI in the Cloud

What PCI Compliance for Cloud Data Looks Like: Challenges and Maintenance

Moving to the Cloud is not as simple as “Just put it in the Cloud and we won’t have to do PCI.” The Cloud can reduce PCI Scope but it can also add to the complexity of maintaining PCI compliance. As we will discuss, the Cloud has benefits, but PCI compliance can be more complicated in the Cloud.

The Truth About PCI Compliance Following Cloud Migration

The biggest Cloud migration mistake we are seeing, as QSAs, is that organizations sometimes spend years migrating to the Cloud under the false premise that almost all PCI requirements will be eliminated. Finally, at the end of their long development cycle, they get hit with a PCI DSS assessment and are stunned because of the many PCI controls they failed to consider.

Consequently, the Cloud migration project is late. Management puts pressure on the teams, customers end up waiting, and suddenly tons of PCI requirements block their release. Questions arise as to why the team missed these PCI controls, and it can be a very stressful realization that PCI compliance does not go away simply because functionality was moved into the Cloud.

Being able to answer a PCI Report on Compliance (RoC) with “N/A” for everything (or almost everything), and thus finally releasing you and your company of the burden of protecting payment card data, is attractive, of course. It is such an attractive scenario that many businesses are falling into the trap of “wishful thinking” that the Cloud makes their responsibilities disappear. They adopt an “out of sight, out of mind” view.

However, it’s important to understand what is specified within PCI Scope. It entails everything that can “adversely affect the security of cardholder data” – it’s not just the handling of the data itself. It encompasses all processes, technology, and people that affect the data security.

So don’t fall into the trap of thinking that just because the Cloud handles the data, the implementation is out of scope. Regardless of the new environment’s design, the Cloud does not automatically eliminate PCI compliance. The Cloud can reduce PCI efforts, but what is often mis-understood is the extent to which it reduces PCI Scope. You still need to apply every PCI control to your Cloud solution in addition to what you do yourselves.

What Does PCI Compliance in the Cloud Look Like?

In the Cloud, PCI controls may be simpler to address, but in one way or another, your organization is still the responsible party because you are accepting cardholder data on behalf of your customers. PCI might be simpler, but the number of controls usually does not decrease very much.

Take for example, an e-commerce site in the Cloud, coupled with call agents located in a call center that handles credit cards. The agents may use a thin client to access servers located in the Cloud, and enter card data into the Cloud site.

• The physical security of the center where recordings of the calls are located are part of PCI Scope.
• The desktops must be secured.
• The processes the agents follow must be secure.

Below are some examples of Cloud-based functionality that an enterprise is ultimately responsible for:

• Systems – the final configuring and hardening of systems both on your site and in the Cloud
• Applications – frameworks and the code you load into the Cloud
• Networking – what protocols are allowed – ingress and egress rules that you have implemented
• Access – defining roles and rights for administrators who implement “production” in the Cloud
• Development – all the code release steps and due diligence in Development before the code is installed in the Cloud.
• Human Resources – hiring trustworthy staff and tracking their access to the Cloud
• Encryption – securing card data in your code installed in the Cloud
• Transmission – ensuring that public channels are secure
• Monitoring – log monitoring, IDS/IPS…. With 24/7 staff available to react to alerts
• Scanning – of public facing applications and even possibly internal configurations and internal scanning of what you have configured and loaded into the Cloud
• File Integrity – The Cloud ensures that systems are stable, but the assessed organization is still responsible for their code, libraries, and frameworks that they loaded into the Cloud
• Incident Response and Risk Analysis – defining risks and what to do when an incident occurs

Note – The PCI Council has a 50-page paper that outlines the responsibilities for differing types of Cloud services. This paper is focused on the most common type – an enterprise service that has been loaded into a third party Cloud.

Let’s take an increasingly common example to demonstrate how an enterprise is responsible; an e-commerce application running in Kubernetes in a Docker Container in the Cloud.

The application is in Java and uses Apache with Tomcat, Apache Struts, JBOSS EJBs, MySQL and JAX RPC with some RMI. The Container image is loaded into a Cloud provider’s Kubernetes Cluster, which contains the Nodes that contain Pods – the Pods contain the instances of the Container; all managed by the Kubernetes Master.

It sounds complicated, so it must be secure, right? No. It could be full of attack vectors (vulnerabilities) that the Cloud provider has no control over. There is even a book named Hacking Kubernetes. The sales material states, “Kubernetes’ complexity offers malicious in-house users and external attackers alike a large assortment of attack vectors.” For example, Metasploit (a hacking tool) can be used to compromise vulnerable versions of Struts and then can run a “shell” in the example Container.

Cloud Security Areas to Consider

External Attacks:

1. Is the code written so as not to expose any of the OWASP Top Ten attacks?
2. Is the version of Java secure? How is it updated? We ask the same questions for Apache, Tomcat, and Struts, all of which are libraries and frameworks that you loaded into the Container.
3. How do you control inbound/outbound traffic to the application?
   • What firewall are you using?
   • How are the rules set and reviewed on a periodic basis?
   • How is the localhost RMI traffic (communications) controlled?
4. How is the integrity of the Container code checked?
5. If a hacker invokes a “shell” are you going to catch it?

Internal Attacks:

1. Is there a controlled process with checks to ensure that only reviewed and QA’d code is uploaded into the Cloud?
2. How is a rogue employee prevented from uploading code on their own?

Because of all the attack vectors listed above, you will have to employ solutions for all of them.

Affected Control Areas Addressed by PCI

• Logging – Centralized logging with monitoring and analysis of the logging. The application will have to log key events.
• Scanning for Vulnerabilities – the Apache, Tomcat, Struts, MySQL, libraries and frameworks that you loaded into the Container are your responsibility. The Cloud provider has no idea as to how your application works.
• ASV Scans – You must have quarterly certified external scans of the e-commerce site.
• Penetration Test – a test of the networking and application both externally and from within your organization.
• Firewalls – Rules sets to limit traffic both external and internally to the application.
• Access Controls – Multi-factor Access for users with designated rights and roles with monitoring of their activities.

The Cloud provider only covers internal Cloud attacks (from a rogue Cloud employee). But that situation brings up a salient point: what are you going to do if the Cloud provider’s security fails? You cannot just say, “Oh it is our Cloud provider’s fault. Go complain to them.” You will be responsible. Do you have security measures in place and a recovery plan for the case of the Cloud provider being compromised? This scenario is happening more and more often these days.

Additionally, once you have the Cloud covered, you will still have to maintain compliance for your own corporate environment. For example, even physical PCI Requirements are in scope, because although the Cloud provider is responsible for the Cloud data center’s physical environment, you are still responsible for corporate hosts used by your staff and developers such as laptops and servers. That makes you responsible for the physical security of your servers and company laptops.

Ensuring You Are Taking Proper Responsibility Over Your Cloud PCI Compliance

In many cases the Cloud can make PCI compliance even more difficult because dividing up PCI control responsibilities requires a complete understanding of which party is doing what. You must cover everything the Cloud does not do, and cover your own organization in addition. The Cloud may cover many PCI Requirements for you, but you are responsible for properly delineating which controls or portions of controls are covered by your Cloud provider and which you are responsible for.  This process of absolutely understanding who is doing what can be very tedious and time consuming – and can make it more difficult to maintain PCI compliance in the Cloud compared to just doing everything yourself, as has been done for decades.

The Cloud provider must state in writing what they cover, and then you must cover the rest. Just because you think the Cloud provider covers something, or they should, is not good enough. You need a document, often called a “PCI Compliance Matrix”. Without that documentation, you are just guessing, which can make PCI impossible to nail down and become a legal nightmare for you if you do not have documented coverage.

The “PCI Compliance Matrix” document should describe in detail, control by control, every service you have purchased and how these services do and do not meet every PCI requirement. However, the first issue you will run into are the many controls that will be labeled “Shared”; meaning the Cloud covers some of it and you must do the rest. What that delineation is may not be clearly defined. The Cloud provider simply states, “Shared”.

For those controls, you need to be able to justify the compliance steps you are taking to claim responsibility where needed, and essentially build a case for your organization.

You should document any “Shared” controls with these steps:

1. Define the responsibilities of the duties for the “Shared” control.
2. Explain how the control is completely covered by the sum of efforts by both parties.
3. Document your coverage in detail for the control and all actions you take regarding that coverage.

In Conclusion

Much like a real cloud that has many shapes and a complicated outline that you can’t grasp, the IT Cloud can be obscure. Still, you must ensure there is complete coverage for PCI because your organization is responsible for your clients’ cardholder data.

Regardless of the benefits of the Cloud, you are ultimately responsible for all of PCI DSS. Therefore, you are responsible for performing the necessary due diligence for all the PCI requirements. You must ensure that all the Cloud’s contributions to your PCI compliance are complemented and completed by your efforts.

As we have shown, the Cloud may reduce your PCI compliance workload, but it requires that you fully understand all the aspects of PCI compliance being performed, often with more detail and difficulty than non-Cloud conventional solutions. So don’t say, “Just put it in the Cloud and we won’t have to do PCI.”

   By: John Elliott   01.05.22