Data Loss Prevention across endpoints, apps, & services | Microsoft Purview

[Guest Zachary Cavanell]

Protect sensitive data everywhere you create, view, and access information with one Data Loss Prevention policy in Microsoft Purview. From email, SharePoint and OneDrive accounts, to Microsoft 365 apps including Microsoft Teams, files managed on device endpoints for both Windows and macOS, as well as non-Microsoft cloud apps and services, and file share servers running on-premises or in the cloud. One policy protects data across all these locations and services.

 

 

 

 

 

 

Cloud-native protection is built into apps, services, and devices, eliminating the need to add solutions, deploy agents, or configure policies in multiple locations.

 

 

 

Shilpa Bothra, Product Marketing Manager for Microsoft Purview DLP, shares how to keep data safe and users productive with differentiated data restrictions in place.

 

 

Single Policy Protection.

 

 

 

Use ONE policy to protect data and prevent overshared information.

 

 

Customize a policy to protect data in all locations.

 

 

 

Monitor, filter alerts, and take action.

 

 

Migrate policies from Symantec to Microsoft Purview DLP easily.

 

 

 

 

 

Watch our video.

 

 

 

 

 

QUICK LINKS:

 

 

— Introduction

 

— Prereqs to configure Endpoint DLP

 

— Policy demo

 

— Customization and business justification

 

— Monitor your policy

 

— Migrate Symantec DLP to Purview DLP

 

— Wrap up

 

 

Link References:

 

 

Watch our Microsoft Purview series at https://aka.ms/DataSecurityMechanics

 

 

 

Information on Data Loss Prevention at Learn about data loss prevention - Microsoft Purview (compliance)

 

 

 

Details about advanced classification methods at Learn about sensitive information types - Microsoft Purview (compliance)

 

 

Unfamiliar with Microsoft Mechanics?

 

 

As Microsoft’s official video series for IT, you can watch and share valuable content and demos of current and upcoming tech from the people who build it at Microsoft.

 

• Subscribe to our YouTube: https://www.youtube.com/c/MicrosoftMechanicsSeries
  
• Talk with other IT Pros, join us on the Microsoft Tech Community: Microsoft Mechanics Blog
  
• Watch or listen from anywhere, subscribe to our podcast: Microsoft Mechanics Podcast
  

 

Keep getting this insider knowledge, join us on social:

 

• Follow us on Twitter:
  
  
• Share knowledge on LinkedIn: https://www.linkedin.com/company/microsoft-mechanics/
  
• Enjoy us on Instagram: https://www.instagram.com/msftmechanics/
  
• Loosen up with us on TikTok: Microsoft Mechanics (@msftmechanics) | TikTok
  

Video Transcript:

 

 

-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 Symantec 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.

 

Continue reading...