(Updated on 02/18/2021)
This is part one in our exclusive three-part series on DLP problems and how to solve them.
Data loss prevention (DLP) is a billion-dollar industry. In fact, your company has probably invested a significant amount of your cyber security budget to protect your confidential data from being shared outside the company. But, how are industry giants like Morgan Stanley and AT&T still suffering from major insider breaches—didn’t they have DLP?
They did. They still do. But just using DLP isn’t enough. Here’s why DLP hasn’t lived up to their expectations and why you shouldn’t settle for either:
1. DLP Requires Classification
To adequately monitor sensitive information, traditional DLP solutions need to know where that sensitive information is located, and then that information must be assigned individualised policies and tags. This is called classification. For enterprises, having to implement the classification that must go with DLP—especially if “Data at Rest” classification is required—is a painstaking and time-consuming process. That is, if it’s done correctly. If not, and data is improperly classified, the traditional DLP has no way of knowing if sensitive data is being leaked.
2. DLP Is Incompatible With SaaS File Sharing
Widely used SaaS file-sharing applications, such as Dropbox and Google Drive, do not rely on transferring data directly between users—as, say, sending an attachment on an email does—but rather by the distribution of a direct link to said content. Traditional DLP solutions lack the capabilities to understand these peer-to-peer sharing semantics and therefore cannot adequately assess the movement of data.
And even if a DLP solution could somehow gain network-level visibility into shared SaaS content traffic, thereby “seeing” each and every link transmitted across an enterprise server, it still doesn’t address the encryption problem. By their very nature, these shared links provide no real indication into what content is being shared— for example, adding someone to a Google Docs file or document gives little indication to what is actually in the document—and as such, traditional DLP solutions cannot adequately interpret links.
3. DLP Cannot Account For Many Internet-Connected Devices
“Bring your own device” (BYOD) policies are increasingly prevalent in the workplace, and many professionals now use personal, mobile devices (i.e., phones, tablets, personal laptops) to perform a large portion of their jobs. To be effective, DLP solutions need to be installed on every potential access point. While possible (although cumbersome and time-consuming) for every stationary workstation in the enterprise, the same cannot be said for mobile devices or shared devices, such as those found in community workspaces or Internet cafes. And all it takes is a single access point to gain entry into the entire system.
4. DLP Cannot Provide Insight Into Suspicious Communications
Traditional DLP solutions cannot decipher suspicious conversations over email or other common enterprise messaging platforms, such as Slack, Gchat, HipChat, or Sharepoint. So if two employees are conspiring to export names out of Salesforce and sell them to a competitor, and they hatch out their plan via email, traditional DLPs cannot detect and prevent this loss of intellectual property.
5. DLP Is Kernel And Not Stable
To be effective, traditional DLP solutions need to be a “baked-in” component of a computer’s operating system. This creates two problems. On the technical side this results in bogged downed computers, choked networks and massive server installations. As the number of connected devices skyrockets, scalability becomes incredibly labor-intensive at best and downright impossible at worst.
Furthermore, even though Microsoft has introduced new and more effective ways of programming the kernel layer, most DLP solutions find themselves unable to turn their back on the already invested work done, using more primitive approaches. Therefore, they continue to promote unstable mechanisms. For example, TDI driver versus Windows Filtering Platform.
On the human side, a DLP solution that operates on a “lower layer” doesn’t adequately provide insight into human behaviours (such as the aforementioned malicious plotting via email). User activity is recorded in logs which offer an incomprehensive picture of the way humans actually behave. The best solutions operate at the “human layer.”
6. DLP May Not Penetrate Homegrown Applications
If an enterprise relies on proprietary, homegrown applications as a key function of the business, there is no guarantee that a traditional DLP system may prove compatible. This is because DLPs are Kernel, and trying to “bake-in” a security solution into an existing operating system may prove detrimental to pre-established applications. If this is the case (as it is often), traditional DLPs simply provide no effective way to monitor insider threats taking place within homegrown applications.
The same problems can also apply to Clearcase and other source code repository systems that may have impenetrable communications (proprietary protocols).
7. DLP Does Not Learn
A traditional DLP solution may tell stakeholders about the security risks it finds, but provides no way of identifying and learning from what it is missing. This means it’s easy to miss potential weak points, such as when policies are not properly configured or when large groups of users don’t have a DLP installed. A lot can be missed.
In the second part of our three-part series on DLP problems, we’ll cover why DLP solution is not necessarily obsolete.