Key Differences Between Legacy vs Cloud-First DLP

Written by Amit Kandpal, Director - Customer Success at Netskope

The first blog in this series covered some critical and fundamental aspects of DLP transformation programs that are often not fully understood.

A simple but effective framework to analyze the key differences between legacy DLP context compared to the cloud-first one is to look at the key differences in channels, content, classification, and context.

Channels:

The legacy tools focus on web, email, and endpoint channels which provided acceptable coverage when the majority of applications, data, and users were within a defined perimeter. In the cloud-first world, the bulk of the data resides in SaaS applications and the public cloud and is exchanged using web email and collaboration tools which are often cloud to cloud. In addition, a significant amount of traffic comes from unmanaged devices. Any DLP transformation will need coverage for each of these scenarios.

Content:

The legacy tools focused on file types like PDF, Office documents, text-heavy documents, and some image formats like JPG or PNG. In the cloud-first world, a significant part of the content is in cloud-native formats, audio, and video. A lot of the content is generated in the cloud itself. Any DLP transformation will need to be able to support these formats with acceptable efficacy rates.

From Classification to Context:

The transitional DLP approach is to classify the documents manually or with a took and then use regexes, dictionaries, Fingerprinting, Exact data Match, and sometimes OCR to look for specific data and block it at the endpoint. The modern DLP is all about context. Some key contextual variables to consider are:

• Device: The DLP solution needs to be aware there the traffic is coming from a corporate device or a personal device as the applicable policy and action may vary based on that.
• Sanctioned vs Unsanctioned App: Most companies have a list of sanctioned applications for different categories like email, storage, collaboration CRM. HCM etc. These applications are vetted and have the required auditing and controls. The DLP tool needs to be aware of the application is sanctioned as certain data and data transfers may be allowed for sanctioned apps and need to be blocked for the unsanctioned ones.
• Corporate vs Personal Instance: A sanctioned app can have corporate and personal instances and a DLP solution needs to be aware of the nature of instances. The policy for a personal OneDrive or Gmail, for example, will typically be very different compared to the personal instance.
• Risk Profile: Within the unsanctioned category, the DLP solution needs to be aware of the risk profile of the application. The policy and actions for a well-known app, even unsanctioned, will be different from an app that has to known compliance or security issues
• Activity: Most cloud application transactions have activity types like Post, Share, etc. that go beyond the traditional upload and download. These activities need to be supported for granular policies which do not impact user productivity.

The other components to consider are user risk rating, application configuration, and granular actions (like user coaching instead of just allow and block actions). While the first two are typically discussed in related categories like UEBA and SSPM, these need to be considered while formulating the DLP strategy. We will discuss some of these considerations in the following blog posts of this series.