Considerations for buying and implementing DLP solutions

Financial institutions are looking to data loss prevention solutions to prevent costly data security breaches. In this tip, Dave Shackleford explains key issues to weigh before buying and installing a DLP product.

There's been no shortage of news regarding data security breaches in the last several years. Verizon's annual data breach report for 2009 provides some useful statistics: 74% of breaches are caused by external sources versus 20% for internal sources, most breaches occur due to errors and misconfigured systems (67%), and nearly all compromised records were taken from servers and applications. Many financial organizations are looking into data loss prevention (DLP) tools to prevent these embarrassing and costly scenarios from occurring. But what should they look for in DLP systems?

First off, let's clarify what DLP tools are. Although they can have a variety of definitions, most agree that DLP systems are those that monitor sensitive data at rest, in motion and in use, and take preventive or detective actions based on centrally defined policies.

The first -- and arguably most important -- feature of any DLP solution is the depth of content awareness and analysis. These tools need to be able to identify a variety of data types, such as credit card numbers, banking records, personal data and financial statements, all in a number of different formats. There are numerous techniques offered by vendors, ranging from sophisticated regular expression pattern matching to dictionary lookups, but more is usually better, especially with regard to file types (Microsoft Word and Excel documents, database files, email archives, etc.).

Before jumping into a DLP project, financial organizations need to carefully define what they want to protect. Another high-level consideration is compliance requirements: Will the DLP solution provide compliance-specific monitoring and reporting for FFIEC, GLBA, SOX and other mandates financial organizations must adhere to? The third consideration ties the first two together: policy definition and implementation. The ability to easily and intuitively create flexible, accurate policies from a centralized console is a key factor in choosing a DLP system, as policy engines and creation tools differ widely between products. These policies should accommodate numerous data types and formats, a variety of implementation points (hosts, networks and applications) and custom tailoring to organizations.

Additional considerations for purchasing a DLP solution include the following:

  • Integration with existing security systems, such as endpoint security tools and encryption, as well as IT infrastructure components like Active Directory and network monitoring tools. Most advanced solutions will incorporate auditing actions that correlate detection and prevention actions with the users who initiate them at the host and/or application level.
  • Accuracy and tested results from existing customers or independent labs. Although many DLP vendors' products may have similarities in terms of policy types and content detection algorithms, all differ somewhat in accuracy and implementation. Ensure you talk with reference customers and industry sources to get up-to-date opinions on how the product actually performs in production environments.
  • Cost, both to implement initially and maintain over time. Hardware, software and operational costs such as additional personnel should be factored in.
  • Platform support and performance metrics, taking both host-based and network-based DLP tools into account. In large, high-speed networks, not all solutions are equally capable of parsing data and accurately detecting policy violations. On the host side, some DLP agents consume significant processor and memory resources.

For financial organizations that have already purchased a DLP product and are close to implementing the technology, there are many considerations as well. Here are some, listed in order of importance:

  • Ensure you know what types of data you want to catalogue, and where it resides. Most DLP systems will need to scan storage drives and systems to build an inventory of data.
  • Define what policies you want to enforce with DLP. This should include a full range of network- and host-based options, including thumb drive detection and analysis, prevention of screen shots on workstations and servers, prevention of data egress over network connections, prevention of printing sensitive documents, etc.
  • Create centralized policies that correspond to the actions you wish to take. Ensure that you consider audit trails and logging as part of this exercise.
  • Look to implement DLP where you can get the most "bang for the buck." Install network monitoring sensors where the most traffic is seen, and in network segments with known sensitive data. Cover the most critical servers and applications first.
  • Perform tests of detection and prevention capabilities with "dummy data" before enabling production policies.
  • Update incident handling, forensics and audit policies and procedures to accommodate DLP detection workflows. For example, what actions are taken to follow up when a DLP event occurs?

Although not a complete list, these are some of the major points financial organizations should consider when planning and implementing DLP systems. With data security breaches occurring regularly and with more severe impacts -- a recent study concluded that each compromised record costs organizations $204 -- putting content-aware controls in place to detect and prevent loss of sensitive data is more critical than ever. As DLP tools mature, and more robust capabilities are available -- tying DLP policies to automated encryption actions, for example -- more financial organizations will look to implement them to satisfy security best practices and compliance requirements alike.

About the author:
Dave Shackleford is director of risk and compliance and acting director of security assessments at Sword and Shield Enterprise Security Inc., and is a certified SANS instructor. He was formerly CSO at Configuresoft Inc. and CTO at the Center for Internet Security, and has worked as a security architect, analyst, and manager for several Fortune 500 companies. In addition to these roles, he has consulted with hundreds of organizations for regulatory compliance, as well as security and network architecture and engineering.

This was last published in January 2010

Dig Deeper on Data security technology and strategy