Login  |  Register  |  Contact

Understanding and Selecting a DLP Solution: Part 5, Data-In-Use (Endpoint) Technical Architecture

Welcome to Part 5 of our series on DLP/CMF/CMP; look here for: Part 1, Part 2, Part 3, and Part 4.

I like to describe the evolution of the DLP/CMF market as a series of questions a CEO/CIO asks the CISO/SGIC (Security Guy In Charge). It runs something like this:

  1. Hey, are we leaking any of this sensitive data out over the Internet? (Network Monitoring)
  2. Oh. Wow. Can you stop that? (Network Filtering)
  3. Where did all of that come from in the first place? (Content Discovery)

This is pretty much how the market evolved in terms of product capabilities, and it often represents how users deploy the products- monitoring, filtering, then discovery. But there's another question that typically comes next:

4. Hey, what about our laptops when people are at home and those USB things? DLP usually starts on the network because that's the most cost-effective way to get the broadest coverage. Network monitoring is non-intrusive (unless you have to crack SSL) and offers visibility to any system on the network, managed or unmanaged, server or workstation. Filtering is more difficult, but again fairly straightforward on the network (especially for email) and covers all systems connected to the network. But it's clear this isn't a complete solution; it doesn't protect data when someone walks out the door with it on a laptop, and can't even prevent people from copying data to portable storage like USB drives. To move from a "leak prevention" solution to a "content protection" solution, products need to expand not only to stored data, but to the endpoints where data is used.

Note: although there have been large advancements in endpoint DLP, I still don't recommend endpoint-only solutions for most users. As we'll discuss, they normally require to compromise on the number and types of policies that can be enforced, offer limited email integration, and offer no protection for unmanaged systems. Long term, you'll need both network and endpoint capabilities, and most of the leading network solutions are adding (or already offer) at least some endpoint protection.

Adding an endpoint agent to a DLP solution not only gives you the ability to discover stored content, but to potentially protect systems no longer on the network or even protect data as it's being actively used. While extremely powerful, it has been very problematic to implement. Agents need to perform within the resource constraints of a standard desktop while maintaining content awareness. This can be problematic if you have large policies such as, "protect all 10 million credit card numbers from our database", as opposed to something simpler like, "protect any credit card number" that will give you a false positive every time an employee visits Amazon.com.

Existing products vary widely in functionality, but we can break out three key capabilities:

  1. Monitoring and enforcement within the network stack: This allows enforcement of network rules without a network appliance. It should be able to enforce both the same rules as if the system were on the managed network, and separate rules designed only for enforcement when on unmanaged networks.
  2. Monitoring and enforcement within the system kernel: By plugging directly into to the operating system kernel you can monitor user activity, such as cutting and pasting sensitive content. This also allows you to potentially detect (and enforce) policy violations when the user is taking sensitive content and attempting to hide it from detection, perhaps by encrypting it or modifying source documents.
  3. Monitoring and enforcing within the file system: This allows monitoring and enforcement of where data is stored. For example, you could restrict transfer of sensitive content to unencrypted USB devices.

I've simplified the options, and most early products are focusing on 1 and 3; this solves the portable storage problem and protects devices on unmanaged networks. System/kernel integration is much more complex and there are a variety of approaches to gaining this functionality.

Over time, I think this will evolve into a few key use cases:

  1. Enforcing network rules off the managed network, or modifying rules for more-hostile networks.
  2. Restricting sensitive content from portable storage, including USB drives, CD/DVD drives, home storage, and devices like smartphones and PDAs.
  3. Restricting cut and paste of sensitive content.
  4. Restrict applications allowed to use sensitive content- e.g., only allowing encryption with an approved enterprise solution, not tools downloaded online that don't allow enterprise data recovery.
  5. Integration with Enterprise Digital Rights Management to automatically apply access control to documents based on the included content.
  6. Audit use of sensitive content for compliance reporting.

Outside of content analysis and technical integration, an endpoint DLP tool should also have the following capabilities:

  1. Be centrally managed by the same DLP management server that controls data-in-motion and data-at-rest (network and discovery).
  2. Policy creation and management should be fully integrated with other DLP policies in a single interface.
  3. Incidents should be reported to, and managed by, the central management server.
  4. Rules (policies) should adjust based on where the endpoint is located (on or off the network). If the endpoint is on the managed network with gateway DLP, redundant local rules should be ignored to improve performance.
  5. Agent deployment should integrate with existing enterprise software deployment tools.
  6. Policy updates should offer options for secure management via the DLP management server, or existing enterprise software update tools.
  7. The endpoint DLP agent should use the same content analysis techniques as the network servers/appliances.

In short, you ideally want an endpoint DLP solution with all the content analysis techniques offered by the rest of the product line, fully integrated into the management server, with consistent policies and workflow.

Realistically the performance and storage limitations of the endpoint will restrict the types of content analysis supported and the number and type of policies that are enforced locally. For some enterprises this might not matter, depending on the kinds of policies you'd like to enforce, but in many cases you'll need to make serious tradeoffs when designing data-in-use policies.

Endpoint enforcement is the least mature capability in the DLP/CMF/CMP market but it's an essential part of any comprehensive solution. Over time, all network-only solutions will add endpoint capabilities, and all endpoint tools will add network coverage. It's that combination, including content discovery, that moves us into Content Monitoring and Protection. Tools may be more restricted and less mature today, but this should even out over time thanks to product advances and the relentlessly increasing computing power of workstations and laptops.

—Rich

Previous entry: Slashdot Bias And Much Ado About Nothing (PGP Encryption Issue) | | Next entry: Encryption: The Maginot Line of Data Security

Comments:

If you like to leave comments, and aren't a spammer, register for the site and email us at info@securosis.com and we'll turn off moderation for your account.

By Adrian Lane  on  10/08  at  08:05 PM

1. Adrian’s Law of Inverse Data Stack to Value is the further down the stack you go, the less contextual information you have, and therefore the more guesses you have to make as to the value and meaning of the data, or the intention of use with any given data element.  The higher up the stack you go, the more contextual & transactional information you have, and can make much better security & policy assessments but at a performance and/or complexity cost. 
2. Regarding 3 key capabilities, it solves the mobile storage problem, but is missing a few key areas.  While I completely agree with one and two, but the third seems redundant.  Why?  An OS is nothing more than a resource allocator.  Memory, file system, network, et cetera. It’s the traffic cop for the computer. So I recommend that you abstract the third item (or add a fourth?), file system, to be something like ‘‘application’’ level.  In this way you cover access control systems, web applications, databases and other facilities like Windows Explorer, Bourne Shell, SSH, Eudora, or some other interface. Those are the end points depending upon the type of usage or transaction.
3. As long as we are talking about evolution, what happens when the majority of corporate intranets are automatically encrypted by the hardware?  I have a half dozen data points that indicate this is coming and it changes the landscape.  While I think you want to offer multiple ways to gather and examine data, the dominant source of information (network) could well start to vanish in the next 5 years. 
4. Good point on DRM.  I think it’s not just access control but other operational tasks as well IMO.
5. Incident reports ... managed by the the central management server?  Really?  Item 5, integration, may offer the right perspective of distribution of authority and assist in workflow.  Fraud detection and deterrence suggest that there is more than one copy.  I am not sure what the answer is here, and I am not sure there is a single trusted repository, only that there needs to be a method to provide some level of trust and authenticity.  There may also be a DRM based solution to this as well, but it would take me 5 pages to describe and it’s probably outside the scope of this thread.
6. "Over time, all network-only solutions will add endpoint capabilities ... ".  I think it’s already here. Looks what has happened in the database ‘‘activity’’ monitoring space, IDS and extrusion prevention. Seems like everyone has an agent now, implemented as either a protocol stack sniffer to an application aware agent.

By Kathy  on  01/02  at  01:12 AM

Just wanted to let you know you’‘ve saved me lots of poking around and trying to find some key components of what I should be looking for from vendors. Would love to see this all in one pdf type document. Do you plan on adding to this series?

By rmogull  on  01/02  at  01:23 AM

Kathy,

You can download it at: http://securosis.com/publications/DLP-Whitepaper.pdf

and it’s in the SANS reading room. Hope you like it!

By mehak  on  03/29  at  08:08 PM

Hi Rich,

This is great information, thanks for sharing this.  I have a question for you. I was wondering that if an enterprise does not have its data classified , it would be tough for any offerred dlp solution to work.

And i dont think, any dlp solution in the industry does data classification.  so is it safe to assume that , data classification is an important pre-requisite to buying a dlp solution?

How is data discovery differnet from data classification.?
thanks

By rmogull  on  03/31  at  07:46 PM

DLP doesn’t need classification, since it performs real-time analysis of content. Thus there’s no need for labels.

Name:

Email:

Remember my personal information

Notify me of follow-up comments?

Submit the word you see below: