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: Hey, are we leaking any of this sensitive data out over the Internet? (Network Monitoring) Oh. Wow. Can you stop that? (Network Filtering) 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: < p style=”text-indent:20pt;”>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: 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. 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. 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: Enforcing network rules off the managed network, or modifying rules for more-hostile networks. Restricting sensitive content from portable storage, including USB drives, CD/DVD drives, home storage, and devices like smartphones and PDAs. Restricting cut and paste of sensitive content. 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. Integration with Enterprise Digital Rights Management to automatically apply access control to documents based on the included content. 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: Be centrally managed by the same DLP management server that controls data-in-motion and data-at-rest (network and discovery). Policy creation and management should be fully integrated with other DLP policies in a single interface. Incidents should be reported to, and managed by, the central management server. 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. Agent deployment should integrate with existing enterprise software deployment tools. Policy updates should offer options for secure management via the DLP management server, or existing enterprise software update tools. 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
