Anton Chuvakin

A member of the Gartner Blog Network

Anton Chuvakin
Research VP
2+ years with Gartner
14 years IT industry

Anton Chuvakin is a research VP at Gartner's GTP Security and Risk Management group. Before Mr. Chuvakin joined Gartner, his job responsibilities included security product management, evangelist… Read Full Bio

Coverage Areas:

On DLP Processes or “No DLP For Dummies”

by Anton Chuvakin  |  October 25, 2012  |  5 Comments

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. Smile 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:

5 Comments »

Category: DLP security     Tags: ,

5 responses so far ↓

  • 1 Anonymous   October 26, 2012 at 4:14 am

    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.

  • 2 Anton Chuvakin   October 26, 2012 at 3:48 pm

    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….

  • 3 bati909   October 31, 2012 at 2:43 pm

    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.

  • 4 Anton Chuvakin   October 31, 2012 at 3:26 pm

    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.

  • 5 DLP and/or/for/vs Data Security   November 1, 2012 at 4:42 pm

    [...] Anton Chuvakin is a research director at Gartner's IT1 Security and Risk Management group. Before Mr. Chuvakin joined Gartner, his job responsibilities included security product management, evangelist… Read Full Bio Coverage Areas: ← On DLP Processes or “No DLP For Dummies” [...]