DLP Reconsidered

Many organizations have thrown in the towel on their Data Loss Prevention ("DLP") program as a result of the limited business value it provides. Not only are DLP solutions costly to implement and operate, but yield a poor return on Cybersecurity investment in the eyes of many IT/Security leaders.

As a result, many organizations' DLP solutions are used on a very limited basis, or are used to perform monitoring without analyzing the results to drive business value. Some comments we commonly hear include:

  • "DLP just wasn't the right fit for our program"
  • "The capital investment to reach the steady-state was much higher than advertised"
  • "Detection accuracy for the most important data types were very low"

These are troubling perspectives because the intent of DLP solutions is to contribute to data protection and monitoring efforts - critical components of a fully functional security program. With minimal or no DLP capability in place, data protection programs are less effective and valuable to the organization. We see a couple of common themes in environments where DLP has been viewed unfavorably.

There is generally a lack of understanding of the business relevance of the data protection strategy and we also see a weakness in being able to understand the scope of business processes that use/create sensitive data. These weaknesses, if addressed, can make it possible to align a DLP solution to maximize its value and the return on the (usually sizable) investment that has been made.

Here are a couple of scenarios that you may be dealing with and some thoughts on how you can bring your DLP solution into alignment with the business and the most relevant data handling operations.

Limited Business Relevance of Data Protection Strategy

Consider the situation in which a DLP solution is implemented and running, but the data protection strategy has been developed solely by information security and/or compliance without input to or output from any business unit. Data types have most likely been limited to regulated data as opposed to business critical data and response mechanisms (if any) are informational or transparent to the end user.

DLP has been implemented to protect data that has been deemed a priority, but this prioritization has been developed in a silo without input from the business. Further, limited time and effort has been invested to understand what data types are used by the business, and how it is being used or stored.

But let's suppose that you had your critical business process flows documented, and let us also suppose that you knew which of those process failed to meet your organization's standards for secure data handling and transport.

These resources would enable you to build, test, and implement a DLP policy rule set that would be directly relevant to specific business units. In the short term, DLP events would be of direct relevance and interest to the business, and from a long-term standpoint, any unexpected changes over time would be cause for concern, interest, and involvement of the business.

Lack of Insight into the Business Processes Driving Sensitive Data Use

Most commonly, we see the situation in which there is little understanding of the business processes behind the data interactions. Without that clear insight DLP policies are difficult if not impossible to make accurate and policy refinement is driven by trial and error as opposed to strategic, business-aware decision making. Sound familiar?

Usually, attempts to protect business-relevant data types have been made, but have proven difficult beyond basic data types (e.g., credit card numbers, social security numbers). Low detection accuracy of intellectual property and other business critical data types have resulted in a very high number of false positives, and teams do not have the resources required to perform meaningful analysis of the results.

Additionally, due to the low accuracy, the implementation of end-user facing response mechanisms may have resulted in embarrassment to the information security organization, eventually leading to the discontinuation of these use cases.

But let's again suppose that you had your critical business process flows documented, and let us also suppose that these processes are maintained and attested to on an annual basis by the respective business process owners.

Then, with the business-sanctioned process already documented, DLP policies can be designed to target and secure the highest risk channels, and highest risk repositories of data. In addition, as events are generated, your teams will be able to focus on actual data breach risks, and eliminate noise caused by legitimate traffic according to the data flows already approved by the business owners.

Knowing how and why your data is used in the context of business processes reveals the insights that are key to making good decisions relating to DLP integration and policy configuration. This results in much more efficient use of these types of tools and much lower rate of false positives so that your team can focus on what matters most.

Daniel Kim