Microsoft Purview Data Loss Prevention – Part 1

Welcome to part 1 of my Microsoft Purview Data Loss Prevention (DLP) blog series. We will be reviewing what DLP is, why you should be using, what each DLP location has to offer, and some practical approaches to deploying DLP in an effective and controlled manner. While the focus of my articles will be on Microsoft’s DLP solution, this is something offered by other vendors as well and regardless of who you or your organization leverages, I strongly encourage having DLP controls in place.

DLP is a security solution offered by Microsoft that can identify sensitive information and then help prevent unsafe or unauthorized sharing, transfer, or use of that data. With Microsoft, depending on your license level, you will have the ability to extend DLP to your on-premises file share, cloud-based locations like SharePoint and OneDrive but also a 3rd-party cloud storage provider such as Box or G-Suite by extending DLP to Microsoft Defender for Cloud Apps (more on this in the coming articles), and your managed Endpoints.

While we be reviewing DLP in this post and throughout this blog series, it is very important to understand where DLP falls in the overall information protection and governance journey, which really has 4 phases to it:

1. Know your data
   1. You MUST understand what your data landscape looks like. What types of sensitive data is being stored in your organization? Where is it being stored? How is it being moved?
   2. You cannot apply effective controls without first knowing your data and this stage is overlooked far too often, leading to ineffective and/or too restrictive policies being enforced.
2. Protect your data
   1. Apply controls such as encryption, access restrictions, and markings. (Think Microsoft Purview Sensitivity Labels, which you can check out an overview here.)
3. Prevent data loss
   1. This is what we will be covering in this blog series. In this stage you will detect risky actions user may be taking with you data and apply controls that prevent authorized sharing or movement of your sensitive data.
4. Govern your data
   1. Apply retention controls that ensure your data is retained, deleted, and stored in a compliant manner

Taking the 4 phases into consideration, DLP is hopefully not the first step you taking in your data security journey. However, it is a critical step and, if approached and implemented correctly, can help prevent accidental and unauthorized sharing or moving of your sensitive data, without disrupting or restricting your legitimate business processes. I will be covering this when we talk policy creation, but you can leverage DLP in a manner that has zero user impact but can help you gather intelligence on how data is being moved or shared across multiple platforms, which can help you know and understand your data landscape.

Now, as mentioned before, there are many locations available with Microsoft Purview DLP and, as expected, some of them require a different minimum license. I usually like to cover this common topic early on, but for this series I will cover licensing for each location itself to avoid any potential confusion. Later in this post, we will be covering SharePoint and OneDrive policies but for now, let’s review some general guidance and things to consider before creating your first policy.

• DLP is not a singular individuals responsibility
  • Sure, you may have one or two people writing your policies, but there are things to do well before your write the first policy, which involve many individuals across the organization
  • Identify and meet with key stakeholders within your organization to gather a holistic understanding of multiple key points, which will drive your policy configurations. Some examples are:
    • Understanding the regulations and industry standards your organization is subject to
    • Different categories of sensitive data and how that data is handled (what processes involve sensitive data?)
      • Financial
      • Medical
      • Privacy
      • Custom (combination of the above)
    • Try to identify risky processes that can be secured or prevented
    • Prioritization of the different data types
• Map out your policies from start to finish before creating anything in the Purview portal
  • Your policy design should not happen for the first time as you’re creating your first policy
  • After meeting with your stakeholders, design your policies on paper (hello Visio) and then meet with them again to ensure the policies align with their valid business processes and the data they use
    • Are you assigning your policies to the proper locations that contain the data? Leveraging the right sensitive information types? Scoping the policies in a controlled manner by starting with pilot users/locations?
• Prepare end-user awareness training and documentation
  • DLP can and is going to introduce a level of disruption for your end-users, changing the ways, which is likely a good thing, in how they handle their data in the day-to-day roles
  • Training your users on the proper ways of handling sensitive data is a key component to a successful data security journey for any organization
• How should DLP alerts and policy matches be handled?
  • This will involve working with multiple teams, including your incident response team/individuals and legal to ensure the necessary steps are taken to not only mitigate the risk but also ensure the appropriate steps are taken to prevent it from recurring again.
• Priority matters
  • Maybe this should be the first bullet point on this list but this is critical to understand. Within each policy, you can have multiple different rules (total number actually depends on the size of the policy) and each rule is given a priority number. The first rule created has the highest priority (can be re-ordered). The highest, most restrictive rule is the one that gets applied when an item matches multiple rules within a policy. All rules matches will be logged and shown in the DLP reports, but the most restrictive, highest priority rule will be applied if multiple rules are matched.
  • You will also likely have multiple policies within your company and this priority matters as well. When an item matches multiple policies and the policies have the same actions, the highest priority policy will be enforced
• DLP locations have different conditions and actions
  • Each location has a unique set of conditions and actions that can be selected when building your rules. If you include multiple locations, like Exchange and SharePoint, you will ONLY be able to choose from the conditions and actions available within both locations. Any Exchange or SharePoint specific options will not be available. While it is possible you only need to pick options available within both locations, please note that you may need a separate policy if you need more granular controls for a specific location.
• Location exclusions, such as users or groups, happen at the policy level
  • Once you set a location and specify the target(s) for that location, you cannot specify further locations

Understanding a DLP Policy

There are multiple steps and decisions to be made when creating a DLP policy. These are the steps you go through, in order, after hitting “Create policy”:

• Template or custom policy?
  • Microsoft provides pre-loaded templates for the different categories of sensitive data. The list of templates is quite long so I recommend checking out the table from Microsoft Learn docs that list each template and will be updated as Microsoft adds or removes templates. You can find the table here.
  • If you select a template, please review each rule, in detail, so you have a clear understanding of what it is looking for and what actions will be enforced. These can be edited as needed.
  • If you wish to build a more custom policy, you may choose the “Custom” category and define each rule yourself.
• Name and Description
  • Please use a naming template of some form. As your DLP architecture progresses, you will have more and more policies and rules created. These CANNOT be modified after the policy is created.
• Assign admin units (preview)
  • This is a new capability from Microsoft. You can leverage your administrative units created within Azure AD and can be used to restrict a policy to only that set of users or groups. The choice you make on this step will affect the locations available to you (I’ll explain this next).
  • If you do not use an admin unit, your policy will be assigned to the full directory by default, but you may apply a specific inclusion or exclusion to each location
• Locations to apply the policy (the sub-bullets are the inclusion/exclusion scope for each location and what data state the protections get applied in)
  • Exchange
    • Distribution group
  • SharePoint Sites
    • Site URLS
  • OneDrive accounts
    • Account or distribution group
  • Teams chat and channel messages
    • Account or distribution group
  • Devices
    • User or group
  • Microsoft Defender for Cloud Apps
    • Cloud app instance
  • On-premises repositories
    • Repository
  • Power BI
    • Workspaces
• Define policy settings
  • Your options here depend on your choice on the templates page
  • If you picked a template, will have a chance to review the pre-built rules
  • If you choose to do a custom template, you will be prompted to create or customize advanced DLP rules
• Customizing an advanced DLP rule
  • Name and description
  • Conditions
    • This is where you specify what data conditions you are looking for. As mentioned, each location has specific options here but some examples include:
      • Content contains (Sensitive info type, sensitivity label, trainable classifiers, etc)
        • The options here vary by location as well
      • Content is shared
        • In or out of the organization
      • File type
      • Various message properties for Exchange like sender/recipient or header details
    • Conditions can be built using AND/OR statements for more granular filtering options
      • Not all locations support this so you may still see a specific “Exclusion” drop-down after conditions
  • Actions
    • When conditions are met, you may enforce specific actions to be automatically applied. These are again location specific, or at least most locations have location specific options, but some options are available from all locations.
      • Restrict or block access
      • Encrypt the email (Exchange only)
      • Block printing (Devices only)
      • Send to a manager for approval (Exchange Only)
    • In some locations, you can set the action to Audit but you can also allow the users to override a block if they have a valid business reason for the action or feel the detection was not accurate
  • User notifications
    • You may add a policy tip when a file is found to match a DLP policy or when a specific endpoint activity is restricted
      • You can also send an email notification the sender/modifier or specific people
    • These can be great in helping drive end-user awareness for proper ways to handle the sensitive data
  • User overrides
    • Allow the user to override a block. This will require them to enter a justification, which will be logged.
    • Endpoint DLP can be configured to show 5 preset values that a user can select as their justification
  • Incident reports
    • Specify the alerts severity from low, medium, or high
    • Send an email alert to admins when a rule match occurs
      • Be mindful of alert fatigue
    • Endpoint DLP can be configured to collect the original file as evidence and have it stored in a pre-configured location
  • Additional options
    • Stop processing more rules if this rule is matched
    • Specify the priority of the rule
      • 0 is highest priority
• Policy mode
  • Test it out first
    • Review alerts to assess the impact but no actions will be enforced
      • Can show policy tips when in test mode
  • Turn it on right away
    • Should be fully replicated within 24 hours
  • Keep it off
    • Keep in mind, this will also turn off auditing for matches against this policy, which will limit your ability to gather intelligence on how this data is being controlled
• Finish
  • Your final chance to revisit any of the above steps before saving your policy
  • You can modify anything in the policy except for the name or rule names after you create the policy, or the template you originally selected

Creating a SharePoint/OneDrive DLP policy

Now that we have reviewed your options when creating a DLP policy, and hopefully you’ve met with key stakeholders and fully mapped out your policy configurations, lets create our first policy. I will be scoping this policy to SharePoint AND OneDrive. I know, I’ve stressed multiple times about each locations having it’s own options. That’s still true. However, one of the most common policy asks I get from clients is preventing the sharing of files containing sensitive data from OneDrive and SharePoint, which can be done with both locations selected on a single policy. Keep it simple.

Now, before diving into the creation, it is worth noting what the difference is between SharePoint and OneDrive. The only difference between the two locations is under the conditions. With OneDrive as the single location, you get the option to set “Content is shared” as a condition, which looks for any file that has been shared with anyone other than the owner, which could certainly come in handy, but that is not the condition I will be looking for in the example we are about to cover.

Prerequisites

Licensing

• Microsoft 365 E5/A5/G5/E3/A3/G3, Microsoft 365 Business Premium, SharePoint Online Plan 2, OneDrive for Business (Plan 2), Exchange Online Plan 2
• Office 365 E5/A5/G5/E3/A3/G3
• Microsoft 365 E5/A5/G5/F5 Compliance and F5 Security & Compliance
• Microsoft 365 E5/A5/F5/G5 Information Protection and Governance

By default, Exchange Online, SharePoint, and OneDrive are enabled workloads for DLP.

Understanding your Policy Goals

Your organization has identified that they routinely have files stored within numerous SharePoint sites and OneDrive accounts that contain the below sensitive information types:

Credit Card Number

U.S. Social Security Number

U.S. / U.K. Passport Number

U.S. Individual Taxpayer Identification Number (ITIN)

Per company policy, any file with 1 – 10 counts of any of the above data types in a file, sharing outside the organization should be blocked, with the ability to be overridden if the user has a valid business reason. Any file with 11 or more counts of the above data types should be blocked and cannot be overridden.

Creating the Policy

Before you begin, please feel free to follow along as I recorded each step in the process and it can be viewed at the below Scribe link.

https://scribehow.com/page/DLP_Blog_Series__aIDE5vffRRa1wxsNAehtGQ

• Login to compliance.microsoft.com
• From the navigation menu on the left, select Data loss prevention > Policies > Create policy
• On the templates page, choose Custom as the category and you must then select “Custom” as the template
• Provide your desired name and description for the policy
• I will not be using an admin unit for this policy as I could then not select SharePoint as a location
• By choosing a custom template, you will be forced to create or customize an advanced DLP rule
• You’ll create a new rule and provide a name. You CANNOT reuse a rule name in your tenant at all so please be specific and use some sort of naming policy
• Creating the rule:
  • Before you select your conditions, with SharePoint and OneDrive policies, if the action is set to block people from outside the organization from accessing the content, you must choose “content is shared from Microsoft 365” as a condition, so I just make it a general rule to select it first in this scenario
  • Drop down “Add condition” > Select “Content is shared from Microsoft 365” > drop-down “only with people inside my organization” and change it to “with people outside my organization”
  • Add another condition by hitting “Add condition” > choose “content contains” > press “add” > choose “Sensitive info types” > Find and select each of the sensitive info types we listed before – if you select the check-box, you can pick multiple at a time. If you click the name, it will reset your selections
    • After you add the sensitive info types, you will be able to specify the amount you’re looking for in a file as well as the confidence level
    • The confidence level will dictate how sure the system needs to be to “detect” the data type in a file. The lower the confidence, the more false-positives you will have. The higher, more false-negatives. Because we are using out-of-the-box SITs from Microsoft, I recommend leaving the confidence levels at their default amounts.
      • If you create a sensitive info type yourself, whatever confidence level you set during the creation of the SIT, you should not tell the policy, wherever you’re making it, to be more confident than you configured the SIT to be or you will have inconsistent results
    • Remember to set the counts to appropriate amount for each rule or you will have unintended consequences
    • You will see a group operator above the list of SITs, for this policy, make sure it is set to “Any of these”. If it is set to “All” the file must contain all of the listed SITs.
  • Now you can configure your actions, select the add an action drop-down and select “restrict access or encrypt the content in Microsoft 365 locations > make sure “Block only people outside your organization” is selected
  • Configure user notifications or else you cannot configure the option to allow overrides
    • I recommend applying a policy tip to help drive user awareness and provide proper usage recommendations
  • Enable overrides and I recommend enforcing the user to provide a valid justification
    • You can set it to automatically override the policy if they mark it as a false positive but this can introduce the ability for users to easily bypass the policy
  • Specify the alert levels as desired. I recommend having the rule that detects a lower number be set to a lower alert level than one set to detect higher levels
• Repeat these steps for the rule that detects 11 or more counts. Please be sure to change the counts to avoid any issues.
  • When creating this rule, per the policy requirements, you will NOT be allowing user overrides but I still recommend enabling the policy tip
• For the sake of testing and in my one person environment, I will be enabling the policy right away. If you did not scope the policy to a small set of pilot users and sites, I recommend setting the policy to test mode.
• Save the policy and give it up-to 24 hours to fully replicate. You should see it working after an hour but it can be delayed for up-to 24 hours

Testing the Policy

Now that you have configured the policy, you will want to test it out. DO NOT test with actual data. You can download plenty of DLP test data from dlptest.com to plug into files for testing purposes

Instead of loading numerous pictures to this, please feel free to review my testing at the below link from Scribe (same one from before), which recorded each action I took, and review the one about testing. Upon testing, I confirmed the policy is taking effect on files containing the matched data types.

https://scribehow.com/page/DLP_Blog_Series__aIDE5vffRRa1wxsNAehtGQ

As you can see, DLP can be a great tool for preventing unauthorized sharing or movement of your sensitive information and I hope part 1 of this blog series helped you better understand DLP as a whole, as well SharePoint and OneDrive DLP capabilities. Below is a quick infographic explaining your options with both selected.

Make sure to keep following along for more information! Up next, we will be taking an in-depth look of Exchange Online DLP, with many more parts and more information to come throughout this series!