The many ways to prevent data leakage in Microsoft 365

Office 365 Data Loss Prevention (DLP), Windows Information Protection (aka Endpoint DLP), Conditional Access App Enforced Restrictions, Conditional Access App Control with Microsoft Cloud App security, Sensitivity labels, Retention labels–are you thoroughly confused yet?

All of the above can help you to prevent the leakage of sensitive data under certain circumstances. But how do you know what to use and when?

Good question, reader. Let’s tackle that now.

I created the below “Cheat sheet” to go along with this post (TL;DR version).

Office 365 DLP (Sensitive info types and Retention labels)

This option specifically targets data that resides within Office 365. As of today, DLP rules can be written to trigger an action based on exactly two things:

1. Sensitive information types
2. Retention labels

The actions you can define based on the above conditions include:

• Filing an incident report
• Notifying / warning the end user
• Automatically encrypting the message (Exchange Online only)
• Block the message / sharing attempt

Even when you pick the most restrictive option (block external sharing), it is not hard to figure out your way around DLP policies. Downloading a copy of the data locally and sending it out on the hush over email (corporate or personal, depending) is one example. So it is certainly not a comprehensive solution on its own, and would need to be combined with other options for better coverage.

However, in some cases this is all that is required–just a little fencing to remind the user population at large about corporate policies around the sharing of certain sensitive information.

Windows Information Protection (aka Endpoint DLP)

Windows Information Protection (WIP) will take over when the file is transferred from its origin in the cloud, to a local Windows device. And note: you can accomplish similar results for iOS and Android devices using MAM policies. These “App Protection Policies” can be targeted against managed and unmanaged devices alike.

While Office 365 DLP will place a “fence” around content stored in the Online services, WIP places a fence on the endpoint, that runs around the corporate apps and network data locations (which you define in a policy). Therefore, Windows will only allow corporate data to be saved or transferred to other approved corporate apps, sites and locations that live inside the fence. Personal and non-approved apps that are outside the fence cannot save or receive copies of corporate data.

See this article for more details. The other major benefit to using app protection (on any platform) is that you can wipe corporate data on the endpoint, effectively removing access to corporate info (e.g. loss, theft, departure), and without harming any personal data or apps on the device.

Policies for WIP and MAM are found under Microsoft Endpoint Manager > Apps > App protection policies.

Again, this takes us further than Office 365 DLP alone, but it still isn’t a perfect solution. It doesn’t cover Mac or other *nix platforms, for instance. And a savvy user might still be able to figure out their way around it. For instance, downloading content to a personal location via a non-enlightened browser.

Conditional Access: App enforced restrictions

Office 365 Exchange Online and Office 365 SharePoint Online (and by extension OneDrive, Teams, etc.) support limited, web-only access for unmanaged devices. That means that attachments or files stored in Office 365 cannot be downloaded to a non-corporate device.

You can build this under Conditional Access, using a Session control (rather than a Grant/Block Access control).

While it is possible to enable this policy whole-sale across the board in PowerShell, we can also now target it more precisely on a per-site basis. Therefore you can protect only your most sensitive locations with this kind of policy. More on that later.

While this doesn’t necessarily help contain the data once it is downloaded on a managed device, it does cut out the possibility that data could be downloaded, even accidentally, to an unmanaged device–so that really limits exposure (e.g. managed devices can be wiped remotely, unmanaged cannot).

Optionally, using Conditional access you could also enforce a policy that would block unmanaged devices and unsupported platforms entirely–further limiting exposure outside of corporate contexts.

Sensitivity labels

Let’s be honest–data is much too slippery nowadays to assume it will always remain within our corporate boundaries. The container-based methodology belongs to a legacy security model, similar to the firewall– it’s just another form of “perimeter.” Now our perimeter is everywhere a user comes in contact with our data–which is a much larger surface area than we’ve had to deal with in the past.

None of the previous methods I mentioned can enforce strong identity-based encryption on the file itself, whether it lives inside or outside of corporate boundary lines. Data is encrypted at rest in Office 365. Data protected by Windows Information Protection is encrypted at rest on the endpoint. But what happens once that data travels to another (non-corporate) location?

Enter Sensitivity labels (and its predecessor, Azure Information Protection). If a label is enabled for encryption, then it is capable of stamping corporate data with a tattoo that travels with the file–wherever it roams. Sent by email? Encrypted. Copied to external media? Encrypted. Shared over a chat or social media? You get the idea.

Sensitivity labels are therefore the strongest form of protection Microsoft 365 offers currently. The problem is, they also screw up the best collaboration features in Microsoft 365: Co-authoring, Delve, Search, etc. So very few customers like to implement this when they are used to having richer collaboration features available.

NOTE: Actually, this is changing right now–it’s still not perfect, but there is a public preview you can opt into that enables Sensitivity labels for SharePoint and OneDrive. At the same time, there is another preview that enables labeling of Office 365 Groups (e.g. Teams)–more on this coming soon.

MCAS and Conditonal Access App Control

Microsoft Cloud App Security is probably my favorite security app in Microsoft 365. Included with E5 plans or available as an add-on to others. MCAS might just be able to help you get the best of all worlds. And it works with many popular third-party apps, too.

There are several problems with implementing stuff like Conditional Access on a global scale. Sure, you can turn on a policy that blocks download on unmanaged devices, but the reason you would want to do that is probably only because of a small portion of your overall data, so why make life harder everywhere else?

Using Conditional Access App Control via MCAS, it is possible to create policies that monitor for specific parameters, and you can get pretty granular using custom expressions and other options.

Maybe you have certain keywords or project names that are private in nature, or even certain file extensions that you care about protecting more than others in specific cloud locations.

Consider this scenario: document encryption (e.g. applied via a label) will tend ruin some of the collaboration and productivity experience in Microsoft 365, so why not only require the file to be stamped upon download? This could be a better solution than having the content labeled in the cloud (at least until they finish working out the kinks in the current preview).

In this example, people are encouraged to collaborate and work with the files in the Office apps online, but they also still have the option of downloading them–at which point a label would be applied.

You can see that this is the only solution that will allow you to apply DLP to third-party apps, so that makes it an easy choice if you have that requirement but want to integrate it with some of the security goodness in Microsoft 365 like Conditional Access and classification labels.

Even outside of third-party app support, it’s value is in the degrees of customization it offers, and the granular control over policies (alert only, take a governance action like block download or apply classification, etc.)

In Summary

As you can see, we have many, many options. Hopefully this provides a good overview of “what’s possible” and why you might want to combine more than one technology from the Microsoft 365 suite in your own Data Loss Prevention strategy.

Thanks for reading. Leave questions or comments below (or email me).