Visa to Global Payments: Strike One, You're Out

A 403 Labs QSA, PCI Columnist Walt Conway has worked in payments and technology for more than 30 years, 10 of them with Visa.

This week, Visa removed, at least temporarily, Global Payments from its list of PCI-compliant service providers. That decision tells every processor and merchant that if it suffers a data breach, at least one card brand may declare the company to be noncompliant with PCI and, therefore, subject to sanctions, fines and possible loss of business. This action reflects a subtly different position than any card brand has taken in the past, and the decision has implications for every merchant and service provider.

The PCI Council states that no breached merchant or processor has been found to be PCI compliant at the time of the breach. I never liked that statement. It seems to be either tempting fate or challenging the bad guys. Although it stopped short of promising a safe harbor, at least the statement acknowledged the possibility of suffering a data breach while still being PCI compliant. Visa's suspension of Global Payments has swept aside that distinction.

The card brands enforce PCI compliance. Visa or any card brand is within its rights to impose sanctions on any processor or merchant that does not comply with PCI DSS. The PCI Council has no role to play in the Global Payments situation.

However, Visa's decision to act quickly leaves me with some questions. My first question: Is PCI a data protection standard or is it a security standard?

The difference may be subtle, but it is significant. I can imagine situations where a processor or merchant could be breached while it remained PCI compliant. For example, PCI doesn't protect a merchant or processor from a compromised or rogue insider with privileged access (Think of "The Lavender Hill Mob"). Similarly, if the individual encryption key custodians collude, they could compromise the cardholder database. An insider, or the bad guys, could tap into the internal network where PCI does not require encryption. Maybe the bad guys found a new vulnerability that we have not seen before and that PCI (which is subject to being amended and updated) does not address. Lastly, let's say the authorities confiscate (or image) a hard drive with cardholder data as part of a criminal investigation and either they lose custody of the data or a compromised insider copies the data (which may be safer and more lucrative than stealing confiscated drugs from the evidence room).

These examples illustrate what I mean when I refer to PCI not being a security program. Every QSA I know and everyone involved in PCI emphasizes security first, and then compliance follows. In each case above, it seems as if there exists at least the possibility that a merchant or processor could be breached while being PCI compliant.

Visa's banishing of Global Payments from its list of compliant service providers tells the world that if a merchant or service provider suffers a data breach, it could not have been PCI compliant at the time. Period. Perhaps Visa has evidence the rest of us don't, or it has taken a leap that says a security breach constitutes PCI noncompliance.

Another question: Would Visa react similarly if Global Payments was a merchant?

My answer is that I doubt it.My answer is that I doubt it. The card brands hold processors and service providers to a higher standard and, in my opinion, this situation is appropriate. For example, a service provider with just 300,000 annual transactions (by brand) needs an outside assessment by a QSA. A merchant with the same number of transactions would be a Level 4 and could self-assess.

Another factor is that merchants are not in the payments business; they sell stuff to consumers. Processors and other service providers are in the payment business. That means processors are, and should be, held to a higher standard than merchants both because card processing (and security) is their core business and because any data breach at a processor is likely to involve many more compromised PANs.

My third question: Does Visa know something that it is not telling us?

To the best of my knowledge, Visa has not revoked the compliance status of a processor for many years. I am sure it did not make lightly a decision that could have such a negative business impact on Global Payments.

There is a lot we don't know about the breach. Based on what I've read (I have no first-hand knowledge), we still are not sure of the timing, size or extent of the breach. We also should acknowledge that it is highly likely that Global Payments was not PCI compliant at the time of the breach (a factor that is relevant in considering my first question) and that the source of noncompliance likely contributed to the breach. Nevertheless, if Visa has some additional information to support its decision, I hope it will make that knowledge public.

Another question for merchants: If Global Payments is my processor, what should I do?

The short answer, at least initially, is to be a pest. Contact the company and keep at it until you get some direct answers. Global Payments made it clear it was the source of the breach and not any individual merchant, so you will have to get answers from the processor. It created a Web site and its merchant customers should check it regularly. Remember, too, to monitor security and news Web sites—and especially, where else?: StorefrontBacktalk—for any breaking developments.

Customers need to know when Global Payments will get back in Visa's—and the other card brands'—good graces. That is, what are the processor's plans and timing for returning to the list of PCI-compliant service providers?

Depending on how long that process takes, merchants may feel pressure to start thinking about whether to find an alternate processor. The only advice I can give as a QSA is to monitor the situation and follow your Incident Response Plan procedures. Naturally, you included a third-party breach in your IR plan, right?

What do you think? I'd like to hear your thoughts. Either leave a comment or E-mail me at [email protected].