Chaordic Mind

Abstract

As regulation-deregulation cycles rise and fall, it is important to understand how the evolving landscape of compliance impacts your future. This post proposes maintaining compliance but making validation an opt-out optional component – a radical change from the status quo.  Evidence already suggests the industry is moving in this direction and changes to compliance are necessary for the continuance of risk management.

Please understand that when I say opt-out, I am referring to mandated external, third-party validation requirements. I think internal validation is more important than ever.

Special thanks to idea people: @lennyzeltser, @mckeay, @alexhutton, @kindervag, @joshcorman

Background

I recently read Lenny Zeltser’s blog titled “Could Regulatory Compliance Encourage Weaker Security?” This is a valid question and one that needs addressing. The question can be rephrased as, “Who does compliance work best for?” To answer that question we need to understand why compliance exists.

In a blog post I wrote on How Compliance Regulations Gets Made we focus on the natural regulation-deregulation cycles and how they exist in response to an increase or decrease in data breach/loss. The ultimate goal of compliance is to set a baseline of standards within an industry. The question Lenny raises is one I’m often asked by opponents of such standards, “what about the big/little guy (who do not fall within the Bell Curve norm for best practices)?”

It’s true that regulatory compliance is targeted not only at setting a minimum standard for technical security (firewalls and IDS) but also a minimum standard for security maturity (policies and procedures) within an organization. So let’s think about this graphically. There are four quadrants within which to place organizations: those with either high/low-level of security and high/low-level of maturity.

Security vs Maturity

For the purpose of this conversation let’s assume that maturity encompasses the Check and Act aspects of the PDCA Cycle and security refers to the Plan and Do components. The reason I break it down this way is to directly reflect the results of the Verizon PCI Compliance Report (PCIR). This report found that:

“Organizations are better at planning and doing than checking. If the check phase is broken, they cannot act to maintain the state of security over time.”

The Verizon PCIR found that organizations are great at Planning and Doing but not great at Checking and, as a direct result, Acting on those changes. To me this disconnect is the difference between organizations with a high-level vs low-level of maturity within their security practice.

With this in mind, let me suggest that regulatory compliance standards should most impact those organizations with a lack of either security or maturity, but not both. So let’s break this down and the types of organizations they embody.

1. High-Security / Low-Maturity: These companies care about security but have never documented policies and procedures. They have log management systems but have slowly stopped reviewing them. Regulatory compliance can have a positive impact here.
2. Low-Security / High-Maturity: These or organizations run well but with little funding for sorely needed security projects. There has never been a “hammer” to drive spending. Regulatory compliance can have a positive impact here.
3. Low-Security / Low-Maturity: These are organizations that do not care about security or compliance. Perhaps they are too small (mom-and-pop companies) or those that will validate compliance but never maintain it through the year. There is no changing these companies and little that compliance can do for them. Validating compliance for them is a waste of time and money and since there is no driver to maintain a state of security.  (Instead new technologies such as tokenization, end-to-end encryption, and validated payment applications will have the highest impact here.)
4. High-Security / High-Maturity: These are companies at the top-tier of their breed. They don’t manage security, they manage risk! They adopt and implement custom risk management solutions based on careful analysis of data classification and impact analysis reports. These companies see regulatory compliance as a roadblock and implementing industry “best practices” as a deviation from their perfect path.

I propose that regulatory compliance will most help groups 1 and 2, but not groups 3 and 4.  (Unless you consider regulatory compliance the driving force for said technologies above, though I would argue data breaches and word of mouth have a higher impact here than compliance.)

Although I believe in the need for increased education, flexibility of controls, and more data for risk modeling – I’m going to save us a bit of time and skip to the chase.

• Companies in group 3, who do not care about compliance or security, will not change their tune by forcing them to validate compliance.  Instead the end result will most likely be in them checking a box and ending up in the 80% of companies (see: Verizon PCIR) that do not maintain their state of compliance.
• Companies in group 4, who care passionately about risk and security, need a reprise from continually validating against a standard that is built for the average individual. Although, the stated way to address this for PCI compliance is through documenting a set of Compensating Controls, what other options do we have out there? What other ways are there for such companies dealing with compliance validation?

Remember, the stated goal of regulatory compliance, taken from regulation-deregulation cycles, is to reduce the number of data breaches and data loss. In both groups 3 and 4, continual validating against a standard may, in my opinion, have little to no impact on the number of data breaches/loss. The reason is that group 3, though validating will not maintain that validation, and group 4, treat validation as an exercise in documentation.

Other Options

On February 6, 2011, Visa launched its Technology Innovation Plan (TIP) “to recognize and acknowledge merchants in Visa Inc. regions outside of the United States that have taken action to prevent counterfeit fraud by investing in EMV technology.” (Since Visa Europe is a franchise, the “outside the US” may only apply to Asia-Pacific and Latin-America & Caribbean, but it’s a bold change we should view as the tip of an iceberg.)

In essence, they are saying that organizations that have achieved the following, need not continue to validate their compliance against the PCI DSS standard:

• Implemented a sufficient level of controls so as to reduce fraud* (see: EMV)
• Validated their state of compliance once
• Have not suffered a data breach

* Yes, fraud is discernibly different from data breaches but one leads to the other and as a result are interconnected.

Wow, what an innovative approach. I’ve talked about the TIP program with industry insiders and they are mostly in agreement that we don’t know if this will result in positive or negative changes. I feel it will be a great success and here is why.

Opting Out of Validation (Not Compliance)

Presently companies that validate their state of compliance need to submit two things: a validation document (either a self-assessment questionnaire or a report on compliance) and an attestation of compliance (AOC) document. The AOC is nothing more than a memo that reiterates that organizations commitment to following the payment-brand rules for protecting payment card data.

I think organizations that choose to opt-out of compliance validation should still need to sign the Attestation on Compliance (AOC) to reaffirm their social contract and commitment to protecting payment card data. If they fail to achieve this within their, alleged, super-robust security and risk program then they deserve to undergo the same forensic review and financial implications that come with any other organization. If they instead achieve in protecting payment card data and are able to repel the wily-hacker then they should continue their reprieve from annual compliance validation (perhaps they can externally-validate every 2 or 3 years).

The reason I suggest this is because, and here’s the kicker, you cannot tell the difference between a PCI compliant organization and one that has let security and compliance lapse until they experience a data breach. Until that point, both organizations appear, from the outside, to be operating in the same manner.  (Sure, you can tell a difference internally, but so far very few organizations that achieve compliance once organically maintain it year-over-year.)

But Wait – It Already Exists

The PCI Council has already rolled out the Internal Security Assessor (ISA) program and MasterCard has begun listing this qualification as part their validation program requirements.

“Effective 30 June 2011, Level 1 merchants that choose to conduct an annual onsite assessment using an internal auditor must ensure that primary internal auditor staff engaged in validating PCI DSS compliance attend PCI SSC ISA Training and pass the associated accreditation program annually in order to continue to use internal auditors.”

(Ok, so Visa has not adopted the same stance and companies that store, process, or transmit payment card data for both brands must adhere to the minimum standard for both, but still it’s a change.  Also, the payment card brand validation guidelines are guidance for the acquiring banks who have the ability to manage their validation programs on a case-by-case basis.)

This means that many organizations (there are exceptions) who wish to opt-out of formal validation can do so leveraging their internal assessor team.

Conclusion

What we have is a directional movement towards, what I will call, selective deregulation. Step 1 is the PCI SSC ISA program.  Step 2 is the Visa TIP program.  What is the next step? The only way to know is to wait and see.

I’m not proposing that we do away with validation entirely, but instead that we move into a hybrid approach towards validation that is based on risk, maturity, pas performance, and future commitment.  The market has spoken and the Council and payment brands are already responding.

My suggestions for you?

If you fall into category 1, 2, or 4 above – prepare the following:

• Develop a “heat map” of your internal risks, data types, and exposures
• Adopt a risk management strategy, however rudimentary or advanced
• Attend the PCI SSC ISA training ASAP

If you fall into category 3 above – investigate the following:

• Are you using a PCI validated payment software and hardware?
• Are you using PCI DSS validated service providers?
• Are you area of technologies that reduce the need for PCI compliance such as: tokenization and end-to-end encryption?

A friend recently asked me to help solve for him a Payment Card Industry (PCI) riddle.  Here is a sanitized and rewritten stub:

A competitor of ours is listed on Visa’s PCI list of validated service providers, but we know that they are not compliant with one of the PCI DSS requirements.  We know this because we operate in the same business model and there is no way that they or we can do this one thing.  My assumption is that this is a case of a Qualified Security Assessor (QSA) missing the boat.  Is there any way that we could also get compliant?

To which I replied:

(1) You can always become compliant. (2) The details are not always what they may seem to you or your competitor. (3) Also, compliance validation is in part to do with the Acquiring Bank and or payment brand.

You seem to think you know everything there is to know about your competitor but in all likelihood you do not – nor are you a beautiful and unique snowflake that deserves special consideration.  Nuances unimportant to you may have a big impact on compliance. I’ve heard this argument before – if they do it why can’t we? The answer is because you know better.

Also, your competitor’s acquiring bank or validation entity may permit them to operate in a certain capacity based on factors unknown to you.  My advice is to talk to your acquiring bank or payment brand and ask them to work with you on a solution.  If you don’t want to do that it’s because you know the answer you will get and just don’t like it.

Alternatives

Of course there are work arounds.  My latest mantra of compliance has been to stop teaching people how to comply and instead teaching them how to develop a risk management program with compliance a natural byproduct rather than an end goal.

To do this you need to know what rules you need to obey, which you can bend, and which you need to work around.  Here is a short list of work arounds.

• Compensating controls
• Segmentation: network, operational, physical, role based
• Tokenization or data surrogacy
• Scope reduction
• Point-to-point encryption
• Remove the data
• Truncate or mask the data

The list goes on.

When measuring compliance results the data available is sparse and the analysis ranges from those who love it to those who hate it. Regardless of your personal, political or analytical beliefs the question remains about the efficacy of the practice itself.

There are several approaches and conversations surrounding the aspect of regulatory compliance, but the question remains, “What leads to excellence in organizations and the security they implement?”

The conclusion of this post is simple: Excellence within an organization is not achieved by measuring the compliance of an organization but by measuring the compliance of individuals and employees.

So how do we come to such a conclusion? To start we identify the main points for and against regulatory compliance:

• Pro: It raises the minimum level of security
• Cons: It creates a glass ceiling that either (1) prevents proactive organizations from implementing better security or (2) encourages reactive organizations to never excel above a certain point

Regardless of your opinion, both arguments focus around the precise level at which compliance measures an organization. Isn’t that interesting? Both the pro (for) and con (against) opinions seem to claim the same thing. This would be a good thing if it encouraged security without limiting organizations.

Already, PCI compliance (credit card security) has been compared with the No Child Left Behind or Elementary and Secondary Education Act (ESEA) within the United States. If this program is broken, let’s identify why, dispel false truths and come to a conclusion of how to learn from its lessons.

The fact remains, “nationwide: only 6 percent of U.S. students perform at the advanced-proficiency level in math, a share that lags behind kids in some 30 other countries, from the United Kingdom to Taiwan.”

Davi Ottenheimer wrote a summary of an article in The Atlantica titled, “Your Child Left Behind”. It goes on to dispel many myths about the No Child Left Behind Act. Eric Hanushek has spent “40 years calmly butchering conventional wisdom on education” including the following:

• More money does not tend to lead to better results
• Smaller class sizes do not tend to improve learning
• No U.S. state does very well compared with other rich nations
• Even relatively privileged students do not compete favorably with average students in other well-off countries. (In Illinois, the percentage of kids with a college-educated parent who are highly skilled at math is lower than the percentage of such kids among all students in Iceland, France, Estonia, and Sweden.)

“Per student, we now spend more than all but three other countries—Luxembourg, Switzerland, and Norway—on elementary and secondary education. And the list of countries that spend the most, notably, has little in common with the outcomes that Hanushek and his colleagues put into rank order. (The same holds true on the state level, where New York, one of the highest-spending states—it topped the list at $17,000 per pupil in 2008—still comes in behind 15 other states and 30 countries on Hanushek’s list.

If money, class size, and affluence of individuals do not impact classroom performance then why do we think that money, attack landscape, and intelligence of security professionals will impact the security of organizations?

Davi writes, “The exception to this lazy approach is the state of Massachusetts, which has followed a path that found success in other countries. It has directly intervened and introduced compliance.” But what kind of compliance? Was it simple testing that measured student performance against standardized tests? Nope.

The Atlantic gives us a glimpse into the answer. “What did Massachusetts do? Well, nothing that many countries (and industries) didn’t do a long time ago. For example, Massachusetts made it harder to become a teacher, requiring newcomers to pass a basic literacy test before entering the classroom. (In the first year, more than a third of the new teachers failed the test.) The state also required students to pass a test before graduating from high school–a notion so heretical that it led to protests in which students burned state superintendent David Driscoll in effigy. To help tutor the kids who failed, the state moved money around to the places where it was needed most. “We had a system of standards and held people to it–adults and students,” Driscoll says.”

So what works?

“Massachusetts, in other words, began demanding meaningful outcomes from everyone in the school building. Obvious though it may seem, it’s an idea that remains sacrilegious in many U.S. schools, despite the clumsy advances of No Child Left Behind. Instead, we still fixate on inputs—such as how much money we are pouring into the system or how small our class sizes are—and wind up with little to show for it. Since the early 1970s, we’ve doubled the amount of money we spend per pupil nationwide, but our high-schoolers’ reading and math scores have barely budged.”

Problem Set

My personal opinion is to focus on a capability and maturity model (CMM) of security and making regulatory compliance a natural side effect rather than an end goal. Sounds academic; so where’s the beef?

The practical implementation of this is shown in the recent Verizon PCI Compliance Report wherein it showed that organizations fail at tasks that: require human intervention or reoccurring activity. Many organizations that focus on compliance as an end-goal, fail to validate or maintain security throughout the year. No shocker there, but how do we overcome the human side of security? Security professionals have been talking about addressing the end-user for a long time, but these are not end-user problems they are security-professional problems.

Can we just throw more money at the problem? Reduce the scope of compliance? Train our security staff? Well, studies of the U.S. education system show these methods to be ineffective since they do not encourage well funded security professionals to do things like review audit logs on a daily basis. Even the most automated of systems are often times ignored for a variety of reasons.

Conclusion

Excellence within an organization is not achieved by measuring the compliance of an organization but by measuring the compliance of individuals and employees.

Building maturity models for information security implies an ever increasing maturity and level of security. This helps break the proverbial “glass ceiling” of compliance by having the security of an organization grow in proportion to the ever evolving attack landscape. This is so much easier said than done.

Our ability to achieve this goal hinges on our ability to encourage individual participation. Encouraging individual security-professionals to take action towards this goal.

So how useful is regulatory compliance? I advocate that compliance is good, but only in measuring the security of an organization at a point in time.  We need something much more than this to achieve real security.  We need something that will encourage validation and maintenance of security.

Final <rant>

Better security will not come from automation (DLP, audit log aggregation, etc.)  Better security will not come from more intelligent tools.  Better security will come from a higher standard within organizations to focus on maintaining security.  This leads to a discussion of cross-training security-professionals on conversational business-speak and helping them build measurable, results-driven risk models… but that is for another day.

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.

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

In April 2010 I’ll be at SOURCEBoston on a panel discussing how compliance regulations get made.  This got me thinking about how to explain in simple terms such a complex series of events.  I’ve previously discussed the question of “why” regulatory compliance is important and it’s relation to vaccinations.  Here I’d like to discuss the “how” of regulatory issues.

(If you’d like to hear about this and other PCI related issues then register for the BrightTALK PCI Compliance Summit on March 25, 2010.)

There are so many debates about the pros and cons of regulatory compliance but they all focus on the individual and not the population as a whole.  In fact, the best way to model and examine the evolution of regulation and deregulation is through the eye of the scientist examining the entire population of players.

Background:

Let’s take a look at the history of regulation and deregulation.  The following are a few industries that have experienced both regulation and deregulation over the years, but the list may as well also include industries such as agriculture, telephone, communications (radio, TV, cable), medical and pharmacy.

• Airline
  –Civil Aeronautics Board (1937)
  –Airline Deregulation Act (1978)
• Railway
  –Interstate Commerce Commission (1887)
  –Railroad Revitalization and Regulatory Reform Act (1976) / Staggers Rail Act (1980)
• Trucking
  –Motor Carrier Act (1935)
  –Motor Carrier Regulatory Reform and Modernization Act (1980)
• Energy
  –OPEC price hikes (1973)
  –Emergency Natural Gas Act (1977)

Each of these industries experienced a need for regulation and eventual deregulation in order to keep in check the potential for large problems that could impact large numbers of people (e.g. monopoly, poor conditions, unbound risk, lack of consumer protection).  In 1935 Congress passed the Motor Carrier Act that gave the Interstate Commerce Commission (ICC) authority to regulate trucking involved in interstate commerce.  When the confines of this regulation outlived it usefulness the tides turned.  From 1971 until the eventual passage in 1980 politicians worked to remove barriers to entry into this industry and finally passed the Motor Carrier Regulatory Reform and Modernization Act.  This migratory pattern of regulation and deregulation occurs regularly in many industries.

Pattern of Data Loss

It is no surprise to anyone that there is a building momentum of data loss.  We can gather individual statistics from the news or get detailed statistics from DataLossDB.org.  Either way we notice a pattern of attacks and rising numbers of data breaches that make us ask, is the situation getting better or worse?  Is what we are doing having the desired effect?

It’s very difficult to answer that question since the problem is multi-factorial, but there are signs that things are getting better.  As fraud shifts from one industry to another and one method to another we are slowly driving it from the system.  (This type of analysis does not as easily apply to authentication/identity fraud, but may very well when it comes to system infiltration and data exfiltration techniques.)  For example, we see attack vectors moving from one method to another and from one geographic region to another.  Attackers originally stole data from flat files but when those were encrypted the attackers began capturing data as it traversed the network.  When this was encrypted they began installing custom malware to capture data in memory.  Slowly the system are moving from system protection, to network, to software, and finally hardware protection.

As protection system such as Chip-PIN were implemented across Europe and Asia we saw a drop in card present fraud as the attackers moved to online and e-commerce fraud (via UKPA or APACS).  The attackers adapted to the system and moved on to other low hanging fruit.

History of Regulatory Time

I can’t really do justice to replicating the work of David Lineman, of  Information Shield, so I’ll simply reference his paper “A History of Regulatory Time” and reference his graph showing a timeline of security privacy-related regulations.  Take a look and map the regulations below against the major data breaches of recent and we begin to notice the correlation of regulation in reaction to the rise in tide of data breaches.

Inflection Points and Traffic Jams

Simply analyzing data breaches and their respective reactionary regulation doesn’t paint a precise picture of how the regulations are formed, only that they are somehow correlated.  To understand this we need to first understand a little about math.  Inflection points are the change in slope from an increasing value to a decreasing value or vice versa.  In terms of data breaches we can consider if the number of data breaches, though currently increasing, has a slope that is increasing or decreasing.

Andy Grove, founder of Intel, said in his book Only the Paranoid Survive that “An inflection point occurs where the old strategic picture dissolves and gives way to the new.”  We need to focus on this inflection point in order to understand and if the increasing numbers reflect a state of growth or decline in a system, which we are (unfortunately) only able to measure over time.

In fact, this concept is familiar to physicists in the term “hysteresis“.

For example, consider a thermostat that controls a furnace. The furnace is either off or on, with nothing in between. The thermostat is a system; the input is the temperature, and the output is the furnace state. If one wishes to maintain a temperature of 20 °C, then one might set the thermostat to turn the furnace on when the temperature drops below 18 °C, and turn it off when the temperature exceeds 22 °C. This thermostat has hysteresis. If the temperature is 21 °C, then it is not possible to predict whether the furnace is on or off without knowing the history of the temperature.

The question we always ask is “Where are we on the Sine Wave of Pain?“  Is the rate of negative events increasing or decreasing?  The only way to know is gather and map data as well as measure trending patterns in the industry and make calculated estimates as to which it is.

One thing for sure is that the population not the individual is what drives regulation and as such it is the population that examined the rising data loss numbers and determines when they want change.  It is this demand for change that ultimately initializes the regulation engine to affect what the individual cannot directly.

Traffic Patterns and Modeling

Still, all we have shown at this point is that a culmination of actions can result in change brought upon by the populous.   How that change is enacted is an area of great interest and one that draws from, of all things, traffic patterns.  Before getting into that I’d like to reflect on different types of phase shifts seen both in nature and fiction.  We are all familiar with the concept of ice melting into water which freezes into ice.  It was Kurt Vonnegut who in his book Cat’s Cradle first proposed the fictional concept of Ice-Nine.  This was said to be a polymorph of water that freezes at 45.8 °C (114.4 °F) instead of 0 °C (32 °F).  The idea being that ice could maintain its ice form even at room temperature which is around 20 °C  (68 °F) to 25 °C (77 °F).  In the book, it would take only a single fragment of “ice-nine” to come in contact with the ocean and they would all instantly freeze.  This shows how a seemingly stable system can react suddenly when given the proper catalyst.

A common method of modeling traffic patterns is the Nagel-Schreckenberg (NaSch) model.  (For more detailed information on this model I recommend reading Traffic Simulation using Agent-Based Modelling by Andrew Lansdowne.)  The diagram to the right shows this model in that the traffic flow (y-axis) is measured against the traffic density (x-axis).  You can see that as the traffic density increases the traffic flow increases.  This continues until point “A” where we reach the critical density.  This is the density at which a chance can occur but not at which it must occur.  If everyone continues driving along at the same rate the density can increase until a critical event occurs that breaks down the system.  An example could be one person applying the breaks which then causes the person behind them to do the same, and on and on.  Point “B” is the moment at which the critical event occurs.  At this point we see the traffic flow decrease representing the slowing of traffic until the density is so high it stops (point “D”).

One interesting feature of this series of events is that the traffic flow pattern will always exist in a cycle moving from point A to B, to D and back to A in that order.  Traffic will never go from D to B because doing so requires it to first traverse A.  Remember that term hysteresis?  In the book Critical Mass by Philip Ball he states, “A state of traffic depends not only on its density but on its history – on whether it was previously denser or less dense.  As the traffic rate rises and then falls, the flow rate follows a loop.”

We can examine the graphical flow of data in another form by mapping space on the road (x-axis) against time (y-axis).  As you can see in the second diagram, we map the position of each vehicle over time.  Until the density decreases the traffic jam will continue.  Here the traffic jam is visible in the very dense points as a diagonal across the diagram.  Once the density decreases we once again see a greater flow of traffic.

What’s the Solution?

As you can see, modeling traffic patterns can be very similar to the regulation and deregulation of an industry.  So what is the solution to an increase in incidents that push us past the critical density?  Contrary to initial though the solution to high traffic is not to simply build more roads.  In fact, Richard Moe, Head of the US National Trust for Historic Preservation, once said “building more roads to ease traffic is like trying to cure obesity by loosening the belt”.  Simply applying ‘more’ security does not mean you achieve ‘better’ security.

I propose the following approaches:

• Help prevent data sprawl :: Security is required where data is maintained.  Does your environment reflect the “data, data, anywhere” or “data, data, everywhere” philosophy?  Do you know where all your data is? Does it exist in more locations than is necessary?  Check these items and set measurable actions to correct it.
• Examine use cases :: While medical record data requires persistence, payment card data is only used once and then not ever again.  The use cases are simple enabling a flexible set of measures to secure the data.  If your business model does require retention of data then examine what data you are retaining and make sure it’s as benign as possible.
• Brute force is effective but costly, while the elegant solution is simple and secure :: Have you ever considered replacing the data you retain with a reference number instead?  I recommend you read up on technologies such as point-to-point encryption and tokenization.
• Solve tomorrows problems with today’s technology :: Problems are not hard if you know which ones to solve.  I recommend absorbing and comparing as many of the data breach reports (more) you can to determine what emerging attack patterns exist in your industry and how to prevent them.  If you are only able to implement one set of technology each 10+ years then make sure it solves tomorrows problems and not yesterdays.
• Plugging one hole doesn’t save the levee :: Reducing card present fraud drives attackers to e-commerce.  Reducing fraud in one country drives them to others.  Only a holistic solution will work on such interconnected systems.  This is one of the arguments for industry regulation.

3 Habits of Highly Effective Regulation

In the end there are three attributes, or habits, that make regulation effective in achieving adoption and acceptance.

1. Education, education, education :: This is the single most effective method of driving adoption.  People want to know how to interpret, implement, and adopt the regulation to their business model.  I’ve seen more people fail to start because they didn’t know where to start than anything else.  People want to know if they can use a $0.10 piece of duct tape or if they need to replace the entire engine of the car.
2. Flexibility of controls :: This is an attribute of so many regulations due to the fact that they apply to such a range of companies, industries, size of organizations and the like.  Remember that 100% compliance is not the goal when system failures occur in groups.  The PCI DSS has what’s called “compensating controls.”  The EU Data Protection Directive has the “comply or explain” concept.  Even the ISO 27000 series do not mandate 100% adherence to each and every control.
3. More data for Risk Modeling :: Let’s consider this without getting into a debate over Frequentist vs. Bayesian statistics (as I’ll leave that to Alex Hutton).  The more data we have the more closely we can make educated decisions about how to evolve the standard, protect against failure, and make deterministic decisions about how to proceed.  More data will help us understand when we have reached an inflection point and ultimately determine when the rising regulation turns toward deregulation.

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.

Recently Nick Selby posted on FudSec his article on Showing the Oblomovs the Door.  For those who care, an Oblomov or Oblomovism is considered a lazy or apathetic person or belief.  The blog post claims that information security professionals are “well-trained, well-intentioned” but “reduced [to] a series of relentless box-ticking” due to being “saddled with compliance management.”

The blog post further claims:

The CEO who lets the Security organization become the compliance department has abdicated to the government and Payment Card Industry his responsibility to understand and manage organizational risk. That is a fiduciary breach of CEO responsibility to shareholders. In addition to firing your ass, this should also be a floggable offense.

I agree one should use compliance as a guideline but manage it with respect to the business process.  I disagree with the fiduciary statement on grounds that one cannot claim a breach based on sparse case study and singularity statements.  The writer says this to bring grandeur to their claim.

The important part of this statement is that we are focused on the individual company here and their personal responsibility.  Remember, if you ever want to get something done don’t pass the buck.

The author, frustrated with the current implementation of compliance, states, “I stomped away from trying to influence security as an analyst because compliance … has managed to suck every ounce of oxygen from the room that is the security industry.”

Let’s just remember that history has shown that in the absence of legislation there exists a downward spiral of corporate responsibility towards protection of customer/consumer information and the well being of others. To support this I point to the moments of punctuated equilibrium that lead to things such as the Food and Drug Administration (FDA), the Securities and Exchange Commission (SEC), marginally improved ecological laws in China, and the current global financial crisis — to name a few.

Let’s also take a moment to remember that regulatory compliance has been raising the bar of information security since 1999, starting with GLBA, then with HIPAA and SOX, and finally with PCI DSS.  Is it because PCI DSS impacts most all business verticals on a global basis that it receives the most abuse from those who feel burned out?

Might I remind you that without such efforts the number of data breaches would be higher, much higher, than we see now because people find it easier to blame someone or something else rather than take personal responsibility for their own work.  The Information Security Management Handbook, by Tipton and Krause, has a section on diffusion of responsibility.

People behave differently based on the perception of being part of a group as opposed to being an individual.  It has been commonly observed that people tend to work less in a group than as individuals when only group output is measured.  People, in addition, tend to feel less responsibility in a group than as a single individual.  The bigger the group, the lower the felt sense of responsibility. Social scientists call this diffusion of responsibility and the phenomenon is commonly observed across all cultures.

I believe that instead of blaming others, we as information security professionals need to become an agent of change starting with ourselves and our current environment and expanding outwards.

The blog then claims:

At this writing it’s unclear whether Black Hat and DefCon demonstrations will include the PCI-compliant account skimmers we’re heard of, but the fact that they’re out there stands testament to the Pyrrhic victory that is the PCI Data Security Standard.

Please remember, the PCI DSS is meant to protect against the electronic and paper theft of payment card data.  It is not meant in any way to prevent credit card skimming. If you wish to raise the issue of skimming, please use the correct approach which is to clarify the need for a more secure payment card.  That of course gives way to the larger question of what is proper capital allocation and the conundrum of offline transactions and backwards compatibility.

I agree, sadly, with the blog post when it says, “PCI is not the minimum standard, it’s the maximum effort that many organizations make.” The question I have is, based on historical precedent (see above): are we better off with or without a carrot-and-stick approach? What impact has HIPAA had on the security of health care records vs PCI on the payment card industry?  In which area do we see more movement?

Certainly, movement does not always imply movement in the correct direction, but I would claim that basic items such as PCI DSS Requirement 3.2 which tells merchants and service providers to not store sensitive authentication date post-authorization has done wonders to the security of our payment card data.  How better to secure the data than to remove it in the first place?  We are seeing trends in this direction more and more in this industry and others.

But isn’t it better to have a minimum standard than none?  What if the minimum was for companies to do nothing?

Jeremiah Grossman stated, “nothing did more to build webappsec awareness than pci-dss. Now we need something to improve webappsec security.” I could not agree more, but let’s please remember that without awareness of a problem you cannot bring clarity or correction. People love to lambaste and transfer responsibility to others, all the while stomping away from personal responsibility.

If your company or those around you fail to see the forest through the trees of ‘industry best practices’ when I wonder if they are fit to run the information security department.  Those who complain that ‘compliance’ is the problem are transferring responsibility to industry standards instead of working to secure their own infrastructure.

Do such standards need correction and evolution to mirror the evolving threat of attackers and the continued evolution of information security practices and technology?  Certainly!  I support Mr. Selby in his goal to drive higher standards and move towards risk management, but let’s do so by taking individual responsibility for our own management of risk.

Mr. Selby claims, “all this compliance stuff is preventing us from addressing risk and performing, you know, security.” Why?  Did someone tell you that you cannot secure your data? Did someone tell you that by using proper the proper risk management practices you claim work so well that you cannot pass the “minimum standard”?  I support you in questioning and ferreting out anyone who makes such statements.  For the rest of the unwashed masses, we need standards.

Mr. Selby ends his rant with a statement everyone should agree with, “Compliance – the state of being – is achieved as a by-product of well-managed risk, not through a relentless ticking of boxes”, which is then followed by high-level statements of positive thinking.  The problem is that we need some tactical examples and guidelines to match the ever increasingly vague strategic statements.  GLBA says to safeguard customer information, but how?  And left to their own devices most companies will chose the cheapest possible way to implement optics of compliance.

I argue, that the PCI DSS has given concrete statements to how one secure their infrastructure, while giving the flexibility one needs to adjust for business and risk management (e.g., compensating controls, wireless and end-t0-end encryption guidelines.)

The problem lies not with our industry “best practices” but with the diffusion of responsibility that happens throughout every company.  Let’s reference back to that Information Security Management Handbook article:

The effects of de-individualization and individualization are real and play a role in how users perceive their role in an information security awareness program.  In the credit card processing call center example, de-individualization can encourage theft, carelessness, and loss of productivity.

I’d like to stop the blame game and see everyone start at home, transforming their company and being neighborly enough to share the information and results with others.  Revolution has often come from emerging evolution of ideas and conversations. I commend Mr. Selby for the conversation, but wish it involved a greater focus on personal responsibility.

Take responsibility for your own security, risk management, and data protection. Start today.

Spam is one of those things we have grown to live with; right up there with junk mail and infomercials.  When we think of spam we usually imagine a Nigerian 419 email or something more sexual in nature.  But today I received a spam message that topped the list of niche markets — PCI spam!

The following is an email I received that purported to help you achieve PCI compliance.

This initially looks like a legitimate company that is trying to sell some snake-oil and make a buck on the uninformed small merchant, but it’s actually much worse.

It seems PCI has become so popular that even phishers and spammers have begun to capitalize on it, ironically stealing your credit card number under the guise of helping you become PCI compliant.

By the time I clicked on the link the URL (www.merchant-sol.info) did not resolve, but a quick WHOIS lookup revealed the domain for what it was.  Under the list of DNS servers it says:

Name Server:DUMMYSECONDARY.PLEASECONTACTSUPPORT.COM
Name Server:BLOCKEDDUETOPHISHING.PLEASECONTACTSUPPORT.COM

Sigh.  It seems there is no place sacred from phishing and spam.  Worst of all, it’s meant to exchange your credit card number for PCI compliance.  Perhaps we need PCI DSS Requirement #13: Do not use your credit card to pay for PCI compliance.

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.