The Payment Card Industry (PCI) Data Security Standard is all the rage in security circles. This isn't surprising
since HIPAA and GLBA are old news, and the Sarbanes-Oxley Act is opaque relative to how much security is required to stay on the right side of the auditors and examiners.
PCI DSS popularity is pushing every security vendor to jump on the bandwagon and position their wares as the "silver bullet" to make PCI go away. Compliance should be a fortuitous result of having a strong security program that protects private information and intellectual property with documented controls.
Sadly, there is no silver bullet for any of these regulations, so if you are looking for one, move along.
In my profession, I have encountered individuals who have tried to skirt regulations without getting into trouble. Version 1.0 of the PCI DSS made resistance easier due to an escape clause, referred to as "compensating controls." This clause acted as a loophole when a particular element of the regulation proved too hard or too costly to do correctly. Basically, an organization could make the claim that they had alternative protections in place to avoid meeting the strict requirements of the regulation, relative to data encryption. Since data encryption is hard, it was deemed necessary to give an alternative; it was unlikely a large portion of the covered entities would be able to comply – at least initially.
The recently released PCI DSS 1.1 standard partially closed that loophole, as discussed by Mike Chapple in his recent tip PCI standard, take two. A compensating control clause is only a good excuse after you've blown one examination. But the reality is the loophole is still in effect -- you just need to be a bit more creative in how you jump through it. Today, you must prove a "legitimate technological or documented business constraint" to apply a compensating control. This process is totally subjective based upon the auditor's view of "legitimate and documented."
A great majority of compensating controls will be deployed to avoid requirement No. 3, which provides guidelines for the protection of stored cardholder data. Why? Data encryption is difficult, expensive and can cause problems for applications, only contributing further to the difficulty and cost of implementing encryption. Implementing compensating controls to protect shareholder data without encryption is easier on the organization
Let's go through the most security elements covered by PCI DSS that are most likely to catch an auditor's attention, and discuss which ones present legitimate compensating controls:
If done correctly, database security is a legitimate compensating control. The database host must be protected because if that machine is directly compromised, data protection is nearly impossible. But short of encrypting all sensitive data at rest, a database security offering can provide appropriate protection. Grade: B+ (Your auditor will grumble a bit, but likely let you skate by.)
For an attacker, the path of least resistance is to attack and compromise an application.That means the data will be stolen from what is considered to be an "authorized" party. NAC isn't going to help protect that customer data by itself. Grade: F (Your auditor would need to be asleep to let this one slide.)
Theoretically, the concept holds water. If you can stop sensitive data from leaving your network, then you are meeting the spirit of the PCI DSS. Leak prevention technology should be used as another layer to verify protection if other defenses falter, since nothing is 100% secure. Grade: C (It'll probably work… until it doesn't.)
So where does that leave you? Basically the same place you started. If you can't encrypt the data at its resting place (as the PCI Standards Council would have you do), then you better be looking at a layered solution to provide adequate compensating controls with database monitoring and leak prevention. Taking precautions within the network and key applications (like email) certainly doesn't hurt, but they are not sufficient enough to make a PCI DSS auditor break out into a toothy grin.
About the author:
Mike Rothman is president and principal analyst of Security Incite, an industry analyst firm in Atlanta, and the author of The Pragmatic CSO: 12 Steps to Being a Security Master. Rothman is also SearchSecurity.com's expert-in-residence on information security management. Get more information about the Pragmatic CSO at http://www.pragmaticcso.com, read his blog at http://blog.securityincite.com, or reach him via e-mail at mike.rothman (at)securityincite (dot) com.