DEVOPSdigest

The technical controls associated with the Payment Card Industry (PCI) standard are the most prescriptive and comprehensive relative to other standards like SOC 2 and HIPAA. Implementing them is a time-consuming and exhaustive process, but necessary given that cloud applications must be PCI DSS compliant in order to accept, transmit, or store cardholder data while avoiding theft, fraud, and misuse. Even with today's automation tools and scripting languages, implementing a highly secure and compliant cloud infrastructure within PCI applications is far from a solved problem.

In fact, building out a modest-size infrastructure of 50 VMs can take one DevOps, one SecOps, and one InfoSec engineer working full-time at least 3-6 months, and require their continued support for ongoing compliance maintenance.

What makes this process so arduous?

Let's break down five key challenges I've seen with implementing PCI DSS compliant controls:

Challenge 1: Highly Fragmented Infrastructure with Microservices

Before the advent of microservices, applications were largely monolithic with very few moving pieces. It was fairly easy for security teams to come up with deployment topology and secure them. The topology also largely remained unchanged through the release cycles. All this changed with microservices be it in the form of Docker Containers or dozens of platform services provided by the cloud providers. There are now scores of touch points for security configurations all distributed in the cloud infrastructure.

There is also a high degree of volatility. From Kubernetes, Virtual Networks, application endpoints, WAF to host operating systems the sheer number of systems to be secured is overwhelming and requires many disparate tools that need to be stitched together in complex workflows by a human being, which is both error prone and laborious.

Challenge 2: DevSecOps is a very difficult skill

DevOps is the discipline which is responsible for deploying, securing and maintaining applications in the cloud. An overwhelming majority of PCI controls fall in the purview of the DevOps team. This is a skill that demands a single individual be proficient in operations and security, as well as programming (i.e. Infrastructure-as-Code). But these have traditionally been three independent job profiles. Developers are not operators. Operators' programming skills are limited to basic scripting and most operators don't have a good grasp of compliance standards.

Challenge 3: Infrastructure-as-code is not a sure fire Solution

While IAC has become a new trend in terms of automating and maintaining Infrastructure state, it is at the end of the day a scripting language. It does not tell the user what configurations to apply, the onus on writing IAC is still on the user. While there are ready made libraries or modules for some standard functions, an engineer without a sound operations background cannot build and operate IAC.

As an organization's infrastructure needs grow, it becomes more complicated to guarantee that all the created infrastructure is secure, compliant, and in line with today's best practices. Given the increasing diversity of tools and configurations, it gets harder to write, test, and review, and roll out code. In fact, the 2020 Cloud Threat Report(link is external) released by Palo Alto Networks identifies around 200,000 potential vulnerabilities in existing Infrastructure-as-Code templates.

Challenge 4: Compliance comes in the way of Developer Self-service

Today most automation workflows in a highly regulated industry cut developer access from infrastructure. PCI controls like those in sections 7 and 8 in the PCI DSS standard explicitly mandate a Just-in-time need basis access control implementation. Implementing this in a highly distributed microservices based cloud infrastructure is a herculean task. Imagine the complexity of AWS IAM policies to achieve this on a per user per login basis for dozens of services and environments.

The end result is either developers have no access or they have too much access in violation of compliance. Due to this reason many organizations approach PCI compliance after a substantial part of the product has been built, which has its own set of challenges.

Challenge 5: Compliance is an afterthought

The level of automation that is required to maintain an agile development of product in the cloud while also adhering to compliance standards like PCI, is beyond the reach of most organizations. This is especially true in the case of fast-growing companies with limited resources. Product development and go-to-market strategies tend to be top priorities, so the foundation for the infrastructure provisioning and automation architecture at the DevOps layer is often in place before compliance requirements are even considered.

But 70% of PCI controls are actually provisioning time controls and changing them requires a substantial amount of rework. Thus adding PCI compliance to an existing infrastructure becomes a 6-12 month process. This is especially true with a detailed and prescriptive standard like PCI versus the more abstract ones like SOC 2 and HIPAA.

Luckily, companies realize these challenges exist and are working rapidly to solve them through things like no-code/low-code automation and compliance. These new solutions claim to deliver DevSecOps-as-a-Service where security and compliance are baked into the system while engineers focus on building their product and are not required to be a compliance or DevOps gurus. These new solutions will greatly ease the lives of Developers and DevOps teams allowing them to get past the compliance hurdle in order to focus on what they're good at — building tomorrow's next great applications.