Data leakage prevention (DLP) is garnering a lot of attention as a cure-all for risk management. Yet deployments often get a bad rap for being too burdensome on an organization's processes. Many IT professionals – and their management – wonder if they're getting the right ROI given the perceived pain and effort involved.
We often see that DLP technologies are recommended before examining how they will work within a company's existing security policies and processes. Is there an understanding of how and why data is being collected? Do administrators know where sensitive information is and how it migrated there? Who internally and externally is contributing to and interacting with this data? And how will the response to security incidents be managed?In a rush to secure their enterprises, reduce risk and meet compliance regulations, IT departments are deploying new DLP technologies without fully engaging the business side of a company. This is forcing fundamental changes in business processes, rather than adapting DLP to the requirements of that organization.
The key to successful DLP solutions is to first look at business processes and existing data and security requirements.
Understand the core business operational or compliance issues up front, matching the business and data processes to the DLP application or tool. What kind of regulatory issues – such as the Gramm-Leach-Bliley Act or HIPAA – need to be considered, or how might third-party data compliance requirements, such as PCI, affect new DLP options? Business processes also drive data acquisition and data flow strategies so, for example, what kinds of protections are required for both data in motion (email) and data at rest (file sharing)?Before making a full DLP deployment, make sure data protection and response policies reflect how an organization can reasonably respond. For example, to cut back on the false positives that impact time and resources, business units need to work with IT to define, and refine with testing, exactly what kind of incidents are flagged as a violation. Policy testing should be defined based on using actual data (e.g., fingerprinting), not pattern matching/regular expressions, whenever possible.
Understanding business processes will also determine who needs access to what kind of information. IT can implement appropriate logical access rules and restrictions to protect sensitive or classified data. Doing all this up front avoids retooling the system and eliminates early user frustrations that often stymie new DLP projects.Further, create a tiered incident response process so that the proper level of management and support teams are responding or contributing to decisions about how to react to security threats. Where is the first line of response? Instead of IT reporting every incident or providing summaries directly to senior decision-makers, an incident response team should be empowered to research the incident and its cause. Was the event intentional or does it reflect some inconsistency in policy or a flawed DLP action?
Data leakage prevention systems and tools provide powerful safeguards for organizations reconciling the need for collecting and harnessing data with the need to manage risk and compliance. Creating an equal level of assurance that these implementations will be successful and yield ROI and acceptance across the enterprise requires a joint IT and business-level team working to define and apply the organizational processes to new DLP disciplines and tools.
