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?

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.