Chaordic Mind

When a situation is not risky, there is little need to manage or measure the risk involved.  This applies equally to lending money to friends, reading utility meters, and until a few years ago, handling credit card transactions.  With the growing risk to financial transactions there is a need to improve the ways acquiring banks, processors, gateways, and even merchants manage and measure their risk.

In fact, prior to the PCI DSS the metrics involved in measuring the risk in an acquiring bank’s merchant portfolio were rather basic.  You look at the number of transactions per month and categorize the merchants into business categories.  One would say that online gambling would be riskier than grocery stores.  The logic seemed flawless, at least for the environment at the time.

Unfortunately the environment changed and hackers turned from fame and glory seekers to those wanting large financial payoffs from their prowess.  They began attacking merchants and even banks by finding the low-hanging-fruit never imagined by the industry.  The hackers began targeting:

• POS systems directly connected to the Internet with weak remote access methods
• Weak or insecure wireless located at physical stores
• Insecurities in partner and vendor connections to companies
• Insecure web application software

The hackers identified, by brute force, holes in the security of an industry that were never imagined by those creating the metric for managing their risk.  When the compromises reached a tipping point, the industry began to shift the focus to security.  The banks and card brands formed the PCI Security Standards Council (PCI SSC or Council) in 2006 and invited merchants, POS vendors, and other industry experts to participate (as Participating Organizations.)

In order to realize the importance of this change you have to first understand that people do things based on incentives, and for most companies security is not something they are very willing spend money on.  This can be seen in the ever increasing number of data breaches that occur every day.  Anyone who has had teenagers can tell you that in order to “encourage” a person to do the right thing you need to properly incent them.  Regulatory compliance has been the thing that has incented companies to place an importance on information security for the last 10 years, and PCI DSS compliance has been the leading force for the last three years.

This might pass over as just another regulatory issue like GLBA or SOX if not for the fact that it’s not specific to a business vertical.  The payments industry is sometimes called a “horizontal” because it cuts across so many areas such as banking an finance, travel and entertainment, health care, power and energy, etc.  In fact PCI DSS is the first globally enforced, industry regulated, cross-industry compliance program.  It’s goal is simple: prevent the electronic and paper theft of payment card data.

But why?  Don’t you like it when we ask why?  The reason was not to do this because it’s the right thing.  We all like to say we are acting “green” by composting when really it’s just a way of reducing the cost of our garbage bill.  We want to prevent the loss of this data because someone is paying for the fraud: other merchants, acquiring banks, and many more.

So, we begin to understand that acquiring banks use the binary aspect of PCI DSS compliance as a measuring stick to determine the risk within their merchant portfolio.  Sure there are still the number of transactions, type of business, and size of the organization, but now there is the check box of security.  What does this really mean in practical terms?

Well, of all the PCI DSS requirements, the most important by all accounts is 3.2 which mandates that sensitive authentication data should not be retained post-authorization.  The other requirements for security act to protect this data from being intercepted in the first place.  The end result is that hackers should never have any access to this sensitive authentication data.

OK, so the standard exists to protect the super secret data so banks can measure how risky their merchants are to them.  This acts much like the credit rating agencies such as Moody’s and Standard & Poors.  The question is, “Are the current  metrics sufficient for measuring risk in a merchant portfolio?”

I would argue that, much like the credit rating that says “AAA”, the PCI DSS is only one part of the holistic approach merchant banks should take to measuring risk within their portfolio.  Think back to the collateralized debt obligation (CDO) market that just exploded.  People were packaging mortgages together into one security that people could then trade against.  The problem is understanding the impact that all those thousands of mortgages and the people behind them will have on the value of that one security.

In a similar way, banks need to look at PCI DSS as just one factor in analyzing the risk to their portfolio.  I’d argue that to keep the model working one should look to the Verizon Data Breach report and analyze attack vectors to determine what areas should be measured.

If we look at the data breach landscape we see the following numbers:

• 74% resulted from external sources
• 20% were caused by insiders
• 32% implicated business partners
• 39% involved multiple parties

The metrics companies and banks should use for measuring risk should include:

• Third Parties and the data they share (all three types)
• Deployment of a wireless network (proximity to acceptance channels such as POS)
• Number and size of business processes (POS network, databases, applications)
• Connected business units (call center, data warehouse, or physically insecure locations)

Individual merchants need to prioritize attack vectors.  If we know that more hacking events occur due to weak passwords or default passwords we should focus on eliminating things like “<blank>” or “password” or “<vendor name>” rather than focusing on achieving 7 character, alpha-numeric ones (which for the record are no better than 5 character ones in theory.)

I argue that we need more focus on attack vector trending threat models for regulatory compliance before we focus on the broad spectrum of security best practices.

Recently, Brandon Williams alerted many of us that MasterCard Worldwide adjusted its validation criteria for Level 2 merchants.  Both Visa and MasterCard, the industry leaders in global market share for locations payment-cards are accepted, had a validation criteria that matched this:

• Level 1 Merchants must validate using an external Qualified Security Assessor (QSA)*
• Level 2-3 Merchants must validate using an internal Self-Assessment Questionnaire (SAQ)
• Level 4 Merchants have no validation criteria at this time (though they must still comply like all other levels)

(* The well trained eye will counter that Visa permits L1 Merchants to self-assess but this was only with permission from the Acquiring bank and has been removed from the Visa website.)

Recently, MasterCard changed their validation criteria to reflect a stricter stance on the matter.  They noted that “All Level 1 and Level 2 merchants must use a PCI SSC certified Qualified Security Assessor for an onsite assessment.” Since most merchants that accept MasterCard also accept Visa, one can assume that (almost) all Level 2 Merchants must hire an external QSA.

The number of Level 1-4 merchants varies and there’s no real numbers that I know of that can peg the market precisely, as merchants are always growing and changing.  That being said, it is generally assumed to have the following break down (within the United States only)

• Level 1: 300-500
• Level 2: 1,500-2,000
• Level 3: 3,000-5,000
• Level 4: 4.7-4.8m

(The numbers are entirely different for other global regions such as Europe, South America, Canada, Asia, etc.)

If we look at these numbers one can assume that currently 300-500 merchants are required to engage an external QSA annually to perform their PCI DSS audit.  If we group Level 2 merchants into this fold we would have 2,000-2,500 merchants annually that require this level of scrutiny.

Or as Anton Chuvakin put it, “Obviously, awesome news for security!Now folks who are hell-bent on not having any concerns for customer data will need to deceive an actual live QSA rather than simply lie on their SAQ…”

If we assume that many Level 2 merchants are already engaging QSAs to assist them on their projects, we still see a market size increase of anywhere from 2-4 times for the QSAs.

I’d generally agree with Anton, and Branden Williams who says, “Level 2 merchants are extremely significant in size, many of which being household names. Unfortunately, PCI self-assessments are typically poorly handled simply due to the complexity of the standard and lack of training provided to those individuals performing the assessment.”

Sure the number of QSA companies is increasing, but I’m actually more concerned about the currently overworked assessors having their workload added to.  Martin McKeay notes the following: “I’m hoping that the quality of the assessors doesn’t fall because of the huge influx of QSA’s we’re needing to handle the work”

I will continue to push for a higher quality of work within the industry.  I know there are a number of people out there who are doing some very quality work, but I want to take this chance to push for higher quality, not higher levels of security.

In a recent presentation from Peter Tippet of Verizon Business (ICSA Labs), he talked about the different between aiming for perfect security and better “synergistic” security.  Instead of trying to make a seat belt 3% better for 300% of the cost, we add airbags to a car that makes it 40% safer for only 10% additional cost.  Let’s start thinking smarter not harder.

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.