This is page 3 of:
How About A Little Service Provider Responsibility Here, PCI-Wise?
This new requirement would most logically fit under PCI Requirement 11 (Regularly test security systems and processes). We could make it an extension of 11.1, which addresses rogue wireless networks.
My guess is that every retailer will have loads of thoughts that qualify for the general feedback category. I’d like to contribute the suggestion that the Self-Assessment Questionnaires (SAQs) are out of date, and most reflect neither current merchant practices nor current threat vectors. I’ve detailed my recommendations for updating the SAQs, so I’ll leave it to others to toss in their own feedback.
All of these suggestions address PCI DSS, which is the main concern of most readers here. I would note that the PCI Council is also soliciting comments on PA-DSS. Taking the view of a retailer (rather than a software developer), I would encourage retailers to think about what would make their life easier when choosing a PA-DSS-validated payment application.
Too many merchants are still under the misperception that implementing a PA-DSS-validated application makes them PCI compliant automatically. Unfortunately, that is not the case. Although a PA-DSS-validated application can simplify PCI compliance (if it is implemented per the vendor’s PA-DSS Implementation Guide and in a PCI compliant environment), it is not a silver bullet.
A second misperception of many merchants is that PA-DSS-validated applications do not store electronic cardholder data. That is wrong. In fact, many applications on the PCI Council’s list of validated applications store cardholder data. That’s just the way they were built.
A merchant storing electronic cardholder data may not validate their PCI compliance using one of the shortened SAQs. I work with merchants who aimed to simplify their life by using an application from the PCI Council’s list, only to find their shiny new payment app threw them into SAQ D, because it stored electronic cardholder data.
Therefore, I suggest retailers might provide one bit of PA-DSS feedback: Include an item in the PA-DSS validation that states whether the application stores electronic cardholder data at any time. The options for this item would be one of: the application stores electronic cardholder data; the application does not store data; or the application is configurable either to store or not to store based on the merchant’s preference.
What do you think? What was your feedback to the PCI Council? I’d like to hear your thoughts. Either leave a comment or E-mail me at wconway@403labs.com.
-Marc
March 29th, 2012 at 4:45 pm
I appreciate the one-sideness issue highlighted in this article. I also understand how card brands have a contractual link to merchants – but only rarely do with service providers. I’d find it virtually meaningless for the PCI requirement to mandate actions by the service provider, when they have no contracted responsibility to a commercial entity. That said, 12.8.4 places an obligation on the service provider to demonstrate compliance to their customer the merchant (or service provider, Acquirer etc).
Is not the combination of these 2 requirements having the same outcome?
March 30th, 2012 at 11:37 am
Thanks for the comment, Lyal. I am not sure I agree with your position on the “contractual link” part, though. Actually, service providers do have direct links to the card brands. For example, many have direct system connections/access points to the card networks. More importantly, all service providers validate their PCI compliance to the card brands. The brands (at least Visa and MasterCard) also post lists of compliant Level 1 Service Providers on their websites.
My point was not so much about the card brands, though. I was observing that since PCI already has a number of requirements that only apply only to Service Providers and not to merchants, there is precedent for one more Service-provider-only requirement to cure the imbalance I noted.
Then again, if all it takes to meet 12.8.2 is for the service provider to be PCI compliant, then all the PCI Council has to do is declare it in a FAQ or clarify the wording of the requirement.
I (and more importantly, retailers and other merchants!) could be happy either way. It is the present, one-sided nature of this specific requirement (12.8.2) that is disappointing.
April 5th, 2012 at 6:06 pm
Walt, I’d suggest that perhaps you have a limited concept of who would be considered a Service Provider under the guidelines that you’ve suggested. The fact is that most resellers/integrators do NOT have direct links to the card brands or the card networks. They may work with processors to board new merchants or provide support, but there is no contractual or legal obligation at all. Your comment that all service provides validate their PCI compliance is also way off base if you include resellers & integrators. The limited number of Level 1 Service Providers probably do validate their compliance, but the vast majority of resellers/integrators are not that big.
Lyal is correct that for most “service providers” (using your definition to include resellers/integrators) there is no contractual obligation or liability to an acquirer or a card brand. The only financial relationship is with the merchant. Adding your suggested line to the DSS won’t change that. In an ideal world it might encourage merchants to pursue the step further, but in reality it won’t happen. There is no incentive to the service provider and most (almost all) merchants won’t care to ask. If they do ask, and the service provider refuses to provide formal acknowledgment, the merchant has no options, short of completely replacing their POS system.
Regardless of precedent, there’s nothing that PCI can hold over most resellers/integrators and force them to accept liability. The only option would be to do follow the precedent of payment applications and begin validating and certifying resellers/integrators. But even that only works if the Acquirers actually verify the information. You’ll still have Heartland sales people who are willing to fudge numbers & board any merchant with a pulse. And you’ll still have the kid down the street who’s willing to setup a router from Walmart so the merchant can offer WIFI. All that would do is put legitimate resllers/integrators who are actually trying, out of business.