Consolidating Data Loss Prevention Tools: Good Idea, Bad Outcome

Historically, data loss prevention (DLP) has been considered a necessary evil for enterprises in highly regulated industries such as finance and healthcare. Organizations in other sectors often opted not to adopt it at all, as DLP systems are perceived as complex and capable of generating an “overwhelming volume of alerts and false positives.”¹ This complexity and noisiness bind significant resources, including money, IT infrastructure, and the time of highly skilled information security professionals.

However, in more recent years, there has been a general increase in DLP tool implementations outside of highly regulated industries, with several key reasons for this development:

• Frequent reporting of data breaches, raising awareness of the need for a DLP program
• New regulatory requirements to protect personal information, such as the General Data Protection Regulation (GDPR) in the European Union or the US State of California Consumer Privacy Act (CCPA)
• Adaption or migration of on-premises resources to the cloud

Other noteworthy reasons include the growth of the chief information security officer (CISO) role, increasing prices of sensitive data on the dark web, and an expanding definition of what is considered sensitive data.²

These challenges and developments have led to a very interesting change in the DLP market. In the past, dedicated cybersecurity vendors (e.g., Symantec, Forcepoint, Digital Guardian) offered DLP as a standalone suite that had to be deployed onsite on enterprise hardware. But with the general move of resources into the cloud, a new breed of DLP tools has emerged. New players have entered the DLP market that do not offer it as a single dedicated suite; rather, it is an add-on to their existing cloud-based offerings such as email protection (e.g., Proofpoint), cloud proxies (e.g., Zscaler), or cloud storage (e.g., Box). In addition, mergers and acquisitions result in DLP becoming part of another enterprise’s bigger IT and cybersecurity tool stack.³ One such example was Fortra’s acquisition of Digital Guardian in 2021.⁴ Changes such as these have made DLP readily available to organizations that have never had a DLP program. But of course, they have also made it available to organizations with an existing standalone DLP tool, and this is where the challenges start.

The Problem With Multiple DLP Tools

Often multiple DLP tools coexist in the same enterprise environment, leading to two problems:

1. Shadow DLP—Multiple DLP tools may run simultaneously without central oversight or coordination, sometimes even without the security team’s awareness. The result is a fragmented DLP landscape and a false sense of security. Because detection is not orchestrated, there may be duplication of detection in some areas and detection blind spots in others.
2. Urge to consolidate—As shadow DLP is addressed, the reaction is often to reduce the overall number of DLP tools in use, with the intention of saving money and eliminating redundancy. But the outcome may be the opposite: a more fragmented DLP environment with higher operational costs.

Shadow DLP is by far the worst evil, as a DLP environment comprised of multiple, uncoordinated tools results in a classical “too many cooks in the kitchen” scenario. It is almost natural as “With new possibilities come new, specialized vendors and tools that are the choice of the engineers doing the work.”⁵ But the results can be catastrophic. Multiple teams performing incident response based on different directives may lead to critical data leaks not being reported correctly, timely, or at all. Inconsistent and fragmented reporting will prevent the organization from seeing the bigger data risk and exposure picture. Inconsistent detection capabilities and policy tuning practices can lead to substantial blind spots in detection, so critical leaks may not get detected in the first place.⁶ DLP tool consolidation is one of the steps an organization can take to address many of these key issues. But DLP tools can be very complex. It is no small task to compare multiple DLP tools and make an executive decision on which tools to keep and which to remove.

Drivers of DLP Tool Consolidation

Even without phenomena such as shadow DLP, tool sprawl is a daunting challenge for organizations of any size, and CISOs often respond with a request to consolidate tools in the same category. Some noteworthy items covered by a tool consolidation request include:

• Elimination of ineffective tools
• Identification and removal of duplicate tools
• Enabling tool automation where possible
• Unification of platforms⁷

Desired results include:

• Better utilization of highly skilled workers
• Reduced complexity of the IT environment
• Money saved

For many tool categories in the cybersecurity stack, this exercise is worthwhile and can yield desirable results. However, DLP is a special breed of tool. Unlike other cybersecurity tools that try to keep bad things out (e.g., hackers, ransomware, spam), DLP is designed to keep good stuff in (e.g., sensitive data, intellectual property). But the “good stuff” is defined differently by each organization. No two organizations host the same kind of data and making sure that a DLP tool knows what to look for is one of the key reasons why DLP is considered so complex. Another key reason is the ever-changing IT landscape in which data is stored and processed in various formats and locations. DLP must keep pace with these developments to offer comprehensive visibility and protection.

A Consolidation Exercise

DLP is a common candidate for tool consolidation, especially if a preexisting standalone suite is already in place. The standalone instance appears inferior because cloud-based tools offer a wider set of functions and capabilities. With several add-on DLP tools readily available, the assumption becomes that a combination of these tools will address all the use cases currently covered by the standalone DLP suite. This may be true for enterprises in less-regulated sectors or with a limited number of fairly generic DLP use cases. But for all other enterprises, the negative impacts are often underestimated, ultimately resulting in the opposite of the original intention.

Consider an example, illustrating how changes in a preexisting DLP environment followed by a tool consolidation exercise could lead to an unexpectedoutcome.

Phase 1: Preexisting DLP Environment
An organization in the finance industry, Bank1, has been running a DLP program for approximately 10 years. It originally acquired a full standalone suite covering all relevant use cases at the time, including email and web traffic inspection, data processing on laptops, on-premises file shares as well as the Preexisting DLP Environment software as a service (SaaS) tool Microsoft Office 365 and the infrastructure as a service (IaaS) Use Cases platform Microsoft Azure. The tool was centrally managed by the information security department, which oversaw the definition and tuning of detection policies, incident response, and reporting. Figure 1 depicts Bank1’s original DLP use cases and the coverage provided by the chosen solution. It is implied that all use cases were sufficiently covered.

Phase 2: Running the Tool Consolidation Exercise
Over several years, Bank1 modernizes its IT infrastructure and purchases additional cloud-based solutions, some featuring DLP capabilities. The product owners test these as part of the proof-of-value exercise or during implementation, and some are fully enabled for production. The CISO becomes aware of these initiatives, considers vendor sprawl at play, and requests a plan to consolidate the DLP environment with a focus on cost savings. With the standalone DLP tool being the most expensive line item on the balance sheet, the plan is to have its capabilities covered by the cloud-based alternatives. As part of the project, adding two new use cases is also required (a second SaaS tool and a collaboration tool). Figure 2 shows where the individual tools (Add-on DLP) complement each other and where overlap exists.

As each DLP tool offers a different level of coverage, no single tool can address all use cases. Although some use cases can be covered by more than one tool, not all tools offer the same level of protection. For example, one tool may inspect emails at the endpoint via an agent before they are sent, while another tool inspects emails in-line after they are sent. This means that the latter tool can enforce email encryption, but the former cannot. This shows yet again that in-depth DLP expertise is required to determine whether a particular tool is sufficient to cover the identified use cases.

Phase 3: Executing on the Assessment Results
Based on costs and coverage, the decision is made to replace Bank1’s standalone DLP tool with a combination of four different add-on DLP tools, as illustrated in figure 3. Each product team is responsible for running their DLP and managing it alongside their tools’ primary capabilities. Infosec’s engagement is reduced to a consultative role, supporting product owners to operationalize DLP for their tools.

Phase 4: Implementation Results
Advantages of this exercise include that the enterprise was successfully able to:

• Replace the standalone DLP version
• Add two new use cases
• Ensure a similar level of overall coverage

However, multiple challenges were introduced, including:

• Loss of a central platform for incident triage
• Inconsistent reporting, as each tool offers different metric options and provides data in different formats
• Different teams with varying levels of information security expertise sharing DLP responsibilities (e.g., defining detection policies, fine-tuning policies, developing incident response procedures)

In addition, unexpected costs have occurred as a result of the increased complexity:

• Training staff to work with their DLP modules
• Hiring new staff to address the increase in DLP events
• Additional license costs to attain the level of DLP coverage needed
• Professional services to help configure and manage some of the DLP implementations

Because the DLP add-ons were part of Bank1’s previously purchased cloud-based solutions, it was assumed that all licensing and staffing requirements would already be satisfied. But DLP is not a core competency of email and network administrators or cloud storage managers. It is unreasonable to assume that they can simply step in and manage DLP along with the rest of their responsibilities without additional training and support.

As figure 4 shows, the costs Bank1 saved by replacing the standalone DLP tool were replaced and exceeded by the additional, unanticipated costs.

In Bank1’s example, the overall costs for running the DLP program increased by approximately 25%. But this may be obfuscated by the fact that instead of having one DLP line item on the balance sheet there will be other costs related to licensing, training, and personnel that may not be associated with the DLP consolidation project.

Alternatives to DLP Tool Consolidation

As the exercise demonstrates, consolidation of DLP tools can backfire. But that does not mean that there are no solutions or alternatives available. Depending on the key issues an organization tries to address (apart from saving money, which is always an incentive, of course), there are several options available:

1. Do not consolidate, complement. In today’s IT landscape, commonly comprising both on-premises and cloud resources, a single DLP solution will likely not be able to satisfy all detection use cases. But that does not mean it must be replaced entirely. Instead, complimenting it with a few add-on DLP solutions will help close detection gaps without substantially increasing complexity. However, it must be ensured that DLP program management is still centralized and not offloaded to the product owners.
   Figure 5 illustrates how Bank1 could have used results from the consolidation assessment to complement the DLP program in place with only two additional tools to keep the requested visibility.
   
   

   

   Costs would have increased for licensing, but Bank1 would still have saved money compared to the path chosen. In addition, established teams, workflows, and reports could have continued to be leveraged to prevent a disruption in service or detection.
2. Orchestrate and automate. As managing more than one DLP tool will become inevitable, leveraging a security information and event management (SIEM) tool is a great first step to get the alerts from different tools into one single platform. This enables a centralized hub that can be used for data review and reporting. Or take it to the next level by implementing a security orchestration, automation, and response (SOAR) platform that can be leveraged to automate workflows and reduce the time analysts must spend on incident response. This solution will enable central management of some key DLP functionalities: incident response and reporting.
3. Leave it to the pros. If the teams responsible for the DLP tools are not specialized in the craft, or there is a staffing shortage, hiring a managed security service provider (MSSP) can be the solution. An MSSP specializing in DLP will be able to provide guidance on selecting the best tools to satisfy all relevant use cases. In addition, they can effectively manage the different platforms, support orchestration and central reporting, and ensure that policy tuning and incident triage are performed in a uniform way to avoid detection blind spots.

Conclusion

In modern IT environments, multiple DLP tools are becoming the norm, and consolidating them with the goals of addressing vendor sprawl and saving money is a common exercise in the enterprise space. However, due to DLP’s complex nature, the perceived benefits can ultimately turn into a financial drain and a data protection disadvantage. Understanding that DLP is not like any other cybersecurity tool is a critical first step. Running a consolidation assessment will help to gain a better understanding of the different tools available. Based on the assessment results, the ultimate decision may be the desired replacement of certain more expensive tools. But in most cases, using a gentler approach—complementing an existing DLP instance, leveraging SIEM and SOAR tools, or outsourcing DLP program management to an MSSP—will be the better choice. It prevents an unnecessary increase in complexity, streamlines the majority of workflows, and ultimately keeps an organization’s data safe.

Endnotes

¹ McNaughton, C.; “The Problems with Data Leakage Prevention (DLP) Platforms: When Technology Outpaces User Experience,” ShadowSight, 20 May 2024
² de Groot, J.; “What is Data Loss Prevention (DLP)? Definition, Types & Tips,” Digital Guardian, 1 October 2020
³ Eizenberg, E.; “The Unattainable Promised Land of Tool Consolidation,” BigPanda, 4 February 2021
⁴ Fortra, “Fortra (The New Face of HelpSystems) Welcomes Digital Guardian”
⁵ Eizenberg; “The Unattainable Promised Land”
⁶ Sawatzki, D.; When Shadows Cast Doubt: The Hidden Problem of Shadow DLP, USA, 2024
⁷ Violino, B.; “6 Tips for Consolidating Your IT Security Tool Set,” CSO Online, 11 July 2024

DENNIS SAWATZKI | CISA, CRISC

Is a lead security analyst at Infolock, where he is responsible for managing data governance programs for some of its key customers. He has more than 10 years of cybersecurity experience and specializes in the implementation of all facets of data loss prevention (DLP) including incident triage, system administration, and DLP program definition and execution. He recently published an eBook and has hosted webinars discussing the risk of shadow DLP.