PCI Compliance in Public Cloud: Practical Considerations and Challenges

The Payment Card Industry (PCI) Data Security Standard (DSS) defines a set of guidelines for securing credit card data in order to minimize theft, fraud, and misuse. Any cloud application that accepts, transmits, or stores cardholder data must comply with the PCI DSS. It is known to be very time consuming and exhaustive in preparing for first time implementation as well as for maintaining ongoing compliance. It can take on an average of 3 to 6 months to build out the infrastructure. In terms of staffing, for a modest size infrastructure of 50 VMs, we see about one devops, one secops and one infosec engineer each, working full time.

But why is this so hard and time consuming? In this blog we break down the process and highlight some of the key challenges of having PCI DSS compliant controls in place.

Let’s start with the detailed guidance provided by AWS on implementing each of the controls: https://aws.amazon.com/quickstart/architecture/compliance-pci/ and https://fwd.aws/AxW3r There is a control matrix of 76 applicable controls that are required. We will use this as the basis of the time and effort estimates and discuss other factors that impact the process. There are 5 key challenges that we focus on in this blog:

Challenge 1: Infrastructure-as-code is not a Remedy

Table 1 shows a snippet of the PCI controls with a sample implementation using Infrastructure-as-code technique. If we complete this costing exercise for each of the 74 applicable PCI control then we could say that

If each control were to take on an average 2 days to implement and test, then for 74 operational controls for any infrastructure with 50 virtual machines and a single payment card application typically takes about 148 days or about 6 months. And, even after this automation, one has to keep the system updated with ongoing code changes based on evolving application needs common in fast growing SAAS companies.

The bigger the size of infrastructure, the more elaborate the needed controls become resulting in larger implementations & code bases. As the size of the code base grows, it becomes harder to make new changes because one has to understand more existing code, test for regression and code review cycles become longer. The size of the devops team will grow, further increasing operational expenditure. Moreover, different devops engineers have preference for their own favorite language. So whenever there is churn in any organization, the new team may choose to use their own favorite tool or language leading to a dreadful mix of code floating around. Eventually it becomes a burden and slows down the development process instead of making it faster.

Challenge 2: Compliance is an afterthought

The guidelines are strict and many ignored at the devops layer. “Production access should be strictly controlled, time bound and only need-basis” is easier said than done. Many changes are dependent on the initial setup and require reprovisioning of resources like the separation of VPCs between production and staging, moving unencrypted databases etc. Technologies like Kubernetes recommend wide open ports across all nodes in the cluster. Below is an official security group recommendation from AWS.

This one recommendation will blacklist EKS from an Infosec perspective. Imagine how DevOps will take that? Now we get into complexities of separating worker nodes into separate security groups that w/o complex automation will break KubeDNS, Ingress controllers and Service-to-service communications.

Challenge 3: Lack of cross disciple Expertise across Devops and Infosec

Devops team and cloud developers lack the skill set or the will to understand the nuances of the policies formulated by the infosec and similarly infosec lacks the will and skill to understand the nuances of the devops configurations and their practical considerations.

Infosec who cover the devops tracks by not requiring them to change any configuration or operational procedure by adding “Acceptable risk” notes in the organization’s infosec policy are best friends to the devops team.

Challenge 4: Need to Unlearn Legacy Enterprise Security Architecture

Challenge 5: Standards are a favorite Punching Bag

Conclusion

So the real question is: Can we have a different approach where machines can convert human intent and high level declarative specification in terms of product architecture, scale, security, compliance and auto-generate all the code, resources needed for a fully compliant cloud infrastructure?

Can we go from Infrastructure as code to No-code based automation?

After all, inside AWS and Azure, a few hundred people run over 20 Million workloads across the globe with 99.99% availability, infinite scale and compliant to all regulatory standards. If you are interested in such a new approach to simplify your life and which can implement every single applicable compliance control out-of-box to produce a PCI DSS compliant infrastructure in less than a week then contact us @ info@duplocloud.com or visit www.duplocloud.com for more information.

Digital Worker for Cloud Ops