How Does PCI DSS Lead to DLP?

Saturday, June 19, 2010

Anton Chuvakin

Ebb72d4bfba370aecb29bc7519c9dac2

By now, it is increasingly obvious that PCI DSS does not (and likely will not) mandate the use of Data Leak Prevention (DLP) technology now or in the near future.

This applies to both discovery and monitoring/enforcement aspects of DLP. However, I am hearing that the percentage of DLP deployments driven by PCI DSS compliance is rising. What’s the story with that?

While a certain percentage of such deployments  simply point “in the general direction of PCI” to get budget (huh…nothing wrong with that :-)), I’d like to comment on the fact that DLP often makes a decent compensating control for many PCI DSS requirements.

First, unless you read the PCI book already, read Branden’s chapter on the Art of Compensating Control (this paper [PDF] has some of the same coverage).

So, here is where I have seen DLP boxes used as compensating controls (warning: evidence of QSA actually accepting it was not available in all cases, so use this advice at your own risk)

  • Stored data encryption (Requirement 3.4 “Render PAN, at minimum, unreadable anywhere it is stored”): DLP was used to compensate for the lack of STORED data encryption. The thinking was that if the data cannot leave the storage (…via the network), DLP was satisfying the same intent as encryption in the original requirement.  Would I agree that “it goes above and beyond” the original? Good question :-)
  • Access control (Requirement 7.1 “Limit access to system components and cardholder data to only those individuals whose job requires such access.”): DLP was used to reduce the chance of PANs falling into the wrong hands and thus satisfying the spirit of this requirement.
  • Monitoring access to data (Requirement 10.2 “Implement automated audit trails for all system components to reconstruct the following events:  […] All individual accesses to cardholder data”): while logging is a common choice here, DLP was used to make sure that all network access to cardholder data is recorded. The reason for choosing DLP over logging was due to the fact that the company didn’t know how to configure logging, but knew how to buy a DLP box :-)

Others examples of auxiliary use of DLP for PCI DSS included verifying that Requirement 4.1 (“Use strong cryptography and security protocols such as SSL/TLS or IPSEC to safeguard sensitive cardholder data during transmission over open, public networks”) is indeed being followed.

In this case, DLP served as a glorified PAN sniffer.

On top of this, the discovery components of DLP tools are often used for scoping. See some fierce debate on this issue, referenced from here.

To summarize, the use of DLP and standalone data discovery tools for PCI scoping is certainly not mandatory, but very helpful.

On top of this, one can use a DLP system to make sure that scope does not explode when people pull card data from the payment environment to development, QA, etc, etc.

Finally, I see the fact that PCI-motivated use of DLP tools is growing as something positive.

To me it says that people are following the spirit of DSS and not simply its letter (of course, one can also say that they are reaching for a DLP box as an easy way out).

Indeed, despite everything that was said above, deleting cardholder data is still a better way to make sure it does not get stolen or “lost”… (also, as a disclosure, I serve on an advisory board of a DLP company, nexTier Networks that has a product called Compliance Enforcer).

Cross-posted from Security Warrior

 

4801
PCI DSS
Post Rating I Like this!
Default-avatar
Dinesh Bareja Anton - points well made for DLP but if DLP is fortified with Information Rights Management (IRM) the shortcomings are addressed.

Taking the three areas mentioned:

Stored Data Encryption: While DLP cannot ensure encryption, IRM will deny access by any other means to the file which it encrypts while enforcing 'rights'

Access Control: IRM is built to specify authorized users/groups and provide granular level access controls to allow (or) deny print/edit/copy/pr_screen etc - while DLP stops at access policy enforcement.

Monitoring; again DLP monitors and logs data access and use (only within the perimeter) and IRM take this further by logging all access to controlled data inside and outside the perimeter.

A short note about DLP - IRM is here
http://blog.seclore.com/2010/04/dlp-what-is-required-to-complete.html

You are so right when you recommend use of solutions / technologies not mentioned in the standard. It will do well to consider limitations and extensions for any technology solution which will help meet compliance requirements.
1277349906
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.

Most Liked