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.

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.

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.)

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

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

Branden reminds us:

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

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

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

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

Why Comply? Why Vaccinate?

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

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

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

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

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

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

Perspective

Part I

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

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

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

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

Part II

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

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

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

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

Economics of Immunization and Compliance

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

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

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

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

So what!

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

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

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

Recently the large story to hit the news, the thing people are all reading and writing about, is the story about how 1 guy (and 2-5 accomplices) were able to steal 130 million payment-cards in over three years, and finally got caught.  The question is, what if Albert “Segvec” Gonzalez (aka. Cumbajohnny) is an outlier?  A statistical anomaly.

Facts of the Case

Rich Mogull has a good overview of the indictment.  Wired magazine, the Washington Post (Brian Krebs), and the Wall Street Journal all have coverage.  Rich has an interesting comment that:

In the “drama” category, we learn that the main perpetrator is the same person who hacked TJX (and multiple other retailers), and was the Secret Service informant who helped bring down the Shadowcrew.

…

This indictment covers breaches of Heartland, Hannaford, 7-Eleven, and two “major retailers” breached in 2007 and early 2008.

…

This is the same Albert Gonzales who was indicted last year for breaches of TJ Maxx, Barnes & Noble, BJ’s Wholesale Club, Boston Market, DSW, Forever 21, Office Max, and Sports Authority.

…

The attacks both sniffed traffic and attempted to identify stored card numbers. They targeted data at rest and in motion.

The Wired article adds:

But these are just the latest in a string of high-profile breaches that have been connected to Gonzalez. He and 10 others were charged in May and August 2008 with network intrusions into TJX, OfficeMax, Dave & Busters restaurant chain and other companies.

…

Using a SQL-injection attack, the hackers allegedly broke into the 7-Eleven network in August 2007, resulting in the theft of an undetermined amount of card data. They allegedly used the same kind of attack to infiltrate Hannaford Brothers in November 2007, which resulted in 4.2 million stolen debit and credit card numbers; and into Heartland on Dec. 26, 2007. Of the two unnamed national retailers mentioned in the affidavit, one was breached on Oct. 23, 2007, and the other sometime around January 2008.

…

Gonzalez was a Secret Service informant who once went by the nickname “Cumbajohnny.” He was a top administrator on a carding site called Shadowcrew when he was arrested in 2003.

…

Gonzalez called his credit card theft ring “Operation Get Rich or Die Tryin.” As Wired.com previously reported, he spent $75,000 on a birthday party for himself and once complained to associates that he had to manually count $340,000 in stolen $20 bills after his counting machine broke.

Stephen Watt, a 25-year-old programmer who was working for Morgan Stanley, created a sniffing program dubbed “blabla” that Gonzalez’s gang used to allegedly siphon credit and debit card numbers from TJX and other companies and is facing sentencing this month.

The Wall Street Journal adds:

The Treasury Department recently reported that of the more than 55,000 incidents of wire fraud since 1998, more than half of them occurred in the past two years.

For the techie in each of you, I’d recommend Rich’s summary of the Visa/FBI/USSS data breach report in February 2009.

Allegations

From all accounts it appears that many of the major payment-card data breaches in the last three years can be attributed to a small handful of people, and perhaps one ringleader. Could this be a normal attack pattern, or were these individuals outliers?  If they were the crest of an even bigger wave of attacks, it does not bode well for corporate America, but if they are statistical anomalies then what would the world look like if we ignored them when measuring the success of the PCI program?

In 2003, Gonzalez, a carder in his own right, was arrested by the Secret Service and turned into a mole to allow them inside of CardersMarket, one of the largest carding rings in the world.  Though Gonzalez was outed at the time by Dave Thomas (aka. Ethics or El Mariachi), many people did not listen to his rants at TheGrifters.net.  Allegedly, Dave Thomas was at the time an informant for the FBI on the same operation.  Later that year, Gonzalez would replace Kim Taylor (aka. MacGyver) as the board manager.

In March 2004, Gonzalez expanded his domain by replacing Dmitry Golubov (aka Script) as board manager for CardersPlanet.

In 2008, Albert “Segvec” Gonzalez, Christopher Scott and Damon Patrick Toey were indited and accused of hacking into TJX Companies and thus exposing 40 million payment-cards.  This 2008 indictment named Aleksandr Suvorov (aka JonnyHell) of Estonia and Maksym Yastremskiy of Ukraine.  Could these be the two “Russian” conspirators that are mentioned in the current indictment of Gonzalez?

But Gonzalez would not have gotten very far had it not been for his friendship with Stephen Watt.  Mr. Watt, a 7 foot tall, 25-year-old programmer, wrote the packet sniffer “blabla” for Gonzalez to capture transactions as they traversed the corporate networks.  Interestingly enough, Watt “graduated from high school at 16 with a 4.37 grade point average and from college at 19″, but had a bug in the software that caused it to deactivate each time the POS was rebooted.

Outliers

Again, I begin to wonder what the world would be like if these personalities had not met or operated in unison.  What would the payment-card world be like without Gonzalez?  It may be a stretch to speculate that this one individual and his actions equate to outlier status. By this measure military dictators and oppressive regimes could also be named outliers even though their affect is quite impactful.

What we are really measuring here is the difference between potential energy and kinetic energy and the catalyst to convert matter from one to the other.  We can assume that there are vulnerabilities in every system and the grater the number the higher the potential energy.  The catalyst, in this case Gonzalez, plays the role in converting that potential energy (vulnerabilities) into kinetic energy (stolen cards and then cash.)  Without the catalyst the measured state would stay the same and as such represent a seemingly stable statistic.

We can ignore this alleged stability in the system by stating that all vulnerabilities have the potential of being converted into cash, but until they are such statements are meaningless (outside of theory modeling.)  To this point we measure vulnerabilities not by their size in population but by how frequently they are exploited.  Without a catalyst to convert the vulnerabilities they contain little value from a metrics perspective of data compromises.

Statistics

According to DataLossDB.org the number of payment-card numbers lost between 2007-2009 equates to the following:

2007: 111,957,179 records

2008: 13,439,242 records

2009: 130,965,494 records (to date)

The total number of records for (almost) three years time = 256,361,915 records.  So, let’s see what these numbers look like if we remove Gonzalez from the picture.  That’s right, let’s throw out the catalyst for the outliers and see what the world of data breaches looks like for the Payment Card Industry.

If we count up the number of records lost due to Gonzalez between 2007-2009 we have the following respectively: 94,000,000 (2007), 4,303,930 (2008), and 130,000,000 (2009).  The revised data for those three years would look as following:

2007: 17,957,179 records (down 84%)

2008: 9,135,312 records (down 32%)

2009:  965,494 records (down 99%)

Analysis

What can we learn from this data?  Well, one can speculate that in the absence of outliers like Gonzalez, the overall volume of credit card fraud is dropping.  In fact, without him we would be coasting through 2009 with very few payment-card related data breaches at all!  I won’t make the mistake you anticipate and confuse correlation with causation.

One could also conclude that payment-card related fraud does not follow a normal Gaussian distribution.  In fact, it appears that payment-card related theft and fraud is statistically closer related to the probability distribution of terrorism than traditional crime statistics.

Taking a business perspective one still needs to be on the lookout for attackers and carders who wish to target your business in an effort to “get rich or dye tryin”.  Wherever there is financial or payment-card data there will be those who wish to plunder and capitalize on it.  One thing we must remember is that underground carding is a business model, albeit an illegal one.