PCI DSS compliant means complete ownership of the responsibility of the cardholder data (CHD). The client must still ensure they are using the service in a compliant manner, and is also ultimately responsible for the security of their CHD (irrespective of what cloud service they are using) and use of a PCI DSS compliant Cloud Service Provider (CSP) does not result in PCI DSS compliance for the clients.
PCI DSS will be applicable if you are storing, processing or transmitting payment data in a cloud environment. The purpose for the usage of cloud service and scope of the PCI DSS requirements that client is expecting CSP to manage (depending on the service option client has selected like IaaS, PaaS or SaaS) are of primary importance from the perspective of achieving compliance. Client needs to drill down each PCI DSS requirement and create responsibility matrix and ownership with respect to each and every task without any assumption. Everything should be clearly documented in the form of agreements, contracts, memoranda of understanding and/or service level agreements stating clearly the roles and responsibilities of each party in the security and process.
One of the challenging areas would be the understanding of Assessors about various cloud service providers. They need to know about the cloud environment in order to provide guidance to client on how to go about PCI DSS compliance? In case of public or truly private cloud, the cloud service provider does not offer any control over hardware. Client needs to manage the control part through application (in SaaS model), applications and virtual components (in IaaS Model) so it depends on the service model.
Security and compliance is a shared responsibility between client and cloud service provider. (Both refers to client and cloud service provider) Example of how PCI DSS responsibilities may be shared between clients and CSPs.
In any of the service model, client is made responsible and part of the control over cardholder’s data.‘Restrict access to cardholder data by business need to know’. That means even if you are using any SaaS application which will store/process/transmit cardholders information, it will be your responsibility to ensure the cardholders data is properly secured.
The PCI DSS requirement state that ‘clear policies and procedures should be agreed upon between client and cloud provider for all security requirements and clear responsibilities for operation, management and reporting need to be defined for each requirement’. This appears quite simple task however considering various service models, control that will be shared with client by cloud service provider will make it difficult for any client to define clearly.
One of the ambiguous areas is about monitoring the ongoing PCI DSS control requirements. ‘The guideline document says ‘Where the CSP maintains responsibility for PCI DSS controls, the client is still responsible for monitoring the CSP’s ongoing compliance for all applicable requirements’. What it means is that even in case of SaaS where most of the compliance responsibility lies with CSP or SaaS application service provider, client will have to monitor and ensure that CSP is following the guidelines. Now how many SaaS service providers provide such flexibility or strong service level agreements?
Segmentation Considerations: Clients utilizing a public or otherwise shared cloud must rely on the CSP to ensure that their environment is adequately isolated from the other client environments.
Segmentation on a cloud-computing infrastructure must provide an equivalent level of isolation as that achievable through physical network separation. Is this practical? Isn’t this quite challenging to achieve? How can a SaaS service provider going to achieve physical network separation between his clients?
Similarly the segmentation consideration guideline suggests that ‘Any shared infrastructure used to house an in-scope client environment would be in scope for that client’s PCI DSS assessment’ the question we would like to ask is why? Is this necessary?
Compliance challenges: Public cloud environments are usually designed to allow access from anywhere on the Internet. It can be challenging to verify who has access to cardholder data processed, transmitted, or stored in the cloud environment. It can be challenging to collect, correlate, and/or archive all of the logs necessary to meet applicable PCI DSS requirements. What more to say when the guidelines itself says that the public cloud environment are challenging from monitoring and access control perspective.
Data Acquisition: The client will ultimately determine how and when the cardholder data is acquired in the cloud environment. End-to-end processes and data flows must be documented across both client and cloud provider networks, so that it is clearly understood where cardholder data is located and how it is traversing the infrastructure. This will also help the client and CSP to identify where each entity acquires and relinquishes cardholder data throughout the process. Needless to say that it’s difficult to identify which system components are in scope for a particular service, or identify who is responsible for particular PCI DSS controls.
Boundaries between cloud service provider and client environment are usually fluid and that’s the bigger part of the challenge. In case of SaaS provider and public clouds clients have no visibility into the CSP’s underlying infrastructure, where the CHD is stored, the actual location and you cannot expect all the CSP to have the same level of access control, logging, and monitoring as their physical counterparts. The complexity and diversity of cloud services makes it difficult to apply one set of rules to everyone. The guidelines are trying to cover entire picture and yet appears vague in many ways.
