- Did you know
that with just one Data Loss Prevention policy
in Microsoft Purview,
you can prevent information oversharing
and protect your sensitive data
pretty much everywhere you create, view,
and access information?
From the emails you send and receive
to the files stored in your SharePoint libraries,
and even your OneDrive accounts,
to your favorite Microsoft 365 apps,
including Microsoft Teams chats with sensitive information,
the files you manage on device endpoints
for both Windows and even macOS,
as well as non-Microsoft cloud apps and services,
and file share servers running on-premises or in the cloud.
One policy protects your data
across all these locations and services.
And with that one policy,
you can even differentiate data restrictions in place.
For example, instead of blocking all printing,
you can choose to block personally-owned
or untrusted printers, but allow printing
to trusted company-owned, onsite printers.
Scoping your policy in this way
balances keeping your data safe and your users productive.
The cloud native protection is built into the apps,
services, and the devices you use every day,
which means you don't have to bolt on additional solutions,
deploy agents, or configure policies in multiple locations.
And of course, you aren't managing
and maintaining on-premise infrastructure.
So, let's unpack how you can set up
that one pervasive policy with differentiated restrictions
to protect data across your cloud
and locally connected endpoints as well as in Microsoft 365
and other services you may have in the cloud
and running on-premises starting with your endpoint devices.
By setting an Endpoint DLP policy,
not only are you protecting the information on the device,
but also the data in the apps that run on those devices,
as well as what those devices connect to, like printers,
USB storage, network connections, service domains, and more.
The key to all this, as I'll show you,
is how we use groups and DLP.
And by the way, these aren't the typical user,
device, or security groups you might have in place today.
They are the groups of local apps, your printers,
removable USB storage, your network file shares,
and can include your service domains, and more,
that you can define using Endpoint DLP settings.
More on that in a moment.
First, there are several prerequisites that are important
for configuring differentiated experiences for Endpoint DLP.
Enabling advanced classification scanning and protection
ensures files on your endpoint devices
are scanned and classified, leveraging exact data match,
named entities, trainable classifiers, and credentials.
In fact, visiting aka.ms/DLPadvancedclassification
goes into more detail about these methods.
Next, restricted apps and app groups is where you control
the level of access that specific local apps have
to sensitive content.
Here is where you can create groups of apps
or individual apps that you can configure
to have varying levels of access restrictions.
Then browser and domain restrictions to sensitive data
lets you restrict sensitive files from being shared
with unallowed browsers and uploaded to service domains.
These controls can work natively with Microsoft Edge
or with Google Chrome and Firefox
when using the Microsoft Purview extension.
And by the way, with the extension installed,
DLP will unblock Chrome or Firefox
even if they have been added to the unallowed list
as you see here.
Then for service domains, you can specify allowed domains
and define service domain groups,
which are often used for file sharing services.
Here you can see that this list can include first
and third party domains with wildcards
denoted by the asterisks.
Beyond your apps and domains,
you can also enable always audit file activity for devices.
This ensures file activities for all onboarded devices
in Microsoft Office, including PDF and CSV files
are monitored in the activity explorer
even if a device is not scoped for DLP policies.
Then printer groups allow you to differentiate restrictions
across trusted and untrusted printers,
and you can define properties like IP ranges
for printers and scope.
In this case, I'll add print to file
so I can allow that with these printers later
and save again to confirm.
Similarly with removable USB device groups,
these let you trust or allow authorized USB devices
for sensitive information storage
and block other non-verified USB devices.
This uses device attributes like product and vendor ID,
device instance paths, and other attributes
to automatically identify devices.
And one more thing I'll point out here
with network share groups, you can define file share paths
to later set different restrictions
for what's allowed per group.
One important tip here, these groups should be set up
using future proof attributes,
and as long as the attributes of the new devices match,
they'll automatically be recognized
and treated as members of your defined groups.
So those are the key prereqs.
Next, let's look at how all of this comes together
in our policy across all locations and services.
I'll show you this by digging into a policy
I've already started.
In the policies tab, I have six policies defined
with five active and one set to test with notifications.
I'll select then edit this US financial data policy.
Notice we've checked all locations
where we want to protect our data,
which is what you saw earlier.
Next, in the advanced DLP rules,
you'll see that you can define different behaviors
based on the volume of content
detected with sensitive information.
For example, elevating alerts when high volume is detected.
Let's drill into this one for low volume.
You'll see the conditions are flagged
based on credit card and bank account numbers.
When I edit the policy,
you'll see each can have different confidence levels
for the matching logic
for that specific sensitive information type,
including supporting elements like the presence
of expiry dates for credit cards.
And these instant counts are in this case
what we define as low volume 1 to 9.
Next, under actions, this is where we can leverage
the Endpoint DLP settings as part of the logic for our rule.
The main thing to understand is that the top level rule
is the default behavior, and in this case,
we are mostly configured to block by default.
Then if I edit the underlying restrictions,
you'll see the trusted domain group from before,
and it is set to audit only, which means it is allowed,
but we'll receive audit logs.
So defining this group overrides the default block
for the service domain members within the group,
which is how we provide the differentiated restrictions
I mentioned earlier.
Equally, reversing this logic can allow you
to default allow or audit activities
and instead block the groups defined within these actions.
Now let's take a look at our apps on devices.
Copy to clipboard is set to audit.
USB devices are set by default to block,
with the exception in our case of approved USB devices
defined by our group.
Network shares are also default blocked with the exception
of our defined groups for the Bellevue
and Seattle locations.
Printing is blocked, except for while in the office.
By the way, restrictions apply to all apps.
You can create differentiated behavior
and exceptions for defined app groups.
For example, here, internal apps are unrestricted,
unwanted apps are blocked, and Microsoft 365 apps
have a unique set of restrictions applied
for clipboard, USB, network shares, and printers
to block with override, so users can perform the action
by overriding.
You can also require business justification,
and we'll get to that in a moment.
So that covers the device endpoint portion of our policy.
Moving on to the other services
that were protected in our one policy.
Here's where you would similarly add actions
to restrict access or encrypt Microsoft 365 locations
for email, SharePoint, and OneDrive.
Protect web activities with the Edge browser,
as well as third party apps and on-prem file shares.
At this point, we've established the scope
of our protections.
From here, we can optionally customize the notifications
that users and admins will see when there is a policy match.
First, here's where you can configure the title and content
of the DLP notification on the endpoint that you saw before.
Next, for Microsoft 365 services,
you can easily customize the text shown in policy tips.
Optionally, these actions can trigger an email
to the end user, content owner,
or other specified recipient.
Here you can also customize the email, text,
and subject line.
Next, if you have configured the actions above
to use block with override, you can enable more options
for Microsoft 365 services to require business justification
or to report false positives.
Then for all other activities beyond Microsoft 365,
you can configure the business justification
requirement here.
Additionally, you have options to set up automatic alerts
when activity matches are detected
and these get logged and reported,
which I'll show in a moment.
You can also receive an auto-generated email
and even define thresholds to minimize notification fatigue.
Once you hit save,
next you can choose to test the policy out first,
and whether or not you want to notify end users
when the policy matches are found.
This lets you easily gauge the potential impact
of the policy prior to enforcing restrictions.
I'll keep that option, review my policy one last time,
and submit, and just like that, our one policy spanning
all of our protected locations is done.
That said, there's more you can do.
With your policy active, you can monitor it.
Data Loss Prevention in Microsoft Purview
gives you a centralized location
to see all DLP activities in one place,
along with insights and actions that you can quickly take
to protect sensitive information.
In the activity explorer, you'll find detailed insights
with a number of recent matches by activity type,
along with all of their details listed out below
to aid with any follow-up actions.
And remember the alerts we just set up?
They show up here in the alerts tab
along with their severity.
Then to prioritize your work, you can filter your alerts
to find the ones that need immediate attention.
And by the way, DLP alerts are not only available
in Microsoft Purview compliance portal.
Now they're also in the Microsoft 365 Defender portal.
You can drill into each one to find the details
and even a contextual summary of the sensitive information
that resulted in the initial DLP policy match.
And to surface DLP alerts in the context
of the security incidents trending in your organization,
you can import them into Microsoft Sentinel.
And if you're currently using Semantec DLP
and looking to try out Microsoft Purview DLP,
you can use our Migration Assistant tool,
which is a Windows app that works
with your existing DLP policies for supported workloads,
including Exchange and SharePoint online,
OneDrive for Business, Teams, and endpoint devices
in order to migrate your policies
from Symantec to Microsoft Purview DLP quickly.
So that was a quick overview of how you can use
the latest capabilities
in Microsoft Purview Data Loss Prevention
to protect your sensitive data wherever you need to.
To learn more, check out aka.ms/DLPDocs.
You can also catch our entire series on Microsoft Purview
at aka.ms/DataSecurityMechanics,
where you'll also see our show on Adaptive Protection,
which elevates existing Data Loss Prevention controls
for your content from being static to dynamic
by automatically adjusting the strength of protection
applied to your data,
based on the calculated data security risk levels
of your users.
Of course, don't forget to subscribe to Microsoft Mechanics
for the latest in tech updates,
and thank you so much for watching.