Understanding PCI DSS compensating controls
Mike Rothman
Rating: -4.55- (out of 5)
|
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...
To continue reading for free, register below or login
To read more you must become a member of SearchSecurity.com
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."
The fact that loopholes exist in every major regulation shouldn't be a surprise. But it's important to know how and when vendors will use compensating controls as a way to justify the purchase of their products, and if it will hold up when an auditor is shining the spotlight on your attempt to skirt an issue.
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:
Database security – Securing your database is one of the least understood emerging categories of security. There are network-based gateways (from folks like Guardium Inc. and Imperva Inc.) and host-based monitoring options (Application Security Inc., Lumigent Technologies Inc.) that purport to monitor database transactions and apply a policy, determining which transactions are allowed based on a myriad of attributes (requestor, application, data type, data content, etc.).
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.)
Network access control (NAC) – Network access control has been portrayed by an increasingly desperate network security market (growth is slowing and innovation is scarce) as the cure to everything, including PCI DSS. The reality is quite different; at first glance, post-connection NAC can ensure only authorized parties access front-end applications and only proper resources access back-end databases. Based on the way most applications are architected, NAC isn't helping with customer data protection. Why? Because there are few servers that are authorized to access the database, and those few servers need to be able to do anything.
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.)
Leak prevention – Data or information leak prevention offerings take a "no blood, no foul" approach to protecting customer data. The data can be at risk, but these offerings stop the data from leaking out at the perimeter. By training the leak prevention product to recognize customer data and intellectual property, a line of last defense is established where a leak prevention gateway will ensure sensitive information stays put.
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.)
Email encryption – Since lots of customer data leaks via email, the idea of encrypting email with sensitive data makes sense. Unfortunately, there are lots of other ways for data to leak out, so at best email encryption is a partial solution. I don't envision the auditor being grumpy about email encryption deployment, but if that's all you've done from a compensating control standpoint, you'll be sucking auditor exhaust. Grade: F (It helps, but not by itself.)
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.
|
|
|
|
|
|
