What Is DLP Anyway?
IT chiefs have varying definitions for DLP. The “L” is “leak” for some and “loss” for others. Some say the “P” is for “prevention,” others say “protection.” But whether it’s data loss prevention or data leak protection, defining the best strategy for using this umbrella security approach remains a bit elusive for many organizations.
Why? Because although products are available from large and small manufacturers and the adoption rate of DLP products grows each year, IT managers often remain skeptical that these products are solving real security problems and reducing their organizations’ risk of data loss.
This is in part thanks to DLP being challenging to deploy, and this is for one key reason: It is not a distinct technology. It’s both a collection of technology products and a methodology.
An IT manager or security chief who tries to install DLP products on a network in the same way that he or she might install an intrusion prevention system (IPS) or an anti-spam gateway is likely to fail and to face frustration. If the goal of the DLP project is to check a box so that an auditor rates the enterprise as compliant, then the effort won’t likely achieve its overarching security objectives either. DLP efforts must be driven by the desire to reduce the risk of data loss in the organization, and that’s a lot more difficult than either plugging in a device or satisfying a group of auditors.
It’s helpful to draw a clear distinction between enterprise-class DLP and an emerging subset of DLP technologies that are now also widely available. Aware of the failure rate of DLP projects, security manufacturers have come to market with a variety of products that don’t aim at the full DLP space, but look narrowly at a specific issue, such as compliance, or a specific type of data, such as email. A limited scope for a DLP project can work well, as long as everyone in the organization agrees on the scope and its limited reduction in overall risk.
For example, DLP products incorporated in endpoint protection suites can easily track traffic in and out of those devices, a natural extension to the malware scanning already taking place. These types of tools, when implemented properly, work well at intercepting and providing feedback on unintentional data leakage, as well as USB device leakage. What they don’t do as well is handle situations with more malicious actors, either insiders or cybercriminals who have established a beachhead within the enterprise network.
Building a Solid Enterprise-class DLP
Every DLP maker has its own methodology for successful deployment, and these approaches are linked closely to the technology being deployed. It’s helpful when considering DLP projects to also look at a technology-independent methodology to understand whether a DLP initiative will achieve its goals when deployed inside an enterprise. The following steps will help the project team flesh out the elements critical to ensuring a successful DLP deployment and operation.
1. Start from the top and get buy-in
When running a DLP project, the chief security officer or chief financial officer of the organization should lead the initiative, with the IT team providing technical support and assisting in deployment and design. It’s important that IT managers not be delegated the role of DLP project leader because this immediately sends the wrong message to the organization.
It can create the impression that DLP is a technology solution that will be addressing a technology risk or problem, such as a crashed hard drive. Instead, it is essential that DLP be viewed as an enterprisewide strategy to mitigate business risk — the leakage of sensitive information assets.
The successful deployment of DLP depends on bringing a team of stakeholders to the table, defining the scope and goals of the project, and getting true consensus from all stakeholders. In this case, stakeholder buy-in represents more than an agreement to participate in initial activities. It means an agreement by all data owners to continue to play an active role for the foreseeable future.
DLP introduces a continuing process within an enterprise because any effective solution will generate frequent incident alerts. If the stakeholders don’t agree to allocate resources to analyze incidents and respond to alerts, then DLP can turn into an expensive piece of shelfware.
The appropriate participating stakeholders will vary depending on the organization, but the critical participants are the data owners — the people responsible for creating, managing and protecting certain types of information. It’s useful to look across all parts of the organization to understand what information is at risk and needs to be protected.
In a typical enterprise, this means that staff members from the human resources and finance departments must participate, because information about finances and staff are two types of data that must be protected. In an organization with any type of web presence, the web application owners must also take part, because they are likely collecting sensitive information about constituents or customers, ranging from simple demographics to financial information.
And, most important, the line-of-business teams must each be represented, because these teams stand to lose the most if there’s data leakage. The data they manage can span the gamut, from source code and manufacturing designs to proprietary planning documents and historical records.
2. Set goals and requirements
The nature of the DLP project needs to be defined in detail before moving to product selection. On the technology front, DLP offers many benefits, but it’s critical for the organization to identify and prioritize project goals to set a clear direction forward.
For example, one of the initial drivers for DLP is often compliance — making sure applicable regulatory requirements are properly supported. This will vary based on industry and enterprise type, but few organizations can operate without some type of compliance program.
Typically, compliance rules govern activities involving:
• Specific information sets, such as financial records, personally identifiable information or patient health data;
• Specific transmission channels, such as email or instant messaging.
DLP can clearly help with such oversight, but only if compliance is identified as part of the initiative early on. More important is a solid definition of exactly how DLP will be used as part of compliance processes. A one-word check box labeled “compliance” won’t ensure success because neither the right techniques nor tools will likely be considered, purchased or applied.
Although an enterprise can deploy DLP as a compliance-only project, it will get greater value if the initiative is tied to specific business risk mitigation strategies, such as ensuring that intellectual property or commercial data is not shared inappropriately. Whatever the ultimate goals, they should be noted explicitly and in as much detail as possible.
Because DLP is as much a process as a group of products, the program goals should also focus on user behavior, which could include identifying inappropriate user activities, providing awareness and feedback to users, helping to train users about how to manage specific data types properly, and, if necessary, using the DLP technology as a discovery and investigation tool when malicious actors are detected.
It’s important that the stakeholders participating in DLP goal-setting agree on the defined goals and consider them worthwhile business objectives. CSOs leading DLP projects can remind stakeholders that every goal listed as part of the project may result in some cost — management, human resources and even direct equipment or licensing expenses. This reminder will help ensure that the initial plans and final agreement are based on sound business principles.
3. Apply a risk-based model
Measuring risk and return on investment (or return on security investment) of security projects can be tricky. Even so, risk measurement should be a strong part of any DLP project. What that means is that the risk measurement should be used to direct the project, not merely to justify it.
Traditional risk measurement suggests that an organization should factor the cost or impact of a loss against the probability of the loss. The DLP project’s stakeholders typically can estimate the overall organizational cost of a particular type of data loss. But this leaves the DLP project team the unenviable and generally impossible task of estimating the probability of each particular loss.
Rather than try and dive deep and assign random numbers to loss probabilities, the DLP team should focus on the most likely types of loss based on the goals of the project.
For example, if protecting customer data is a goal, then identifying the most likely vectors for loss of customer data will help when attempting to measure risk and prioritize DLP techniques. Customer data can be lost by having inappropriate FTP or web servers, by a malicious staffer removing data on a USB drive, by a notebook falling into the wrong hands, or possibly by someone emailing data accidentally outside of the enterprise. But by and large, the greatest risk comes from attackers — cybercriminals that want the data and want to exploit it.
If a notebook with customer data is lost, that’s a problem. But depending on how the data has been protected and how the notebook was lost, the incident may not represent a huge risk to the organization. If an attacker breaks in specifically to steal customer data, then the goal is clearly to exploit the data, which obviously raises the risk to the enterprise.
Using a risk-based model doesn’t mean that the IT staff should forego looking for inappropriate FTP servers. It just means that the DLP project should start with a goal to mitigate the greatest risks first. Notice that the previous example using the notebook includes risks that have nothing to do with a DLP product.
Finding poorly secured or inappropriate FTP servers can be the job of a vulnerability analysis or network mapping tool, while tracking down customer information in the wrong file shares is an entirely different exercise, and ensuring that whole-disk encryption is in place on every notebook is yet another task. It’s the identification of these different issues that helps move DLP away from a “buy a product to solve a problem” initiative and toward the much more effective “reduce the risk of this particular type of data loss” effort.
4. Determine a strategy
With goals and risk measurement taken care of, the next step is to determine the DLP strategy that will detail the fastest and most effective ways of meeting a specific set of goals and reducing business risk.
Obviously, part of the strategy will likely involve identification of a DLP product, and that’s where the IT team will play a critical role in the project. But it’s possible that explicit DLP products may not be needed.
A variety of IT controls can be applied to enterprise assets, either through new products or simply by redesigning policy in existing products (such as URL content filters, anti-spam gateways and firewalls) to achieve the DLP objectives. But even under these scenarios, the IT team must help provide the background information and technology guidance necessary to move forward.
As the strategy begins to shake out, the project group will enter the product selection process. The IT staff can take the business goals and risk measurements and help identify the most appropriate products to help meet the DLP goals of the organization.
Advice at this stage of the project is plentiful from product manufacturers, third-party consultants and analyst firms. And although it’s possible that no products will be needed, it’s likely that at least one or two will be procured and installed as part of the DLP project.
But even after products have been installed and policies changed within the existing infrastructure, the strategy phase should not end. With DLP, as already noted, the organization must make a long-term commitment to implementation and enforcement.
For many enterprises, DLP is more so about user training and user feedback as it is about external cybercriminals and malicious actors. The continuing chain of incident alerts must be investigated, which implies a full workflow of incident qualification, research, notification and resolution. And then all learnings must be pumped back into the strategy and the process (and possibly some technology tools) refined.
Squeezing the takeaway from incidents is only part of the continuing strategy evolution that must occur within a successful DLP program. Over time, both incidents and the changing IT landscape will require that data owners be prepared to make policy decisions about data archiving, role-based access controls, policy refinements and adaption of DLP processes to changes within the IT infrastructure.
5. Measure results and give feedback
DLP projects require regular evaluations and audits — like any other business initiative. Just as the continuing cost of incident management and policy refinement must be a factored into the organization’s annual budget for DLP, so too must periodic review of the program.
Well-run DLP projects will hinge on development of key performance indicators to help measure success. These metrics can be used as guideposts, where needed, for setting strategy changes and ensuring project realignment.
Want to learn more? Check out CDW’s Next-Generation Security Reference Guide.
