This is page 2 of:
Retailers Need To Protect Themselves From Lying Vendors
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.
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.
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.
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 wconway@403labs.com.
Cards issued by European banks when used online cross border don't usually support AVS checks. So, when a European card is used with a billing address that's in the US, an ecom merchant wouldn't necessarily know that the shipping zip code doesn't match the billing code.
-Marc
