Chaordic Mind

This is a re-post of an article I wrote for IT Compliance Advisor, a part of TechTarget.com, in August 2009.  I find the material to be just as applicable now as it was then.  You can find a list of reference material here.

One of the problems that many companies face is staying ahead of the information security curve. Go too fast and you run the risk of wasting capital, but run too slow and you run the risk of being compromised. So how a company can escape the hamster wheel of pain? Be proactive in managing risk and implementing a maturity framework for the organization.

In an attempt to balance the two domains of cost and security, a continual tradeoff, many companies have implemented regulatory compliance standards. These are good tools for measuring ones security to a known industry baseline. The classic example of this is the Payment Card Industry Data Security Standard (PCI DSS). Using standards like PCI DSS, companies can measure their adherence to eliminating sensitive data and protecting the remaining in-scope systems.

There are two problems with aligning an entire information security model along any singular guideline. It should be noted that, in the absence of any information security program, PCI DSS is a very good baseline standard.

The first challenge is the 0-to-100 problem. Some companies start with no information security program and try to adhere to something like PCI DSS. Much like measuring the acceleration of a car by how fast it can go from 0 to 100 miles per hour, these companies struggle with getting from 0 to 100 percent compliance in under 12 months. For these companies this means implementing security for the sake of a deadline, which means not always having the time to test what works and what does not.

The second challenge is the security limiter problem. Once companies reach 100 percent adherence to a given standard, many times they stop developing their information security program. These companies then enter a vicious cycle of identification and remediation. Each year, their auditors alert them to a new set of issues and, each year, the companies fix those and then relax until the following year.

So how do we escape this endless cycle of identification and remediation? How do we provide a way for companies to go from 0 mph to 50 mph in year one, 50 to 100 in year two, and still be inspired to go from 100 to 150 in year three? How do we become proactive instead of being reactive? One option for addressing these problems is the capability maturity model (CMM) that involves risk management.

A CMM is nothing new or innovative. It’s a useful approach for managing the maturity in a system. The Computer Security Handbook 4th Edition reveals that CMMs originated from software development. This book states that a CMM “can be used as a way to assess the soundness of a security product builder’s engineering practices during the many stages of product development.” If a CMM can be used for measuring the soundness of engineering practices, then why not leverage it to measure the soundness of information security practices?

A maturity model encourages continual growth rather than strict adherence to Procrustean boxes of information security. It’s the mathematical equivalent of the integral or the continual variable transmission of an automobile. It provides a smooth curve instead of designated endpoints of information security. For companies suffering from the 0-to-100 problem, a maturity model enables growth from 0-to-50 initially, with the projection of moving from 50-to-100 at a later date. Companies that suffer from the security limiter problem have the ability to continuously and proactively plan information security development to parallel growing business needs, instead of an independent set of criteria.

The Information Security Management Maturity Model (ISM3, or ISM-cubed) provides us with the intersection of information security and a maturity model for growing an information security program. ISM3 describes the process this way:

“Rather than focusing on controls, it focuses on the common processes of information security, which are shared to some extent by all organizations.

Under ISM3, the common processes of information security are formally described, given performance targets and metrics, and used to build a quality assured process framework. Performance targets are unique to each implementation and depend upon business requirements and resources available. Altogether, the performance targets for security become the Information Security Policy. The emphasis on the practical and the measurable is what makes ISM3 unusual, and the approach ensures that ISM systems adapt without re-engineering in the face of changes to technology and risk.”

In fact, the ISM3 is based in part on extending the Systems Security Engineering Capability Maturity Model (SSE-CMM), which is ISO standard 21827. The SSE-CMM “describes the essential characteristics of an organization’s security engineering process that must exist to ensure good security engineering.”

In addition, consider the Building Security in Maturity Model (BSIMM), which is “designed to help you understand and plan a software security initiative.” As well there is the, Open Software Assurance Maturity Model (OpenSAMM) project that can “help organizations formulate and implement a strategy for software security that is tailored to the specific risks facing the organization.” These frameworks exist as tools for helping develop the maturity of organizations and software through the use of measured metrics.

And metrics is where all the magic really happens. Only by measuring the maturity of an organization and matching it to the development and progress of known attacks can we demonstrate that we are maintaining the balance between costs and security. There is a saying that if you and your friend are being chased by a bear, you don’t need to outrun the bear — you need only outrun your friend. In the world of ever-increasing compromises, many companies struggle to stay ahead of the curve. A maturity model, with proper metrics, can help your organization do just that. The best part? Companies that implement a maturity model and show measured growth are many times more likely to adhere to industry standards such as the PCI DSS.

This post clarifies an earlier one “Considering an Opt-Out Program on PCI Validation“ and helps explain how PCI compliance validation is changing based on risk measures present in the merchant’s environment.  Regulation and deregulation cycles happen in response to market forces.  In this case selective deregulation is happening in the form of reduced validation based on risk and fraud reduction measures present in merchant organizations.

Present State

When many companies think of PCI compliance they immediately think of a third-party QSA auditor.  For mature organizations this is the old way of thinking as both Visa and MasterCard permit merchants of any level to self-assess.

• Visa (Inc. and Europe) permits a report on compliance from an internal auditor provided it is signed off by an officer of the corporation.
• MasterCard permits self-assessments but internal auditors must “attend PCI SSC ISA Training and pass the associated accreditation program”

Although organizations must validate annually, they are relieved of this in the following  situations (as noted by Simon Sharp):

• Visa Inc.: merchant does 75%+ EMV transactions = no requirement for ongoing external assessment (major abbreviation)
• Visa Europe: merchants meet 1-4 milestones of Prioritized Approach are in a safe harbor even if breached (major abbreviation)
• Visa Asia: merchants who implement end-to-end encryption or process EMV chip transactions in countries where iCVV penetration is >75% have the following options:
  • Validated compliance with milestones 1-4 of the PCI SSC’s Prioritized Approach are recognized as fulfilling Visa PCI DSS validation requirements.
  • Attested to not storing prohibited data and process EMV chip transactions in markets where iCVV penetration is higher than 75 percent – you may define merchant level by the annual volume of non-chip transactions.

Reducing Risk = Reduced Validation

Visa Inc’s Technology Innovation Program (TIP) notes organizations that reduce fraud risk using technologies such as EMV (Chip/PIN) no longer need to validate compliance annually.  Visa Europe has their own version of TIP that goes a step further to say that for merchants who validate against the Prioritized Approach 1-4, Visa Europe will:

• waive penalties for non-compliance or non-progression
• grant ‘safe harbour’ from penalties and allocation of incremental counterfeit fraud losses in the event of a data compromise

Sure there are caveats and I’m not certain what “allocation of incremental counterfeit fraud losses” entirely means, but the idea that a merchant will achieve safe-harbor from anything is a pretty big carrot with which to lead merchants.

Certainly the pendulum has moved from encouraging compliance to encouraging risk and fraud reduction.  To this end the Visa has changed from incentivizing compliance, via the Visa CAP program in 2007, to incentivizing risk and fraud reduction, via the Visa TIP programs in 2011.

PCI Deregulation

Perhaps it’s premature to say that PCI compliance as an industry is in a deregulation phase.  Clearly PCI compliance for regions that have not seen wide adoption such as Asia/Australia still need movement towards full compliance and validatoin.  Conversely, if a merchant has >95% of transactions using EMV (Chip/PIN) with iCVV and CDA authentication – the need for PCI compliance may be limited.

Although deregulation may never fully occur, the need for annual third-party validation is no longer necessary for companies that have either: reduced the risk to payment card data or have highly-mature internal controls and validation capabilities.

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.

Before we jump in, I want to let you know that I am very supportive of the increased levels of education.  As you may have read in my 3 Habits of Highly Effective Regulation, education is #1 on my list.  There is plenty of information on my old blog PCI Answers, my old PCI forum, the PCI SSC website, and Visa Alerts.

The PCI SSC Special Interest Groups (SIGs) have and will continue to release information that, although it does not trump the PCI standards, helps to clarify the interpretation and implementation of them.  The following is an “un-boxing” of the PCI Reference Architecture for the PCI DSS 2.0 Compliant Clouds as published by Cisco, VMware, HyTrust, Savvis and Coalfire.  The tagline used is that these companies are “all core members of the PCI [SSC] Virtualization Special Interest Group (vSIG)”.  It is important to note two things:

1. The PCI Reference Architecture is created by many, many vendors.  As much as I love industry bodies weighing in, I would love to have seen a non-vendor name on the cloud architecture.  There is something very postured about a document made up entirely of vendors.  “Here, I have this thing called a PCI-Cloud, that if you configure in my data center, with my products, assessed by my QSA all will be OK!”
2. The PCI Reference Architecture is NOT an official document released under the Virtualization SIG by the PCI SSC.

The 19 page paper poses some interesting questions and makes some casual comments.  Let’s deconstruct the document, through the lens of a practitioner, educator, and analyst.

First, in the opening paragraphs they violate my “standards are technology agnostic” rule by bringing up that somehow guidance is needed before one can assess compliance in the cloud.

The terms “virtualization” and “cloud computing” do not exist in PCI DSS Version 1.2.1. This version of DSS does not provide specific advice about whether CDE system components need to be physical. This is of no surprise as it was developed before virtualization technologies gained wide spread adoption. In PCI DSS Version 2.0 „System Components‟ include virtualization technology (hypervisors) and virtual system components such as virtual machines, virtual switches, routers and networks, virtual appliances, virtual applications and desktops.

It is important to remember when reading this and other documents, that data security (and compliance) is highly dependent on the use cases.  For example, we all thought we understood scope using network segmentation of physical systems, but how do we define scope in a virtualized world?  How does the scope for a distributed call center differ from that of a brick-and-morter retail environment?  What are the scope considerations of Virtual Terminals or administrative and management systems?

One could just as easily have said that version 1.2.1 of the PCI DSS did not use the terms “call center”, “data warehouse”, “pre-authorization”, “data aggregation” or a plethora of other terms, and as such the shroud of mystery exists as to how PCI compliance applies to these areas.

Furthermore, neither do the terms Tandem, voice response unit (VRU), or cell phones exist in the PCI DSS and as such one may not have clear guidance on how to assess these environments.  Taking this approach is simply defeatist – but this is where the clarification documentation corrects these false assumptions, which I applaud.  Even though the paper outlines an arguably biased use case, it does explore the efficacy of it and as such adds to the pool of possibilities.

3 Challenges

The document presents us with three “challenges” of PCI compliance in the cloud, all of which are valid and important points:

1. If an in-scope CDE system component is virtualized, can it be adequately protected to meet all the PCI DSS requirements? What else becomes within scope?
2. How can virtualized system components within a CDE be co-mingled with virtualized system components (servers, network components, security components, management and monitoring components, and such) used for non-CDE functions? Can CDE virtual system components reside on the same physical system as non-CDE virtual system components and still achieve PCI DSS compliance?
3. How can adopters of emerging technology satisfy the intent of PCI DSS and adequately protect cardholder data without any specific guidance?

Remember that there are no precise answers to the above questions, only rather accurate answers with a relative probability density.  Which is to say, the answer is highly dependent on the use case.  Still, it is may times more important to know the right questions than to know the right answers to the wrong questions.

Let’s quickly answer question #3.  The intent behind the PCI DSS is to prevent the electronic and paper theft of payment card data. Regardless of technology, all architecture and guidance documentation should keep this mantra in mind.  Emerging technology can satisfy the intent of the PCI DSS as long as it is properly configured and maintained to achieve the the goal of payment card data security.

Operational Issues

The case studies base their configuration and environment on a list of assumptions that they enumerate.  In this sanitized case study all the proper controls are in place.  For example:

Hosts are hardened according to VMware‟s hardening best practices using the HyTrust Appliance. They are also routinely assessed for configuration drift, and automatically remediated depending on policy.

Pardon? I don’t thing many companies do this in their current environment, much less after having moved to a cloud based architecture.  I understand they listed the assumptions to focus on the architecture, but I want the reader to turn those assumptions into a TO DO or ACTION ITEM list.  All too often we make assumptions.

What is one of the most common assumptions many people make when moving to the cloud? People assume that the cloud provider will handle all roles and responsibilities related to data security and compliance.  Hey, since nobody defined who has to harden the servers let’s just assume the cloud provider is, since after all they are PCI compliant, right?  Wrong!

Before engaging a cloud provider, even one that validated their service offering as PCI compliant, make sure you understand the delineation of information security roles and responsibilities.  Again, the architecture is a framework but the use cases dictate security measures.

Conclusion

My favorite part of the paper is that it concludes by reminding you that IT IS POSSIBLE TO BE PCI COMPLIANT IN THE CLOUD!

Multi-tenancy and mixed-mode: CDE VMs and non-CDE VMs can be co-mingled on a cluster of hypervisors as long as adequate controls are implemented and validated to ensure proper isolation. Network controls and communication must be tested in the same or similar fashion as physical environments to demonstrate segmentation.

Update (per feedback from @Beaker):

A more complete conclusion is to remember the following when building/selecting a PCI compliant cloud:

• Yes, you can be PCI compliant in the cloud, but not every cloud is PCI compliant.
• This PCI Reference Architecture is just one of the many ways one can be compliant in the cloud
• The type of data you retain (payment card data vs personal health information) and the use case of your environment (call center vs single location office) will determine what configurations are required for adequately protecting that data according to industry standards
• Using a PCI compliant cloud provider will not make you PCI compliant

People love to talk about Cloud and they love to talk about PCI. In the past two years the mashup of a PCI Compliant Cloud has been on the forefront of many peoples’ mind.  This post will outline the three key rules of [PCI] Compliance in the Cloud.  To introduce these rules, I’ll ask the question, “can any firewall be used to segment a network?”  The answer is a resounding “No. Only a properly configured firewall can be used to segment a network.”  In the same say, “Can any Cloud be PCI compliant?” By now you should be saying, “No. Only a properly configured Cloud can be deemed PCI compliant.”

3 Rules of Cloud Compliance

1. Compliance is based on the service being delivered, thus we cannot compare PCI-compliant-cloud to PCI-compliant-cloud until we compare the service levels.  Much like a SAS-70 (third-party assessment of a service provider) that only assesses the “control objectives” as defined by the service provider, saying one is PCI compliant in the cloud is situationally dependent on the control objectives or service levels being offered/assessed.

Even if we examine, Infrastructure as a Service (IaaS) the level to which one is validated as compliant is only that which the service offering delivers.  Depending on the level of service the IaaS provider offers may determine the level of effort remaining for the customer to be fully PCI compliant.  For example, the following are three different levels of service offered by hypothetical IaaS Cloud providers:

• A base operating system – in which case the customer must configure it securely according to PCI DSS Requirements 1-8 and 10-12. In addition they may require an independent PCI assessment.
• A hardened operating system and managed security services – in which case the customer must secure the data and manage security alerts according to PCI DSS Requirement 3 and parts of 10 and 11. In addition they may require an independent PCI assessment.
• A hardened operating system, managed security services, and professional service offerings – in which case the customer must verify the outsourced team has properly secured the data, manages security alerts, and performs an annual PCI DSS assessment of the client’s environment.

If you are interested in a good description of service delineation for PCI compliance, check out this example coverage summary table. It clearly shows what they do and what their customers must do to achieve PCI compliance.

2. Compliance is only as strong as the security of the implementation.  (See also: the opening paragraph of this post.)  People love to hate PCI Compliance in the Cloud.  They say it’s not possible.  They ask about multi-tennancy.  They say many things, but at the end of the day if you can secure data in the cloud then you can be compliant in the cloud. It may not be the way you want to configure your systems, and not every implementation can be found compliant, but it’s possible.

The end result is that, YES, you can be PCI compliant in the Cloud – it just depends on how you’ve secured the configuration.

3. PCI compliance for a company is based on their individual compliance plus that of any outsourced vendors.  Migrating to a PCI compliant Cloud vendor will not magically make your entire enterprise PCI compliant. It will not obviate you of your PCI responsibility.  At a minimum, all organizations that use their own merchant ID must comply with PCI DSS Requirement 12.8, which states that organizations must verify proper third-party contracts exist with their cloud vendors and to check the annual PCI validation of their cloud provider.

PCI compliant Clouds can only enable compliance, they will not make you fully compliant.

Notes

In 2008, Chris Hoff asked on his blog if a very specific implementation of Cloud could be PCI compliant.  He received a variety of answers that ultimately pointed to Rule #2.  Although not every cloud may be PCI compliant, there are implementations that can (and have) validate as compliant.

In 2009, Martin McKeay blogged in response to verbiage from Amazon EC2′s PCI compliance statement that one cannot be compliant in that cloud. I actually think Amazon did the right thing by directing users to only accept payments via their Flexible Payment Solution (FPS).  Instead of trying to educate the millions of end users on how to secure their systems and achieve PCI compliance, Amazon make it simple by telling them to direct payment acceptance to a single, secured system.

In 2010, I updated a my 2009 SOURCEBoston presentation on PCI Compliance in the Cloud to discuss if PCI Compliance will Help or Hurt Migration to the Cloud.  This webcast clearly states that, YES, you can be PCI compliant in a cloud environment, just not in every cloud.

I’ve also done two podcasts on PCI Compliance in the Cloud.  One in 2008 and another in 2009.

• Cloud Computing and PCI Compliance (part 1) [2008]
• Cloud Computing and PCI Compliance (part 2) [2009]

I’ve waited longer than usual to write about my feelings on the newly released PCI DSS and PA-DSS v2.0 standards by the PCI Security Standards Council.  I’ll give my own impression and then do a round-up of the various other blog posts and reactions to the update.

Executive Summary

Don’t panic! This too shall pass. (It’s true.)

Timelines

Since v2.0 was released October 28, 2010, the big question is when do I have to start using it and how long as I used v1.2.1?

• PCI v1.2.1: Can be used through the end of 2011. Organizations that are working under v1.2.1 must submit final reports no later than December 31, 2011.
• PCI v2.0: Reports using v2.0 will not be accepted prior to January 1, 2011. Any assessment started after January 1, 2011 should begin to use v2.0.  Any assessment started after December 31, 2011 is required to use v2.0.

Changes Summary

The PCI Council moved from a two (2) year to a three (3) year standards cycle meaning the standards will stay static until 2013.  Tastes great vs Less filling?  People will say this is bad because it does not change, but as Bob Russo stated [26:30] in his podcast with Martin McKeay, “as the landscape changes there is an errata process that involved in the standards. So ee have the ability to issue errata anytime we need to, and if there is something that affects the standard and we have to address it immediately we are able to do that.” In addition, there are the various Special Interest Groups (SIGs) creating content and clarification in areas such as: scoping, encryption, tokenization, virtualization, Chip and PIN, wireless, etc.

The actual changes to the standards were more evolutionary than revolutionary.  This means they were clarifications and consolidations rather than major changes.

The #1 change to impact the industry is not the release of v2.0 of the standard, but release of the PCI Scoping Guidance documentation (still to be released) from the PCI SSC Special Interest Group (SIG) on Scoping. (Full disclosure, I participate on the Scoping SIG.) The scoping SIG is lead by Gene Kim, founder of Tripwire, and include participation from QSAs and merchants alike.  This guidance documentation has the potential to clarify the way we look at the application of every control.  I believe it will bring standardization to the scope of assessments.

Check out Gene Kim’s presentation: 2010 07 BSidesLV Mobilizing The PCI Resistance 1c

For details on changes to the standard, ‘I recommend reading the following two summaries:

• Qualys tech has a nice writeup of the key changes
• Davi Ottenheimer has a good writeup on the Flying Penguin

The key changes I want to highlight:

• Virtualization: Yes, PCI DSS Requirement 2.2.1 is updated to use the word “virtualization” and it’s included in the overall scoping documentation as well.  I’ll defer to Chris Hoff’s writeup for details. Remember that compliance standards should be “technology agnostic”, as such any new technology can [theoretically] be used to comply with the standards as long as they are properly secured.
• Risk Management: The emphasis for risk management increases.  It started with PCI DSS Requirement 12.1.2 which notes an “annual process that identifies threats, and vulnerabilities, and results in a formal risk assessment.”  Now, PCI DSS 6.2 expands this to risk ranking vulnerabilities with, “establish a process to identify and assign a risk ranking to newly discovered security vulnerabilities.”  Though this is a recommendation until June 30, 2012 when it becomes mandatory, I don’t understand why anyone would NOT want to take a risk based approach.
• Secure SDLC: The PCI DSS Requirement 6.5, formerly applicable only to “web applications”, now applies to all developed applications.  It is no longer tied to OWASP but now recommends best practices such as the OWASP Guide, SANS CWE Top 25, CERT Secure Coding, etc.

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.

I write this more for myself to keep track of things I’ve been up to so I can both reflect and track activity. This blog itself is a much larger representation of the same.  That caveated, here’s some recent events, talks, and items I’ve participated in:

• ShmooCon :: PCI: An Existential Threat To Security As We Know It? – Joshua Corman, Michael Dahn, Anton Chuvakin, Jack Daniel (5-7 February 2010)
• BrightTALK :: Evolution of a Standard: How Compliance Regulations Get Made (25 Mar 2010)
• Information Security Magazine :: PCI update could mean clarity or confusion (Sep 2010)
• BrightTALK :: Does PCI Compliance Help or Hurt Migration to the Cloud? (9 Sept 2010)
• BrightTALK :: Changes in the Payment Card Industry: Standards & Implementation (23 Sept 2010)
• Black Hat :: Expanding Compliance into Critical Infrastructure (23 Sept 2010) [Mike Dahn and James Arlen, moderated by Jeff Moss (Dark Tangent)]

Attended but did not present:

• RSA San Francisco 2010
• I-4 San Francisco 2010
• SourceBoston 2010
• Security B-Sides San Francisco, Las Vegas, Boston 2010
• Electronic Transaction Association (ETA) 2010
• PCI SSC Community Meeting (Orlando, FL) 2010

(I’ll update this later in the year as things progress.  There are a few other events that aren’t open to the public but I’ll try to list/blog/share the presentations regardless.)