(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!

David Spark here reporting for Tripwire at the 2010 RSA Conference in San Francisco.

What makes the mainstream news in security? High profile data breaches especially with credit cards. In an effort to improve the value of your organization’s security strategy and hopefully keep all of us out of the news, Bob Russo, General Manager of the PCI Security Standards Council explained what to expect from the new set of PCI standards.

PCI Security Standards Council (SSC) is an open, global forum responsible for PCI Security Standards. They exist because people simply don’t know what to do when it comes to PCI. PCI’s putting out three new standards this year. They are PA-DSS – Payment Application Data Security Standard, PCI PTS: PIN Entry Devices standard, and PCI DSS: Data Security Standard.

(more…)

I continue to hear comments that PCI DSS doesn’t work and that it should be modified or even eliminated. My favorite recent criticism was from Rep. Yvette Clarke (D-N.Y.) when she said “the standard by itself is simply not enough to protect cardholder data… I do want to dispel the myth once and for all that PCI compliance is enough to keep a company secure.” I find it interesting that so much fault can be leveled at PCI DSS in light of the facts that Verizon Business puts forth in their 2009 Data Breach Investigations Report. Here are some of their findings after investigating data breaches that compromised 285 million records in 2008 alone:

· Payment Card Data was the target in 81% of the breaches (98% of the records were Payment Card Data)
· 74% of breaches were caused by external sources
· 75% of the breaches were from 3 industries: 31% Retail; 30% Financial Services ; 14% Food Service
· Point of breach entry to actual compromise: 27% in minutes; 21% in hours; 29% in days
· Compromise to discovery: 16% in days; 25% in weeks; 49% in months
· Discovery to containment: 37% in days; 42% in weeks; 15% in months
· 81% of the victims were not PCI compliant

The last point—81% of the victims were not PCI compliant—speaks volumes about the spirit, intent and effectiveness of PCI DSS …. if it is treated as security best practice and followed on a daily basis rather than treating it as a checklist that must be passed annually. Until each of the above percentages changes dramatically, I think PCI DSS should be seen as a good security best practice to follow continuously.

Had Heartland Payment been using Tripwire’s Enhanced File Integrity Monitoring solution, they would have uncovered something amuck within hours or even minutes of being breached—provided the solution was utilized as described below and the alerts were acted upon.

Here is a simple summary of what Tripwire’s Enhanced File Integrity Monitoring solution would have provided the Heartland IT Security team, given the current public knowledge of the breach.

• Following the SQL injection, the key to the breach was the installation of the hacker’s package in Heartland’s infrastructure. Because Tripwire can continuously monitor for change, the installation of the “bad” code would have been detected quickly whether it was installed on a single server or migrated to other servers, even if installed in unallocated space or ADS. The alert would have triggered an investigation process to determine the unknown source of the code.
• Part of the final discovery of the malware was the tedious evaluation of temp files. Tripwire would have helped determine that the files were not associated with any known application; that would have raised a red flag.
• It has been stated that this breach continued for an extended period. To have accomplished that, the configuration of the server(s) would have been altered to allow the malicious code to become persistent through server re-boots. Tripwire’s continuous Configuration Assessment capabilities would have detected the configuration change causing an alert and providing detailed information to speed investigation and remediation.
• Finally, even though the details have not been revealed, it is likely that changes to Heartland’s network infrastructure must have taken place to ease the exporting of sensitive data out to the hacker. Tripwire’s ability to detect network device configuration changes (start-up & running) and then to immediately assess the changes against policy (CIS, PCI, etc.) would have been a red flag to Heartland’s security team.

But Heartland Payment Systems was PCI compliant! Why would the Tripwire Enhanced File Integrity Monitoring solution have helped Heartland find the effects of the breach any sooner? Because Tripwire doesn’t just detect change like so many simple file integrity monitoring products, or assess configuration information every once in a while. Instead, Tripwire determines if a detected change was expected and authorized, and if the same change was in compliance with policy. It does this on a continuous basis and generates alerts and remediation advice when the answer to either question is “no”.

No solution is going to stop every breach or bad change. But continuous detection and analysis of change to critical system, configuration or content files can dramatically reduce the risk and duration of malicious change.