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.
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.
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?
Comments
Post a Comment