Taking steps to keep your business data secure in Microsoft 365 is relatively straightforward, with great discovery, monitoring, protection and lifecycle management capabilities integrated deeply into the fabric of the ecosystem.

Thing is, there are a million other cloud services your data can end up in as well. Taking steps to protect sensitive information from being uploaded from your managed endpoints to unapproved SaaS services is something I warmly recommend.

In this blog, I’ll try to demonstrate one possible way to go about this, taking advantage of Microsoft Purview Endpoint DLP capabilities. This is not a guide for production rollouts “as is”, but instead aims to provide a more general idea for how to approach this key scenario.

Prerequisites

To use the capabilities I discuss in this blog, you’ll need to have the licensing to use Defender for Endpoint & Endpoint DLP. To understand which services your licenses permit you to use, I recommend Aaron Dinnage’s fantastic M365Maps.com and its licensing matrix.

First up, you need to make sure your managed devices are onboarded either to Defender for Endpoint or directly to Microsoft Purview. This lets you audit relevant events and enforce controls.

If you already onboarded your devices to Defender for Endpoint, you still need to take the one-time step of turning on onboarding to Purview as well. This is done in the Compliance portal, under Settings > Device onboarding.

It is also beneficial (but not mandatory) to have functional document sensitivity labeling in place and in widespread use.

The process for controlling file uploads to unapproved cloud services can be thought of in five steps after the initial preparation is done:

1. Designate unallowed and approved browsers
2. Understand your current cloud service usage and risks
3. Define explicitly unapproved and approved cloud services
4. Configure Endpoint DLP to control and audit file uploads
5. Monitor outcomes and respond to incidents

Browsers

Let’s start with web browsers.

To upload files to any SaaS cloud service, people are generally going to use a browser. Maybe it’s Edge, maybe it’s Chrome or perhaps Firefox. Some might opt for Opera and so forth.

If you want to detect and control uploads of sensitive files to unapproved cloud services, you need a compatible browser that can work together with Defender for Endpoint to coordinate the required actions.

As of 4/2023, the currently supported browsers are Edge (natively), Chrome (with a browser extension) and Firefox (in preview, with a browser extension).

👍 Approved browsers

For Edge, you don’t need to do anything. It’s got all the required bits and pieces ready under the hood.

For Chrome, you need to deploy the Microsoft Purview extension.

For Firefox, you also need to deploy the Microsoft Purview extension.

For both Chrome and Firefox, as of 4/2023 the extension doesn’t support Incognito / Private Browsing mode, so you’ll need to disable that via policy to ensure correct functionality.

As a bonus, deploying the extension for Chrome / Firefox will help you get improved visibility to important signals from those browsers on endpoints that can help you design your DLP solution.

(For Chrome, the extension additionally feeds into Insider Risk Management, providing new Risky browsing indicators. Firefox could very well get this in the future as well, since it already has the extension.)

🚫 Unallowed browsers

As a natural follow-up to defining your approved browsers for Microsoft Purview compatibility, you’ll want to make sure any other browsers aren’t allowed to interact with your sensitive business data.

You can do this in Endpoint DLP settings in the Compliance portal. Take a look under Browser and domain restrictions to sensitive data and you’ll find a bunch of common pre-configured browser options. If a browser you want to restrict isn’t on the list, you can add it yourself.

• For Windows, just define the executable.
• For MacOS, you’ll have to define the full path.

When trying to use unallowed browsers to access content protected by Endpoint DLP rules, people will be directed to Microsoft Edge instead.

Understanding existing upload activities

When it comes to organizational data, cloud services can be split into more or less three buckets:

• 👍 Identified & approved – your Microsoft cloud services and other supported services like ServiceNow, Jira etc.
• 🚫 Identified & unapproved – services you explicitly don’t want your organizational files to end up in. Examples can include consumer messaging and file storage services like Outlook.com, GMail, Dropbox, WhatsApp and so forth.
• ❓Unidentified – all of the services people also upload organizational documents to but that you don’t know about. These are the ones you need to make an effort to uncover while preparing to shape your Endpoint DLP policy.

Luckily, if you have your managed devices onboarded to Defender for Endpoint or directly to Microsoft Purview, you can start leveraging visibility into an expanded selection of device events to build a comprehensive understanding into sensitive data movements – both in general terms, and for the purposes of this specific scenario.

I highlighted some of these newly reported events below.

My favourite tool for exploring events for data security development purposes is the Activity Explorer in the Compliance portal.

When the goal is to gain visibility into file uploads to potentially undesirable cloud services, the File copied to cloud event is exactly what we want to look at. We can then further refine our results by filtering only for files with specific sensitivity labels.

💡Activity Explorer tips:

• While the username and the file path columns are visible by default, you can customize the view before refining your search to ensure you aren’t unnecessarily exposed to identifying information.
• On the other hand, you might want to enable the Target domain column along with the Sensitivity label, Sensitive info type, File extension and possibly Device name columns.
• I recommend always adjusting your view to only see relevant information before starting discovery work in the Activity explorer.

Once you have your Activity Explorer view prepared and cleaned of personally-identifying information (PII), you are free to refine the results and do some discovery.

In the design phase for new DLP policies, I recommend aggregating and visualizing the data in Excel. You can use the export function to do this, provided you have less than 10,000 events in scope.

If you have more events than that, I suggest refining your filters and time scope until you fit within the export limit.

Alternatively, you can pull even more events by leveraging the Export-ActivityExplorerData PowerShell cmdlet. Here’s a script I wrote to facilitate pulling large amounts of events using that method: GetActivityExplorerEvents.ps1 – you’re welcome to use it as a template.

There are many ways to look at file upload events in Excel, but here’s an example. You can create a Pivot chart to show the # of uploaded files per cloud service, grouped by sensitivity label. Like this, you can rapidly pick out previously unidentified real-life scenarios to support design efforts.

I suggest taking a few weeks worth of events and using them to make a list of all of the domains your business information was actually uploaded to. Then you can go through the list and decide whether usage of those services is approved or unapproved.

You can use this groundwork to your advantage in the next part.

Preparing sensitive service domain groups

Once you have decided which cloud services you want to allow sensitive data to be uploaded to, you want to create service domain groups in Endpoint DLP settings. These groups of domains (and IP addresses & IP ranges) can then be leveraged in Endpoint DLP policies to apply restrictions per group.

Here’s an example what a limited Unapproved services service domain group could look like:

💡Tip: Check out the syntax options for defining service domain groups here in Microsoft Learn.

Similarly, you might want to create a dedicated service domain group for Approved services. In it, you can define domains like your own domain’s SharePoint and OneDrive, along with other OK’d services.

As I mentioned before, you can also add individual IPs and IP ranges to these groups. This is handy since not all services use a domain – this can especially be true for some internal systems.

You could also create all kinds of other groupings of domains for more specific purposes – like one for applying controls specifically for known consumer-focused cloud services.

Creating Endpoint DLP policy rules

Now you’re ready to create some Endpoint DLP policies to start taking charge of upload actions.

Create a DLP policy scoped to the Devices location.

Then, create a new DLP rule.

If you want to, you can use Conditions to limit upload restrictions only to content that has sensitive information or a certain sensitivity label. In the DLP rule’s Actions, you’ll choose to Audit or restrict activities on devices. This gives you access to the Service domain and browser activities, among other options.

Here, you can take action on a couple of different levels.

The control (Audit, Block w/ override or Block) you choose here will apply to any configured individual restricted service domains and for any specified unallowed browsers.

To apply granular and differentiated controls for your service domain groups containing approved and unapproved domains, choose the option called Choose different restriction for sensitive service domains.

First, you can add any of your service domain groups to the policy’s scope. Then, you can choose a differentiated control for domains in that group. Priority matters here – if a domain is part of several groups, the group with the highest priority wins.

In this case, we might want to block sensitive file uploads to consumer services and other unapproved services, while only auditing files uploaded into our approved services. We could also choose to simply allow uploads without auditing.

By the way, I would recommend monitoring sensitive data upload activity even for approved domains as a baseline measure and only disabling DLP auditing for specific domains if the need arises.

With the DLP policy configured, I’ll move to show you the user perspective.

The user experience

Freshly created and recently modified Endpoint DLP policies can take some time to propagate to endpoints. This latency is affected by a multitude of factors, including whether the endpoint is online or not.

In general, I would expect new policy propagation to take around 24h – and I can just be pleasantly surprised if it’s faster than that. 😏

Edge – upload to unapproved and approved domain

In the first user experience demonstration, we use Edge to upload a document to two different domains:

• The unapproved Dropbox.com, which gets blocked. We are informed of the restriction via a native browser pop-up.
• the approved SharePoint online of our tenant, which is allowed and silently audited.

Chrome – upload to unapproved domain

In the second demonstration, we use Chrome with the Microsoft Purview extension installed to upload a confidential document to the unapproved consumer OneDrive account. The upload gets blocked, and we are notified via a Windows native popup.

Firefox – upload to unapproved domain

The same scenario as with Chrome – using Firefox with the Microsoft Purview extension installed. Unlike Chrome, the default message for Firefox mentions the name of the document

Monitoring the results at scale

After implementing Endpoint DLP to block file uploads to unapproved cloud services, you’ll want to periodically monitor its effectiveness.

In Activity Explorer

Activity Explorer can help you out with DLP monitoring as well – but this time, you’ll want to look for..

• Activity: DLPRuleMatch
• Rule: <your DLP policy rule name(s)>

For view customizations, I like to look at file extension, application, enforcement mode, target domain and activity type. If your DLP rule is scoped to trigger from multiple different sensitivity labels or various types of sensitive content, you’ll typically want to include related columns as necessary.

For some Endpoint DLP scenarios, you might also want to start an actual investigation when a rule match (or several) occur. This might for example be the case for uploads of the most highly confidential and controlled materials into especially risky cloud services.

To enable facilitating an effective incident response process in these cases, you’ll want to modify desired Endpoint DLP policy rule(s) to generate alerts – this is not on by default.

As a general rule, I believe you should only generate alerts from DLP when you really need them. Alerts and incidents get investigated by SecOps teams and there are a multitude of reasons to not give them any alerts we don’t truly need them to dig into with an “assume breach” mentality.

In Sentinel

Both DLP rule matches and DLP alerts can also be ingested to Microsoft Sentinel through Defender for Cloud Apps, using the Microsoft 365 Defender connector.

You can find DLP rule matches in the CloudAppEvents table:

CloudAppEvents
| where ActionType == "DLPRuleMatch"

To make the most of this data, you’ll need to extract and extend most relevant fields from the JSON-formatted RawEventData field. It often also includes a ton of metadata about the DLP rule match and assets related to the event – too much to unpack in this space. Happy exploring, though!

As always in Sentinel, you can choose to retain events in the CloudAppEvents table in interactive and or archived form for extended periods of time. This lets you utilize a large volume of DLP matches to create continually updated, long-term aggregations and reports to describe the effects your DLP policies have had.

In conclusion

While Endpoint DLP is already supported in both Windows 10/11 and macOS, there are still some capability differences.

Microsoft seems to be focusing significant efforts to building more and more comprehensive capabilities into Endpoint DLP, with support coming soon for capabilities such as..

• Document Fingerprints
• Optical Character Recognition (OCR)
• Contextual evidence information for admins
• + certain other very cool ones that I have had the privilege of testing, but cannot talk about just yet.

Enhanced capabilities for MacOS are also in the works. All around, Endpoint DLP is already in a strong place right now and I could probably keep blogging about it exclusively for a few months going forward.

Not saying I’ll do that – but I could. 😉 Try it out for yourself and see!

I have to admit that Endpoint DLP is currently my favorite DLP capability for discovery, monitoring and control – and it still seems to be critically underutilized.

Thanks for walking through this one singular use case with me. I hope to write about others in the near future.

Cheers! ✌️