(First a disclaimer: Although I am part of the leadership team of the PCI Scoping Special Interest Group, everything in this article are only my opinions, not anyone else’s, or an official position of the PCI Security Standards Council.)

Don’t get me wrong.  I think the mission behind the Payment Card Industry Data Security Standard (PCI DSS) is critical one: ““improve the security of global payment systems by protecting consumers, merchants and banks from credit information theft and loss and subsequent fraudulent activity.”

Given the fact that millions of cardholder records continue to be stolen show that there is a need for significantly increased discipline and rigor around the necessary controls required to protect cardholder data.

But as organizations mobilize to comply with the PCI Data Security Standard, they’re finding that it’s a huge project.  Like really huge.  Many organizations are finding that complying with PCI DSS will require more project hours than the organization has!  Even if the only project they had to complete was “comply with PCI,” even then, wouldn’t be able to complete it in one year!!

Even for organizations that don’t have over ten-thousand project hours dedicated to PCI, PCI compliance is still sucking up all the air in the room, starving a gazillion important projects of necessary resources.

One of the most frustrating aspects of PCI, though, is the standoff between the organizations who have to comply with the PCI DSS, and the Qualified Security Assessors (QSAs) that audit them for compliance.

The interaction may sound like this:

• Organization: “We have isolated our sales order entry systems as best as we can, and believe we are still effectively protecting cardholder data. Due to an architectural decision, we can’t partition off these systems from the rest of the business processes.”
• QSA: “I understand. But, we’re still liable for our role. So, your entire 20,000 systems will be in the scope of the PCI assessment.”

Maybe it’s not 20,000 systems that are being argued about.  Maybe it’s the CEOs laptop, even though the CEO isn’t entering customer orders or able to retrieve cardholder records.

I think this is an important topic.  So, here’s the topic that I’ll be submitting for this year’s Las Vegas #BSides conference.

“Properly Mobilizing the PCI Resistance: Lessons Learned From Fighting Prior Wars (SOX-404)”

I have noticed that there is a growing wave of discontent and disenchantment from information security and compliance practitioners around the PCI DSS.  Josh Corman has been an effective voice for these concerns, providing an intellectually honest and earnest analysis in his talk “Is PCI The No Child Left Behind Act For Infosec?”

The problem are well-known and significant: too much ambiguity in the PCI DSS, Qualified Security Assessors (QSAs) and consultant using subjective interpretations, existing guidance either too prescriptive or too vague, scope missing critical systems that could risk cardholder data, overly broad scope and excessive testing costs, excessive subjectivity and inconsistency, poor use of scarce resources, no meaningful reduction in risk of data breaches, and so forth.

For years, I have been studying the PCI DSS compliance problem, as well.  I have noticed many similarities to the PCI compliance challenges and the “SOX-404 Is The Biggest IT Time Waster” wars in 2005.  I was part of the leadership team at the Institute of Internal Auditors (IIA) where we did something about the it. We identified inability to accurately scope the IT portions of SOX-404 as the root cause of the billions of dollars of wasted time and effort, while not reducing the risk of financial misstatements.

I propose to present the two-year success story of the IIA GAIT project and how we changed the state of the IT audit practice in support of SOX-404 financial reporting audits.  We defined the four GAIT Principles, which could be used to correctly scope the IT portions of SOX-404.  We mobilized over 100K internal auditors, the SEC and PCAOB regulatory and enforcement bodies, as well as the external auditors from the 8 big CPA firms (e.g, Big Four and other firms doing SOX advisory work).  In short, we made a difference, in a highly political process that involved many constituencies.

I am attempting to do something similar with the PCI Security Standards Council, through my work as part one of the leaders of the PCI Scoping SIG (Special Interest Group).  My personal goal is to find a “third way” to better enable correct scoping of the PCI Cardholder Data Environment, and create a risk-based approach of substantiating the effective controls to ensure that cardholder data breaches can be prevented, and quickly detected and corrected when they do occur.

My desired outcome is to find fellow travelers who also see the pile of dead bodies in PCI compliance efforts, and work with those practitioners to catalyze a similar movement to achieve the spirit and intent of PCI DSS.

There is a better way…

I’ll be writing a lot more on this.  Here are some topics I’m hoping to cover in the next couple of weeks:

On GAIT and SOX-404:

• a history of the GAIT for SOX-404 project
• examples and analysis of inappropriate SOX-404 scoping
• the method behind the madness: why did GAIT work?

On it’s application to PCI:

• what principles can be ported over to PCI DSS?
• conversation with Josh Corman on “inside baseball talk: how does the PCI SSC and the SIGs work?”

And some very exciting news on how the PCI Scoping SIG is doing:

• the thought process behind the solution
• desired outcomes and guidance
• a report on our progress and work in process on solving this problem

And most importantly, what can you do to help?

Of course, the last point is likely the most important one.  There are things you can do to help the movement.  Interested in learning more, or is this a hysterical person on a lonely crusade against an imagined problem?

Thanks, and looking forward to your comments!

I’m a cancer survivor, and it strikes me that cancer and IT security breaches have something in common: early detection is crucial.

You see, 11 years ago, I caught my cancer (malignant melanoma) fairly early, it was treated quickly, and I’ve had no recurrence since then. This was possible because a) my wife noticed something suspicious and, b) I had it examined by a medical professional who knew what to look for.

And even with my (somewhat) early detection, the treatment was worse than I’d have liked – instead of removing only the cancerous spot, mine had spread a bit so the had to take a 1-inch clear margin all the way around the cancer (that’s 2 inches – about 5cm – across). A couple of weeks earlier and that might not have been necessary. Now, I know what to look for and am vigilant, so I hope to catch it early if I ever get it again. [you can find out more about detecting skin cancer at my personal blog]

With IT breaches, time is also of the essence. The longer you’re breached without realizing it, the more potential damage or loss your organization will experience.

Flying blind

If you look at recent studies, organizations are – as a rule – not very good at detecting breaches:

• Breaches go undiscovered and uncontained for weeks or months in 75 % of cases. — Verizon Business, 2009
• Average time between a breach and the detection of it: 156 days [5.2 months] — HelpNet Security, Feb 2010
• ““…breaches targeting stored data averaged 686 days [of exposure]” — Trustwave, 2010

That’s a reeeallly long time, no matter which figure you cite!

The challenge is shortening the breach-to-discovery gap. And you want to be the one who discovers it – not like a company I know of who found out their customer’s information was for sale on a hacker site when the FBI showed up at their door to tell them. [and no, I won't tell you who it is]

What’s the problem?

There are lots of issues that contribute to organizations having such a hard time knowing they’ve been breached. Here are some of them:

• Too many cooks in the kitchen
  This is when lots of people have access to too many sensitive or critical systems. You need to really get a handle on this if you have this problem, and focus on “least privilege” principles. If lots of people are adjusting systems, it’s hard to spot suspicious adjustments.
• Fuzzy roles
  This is a particular problem in small IT shops or, as I like to call them, “multiple hat” shops where one person may cover lots of different job functions. This might mean that there is little in the way of oversight / checks & balances that might detect inappropriate or accidental actions by a trusted individual.
• Unclear policies
  One of the biggest problems is when policies a) aren’t defined, and/or b)aren’t consistently communicated, and/or c) aren’t understood by the people who are supposed to follow them. Documentation, consistent communication, and education are critical.
• Lack of controls
  It’s one thing to be able to tell people what rules they should follow, it’s quite another to have the means to verify they are not breaking those rules. You need controls (processes, technology, oversight, independent verification, audit trails, and things like that) to allow you to evaluate what’s actually happen in comparison to what was supposed to happen. Automated controls are better than manual – people don’t pay attention consistently enough.
• Lack of accountability
  This is one of the biggies. This can occur when there is no “tone at the top” that creates measurable consequences when someone breaks the rules. If nothing happens when someone violates a policy, what good is that policy?

And I could add to this list for the next hour…

All of these issues are compounded by the overwhelming volume of information we’re tracking with security products, and the various disconnected “silos” of information and activity – the network team, the security team, the virtualization team, the firewall team, the ops team, the apps teams, the OS team, and so on.

It’s no wonder it takes most organizations multiple quarters to notice there’s a problem.

There is a way to fix this

The key is to get visibility into all the activities, events, and changes that relate to critical systems and assets; perform intelligent analysis of what’s happening (in relation to what’s expected or what’s specified by policy) so you can focus the organization on the exceptions; then apply automation so that this analysis of the haystacks of data happens automatically, all the time.

Ultimately, you want to focus the organization’s attention on “events of interest” that result in “changes of interest” – aka “suspicious activities that lead to suspicious results.”

This approach enables you to manage by exception – not by fire drill. If you want to get there, you can start by reading the IT Process Institute’s guide, “Security Visible Ops” – coauthored by my friend Gene Kim – or listen to Gene’s introductory webcast on this topic.

We have been talking with Gene about various audit horror stories. In this episode Gene aptly names this “How did we get hacked even though we passed the audit?” Compliance is a point in time if you approach it as a project you have to complete for a test. Many people approach compliance initiatives such as PCI or SOX404 in just this way. A point to consider is that when you are secure compliance is free – not vice versa.

At this point you have seen lots of videos of Gene (@realgenekim) talking about his areas of passion as well as interviewing others. The other day Gene surprised me with a topic for a post. For most of those videos I (@matthixson) have been the person behind the camera and Gene wanted to do a post in regards to that.  Here you go!