Chaordic Mind

As many of you know EMV, or more commonly referred to as Chip and PIN (Chip/PIN), have been a long time structure in areas such as Europe and most of the Asia-Pacific region.  Europe made the transition between 2001 to 2006.  Canada has a mandate of October 2010 for implementation and the intra-region liability shift.  The US it seems is now entering the came with a few very small but significant moves.

• Wal-Mart has asked for Chip-and-PIN saying that now is the time to roll it out.
• In May 2010, the United Nations Federal Credit Union (UNFCU) became the first financial institution to begin issuing Chip/PIN cards.
• It should be noted that although AmEx is not technically a “financial institution” in the US, it did issue its “Blue” card with a chip for such transactions in Europe.

So will this bring us all the safety and security we want?  What will this change mean for cardholders and retailers?  Those are more complicated answers and the answer really varies from one region/country/bank to the next.  Here’s a few things that Chip/PIN changes do mean.

Liability Shift

If you read the Visa OpRegs you’ll see three different listings for liability shift.  Merchants that accept Chip/PIN transactions are not always liable for fraudulent transactions since the understanding is that they are asking for both a card and the PIN (something allegedly only the cardholder knows.)

These shifts in liability can be either domestic, intra-region or bilateral shifts (according to Visa).  MasterCard says of domestic liability shifts, “A shift in liability to the non-EMV compliant party, fraud liability is born by non-EMV complaint party for all regional transactions.  Bilateral shifts existed previously between the various Visa Regions, “Visa EU and CEMEA signed a bi-lateral agreement in order for the liability shift rule to apply for international transactions between both regions as soon as the CEMEA rule went into effect on January 2006.”

This shift takes the liability off the merchant, but who does it go to?  Well according to the Financial Ombudsman Service (FOS) in the UK that handles consumer complaint disputes, it is the bank that is responsible for the fraud unless customers acted “without reasonable care”. This could include writing down a PIN or allowing someone else to use a card.  What does this really mean?  Well, banks around the world are struggling as consumers claim fraud and the banks claim “without reasonable care.”

Risky Business

In a ComputerWorld article, analyst Avivah Litan, says that “companies such as Visa and MasterCard should consider easing some of their security requirements for U.S. merchants willing to make their payment systems EMV-ready. Visa has reduced the scope of its security audits in cases where organizations have implemented EMV technologies, and the same could be done in the U.S”

Pardon? (Fallacy alert!)

Let’s remember that Chip/PIN only helps reduce fraud at a singular merchant, it does not reduce the instance of payment card data theft.  In fact Chip/PIN transactions can be just as risky as magnetic stripe transactions from a data theft and skimming perspective.  Chip/PIN cards used as a payment terminal may leave “track equivalent data” which cannot be used to recreate the Chip but could be used to re-encode the magnetic strip on the back of traditional cards.  I mentioned this in 2008 and Gartner is still saying the same thing.

Conclusion

The US moving to Chip/PIN is a good thing and something that will drive down card-present fraud.  It may not directly impact payment card data theft and thus will not detract from PCI DSS compliance. I remember teaching a PCI DSS class of QSAs (back then CISP assessors) in the UK back in 2006.  They struggled with the problem that merchants in the UK thought they didn’t need PCI DSS compliance because they already had adopted Chip/PIN, something they already equated with “credit card security”.  I blogged about this from 2006 – 2007 to explain the differences between Chip/PIN and PCI DSS compliance and risks.

Companies that adopt Chip/PIN will still need to comply with the PCI DSS.  That being said, there are some benefits:

• Reduced interchange (in some instances)
• Reduced fraud (as measured in the UK by APACS)
• Liability shift for Chip/PIN transactions

Links

• Visa International OpRegs on Chip/PIN global mandates (2007)
• Visa Regional OpRegs for Canada (2008)
• Visa Smart Debit/Credit Certification Authority Service Description (2008)
• RBSWorldPay talks about liability shifts

A friend of mine and well known expert on the PCI standards, Branden Williams, blogged about “Does PTS apply to ATMs?“  For those of you still reading that question, PTS stands for PIN Transaction Security and was formerly known as the PIN/PED program.

The important question is which standard do you apply to automated teller machines (ATMs) which seem to exemplify the need for each standard to one degree or another.

Branden reminds us:

ATMs are payment devices just like the card swipe or chip & pin machines we see at mearchants all over the world.  The only difference is that they typically have larger displays, are heavier and more physically hardened, and they spit out money on request.  They’ve also become a great target for hackers to prey on the trusting human (with a fake ATM), or to add sophisticated skimming devices to steal and take advantage of consumer payment data.

It is important to not compartmentalize systems into Procrustean boxes and instead break them into their respective parts.  For example, a company may be both a merchant and a service provider (e.g. Amazon.com or Internet Service Providers).  In the same way an ATM can be broken down into its respective parts and the standards which apply.

• PTS applies to the PIN pad component
• PA-DSS applies to the software running on it (potentially)
• PCI DSS applies to the company that drives the ATM network

I don’t think many people have ever asked themselves what regulatory compliance has in common with immunization, but they should.  The fact of the matter is that these two have more in common than you think and understanding one will help you better understand the other and how to make better educated decisions.  In addition, there are trade-offs — both heath and economic — to the choices one makes in participating in vaccination and immunization programs.  The following addresses a few of these items and opens the doors for further conversation.

Why Comply? Why Vaccinate?

Immunization and vaccination are the process by which an individual or population is treated in order to fortify itself against attack from foreign bodies.  Vaccination against disease can help prevent contracting that pathogen in the future, and preventing multiple individuals in a population from becoming infected helps prevent the widespread outbreak and transmission of diseases such as smallpox, polio, measles, mumps, and anthrax.  By elevating the level of a population that is resistant to such attacks vaccines help protect the entire population from harm.

The problem is that although most all agree that vaccination is positive for the population not everyone agrees that it is positive for the individual.

Since vaccination began in the late 18th century, opponents have claimed that vaccines do not work, that they are or may be dangerous, that individuals should rely on personal hygiene instead, or that mandatory vaccinations violate individual rights or religious principles.

Have we not heard similar arguments against regulatory compliance?  Individuals stating that:

• My environment is already secure
• I know how to manage risk better than the regulatory bodies
• My environment is special and unique and does not fit into your Procrustean boxes

I’ve listened to people sing the virtues of regulatory compliance as often as I’ve heard other individual tell me “that sounds good but it’s not for me.”  I feel as if I’m mediating between the Center for Disease Control (CDC) and a troubled parent about why their child should be vaccinated before entering grade school.

Perspective

Part I

One of the problems with understanding the complexity of the problem is that of perspective.  The CDC and the parent have very different perspectives on vaccines and immunization.  In the same way, the regulatory bodies and those who must comply with them have very different views on how to best apply data security practices.

For example, it is widely known by the payment card industry (PCI) that the majority of small and medium merchants use one of a few brands of payment application.  Many retail merchants use a Micros, VeriFone, or Radiant Aloha (restaurants) point of sale (POS) application.  This high level of homogeneity in a population lends itself to attract attackers (pathogens) who wish to take advantage of any vulnerabilities they can identify in these systems.

The PCI Council, who act as the CDC, along with the card brands mandate that software companies validate their applications against a given security standard (in this case the PA-DSS).  They then introduce these more secure applications into the population and the governing bodies mandate their use over less secure payment applications.

So why not just stop there?  If things were that easy, the CDC would only ever have to worry about one pathogen using one attack vector.  If we secure the retail payment applications, attackers will just move to other industries such as petrol (gas) stations, ski resorts, and florist shops.  To which the industry responds with Dresser Wayne or Gilbarco, SKIDATA, and Teleflora Dove validated payment applications respectively.  The validated payment application program targets to inoculate every industry against the dangers of retaining data most valuable to attackers.

Part II

But what about the individual restaurant owner who says they don’t need a validated payment application?  They claim all the reasons mentioned above from the specialized nature of their business or network to the secure risk management platform they have already implemented.  Why should they comply?

I do not have a good answer to the ‘why’ but I do have one for the ‘how’.  In fact, about 95% of the ‘PCI Wars’ debate going on today try to answer the question of “why” when this is as futile as debating intelligent design vs evolution (because both are based on separate and unequal premises.)  Debating why one should comply is futile as the rules state that everyone who “stores, process or transmits” such data must comply (as per the card brand operating regulations.)

The more interesting question is that of how one should comply.  These examples reference the PCI standards but could apply to just about any regulatory compliance mandate.  The way in which one complies can be taken at a high level.  For the PCI standards it implies preventing the paper and electronic theft of payment card data.  In fact, any way that your company decides to do this implies compliance with the standard.

If parents didn’t mind sending their children to school in hermetically sealed bubbles, then there would be less of a public policy need for them to be vaccinate against disease.  In this way, the parent and child could make their own decision about data security without harming or posing a risk to the rest of the population of school children and their parents.  If your company can, via whatever means at your disposal, hermetically seal itself against attacks then the matter of compliance is simply an exercise for the user in creative documentation, reporting, and compensating controls.  The problem is, many companies over estimate their security controls and thus cause a break in the structure of data security.

Economics of Immunization and Compliance

When approaching the economics of immunization one cannot ignore the population at hand.  For example, a poorer population will benefit more strongly from an immunization program than one that maintains a high level of sanitation, health care, and treatment programs.  To the same degree a more vulnerable population (e.g. retail, restaurants, higher education, e-commerce, etc.) will benefit more from regulatory compliance than one that is more highly secure (e.g. government systems).

In fact, one of the primary catalysts for regulatory compliance is the build up of problems (e.g. data breaches) within an industry followed by the punctuated equilibrium that brings about a response founded in legislative and regulatory action.

The cost of making a population more secure is relatively simple: require them to use more secure applications and systems.  The cost to the individual can vary along with the benefits.  The same applies to vaccines.

One could go their entire professional life without contracting the flu but this is rather rare in my experience.  Instead many people will get the flu vaccine each year on the off chance they will come in contact with the virus because being bed ridden for 1-2 weeks can be both painful and detrimental to the company.

So what!

The cause of action to vaccinate a population is to immunize them from each other.  The process involves a uniform across the board preemptive treatment that is meant to mitigate risks, not prevent them entirely.  In the same way, regulatory bodies craft legislation as a one-size-fits all in order to protect the population from each other.  The individual implementation should see this as guidance and not a rule without exceptions.

The details of how one protects themselves against attack and infection may be unique to each individual, but they still must comply with the overarching industry agreement to protect themselves and thus the population against attacks.  The implementation will vary, of course it will.  One size does not fit all.  But the industry needs a standard, a baseline, against which it can measure risk.  As new infections and outbreaks occur, the industry will change the baseline to match the new attacks.

Those who can visualize the various perspectives will have a greater visibility into how they can better fortify their individual organizations to both validate against industry mandates and manage risk based on their specific organizational behavior.

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.

Many people debate the efficacy, effectiveness, and overall utility of the Payment Card Industry Data Security Standard (PCI DSS).  Some people involved in this debate suffer from a bounded rationality, wherein their rationality is bounded by the few articles they read online, their perspective as a merchant, or their view as an information security professional.

I’d like to outline the good, the bad, and the ugly about the PCI DSS.  I do this not to condemn or defend any one party but instead to raise the level of conversation and debate beyond some of the fallacy ridden discussions we have been having up until now.

The Good

One thing that people do not realize is that the Payment Card Industry is unlike any other.  The reason we all talk about it is because it is more of a “horizontal” than it is a “vertical” industry.  Instead of talking about the banking & finance, agriculture, or even retail industry we are talking about just about every company that utilizes credit cards in some way.  It is the case that regulatory compliance has driven the dollars behind information security since 2001, and the greatest motivator in the past few years has been the PCI DSS.  If we like it or not, this standard has been the carrot (and stick) necessary to making companies care about securing your payment card data.

Until the PCI DSS was created (and the CISP/SDP before it) there was little to no standardized way for acquiring banks to measure the risk present in their merchant population. Sure, they could have reviewed varying security reports but none of these went to the heart of the risk matter by eliminating the retention of sensitive authentication data.  In fact, it was not until the PCI mandates for not storing such data that we saw real change in the payments industry.

Thought the original PCI DSS compliance deadlines were September 30, 2004, it was not until the Visa Compliance Acceleration Program (CAP) in 2007 that substantial movement occurred.  The CAP program provided the motivation necessary to make merchants validate they were not retaining sensitive authentication data.

Information security writer and reporter, George V Hulme, gets it and says, “I still contend, PCI DSS has done much to raise merchant security from the dismal state it was in — to the better state it is in today.”  Things are certainly getting better.

The PCI DSS has given acquiring banks, merchants and service providers a method of measuring their exposure to electronic and paper data compromise, the most important of which is keeping hackers from accessing the payment card data.  This is something that no other security standard specifically calls out.  (There exist many other information security programs but none define industry terms such as “sensitive authentication data” or “cardholder data”.)

So where would we be without the specific PCI mandate to eliminate sensitive authentication data and protect the remaining cardholder data?  Well, I argue we would have even more data breaches than we see today.  In the most recent (3.31.09) Visa Inc statistics, we see that within the U.S. all of the top two merchant levels have either validated compliance or are in the process of remediation.  This is a big change from even 3-4 years ago where many merchants had only begun to protect their payment card data.

Additionally, there has been significant work done to help the medium and smaller merchant levels.  Visa spearheaded the PA-DSS program, formerly the PABP, in an effort to provide secure payment applications to merchants who may not otherwise care about security or compliance.  If we follow the 80/20 rule, it is easy to imagine that 80% of the small (Level 4) merchants use the top 20% of payment applications/terminals.  If the industry can verify these payment terminals are secure they can help reduce the risk of data loss for 80% of the small merchant market.

The Bad

The PCI SSC has put in place a structured 2-year cycle for updating and improving the PCI standards.  These changes hope to move the standard in the direction of protecting data compromises based on evolving attack and threat patterns.  In the move from v1.1 to v1.2 we saw the addition of Requirement 6.6 in direct response to the rise in the number of web application attacks.  These are very positive moves, but I would not say everything is roses.

The PCI DSS references the need for a “risk based” approach but it is buried deep in Requirement 12.1.2, which states, “[security policies must] include an annual process that identifies threats and vulnerabilities, and results in a formal risk assessment.”  I like that it is here, but I think this sentence should be the overarching measure by which all requirements are addressed.

There have been many positives moves in this direction.  In April 2008, Bank of America released a document titled Beyond Minimum Compliance: PCI Risk Management.  Though not a risk management framework, this document outlined some Top 10 PCI Best Practices that included: becoming compliant, using secure payment applications, reducing the scope of data, validate compliance, and maintain a state of security throughout the year.  In 2009, the PCI Security Standards Council released a Prioritized Approach to Pursue PCI DSS Compliance.  This takes the PCI SAP and prioritizes each requirement based on, what I assume is, that which may prevent the exposure of payment card data to the greatest number of attacks.

The executive summary of the PCI Security Audit Procedures (SAP) should clearly state the need for a risk management methodology and approach.  Moreover, it should designate a call for action that companies create and maintain a capability and maturity model (CMM) to track their progress in reducing risk.

I’ve found that one of the major roadblocks to compliance adoption is the confusion about to what degree each requirement should be implemented.  These fears could be lessened if the risk management dialogue happened at the beginning of the standard.  Similar approaches have been seen in COBIT and even the ISO27001 (with the ISO27005 framework) to name a few.

The Ugly

What I find ugly about the industry is the continual flame wars that erupt around the standard itself.  I find that many, if not all of these, have to do with the improper implementation of the standard, or the lack of a deeper insight to the industry and the history of regulatory compliance.

Anyone who has worked in a cross section of regulatory compliance arenas can tell you that there is a major difference between government regulated industries and self-regulated industries.  With the exception of NAR’s REALTOR® Secure Program, I don’t know any other industry self-regulation that exists other than the PCI DSS.  (Branden Williams, Alex Hutton and David Mortman remind me of the HiTRUST program for the health care industry.)  This is a welcome anomaly in the world of government mandates.  Those who think PCI DSS is hard to comply with may not have dealt with GLBA or SOX.  With the GLB Act, if the Fed gives you a low rating (higher number) on your bank, they don’t fine you, they just shut you down.  The payments industry is trying to enable commerce in a more secure way than it was done before.

A favorite topic of Dan Geer is that of punctuated equilibrium.  The historical context of punctuated equilibrium has shown that without incremental action, a buildup of force can result in great reactionary action.  The simplest example of this is that of a volcano or earthquake.  In public policy and the payments industry this buildup has been noted several times.  We can see this historically where the government has intervened after the industry itself could not properly self-regulate.  The Great Depression gave rise to the Securities and Exchange Commission (SEC), the once poor food standards gave rise to the Food and Drug Administration (FDA), and we are now asking if the lack of personal data privacy will give way to a government managed compliance standard.  I argue that self-regulation with continual improvement will make faster strides towards data protection than will omnibus legislation.

People complain that the 2-year life cycle of the PCI DSS is too slow, but they must not be that familiar with the 4-year life cycle for other government mandates.  Also, changing a standard any faster would cause merchants’ heads to spin!  Though the payments industry is trying to self-regulate, this never seems to be enough for some people.

The “ugly” side of the industry is that which everyone becomes a pundit, spinning the story to meet their specific pain.  People say that PCI DSS is all about “risk transference” which is a flat out fallacy of belief.  The truth is that Issuing banks have always picked up the tab for fraud, and have long been able to recover that money from merchants via the various card brand issuer reimbursement programs (i.e. Visa ADCR).  The only thing the PCI DSS ever did was give acquiring banks (and all organizations handling payment card data) a measure against which to protect the payment card data.

This angry snarl of punditry is really the sad conclusion to our state of affairs.  I fully support those who wish to improve the industry but many times people feel that change should be revolutionary and not evolutionary.  They are quick to call your baby ugly and then tell you how to parent your child.  Everyone has their own input, and I just wish people would be more constructive with their comments, feedback, and advice.  We are listening!  I am listening!

As a final note, I’d like to remind the implementers of the PCI standards (merchants and service providers) to take responsibility for their own actions.  The PCI DSS should not be used as a stand alone tool.  Companies need to wrap the DSS in a comprehensive risk management program that is measured through time by a proper capability and maturity model.  Only by staying vigilant and continuously reevaluating our current security posture can we properly protect against the ever changing attack vectors that confront us.

Additional Reading

I also highly recommend PCI Shrugged: Debunking Criticisms of PCI DSS.  Please suggest others in the comments.