Using DLP to protect sensitive sites

Posted by

Reading time: 5 minutes

During some configuration on DLP rules, I came across the term “sensitive sites”. Wondering what to make of these, I wanted to find out. So let’s take a look.

Data Loss Prevention

In one of my earlier posts (Microsoft 365 DLP – The (new) control pane?), I stated that data loss prevention might become the new control plane for guarding your information. In this blog, I want to focus a bit more on endpoint DLP. This is one of the most complex components within Microsoft Purview.

Some time ago I came across the term sensitive sites, so I wanted to explore these. The term itself first appeared in the Actions section of a DLP policy. Let’s see.


Sensitive sites?

Endpoint DLP allows you to check on actions performed on sensitive files on the endpoint. This can be both Windows or Mac (with some restrictions). For this to work, you will need the required licenses and have your endpoint onboarded to Microsoft Purview. If the devices are already onboarded to Microsoft Defender for Endpoint, then you are also set to go.

Endpoint DLP is different from many other DLP functions in Purview in that it has many, many options you can configure. These range from storage locations that do not have to be part of DLP protection to configuring safe USB devices that can be trusted.

Sensitive sites are part of these settings and can be found in the Browser and domain restrictions to sensitive data component.

You might notice two things:

  1. There is more than just one setting;
  2. Sensitive sites are not used as a term, it is called Sensitive service domain.

The term sensitive sites is not present in this interface. What you see in the screenshot is the name I gave to my group of “sensitive service domains”. But this can be confusing as the DLP rule itself does mention sensitive sites.

As to the other settings. These require some explanation. The main difference between Unallowed browsers | Service domains | and Sensitive service domain groups is the interaction with sensitive files.

The first two options are dedicated to the interaction with sensitive files (documents for example) by websites and/or web browsers. The third option focuses on the information on a website and the allowed/blocked interactions with that information. Which makes sense, as not all information is stored in files 🙂

Setting up sensitive service domain groups (aka sensitive sites)

To configure specific sensitive sites in these settings, you will need to adhere to a specific syntax. The protocol (https:// for example) cannot be part of the URL. Instead, you will use this:

http://www.contoso.com/sub

fabrikam.com/

The / at the end of the URL will end that URL. If the / is not included, all sub-sites will be included as well. Instead of the URL match type, you can also use IP addresses and IP ranges. You can also use wildcards when using URLs (*.fabricam.com/).


Used in DLP policies

When the list of sites is finished, you can use this list in the DLP policies. And this will become somewhat complex. The sensitive sites can be used in two Endpoint DLP-specific actions.

But first, we will need to set up a condition for the rule. This is the simple part – as this condition can be easily selected. Let’s look at the action available.

Audit or restrict activities on devices

This is the part where you would configure app-specific actions. For example: blocking copy/paste from a sensitive document to an insecure location. Or preventing sending the document using Bluetooth.

It is also the location where you configure specific upload/paste actions based on web domains or unallowed browsers. This requires either Microsoft Edge or Google Chrome/Mozilla Firefox with the Microsoft Purview extension.

In this section, a new option is available. You can configure the specific sensitive sites to have a different setting. So, for instance, you might audit any upload or paste action to domains, and you might want to block these actions for specific sensitive sites. And this is possible.

To be sure: this only applied to the Upload/Paste actions. And this is not restricted to Microsoft Edge.

Audit or restricted activities when users access sensitive sites in Microsoft Edge browser on Windows devices

This option is specific to Microsoft Edge (and Windows) and websites. It allows you to control the activities Print | Copy | Save when accessed using Microsoft Edge.

The options are the same as for most other DLP actions: Audit, block, or block with override. In practice, this will look like this:

And this will be the interface when trying to drag/drop a sensitive file to an unallowed domain.

And from the Purview admin console, you will see it appear as well.


That’s it

So the sensitive sites allow for more differentiation for your endpoint DLP rules. I would expect that controlling what a sensitive site is, will be connected to sensitivity labels in the future. That would be a great addition.

If you haven’t looked at endpoint DLP, please do so. It is complex, but also very powerful. For more information:

https://learn.microsoft.com/en-us/purview/endpoint-dlp-learn-about#endpoint-activities-you-can-monitor-and-take-action-on

And one last tip. If (like me) the testing doesn’t quite work, you can check out if the (test)device has the policies assigned. In the Purview portal, go to Settings | Device onboarding. You should see your device here. When opening the details, it will show you all DLP policies! Nice!

Leave a comment