Considering an Opt-Out Program on PCI Validation
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.
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.
- 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.
- 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.
- 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.)
- 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.
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
“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.
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?