alphaspirit - Fotolia

News Stay informed about the latest enterprise technology news and product updates.

SSC issues PCI compliance checklist for third-party service providers

The PCI Security Standards Council's new information supplement helps enterprises implement a security assurance program to ensure their third-party service providers meet PCI DSS requirements.

The industry consortium behind the Payment Card Industry Data Security Standard has released new measures to help...

merchants and other organizations keep payment data secure when working with third-party service providers.

Today, the PCI Security Standards Council issued an information supplement created by its Third-Party Security Assurance Special Interest Group (SIG). The document, nearly two years in the making, offers detailed guidance for PCI-bound organizations to avoid data breaches at the hands of a third-party service provider.

Virtually all merchants rely on various third-party service providers to process payment card data, but a growing number of SMBs are using upstart or non-traditional service providers to try to cut costs and complexity. However, third-party service providers have long been the Achilles heel of the payment card data security lifecycle, with notable breach events dating back to payment processor Heartland Payment Systems Inc. in 2009, and messaging provider Epsilon Data Management LLC in 2011.

More recently, attackers behind the massive Target Corp. data breach are believed to have gained access to the retail giant's systems by exploiting weak credentials for an HVAC system managed by a third party.

Troy Leach, chief technology officer for the PCI SSC, said that while the new guidance is geared toward third-party providers that handle payment data, data breaches involving all types of third parties are occurring more frequently. Often, this happens because the responsibility for payment card data security is not clearly defined between the merchant and the service provider.

The new third-party security assurance guidance, Leach said, provides organizations with a framework to implement robust third-party service provider security assurance programs.

"It's not a new compliance requirement. Rather, it's an expansion of guidance that just can't be in the standard itself," Leach said. "It walks through various types of issues, like how to determine scope, ensuring due diligence in the relationship, how do you establish a good relationship with service providers, and simply what a policy should include, and what types of questions you should ask."

Document covers third-party compliance lifecycle

The third-party security assurance guidance highlights best practices throughout the lifecycle of a merchant-provider relationship, covering key steps including how to conduct service provider security due diligence; how to engage the provider in a way that prioritizes payment card data security; how to develop written agreements that clearly outline policies and assign security responsibility; and how to monitor providers ongoing commitment to security.

The document's information pertaining to third-party service provider security due diligence includes several flow charts (see below), which can help enterprises implement a process that aligns with its own policies, procedures and constraints.

Example third-party service provider due diligence process
Example third-party service provider due diligence process

Leach said one of the most common challenges the council sees is that many merchants falsely assume that because a third-party service provider is itself PCI compliant, all its services will be PCI compliant as well, and in turn, secure.

"Often those service providers are doing the same thing their customers are doing -- namely validating how they accept payment card data -- but that payment card environment is often not the same environment that they're using to provide services to their customers," Leach said. "It's critical to have that candid conversation as to how the service provider plans on supporting compliance in the context of the services it offers to customers."

Surprisingly, the framework outlined by the PCI Security Standards Council indicates that enterprises may consider certain service providers, even if they haven't validated PCI DSS compliance for the service in question or haven't proven that the service meets the intent of the PCI DSS. Leach said that's because the SSC recognizes that not every third-party service provider relationship will involve a direct contractual relationship to protect payment card data.

"But the responsibility of the merchants -- because they are responsible for how that card data is being transmitted through different third parties -- and their due diligence becomes much greater," Leach said. "The responsibility for the monitoring of the security of the providers remains with the merchants."

Third-party compliance complexity

Third-Party Security Assurance SIG committee member Robert Spivak, a QSA and senior consultant with Toronto-based consultancy Control Gap Inc., said the guidance goes to great lengths to define what a service provider is, as well as the four different types of service provider relationships: cardholder data processors, cardholder data security providers, cardholder data environment (CDE) protection providers and providers that may have incidental access to cardholder data or the CDE.

In reviewing feedback from the PCI community, he said the group realized many organizations lacked an understanding of what a third-party service provider actually was, and what actions were necessary to meet the requirements of the DSS.

"One particular situation that stood out was a service provider that uses other service providers to provide services to merchants -- we call that a chained third-party service provider," Spivak said. "Although the agreement may be between the merchant and its service provider, there are additional agreements between service providers that often have to be considered as part of the scope."

And those relationships can get surprisingly complex. Spivak cited an example of a payment provider that may leverage another to manage its data center. That provider, in turn, may use additional providers to build and manage its hardware infrastructure, and yet another to oversee physical security of its data centers.

"Ultimately, the responsibility for the security of payment data is shared among the merchant and its service provider, but there's often a whole ecosystem in play depending on how many service providers are being used."

Another common PCI DSS pain point regarding third-party providers is ensuring consistency in the way merchants evaluate and engage provider organizations. The guidelines in the document include detailed appendix sections identifying key third-party security controls that support PCI compliance, as well as a responsibility matrix to simplify the process of assigning responsibility for each requirement between a merchant and a provider.

Too often, Leach said, merchants make assumptions about providers' responsibilities without discussing and documenting who is responsible for what.

"We think that inconsistency is going to be addressed with the details provided in this SIG paper," Leach said. "Too often, the merchants are assuming the service provider is managing all 12 requirements for the customer, and the reality is they're only assuming responsibility for a subset of that."

Steven Weil, senior security auditor and QSA with Louisville, Colo.-based IT audit and compliance firm Coalfire Systems Inc., said that while managing third-party service provider compliance isn't among the most difficult of the nearly 300 security controls required by PCI DSS, small merchants often struggle to get large providers to provide the information they need to support their compliance efforts.

"If you're one of these large service providers, you're getting these kinds of requests every day," Weil said. "They don't want to fill out questionnaire after questionnaire."

Weil said a growing number of service providers now offer their customers a lengthy document that outlines its compliance responsibilities, as well as those of the merchant, and he hopes that the release of the SIG guidance will spur more vendors to offer detailed documentation on their obligations.

Leach said the guidance serves as an encouragement for transparency in not only written agreements, but also in the relationship between merchants and their providers. He said the SSC recognizes the challenge, particularly when it comes to asking providers to open up their environments for review or for breach investigations. However, the guidelines can serve as a framework for identifying what a provider will and won't do in advance so that a merchant can acknowledge potential problems before entering into a business relationship with a provider.

The Third-Party Security Assurance SIG began its work in 2012 with the involvement of more than 100 participating organizations, and was slated to release its information supplement last year. However, Leach said the group's efforts were delayed first by its focus on contributing to changes in PCI DSS version 3.0 -- specifically Requirements 12.8 and 12.9 that mandate new documentation and acknowledgement regarding security provider security responsibility. Also, the group encountered delays as a result of its support of the development and release of additional guidance documents to improve the PCI 3.0 compliance process.

Leach said the SSC's remaining 2013 SIG, which is outlining best practices for maintaining PCI compliance, is expected to issue its guidance this month. He's also optimistic that its newer SIGs, covering penetration testing and security awareness, respectively, will release their best practices documents prior to the September PCI community meeting in Orlando.

Next Steps

Ed Moyle reviews the five most important changes in PCI 3.0

Verizon says a surprisingly low number of companies meet all 12 PCI requirements

Dig Deeper on PCI Data Security Standard