Businesses in the financial tech (fintech) industry handling payment cards must adhere to the Payment Card Industry Data Security Standard (PCI DSS). Failure to comply results in low public trust and loss of a key certification. With the fintech space booming as new players enter this market, agility is key. Both for established enterprise players that want to keep their competitive edge and for the startups with a great idea. Kubernetes and the cloud-native landscape of services is well-known for providing agility in software delivery. But how can we make sure that the underlying platforms powering modern fintech applications are compliant?
The 12 requirements to comply with the PCI DSS
The PCI DSS is, as most of these compliance requirements standards, quite a long read. However, thankfully, the gist of it can be easily understood by referring to the PCI DSS Prioritized Approach. It is provided free of charge by the PCI Security Standards Council.
The 12 requirements stipulated by the PCI DSS are the following:
- Install and maintain a firewall configuration to protect cardholder data
- Do not use vendor-supplied defaults for system passwords and other security parameters
- Protect stored cardholder data
- Encrypt transmission of cardholder data across open, public networks
- Use and regularly update anti-virus software or programs
- Develop and maintain secure systems and applications
- Restrict access to cardholder data by business need to know
- Assign a unique ID to each person with computer access
- Restrict physical access to cardholder data
- Track and monitor all access to network resources and cardholder data
- Regularly test security systems and processes
- Maintain a policy that addresses information security for all personnel
We will go over all these in detail in the next sections. Remember that we focus on the Kubernetes platform. So some requirements are beyond the scope of this blog post — how an application handles data or the physical security aspects are of course not platform services.
Making Kubernetes comply with the PCI DSS
In this section and its subsections, we will focus on what can be done to make a Kubernetes-based environment comply with the PCI DSS. We said earlier that some of the requirements are out of scope, as they relate to e.g. how the application works or that they require physical security. Many of the requirements also require changes to how the organization works, such as keeping a list of all people with administrative access. Such human-centric processes are also not covered here, as we deep-dive into technology as the supporting tool to business that it is.
R1: Firewall configuration
Using a Container Network Interface (CNI) provider that supports Kubernetes Network Policies, we can add firewalling to applications deployed on Kubernetes. Combined with formal processes around how to update rules and who gets to do it, this provides sufficient protection. Payment card data must be put in an internal network. Businesses can bridge the internal network with a public one. They then need to establish a demilitarized zone (DMZ) between these and strict rules about how traffic gets to flow. Network Policies can aid also here, in that services can be exposed selectively based on IP ranges.
R2: Avoiding default passwords and security parameters
Kubernetes itself is completely unaware of which applications are deployed onto it. So it will not protect against configuration errors like use of default passwords or other security parameters. However, by using the Open Policy Agent (OPA), policies can be put in place to forbid default passwords in configuration files. If an administrator should make a mistake, the OPA will catch it before the resource is admitted onto the Kubernetes platform. So the error will never be put into production and the reason will be logged.
This requirement also states that services of different security levels should not co-exist on the same servers. To ensure this, Kubernetes worker nodes should be annotated with their security level. All Pod specs should then reference which security level they require. The OPA can ensure that such a specifier must be given, preventing human error mistakes.
R3: Protect cardholder data
This requirement is up to the database or storage service that is used, so beyond the scope of the Kubernetes platform. Elastisys recommends using a hosted service for this purpose, to ensure proper encryption, data retention, and documentation. We offer both MariaDB and PosgreSQL as managed services, so do contact us if you want to discuss how to proceed.
R4: Encryption of transmission over public networks
Encryption of data in transit requires strong ciphers and frequent certificate rotation. Cert-manager can be added to a Kubernetes cluster, and handled x509 certificate operations automatically. Ensuring that all public endpoints are exposed only securely can be done by again relying on the Open Policy Agent to avoid configuration errors.
R5: Use of antivirus software (proactive security)
In Kubernetes, Linux-based as it is, antivirus software is not particularly common and even if one installs e.g. ClamAV, the added protection is not sufficient to protect against server-side vulnerabilities. However, if interpreted as requiring the use of proactive security software, there is more we can do. First of all, vulnerability scanning in container images is offered by serious registries such as Harbor. For runtime protection, we also care about intrusion detection. Correctly configured, this is what Falco offers. Combined with sandboxed containers, Pod Security Policies that explicitly list required capabilities, and Open Policy Agent to enforce that no misconfiguration can happen, a full protection suite is in place.
The use of anti-virus is still a good idea, however! Both to protect your staff and your customers. Imagine sending infected documents to your customers. Don’t be that company!
R6: Developing and maintaining secure applications
While much of this requirement is out of scope for the underlying platform, the platform is definitely still part of the “application” itself from the point of view of the PCI DSS. Thus, there is a requirement to have sufficient processes in place, documentation, keeping up on upstream updates, and much more. For organizations that choose to self-host Kubernetes, this burden falls on them. By instead relying on a managed service, e.g. Elastisys Compliant Kubernetes, this responsibility is shifted toward the provider instead. For agility in developing your application, we of course recommend choosing a managed service.
R7: Restrict cardholder data by business need to know
This requirement primarily targets processes that need to be in place. On a technical level, the support that can be given here is to ensure that not only database access is restricted, but also to applications. Both external and internal access to APIs and services that may read sensitive data must also be restricted.
R8: Unique IDs for each person with computer access
For staff, businesses big and small typically already have something like this set up already. And a lot of integrations that rely on this system working, so getting a new one would be a hassle. So in practice, this requirement is in most cases handled by relying on an identity provider, such as Google or Active Directory (or some other LDAP). Kubernetes does not natively integrate with such identity providers, but does support OpenID Connect. Leveraging an OpenID Connect aware client to other identity providers can create a needed bridge. We recommend Dex for this purpose for staff.
Users are typically handled not via e.g. an Active Directory, but via some customer database in e.g. PostgreSQL. Then, of course, that database must be kept secure as well and access to it restricted. Again, we recommend a managed service for handling databases, such as the one offered by cloud providers or directly by Elastisys.
R9: Restrict physical access to cardholder data
This obviously falls outside of the responsibility of software. However, we would like to note that customers should use only PCI DSS certified cloud vendors, or make the appropriate restrictions in their own data centers.
R10: Track and monitor all access to network resources and cardholder data
This requirement stipulates tamper-proof audit logging, time synchronization between computers, and that logs are reviewed for security incidents. Audit logging can be enabled in Kubernetes and combined with role-based access control (RBAC), all operations happen within the context of a particular user. Combined with an identity provider from R8, the context is clear. However, audit logs must also be securely stored. Logging data can be stored in e.g. the fully open source Open Distro for Elasticsearch, developed by Amazon Web Services. How to in detail ensure that log entries cannot be tampered with is beyond the scope of this blog post, but forcing append-only semantics helps considerably. Written entries cannot then be overwritten.
R11: Regularly test security systems and processes
On a process level, this requirement states that regular security scans and audits must take place. On a technical level, this means that automated vulnerability scanning must be used regularly. In addition, intrusion detection systems must be employed. For intrusion detection, we recommend Falco.
PCI DSS states that a “change detection” system should also be in place, for which we recommend signed container images coming out of the build system. This can be accomplished using Docker Notary as a final part of your CI/CD pipeline. With signed images, the Open Policy Agent can be configured to reject images that do not have the correct signature.
Related to change detection is change avoidance. To reduce the number of moving parts in your system, you can ensure that Pods mount read-only file systems, worker nodes are immutable, and thereby reduce your exposure to changes significantly.
R12: Maintain a policy that addresses information security for all personnel
This requirement is almost entirely on an organizational level and relates to policies. However, again, the Kubernetes platform must also comply with the standard.
Summary
In this blog post, we have covered all the 12 requirements of the PCI DSS and how they translate into actionable tasks for ensuring compliance in Kubernetes-based environments. Kubernetes has a proven track record of increasing agility and ability to deliver software to customers. In addition, the cloud-native ecosystem is evolving and creating a lot of fascinating technology that makes software development and delivery easier and more cost-effective. For businesses in financial technology, Kubernetes can be a game changer that lets them cut down on costs and focus attention on offering a better application than their competitors.
PCI DSS requirements also apply across the entire software stack. Therefore, companies that choose to self-host the Kubernetes platform have a much larger burden than companies that choose a trusted partner to do it for them. Elastisys Compliant Kubernetes embodies all the technological steps and knowledge presented in this blog post. Customers that value agility, wish to reduce their compliance burden, and reduce their time to market for new features rely on Elastisys to host fully-managed Compliant Kubernetes for them.
