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.
Good writeup! One small thing though. The Visa web site admins aren’t very good at keeping up with the CISP team. “PCI DDS” was in there for quite a while. It wasn’t until January this year that they updated the payment app security mandates to clarify that PA-DSS compliance is what’s required, not validation (For obvious reasons). It’s only in the last month or two, after RBS Lynk and Heartland that Visa changed the wording on service providers to say validated instead of compliant. That mistake has always been a pet peeve of mine since it contradicts compliant vs validated preaching. Check out the wayback machine (http://web.archive.org/web/20080126112739/http://usa.visa.com/merchants/risk_management/cisp_service_providers.html) or even the name of the pdf doc itself (cisp-list-of-pcidss-compliant-service-providers.pdf).
“The PCI DSS is all about “risk transference”
I have to restrain myself physically when people say those naughty two words.”
Exactly! Me too! Me too!! I want to also remind them that risk needs to be transferred to the party responsible – which, in a conservative 99% of cases :-), is the merchant…
What’s up with everybody’s PCI myths being the same? http://www.slideshare.net/anton_chuvakin/pci-dss-myths-mistakes-misconceptions-2009-teaser-version-1171140
In addition to Lucas’ point, the list of service providers MasterCard publishes, also says ‘compliant’.
With astonishment, I have read the following argument of yours:
“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).”
Of course Level 1’s can self-assess, so can my grandmother, but they also have to get in a QSA for validation! If not, please show me where that is written.
If the acquirer agrees to the request of the merchant to self validate:
http://usa.visa.com/merchants/risk_management/cisp_merchants.html
Level 1 Merchants
The Annual On-Site PCI Data Security Assessment must be completed for Level 1 merchants according to the PCI Requirements and Security Assessment Procedures v1.2 document. This document is also to be used as the template for the Report on Compliance.
Level 1 merchants should engage a Qualified Security Assessor to complete the Report on Compliance and provide the report to their acquirer. Alternatively, acquirers may elect to accept the Report on Compliance from a Level 1 merchant, provided that a letter signed by a merchant officer accompanies the report. Level 1 merchants must also submit the Attestation of Compliance for Onsite Assessments – Merchants form completed by their assessor to their acquirers. The Attestation of Compliance for Onsite Assessments – Merchants can be found in the PCI Requirements and Security Assessment Procedures v1.2 document.
Acquirers must submit the Attestation of Compliance for Onsite Assessments – Merchants form and a letter accepting the merchant’s full compliance validation to Visa upon receipt and acceptance of the merchant’s validation documentation.
Download the PCI Data Security Standard v1.2.
Download the Attestation of Compliance for Onsite Assessments – Merchants.
Good to see you back on the blog scene again!
BTW, what happened with you and Aegenis?
Anton, yes, many of us preach the same thing over and over. One of the thins I’ve been considering is that we have reached critical mass with getting people on-board with payments security. I believe the remaining people are those who have heard the warning signs and disregarded them.
What I’d like to work on next is helping people ask better questions about payments security. I think we focus so much on the answers that we don’t ask if we are asking the right questions.
After almost 4 years of fielding questions, I have a list of them in my head that come up over and over. In fact you only need to get the questions for a few months before you see them repeat. In fact, I believe most people are asking the wrong questions and then debating the answers, which at that point are potentially irrelevant.
“One of the thins I’ve been considering is that we have reached critical mass with getting people on-board with payments security.”
God no. Nowhere near reached it, if you look at smaller orgs.
“What I’d like to work on next is helping people ask better questions about payments security.”
Definitely! I just had a freak-out recently over “PCI is toothless.” For fuck’s sake, you are not doing PCI because of some teeth, but to secure your data!!!
“After almost 4 years of fielding questions, I have a list of them in my head that come up over and over. ”
Mike, you need to …uh… write a book on it or something 🙂 Sorry! 🙁
Pingback: Chaordic Mind » Personal Responsibility in PCI