On Risks of DLP

Imagine that some security controls can actually introduce additional risk to an organization (a useful discussion of this). DLP is, in fact, one of those controls. While engaged in my content-aware DLP research, I’ve come across a rich set of risks related to DLP technology (mind you, this is completely separate from a discussion of key risks to a DLP project). First, however, I wanted to explicitly exclude from discussion all those bizarre European privacy “risks” related to DLP monitoring. I’d rather lawyers hash it out before technologists can step in.

Other real or perceived risks I came across include:

• “Silver Bullet” syndrome related to DLP is definitely a risk; specifically, a perception that “owning a DLP box = having data security handled”, though less common now, is still around, causing damage, wasting budgets and making organizations misjudge their true defense strength.
• Overprotection, such as due to shifting DLP to blocking mode too soon or without sufficient thinking, often leads to DLP being abandoned and thus to loss of critical visibility across data access and usage activities. One can say that this makes the organization no worse than before they tried DLP, but think about all the energy and money that could have been spent elsewhere.
• “Documenting failure” using DLP full content capture capabilities is a risk for organizations that use their DLP tools as “incident response helpers” i.e. run without alerts or blocking, but with all policies enabled. Such deployments become rich repositories of legally discoverable history of negligence, incompetence and insider malice, potentially worth millions in legal settlement fees.
• Alert response and DLP tuning with no set  goals leads to obvious “opportunity costs,” and to time being spent on activities with no risk reduction impact (and thus NOT spent on focused data risk reduction). For example, starting with many DLP policies enabled (with no clear reasoning why) and then trying to make the volume of alerts go down is often a frustrating effort, that can be avoided if one focuses on one policy with a clear business reason first. 
• Endpoint stability (for endpoint and, sometimes, even discovery DLP components) is still there as well. Any piece of software deployed en masse on today’s fragile information systems will occasionally lead to downtime and even information availability loss. Also, can DLP agents be remotely exploited? <no comment>
• Theft of valuable data from DLP system itself presents an interesting, but, sadly, real  risk. A DLP system may contain “concentrated secrets cocktail”, ranging from payment card numbers to the proverbial new product plans. Who should access it? Who will access it on a regular basis? Who might be able to?

Any other risks you’ve seen?

P.S. My previous post (DLP: Discover First or Monitor First?) have sparked a lot of heated discussion in DLP-related LinkedIn groups. Check them out.

Related posts:

• DLP and Data Classification
• DLP: Discover First or Monitor First?
• On DLP and PCI DSS
• On DLP and IP Theft
• DLP and/or/for/vs Data Security
• On DLP Processes or “No DLP For Dummies”
• On DLP Research