Prepare Ye List Of PCI Grievances
Written by David TaylorSeptember 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.”
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.)
“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).
“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.
“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.
-Marc
September 16th, 2009 at 3:14 pm
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.
September 16th, 2009 at 3:56 pm
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
September 17th, 2009 at 6:13 am
David
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.
September 17th, 2009 at 8:36 am
Mark,
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.
Dave
September 17th, 2009 at 8:56 am
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.
September 17th, 2009 at 9:18 am
David,
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
September 17th, 2009 at 10:30 am
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.
September 17th, 2009 at 10:43 am
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.
September 17th, 2009 at 3:14 pm
“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?
September 18th, 2009 at 12:56 am
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.
September 18th, 2009 at 9:01 am
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
September 20th, 2009 at 8:08 pm
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.
September 24th, 2009 at 7:44 am
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.
October 15th, 2009 at 11:00 am
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