Will The PCI Council Show A Little Mercy To Retailers This Week?

Written by Walter Conway
September 11th, 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.

Expectations are high for the upcoming PCI Community Meeting. In addition to hearing the latest on mobile commerce and point-to-point encryption (P2PE), this is a feedback year. That means this is the meeting when the PCI Council and the card brands respond to the comments and suggestions offered by participating organizations (POs) and assessors. Based on the information provided by the PCI Council, it is listening. The next step is to hear its responses.

Here is how I hope the Council will respond to the feedback on PCI DSS version 2.0.

PCI DSS, along with the companion standard PA-DSS, has a three-year lifecycle. This year, the second year of PCI DSS and PA-DSS v2.0, the PCI Council asked every PO, qualified security assessor (QSA) firm and approved scanning vendor (ASV) firm to provide feedback based on their experience with the current versions of both standards.

I’ll focus on PCI DSS, because that standard has the most immediate impact on retailers and other merchants and service providers.

The Council established its listening credentials. It provided POs with a 66-page document detailing every single comment submitted, together with the disposition of that comment. It makes for some interesting reading. If you haven’t seen the document, get a copy from your principal contact. If you are not a PO, maybe this is another reason you should be: PCI DSS impacts your business, so you might want to have a seat at the table.

The Council summarized the feedback in a press release. Based on that release, here are the six feedback areas it is committing to consider, together with some thoughts on what I hope the Council will say.

The first area is PCI DSS Requirement 11.2, which addresses vulnerability scanning. Suggestions include prescribing use of specific tools, requiring ASVs to perform internal scans and defining what constitutes a “significant change.” I personally doubt the Council will—or should—recommend a particular tool or product, so don’t expect too much on that front. As for what constitutes a “significant change,” that currently includes things like reconfiguring your network, installing new network devices or adding new payment applications. I don’t know how much more specific the Council can be without being overly prescriptive.

Remember that although PCI DSS may be a prescriptive standard in many ways, the standard is full of requirements that call for judgment and a thoughtful risk-based approach to give merchants and service providers flexibility. If you don’t like flexibility, you’ll hate the alternative.

The second feedback area is clarifying the definition of PCI DSS scope. I’ve addressed scoping in an earlier column, so there is not too much to add. Hopefully, the Council can resolve this question and move on to critically important areas such as mobile commerce and P2PE.

The third feedback area highlights an issue that, in this QSA’s opinion, too many merchants take too lightly: PCI DSS Requirement 12.8. This requirement addresses how merchants manage service providers. The feedback asked for clarification on two areas: What constitutes a “service provider”; and what is required in written agreements that apply to service providers.

The first part of this one surprised me. I don’t get what is unclear about “any entity that can affect the security of the transaction.” However, I am happy this area made the list because of the request to clarify what details must be in the service provider’s agreement with the merchant.

I don’t think there is any need to change the current requirement. It is fine as it is. The problem is the lack of a corresponding service provider requirement to agree to the contract language mandated by Requirement 12.8.2. As I’ve written before, the simplest way to fix this is to make providing that language a condition of the service provider’s own PCI DSS validation.

The difficulty is that Requirement 12.8.2 is asymmetric.


Comments are closed.


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

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...

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.