Data loss prevention technology is garnering a lot of attention these days thanks to publicized data leaks and...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
increasingly stringent regulatory compliance mandates concerning data protection. While the technology itself is not a regulatory requirement, the ability to identify sensitive or private data, secure it (by rendering it illegible to unauthorized parties via encryption), and prevent its unauthorized disclosure – all objectives of DLP systems – can help organizations stay out of the headlines and meet their compliance and data security goals.
However, technology is only one small part of a full-blown DLP implementation. It also requires a significant amount of effort dedicated to strategy, people and process. When DLP deployment projects go wrong, it is usually due to common mistakes that arise in relation to these other non-technical components. Here are four DLP best practices to help ensure your organization’s data loss prevention initiative is a success.
1. Understand your requirements
The most critical DLP deployment mistakes are made before the technology is evaluated and acquired. According to Rich Mogull, analyst and CEO of analyst firm Securosis, one common mistake is failing to understand the technology and what it’s capable of. “People don’t set up their needs or requirements well enough, then when they go to deploy [DLP] they start running into trouble,” he says.
Andrew Engelbert, director of infrastructure and IT risk management at Oxford Consulting Group, agrees: “It’s important to have an understanding of what it is that’s driving your desire for DLP technology. What are you trying to solve? What’s driving the need for this technology? A lot of customers don’t have a DLP strategy in place before making the decision to purchase technology, and that gets them into a lot of trouble.”
Nine times out of ten, Engelbert says, his clients are considering DLP because they’ve been approached by a vendor that has used FUD (fear, uncertainty and doubt) to raise concerns about data protection.
“Don’t let the vendor define what your business needs are. They’re going to tell you everything they want to sell you... [DLP] is by no means a silver-bullet technology. It provides a cohesive solution to manage data loss activities, but it’s not bulletproof,” Engelbert says.
The term “DLP” describes a product set that includes different modules, usually one each to protect data in motion, data at rest and data in use (at the endpoint). These different modules are managed under a centralized management console. Vendors sell each module separately, enabling organizations to focus on high-risk areas. For example, Broadcom, an Irvine, Calif.-based maker of semiconductors for wired and wireless communications, began its DLP deployment with endpoint protection. “We deployed endpoint agents when we recognized that our biggest security gap was at the endpoint where we had proprietary data leaking,” says Geoffrey Aranoff, CISO at Broadcom.
Determining your organization’s DLP is the more onerous part of a DLP deployment., says Tony Meholic, CISO at Philadelphia-based Republic Bank. “You need to know what data you want to protect and where it’s residing,” he says.
Experts agree that understanding what you need from a DLP technology begins with understanding your data. “Before you run out and engage vendors and start proof of concepts, have a good understanding of what you need to protect and how you need to protect it,” says Mogull.
Once you get into the technical details, you will have the information you need to make a decision, explains Mogull. It will become clear which product will best suit your needs just based on your requirements. For example, if you need the ability to monitor SSL, you'll need to look for a product that has the appropriate technical pieces in place to enable that capability. Then you might consider which product(s) offer that capability natively versus those that tie in with another product.
Similarly, organizations need to decide which applications will be integrated with the DLP system. “It’s expected that you’re going to have conflicts. Not all the applications will play nicely in the sandbox,” says Aranoff. “If I have to filter out an application to make my DLP work, that’s a good short-term fix, but I won’t know if proprietary data is going through that app.”
2. Work with the business
The success of a DLP deployment also hinges on getting broad support across the organization from all data owners. Managerial levels and above should be engaged in a DLP project for several reasons. Of course, their cooperation is necessary since the deployment will impact a great number of users. These stakeholders should be educated on DLP technology, why it’s important for the business and how it’s going to impact users.
Data loss protection technology is fairly mature. According to Paula Musich, senior analyst at market research firm Current Analysis, the market has split into two. “The low-hanging fruit, if you will, is using DLP within a product or service… to protect mostly structured data; less so unstructured,” she says. These vendors have integrated DLP capabilities into pre-existing products like email and Web security gateways.
“Then there’s full-blown DLP implementation where you’re trying to boil the ocean to provide protection for both structured and unstructured data -- anything that’s valuable,” says Musich.
Such a deployment can be a significant undertaking. “It’s a very involved implementation to make that kind of capability a reality in many enterprises. It takes a long time,” she adds.
Once you have business stakeholders on board, you can conduct interviews with data owners to understand the data they have access to, their responsibilities for various data types, how and with whom it is shared, etc. In this manner you can begin to determine how the data should be protected.
Support from business stakeholders is also important to ensure the DLP implementation does not unnecessarily disrupt existing business processes. “They have to be involved because ultimately they’re the ones that use that information on a day-to-day basis. If you lock things off and don’t let users get the data they need, processes will get in a crunch,” says Allen Zuk, president and CEO of Sierra Management Consulting. For example, the marketing department may attempt to send a marketing plan for an upcoming product release to the organization’s PR agency. IT might stop this transmission because the marketing plan is sensitive information, not aware that this is a legitimate sharing of information.
On the other hand, false positives generated by DLP software may uncover broken business processes. “You’re going to have false positives, but you as the security practitioner can’t say, ‘This is a false positive,’” says Engelbert. Security needs to work with the business owner to identify why a specific business process is generating an alert. Together, security and the business owner can look at the business process, uncover the flaw and identify steps that can be put in place for remediation.
As an example of a broken business process, Engelbert describes a situation where, rather than using a secure file transfer solution, someone in the payroll department transfers spreadsheets with payroll information to a third party via email. The third party may have a legitimate need for that information, but it should be sent using an approved third-party solution or something like TLS to encrypt the data between organizations, explains Engelbert.
3. Get legal involved
Another “people” problem associated with DLP deployments is failing to get legal and compliance stakeholders involved. Like understanding your data protection needs, legal should be pulled into the discussion before anyone touches the technology. “It’s not too uncommon for tech folks to say, ‘We’re going to deploy this tool,’ but they haven’t necessarily sat down with legal and thought about: Are there compliance issues we’re contending with? What will we utilize the tools for? What practices will we put into place to make sure legal and compliance aren’t blindsided?,” says Zuk.
Legal stakeholders have a multifaceted role in a DLP deployment. “Legal is the authoritative source on what we need to do to keep ourselves out of hot water in the event something happens. They’re the subject matter experts on the regulatory changes and the direct implications across the U.S. They are the authoritative body on how we need to respond in the event that we confirm an incident has occurred,” explains Engelbert.
Legal should be involved, along with HR, when an incident has occurred that involves an employee. “They need to be involved so there’s clarity and consistency in the actions taken,” he adds.
Equally important is the legal department’s involvement to ensure the organization is adhering to regulatory mandates, like HIPAA and PCI DSS. Similarly, global organizations are likely subject to differing regional restrictions when it comes to employee monitoring. The legal department can clarify those restrictions and help ensure the DLP product is operating within legal boundaries.
In the event of data loss, the legal department also serves as “secondary stakeholders,” says Engelbert. As such, they can help with the overall escalation process of how an event will unfold. “Legal plays a critical role in helping define the thresholds for matches of credit card numbers going out in a spreadsheet. How many do we really care about? We’ll treat one or two differently than 500 or more,” he says.
4. Undertake a phased rollout
You have the proper people on board, you know what data you are going to protect and how, and you have the technology to do so. Now you’re ready to deploy your DLP solution, right? Not so fast. Another common DLP deployment mistake, say experts, is deploying everything at once instead of taking a calculated approach in which components are deployed incrementally. If you plan on deploying a complete DLP solution that covers data in motion, data at rest and data in use, start with just one of those components. You might also consider rolling it out to just one business unit to start.
“With a phased deployment, you have consumable portions that you can effectively monitor and manage all the way through,” says Engelbert. “If you try to eat the elephant all at once, it is a very large undertaking.”
A phased rollout offers several benefits, including the opportunity to acquire experience and lessons learned that can be applied to future phases. And with a successful rollout of one phase, both IT and business stakeholders will feel more confident delving into the next phase. This success can also translate into additional funding, if needed, for future phases because, for some organizations, the cost of acquiring an entire DLP package upfront simply isn’t viable, according to Engelbert. But even those organizations that acquire a complete DLP product still see the benefit of rolling it out in a phased approach.
“A deployment is usually straightforward,” says Mogull, “if it’s done incrementally. It can be easy, if you’re smart about it.”
About the author:
Crystal Bedell is a freelance writer specializing in security, networking and cloud computing. Send comments on this article to firstname.lastname@example.org.