IT leaders responsible for implementing DLP program frequently face many challenges during its implementation. If you're unsure how to begin, you may be asking yourself:
“Where do we start?”
“What data is important to the business?”
“Where is all of this data located?”
“Who owns the data?”
A DLP program seeks to improve information security and protect business information from data breaches. It’s not just a tool; it’s an approach that combines defined processes, well-informed and trained people, and effective technologies.
DLP cannot stop all attacks and nor can it mitigate the risk of poor business processes. A DLP program is a risk reduction, not a risk elimination exercise. Treat DLP as a program and process, not a technology, and follow specific steps to implement it successfully.
DLP Step #1: Scope the program
Goal: Provide insight into data and business practices to allow DLP to address real issues without prompting disruption.
First, understand the needs of the business by identifying and prioritizing risks such as the data risk appetite. Then identify the data the business needs to protect, including intellectual property (IP), and verify the data and application owners.
Use data flow mapping to identify where the data originates, where it is being saved, and where it is going. For example, data that is downloaded from a server, saved to a desktop, sent via a web browser, or uploaded to a cloud app has a data flow, and you use DLP tools to detect and block data at all of these points. Finally, develop appropriate security and information policies to support and promote the DLP program.
DLP Step #2: Start awareness and governance activities
Goal: Build a plan to communicate to all parties what is happening with data, why it is happening, the benefits, and the likely impacts on them.
Identify and improve business practices for data handling. For example, create a list of accepted protocols, programs, and data-handling procedures, and work with legal and procurement teams to include data loss requirements in contracts. Because DLP needs constant iteration as business needs change, the communication lines must remain open. Use a collaboration platform to perform surveys, convey messages and give users the ability to ask questions.
DLP Step #3: Design initial architecture
Goal: Map your DLP use cases (detection and context requirements) to each enforcement point.
Identify the DLP tool types that will provide the necessary control. As it’s not always possible to get one vendor or solution to cover every aspect of DLP your business may need, choose vendors that can protect data in the multiple use cases you identified in the data flow mapping activity. It’s also worth testing each solution thoroughly as a proof of concept before making a selection, and ensuring that it meets business requirements.
DLP Step #4: Begin to address dependencies
Goal: Push for improvements on some of the dependencies identified early on.
The ability of DLP programs to detect data loss can be confused by a range of dependencies, both technical and procedural. DLP effectiveness depends on addressing these dependencies.
Take identity management, for example. DLP cannot do much to prevent data loss if users are granted unrestricted access to data by default. Ensure that you only provide access to data if there is a legitimate business need. Also use data classification, which discovers sensitive data in storage locations, such as file shares, cloud storage, databases, and network-attached storage appliances, to shed light on data permissions, sensitivity, and locations.
DLP Step #5: Deploy, operate, and evolve
Goal: Start small and deploy in stages, as DLP rollouts can be disruptive.
Use a “monitoring only” initial implementation so you can test and refine your policies to reduce both false negatives and business impacts. Communicate each stage to impacted users, and let them know what is happening with data, when, and why.
As you move into operations mode, identify operational metrics that support both continuous delivery improvement and measuring DLP’s impact on data risk. These metrics could include the number of resolved incidents or the number of times DLP blocked sensitive data.
DLP is not a set-it-and-forget program, so be sure to allocate some resources to fine-tune DLP policies as changes in business processes or data types occur.
The original article by Anthony Carpino, Gartner's director analyst, is here.
The views and opinions expressed in this article are those of the author and do not necessarily reflect those of CDOTrends. Image credit: iStockphoto/the-lightwriter