Most misconceptions about what data leakage prevention (DLP) is and what it can do originate from treating DLP like a “checkbox” running it like any other IT project, skimping on a “free” solution, or listening to analysts/ vendors selling something other than DLP.
Many believe DLP is a product they buy and implement, rather than a program itself. DLP is a grouping of specialized people, creating a set of specific policies and processes, leveraging a set of tools to accomplish reduced risk from data loss. The biggest mistake DLP newcomers make is trying to use non-dedicated (or purpose-trained) staff to execute the program.
Others assume DLP can be treated as a typical IT project, one with requirements-gathering with stakeholders and service-level agreements (SLAs). Such projects are rarely iterative, communicate with the business or leverage the business to “own” the program, including incident response. Ultimate accountability still rolls to the CISO, but only insomuch as s/he has allowed the business to make informed decisions regarding participation.
Some fear bringing in DLP will force them to act on what they find. Certainly, there is vague verbiage in several regulations (HIPAA/GLBA) stating that management cannot ignore signs of data theft or tampering. But there is no law stating one need immediately act on every bit of data from every tool in the enterprise. The primary source of corporate liability from loss of data results from ignoring the problem and not having a plan to maintain adequate levels of protection. Not having one at all smacks of negligence.
Many contend DLP is so sensitive they must manage it in house, yet many failures result because DLP is tough and expensive to staff, train and operate. The data it captures is so sensitive, most organizations keep the software on premise, getting by with a minimal, typically shared team. But there are solutions that ensure no sensitive data is stored in the cloud, provide dedicated specialists and cost far less than even a half-hearted attempt to staff the project.
Another misconception is that a data classification program is not needed to deploy DLP. This is technically correct, in that a classification project need not be in place to be successful with a DLP program. That's akin to buying an expensive video surveillance system without knowing what you're protecting or where it is and then placing the cameras in the wrong locations. It's far better to do the initial legwork by drafting a working version. With a solid foundation, your tools will help to improve and refine policies. Resist the urge to jump in and buy that shiny new DLP toy before you truly know what you need.
It's also misleading to think one need not have a corporate sensitive data handling and protection policy to deploy DLP. Defining acceptable use of data (which also builds on a data classification scheme) helps to draft DLP configurations in business language. This gives clear benefits:
- A roadmap for policy creation;
- A vehicle for user awareness;
- The ability to configure notifications referring to specific sections of the policy at the point of violation -- critical from a user awareness and behavioral training standpoint.
Some attempt to address the entire organization, across all data types simultaneously. Many projects aim for too much too quickly. It's far better to set the bar low with one to three simple use cases so you will knock it out of the park. This could be preventing CSRs from using USB drives or locking out particular cloud storage providers. High profile wins can generate the momentum necessary to move on to harder aspects of the program.
Others fear they will be locked out of DLP in privacy-centric economies like France and Germany. Attempting to monitor all network or endpoint activities in those environments can land you on the worker councils' hit lists, so adopt a slow and grow strategy, mixed with proper user privacy protections. Identify one to two highest value use cases where violations would be so egregious the councils would be putting themselves in an indefensible position if they balked at such monitoring. Be sure not to collect data in a way that it can be used for “eavesdropping” or “activity monitoring.” Leverage DLP tools that obfuscate the data collected from the tool so that incident response is looking at the violation itself, not the violator. Require that a designated individual selected by the council is needed to reveal the identity of violators. Respect that differing cultures place more emphasis on privacy and come to conversations in a spirit of mutual cooperation. You may find this mindset alone curries favor.
Finally, one should not assume execs care about fancy DLP reports. Volumes of pretty charts are usually useless. Execs typically care about few questions, including:
These questions usually pertain to IT security as a whole unit. Thus, it is wise to align the data being reported up to the CIO/CFO along these lines.
