Welcome to the second to last post in my series on DLP. You can find the other parts here: Part 1, Part 2, Part 3, Part 4, Part 5. In this post we’ll be covering the major features of the central management server. Our final post will cover recommendations for evaluating and selecting the best tool for your environment.

As we’ve discussed throughout this series, all current DLP solutions include a central management server for administering enforcement and detection points, creating and administering policies, incident workflow, and reporting. These features are frequently the most influential in the selection process. There are a lot of differences between the various products on the market; rather than trying to cover every possible feature, we’ll focus on the baseline of functions that are most important.

User Interface

Unlike other security tools, DLP/CMP tools are often used by non-technical staff ranging from HR, to executive management, to corporate legal and business unit heads. As such the user interface needs to account for this mix of technical and non-technical staff and should be easily customized to meet the needs of any particular user group. Due to the complexity and volume of information a DLP solution may deal with, the user interface can make or break a DLP product. For example, simply highlighting the portions of an email in violation of a policy when displaying the incident can shave minutes off handling time. A DLP user interface should include the following elements:

• Dashboard: A good dashboard will have user-selectable elements and defaults for technical and non-technical users. Individual elements can be enabled or restricted based on user and group. The dashboard should focus on the information valuable for that user, and not be just a generic system-wide dashboard. Elements should include number and distribution of violations based on severity and channel and other top-level information to summarize the overall risk to the enterprise.
• Incident Management Queue: The incident management queue is the single most important component of the user interface. This is the screen incident handlers will use to monitor and manage policy violations. The queue should be concise, customizable, and easy to read at a glance. Due to the importance of this feature we will detail recommended functionality later in this post.
• Single Incident Display: When a handler digs into a single incident, the display should cleanly and concisely summarize the reason for the violation, the user involved, the criticality, the severity (criticality is based on what policy is violated, severity on how substantial the violation is), related incidents, and all other information needed to make an intelligent decision on incident disposition.
• System Administration: Standard system status and administration interface. Includes user and group administration.
• Hierarchical Administration: Status and administration for remote components of the DLP solution, such as enforcement points, remote offices, and endpoints.
• Reporting: A mix of pre-built reports and ad-hoc reporting.
• Policy Creation and Management: Next to the incident queue this is the most important element of the central management server. It includes the creation and management of policies. Because it’s so important, we’ll cover it in more detail later.

A DLP interface should be clean and easy to navigate. That may sound basic, but we’re all far too familiar with poorly designed security tools that rely on the technical skills of the administrator to get around. Since DLP is used outside of security, possibly even outside of IT, the user interface needs to appeal to a wider range of users.

Hierarchical Management, Directory Integration, and Role Based Administration

DLP policies and enforcement often need to be tailored to the needs of individual business units or geographical locations. Hierarchical management allows you to establish multiple policy servers distributed throughout the organization, with a hierarchy of administration and policies. For example, a geographic region can have its own policy server slaved to a central policy server. That region can create their own specific policies, ignore (with permission) central policies, and handle local incidents. Violations are aggregated on the central server while some policies are always enforced centrally. The DLP tool must support the creation of global and local policies, assign policies for local or global enforcement, and manage multi-regional workflow and reporting.

DLP solutions also integrate with enterprise directories (typically Microsoft Active Directory) so violations can be tied to users, not IP addresses. This is complex when you realize you’re dealing with a mix of managed and unmanged (guest/temporary) employees without assigned IP addresses. The integration should tie DHCP leases to users based on their network login, and update to avoid accidentally tying a policy violation to an innocent user. For example, one product in an earlier version would keep a user associated with an IP address until that address was assigned to another user in the directory. One reference almost fired an employee because a contractor, not in Active Directory, was the next person to use that IP and committed a policy violation. The tool tied the violation to the innocent employee.

The system should also allow internal role based administration for both internal administrative tasks, and monitoring and enforcement of users. Internally, users can be assigned to administrative and policy groups for separation of duties. For example, someone can be given the role of enforcing any policy assigned to the accounting group, but not administer the system, create policies, see violations for any other group, or alter policies. Since your Active Directory might not fully represent how you’d like to divide up monitored users, the system should also support groups and roles for dividing up employees for monitoring and enforcement.

Policy Creation and Management

Policy management and creation is a critical function at the heart of DLP solutions; it’s also (potentially) the most difficult part of managing DLP. The policy creation interface should be accessible to both technical and non-technical users, although heavily customized policies will nearly always need technical skills to define.

For policy creation, the system should let you identify the kind of data to protect, a source (if needed) for the data, which channels to monitor and protect, what actions to take for violations, what users to apply the policy to, and what handlers and administrators can access the policy and violations. Since not all policies are created equal, they should also be assigned a sensitivity and thresholds for severity (the volume of violations). Policies should be usable as templates for new policies, and if the system includes categories (which you really want) the policies associated for a given category should also be editable and available as templates for custom policies. Policy wizards are also a useful feature, especially for policies like protecting a single document.

I tend to prefer user interfaces that use clear, graphical layouts for policies. Preferably with an easy to read grid of channels monitored and disposition for violations on that channel. The more complex a policy, the more likely you’ll create internal discrepancies or accidentally assign the wrong disposition to the wrong channel or violation.

Essentially every policy will need some level of tuning, and a good tool will allow you to create a policy in test mode that shows how it would react in production, without filling incident handlers’ queues or performing enforcement actions. Some tools can test draft polices against previously-recorded traffic.

Policies will include extremely sensitive information, so they should be hashed, encrypted, or otherwise protected within the system. Some business units may have extremely sensitive policies which will need to be protected against system administrators not given explicit permission to see those policies. All policy violation records should also be protected.

Incident Workflow and Case Management

Incident workflow will be the most heavily used part of the DLP system. This is where violations are reported, incidents are managed, and investigations are performed.

The first stop is the incident handling queue, which is a summary of all incidents either assigned to that handler, or unassigned but within the enforcement domain of the handler. Incident status should be clearly indicated with color-coded sensitivity (based on the policy violated) and severity (based on the volume of the transgression, or some other factor defined in the policy). Each incident should appear on a single line, and be sortable or filterable on any field. Channel, policy violated, user, incident status (open, closed, assigned, unassigned, under investigation) and handler should also be indicated and easily changed with just a click for instant disposition. By default, closed incidents shouldn’t clutter the interface- basically treating it like an email Inbox. The user should be able to customize anything to better suit their workflow. Incidents with either multiple policy violations, or multiple violations of a single policy, should only appear once in the incident queue. If someone sends out a document with 10 emails it shouldn’t show up as 10 different incidents.

When a single incident is opened, it should list all the incident details, including (unless otherwise restricted) highlighting what data in the document or traffic violated which policy. A valuable feature is a summary of other recent violations by that user, and other violations involving that data (which might indicate a larger event). The tool should allow the handler to make comments, assign additional handlers or notify management, and upload any supporting documentation.

More advanced tools include case management for detailed tracking of incidents and any supporting documentation, including timestamps and hashes of data. This is valuable in cases where legal action is taken, and evidence in the case management system should be managed to increase the probability of admission in court.

System Administration, Reporting, and Other Features

As with any security tool, a DLP solution should include all the basic system administration features such as:

• Backup and restore- both full system, and system configuration only, for platform migrations.
• Import/Export- for policies and violations. There should be support for exporting and removing closed violations to free up active space.
• Load balancing/clustering
• Performance monitoring and tuning
• Database management

Tools tend to mix these functions between the tool itself and the underlying platform. Some organizations will prefer to completely manage the tool internally without requiring the administrator to learn or manage the platform (often through the command line and platform utilities). As much as possible, you should look for a DLP tools that lets you manage everything through the included interface.

Reporting tends to vary widely across solutions, some using internal reporting interfaces while others rely on third party tools like Crystal Reports. All tools ship with some default reports, but not all tools allow you to create your own reports. You should look for a mix of technical and non-technical reports, and if compliance is an issue consider a tool with pre-built compliance reports.

When you use data-at-rest or data-in-use (endpoint) features, you’ll need a management interface that allows you to properly group and manage policies across servers, storage, and endpoints. The tool should support device grouping, rolling signature updates, and other features as needed to manage large numbers of devices.

Beyond these basic features, products start to differentiate themselves beyond what we have space to cover, including features such as:

1. Third party integration, from web gateways to forensics tools.
2. Language support, including double-byte character sets for Asia.
3. Anonymization of policy violations to support international workplace privacy requirements.
4. Full capture for recording all traffic, not just policy violations.

This is a bit of a longer post, but by now you should have a very good understanding of what compromises a DLP/CMF/CMP solution and major features to look for. Our last post in the series will dig into the selection process to help you pick the best tool for your environment.

As always, please hit me with your feedback in the comments. Even after 6 posts on this topic it’s highly likely I’ve missed some major features or functionality.