Best Practices For DLP Content Discovery: Part 3
In Part 3 of our series we finished our review of the technical architecture and selection; now we’re going to delve into best practices for deployment. We will focus on setting expectations, prioritization, and defining your internal processes. The main obstacle to successful deployments isn’t a technology weakness, but rather the failure of the enterprise to understand what to protect, decide how to protect it, and recognize what’s reasonable in a real-world environment. Setting Expectations The single most important factor for any successful DLP deployment – content discovery or otherwise – is properly setting expectations at the start of the project. DLP tools are powerful, but far from a magic bullet or black box that makes all data completely secure. When setting expectations you need to pull key stakeholders together in a single room and define what’s achievable with your solution. All discussion at this point assumes you’ve already selected a tool. Some of these practices deliberately overlap steps during the selection process since at this point you’ll have a much clearer understanding of the capabilities of your chosen tool. In this phase, you discuss and define the following: What kinds of content you can protect, based on the content analysis capabilities of your tool. Expected accuracy rates for those different kinds of content; for example, you’ll have a much higher false positive rate with statistical/conceptual techniques than partial document or database matching. Protection options: Can you encrypt? Move files? Change access controls? Performance, based on scanning techniques. How much of the infrastructure you’d like to cover (which servers, endpoints, and other storage repositories). Scanning frequency (days? hours? near continuous?). Reporting and workflow capabilities. It’s extremely important to start defining a phased implementation. It’s completely unrealistic to expect to monitor every nook and cranny of your infrastructure with your initial rollout. Nearly every organization finds they are more successful with a controlled, staged rollout that slowly expands breadth of infrastructure coverage and types of content to protect. Prioritization If you haven’t already prioritized your information during the selection process, you need to pull all major stakeholders together (business units, legal, compliance, security, IT, HR, etc.) and determine which kinds of information are more important, and which to protect first. I recommend you first rank major information types (e.g., customer PII, employee PII, engineering plans, corporate financials), then re-order them based on priority for monitoring/protecting within your DLP content discovery tool. In an ideal world your prioritization should directly align with the order of protection, but while some data might be more important to the organization (engineering plans) other data may need to be protected first due to exposure or regulatory requirements (PII). You’ll also need to tweak the order based on the capabilities of your tool. After your prioritize information types to protect, run through and determine approximate timelines for deploying content policies for each type. Be realistic, and understand that you’ll need to both tune new policies and leave time for the organizational to become comfortable with any required business changes. We’ll look further at how to roll out policies and what to expect in terms of deployment times later in this series. Define Process DLP tools are, by their very nature, intrusive. Not in terms of breaking things, but intrusive in terms of the depth and breadth of what they find. Organizations are strongly advised to define their business processes for dealing with DLP policy creation and violations before turning on the tools. Here’s a sample of a process for defining new policies: Business unit requests policy from DLP team to protect content type. DLP team meets with business unit to determine goals and protection requirements. DLP team engages with legal/compliance to determine any legal or contractual requirements or limitations. DLP team defines draft policy. Draft policy tested in monitoring (alert only) mode without full workflow and tuned to acceptable accuracy. DLP team defines workflow for selected policy. DLP team reviews final policy and workflow with business unit to confirm needs have been met. Appropriate business units notified of new policy and any required changes in business processes. Policy deployed in production environment in monitoring mode, but will full workflow enabled. Protection certified as stable. Protection/enforcement actions enabled. And here’s one for policy violations: Violation detected; appears in incident handling queue. Incident handler confirms incident and severity. If action required, incident handler escalates and opens investigation. Business unit contact for triggered policy notified. Incident evaluated. Protective actions taken. If file moved/protected, notify user and drop placeholder file with contact information. Notify employee manager and HR if corrective actions required. Perform required employee education. Close incident. These are, of course, just rough samples in text form, but they should give you a good idea of where to start. Share:
