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?
- 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
Read Complimentary Relevant Research
Five Golden Rules for Creating Effective Security Policy
Policy writing is a risk communication exercise that is frequently performed by people who lack the skills needed to create good security...
View Relevant Webinars
Identity Proofing for Secure Payments
Data privacy is dead. Web application security continues to fail, resulting in the numerous data breaches seen over the past three to...
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.