Tutorial

Best Practices for DLP Content Discovery: Part 5

By Rich

In our last post we finished our review of DLP content discovery best practices by discussion rolling out and maintaining your deployment. Today we're going to focus on a couple of use cases that illustrate how it all works together. I'm writing these as fake case studies, which is probably really obvious considering my lack of creativity in the names.

DLP Content Discovery for Risk Reduction and to Support PCI Audit

RetailSportsCo is a mid-sized online and brick-and-mortar sporting goods retailer, with about 4,000 headquarters employees and another 2,000 retail employees, across 50 locations. They classify as a Level 2 merchant due to their credit card transaction volume and are currently PCI complaint, but struggled through the process and ended up getting a series of compensating controls approved by their auditor, but only for their first year.

During the audit it was discovered that credit card information had proliferated uncontrolled throughout the organization. It was scattered through hundreds of files on dozens of servers; mostly Excel spreadsheets and Access databases used, and later ignored, by different business units. Since storage of unencrypted credit card numbers is prohibited by PCI, their auditor required them to remove or secure these files. Audit costs for the first year increased significantly due to the time spent by the auditor validating that the information was destroyed or secured.

RetailSportsCo purchased a DLP solution and created a discovery policy to locate credit card information across all storage repositories and employee systems. The policy was initially deployed against the customer relations business unit servers, where over 75 files containing credit card numbers were discovered. After consultation with the manager of the department and employee notification, the tool was switched into enforcement mode and all these files were quarantined back into an encrypted repository.

In phase 2 of the project, DLP endpoint agents were installed on the laptops of sales and customer relations employees (about 100 employees). Users and managers were educated, and the tool discovered and removed approximately 150 additional files. Phase 3 added coverage of all known storage repositories at corporate headquarters. Phase 4 expanded scanning to storage at retail locations, over a period of 5 months. The final phase will add coverage of all employee systems in the first few months of the coming year, leveraging their workstation configuration management system for a scaled deployment.

Audit reports were generated showing exactly which systems were scanned, what was found, and how it was removed or protected. Their auditor accepted the report, which reduced audit time and costs materially (more than the total cost of the DLP solution). One goal of the project is to scan the entire enterprise at least once a quarter, with critical systems scanned on either a daily or weekly basis. RetailSportsCo has improved security and reduced risk by reducing the potential number of targets, and reduced compliance costs by being able to provide auditors with acceptable reports demonstrating compliance.

DLP Content Discovery to Reduce Competitive Risk (Industrial Espionage)

EngineeringCo is a large high-technology manufacturer of consumer goods with 51,000 employees. In the past they've suffered from industrial espionage, when the engineering plans for new and existing products were stolen. They also suffered a rash of unintentional exposures and product plans were accidentally placed in public locations, including the corporate website.

EngineeringCo acquired a DLP content discovery solution to reduce these exposure risks and protect their intellectual property. Their initial goal was to reduce the risk of exposure of engineering and product plans. Unlike RetailSportsCo, they decided to start with endpoints, then move into scanning enterprise storage repositories. Since copies of all engineering and product plans reside in the enterprise content management system, they chose a DLP solution that could integrate and continuously monitor selected locations and automatically build partial-document matching policies for all documents. The policy was tested and refined to ignore common language in the files, such as corporate headers and footers, which initially caused every document using the corporate template to register in the DLP tool.

EngineeringCo started with a phased deployment to install the DLP endpoint discovery agent on all corporate systems. In phase 1, the tool was rolled out to 100 systems per week, starting with product development teams. The initial policy allowed those teams access to the sensitive information, but documented what was on their systems. Those reports were later mated to their encryption tool to ensure that no unencrypted laptops hold the sensitive data. Phase 2 expanded deployment to the broader enterprise, initially in alerting mode. After 90 days the product was switched into enforcement mode and any identified content outside of the product development teams was quarantined with an alert sent to the user, who could request an exemption. Initial alert rates were high, but user education reduced levels to only a dozen or so "violations" a week during the 90-day grace period.

In the coming year EngineeringCo plans to refine their policy to restrict product development employees from placing registered documents onto portable storage. The network component of their DLP tool already restricts emailing and other file transfers outside of the enterprise. They also plan on adding policies to protect employee healthcare information and customer account information.

These are, of course, fictional best practices examples, but they're drawn from discussions with dozens of DLP clients. The key takeaways are:

1. Start small, with a few simple policies and a limited scanning footprint.
2. Grow deployments as you reduce incidents/violations to keep your incident queue under control and educate employees.
3. Start with monitoring/alerting and employee educations, then move on to enforcement.
4. This is risk reduction, not risk elimination. Use the tool to identify and reduce exposures but don't expect it to magically solve all your data security problems.
5. When you add new policies, test first with a limited audience before rolling them out to the entire scope, even if you are already covering the entire enterprise with other policies.

–Rich

Best Practices For DLP Content Discovery: Part 3

By Rich

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:

1. What kinds of content you can protect, based on the content analysis capabilities of your tool.
2. 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.
3. Protection options: Can you encrypt? Move files? Change access controls?
4. Performance, based on scanning techniques.
5. How much of the infrastructure you'd like to cover (which servers, endpoints, and other storage repositories).
6. Scanning frequency (days? hours? near continuous?).
7. 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:

1. Business unit requests policy from DLP team to protect content type.
2. DLP team meets with business unit to determine goals and protection requirements.
3. DLP team engages with legal/compliance to determine any legal or contractual requirements or limitations.
4. DLP team defines draft policy.
5. Draft policy tested in monitoring (alert only) mode without full workflow and tuned to acceptable accuracy.
6. DLP team defines workflow for selected policy.
7. DLP team reviews final policy and workflow with business unit to confirm needs have been met.
8. Appropriate business units notified of new policy and any required changes in business processes.
9. Policy deployed in production environment in monitoring mode, but will full workflow enabled.
10. Protection certified as stable.
11. Protection/enforcement actions enabled.

And here's one for policy violations:

1. Violation detected; appears in incident handling queue.
2. Incident handler confirms incident and severity.
3. If action required, incident handler escalates and opens investigation.
4. Business unit contact for triggered policy notified.
5. Incident evaluated.
6. Protective actions taken.
7. If file moved/protected, notify user and drop placeholder file with contact information.
8. Notify employee manager and HR if corrective actions required.
9. Perform required employee education.
10. Close incident.

These are, of course, just rough samples in text form, but they should give you a good idea of where to start.

–Rich