What to Know about Container Security and Digital Payments
Managing containers in the world of digital payments just got a little easier. Now that containers are a preferred option for cloud native architectures, practitioners need guidance to support highly regulated industries, such as financial services and payments. While the PCI guidelines for virtual machines (VMs) are still in use and likely will be for many years, they’ve evolved to include container orchestration. Here’s what you need to know.
New guidance for containers and container orchestration was released by the Payment Card Industry (PCI) Security Standards Council last year. These guidelines are important for any business that processes credit card payments and wants to use containers at scale to support its business goals. The new guidance is part of the PCI Data Security Standards (DSS) 4.0 and is similar to that for VMs, but there are important differences. Any business or practitioner working with a company that takes credit card payments can now reference a set of best practices to help them meet the latest PCI DSS requirements when using containers and container orchestration tools.
I participated in working groups that helped update the PCI guidelines. As a qualified security assessor (QSA), I performed PCI audits, payment application audits and penetration tests for many companies. Eventually, I started a company that helps small and midsize organizations that were struggling with the technical requirements PCI imposed on their applications and infrastructure. At that time, most application infrastructure was run on virtual machines, and many companies were struggling to understand the implications on their application infrastructure. That’s why the PCI Virtualization Special Interest Group (SIG) proved to be an invaluable resource for practitioners and large infrastructure teams alike when it published the PCI Data Security Standards Virtualization Guidelines in 2011.
Today, with the popularity of containers among large enterprises, the PCI Special Interest Group (SIG) focusing on container orchestration aims to do the same for a cloud native world. VMware — along with other SIG participants that work with modern orchestration systems and that represent companies from all over the world — created new guidance for using PCI in containers and container orchestration, which you can read about in this blog post.
Like the virtualization guidelines before, the guidance for containers and container orchestration is not a step-by-step guide to achieving PCI DSS compliance. Rather, it’s an overview of unique threats, best practices, and example use cases to help businesses and practitioners better understand the technologies and practices available that can help with PCI compliance when using containers.
Among other things, the guidance includes a list of common threats specific to containerized environments and the best practices to address each threat. Some of the guidelines will sound familiar, because there are some very basic principles and best practices that just make sense regardless of your environment. The threats and best practices are segmented by use cases like baseline, development and management, account data transmission, and containerization in a mixed scope environment. These use cases help practitioners understand the intent of scope where the best practices apply.
The working group also breaks down the best practices into 16 subsections:
- Workload security
- Network security
- Secrets management
- Container orchestration tool auditing
- Container monitoring
- Container runtime security
- Resource management
- Container image building
- Version management
- Configuration management
While some of these are applicable outside of containerized environments and are considered good security hygiene, some areas are specific to containers. Here are the ones I believe are most critical for containerized environments:
- Workload security – In a containerized environment, the workload is the actual container or application. In virtualized environments, PCI defines everything as a system. In containerized environments, a workload is defined as a smaller unit or instance. When applications are packaged as “containers” that fully encapsulate a minimal operating system layer along with an application runtime (e.g., .NET, Njs and Spring), there are no external dependencies, and all internal dependencies are running at versions required by the application.
- Container orchestration tool auditing – The main benefit of orchestration tools is automation. The tools can include CI/CD, pipelines, supply chains and even Kubernetes. PCI recognizes that automation is just as critical to the environment as the application and the data, and, as such, the tools you are using must be audited.
- Container monitoring – Because of the ephemeral nature of containers, container monitoring should not be tied to a specific instance. PCI suggests a secured, centralized log monitoring system that allows us to make better correlations of events across instances of the same container. In addition, PCI suggests monitoring and auditing access to the orchestration system API(s) for indications of unauthorized access.
- Container runtime security – Just as with its container monitoring, PCI’s recommendations for container runtime security are essentially the same as those for VMs. By calling this out as the container runtime security, PCI is recognizing that containers are unique from VMs and, as such, have their own unique runtime elements.
- Resource management – Container orchestration capabilities like those found in Cloud Foundry or Kubernetes include resource management as part of the platform. Since it’s common to have workloads (i.e., containers and apps) share clusters and resources, PCI recommends having defined resource limits to reduce the risk of availability issues with workloads in the same cluster. With virtualized environments, this is defined as availability.
- Container image building – This is perhaps the most pronounced difference between the PCI recommendations for VMs and containers because images are unique to containers. They are what allow us to run a container anywhere. It is also why there is so much we can do with tooling, building and releasing containers, and why the implications on your security posture are profound. Automating the image build lets us set policies to specify which is the trusted (or “golden”) image. Container provenance and dependencies are major concerns for QSAs and security teams. Consider this: A quick search on Docker Hub for Java produces a list of 10,000 images using Java. While some are “official” images, many are images built by unknown people around the world and might not have been updated in a long time, or that potentially include code that could compromise the security of businesses using it.
- Registry – Registries are required if you are running containers at scale. They function as gatekeepers, enforcing policies around things like image signing and scanning.
- Version management – Container orchestration systems can run blue-green deploys based on the version management system. This means we can deploy or roll back an upgrade with no effect on our application. Version management should also be used for more than just application changes. Platforms should be automated and have configuration in version control and be treated like any other product that the company might create, operate and manage.
The final section of the orchestration guidance ties together the threats and best practices with practical use cases to help businesses and QSAs apply the provided guidance in real-world scenarios. These use cases provide a diagram and documentation around how a situation is organized, highlighting the threats with the situation and providing a mapping to the previously documented threats and best practices to show how various use cases tie to the best practices shared with the reader.
PCI is a complex process that has many “it depends” scenarios. While the PCI guidance is helpful, this white paper gives a practical example using VMware technologies. You can also reach out to the PCI Security Standards Council or your QSA if you have questions about PCI and your business.
Rita Manachi contributed to this article.