Microsoft Purview Insider Risk Management – Creating a Data Leak Policy

Although Microsoft Purview receives all kinds of signals from the various workloads within Microsoft 365, it doesn’t know what to do with the signals until you tell it what to do.  This is the case with Microsoft Purview Information Protection  (MPIP), Data Loss Prevention (DLP), and Insider Risk Management (IRM).  The policy in IRM tells the system what it needs to watch for in order to generate an alert, but a unique component of IRM is the scoring capability.  Once a trigger generates the alert, the alert uses the configuration of the policy that generated it to score each of the risky activities the user completed in an effort to paint a larger picture of their actions.  Was the trigger a one-off, or is it an indicator of a much larger problem?  In this post, I’ll cover the different types of templates IRM utilizes and finish off by creating a data leak policy for IRM.

As always, please be aware of my blog disclaimer

For more information in this series on Insider Risk Management, please see the other posts I have written on this topic (the links will be active as the pages become active):

• An Overview of Insider Risk Management
• Configuring Your Tenant for Insider Risk Management
• Creating a Data Leak Policy (this post)
• Reviewing Alerts In Insider Risk Management
• Escalating an Alert in Insider Risk Management

Insider Risk Templates

Similar to data loss prevention, Insider Risk Management is all about the template.  You can’t create a policy without basing it on one of Microsoft’s templates.  We’ll cover those first and then run through the steps to create a data protection policy.

Data Leaks & Data Leaks by Priority Users

The Data Leaks template focuses on information loss (usually by exfiltration) caused by users within the organization. It also focuses on information shared or accessed internally or exfiltrated outside of the organization. Key components of the template include DLP policies as guides for monitoring and flagging data, but they are not required to function.  An alternative to the Data Leaks template is the Data Leaks by Priority Users template.  Like the Data Leaks template, it focuses on data loss via a number of different possible triggers.  Where it differs is the ability to focus on a group of users. These users are expected to be considered priority based on the information they handle and/or whom they collaborate with regularly.  It is not intended to be based on any expected suspicion of their activities.  As the template is based upon DLP policies, sharing, and exfiltration activities, the template monitors these actions taken by employees.

Data Theft by Departing Users

This template tends to be very important to many organizations.  This is because its trigger is the resignation or termination of an employee.  Consider this: Frank in accounting just handed in his resignation.  Now that Frank is leaving, he starts downloading and keeping various documents (sensitive or not) from his organization’s data storage locations.  Whether Frank feels he is entitled to the information or not is beside the point.  The point is that he is taking the organization’s data.  Insider Risk Management can be notified when Frank submits his resignation to HR and can track his activities.  But what if Frank started exfiltrating data weeks before his notice because he knew he might be checked?  IRM has you covered in that it will review Frank’s activities for 90 days before the resignation is handed in.  This is the basis for the template Data Theft by Departing Users.  I’ll cover how HR can notify IRM of resignations and terminations in a future post.

Risky Browser Use

This policy is great for those who support remote work and don’t always have a VPN that forces the data traffic through the organization’s firewall.  You can track and block websites via your organization’s firewall if your users are at the office.  But what do you do for users working outside the office?  They could be remote workers at home or traveling for work or any option really.  The key factor is that they are not inside your firewall’s control and could be committing risky or just downright malicious acts.  This is where the Risky Browser Use template comes in handy.  It requires the user to use Microsoft Edge as the browser.  Chrome and Firefox are also supported but require an additional add-on for Microsoft Purview.  With these browsers, you can still track their activity even outside of the organization’s security perimeter.

Security Policy Violations and Security Policy Violations by Departing Users

The Security Policy Violations templates focus on signals from Microsoft Defender for Endpoint.  It focuses more on the activities outside of the cloud, including, but not limited to, improper use of sensitive information (printing, USB, etc).  It also watches for activities such as trying to circumvent the Microsoft Defender install

Patient Record Misuse

This template is very niche and focuses on organizations that store medical and patient records.  It is used to support the monitoring of risky actions around things such as health records and other Personally Identifiable Information (PII).  Similarily to the Data Theft by Departing Users template, this template requires a connector to Purview from the business’s electronic medical records system (EMR)

Creating a Data Leak Policy

The following steps can act as a guide for creating a Data Leak policy within IRM.  Please review the steps closely as I provide some additional commentary for the various configurations within the creation process:

1. Log in to Insider Risk Management (https://purview.microsoft.com/insiderriskmgmt)
2. Click on Policies and then + Create Policy

3. Select the template on which the policy is to be based.  Note: The template will indicate if your tenant is configured to support the template you wish to implement

4. Click Next
5. Provide a meaningful name for the policy.  The description is recommended but optional
6. Next select whether the policy will target specific users or the entire org.

Important Consideration: I recommend a smaller target group first to assist with fine-tuning the policy before opening it up to the entire org.  This could save the cybersecurity team from a lot of noise to churn through when the policy first goes active.

7. A new option is available but is in preview. This is to exclude users or groups from being picked up. This can come in handy when you have a group of users who, by the nature of their work, will create a number of alerts. I suggest you set up a separate policy for them with thresholds that match their work. In the meantime, you can add users or groups to the exclusion list or simply click next.
8. The next screen allows the administrator to focus the data leak policies on specific sites, sensitivity labels, etc.  I tend to recommend that you separate out the different priorities into their own policies. The separation provides better control for modifying the thresholds within the policy.  As this is a general data leak policy, I will select the option “I don’t want to prioritize content right now“

9. Next, select the event or events that can trigger the policy and begin reporting to the user.
   • Can select the trigger to be based on a DLP policy
   • Can select the trigger to be based on a number of specific activities

10. Next, the admin can select the thresholds for the triggering events.  In other words, how many times does the user need to download, rename, and exfiltrate a document before the alert triggers?
    • The options include using built-in thresholds or customizing each trigger you selected in the previous screen.
    • I recommend starting with the built-in thresholds and modifying them later as you refine the policies.

11. On the next screen, you get even more options. The indicator screen allows you to select the various risky indicators the policy should review and score. With the exception of Office indicators, the other groupings all require a connector to share signals with Purview. For example, to use Device indicators, Microsoft Defender needs to be configured to send signals to Purview.  IRM provides 79 different indicators to use when scoring the alert activities!  Select the ones that make sense for your policy.

12. Next, you are presented with a number of different options related to the indicators.  These options allow you to select the sequences you wish to watch for such as when a user downloads the document, removes or lowers the sensitivity, and exfiltrates the information.  I normally select all options unless there is a reason not to.  Click Next after you make your selection.
13. If you thought there were a lot of options on the indicator page.. just wait until you hit Next.  On the next screen, you get to set the thresholds for each and every indicator you are monitoring.  Each indicator has three thresholds: Low, Medium, High

14. For a new policy, I recommend selecting the center option “Apply thresholds specific to your users’ activity”.  This is an internally created threshold based on IRM’s baseline that it creates for your users when Analytics are enabled within IRM.  If you didn’t enable Analytics, start with the Microsoft thresholds and modify them later as necessary.

15. Review the settings on the summary screen, and once satisfied, click Submit.

Once the policy is created, give it time to start generating the alerts.  Review the alerts and modify the thresholds as required to weed out as many false alerts as possible while maintaining a good threshold for capturing valid alerts.

 

Thanks for reading!