Dr Anton Chuvakin Blog (Original)

Security writing since the mid-2000s. New posts are mirrored from Anton on Security on Medium.

DLP: Education and/or Automation?

By Anton Chuvakin
Historical Archive Note: This post was originally published on the Gartner Blog Network on January 4, 2013 by Anton Chuvakin.
Original URL: http://blogs.gartner.com/anton-chuvakin/2013/01/04/dlp-education-andor-automation/ | Archive.org Snapshot

Is DLP an education tool or an automation tool? Huh? Why does it have to be an “or” question? Can it be both? Why so many questions? Smile

In any case, during my DLP research I have come across a set of peculiar attitudes about content-aware DLP:

  1. Since DLP is a non-transparent control, behavior change is its primary mission. The tools can block and encrypt, but ultimately MUST change behavior to reduce data risks.
  2. DLP tools can interact with users, but users are incorrigible. Unless we can automate the protection of data, we will fail to reduce the data risks.

Notice something interesting here? There is a philosophical disagreement among DLP users about its primary mission. 

Those in camp #1 will focus on educating the users and using DLP as “behavioral change amplifier.”   They will heavily rely on warning messages, notify/justify prompts and “real-time education” features (“please don’t email SSNs – here is a link to our approved secure data transfer facility”). Of course, they will block the most blatant data violations, but will use the act of blocking as an educational opportunity as well.  These people would celebrate when they see less attempts to send the data by the users rather than when they see more blocked attempts. Finally, they are  well aware of the limits of automation, especially when complex and potentially ambiguous pieces of information need to be protected.

Those in camp #2 will focus on tuning the policies for more reliable automated blocking, low “false positive” rates and will seek out ways of triggering various automated actions (such as encryption, access right changes, etc). Of course, they will grudgingly access that a DLP tool will occasionally become visible to users, but they would treat this as a “failure of automation.” They talk a lot about how “users are a security problem” and how “policies are there since we cannot trust the users.” Moreover, they only accept security features that work “despite the user” and “take the decision away from  them.”  (all quotes fictitious, of course).

So, what do  you think? Do you block since you cannot educate or do you educate since you cannot reliably block? Do you prefer to FORCE the users or to CHANGE them? Or do you simply think that these two must form a balance?

BTW, DLP Magic Quadrant 2012 is out.

Related posts: