How to Make PCI DSS Compliance Cloud Native

Frameworks and standards like PCI DSS have been a part of the regulation and compliance industry well before any of us overheard terms like “the cloud” or “containers” at our local coffee shop.  And although you will not currently find specific detail regarding cloud-native technologies like containers in the PCI DSS standard, that does not mean your organization can expect any latitude on PCI Compliance just because it is running a containerized environment.

"The cloud migration services market is expected to reach USD 448.34 billion by 2025, at a CAGR of 28.89% over the forecast period 2020 - 2025."

- Cloud Migration Market Report, 2020

"By 2022, more than 75% of global organizations will be running containerized applications in production, up from less than 30% today."

- “Forecast Analysis: Container Management (Software and Services), Worldwide”, Gartner

Cloud-native technologies remain key drivers of the continued surge of this digital transformation age we have become so accustomed to.  But they are not only popular with businesses.  They also have the attention of bad actors.  As detailed in Verizon’s Data Breach Investigation Report (May 2020), 24% of the breaches thus far were around cloud-based assets.  As organizations move ahead on their digital transformation journey, inherently, they find themselves with the challenge of also transforming their information security program.  Such a security transformation also requires a transformation of how your organization approaches compliance.

Before we go any further, what exactly is a container?  Containerization is an increasingly popular technology for running many instances of a server or application.  It has resource, security, and isolation properties similar to those of virtual machines, but not the memory and performance overhead inherent in system-level hypervisors.  Containers are designed to be deployed as very lightweight, short-lived groups of systems.  This provides speed and scalability by increasing the quantity of containers in the group dynamically.  Because of this, controls should focus on the image templates and group as an aggregate, not the individual containers within the group.

Security Properties

Containers have unique security properties.

• Declarative
  Contents and all its dependences are explicitly laid out at build time.

• Inspectable
  Contents can be statically checked without having to run the container.

• Immutable
  Containers cannot be modified once created: no updates, no patches, no configuration changes.  If you must update the application code or apply a patch, you build a new image and redeploy it.

The Model

With containers and other cloud-native technologies, we get a new security model.

• Build from trusted sources
  Ensure your container images are built from up-to-date minimal base images, from trusted sources.

• Implement streamlined security checkpoints
  Utilize streamlined security checkpoints.  For example, implement tests and scans as part of your CI/CD (continuous integration/continuous delivery) pipeline.

• Shift Left for declarative compliance
  Maintain a policy-driven release practice by codifying your security requirements as early as possible.  Then, be sure controls are in place so that only images that have gone through the necessary validations are admitted.

Shifting left simplifies compliance.  By decoupling compliance controls from business logic with a cloud-native architecture, it allows your environment to adapt to evolving compliance requirements.

Detecting and remediating defects in the design phase will also result in faster time to market, and cost savings since you will not have to go back and rebuild once you are already hit the implementation or testing phase.  Simply put, you can shift left and declare your compliance outcome as a code.  Just be sure you make your QSA or auditor aware at audit time.

The challenges of demonstrating compliance will raise anxiety levels when the “audit bell” rings.  When you hear that bell, remember these two key aspects of a PCI DSS assessment:

• Scope your PCI audit accurately

• Evidence controls

Scoping is an easy task in a monolith application, with one application server and a backend server running in a single data center.  But with container-based architecture, containers are often running in different clouds.  Trying to draw a boundary can feel like sweeping sand off the beach.  Additionally, different containers in different clouds, illustrating shared responsibilities between you and your cloud providers can induce a headache!

Kubernetes

For the purposes of explanation, we will use the Kubernetes architecture as the basis of a cloud-native ecosystem for this discussion.  That said, before we continue with how to demonstrate PCI DSS compliance, let’s quickly break down a few basic concepts.

• Pod
Think of a pod as a container for your containers.  A pod is essentially a logical wrapper for a container to execute.

• Node
Nodes, or worker nodes, are the virtual or physical machines in which pods run.

• Cluster
Clusters consist of a set of nodes, that run your containerized applications.  Every cluster has at least one node.

Another important concept to keep in your kit bag is the use of namespaces.  A namespace is a virtual cluster backed by the same physical cluster, that serves as a logical border enabling you to divide cluster resources between multiple teams or projects.  Simply put, namespaces are a key enabler for isolation in your cloud-native environment.  We will revisit the idea of namespaces a little bit later.

Common Compliance Requirements

The first step in your quest to demonstrate PCI DSS compliance requirements is to ask yourself the following questions:

• Segmentation and Networking
  How do we isolate workloads with different risk profiles? Which parts of our environment do we need to make compliant?

• Identity and Access Management
  Have we implemented the right access controls?

• Data Security and Encryption
  Can we attest that our payment card data is properly secured?

• Continuous Monitoring
  How do we detect common vulnerabilities in applications?

• Secure Supply Chain
  Are we deploying up-to-date, trusted workloads?

• The Human Factor
  Who are the stakeholders?

In the sections below, we will cover each of these common requirements.

Segmentation and Access Management

While the PCI DSS clearing states that segmenting your cardholder data environment from the rest of your network is NOT a requirement, it strongly recommends segmentation with the caveat that the flatter your network, the bigger the portion of it will be in scope for a PCI DSS assessment.

With respect to containers, there are two main types of segmentation.

Macro-segmentation includes actions you can take outside of the cluster.  For example:

• User segmentation (Identity and Access Management)
  Enforcing access on a “need to know” or “least privilege” basis.

• Network segmentation
  Limiting access from trusted or private networks only.

• Application segmentation
  Isolating your “in-scope” and “out-of-scope” applications.

Micro-segmentation is the segmentation you build within the cluster. This includes:

• Cluster segmentation
  Limiting your “in-scope” pods, and ensuring they are appropriately isolated.

The key takeaway is that cloud-native technologies like containers give you the flexibility to build layers of segmentation that best suit your business needs.

Cluster Segmentation

In a cluster, every pod gets its own IP address, scoped to the cluster.  Pods can reach each other, even across nodes. To achieve segmentation at the cluster level, you can restrict PCI pod traffic to and from non-PCI traffic by employing network policies to allow or deny traffic based on IP rules.

Namespaces

We are not done with our segmentation mission just yet.  Demonstrating the separation of development environments from production environments still has to be addressed.

Namespaces are API objects which partition a single cluster into multiple virtual clusters.  They can be created as needed, per user, per application, per department, etc.  They provide each user community with its own policies, with delegated management, and resources with consumption limits.

You can use namespaces wherever you need to segment certain application profiles where one application contains PCI data, and another does not.

What if You Need Stronger Isolation?

A service mesh is a dedicated infrastructure layer that simplifies the process of connecting, protecting, and monitoring your microservices. If stronger isolation is something you talk about in your weekly meetings, service mesh can fulfill the need for stronger segmentation of users, networks, and applications.

Service mesh can also provide you with the following benefits:

• Assist with the implementation of a strong Zero Trust Network.

• Enable the use of mTLS (mutual TLS) to encrypt service to service calls.  With mTLS, the client and server each verify each other’s identities before proceeding on to the HTTP exchange.

Whether you employ tools like service mesh or not, always consider the fundamentals. The cleanest and easiest way to achieve segmentation is to completely separate Kubernetes clusters that house payment card data, from clusters that house non-payment card data.