advertisement
advertisement

How About A Little Service Provider Responsibility Here, PCI-Wise?

Written by Walter Conway
March 29th, 2012

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

Among all of the PCI requirements, there is one that reflects a fundamental imbalance. That requirement is 12.8.2, which requires all merchants to: “Maintain a written agreement that includes an acknowledgement that the service providers are responsible for the security of cardholder data the service providers possess.” This is a great requirement, but it places the entire burden on the merchant. Where is the corresponding requirement that a service provider actually agrees to deliver that written acknowledgement?

This situation can be addressed with one simple change to 12.8.2. It would apply to service providers only. The change is to add wording that requires service providers to deliver this “acknowledgement” in writing to their customers.

Have more PCI phrasings you want changed? You now have your chance. The good news is that you still have time, although not much. Participating Organizations now have until April 15 to submit up to five ideas for improving PCI DSS (as well as PA-DSS). Therefore, your first step is to speak to the PCI contact within your company and see what feedback she/he is preparing.

Depending on what you learn, you may want to consider the following suggestions. I’ve based them on issues I see at retailers and other merchants. I hope the suggestions stimulate some thinking about what changes retailers want and need to see in the upcoming revisions to PCI.

Participating Organizations can make as many as five comments. The comments may:

  • Request clarification of a particular PCI requirement or testing procedure.
  • Request additional guidance on how to meet a requirement.
  • Suggest a change to an existing requirement or testing procedure.
  • Offer a completely new PCI requirement.
  • Provide feedback to the PCI Council on just about any topic without necessarily requesting any changes.

Let’s take them one at a time.

My nominee for requesting clarification is: At what point does a system reseller or integrator become a PCI service provider? I’ve written about how PCI pretty much ignores system resellers and integrators, even though they play a crucial role in many retailers’ POS implementations. In many cases, the reseller/integrator’s work includes configuring firewalls, changing default passwords and other security-related functions. When they do this, a retailer (or their QSA) could view the reseller/integrator as a PCI service provider, because their actions directly affect the security of each transaction.


advertisement

3 Comments | Read How About A Little Service Provider Responsibility Here, PCI-Wise?

  1. lyal collins Says:

    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?

  2. Walt Conway Says:

    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.

  3. Nathan Says:

    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.

Leave a Reply

Readers, specifically those who want to comment on a story:
Our Comment SPAM system is getting very aggressive these days and has been blocking legitimate comments. If you post a comment and don't see it appear within 2 hours or so, can you please send a heads-up to customer-service@storefrontbacktalk.com? Ideally, please include the time you posted the comment. That will allow us to try and hunt for it. Thanks! P.S. We're working on fixing the system, but we don't want to lose any valuable comments in the meantime.

Newsletters

StorefrontBacktalk delivers the latest retail technology news & analysis. Join more than 17,000 retail IT leaders who subscribe to our free weekly email. Sign up today!
advertisement

Most Recent Comments

Why Did Gonzales Hackers Like European Cards So Much Better?

I am still unclear about the core point here-- why higher value of European cards. Supply and demand, yes, makes sense. But the fact that the cards were chip and pin (EMV) should make them less valuable because that demonstrably reduces the ability to use them fraudulently. Did the author mean that the chip and pin cards could be used in a country where EMV is not implemented--the US--and this mis-match make it easier to us them since the issuing banks may not have as robust anti-fraud controls as non-EMV banks because they assumed EMV would do the fraud prevention for them Read more...
Two possible reasons that I can think of and have seen in the past - 1) 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. 2) Also, in offline chip countries the card determines whether or not a transaction is approved, not the issuer. In my experience, European issuers haven't developed the same checks on authorization requests as US issuers. So, these cards might be more valuable because they are more likely to get approved. Read more...
A smart card slot in terminals doesn't mean there is a reader or that the reader is activated. Then, activated reader or not, the U.S. processors don't have apps certified or ready to load into those terminals to accept and process smart card transactions just yet. Don't get your card(t) before the terminal (horse). Read more...
The marketplace does speak. More fraud capacity translates to higher value for the stolen data. Because nearly 100% of all US transactions are authorized online in real time, we have less fraud regardless of whether the card is Magstripe only or chip and PIn. Hence, $10 prices for US cards vs $25 for the European counterparts. Read more...
@David True. The European cards have both an EMV chip AND a mag stripe. Europeans may generally use the chip for their transactions, but the insecure stripe remains vulnerable to skimming, whether it be from a false front on an ATM or a dishonest waiter with a handheld skimmer. If their stripe is skimmed, the track data can still be cloned and used fraudulently in the United States. If European banks only detect fraud from 9-5 GMT, that might explain why American criminals prefer them over American bank issued cards, who have fraud detection in place 24x7. Read more...

StorefrontBacktalk
Our apologies. Due to legal and security copyright issues, we can't facilitate the printing of Premium Content. If you absolutely need a hard copy, please contact customer service.