Prepare Ye List Of PCI Grievances

Written by David Taylor
September 16th, 2009

Columnist David Taylor is the Founder of the PCI Knowledge Base and former E-Commerce and Security analyst with Gartner.

Depending on your perspective, the upcoming Community Meeting of the PCI SSC members is a “chance to provide feedback” or a place to “share ideas” regarding the standards or “Whinefest 2009.” I’m taking a perspective that dates back to the founding fathers and preparing a “List of Grievances.”

  • We Hold These Truths To Be Self-Evident
    The U.S. Declaration of Independence includes a List of Grievances against King George of England. Apparently, putting together the list got the Continental Congress so riled up that they decided to make themselves a whole new country. But I’m not expecting anything that dramatic out of the PCI SSC Community Meeting. Although there are “pseudo-secessionist” groups, such as the Merchant Advisory Group, most of the following comments (which are taken from the anonymous interviews that are the cornerstone of our research) are meant to be constructive rather than revolutionary.

    (Editor’s Note: Would strongly suggest that you peek at the comments for this story. At times, that debate is almost–forgive me, David–more interesting than the column.)

  • What We Have Here Is A Failure To Communicate
    “There is little guidance from the PCI SSC or the card brands or the banks when it comes to interpretation of key standards.” A related grievance is that when guidance is given, it’s usually specific to a given situation via a private communication to a QSA. Not only are merchants and service providers unhappy about this, so too are the QSAs, who complain that it takes months to get any kind of meaningful ruling from the SSC or the card brands or the compliance officer of an acquiring bank. The real issue here is that “guidance = liability,” which necessitates a detailed review process for all “official” guidance, vaguely worded E-mails and pushing guidance back onto the QSAs, who pretty much get blamed for everything (or so they tell me).

  • The Standards Are Designed For A Bygone Era Of Technology
    “PCI compliance has effectively limited our deployment of virtualization, cloud computing SaaS (software as a service) and other technologies designed to help us maximize the value of our IT investment.” Even though there are committees among the SSC community members looking at some of these issues, the task is tied to the process of adapting the “letter of the law” in the standards and designing a way of validating compliance with a set of standards that make “data ownership assumptions” that are fundamentally inconsistent with the SaaS and resource virtualization models.

  • The Standards Are Not Standard
    “How can the card brands call what they are doing a standard, when they don’t standardize the enforcement process?” Many merchants and service providers complain that PCI DSS is functioning more like another ‘layer’ of requirements than an industry standard. This grievance is more common since the MasterCard “schism” that forces Level 1 and Level 2 merchants to use a QSA. But it’s been around since the beginning. Having the PCI SSC represent a bunch of guidelines that they call standards while each brand has whole separate lists of things they demand from merchants, service providers, banks and processors is more than a semantic issue.

  • advertisement

    14 Comments | Read Prepare Ye List Of PCI Grievances

    1. Bryan Johnson Says:

      David – you’ve put together a good list. I agree that the grievances should not result in the abandonment of PCI, but that the industry needs to keep up and look at the current PCI DSS as a basis for continually striving to stay ahead of the those intent on stealing the data.

    2. Dave Taylor Says:

      Bryan, thanks for the feedback. Last week I wrote a real “pro PCI” column, so I wanted to make sure folks know that our research discussions really run the gamut. But, for me, the bottom line is, as you say, focused on the improvement in the standards to keep them current, and ahead of the criminals who would seek to do harm.
      thx, Dave

    3. Mark Pinkerton Says:


      We have clients here in the UK who have had to get to Level 1 compliance for a website making 60k transactions a year, simply because of the size of the rest of the organisation. This caused enormous problems and costs that were disproportiate to the size of the web business.
      BTW The banks are also using threatening noises to several clients (with seriously large debt – AKA overdraft facilities) that unless they fully implement 3D secure and or PCI that their debt finance will be under threat.
      3D secure costs most of our clients more in terms of lost business than the fraid levels prior to implementation. It only safeguards the banks who have done little or nothing to promote it in the UK.

    4. Dave Taylor Says:

      that’s amazing – tying PCI compliance and 3D Secure implementation to debt re-financing. Somehow, it don’t think that’s in keeping with the spirit of PCI. Or, here’s the scary part: Maybe it is!!
      I appreciate the comment.

    5. David W. Says:

      The biggest problem associated with PCI is not standards or technology. It’s approach. PCI compliance isn’t a patch or a product. It’s a business process overhaul. The world has changed – credit card data is a high-value target because it is readily convertible into good, services, and ultimately cash. Cardholder data is like a rash on corporate systems. As the rash spreads, so does the risk of compromise, the scope of the compliance effort, and the cost. Instead of seeking compliance, companies should be revamping processes to eliminate cardholder data storage.

      Trust me, IT isn’t storing cardholder data because they can get .10 per meg or gig for storage. They’re storing it because a business owner required it. However the PCI DSS smells like IT Security, and most companies unfortunately pigeon-hole it in IT. As a result, they get an IT solution: overlay (expensive) products and services onto obsolete business processes to make them complaint. The real solution lies in revamping processes to reduce or eliminate the cardholder data footprint, reducing risk, scope, and cost.

    6. Dave Taylor Says:

      I agree with your point in terms of the need to revamp processes to eliminate the card data footprint. I also have a question for you and anyone else reading this: To what extent is “Data Mining” and the desire to keep as much customer data as possible continuing to be an argument to keep card data, or is the need to retain this data purely a “legacy system” issue?
      thx, Dave T

    7. David W. Says:

      Dave Taylor:

      I would think that a better unique identifier could be found/established for the customer than credit card for a couple of reasons. First, Cardholder numbers change. Second, I’ve got 4 cards in my wallet right now. I would think a merchant would want to track me by my purchases across all 4 cards.

      Each company has to make business (and risk acceptance) decisions rgarding PCI. It may decide the risks of retaining the card and the costs of compliance are outweighed by the ability facilitate a transaction. It may also be necessary from a business perspective – think recurring billing for an e-commerce subscription. In such cases, you look at reducing the footprint since you can;t elimiante it.

      The point here is that merchants need to udnerstand that the solution to their PCI compliance equation is as unique as they are, and put all the options on the table – technology AND business process – to arrive at the best possible answer for them.

    8. David W. Says:

      Dave T Followup:

      I did want to make on other point regarding data retention. I worked with a merchant whose reason for retaining cardholder data was “chargebacks”. They had to retain the CHD to defend chargebacks. We attacked the process first. We went to the acquirer, and examined what it takes to successfully defend a chargeback. Lo and behold, not having the CHD would impact them, but not make it impossible. Next we looked at cost of compliance vs. cost of losing chargebacks previously won (because the ones they lost would be lost anyway). There was plenty of historical data for that – literally years – trending and everything. The cost of losing chargebacks normally won was about 1/10 of 1% of their compliance cost. It was a no-brainer to adopt a modified chargeback defense process and quit storing CHD. I know it’s not that easy for everyone. But the point is this merchant looked at all the factors, and made an informed decision.

    9. Cranston Snoard Says:

      “Compliance Gamesmanship Works Better Than Risk Management — With more than 230 controls that have to be met 100 percent of the time, there’s no way we’d be compliant if we were strict about this, so we’ve learned how to play the PCI game.”

      Which again proves how useless PCI DSS really is. A process everyone tries to circumvent or marginalize is a wasted effort. If a firm implemented other business controls that were treated in this light, it would show up in a Dilbert cartoon — but because it is the PCI SSC and the brands dictating it, everyone bows to it and is afraid to call it out for the dumb process it is. A stupid process is a stupid process, regardless of who dictates it – and PCI DSS is one of them.

      And even if you are deemed compliant, if there is a breach that goes beyond (such as the recent events), you are still on the hook. It’s like being forced to buy fire insurance, told you must install a specific manufacturer’s device to detect and suppress fires for the insurance to be valid, and then when a fire does occur because the specific system you were forced to purchase doesn’t work and actually starts the fire, you are told your insurance is null and void for not following the rules.

      As to inconsistencies in PCI DSS — does anyone seriously expect the “standards” or their application to be consistent when the SAQ can’t even use a consistent numbering scheme? Or delves into useless specifics on certain articles and then is amazingly vague on others?

    10. A reader Says:

      To preface my complaint, retailers and processors shouldn’t have access to the data at all, ever. It should be encrypted on customer-held smart cards using keys held and maintained by the banks, and transmitted encrypted throughout the merchant, authorization and settlement chains. The retailers should never have access to the valuable cleartext data — it should be fully protected before it’s entrusted with the likes of us. That’s cryptography 101. But since neither the banks nor the PCI are stepping up to the plate with a secure product, we’re stuck with using PCI DSS to try to defend their leaky buckets.

      So my #1 grievance with the standard as-is: a lack of prescriptive standards for encryption. By the use of weasel words such as “strongly encrypt” or “adequately protect”, the PCI put no skin in the game and did not produce an actual functional specification. They left that up to a conglomeration of six million retailers, about a thousand of which have people experienced enough to know they are not professional cryptographers and needed to bring in outside help. Most of the other 5,999,000 organizations can barely spell AES, they don’t know what encryption is, and simply hope that their POS vendors do. And of those POS vendors, few offer solutions that are actually cryptographically secure, with most solutions amounting to handwaving and (mis)placed trust in OS security. Worst off are those organizations that have a programmer who once read a Bruce Schneier book and tried to protect the data themselves.

      This lack of knowledge extends to the PCI auditors, too. They see a line on a chart labeled “AES-256” and look at a key management form, then check a box labeled “Encryption – YES”. No offense, David, but I seriously doubt that half of the PCI auditing firms have competent cryptographers on staff who are qualified to review the encryption or key management protocols they approve.

      Strong encryption is the easy part. Anyone can pick a good algorithm, as long as a snake-oil salesman isn’t pushing a “holistic” alternative. But creating and using secure encryption protocols is so very, very hard that even the civilian professionals almost never get it right the first time. By contrast, PCI DSS today is a hope that six million amateurs get it right every time. No wonder Visa won’t raise a finger to defend us.

      The PCI should have invested the money up front once for all of us, and published a complete protocol for cardholder data protection. (Remember SET? Good starting point.) From bank to customer to merchant to processor, each entry and exit point should have clear delineation as to what the data should look like, what the algorithms and key sizes should be, how it should be encrypted, who should own the keys and data, how the packets should be signed; and the PCI should provide a suite of test vectors, sample cards, and validation programs that each merchant, processor and bank can run to prove compliance.

      The introduction of PCI was the chance to create a unified solid foundation. Instead, we now have organizations that encrypt the data here, decrypt it there, send it over here, change the keys in this box, put it in this SSL tunnel, patch some IPSec over this tube, stand a guard dog in front of this server, etc., etc., etc. Repeat six million times, and you have six million retailers who spent a whole lot of money on a patchwork quilt of security; and while we’re all quibbling over which patches are the most crooked, the real problem is we’re arguing about a security blanket instead of building a concrete and steel vault!

      The most shameful part of this wasted effort is that even if PCI comes out with a perfectly secure prescriptive DSS encryption standard today, you’ll have the same six million retailers crying “foul! We just did what you told us to last year, we’re not changing again now just because you think you got it right this time!” Your big chance came years ago, but that bird has flown. The time has come to completely move it out of our hands and back into the banks. At least they understand security.

    11. Dave Taylor Says:

      Mr/Ms Reader,
      I think your points (and Cranston’s, which appear above yours) are all excellent. As for the “no offense” comment, i also agree that most QSAs do not have sufficient background in cryptography to evaluate the effectiveness of encryption algorithms or, more importantly, key management systems. Most security folks, for that matter, come from the networking world, and there’s not a lot of shared understanding between network security folks and DBAs. I’ve seen this up close & personal when I was a consultant specializing in encryption & key mgmt for PCI. I think we would all like to see some substantial changes to PCI DSS. But, more importantly, to the structure of the card data management process. We’ll hopefully learn some useful things at the PCI SSC Community Meeting next week – maybe the recommendations from the PWC study on tokenization, E2E encryption and EMV. We’ll see.
      thx, Dave

    12. Cranston Snoard Says:

      Perhaps someone who is attending the Community Meeting of the PCI SSC (I am not part of a participating organization, and somehow I suspect PCI SSC wouldn’t want me there anyways!) can ask the powers that be why something so simple as the Prioritized Approach Toolkit can be so friggin’ messed up.

      Not only does most of the wording in the description columns not match the corresponding SAQ articles, the break-out of articles does not match the SAQ either Again, the numbering scheme and the collapsing together of certain articles is inconsistent and makes no sense.

      And whoever set it up must be a rank amateur at EXCEL spreadsheets — the cell formating is inconsistent (under the Comments column, some cells are centered text, others are right or left justified…), some rows are not high enough to display all of the text within them… and the “freeze” point for column scrolling is rather interesting…

      Then again, this sloppiness is consistent with the usefulness of PCI DSS…

      I use a spreadsheet that breaks out all 230 (whatever the count is this week!) articles and sub-articles of the requirements. With colour coding, I can tell at an instant if an article is compliant or not… but I can also quickly tell if it is because all of the sub–articles are non-compliant or if there is only 1 sub-article remaining. That to me gives a better understanding of where I stand with each set of requirements and their sub-articles.

      The current toolkit provided by PCI SSC is amateurish at best, and does not provide a reasonable representation of one’s efforts or compliance status.

    13. A Mercahnt Says:

      As a Merchant we have made the decision of “store no CHD at all”. Every comment in this article hits the right points. The standard is not a standard it is a blame tool. Companies spend more time playing the PCI game for compliance than acutally spending securing their systems, i.e. compliance spending is outwaying security spending. If we have no card holder data then do we need to worry about PCI? End to end, tokens, etc. what ever removes CHD from my environment, that is where we are going. No data, no disputes, no fines.

    14. Just-a-Reader Says:

      Back to Basics…. with Cash and Checks. No Card, No Data, No Disputes, No Fines, No Bad Reporting, No Under Scoring, No Thefts, No Stealing . Just Cash or Check N Carry and everybody be Happy


    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.