Microsoft Purview Endpoint DLP for MacOS

Get onboarded

The first step is to get the macOS device enrolled in Intune for easy management. To do so, follow this guide:

https://learn.microsoft.com/en-us/mem/intune/user-help/enroll-your-device-in-intune-macos-cp

The guide is a little out of date, but the principals work all the same. Now to get the device onboarded into Microsoft Purview.

https://learn.microsoft.com/en-us/microsoft-365/compliance/device-onboarding-offboarding-macos-intune?view=o365-worldwide

As you will have seen in the article above, onboarding uses the same mechanism for onboarding macOS to MDE. Once the configuration profiles are installed as seen in Intune > Devices > macOS > macOS devices > click the device name > Device configuration. They should have a nice green tick next to the word “Succeeded” under the “State” header. I had a bit of a brain spasm with the naming, I would use Microsoft’s naming suggestion as seen in their guide.

 

Create the DLP policy

To configure the DLP policy, in the Microsoft Purview portal (https://compliance.microsoft.com) > Data Loss Prevention > Policies > Create policy.

I selected the financial template from the list shown below, but any template can be chosen to suit your needs. You can make the list relevant to your country by clicking the “All countries or regions” drop-down and selecting your country.

If you have selected one of the templates from the main list, you will need to select the appropriate countries’ data on the next screen. I have chosen the "U.K. Financial Data" option.

Click “Next” and provide a meaningful name and description.

Click “Next”.

Deselect all the other locations apart from devices. You can combine locations, but I prefer a policy per location. The reason for this is that a single, all-encompassing policy can get unwieldy with too many locations and the associated configurations to wade through before getting to the settings you want to change. This is my personal preference though, feel free to do it your way.  

Click “Next”. I selected the “Create or customise advanced DLP rules” on the next screen so I get to see all the options and configure it exactly how I prefer.

Click “Next”. You will see a low-volume rule and a high-volume rule. These can be changed, removed, or more rules can be added. For example, you might remove the high volume rule and adjust the low volume rules if you wanted to use only one rule regardless of the volume of sensitive information found. I like the low-volume and high-volume approaches as it means you can have a different, more robust response to lots of sensitive data potentially leaving the business as opposed to low levels of sensitive data leaving the business.  

The next screen shows the sensitive information types, confidence levels, and instance count. The confidence levels are based on the amount of supporting information. For example, a credit card number is a simple 16-digit number. This can be formatted in different ways and can be confused with other 16-digit numbers. If you enabled the sensitive information type (SIT) for credit cards and the policy found a 16-digit number without supporting information it may classify the credit card number as a credit card number, but with low confidence. As per the policy shown below, no actions would be applied by this policy because it is looking for high confidence levels before applying the policy rules.

The question is, how does the system get high confidence that a credit card number is indeed a credit card number and not just some random 16-digit number? I mentioned the supporting information. On a credit card, these are fairly obvious. You could have a CVV number, an issue number, and an expiry date. These supporting elements can give the system a high level of confidence that it has found a credit card number.  

If you want to see a full list of supporting elements for credit cards, you can see that here: - https://learn.microsoft.com/en-us/microsoft-365/compliance/sit-defn-credit-card-number?view=o365-worldwide.

The instance count is exactly as described: how many instances of these kinds of information will trigger the policy rule?

If I scroll down a little, I can click on Add an action > Audit or restrict activities on devices.

This will bring up the following window where I am going to configure each activity relating to sensitive data to “block with override”. The other options are “Audit only” which will log the activity, but won’t block anything and the “Block” option.

Scrolling down I have made sure user notifications are enabled and that policy tips will be shown when a policy is violated.

For the demonstration, I have not customised the policy notifications, but it is highly recommended you do so in production as a custom experience can give the user more information. It also distinguishes your environment from a potentially harmful environment if the user gets duped into a malicious, copycat environment. I am happy with the other options so I will save them.

Finally, you have a few different options as seen in the image below. Because this is a demo environment and I am comfortable with the consequences of enabling this particular policy I am going to choose “Turn it on right away”. I would implore you to use “Test it out first” or even better, “Test it out first” with “Show policy tips while in test mode” after initial testing. When deploying to production users it is good to show the policy tips so they get used to the kind of messages they will receive without them being prevented from doing their important work.

No matter how much careful planning you do, some data may be shared in ways that were unforeseen. Using this careful approach means the activities can be monitored in the “Activity explorer”, the users start to think more about the type of data they are processing, and nobody is prevented from completing important tasks.

Click “Next”, check the policy is correct on the review page and click “Submit”. If configured as shown above, the policies should be applied to the devices very quickly and should kick in the next time items on the targetted devices are accessed or modified.

Testing

Now we can perform some testing. I have some DLP testing data in a Word file, namely credit card details (not real ones I hasten to add). I use this site and have not had any issues: - https://dlptest.com/sample-data/. I have used another site in the past and wondered why my policy wasn’t working for hours only to find out the data wasn’t good enough to trigger a policy. The air was blue that day!

Copying company data to a local application

I highlighted and copied the credit card details. When I tried to paste into “Notes”, this notice was displayed.

This is because when I setup the policy I chose the “Block with override”. Clicking “Allow” means the operation is allowed. 

The action is noted in the activity explorer. The image below shows an example of the DLP rule match entry. In this case it was an attempt to copy the sensitive data to a USB drive.

Scrolling down the Activity details page surprisingly enough gives you more details. The image below shows details such as sensitivity label, sensitive info type, the file “SHA” values, the rule that was triggered and more.

Printing 

Printing is a similar story. Trying to print produces the message below.

Summary

To summarise, we have seen how to get the Mac OS devices onboarded, we have seen how to check the configuration profiles have been applied, how to set up the Endpoint DLP policy, and how to check the policy using various restricted actions. Feel free to leave a comment, was there something that was particularly useful? Is there something you would like to see added? Is there another article you would like to see?