Service Providers and PCI Compliance, Part 1 – Cloud Services and Your Obligations

This post is the first in a three-part series dedicated to companies working with service providers relating to PCI compliance.

The PCI consulting practice at Optiv performs hundreds of PCI-related engagements each year, including ROCs, SAQs, gap assessments, readiness assessments, and executive workshops. One of the frequently-requested topics of conversation is all about PCI compliance in the cloud. We’ll address different facets of this topic in this article.

"Cloud" is that overused IT pronoun that has many different meanings in different contexts. We'll address some of these perspectives here.

Infrastructure as a Service (IAAS) and PCI

Organizations using IAAS as a part of their cardholder data environment (CDE) typically design and implement an environment consisting of servers with their respective operating systems, database management systems, applications, tools, and supporting services; as well as firewalls and other network devices. The IAAS environment will probably utilize a defined demilitarized zone (DMZ).

The misnomer of cloud services is that the cloud service provider takes care of all security matters. This assumption is patently WRONG. The fact of the matter is this: no matter where, or in what form, the CDE infrastructure is located, the cloud customer is responsible for all infrastructure-related PCI controls (the only exception is physical security, which we'll cover shortly). An organization that places its workloads in the cloud is responsible for implementing and managing firewalls, intrusion prevention system (IPS), file integrity monitoring (FIM), event logging and alerting, anti-virus, server hardening standards, network architecture, and all of the other controls regarding user and administrative access controls, monitoring, reviews, policies, and so on. From a PCI perspective, moving from an on-prem data center to the cloud absolves an organization of ONLY the physical security controls. However, even here, organizations are not entirely off the hook.

Regarding physical security.

An organization that is in a co-location or an IAAS environment is still indirectly responsible for physical security. In these situations, organizations need to ascertain whether their co-lo or IAAS providers are themselves PCI compliant. Generally, this is done by asking for their "attestation of compliance" (AOC), a formally signed document that asserts their compliance to applicable PCI controls. If the co-lo or IAAS provider doesn't have this, organizations will have to determine through other means the degree to which they are PCI compliant.

Further, in any co-lo or IAAS situation, organizations should complete a PCI Responsibility Matrix. This is a worksheet that details the responsibilities for all PCI controls, specifying which party(ies) are responsible for which controls, and how they test and attest to those controls. The PCI Responsibilities Matrix is available from the PCI Standards Council in the Information Supplement on Third-Party Security Assurance document. While this can be tedious to complete correctly, all parties must understand and agree to their stated responsibilities for PCI controls.

Software / Platform as a Service (SAAS/PAAS) and PCI

Organizations using SAAS or PAAS environments that are a part of their CDE have an obligation that is similar to the IAAS discussion described earlier. Typically, a SAAS or PAAS environment will have a somewhat larger share of responsibilities than an IAAS service provider. Instead of just being responsible for physical security, a SAAS and PAAS organization will also manage its own network architecture, server security, firewalls, security monitoring, administrative access, and more.

Because of the variance among SAAS and PAAS orgs, it’s doubly important to complete a PCI Responsibility Matrix so that there are no ambiguities with regards to responsibilities for every PCI control. This matrix is included in the PCI Standards Council's Information Supplement on Third-Party Security Assurance document. But don’t just skip to the appendix; instead, it is important to understand the narratives as well.

Regardless of the type of relationship you have, it is critical as a cloud customer that you clearly understand your responsibilities.

Be sure to check our blog soon for Part 2 of this series where will explore these third party relationships in more detail.

Comments are closed.