Since my goal is to make your arguments better, here are a few of my personal problems I have with the current PCI-Wars debate.  For those not familiar with logical reasoning, please read up on some of these fallacies.

The following is a list of unbalanced flaws in conversational logic that should be avoided when having a conversation with me about PCI.

1. Companies got hacked so PCI must not work

People like to point at recent data security breaches and claim that because companies have been compromised then of course the standard must not work.  Under the same logic if any company gets compromised then the entire information security industry must have somehow failed us.  People forget to remember that it’s all about: people, process, and technology, not just the industry standard.

2. The PCI DSS is all about “risk transference”

I have to restrain myself physically when people say those naughty two words.  Let’s take a walk down the life cycle of a fraudulent transaction for a moment, completely independent of PCI or compliance.

Merchant “A” accepts a fraudulent payment card and delivers the product to the client.  If a cardholder denies the charge, it’s a charge back and Merchant A must absorb the fraud.  (This is why merchants should maintain strong fraud reduction measures.) In the event of a CPP designation on Merchant “B”, the Issuer may apply for reimbursement from the compromised Merchant B.  To do so they need to apply, through the card brands and Acquiring bank, for reimbursement.  If Merchant B can cover the cost then they will pay for the fraud due to their losing data.  If Merchant B cannot cover the cost, then responsibility resides on their Acquiring bank to pay for the fraud.  In many instances it’s not the compromised merchant that pays for all the externalities resultant from lost or exposed payment card data.

So you can see, a compromised merchant is usually the last one to pay for fraud resulting from data that they lost.  They have always been responsible and PCI DSS does not change that in any way.  Instead, the PCI DSS serves as a metric by which the Acquiring banks can begin to measure their potential exposure to financial loss.

3. PCI compliance is all about making money for someone else

Whoa there cowboy!  Remember that the card brands, issuers, and acquirers all spend money on trying to keep merchants and service providers secure.  They put time, money, and resources into developing the program and educating others about it.

The participants: the QSAs, ASVs, infosec vendors, etc. all already existed before PCI ever came alone, they were just called “security consultants”, “Internet vulnerability scanners”, and “product vendors”.  Changing the name of a company doesn’t change the game.  Most merchants forget a small fact that every level of merchant is allowed to self assess if they wish.  Level 1 merchants can use their internal audit group or a QSA, and Levels 2-4 all use the Self-Assessment Questionnaire (SAQ).  The reason companies pay consultants to help them out is the same reason I hire an electrician to rewire my house.  They have experience with it.

I’ve got a deal for you.  You promise to never lose or expose payment card data then I’ll wave my hand and say “this isn’t the non-compliant company you are looking for.”

4. Credit card theft is part of identity theft

Pardon? Ok, in the metaphysical world where everyone sings coombyya then, yes, credit card theft is part of identity theft.  In that same world so is automobile theft, library card theft, and friends using your Costco membership.  I read recently that, “The Federal Trade Commission (FTC) estimates that 50 billion is lost annually due to identity theft and credit card fraud.”  Without context we have no way of understanding this number.  We need to define “identity theft” or else we should include the automobile theft statistics, because if someone steals your car and gets ticketed, isn’t that your identity as well?

Credit card theft has so little impact on the cardholders that almost every issuing bank waves the $50 service fee, and reissues a card within 7-10 days.  If someone steals my SSN, and uses it, the cost to me could take years of work to reverse.

5. PCI just enables checklist security

Yes, just like every other security checklist that ever came before it.  That’s like saying a wheel is only a tool.  Correct, but if that wheel is a racing tire and put on a Formula-1 car it can do good things.  If you hang that wheel on your front door hoping it will ward off evil, I suggest altering your philosophical beliefs.  Companies need to learn how to use the PCI DSS to enable security within their payment card environment and not follow it alone.

The problem occurs on the implementation side when companies with no prior security adopt the PCI DSS as their information security management system, which it was never designed to be (IMHO).  Companies must integrate the PCI DSS into their overall security framework and not use it to replace one.

6. A “compliant” company was compromised so the standard must not work

This is not true.  Please see also: compliance vs validation.  The Visa website provides a “Global List of PCI DSS Validated Service Providers“.  I don’t see the word compliant in there once.  In fact, if we open the PDF and read the first sentence it says, “The companies listed below were validated as being PCI DSS compliant by a QSA as of the ‘VALIDATION DATE’.”  What this means is that a company validated they were compliant one day of the year.  What that company does the other 364 days of the year is an unknown, until the forensic investigation team shows up.

7. Merchants are required to maintain the PAN

Ugh… In late 2007 60 Minutes did a broadcast that contained some misinformation.  One of the people being interviewed claimed that the credit card brands require companies to store the Primary Account Number (PAN), one of the basic elements in authorizing credit card transactions.  I know one person who had to restrain himself from throwing things at his TV after hearing this.  The payment card brands (i.e. Visa) had long since changed their rules and do not require merchants to retain the PAN after authorization and settlement of transactions.  This informaiton has not been widely disseminated to the pupulation.

Regarless, this is still a weak argument, since we know that the vast majority of payment card fraud has nothing to do with just the PAN, but instead the resale and illegal use of sensitive authentication data (track data, CVV2, PIN block).  And this, everyone universally agrees, should not be retained or available to hackers.

8. PCI is reactionary and not preventative

The PCI SSC has stated they will update the PCI standards on a 2-year basis.  When updating these standard, I assume, they will use data breach information and feedback from the industry itself to keep the document as up-to-date and usefull as possible.  When we saw web-application data breaches on the rise, the PCI DSS was updated to include Requirement 6.6 which helped address the problem.

Only by understanding the patterns of attack can be better help companies repel these forces.

Please also remember that the PCI SSC is contributed to by the Participating Organizations who provide feedback on a regular basis.  If you want to get involved then join as a member.

9. PCI is too much! or PCI sucks!

Let’s all chant together, “Tastes great! Less filling!”  Most people get less 5th grade about it and say, “PCI is too specific” and others say, “PCI is too vague”, while still other cynics claim, “… no, it’s specifically vague!”  Wrong, wrong, wrong.  If PCI is too much then why don’t you just secure your data and call it a day.  If your security foo is so good then validate as such.  Also, remember #5.

Jack Daniel said it this way, “PCI sucks. But it sucks less than doing nothing, which is the normal alternative. Real security would be better. So would unicorns.”  If PCI is painful then I begin to wonder why.  Perhaps you don’t fully understand the scope, intent of requirements, or how to best secure your infrastructure?  Perhaps you understand all these but still cannot achieve compliance due to a flat network topology or other scope issues.  This is when I remind you that the overall intent of the PCI DSS is to prevent the paper and electronic theft of payment card data.  If you can understand and achieve this, then it’s all you need.

10. PCI is not enough!

To this I agree, but not that we need more regulation or more security products.  I think people need to expand their insight into the intent behind the requirements and the standard itself.  In the last paragraph I stated that meeting the intent facilitates compliance.  Let’s take this to the next logical conclusion.

While many security people are happy to help you “carpet bomb security” by securing every system to the 9’s, why don’t we start talking about scope reduction and eliminating systems from scope.  The PCI Answers blog lists for us several product vendors that support end-to-end encryption.  Other people have begun creative ways to remove data from scope instead of securing it.

By removing data from scope, and finding more creative ways of securing the data we do store, we are going well beyond simple compliance into the realm of sound security practices.  The PCI DSS exists as a minimum bar to which those who have little security in place can aspire.