Microsoft Purview Data Protection – Protecting Sensitive Data from Third-Party Apps

Recently, I released a post concerning protecting data against third-party cloud storage.  This post is similar but focuses on applications installed on the workstation.  A common use case is blocking sensitive data from being accessible for applications like Dropbox.  The argument could be said that the organization could just block the application from being installed, or they could have a corporate version of the application and monitor through Defender for Cloud Apps (a post for another day).  And they would be correct.  However, some organizations can have a real use case that allows for third-party apps to be used for day-to-day work, but you still want to control the flow of sensitive information to those tools.  We’ll cover this sort of situation in this post.

As always, please be aware of my blog disclaimer

You’re Going to Need Microsoft Defender for Endpoint

Similar to blocking service domains, you must have Microsoft Defender for Endpoint (MDE) deployed to the workstations for this to work.  If your organization already uses an Endpoint Detection and Response (EDR) tool like Crowdstrike or Trend Micro, that is ok.  MDE can provide the controls we are looking for in what is known as passive mode.  Passive mode is exactly as it sounds: the tool sits there and monitors and reports the information it needs to gather.  It just doesn’t act on it.  While this sounds great, as an endpoint support analyst, you need to be aware that MDE can get in the way of your EDR even in passive mode.  What happens is that both MDE and your EDR try to access the same file or monitor the same activity simultaneously and lock each other out.  This is known as a race condition.  This is happening less as the various tools are being updated to allow for multiple instances of an EDR tool running, but it does happen.

The rest of this post will assume that MDE is deployed in at least a passive mode.  An important note to make here is the parts of Purview and MDE that we are going to be using here will work even with MDE in passive mode.  The tool to be configured is known as Endpoint Data Loss Prevention or eDLP.  This is just a part of MDE, and because it does not do the same thing as a standard Crowdstrike or Trend Micro install, it is able to function in a more active mode.  However, you will likely run into some problems if you have another eDLP tool active on your workstations.

Identifying the Executables to Monitor

Before creating any policies to monitor or block the accessing of content by an application, we need to identify the executables that will be accessing the data.  To do this, you must review the various third-party applications you will monitor (or block).  For this post, I will monitor Dropbox.  Once the executables have been identified, use the steps in a related post: “Microsoft Purview Data Protection – Configure the Restricted App Groups” to monitor the following executable: dropbox.exe

Protecting Sensitive Data from Third-Party Apps

Once the Restricted App Group has been created, it is time to create the DLP policy that will use the App Group as a control for the policy.  In this example, we will block any confidential or restricted content from being accessed by the Dropbox application installed on our workstation.

1. Login to Microsoft Purview (https://purview.microsoft.com).
2. Click on Data Loss Prevention –> Policies –> + Create policy.
3. Create a custom policy and click next.
4. Provide the policy with a meaningful name and a description (optional)

5. Click next twice (leave admin units at default setting).
6. Ensure the only location selected is Devices

7. Click Next and then Next again at the Define policy settings screen.
8. Click + Create rule
9. Provide the rule a meaningful name.
10. Create a “Content Contains” activity under Conditions.
    1. Click Add and Select Sensitivity Labels
    2. Select Confidential and Restricted Labels
11. Under Actions, click + Add an action and select “Actions Audit or restrict on devices“.

12. As this policy focuses on the executables, leave the browser and domain options unchecked.  Also, leave File activities for all apps set to “Don’t restrict file activity” (I usually separate out these workloads to separate policies).
13. Under “File activities for apps in restricted app groups (preview),” add the restricted group you previously created by clicking on + Add restricted app group and adding the group.
14. You will be prompted to perform additional checks like copying to USB or clipboard, but I like to have a certain level of separation between policies so I select Don’t restrict activity in the next section of the policy.
15. Set the group’s control as necessary (for the purpose of this post, set it to block with override).  The options available are:
    • Audit Only: Only alerts will be generated.
    • Block with override: Initial action will be blocked, but users can override the block
    • Block: Block without providing an option to override

16. Configure the remainder of the notification settings as you see fit for your organization

17. Click Save
18. Back on the Rule overview page you can click on the down arrow beside your rule to review a summary of the rule’s configurations

19. Click Next
20. Choose to run the policy in simulation mode, turn it on, or leave it off.
21. Review the configurations of the policy and click Submit.

Policy Results

In the following example, I will attempt to upload a confidential document to Dropbox.  You’ll notice that when I upload an internal document, it works without any issues.  However, when I upload a Confidential or Restricted, I am prompted to provide a justification.  The process is similar to when one attempts to lower the sensitivity of a document.

(Click to enlarge)

Thanks for reading!