News, Education and Events Decoding Digital Payments & Fraud

News, Education and Events Decoding Digital Payments & Fraud

CNP Series Report – PCI Part 3: Third-Party Crashers

By Jeff Man, Security Strategist and Evangelist, Tenable Network Security, exclusively for

PCI Part 3: Third-Party Crashers When the PCI Security Standards Council (PCI SSC) published version 3.0 of the Payment Card Industry Data Security Standard (PCI DSS) in November 2013, there were several changes the organization felt were significant enough to warrant a grace period.  That reprieve came to an end June 30, 2015, when those changes morphed from “best practice” to “requirement.” There are five new requirements found in PCI DSS v3.0/3.1 that went into effect on that date. The third and final article in this series will examine the requirements that outline a company’s PCI compliance responsibility when dealing with outside vendors. 

When PCI DSS v3.0 was first published in November 2013 there was a lot of attention given to what many considered to be the biggest change to the standard at the time, which was the greatly expanded definition of penetration testing and the requirement for companies subject to PCI compliance to implement a documented penetration testing methodology ( covered in the first installment of this series ). But as time has passed and events have unfolded, the new requirements that are directed at service providers might prove to be the most important and meaningful changes made to the PCI DSS to date.

There have been numerous payment card breaches in the past eighteen months that were successfully conducted through [hide for=”!logged”]the exploitation of a third party. Probably the most well-known was when Target was breached through an HVAC provider, but there have also been breaches perpetrated through point-of-sale vendors, and just in the past week, a company that “provides a proprietary transactional software platform” was blamed for the intrusion that shut down photo processing Websites at CVS, Costco and Walmart Canada.

While one might be able to see why an HVAC company might not be considered when evaluating security for PCI compliance, it gets harder to extend that benefit of the doubt to a point-of-sale provider or a transactional software platform.

What is a Service Provider?

The PCI Glossary Version 3.1 states that a Service Provider is a “Business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data on behalf of another entity. This also includes companies that provide services that control or could impact the security of cardholder data.” The glossary also lists examples of companies that should be included and the special circumstances where a company may not be considered a service provider.

Historically, service providers were recognized as the companies that operate “in-line” with the payment authorization and settlement path. Service providers are responsible for reporting their compliance status to the major payment card brands, and Visa and MasterCard actually maintain global listings of all the validated compliant service providers registered to do business with them. The broad nature of the definition of service provider, and the changing IT landscape that revolves more and more around outsourcing has meant that there are lots of companies that perform services for merchants that weren’t “on the radar screen” for the service providers. In recognition of this, Visa recently launched a new program where these other service providers can be recognized and tracked. The program is called the Merchant Servicer Self-Identification Program (MSSIP). This program is intended for those companies that fall outside of the direct payment path, but all are subject to PCI compliance based on the definition of service provider.

Are You a Merchant or a Service Provider?

PCI Part 3: Third-Party Crashers If you are a merchant, you need to understand that every company or third party that helps you conduct business is a likely candidate for being classified as a service provider. So, if your company sells a service, you are probably a service provider. If your company sells to other companies (and not directly to consumer), you are probably a service provider. If your company is primarily a supplier of hardware and/or software AND you provide support for the hardware/software you sell, you are probably a service provider.

Merchants have been responsible since PCI DSS v2.0 for managing the relationship with their service providers including maintaining a comprehensive listing of all third parties that provide services to them in support of their payment transaction processes, assuring that each service provider has a written agreement to protect cardholder data, conducting proper due diligence before engaging a third party, and also keeping track of each of their third parties’ own PCI compliance status (PCI DSS 12.8, 12.8.1-12.8.4). PCI DSS v3.0/3.1 enhanced this requirement to explicitly include service providers that “could affect the security of cardholder data.”

In addition to the 12.8 requirement, PCI DSS v2.0 also provided detailed instructions for how third parties/service providers were to be treated during the merchant’s PCI compliance validation process. These instructions were found in the introductory section entitled “Scope of Assessment for Compliance with PCI DSS Requirements” and basically stipulated there were two ways for a third-party service provider to demonstrate compliance with the PCI DSS for the benefit of their merchant customer’s own PCI compliance. The preferred method was for the third party to conduct its own PCI compliance assessment and provide evidence in the form of an Attestation of Compliance. The alternative method was for the third party to participate in the merchant’s PCI compliance assessment and be available for interviews, provide the required documentation or evidence, and be available for any detailed reviews required to be performed by the QSA.

This strategy did not prove successful. There were many merchants that thought all they need to do to manage their third-party service providers was to fulfill the 12.8 requirement, and there were many companies that fit the definition of service provider that either didn’t recognize this designation or didn’t think it applied to them.

Clarification and additional guidance provided in PCI DSS v3.0/3.1 included the two new requirements that will now be discussed.

New Service Provider Requirements in PCI DSS v3.0/3.1

There are two new service provider-focused requirements in v3.0/3.1 (8.5.1 and 12.9). Requirement 8.5.1 states that “Service providers with remote access to customer premises (for example, for support of POS systems or servers) must use a unique authentication credential (such as a password/phrase) for each customer.”

This requirement was added to the existing 8.5 requirement that prohibits the use of “group, shared, or generic IDs, passwords, or other authentication methods.” Apparently, it was not well understood that this security best practice should apply to all access to systems within the cardholder data environment including by companies that are providing administration or management of these devices.

The addition of this requirement will hopefully eliminate breaches such as the one caused in the past year by the point-of-sale vendor that was using a common or shared password to remotely administer all of their customers’ systems. But this will only prove true when these types of companies understand that they are acting as a service provider and are thus subject to the security requirements put forth in the PCI DSS.

The second new requirement in PCI DSS V3.0/3.1 was added immediately after the 12.8 requirement and states that “Service providers acknowledge in writing to customers that they are responsible for the security of cardholder data the service provider possesses or otherwise stores, processes, or transmits on behalf of the customer, or to the extent that they could impact the security of the customer’s cardholder data environment.”

This requirement actually was introduced in PCI DSS v2.0, but in the introductory scoping section previously indicated. This requirement simply requires that the merchant and the service provider agree on which requirements are (or are not) being covered by each of the respective companies. The goal is to make sure that all of the PCI DSS requirements are being met by someone to reduce the likelihood of compromise or attack.

From a card-not-present perspective, for example, e-commerce merchants whose servers are being hosted or managed by a third party need to pay particular attention to what the hosting provider or the company that “provides a proprietary transactional software platform” is managing in terms of the specific PCI DSS requirements.

It is very common for hosting providers to advertise that they are “PCI compliant” and even maintain their status on the Visa Global Security Provider listing. But that doesn’t mean that they are meeting all of the specific PCI DSS requirements you think they are providing. Hosting providers very often only provide rack space, “lights and power” and physical security to the facility where the servers are hosted. This does not typically include the requirements for building secure servers, maintaining the security of the servers through patching, configuration and change management, vulnerability management, logging and monitoring or incident response.

What Should We Do?

There are several key steps that hopefully have become clear. First and foremost, identify whether or not your own company is a service provider to other companies. Assuming you are a merchant, it is imperative to identify all third parties you do business with and determine if they are directly or indirectly involved in your payment-card processing. Then you must negotiate with each one to assure that both parties agree on “who’s doing what” when it comes to meeting each of the PCI DSS requirements.

This has been a daunting process for many merchants over the years, as evidenced by the spate of breaches where a service provider was involved. Hopefully, the new requirements, along with better education and understanding of the roles and responsibilities of everyone involved, will help prevent hackers from successfully attacking your systems.

The bottom line: Many companies have failed to realize that they are functioning as or fall under the category of service provider in the eyes of the PCI world, and, as such, have ignored the requirements set forth in the PCI DSS. Unfortunately, too many times these situations are “discovered” as a result of a payment card breach. Know who you are; know what you are; and secure your data and your customers’ data accordingly!

Read PCI Part 1: New Penetration Testing Requirements

Read PCI Part 2: Card-Not-Present vs. Card-Present Requirements


  • Share this Article:

Daniel Leibovitch