Blog post


By Anton Chuvakin | November 30, 2012 | 2 Comments

securityDLPDenial of Service

The dirty not-really-a-secret of DLP is that most DLP technology is deployed because of either a compliance requirement (usually an implicit one) or a need to protect regulated data. Note that those, though similar, are NOT the same: the former is often about checking the box, while the latter is about safeguarding specific third party data, entrusted to an organization. Keep in mind that no regulation or mandate today explicitly states, “procure and deploy DLP technology.” PCI DSS, as of version 2.0, almost mandates DLP data discovery functionality by stating that a merchant should “confirm the accuracy of their PCI DSS scope by identifying all locations and flows of cardholder data.”

Here are a few random – and hopefully useful – thoughts related to regulatory use of DLP that were inspired by my recent conversations:

  • Before you safeguard it, consider deleting it! This may not work well for sensitive corporate information, but it sure works for regulated data. As we say in our PCI DSS book (Chapter 7, “Protecting Cardholder Data”), “dropping, deleting, not storing, and otherwise not touching cardholder data is the best single trick to make your PCI DSS compliance process easier.” And then you can “DLP the rest of the way”, if you insist.
  • Data sprawl (discussed in recent GTP research) affects all types of sensitive data. Card numbers, financial data, healthcare records and new product plans all tend to sprawl and leak, hindering protection efforts. Fighting this war seems easier for regulated data than for sensitive business data though! Still, you fight the sprawl – but the  sprawl also fights you, and the information shows up at partner systems, vendor systems, cloud provider systems, etc.  DLP is ultimately a lost war, but you have some choice on how you lose it.
  • Thus, compliance DLP projects are typically easier than IP protection projects.  This has a few implications, such as “if your organization is having trouble with a compliance-focused DLP implementation project, it is very likely not ready for an IP secrets-focused project.” A security team should learn from the former, before starting the latter.
  • Broken and risky business processes lead (led?) to such blatant PCI DSS compliance failures as “PANs on public web servers”, “emailed SSN lists”, etc. My informal poll of QSAs indicates that even the most crazy ones are not yet gone (even if rare). A DLP tool can sometimes work well to plug such blatantly obvious broken processes at lower cost than actually fixing the process.

Regarding the actual use for DLP for PCI DSS,  a use of DLP boxes as compensating controls  is common as well (warning: evidence of QSA actually accepting it was not available in all cases, so use this advice at your own risk). For example:

  • 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 because the company didn’t know how to configure logging, but knew how to buy a DLP box 🙂

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 PCI 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”…

Related posts:

The Gartner Blog Network provides an opportunity for Gartner analysts to test ideas and move research forward. Because the content posted by Gartner analysts on this site does not undergo our standard editorial review, all comments or opinions expressed hereunder are those of the individual contributors and do not represent the views of Gartner, Inc. or its management.

Comments are closed


  • Clay Keller says:

    One difference between your standard “vulnerability management” remediation efforts, and DLP finding remediation efforts, is that DLP findings are often owned by direct end users on end user systems. So instead of working with an application development or database team, you are often working with a non-technical end user.

    This different ownership structure can be a new challenge depending on the size of your organization. Those end users may not have any management direction or support to help resolve your issues, and may view you as just another IT person trying to make their job harder.

  • You hit upon one of the (of not THE) differences between DLP and other security tools, as I’ve discovered so far.

    BU people own the information and are unlikely to “be nice” to “meddling IT security types.” Some of the analysts here even go as far as to say “if business unit mgt is not on your side, drop the DLP project”…..