PCI Compliance for Containers and Kubernetes

In this blog, we will cover the various requirements you need to meet to achieve PCI compliance, as well as how Sysdig Secure can help you continuously validate PCI compliance for containers and Kubernetes. Learn how to meet PCI Compliance Requirements for Container and Kubernetes Environments! Click to tweet

What is PCI DSS Compliance?

Hackers are getting better at stealing credit card data, costing companies up to billions of dollars in fines every year. To prevent these types of attacks, the Payment Card Industry (PCI) security standard was created, along with a set of requirements to meet in order to mitigate risk. Many of your applications are now starting to run on containers in the cloud, where there are many more attack vectors. So how can you validate container compliance for your cloud applications?

Why is PCI compliance different in containers and Kubernetes?

As applications migrate to the cloud, there are three key attributes of containerized environments that make PCI container compliance challenging:

Container sprawl
Container lifespan
Open-source packaging

Container sprawl: When virtualization took off, there was a concept of Virtual Machine (VM) sprawl that came about as a result of increased density of VMs. As more applications get containerized, the concept of container sprawl is essentially VM sprawl on steroids. Now your microservice is distributed across thousands of nodes, supported by maybe millions of containers. Containers spin up and down and IP addresses are constantly changing, making any form of PCI audit extremely difficult. Container lifespan: Sysdig’s 2019 container usage report found that 52% of containers live for five minutes or less, while six percent of containers live longer than a week. Meeting requirements of PCI-DSS can be complex in fast-changing container environments where some containers last a long time, while others are quick to come and go. In addition, with 39% of containers living for a minute or less, you must establish a way to record detailed container activity as proof of compliance after the container has disappeared. In the event of a compliance violation, you’ll want to know what processes were spawned, what connections were made, files modified etc. You also need to be able to correlate this system activity with user activity and understand who accessed what. With access to this granular data, you can effectively provide an audit trail to 3rd party assessors. Open-source packaging: Software today is assembled, not built from scratch. Today, the fastest way to drive innovation, speed, and lower cost is by adopting open source. Your developers will pull open-source base images and leverage third-party libraries to build and scale containerized applications. However, using open source also requires that companies remain as diligent about updating their open source dependencies as they would be about updating their own code. If there is a vulnerability that is inherited from the base image or libraries like Java JAR, Python PIP, etc., then the risk belongs to the organization. And when you have hundreds of thousands of containers that support thousands of microservices, how can you prevent vulnerabilities from entering production. Preventing known vulnerabilities and flagging newly identified vulnerabilities not only reduces risk, it is a step in passing PCI audits. In addition, misconfigurations in your dockerfile such as exposed ports, embedded access keys or tokens can easily lead to compliance violations. According to Gartner, through 2023 at least 99% of cloud security failures will be the customer’s fault.

Traditional compliance tools don’t work

Managing the process with traditional tools does not work for containers and Kubernetes; they can’t see inside containers or assess their behavior. Most container traffic is east-west in nature – versus north-south – meaning traditional security controls never see most container activity. They also don’t have relevant context about the cloud and Kubernetes environment, which means they can’t tie vulnerabilities back to applications and namespaces. Finally, these legacy tools are not built for DevOps, and are designed to be applied post application deployment.

PCI compliance cost implications and consequences

Validating compliance is the number one blocker for faster application delivery. Regulators are increasingly enforcing financial penalties for failure to comply. Studies have shown that:

Annual cost of non-compliance to businesses runs an average of $14.8 million*
The cost of compliance, on the other hand, was found to average $5.5 million*

Kubernetes is a dynamic environment in which it’s difficult to detect when assets fall out of PCI compliance. Without a clear mapping of PCI guidelines to this new environment, your teams won’t be able to prove they meet compliance requirements. As a result, meeting a PCI audit becomes an expensive fire drill, slowing down application delivery for your cloud teams. Kubernetes compliance requires a new approach. Your teams need to have a clear mapping of controls to their containerized workloads and the ability to continuously track compliance over time. This will let them be confident in their ability to manage security risk and pass security audits. Ultimately, you need to ensure compliance is not blocking cloud adoption, so your business can ship cloud applications faster. *Ponemon study

Sysdig Secure helps you validate PCI compliance

Sysdig Secure helps you validate PCI compliance across all stages of the container and Kubernetes lifecycle, ensuring that compliance is not a blocker for cloud adoption. A few examples of how we address PCI:

Out of the box policies – PCI 1.1.6 and 6.1 Requirements

Sysdig provides default PCI scanning policies and also customize policies based on the scope that is relevant to your PCI controls. These policies provide a single workflow for detecting vulnerabilities and misconfigurations in registries, containers, and Kubernetes

Kubernetes Network Topology Maps – PCI 1.1.2 Requirement

Sysdig will dynamically generate topology maps of all hosts, containers, and processes on your infrastructure and map any network connection they make inside and outside your network. These topology maps can also be customized to show the logical services and how they’re connected as well.

Asset Inventory Management – PCI 2.4 Requirement

Sysdig comes with an explore view that will give you a view of all hosts, containers, or any process grouped by metadata running on their system. They can use this table to slice and dice all system components however they choose.

Access control of cardholder data – PCI 7.1 Requirement

Sysdig analyzes the requirements of the Pod spec in your Deployment definition and creates the least privilege PSP for your application. This controls if you allow privileged pods, users to run as the container, volumes, etc

Kubernetes Audit Trail – PCI 10.1, 10.2 Requirement

Sysdig provides a continuous audit of all container infrastructure events to facilitate incident response and PCI-DSS compliance. Use this as proof of compliance for your 3rd party auditors even after the container is gone. To dig deeper into how Sysdig Secure can map and address many more PCI controls, check out some of these resources below:

Download our Guide to PCI compliance for containers and Kubernetes
Attend our webinar: PCI compliance for containers and Kubernetes.
Sign up for Sysdig Secure free trial!