Skip the navigation

Security Manager's Journal: A rush to judgment on DLP deployment

Our manager gets funding for DLP deployment added to his current budget. But that budget expires in a few weeks.

By Mathias Thurman
December 5, 2011 06:00 AM ET

Computerworld -

Trouble Ticket

At issue: A budget request is granted, with funding slashed and the time frame squeezed.
Action plan: With just weeks available to evaluate technologies, choose a tool and buy it, there's no room for missteps.

I got most of what I asked for, and I got it early. Sounds good, right? Not so much.

In my planning for 2012, I requested budget for data leak prevention (DLP). I had reason to believe I had a decent shot at getting the funding. I have a mandate to protect the company's intellectual property, and DLP has been a hot topic within the executive ranks.

I just learned that I'll be receiving a portion of my budget request, but not in 2012. It's been tacked onto the remaining 2011 budget. That means I have to buy a DLP tool before the end of the year. It appears that the executives have been persuaded that DLP will be a valuable piece in our security arsenal, and they've decided that the sooner we implement it, the better. The good news is that executives in this company take information security seriously. The bad news is that they don't understand that there is great value in taking time to study a technology before making a decision. If you rush, you can end up with something that doesn't really address the issues you want to tackle.

My original plan was to hire two DLP analysts and to work with them on a proof of concept. The reduced budget means I can hire only one analyst, but the time crunch makes matters even worse. We only have two months to conduct a formal proof of concept -- two months that are packed with holidays. What's more, I don't have the budget or head count to support a comprehensive DLP deployment.

Such a deployment would combine network DLP with discovery and endpoint technology. With network DLP, you identify data for monitoring, and you are then alerted when any of it leaves the company, be it through Microsoft Exchange email, webmail, file uploads, social media, FTP or any other method. As the name implies, though, network DLP only monitors traffic on the network. If identified data is on a laptop and that laptop goes off the network, you're blind. Endpoint DLP extends the DLP policy to devices that can work off the network. Discovery DLP lets you determine where all sensitive information resides, and it alerts you when any of that information is moved or is someplace it shouldn't be.

With the budget and time frame I've been given, our initial deployment will be restricted to network DLP at our three largest sites. That's not 100% coverage, but it's pretty close. I'll also be able to make use of my own experience, since I've deployed DLP in the past with success.

In the next few weeks, we will conduct limited proofs of concept, asking vendors to set up environments for testing our use cases. That won't leave much time for us to make our choice, negotiate the price and get the contract reviewed by legal.

Making do

But if all of that happens in time, we can start the new year setting up our new tool. I expect to create some initial structured data rules that look for things like credit card numbers, Social Security numbers and some source code. I'll also include keywords such as code names for mergers or acquisitions we might be involved in, so the DLP system will look for those code names in all communications. For the unstructured data, I will create protected directories for each major business unit. The units will then identify all of their sensitive data and place a copy of it in their respective directories.

Once documents have been identified, we will monitor the networks for data leaving the network. Events will trigger a notification that will be sent to the person responsible for reviewing alerts and determining whether they warrant further action.

In other words, we will make the most of what we have been given. 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.

Join in the discussions about security! computerworld.com/blogs/security

Read more about Security in Computerworld's Security Topic Center.