PCI DSS Version 3.0: No Relief For Security Pros

It’s been almost a decade since the Payment Card Industry Data Security Standard (PCI DSS) was introduced to protect credit card data, but financial fraud seems to be getting worse, not better. If 2013 was the year of the data breach, then 2014 looks like the year of the data apocalypse with Target reporting a staggering 110 million records compromised.

Many security professionals accuse PCI DSS of being just one more in the confusing array of checkbox compliance initiatives bogging them down with paperwork instead of offering any real mitigation of risk. There's even an entire cottage industry of training classes, consultants and auditors focused on getting organizations compliant with this often-confusing standard. According to Verizon’s recently released 2014 PCI Compliance Report, organizations still struggle to maintain PCI programs, with the average level of compliance at 89.7% of all controls.

While there are only 12 requirements, don’t let the documentation fool you: PCI DSS compliance is hard. The schadenfreude surrounding the Target breach is misleading and frustrating. For anyone who actually works in a payment-processing environment, sometimes PCI DSS seems like a hill and sometimes it’s a mountain, often tricking one into thinking it’s easily achievable. Unfortunately, the recent release of PCI DSS Version 3.0 does little to make the standard any clearer for those of us who wrestle with it daily.

In an age where a Web application can be comprised of a whole series of devices and servers, tracking dependencies and limiting scope can be challenging while still attempting to maintain some sense of manageability of those systems. Defining and documenting scope has always been a major point in PCI DSS, but it doesn’t get easier with version 3.0, with the addition of requirements 1.1.3 and 2.4 that call for network diagrams documenting cardholder data flows and a device inventory of the Cardholder Data Environment (CDE). Additionally, the updated standard introduces a new pen testing requirement to verify segmentation.

Keep it simple by treating the CDE like a childhood game of cooties: If a device or system touches cardholder data, then it’s infected and must be contained or isolated.

[Read why the National Institute of Standards and Technology standards provide a strong foundation for an information security program in "Do NIST Information Security Standards Matter?"]

Moreover, the new standard doesn’t clear up some common myths and misconceptions about PCI DSS. For example, contrary to what some think, a wireless network is still subject to the standard, even if cardholder data doesn’t transit it. It’s untrusted and must be verified as isolated from the CDE by a firewall. You also have to implement processes that detect and identify unauthorized access points on a quarterly basis.

However, the language in the standard still seems unclear on this point because of context. Wireless (whether in scope or not) appears in multiple sections of PCI DSS Version 3.0, and in a culture of tl;dr (too long; didn't read), a document of 112 pages will put all but the most dedicated technologists to sleep.

PCI DSS 3.0 does nothing to clear up the confusion surrounding the Self Assessment Questionnaire (SAQ) and its categories. Just because you’re at a level of processing which permits completion of a self assessment, that doesn’t mean the requirements are optional. Unfortunately, the documentation for self-assessments are on a separate part of the PCI Security Standards website and the PCI DSS Self-Assessment Questionnaire Instructions and Guidelines document even seems to encourage the assistance of a Qualified Security Assessor (QSA) to ensure compliance.

Then there’s the dreaded compensating control. Used when an organization can’t meet an explicit requirement due to a technical or business limitation, this seems to be the infinite loop of PCI DSS and most likely to cause aneurisms in a security team. You’ll see professionals argue about compensating controls into perpetuity, with some trying to pass off the most ludicrous options.

While 3.0 doesn’t seem to make this easier to understand, the important thing to consider when implementing a compensating control is included in Appendix B of the standard: It must “meet the intent and rigor of the original PCI DSS requirement, provide a similar level of defense ...” and “be above and beyond other requirements.”

PCI DSS is a framework of specifications and guidelines, but vendors often add to the confusion by hyping their PCI-compliant products as an immediate solution to something that’s often less a technology than a people problem. Compliance often requires a change in business processes. If there isn’t leadership in place to drive collaboration across organizational silos, then those attempting to implement the initiative end up like Sisyphus crushed by the PCI boulder as it rolls down on top of them.

[Learn best practices for starting and maintaining a PCI DSS compliance program in Michele Chubirka's session, "Adventures in PCI Wonderland"at Interop Las Vegas March 31-April 4. Register today!]