PCI Compliance in the Age of Cloud Native Tech
The Payment Card Industry Data Security Standard (PCI DSS) entered the scene back in 2004 with the rise of payment fraud. Created by leaders in the credit card industry, PCI DSS was developed to provide a baseline of technical and operational requirements designed to protect cardholder payment data and was commonly understood by those in the legacy security world.
All entities involved in payment card processing — including merchants, processors, acquirers, issuers, service providers, as well as other organizations that stored, processed or transmitted cardholder and sensitive data — were required to abide by these regulations.
In 2006, the PCI Security Standards Council (SSC) was formed to regularly update the standards to reflect current best practices. Over the years, PCI DSS has been through myriad versions, each sharpening functional testing procedures to help organizations implement proper policies for handling sensitive data.
Today, PCI DSS is composed of 12 high-level requirements, but even with these regulations in place, how do you ensure PCI compliance in the age of cloud native tech?
Implement PCI in a cloud native environment
PCI DSS requirements are now almost 20 years old, and we’ve come a long way from controlling access through identity and access management (IAM), implementing the policy in your privileged identity management (PIM) tool and hoping for the best.
However, the shift to cloud native has completely changed the way organizations do business and has redefined network and storage parameters. Although you will be hard-pressed to find specific detail regarding cloud native tech in the PCI DSS standard, that doesn’t mean your company can expect any leeway on PCI compliance because it is running a containerized environment.
In a microservice-based environment, the control points are new and highly diverse as applications live in the cloud and/or hybrid environments and are delivered in various capacities, making them more accessible to the end-user.
Complicating things further, there are often myriad redundant options for controlling storage, network and compute resources, such as API gateway, service proxy/mesh, namespace, L7, microsegmentation, cloud SDN and others. Thus, meeting PCI compliance can post a hefty challenge.
Moving to a compliant state in cloud native environments requires a new and highly time-consuming step: identifying where policies will be most effective and how they map to existing regulations. It also entails a new security model, which includes the following:
Build from trusted sources — Make certain your container images are built from current minimal base images from trusted sources.
Apply streamlined security checkpoints — Use streamlined security checkpoints.
Shift left for declarative compliance — Retain a policy-driven release practice by codifying your security requirements as early in the process as possible. Ensure controls are in place so that all admitted images have gone through necessary validations.
If dealing with legacy parameters, you can likely skip this since the work has already been done; this would be the opportune time to audit best practices.
For those not running legacy systems, the easiest place to begin is Kubernetes (K8s). Kubernetes allows control over storage, network and compute resources but still requires that you map relevant control to the PCI standard itself.
Example:
Requirement 7.1.2: Restrict access to privileged user IDs to the least privileges necessary to perform job responsibilities.
However, in cloud native, authentication along with IAM doesn’t always work because of containers’ dynamic nature. Solutions must be active in real-time and be able to automatically respond to rapidly transforming attacks. What is the answer? Kubernetes admission control.
Along with making sure users and service accounts adhere to the principle of least privilege, containers should too. A best practice when running a container is to run the process with a non-root user. Pod Security Policy (PSP) was an admission controller/cluster-level resource that controlled requests to create and update pods on your cluster. It also defined a set of conditions that pods must meet to be accepted by the cluster in addition to defaults for the related fields.
Previously, when a request to create or update a pod did not meet the conditions in the Pod Security Policy, that request was promptly rejected and an error was returned to the user. Since the depreciation of PSPs, Styra has implemented policy packs that serve to replace PSPs.
As you can see, rapid development means that addressing the requirements in a cloud native environment is not an easy task, but you can implement PCI with the right steps:
Understand how legacy systems are handling cardholder data and map that to cloud native architecture if you are at the beginning of your digital transformation. This process ensures that when moving applications, the proper frameworks can be put in place, whether that be policy to control orchestration, service-to-service communication or gateways.
Use open source solutions, in the beginning, to see where there are gaps and understand the manual effort it takes to manage these solutions and prove compliance (internal or external). Solutions like Open Policy Agent (OPA) can be used to manually create policies that map to PCI. Or, depending on where you are in your journey, there are turnkey control planes with prebuilt PCI policy packs that have already been mapped.
Look for solutions that will not only enable your team, but the teams that are also responsible for any compliance pieces. For some organizations, it is legal, security, IT and GRC teams, and sometimes it is just IT. But be cognizant that as your organization grows, the solutions need to be able to adapt.
While implementing PCI policy is essential, proving the policy works is more important. Having confidence that the policy will properly handle cardholder data allows policy-as-code to be attainable for security, IT and GRC teams, as well as proof for auditors.
When it comes to PCI, determining compliance for the use of cloud native technologies is challenging for both auditors and users, especially since the requirements are not specific to containers. However, with detailed documentation, clean automation and the right solutions in place, PCI compliance can be achieved.
For a deeper look into how Styra can assist with your PCI compliance, read the white paper, “How Styra Maps to PCI Data Security Standard v3.2.”
A version of this blog first appeared in The New Stack on January 11, 2022.