Retailers Need To Protect Themselves From Lying Vendors

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

I am not a fan of boxing, but I seem to remember that just before the start of a fight the referee tells each boxer to "remember to protect yourself at all times." I am starting to think that merchants need to take this advice when dealing with some payment system and application vendors.

If you don't protect yourself at all times, you could end up paying a lot more in both money and time to become PCI compliant. With the Visa mandate on PA-DSS applications in full effect, it may be time for retailers to break out their boxing gloves.

A retail CIO's life is complicated enough without having to deal with the few application vendors and service providers that lie. I'm not talking about the usual marketing hype or stretching the truth about how easy it is to install some software package. Rather, I'm talking about misrepresenting the impact of a vendor's product or service on a retailer's PCI compliance.

Regardless of the chain's size--from a large retailer with lots of localized decision-making to a franchisor with franchisee-owned stores to even a midsize merchant without a large IT staff--this situation affects you.

I guess I could be diplomatic and say these vendors just don't understand what PCI requires, but it is a bit late for that. PCI has been in effect for several years, so ignorance is no longer an excuse. That train has left the station. Any vendor that can't properly describe how its application or service will impact a merchant's PCI scope or compliance is--in this QSA's opinion--simply not telling the truth.

Were the vendors genuinely ignorant of PCI? I do not know where stupidity ends and lying begins. But in my mind, such vendors misrepresent their products to their customers, and the customers are now paying the price.

To be fair, we need to remember that the lies may have two sources. It's not necessarily the case that the vendor representatives in your office are lying about PCI. They may be honestly telling you what their company told them to say or what they read in a talking points memo. Instead, it may be their bosses who have lied.

On the other hand, you may have the opposite situation, where the vendor is being truthful but the reps have chosen to be stingy with the truth. Whether or not they know what they are saying is a lie is irrelevant to my point. You need to understand what PCI requires. The days of blindly trusting a specialized vendor for trusted counsel are, sadly, gone.

Here are some situations I have seen recently:

  • The first indication that should make you suspicious is when a vendor talks about being PCI "certified."

    As far as I know, nothing in the world of PCI is "certified." Payment applications may be validated, PIN encryption devices may be approved and service providers may be assessed or compliant, but nothing is certified. Maybe the vendor in this case is certifiable, but that is a separate discussion.

    The problem is that the retailer is left to pay the price in terms of increased risk, expanded PCI scope and possibly higher cost to become compliant.

  • You also may be dealing with a lying vendor if the reps talk about "how our partner is PCI compliant, so you have nothing to worry about." In this case, it was a client who hosts a payment application that purportedly makes the merchant PCI compliant because the package connected to a Level 1 Service Provider. Unfortunately, the vendor told only half the story. What the vendor did not point out was that the client-hosted application processed payment card data before transmitting everything to the service provider. .What the vendor did not point out was that the client-hosted application processed payment card data before transmitting everything to the service provider. This approach puts the application squarely in the merchant's PCI scope. The merchant intended to outsource this part of its card processing but ended up expanding its PCI scope instead.

    Adding to the problem is the fact that the application itself was not PA-DSS validated. As a result, the merchant runs afoul of the Visa mandate and the application code may also fall into the merchant's own PCI scope.

  • In another recent case, I've seen a vendor selling a Web-based module that processes cardholder data on the client's Web server before transmitting it to the processor.

    Instead of a hosted order page at a PCI-compliant service provider, the merchant ended up running a Web-facing application and having to comply with Requirements 6.5 and 6.6, among all the others.

  • Yet another situation where you may be dealing with a lying vendor is when you hear "the application is behind a firewall, so you are PCI compliant."

    A firewall does not make you PCI compliant. If you have, say, outsourced this application to a third party but that provider wants you to continue to host it in your data center, just behind a firewall, look for the door.

    Running the application behind even a properly configured firewall will not remove it from your scope if it is your firewall. Worse yet, because you are now hosting a payment application for a third party, you may just be considered a service provider.

  • Similarly, if you hear "the application is PA-DSS certified so you will be PCI compliant," I advise you to get up and take everyone you like out of the room.

    Implementing a PA-DSS-validated (not "certified," remember?) application can certainly aid your PCI compliance if it is installed according to the vendor's implementation guide and in a PCI-compliant environment. PA-DSS validation is not a free pass on PCI.

    For example, it does not mean the application doesn't store electronic cardholder data, which itself will expand your PCI scope and preclude your using any of the simplified Self-Assessment Questionnaires (SAQs).

    A last thought is to remember that the PCI Council's PA-DSS list has two categories: one for applications "acceptable for new deployments" and the other for applications "acceptable only for pre-existing deployments." When an application vendor tells you it is on the Council's list, make sure its product (and version) is in the first category and not in the second.

    Why am I blaming vendors and not merchants? After all, should not all merchants be in "protect yourself at all times" mode, too? The difference is that I expect more of the vendors; this is their job. The retailers' job, and even the retail IT staff's job, is to run their business. They count on vendors for expert knowledge, information on industry trends and a certain amount of expertise. Many vendors do provide these benefits, and you should value those relationships. Unfortunately, this is not always the case.

    Other than having your QSA in every vendor presentation--which I definitely would not recommend--the best way retailers can protect themselves is to get smart and get trained in PCI. The PCI Council offers a choice of training sessions, each of which is worth your consideration. Think of these sessions as your PCI boxing gloves.

    Have you had a disappointing experience with a lying vendor? How about an experience with a knowledgeable vendor that opened your eyes and did a great job? I know there are vastly more of these honest vendors than there are lying vendors. I'd like to hear your experiences. Either leave a comment or E-mail me at [email protected].