PCI 3.0 Pushes Security, Not Just Requirements

If you want to get a handle on PCI version 3.0, one place to start is compensating controls. You know the idea: You can't meet the letter of some PCI requirement, so you come up with an alternative security measure that your QSA confirms will produce the same result. Instead of having to twist your systems in knots over a requirement, you focus on making your systems secure. And that, in a nutshell, is what the new version of the PCI Data Security Standard is trying to do too.

Last Thursday (Aug. 15) the PCI Council released what it calls "change highlights" for the new version, which will officially be published in November and will go live on Jan. 1, 2014. There are some specific new requirements, but with version 3, the big pictureis that PCI wants you to focus on the big picture—ongoing security instead of meeting checklist requirements when a QSA comes to inspect. And while it all makes sense in context, it may be hard for some retail IT people to get from PCI-is-a-pain to PCI as a framework for doing business.

PCI 3.0 is actually intended to provide more flexibility in how systems are secured, according to PCI general manager Bob Russo, who talked about the new version to Bank Info Security. Instead of letter-of-the-law compliance at audit time, the focus is supposed to be on security that retailers can live with on a "business as usual" basis, validated more rigorously and consistently by QSAs.

In other words, instead of any three QSAs having five opinions about compensating controls, it all should be a lot less subjective. And instead of PCI compliance being no guarantee of actual security, good security should be a reasonable guarantee of PCI compliance. We'll know how that actually plays out once audits under the new version have been going for a year or so.

In the meantime, PCI 3.0 also adds some proposed requirement updates that clearly come out of the last few years of experience with attacks on retailers.

For example, Requirement 5 currently mandates updated antivirus software on all systems commonly affected by malware. The new version adds this: "Evaluate evolving malware threats for systems not commonly affected by malware" (emphasis ours).

Requirement 9 now says "Restrict physical access to cardholder data." The new version adds: "Protect POS terminals and devices from tampering or substitution."

And Requirement 2, which bans using vendor-supplied default passwords?And Requirement 2, which bans using vendor-supplied default passwords? PCI 3.0 clarifies that changing default passwords is required for application and service accounts as well as for user accounts.

The right way to do that, of course, isn't to check those passwords before the audit. It's to inventory everything in PCI scope, make sure all passwords aren't vendor defaults, and then change the default password on anything new that comes in scope before it actually comes in scope. That way the password change can't be forgotten.

But that also can't always be done if, say, the vendor is installing a system and the installers are required to make sure it's operating properly using the default password. That's where the new flexibility comes in—you get to choose when you'll change the default. You just need to do it as early as is practical.

How do you know what's in scope? You check the inventory of in-scope system components that PCI 3.0 requires you to develop under Requirement 2. How do you compile the inventory? It's anything connected to any system in contact with cardholder data, and you'll know that because the update to Requirement 1 mandates keeping a current diagram that shows cardholder data flows.

Maybe the requirement that best embodies the new philosophy is Requirement 11, which currently says you have to regularly test security systems and processes. That sounds a lot like testing a smoke detector. The update adds: "Implement a methodology for penetration testing, and perform penetration tests to verify that the segmentation methods are operational and effective." That's more like trying to set the building on fire to make sure the whole fire suppression system works the way it's supposed to. It's a really good idea for security, but it's a lot more than most retailers have been doing.

So this really is not just a philosophical shift. It's a philosophical shift that will have teeth—eventually. Although the completed PCI DSS 3.0 standard is scheduled to be published on Nov. 7 and become effective on Jan. 1, you'll still be able to conform to version 2.0 until Dec. 31, 2014, and some of the new subrequirements of 3.0 will just be treated as best practices until July 1, 2015.

In the meantime, download the Change Highlights document and start thinking about getting rid of your ideas about compensating controls. If PCI 3.0 works as planned, you'll be doing a lot less sweating over requirements—and a lot more sweating over actual security.