Wednesday, June 16, 2010

How PCI Leads to DLP?

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.
PCI Compliance: Understand and Implement Effective PCI Data Security Standard Compliance
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)
Possibly related posts:

Dr Anton Chuvakin