As discussed in the overview of Insider Risk Management, the feature can monitor and alert admins of their users performing actions that can place the organization at risk. The information can come from many sources and focus on different areas of the organization’s data storage. This means it isn’t just SharePoint or Microsoft Exchange. In this post, I’ll cover some common steps that should be taken when configuring your tenant for insider risk management to ensure the policies you create later can gather all the information necessary to provide excellent coverage when monitoring your environment.
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 (this post)
- Creating a Data Leak Policy
- Reviewing Alerts In Insider Risk Management
- Escalating an Alert in Insider Risk Management
Configuring Your Tenant for Insider Risk Management
Plan for Access
Because Insider Risk Management (IRM) provides reviewers with access to content that could be considered private and sensitive, access to the content provided by IRM and even the configuration sections of IRM are not available by default, even to tenant admins. IRM has unique roles within it that control both administration and data access. In fact, I do recommend that organizations separate the capabilities within their organization if they are able, with specific admins having access to the configurations to affect change but no access to data and alerts and analysts that have access to the data and alerts but lack the ability to change the configurations of IRM. The following table provides an overview of each role, along with the function and capabilities. The organization should be aware ad determine the best deployment of roles within their tenant.
| Role Name | Role Functional Area | Role Capabilities |
|---|---|---|
| Insider Risk Management | Administration\Investigation | • Full Control to the IRM environment • Create, modify, and delete policies • Full access to alerts and events |
| Insider Risk Management Administrator | Administration | • Full Control to the IRM environment • Create, modify, and delete policies • No direct access to data returned by IRM Alerts |
| Insider Risk Management Analysts | Investigation | • Review of alerts and cases • No access to event details • No administrative access |
| Insider Risk Management Investigators | Investigation | • Review of alerts and cases • Able to access event details and content • No administrative access |
| Insider Risk Management Auditors | Other | • Review and export IRM audit logs • No ability to administrate or make configuration changes • No ability to view content or alerts returned by IRM |
| Insider Risk Management Approver | Other | • Approve the release of forensic evidence pertaining to an IRM case (will cover this in a future post) |
Building the Analytics
A big part of IRM is monitoring to see if you behave outside your normal activities. For example, did you suddenly start downloading several sensitive files when you very seldom work with that type of data? To do this, IRM builds analytics to create baselines for regular usage by users within the organization. Once those baselines are established, the system can compare your current activities with what it has tagged as usual. It also allows the system to provide suggestions on the thresholds to configure your policies (more on this in a future post). You can enable analytics within IRM by using the following process:
- Login to Microsoft Purview (this walkthrough uses the new Microsoft Purview interface)
- Click on Settings Cog at the top right-hand corner of the screen and select “Insider Risk Management”
- Select Analytics
- Enable the slider to On.
Privacy Considerations
There are a couple of reasons to consider privacy within IRM. The first reason stems from the data provided to analysts via the IRM console. When reviewing an alert, you are able to view who generated the alert, what they were doing, and the data they were accessing. This could potentially be a breach of your organization’s privacy policy depending on the analyst reviewing it, their clearance within the organization, and their access to the data.
The second reason to consider privacy isn’t as much a privacy consideration as it is a method to avoid preconceptional bias by the reviewer. Preconceptional bias means that the analyst can review the person the alert was generated for, and knowing that person could decide based on their knowledge of them either for or against the alert. Think: “Janine couldn’t be a risk to the organization. I know her really well. She’d never do anything to harm ACME Org.”. Then, the analyst disregards the alert due to this preconceived notion of Janine.
IRM provides analysts and admins with a way to obfuscate the user for whom the alert is generated. This helps to hide some of the private information unless further review is required. It also blocks an analyst’s preconceived decisions about the alert because they will have no idea who it is for. They will judge the alert by the merits of the activities reported. The following screenshot will illustrate what an analyst will see if IRM anonymization is enabled to obfuscate a user:
To enable IRM anonymization:
- Login to Microsoft Purview (this walkthrough uses the new Microsoft Purview interface)
- Click on Settings Cog at the top right-hand corner of the screen and select “Insider Risk Management”
- Click on Privacy and select Show pseudonymized versions of usernames
- Click Save
Integrate Microsoft Defender with Microsoft Purview
Insider Risk can review activities outside of Microsoft 365. Using Microsoft Defender, IRM can monitor activities on workstations, such as renaming sensitive files on the hard drive or copying files to a USB. However, it can’t do this if Defender is not sharing its logs with Purview. To get the signals from Microsoft Defender, the Defender console must be configured to send signals to Purview. Note: this may already have been enabled in your tenant from other configurations the administration has made. But it is a good practice to ensure the feature is enabled, and if not, turn it on. To do this perform the following steps:
- Login to the Microsoft Defender portal (https://security.microsoft.com)
- Under the System menu, select Settings.
- Click on Endpoints
- Select Advanced features and scroll down the options.
- Enable Share endpoint alerts with Microsoft Compliance Center
Once the alerts are enabled, give the environment up to 24 hours for the settings to propagate. Then enable the device indicators within Insider Risk Management:
- Login to Microsoft Purview (this walkthrough uses the new Microsoft Purview interface)
- Click on Settings Cog at the top right-hand corner of the screen and select “Insider Risk Management”
- Click on Policy indicators and then enable all items under Device indicators.
This should cover some of the key configurations necessary to support the initial configurations for IRM. The next post will help you create your first data leak policy in IRM
Thanks for reading!
Leave a Reply