As I delve deeper into Data Loss Prevention (DLP) technology, I am noticing some uncanny similarities between select SIEM challenges and DLP challenges in large enterprises. I pointed out in this post on SIEM that security monitoring tools require associated processes in order to be useful and successful. Specifically, alert triage and security incident response processes have to be in place to make a decision and then to affect environment changes based upon the tool output.
DLP alert triage process and related incident response (IR) procedures have to be in place for DLP to be useful as well, but there are a few interesting differences. For example, DLP alert triage is MUCH more likely to involve a data owner or a representative of HR, legal, finance, etc (i.e. somebody from outside IT and information security teams). An incident response process will almost certainly involve somebody outside of IT. Thus, an IR process must have a strong handoff component so that the alerts are triaged, responded to and closed and then DLP rules are refined, if needed.
On a related note, what do you think are other mandatory processes and practices to have around DLP? I suspect the answer will depend on the use case type (regulated data vs intellectual property protection), DLP modules deployed (discovery, network, endpoint) and a set of other constraints, but let’s have a discussion here.
Unlike SIEM, DLP is used for automated blocking/remediation of detected issues. Oh my! I could not imagine that a company will actually use “encrypt sensitive documents discovered on desktops and ‘hide’ the key from the user, unless he is authorized," but some do exactly that. Why can they? Because it is not seen as “IT interfering with business," but BUSINESS affecting the business, a stark difference from most other security technologies. What other automated DLP remediation methods have you seen in common use?
There are some sad similarities. In the field, DLP technology seems to be affected by the “magic-box-itis” disease as much as SIEM. “Just get a DLP box and the data will never leak” is certifiably crazy, yet still common. Just as with SIEM, more companies like to BUY more than they like to USE the tools. Also, companies fail to understand that data can move throughout and outside of today’s ever-complex IT environments in a dizzying array of methods, both digital and analog. Just as with SIEM, the role of integration with other systems – both enterprise-wide (such as IdM) and local (such as endpoint tools) – is often underestimated for DLP projects.
Finally, a lot of DLP analysts state that DLP “must involve the business.” It sure makes sense! However, what should an information security team do if a business unit refuses to take responsibility for their own data? There has been no clear guidance on that, apart from checking your parachute. 
In essence, it creates an interesting “DLP conundrum”: DLP process must involve business, IT/infosec cannot do it alone, but business kicks the ball back into IT. So, what’s IT’s next move?
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
4 Comments
One thing you definitely need to have are answers to the question “Why didn’t DLP find X?” That question comes up frequently and regardless of the maturity or scale of deployment. It’s important to address with stakeholders before you embark on a deployment.
Generally speaking, it’s all shades of grey when it comes to effectiveness. There needs to be a focus on continuous improvement wrapped around the entire program. This takes more work than just care and feeding the technology platform and a focus on the broader hard problems you are trying to solve.
Thanks a lot for the comment. Indeed, “false negatives” as well as various tool misconfigurations leading to failed detection/blocking/discovery will be part of the research.
Even more importantly, ongoing tuning and “closed loop” process for deployment optimization will be a major focus. It takes more work to use the box than simply to buy it, and it takes waaaaaaaay more work to optimize one’s use of a DLP box over time….
Regarding processes I think you should also consider educational stage of the DLP implementation. It’s always good practise to start DLP as a educational (or mistakes prevention) tool rather than blocking tool. Start with blocking and you will be quickly stopped by business and kicked out.
It important to think about “environment changes based upon the tool output” also as changes in human behavior and security trainings for the employees.
This educational stage also has a good impact on the cooperation with the business. When you can show them that some users has to “break” some rules just to get things done (which can be seen in the exceptions reports), it starts a discussion about how the rules for DLP should look like.
Thanks for the comment. Indeed, the role of DLP for employee education and “re-education” will be covered. Some people think of DLP actions as blocks only, but I think a warning to offender, notice to data owner, etc play a huge role.