Gartner Blog Network

DLP: Discover First or Monitor First?

by Anton Chuvakin  |  December 7, 2012  |  6 Comments

Should I DISCOVER where sensitive/regulated data resides in my environment OR DETECT when it is being leaked? Storage DLP first or network DLP first? Data-at-rest (DAR) first or Data-in-motion (DIM) first? What is more important, knowing WHAT can be stolen and from where OR WHAT is being sent out today?

Sorry, but “IT DEPENDS.” As many tough questions in life, this one has no single right answer. Successful data protection projects, whether for regulated data or corporate secrets, often start from a discovery sweep of an internal network. Looking for PANs, SSNs, known secret documents, customer records or whatever else allows the DLP conversation to start and the “lay of the data land” to become more clear. At the same time, they also often start from observing sensitive and regulated data flows out of your environment via email, FTP, web uploads, etc. This helps jumpstart the DLP discourse and creates a sobering realization of “Whaaaat!? This is going on RIGHT NOW!!?” Both are common and reasonable.

So, why discover first?

  • Learn the extent of sprawl of a particular type of data
  • Assess the complexity of the upcoming data protection effort
  • Gather ammunition for identifying and then engaging the data owners
  • Learn what to include in monitoring policies next

Why monitor first?

  • Observe (and, then, hopefully, stop) the most blatant and obvious leaks
  • Assess the priority of needed data protection efforts based on ongoing data movement
  • Easily get a taste of content-aware DLP technology without too much hard work (!)
  • Learn what to include in discover scans next

As a side note, few organizations would venture into “enforce first” as you need to know BEFORE you can act. Control comes after visibility (and, by the way, in some domain it never really comes…). One can discover first and then reduce, secure, monitor and protect what is discovered. One can also monitor first and then evolve to reduce the exposure. A sole exception I’ve seen is about enforcing something trivial like ‘block all USB access on endpoints’ which is hardly at the core of content-aware DLP.

Finally, if you’d absolutely push me to the wall and make me give a simple answer to a complex question, then go do network monitoring first… mostly because it is easier (= the most similar to netsec technologies) and often produces nasty (and thus deeply motivating) surprises.

P.S. this discussion does not remove the requirement to understand what you are trying to do with DLP and with data security in general. The real FIRST action is always ‘think’, not ‘buy’ or ‘deploy’. Don’t get those ideas :-)

Related posts:

Category: data  dlp  security  

Tags: data-security  dlp  security  

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

Thoughts on DLP: Discover First or Monitor First?

  1. Kenneth Ng says:

    I see the short answer as “yes” :-). Long answer is I believe this is an iterative process, where one will find information about the other, and feed back. Monitor the network first, see what you get. Trace back to the sources. Traces the processes to see where else that data ends up, add those sources to the network monitor to check out what you may be missing. Lather, rinse, repeat ;-)

  2. Ken, thanks for the comment. Indeed, “yes” is *ultimately* the answer, but what to do FIRST is still a question :-)

    An interactive process is indeed a good idea – monitor->discover->monitor, etc, etc.

  3. Good points on the Discovery aspect; I think a lot of companies don’t value (or focus on) the proactive angle enough.

    In the vast majority of cases monitoring will come first, if for no other reason than business units and executives won’t give the project enough attention unless they first understand a large present risk–something monitoring will provide.

    Ideally, Data Valuation with the business comes first (often it only comes after a breach, unfortunately). Initially, Network and Endpoint monitoring should be set up to focus on that highest value data.

    If you focus individually on business processes and data types, you may often pursue monitoring and discovery in parallel, providing the best visibility to understand the business process, and thus move rapidly toward enforcement.

    It’s far better to have excellent controls around 20% of your most sensitive data than mediocre controls around 80% of all your data. Managed services can be used to close that gap very quickly these days.

  4. Darrin, thanks for an insightful comment.

    >vast majority of cases monitoring

    Indeed, monitoring it is, but where? I am hearing some people start from endpoint monitoring, rather than from the network.

    >It’s far better to have excellent controls around 20% of your most
    >sensitive data than mediocre controls around 80% of all your data.

    Well, it *rings* true, but it is hard to say whether it is always true. Discovery might reveal data that you thought was in the 20%, while really it was in the 80%….

  5. […] DLP: Discover First or Monitor First? […]

  6. […] My previous post (DLP: Discover First or Monitor First?) have sparked a lot of heated discussion in DLP-related LinkedIn groups. Check them […]

Comments are closed

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.