I’ve been so tied up with the Nexus, CCSK, and other projects that I haven’t been blogging as much as usual… but not to worry, it’s time to start a nice, juicy new technical series. And, once again, I return to my bread and butter- DLP. As much as I keep thinking I can simply run off and play with pretty clouds, something in DLP always drags me back in. This time it’s the chance to dig in and focus on implementation and management (thanks to McAfee for sponsoring something I’ve been wanting to write for a long time). With that said, let’s dig in…
In many ways Data Loss Prevention (DLP) is one of the most far-reaching tools in our security arsenal. With a single platform DLP touches our endpoints, network, email servers, web gateways, storage, directory servers, and more. There are more potential integration points than nearly any other security tool (perhaps except for SIEM). And then we need to build policies, define workflow, and implement blocking… all based on nebulous things like “customer data” and “intellectual property”.
It’s no wonder many organizations are intimidated by the thought implementing a large DLP deployment. Yet, based on our 2010 survey data, somewhere upwards of 40% of organizations use some form of DLP.
Fortunately, implementing and managing DLP isn’t nearly as difficult as many security professionals expect. Over the nearly 10 years we’ve covered the technology, talking with probably hundreds of DLP users, we’ve collected countless tips, tricks, and techniques for streamlined and effective deployments that we’ve compiled into straightforward processes to ease most potential pains.
We’re not trying to pretend there isn’t any complexity involved in deploying DLP. DLP is one of the most powerful and important tools in our modern security arsenal, and anything with that kind of versatility and wide range of integration points can easily be a problem if you fail to appropriately plan or test.
But that’s where this series steps in. We’ll lay out the processes for you, including different paths to meet different needs, all to help you get up and running, and stay there, as quickly, efficiently, and effectively as possible. We’ve watched the pioneers lay the trails and hit the land mines, now it’s time to get those lessons out to everyone else.
Keep in mind that despite what you’ve heard DLP isn’t all that difficult to deploy. There are a lot of misperceptions out there, in large part due to squabbling vendors (especially non-DLP vendors). It doesn’t take much to get started with DLP.
On a practical note this series is a follow up to our Understanding and Selecting a Data Loss Prevention Solution paper that’s now in its second revision. We pick up right where that paper left off, and if you get lost in any of the terminology we suggest you use that one as a reference.
On that note, let’s start with an overview and then we’ll delve into the details.
Quick Wins for Long Term Success
One of the main challenges in deploying DLP is to show immediate value without killing yourself with too much data. DLP tools tend to not be too bad with false positives; certainly nothing nearly as bad as your experiences with IDS. That said, we’ve seen many people deploy the tools without knowing what they wanted to look for which can result in a lot of what we call false real positives; real alerts on real policy violations, just not something you actually care about.
Now the way to handle too many alerts is to slowly deploy and tune your policies, which can take a lot of time and may even focus you on protecting the wrong kinds of content in the wrong places. Thus we compiled two separate implementation options:
- The Quick Wins process is best for initial deployments. Your focus is on rapid deployment and information gathering vs. enforcement to help guide your full deployment. We previously detailed this process in a white paper and will only briefly review it in this series.
- The Full Deployment process is what you’ll use for the long haul. It’s a methodical series of steps for full enforcement policies. Since the goal is enforcement (even if enforcement is alert/response and not automated blocking/filtering) we spend more time tuning policies to produce desired results.
The key difference is that the Quick Wins process isn’t focused on enforcing every incident- just really egregious problems. It’s about getting up and running and quickly showing value by identifying key problem areas and helping set you up for a full deployment. The Full Deployment process is where you dig in, spend more time on tuning, and implement long-term policies for enforcement.
The good news is we designed these to work together. If you decide to start with the Quick Wins everything you do will feed directly to a full deployment. If you already know where you want to focus, you can jump right into a full deployment without bothering with the Quick Wins. In either case the process guides you around common problems and should speed up implementation.
In our next post we’ll show you where to get started and start laying out the process(es)…
- Rich (0) Comments