The new PCI DSS Cloud Computing Guidelines Information Supplement v3 is a much-anticipated update that clarifies the roles for both the cloud provider and cloud customer for hosted payment technology.
Securing cloud infrastructure is a complex undertaking. The issue of who is responsible for what can be, well, a bit cloudy.
Overall, this update will be an immense help to the broader payments industry in the ongoing adoption of cloud computing by organizations subject to PCI compliance obligations. While we typically want more clarity, the current document represents a major step forward, with actionable guidance on trending topics. Coalfire recommends that all organizations with cloud environments review the guidance for compliance insights.
The guidance underscores the necessity of collaboration, transparency, and communication between cloud providers and their customers. Public-facing enterprises that process sensitive information are at risk if they can’t keep it secure. The SSC’s guidance gives everyone a meaningful place to start.
In the update, published on April 4, the SSC has shared detailed guidance about how key cloud technology fits into PCI compliance efforts from the perspective of shared responsibility, management and assessment.
Segmentation in a cloud setting has been a challenge. Evolving technological methods of isolating traffic and compute workloads have strained the DSS and resulted in uncertainty around how multi-tenant environments can be properly scoped for assessment.
While the update provides helpful guidance on scoping many cloud scenarios, it stops short of directly describing one of the most common Infrastructure as a Service (IaaS) scenarios, where the customer manages their own VM on a provider-managed hypervisor that provides demonstrable PCI DSS-compliant segmentation between customers.
In this situation, the applicable guidance is for service customers and their providers to “clearly document and understand where the boundaries are in their particular relationships, rather than assuming that any particular responsibility model applies to them.”
More recently, the appeal of microservices has led to widespread use of containers for PCI workloads. A particular challenge here is that assessed entities may have perimeters at the edge of their containers. Happily, the new guidance recognizes that Software Defined Networking (SDN) is a viable technology for securing this “micro-segmentation” scenario.
It also includes other helpful, quite specific advice, which is welcome, considering this important technology had not been addressed until now. Specifically, the orchestration system represents significant risk in a multitenant scenario. These systems merit specific attention during assessments.
Scoping for cloud environments also received strong coverage in the update, including guidance on how to parse the shared responsibilities inherent in cloud computing. The SSC also summarized some guidance for entities that are considering moving PCI workloads to the cloud. We consider these guidelines to be well motivated, but rather conservative. There are broader industry examples of successful adoption of cloud-native architecture for sensitive workloads (including the U.S. government, via FedRAMP).
With great power, however, comes great responsibility. Assessed entities wishing to take advantage of cloud benefits such as tooling and of the economies of scale must also prepare to manage operational risk with strong procedures and oversight. There have been regular reminders of this, with many headline issues that resulted from customer-managed misconfigurations of cloud resources.
One particular note for scoping is that the SSC has explicitly mandated that Security as a Service (SECaaS) providers that support an entity’s in-scope environment must be assessed. Key examples in this space include log monitoring and alerting services, and multifactor authentication services.
This clear guidance will drive broader standardization of assessments across the industry.
Guidance was also offered for new and evolving technologies. IoT and fog computing have been getting increased attention for both utility and security implications. The SSC guidance says these should be treated like any other cloud implementation.
Practical considerations include ensuring that proper logical access controls are in place, and that the cloud provider supports data security throughout the services being leveraged.
The update also addresses the use of emerging technologies like Secure Cryptographic Devices (SCDs) and cloud encryption. It reviews DSS expectations for key management as well as options for cryptographic architecture for cloud deployments. The SSC expresses a preference for handling encryption/decryption on customer premises, but outlines the concerns for operations in the cloud. The guidance points out that when a cloud provider offers an SCD (e.g., Hardware Security Module for customer use), assessments should be done at the provider level and documented in the provider’s attestation of compliance.
Desktop as a Service (DaaS) has growing appeal, and can be delivered in innovative ways. One interesting example is “Stateless VDI,” where individual components of the workspace (i.e., applications and storage) may be delivered from separate servers and networks. This can pose a scoping challenge for assessed entities, when the service delivery is not sufficiently understood.
Providers have a role to play in enabling this. For assessment purposes, anything other than a “zero” client approach will require assessment of the client for applicable controls.
In a demonstration of how seriously the SSC has taken this broad update, there is also deeper coverage of other key dimensions of the relationship between cloud provider and cloud customer. These include vendor management, due diligence and right to audit.
While vendor management requirements have been a part of the DSS from the beginning, the current guidance details the SSC’s higher expectations for due diligence. "Effective due diligence is not simply reading the Provider’s marketing material or relying on a Provider’s claims of PCI compliance; rather, it involves research, review and evidence collection." Likewise, ongoing and periodic review of the provider’s service options and customer responsibility guidance will be necessary. In certain cases, exercising a right to audit may be indicated.
The update also addresses data life-cycle considerations: knowing where cardholder data is, and has been, will enable assessed entities to better manage their retention obligations. This can be challenging in a cloud context, as the provider service delivery mechanisms may result in data that is in between normal states (e.g., in-memory processing in a suspended VM that is never reused). Providers typically do not expose these details for customer inspection; this should prompt broader conversations with providers.