Security Manager's Journal: The ins and outs of extending DLP

I love DLP! That's not a statement that would sell a chief financial officer on data leak prevention, but I can show real ROI from our deployment as well.

Trouble Ticket

At issue: The company's DLP deployment is currently restricted to three big offices.

Action plan: Study the options for getting cost-effective coverage to the 50 smaller offices located around the world.

Our recent discovery of problems with our email security settings is only the latest example of our DLP investment paying off. Since we deployed network DLP last year, we've identified both inadvertent and deliberate disclosures of sensitive data. DLP alerts have led to employee terminations and legal action. Some of the incidents involve downright criminal activity.

Now I want to extend DLP's reach. Our current deployment is limited to our three main offices: one in the U.S., one in Europe and one in Asia. But 40% of our workforce is located in roughly 50 smaller offices around the world. Ideally, we would have architected the network so that all Internet traffic would be routed to regional hub sites via backhauling of the MPLS traffic. That would allow us to monitor network traffic for all of our remote offices with just three or four sensors. Instead, each remote office uses its own Internet service provider.

That being the case, we have two options for monitoring outbound Internet traffic for the enterprise. The first is to install DLP network sensors at each office (or alternatively, to provision virtual servers at all of our remote offices). The problem with this approach is that it provides no visibility into what users do once they take their laptops off the network.

Endpoint DLP, the second option, addresses that particular problem, and for the past few months we've been running a proof of concept to test its effectiveness.

The concept is appealing. We can install a lightweight agent on every PC via group policy or our regular software distribution and -- voila -- complete coverage for the enterprise. In reality, though, we've found that endpoint DLP falls short of network DLP.

Under the Hood

To help you understand the problem, let me explain a bit about how DLP works. DLP relies on both content matching and index matching. Content matching detects things like keywords, Social Security numbers, credit card numbers and other easily identifiable terms. It's quite simple, and even many firewall, email gateway and other proxy vendors offer similar functionality. Index matching goes much deeper and, in my opinion, provides the real value you get from enterprise DLP technology.

And this is how index matching works: When a document that has been identified as needing protection is checked in to the DLP infrastructure, complex computations are conducted on it. Afterward, if even a snippet of the document is leaked, the DLP infrastructure will recognize the snippet as part of a previously identified document. If just a few lines of source code are entered into an email message and sent out of network, the DLP index matching technology will identify it as protected even if the original document that was registered in the system contained 10,000 lines of source code.

All of this works seamlessly with network DLP, but when you try to do the same thing with endpoint DLP, you come up against performance and scalability issues. That's because the agents installed on each PC have to communicate with a central server to determine whether the data is part of a checked-in document.

This will all be resolved in future releases, the endpoint DLP vendor assures us. That doesn't help us now, though, so we'll either have to deploy network sensors at all of our remote offices or accept the decreased functionality that we'll get with endpoint DLP.

This week's journal is written by a real security manager, "Mathias Thurman," whose name and employer have been disguised for obvious reasons. Contact him at mathias_thurman@yahoo.com.