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)
