Chaordic Mind

History and Background

I’ve been deeply involved in the creation and maintenance of the PCI standards and framework since their initial inception.  Not only did I perform one of the first CISP assessments, I also wrote the framework for what is now the PA-DSS and performed the first PABP assessment ever.

I’ve been more than an implementer.

For a few years I trained all Qualified Security Assessors (QSAs) globally, and trained thousands of merchants, processors, and acquirers globally.  This experience taught me more than I could ever have hoped for because it instilled in me a deep understanding of the complexities within what we commonly refer to as the payment card industry (PCI).

Payments are complex, organic, and sometimes legacy systems that are complex enough in the US when you consider the various acceptance channels, networks for credit vs debit, payment channels, issuers/acquirers, payment gateways, point of sale software, third-party processors, and millions of merchants that vary in size from 5 transactions per year to 500 million.

Now take that and multiply it by a few hundred since each country has their own nuance issues.  These include everything from a single-acquirer model in Central and South America to the multi-acquirer models in Spain, Italy, and other European countries.  In S. Korea you use your banking information, not your payment card for e-commerce transactions.  In Brazil many merchants have a different payment terminal for each type of payment card they accept.  It’s not nearly as simple as we would like to imagine.

Bottom line: the industry is complex and any hack can find a loophole where a single standard may not apply to everything.  It is important therefore to move beyond the literal wording and see the intent behind the PCI standards.

Tradeoffs

No matter how smart you think you are, there is no simple solution.   It’s all a matter of tradeoffs, and my goal is to help you understand what some of those tradeoffs are.  Let’s look at a few examples:

1. Scope Reduction
   • You can deploy a Magtec encrypted card reader to encrypt all card present transactions in a tamper resistant security module (TRSM) hardware device so the data is not decrypted until it reaches your payment processor.  This could remove your card present transactions from the scope of PCI.
   • You can leverage Akamai Edge Tokenization to prevent payment card data from ever hitting your e-commerce environment.  This could remove your card-not-present transactions from the scope of PCI.
   • Perfect, right? It’s all about tradeoffs.  You remove the need for PCI compliance and simultaneously remove the ability to use that data for other business processes.  Securing data is always a matter of tradeoffs.  I call this Newton’s Second Law of Data Security. For every action there is an equal and opposite business reaction.
2. Data Breach vs Fraud Costs
   • One of the things that boggles my mind is that cardholders end up placing blame on their card issuing bank when they experience fraudulent activity on their payment card.  It wasn’t the bank that exposed your data in a data breach.  Instead it was more likely a merchant on the other side of the payment landscape that was breached and now it’s your bank who is absorbing the costs.  This is the digital equivalent of your neighbor’s house getting broken into and you paying for all the damage.  No matter how secure you make your house they continue to leave their house insecure and you continue to pay for damages. WTF?
   • The PCI standards were meant for the merchant acquiring side of the payment landscape to encourage these merchants to secure their house and thus reduce the amount of fraud occurring in the system.
   • In the United States we have mandatory data breach laws which mean the compromised merchant is required to notify the cardholder that a breach has occurred.  While some merchants may choose to ignore this, others simply cannot notify.  E-commerce merchants may have your name, address, and phone number but card-present merchants may only have your card number and no real way to notify you in the event of a data breach.  Individual state laws permit the merchant to make a local or national announcement but who is to know if you will ever hear about it?  Now, one person does have your name and address — the Issuing Bank — but they cannot disclose information related to a data breach due to non disclosure agreements they have in place.  I’d like to see a world in which compromised merchants either notify me or permit the issuing bank to notify me on their behalf.  Which brings me to my next two laws:
     • Mike’s Data Breach Rule: “They who expose my data should be the one to notify me.”
     • Mike’s Data Breach Corollary: “If they who expose my data cannot notify me, they should permit another org to do so on their behalf.”
3. Magnetic Stripe vs Chip and PIN
   • For decades people have been proposing complex technologies that could “solve” the fraud problem within the PCI industry — most of them including some form of one-time-use payment card number.  I roll my eyes and remind the reader to re-read the complexity section above.  Sure, we can issue everyone a one-time use card number but this necessitates all transactions be on-line.  Suddenly we begin to see the problem with tradeoffs wherein you cannot make purchases in airplanes, or even in retail stores that go offline.  It is the desire of the merchant community to maintain support for multiple payment methods and options because nobody wants to be told they cannot accept a payment.
   • Still others cry mutiny at the banks that they claim are forcing a legacy technology on the merchant community called the “magnetic stripe.”  Again, not true.  Remember that the cost of upgrading all payment terminals in the US to support Chip and PIN is not a cost to be borne by the issuing banks who give you the card but by the acquiring banks and every small merchant in America.  Think this would be easy?  Consider for a moment that just the payment card system for a gas (petrol) station can cost upwards of $75,000 per pump!  That does not include the back-end software required to manage the pumps and transactions.  Now consider that every merchant of every type and complexity needs to upgrade their systems.  Oh, it will happen, but it’s not the banks forcing legacy card technologies; the reason we have not moved to Chip and PIN faster is due to resistance from the merchant community.
   • Read more details here: The Real Deal on Chip and PIN (EMV) in the US.

What Makes You So Special?

That said, even with all the complexity of the various payment types and globalized networks — the variances in how data breaches occur is getting smaller and smaller.  This past week I spoke with a globe trotting PCI Forensic Investigator who told me that people always ask him, “so what fraud patterns do you see in your area of the world?” He replied with, “the same ones you see in yours and others see in theirs!”

Yes, there are variances.  As you chase the attackers out of one vector they move on to another.  Block card present, they move online.  Block online, they move upstream.  Block upstream, they move downstream.  At the end of the day, they tools are different but their target and intended goal is always the same.  So how do we defend against this ever present threat?  Scope reduction, data surrogacy, and data deprecation are some but we almost always have some data to protect, and thus a baseline for securing that data.

One thing the Verizon PCI Report taught me is that organizations focused on compliance as the only goal tend to achieve that goal and then regress immediately thereafter.  In my opinion, organizations that take a continuously improving capability and maturity model towards information security tend to regress less.  Instead of seeing compliance as a goal these organizations see compliance as a byproduct of a solid security program.

I believe in PCI compliance and the need for it (see also: regulation-deregulation cycles), but as many others have echoed — compliance is only a minimum — it is a baseline that we should continue to strive beyond.  If you feel that point-in-time compliance is the only thing you need, let me know so I can stop providing you my data to expose.

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.