Best Practices For DLP Content Discovery: Part 3



Okay, I’m a day late with this one, but that’s pretty good for me these days.

In our last post we talked about the base technical architecture. Today we’ll fill in with enforcement, management, workflow, and reporting.

Enforcement actions

Once the DLP discovery tool determines something is out of place, it can (depending on the tool) take enforcement actions that range from alerts to full-on protection, including combinations. In cases where files are restricted, moved, or encrypted, an unprotected plain text file can be dropped into the same location to notify users who to contact with questions now that they can’t access the file.

  1. Alert: an alert is recorded as a DLP incident. This is the base action, triggered no matter what else occurs.
  2. Notify: Email is sent to either the content owner (based on access controls and directory integration), policy owner (based on the DLP policy), or pretty much anyone else (such as the content owner’s manager).
  3. Restrict access: Access controls are modified to restrict access, e.g., block anyone except a security administrator from accessing the file so it’s protected until the violation is manually reviewed.
  4. Move/quarantine: The file is moved to a secure repository.
  5. Encrypt: The file is encrypted. It could be protected with something as generic as a corporate key, or something more specific like a group, security, or administrative key.

Management

Ideally your content discovery capabilities will be managed through the same server as the rest of your DLP deployment. This will maintain consistent policies, workflow, and incident handling. Here are a few discovery-specific capabilities to look for:

  1. Policy creation: Data at rest policies should be completely integrated with your other DLP policies. This enables you to define a type of content only once (e.g., credit card number or engineering plan) then apply appropriate alerting and protection rules for at-rest, in-use, and in-motion as part of a single policy. Policies should allow for fine-grained control based on user groups through directory integration.
  2. Directory integration: All DLP solutions can identify IP and email addresses, but for content discovery they also need to understand network users and groups, to tie into access controls.
  3. Repository management: This is the part of the system where you identify and group storage repositories such as servers, shares, and document management systems. For crawling it’s where you store access credentials, and for agents it includes agent management. Ideally you can tag groups of repositories to make policy building easier (e.g., “accounting” or “engineering”). This is where you also define scanning frequency, bandwidth/performance throttling, and other basic functional preferences.

Workflow and Reporting

Workflow should be completely integrated into the base DLP incident handling queue. Content discovery related incidents should appear right alongside in-motion and in-use incidents, although you might assign a different incident handler for at-rest policies depending on organizational needs. For example, you could assign a specific handler for all storage-related PCI violations, while keeping network violations in the general queue. If you encrypt, quarantine, or otherwise protect files, the DLP solutions needs to include management of those controls so you can release and restore when needed.

Reporting, on the other hand, should include content-discovery-specific reports, especially audit reports to help with compliance efforts. While a report on all transmissions of credit card numbers over email might not be the kind of thing you want to send an auditor, a report showing that you don’t have any unprotected numbers in any known storage location would be more useful. Also look for the ability to generate reports for business unit managers, storage administrators, audit/legal/compliance, and other non-technical personnel. Because scans are run periodically, the solution should allow you to automatically schedule and distribute reports, rather than requiring them to be run manually every time.

Again, this section is just meant to highlight a few content-discovery-specific capabilities to look for and does not even attempt to describe all standard DLP features.

Posted on

3 comments

  1. Colin Apr 18

    This seems like a good strategy, Rich, albeit a complicated one. How many businesses have the expertise and resources to do something like this now? Is there a lot of reliance on outside solution providers?

  2. rmogull Apr 21

    NOt a ton- usually people spend a little time with their vendor getting thigns up and running, with periodic hand holding after that when they add in new policies. It’s not terribly complex, but does take a lot of political willpower.

  1. Best Practices For DLP Content Discovery: Part 4 | securosis.com

Leave a reply

Related Posts

New Whitepapr: Best Practices For DLP Content Discovery
Content Discovery vs. E-Discovery vs. Content Classification
Best Practices For Endpoint DLP: Part 2