Cloud Foundry Security: Achieving PCI DSS Compliance
What is PCI DSS?
The Payment Card Industry Data Security Standard (PCI DSS) is a proprietary information security standard designed to ensure safety of payments and card holder data. It sets technical and operational requirements for organizations, software, and devices that participate in payment transactions.
There are 12 major requirements that must be satisfied to obtain certification (taken from the official PCI Security Standards Council website):
Normally, PCI DSS evaluation is performed separately for each deployment. This high-level overview gives a general idea of how CF meets the standard’s major objectives. The points are covered in the same order as shown in the table.
1. Install and maintain a firewall configuration to protect card holder data
Using firewalls and reducing surface area for potential attacks are common strategies that help to ensure security of networks. Cloud Foundry employs the networking capabilities of the underlying IaaS, thus network security depends on the infrastructure, as well as the type of deployment and configuration. The following diagram demonstrates a typical networking setup for Cloud Foundry.
As you can see, the components run on virtual machines (VMs) within a VLAN. The only access points visible on a public network are the load balancer, which maps to one or more Cloud Foundry routers, and, optionally, a NAT VM. The rest of the deployment is safely hidden inside a private network. This minimizes surface area for potential attacks, while allowing the components and apps to securely access external services. We recommend that you also install a NAT VM for outbound requests and a jumpbox to access the BOSH Director.
Cloud Foundry can be used together with an IaaS-level solution for monitoring and testing network connections, dynamic packet filtering, anti-spoofing, etc. It is also possible to implement a custom BOSH release with a service providing these features. Such services should be installed in front of the load balancer.
2. Do not use vendor-supplied defaults for system passwords and other security parameters
Passwords and security parameters for Cloud Foundry and apps are set in the YAML manifests. To meet this requirement, DevOps engineers responsible for installing the platform need to ensure that all the default values are replaced before deploying. As an additional precaution, manifests may be double-checked for default passwords and values with a custom script.
3. Protect stored card holder data
Cloud Foundry is designed to run stateless software and does not save any app data, be it credentials, card holder details, or any other information. Apps normally keep their data in external data stores available as services (through a marketplace, user-provided, etc.). To protect card holder data, Cloud Foundry users need to be aware that:
- Role-based access control is used for BOSH.
- Encryption should be enabled for logs, because they may contain sensitive information.
4. Encrypt transmission of card holder data across open, public networks
One of the most widespread protocols for encrypting data sent over public networks is TLS/SSL, usually referred to as SSL. This protocol is the standard for web, e-mail, instant messaging, and other applications. Banks and popular financial services, including PayPal and Stripe, employ SSL.
In Cloud Foundry, SSL is used to encrypt data sent over untrusted networks and circulating between most of the platform’s own components, such as HAProxy, Gorouter, Doppler, UAA, Consul, and their clients. Diego—the replacement for the existing runtime environment—has added a next-generation Cloud Foundry component called BBS (Bulletin Board Server) to this list.
5. Protect all systems against malware and regularly update anti-virus software or programs
Cloud Foundry is an open-source software, so users have full control over the contents of stemcells/buildpacks/stacks in their VMs/containers/apps. DevOps engineers can freely add any anti-virus software, security patches, and/or monitoring tools to protect their systems at the PaaS level. BOSH/Cloud Foundry maintainers also regularly publish new releases with security patches and other improvements.
Note that public stemcells and buildpacks do not include such software out-of-the-box. It is also worth mentioning that Cloud Foundry components run on Linux-based hosts, which are generally not vulnerable to malware and usually do not need any anti-virus software. Support for Windows servers was added with Diego in 2015.
6. Develop and maintain secure systems and applications
While this requirement is mostly administrative, Cloud Foundry has features that help to achieve its objectives. Specifically:
It automates many processes, reducing the chance of human error. In addition to built-in automation features, Cloud Foundry allows for using custom scripts to perform software checks, install patches, etc.
It can be integrated with any third-party or custom security solution.
Cloud Foundry makes it possible to create continuous delivery (CD) pipelines with any number of identical, yet completely isolated, environments. Users can consistently re-create the same environments any number of times.
7. Restrict access to card holder data by business need-to-know
As noted before, card holder data is not stored inside Cloud Foundry. See point “3. Protect stored card holder data” for more on how to ensure that no sensitive app data gets compromised. User authentication and authorization will be discussed in the next section.
8. Identify and authenticate access to system components
The eighth requirement has to do with authentication (who the user is) and authorization (what they are allowed to do). Cloud Foundry provides fine-grained access control at the PaaS level via a component called UAA. Responsible for authenticating and authorizing users, UAA is what makes multi-tenancy, one of CF’s greatest features, possible. It supports LDAP and can retrieve user data from Active Directory, Google, Facebook, and other services. Below is a diagram by Pivotal that demonstrates how UAA works.
Recently, authentication and authorization features for operators were added to BOSH. Now, it is possible to differentiate admin BOSH users with full access to all deployments and users with read-only rights.
9. Restrict physical access to card holder data
Cloud Foundry is a software product, so it can have no influence on who gets physical access to servers with card holder data. It certainly does not stand in the way of restricting such access. Some of Cloud Foundry’s features may actually be helpful in meeting this requirement, for instance:
The PaaS is IaaS-agnostic and may be deployed to any infrastructure.
Cloud Foundry apps keep all data in external services. This gives users a lot of freedom in choosing where and how their data is stored.
10. Track and monitor all access to network resources and card holder data
Cloud Foundry can work with any network monitoring tools. It also provides convenient access to all its logs and metrics through a single endpoint. (See the comments to the requirement “12. Maintain a policy that addresses information security” for more on Cloud Foundry logging.)
11. Regularly test security systems and processes
Security systems and processes—e.g., vulnerability and intrusion detection tools—need to be in place with or without Cloud Foundry. In its turn, the platform does not interfere with implementing or using such systems and processes in any way.
BOSH can help with integrating agents of security systems into all hosts within a Cloud Foundry cluster in an easy and consistent way. Any security software can be incorporated into a CF release in the form of jobs to be automatically installed on each machine created and managed by BOSH.
12. Maintain a policy that addresses information security
While maintaining a security policy is strictly an administrative requirement, Cloud Foundry helps to satisfy it by auditing data with:
- CF application logs
- CF component logs
- application events
- logs of actions performed by users and BOSH operators
BOSH operators have access to an audit trail through the bosh tasks command that displays all the commands executed by an operator. For users, Cloud Foundry records an audit trail of all relevant API invocations of an app.
All the Cloud Foundry component logs and metrics can be accessed through a single endpoint known as the Firehose. Operators can then redirect them to an external log aggregation system/monitoring tool, such as ELK, Splunk, etc.
Can a PaaS be an obstacle to getting PCI DSS certification?
In conclusion, I’d like to stress that PCI DSS requirements are targeted at systems that include many layers besides a PaaS. Consequently, security of such systems depends on many factors. These include deployment configuration, type of infrastructure, PaaS distribution, and how the apps are built.
The following table is a summary of how the different PCI DSS requirements can be addressed in a system based on Cloud Foundry.
| PCI DSS requirements | Can I meet them with Cloud Foundry? |
|---|---|
| 1. Install and maintain a firewall configuration to protect card holder data | Not directly related to CF. Compliance can be achieved at the IaaS level and via administrative processes. |
| 2. Do not use vendor-supplied defaults for system passwords and other security parameters | Not directly related to CF. Compliance can be achieved via administrative processes. |
| 3. Protect stored card holder data | We assume that apps running on CF are stateless and use external storage. Compliance can be achieved at the IaaS level and via application architecture. |
| 4. Encrypt transmission of card holder data across open, public networks | + |
| 5. Use and regularly update anti-virus software on all systems commonly affected by malware | + |
| 6. Develop and maintain secure systems and applications | + |
| 7. Restrict access to card holder data by business need-to-know | Not directly related to CF. Compliance can be achieved at the IaaS level and via administrative processes. |
| 8. Identify and authenticate access to system components | + |
| 9. Restrict physical access to card holder data | Not directly related to CF. Compliance can be achieved via administrative processes. |
| 10. Track and monitor all access to network resources and card holder data | Not directly related to CF. Compliance can be achieved at the IaaS level and via administrative processes. |
| 11. Regularly test security systems and processes | + |
| 12. Maintain a policy that addresses information security | Not directly related to CF. Compliance can be achieved via administrative processes. |
As you can see, Cloud Foundry does not create any obstacles on the way to getting certified with PCI DSS. In fact, it provides better overall security than running apps without a PaaS. There is a large community actively contributing to and improving Cloud Foundry, so it is likely to become even safer in the future.
In upcoming posts, I am going to speak about SSL validation for custom domains and share some of Altoros’s experience with securing PaaS deployments.
I am also glad to say that, thanks to Joshua McKenty (Pivotal) and Diego Lapiduz (18F), we now have an open wikibook for accumulating real-life Cloud Foundry security experience. Feel free to contribute.
Further reading
