14. Insider Risk Management

_______________________________

In This Chapter

Introduction

Prerequisites

Policy Creation

Creating a Policy Via PowerShell Only

Set-InsiderRiskPolicy

Removing Policies

Policy Templates

Further Use Case Scenarios for Insider Risk

_______________________________

Introduction

What is Insider Risk and why should this prove to be a concern for your tenant in Office 365? Think of Insider Risk as another Office 365 process to help protect you and your organization from possibly disgruntled or malicious employees / users with access to sensitive data. Setting up Insider Risk Policies will help focus Microsoft’s logic to look for certain types of behavior in your environment. This behavior includes data leaks, confidentiality issues, Intellectual Property loss, fraud and more.

Insider Risk Policies can be focused on SharePoint sites and files, Exchange mailboxes and Teams sites. They can also leverage other outside triggers like DLP Sensitive Information Types, DLP Policies and Sensitivity Labels. Setting up a policy is the first step in a range of actions that can be taken if a risk is detected. Alerts are generated, other resources are coordinate, incidents are investigated and then an action is taken on the alerted issue.

From the Compliance Center interface (https://compliance.microsoft.com), we can see that Insider Risk Management feature is found under the ‘Solutions and Catalog’ along with Communication Compliance:

Prerequisites

In order to utilize the Insider Risk Management feature in the Compliance console or with PowerShell in the Security and Compliance Center, we need to meet certain prerequisites. Both the prerequisites need to be met before Insider Risk Management is operational. Below are the two requirements that need to be met:

Licensing Required for Insider Risk Policies:

• Microsoft 365 E5 subscription (paid or trial version)
• Microsoft 365 E3 subscription + the Microsoft 365 E5 Compliance add-on
• Microsoft 365 E3 subscription + the Microsoft 365 E5 Insider Risk Management add-on
• Microsoft 365 A5 subscription (paid or trial version)
• Microsoft 365 A3 subscription + the Microsoft 365 A5 Compliance add-on
• Microsoft 365 A3 subscription + the Microsoft 365 A5 Insider Risk Management add-on

Permissions Required to work with Insider Risk Policies:

• Insider Risk Management
• Insider Risk Management Admin
• Insider Risk Management Analysts
• Insider Risk Management Investigators

  https://docs.microsoft.com/en-us/microsoft-365/compliance/insider-risk-management-configure?view=o365-worldwide

Policy Creation

Creating a new Insider Risk policy affords us quite a few options in PowerShell, but very few PowerShell cmdlets:

Get-InsiderRiskPolicy

New-InsiderRiskPolicy

Remove-InsiderRiskPolicy

Set-InsiderRiskPolicy

At the time that this chapter was added to this book, no help or examples were provided. Online help is unavailable as well. The online documentation for the general concept and GUI representation in the Compliance console is decent and detailed, but not coverage of back-end PowerShell at all. So we will explore the console to help us drive information for various parameters of the Insider Risk Policy cmdlets.

When the appropriate prerequisites are met, we can start working with the Insider Risk Management option. First, we can open up the Compliance console at https://compliance.microsoft.com. Then we can click on the Insider Risk Management tab on the left, after you click on Show All Options:

First time Insider Risk Management is accessed, we get a welcome message and some information blobs:

The Insider Risk Management interface looks like this:

First, if we click on ‘Insider Risk Settings’, we find our global settings that include these items:

Privacy - Allows you to anonymize user names in the data to help protect users.

Indicators - Actions that trigger alerts for Insider Risk Policies.

Policy Timeframes - A window of time to review user activity once an alert is triggered.

Intelligent Detections - Set of criteria to further analyze actions, such as anomalies, language and alert volume.

For reference, here are the global settings for Privacy and Indicators:

And the Policy Timeframes and Intelligent Decisions global settings follow:

Creating a policy via the Compliance console also helps visualize what settings work for PowerShell as well. First we give the new template a name, a brief description and choose a base template. Then we select which users the policy applies to as well:

After this we have the options to optionally specify which content to prioritize on. Perhaps if we have more sensitive information to protect, or if there is a specific use case, then this page becomes useful. There are options for SharePoint Sites, Sensitive Information Types and/or Sensitivity Labels (left) and Indicators are known as Alert Indicators in the rule wizard, but all options are unavailable and grayed out (right):

Lastly,we see Policy Timeframes are also grayed out, as they are also set globally:

Creating a Policy Via PowerShell Only

Taking all of the knowledge and examples above, let’s see if we can create a reasonable PowerShell one-liner to create a new Insider Risk and then use PowerShell to manipulate the same policy. For this sample scenario we will set up an Insider Risk Policy that will handle Data Leaks and specifically these DLP Sensitive Data types:

‘U.S. Bank Account Number’

‘U.S. Driver’s License Number’

‘U.S. Individual Taxpayer Identification Number (ITIN)’

‘U.S. Social Security Number (SSN)’

‘U.S. / U.K. Passport Number’

We’ll also set a custom InScopeTimeFrame (30 days) and HistoricTimeFrame (90 days). As this will be a company-wide policy, the policy will be applied to all mailboxes. We also need an appropriate description for the policy as well. For reiteration, we have no examples to work from in PowerShell:

So how do we go about building a Policy in PowerShell without examples? We can check out the Parameters for a cmdlet to see what we have available and match them to settings in the policy:

** Remember that we can list all of the parameters by using Ctrl+Space after we type in a dash (‘-’).

From our previous requirements, we should use the following parameters - Name, Description, ExchangeLocation, and DLPSensitiveTypes. One other parameter is required and this is the ‘InsiderRiskScenario’ and this value is driven by the Policy Templates that are included in Insider Risk Management. When we initially looked at the policy created from the Console, we saw that there were three available: ‘Departing Employee Data Theft’, ‘Data Leaks’ and ‘Offensive Language in Email.’ These same scenarios correspond to these values in PowerShell:

Scenario Explanation

IntellectualPropertyTheft - Looks for data theft from employees near their resignation date. Leverages data from HR about employee dates of employment.

LeakOfInformation - Alerts based on DLP matches - Policy or Sensitive Information types.

Offensive Language in Email - Uses Microsoft’s machine logic to analyze emails for offensive content.

Now that we have our base criteria and the appropriate parameters for the cmdlet, let’s dig into how we get the values we need to put with our parameters. For this example, we will use the ‘LeakOfInformation’ value for the ‘InsiderRiskScenario’ parameter.

Name

The name of the Policy should be something that represents what the Policy is for and it can contain alphanumeric characters and spaces. For example we could name our example Policy:

‘Insider Risk - PII - Corp Wide’

Description

Our Policy description should expand upon the name of the Policy and explain our policies purpose. We can even include dates for when the policy was created, modified or who created the Policy.

‘This policy is designed to alert on PII information that could be leaked by bad actors. The policy is company wide and will report on any user in the firm. Created on 6/1/20 by Damian Scoles.’

Exchange Locations

We know that we can set the Insider Risk Policy to look at SharePoint Sites (Files and Folders). However, there are options for Exchange and Teams. Adding one user to the Policy will populate this user in the ‘ExchangeLocation’ of the Policy:

We can find a name to use by looking at values of a user account and using the ‘Name’ property of the user. This will only work if the user has a mailbox.

For Exchange Locations, we can also select all mailboxes in Exchange Online by using the ‘All’ value.

DLP Sensitive Information Types

The usage of DLP Sensitive Information Types should be used in conjunction with the Data Leak Insider Risk Policy Template. When choosing a DLP Sensitive Information Type, we see that the available types are the same ones available in the Security and Compliance Center. This can be verified by checking the count (in the SCC PowerShell) versus the count that shows in the Policy choice:

If we check the Insider Risk Policy, we see this Sensitive Information Type was added:

We can get a list of all DLP Sensitive Information Types by running one cmdlet - Get-DLPSensitiveInformationType:

If we review a test policy created with some DLP Sensitive Information Types, we see that we need the name and Id value from the Sensitive Information Type.

Creating One-Liner

Building the one-liner, we can combine the information above, with the requirements and we now have this code to create the new Policy:

New-InsiderRiskPolicy -Name “Insider Risk - PII - Corp Wide” -InsiderRiskScenario LeakOfInformation -Comment “This policy is designed to alert on PII information that could be leaked by bad actors. The policy is company wide and will report on any user in the firm. Created on 6/1/20 by Damian Scoles.” -ExchangeLocation All -DLPSensitiveTypes “U.S. Bank Account Number” , “U.S. Driver’s License Number” , “U.S. Individual Taxpayer Identification Number (ITIN)” , “U.S. Social Security Number (SSN)” , “U.S. / U.K. Passport Number”

One would think that the above one-liner is syntactically correct and would create a new Insider Risk Policy, but PowerShell for a DLP Sensitive Information Type seems to fail:

The issue is that the DLP Sensitive Information Types need to be formatted differently and need some specific values wrapped with it as well:

In order to make this work, we need not only the name, but the GUID for the Sensitive Information Types:

Following the format from an existing policy, we can format each type like this:

“{‘Name’:’U.S. Driver’s License Number’,’Guid’:’dfeb356f-61cd-459e-bf0f-7c6d28b458c6’}”

“{‘Name’:’U.S. Bank Account Number’,’Guid’:’a2ce32a8-f935-4bb6-8e96-2a5157672e2c’}”

“{‘Name’:’U.S. Social Security Number (SSN)’,’Guid’:’a44669fe-0d48-453d-a9b1-2cc83f2cba77’}”

“{‘Name’:’U.S. Individual Taxpayer Identification Number (ITIN)’,’Guid’:’e55e2a32-f92d-4985-a35d-a0b269eb687b’}”

“{‘Name’:’U.S. / U.K. Passport Number’,’Guid’:’178ec42a-18b4-47cc-85c7-d62c92fd67f8’}”

To populate the DLPSensitiveTypes parameter for the cmdlet correct, we have a couple of choices, but the best is pulling information dynamically with PowerShell. The code below is reusable with other DLP Sensitive Information Types. The key is to get all of the items grouped together as adding a value does not appear to work.

$Part1 = ‘{“Name’+’”:’

$Part3 = ‘,”’+’Guid”:’

$DLPTypes = Get-DlpSensitiveInformationType | Where {$_.Name -like ‘U.S.*’}

Foreach ($DLPType in $DLPTypes){

$Name = $DLPType.Name

$GUID = $DLPType.Id

$DLPName = ‘”’+$Name+’”’

$DLPGuid = ‘”’+$GUID+’”}’

$Value = $Part1+$DLPName+$Part3+$DLPGuid

$Values += $Value

}

$Values

Notice the third line, which is the most critical, where we query the DLP types needed. In our case, any Sensitive Information Types that start with ‘U.S.’ and the Name and Id values are stored in a variable called $Values. If we’ve done this correct, the $Values variable would look like this:

We don’t need to join the values with a command as it provides the wrong data format to the DLPSensitiveType parameter:

Combining all of the newly written Sensitive Information Types, we can rewrite the one-liner like so:

New-InsiderRiskPolicy -Name “Insider Risk - PII - Corp Wide” -InsiderRiskScenario LeakOfInformation -Comment “This policy is designed to alert on PII information that could be leaked by bad actors. The policy is company wide and will report on any user in the firm. Created on 6/1/20 by Damian Scoles.” -ExchangeLocation All -DLPSensitiveTypes $Values

Once we’ve run our one-liner, we need to verify our settings are present:

Get-InsiderRiskPolicy ‘Insider Risk - PII - Corp Wide’

Set-InsiderRiskPolicy

Once a Policy is created, the settings are not permanent and we are allowed to make changes. The cmdlet used to make these changes is Set-InsiderRiskPolicy. Let’s review some of the settings that we can change and how they interact with our global Insider Risk Policy settings.

Indicators

If we were to change the policy timespans to say 24 and 100, we would see these in a new Insider Risk Policy. Same goes with the Indicators if one of the Indicators were checked, it will also show in a new Insider Risk Policy. This is something to keep in mind for these settings. One more note on these changes, note that a new Insider Risk Policy will show up and your existing Insider Risk Policies will also be modified.

Now, these values can be reset to something other than the global settings, like so:

Set-InsiderRiskPolicy Test -InScopeTimeSpan 27 -HistoricTimeSpan 102

If the global settings are changed again, any settings changes that were made will be overwritten. Only the selected choice is actually set to True (orange rectangle) and this can be seen in the below screenshot. All unselected options are left at False (blue rectangle):

Teams Sites

However, as there is no example for the ‘TeamsSites’ and there is no option in the GUI it will be hard to find the appropriate format for what goes in that field. It is also possible that the field is not meant to be used. If we were to attempt to use the web link available for the Team, we get an error:

Another note on Policy creation, some policies may show that alerts will not show for up to 24 hours post policy creation:

Removing Policies

Once an Insider Risk Policy is no longer needed, we can remove it. Reviewing the parameters for the Remove-InsiderRiskPolicy cmdlet, we see we have very few parameters to choose from:

Using this one-liner we can list the Name and Identity for all existing Insider Risk Policies:

Get-InsiderRiskPolicy | Ft Name,Identity

For this example, we need to get rid of the Policy with the name of ‘test’. We have two ways to formulate PowerShell cmdlets for this:

Get-InsiderRiskPolicy ‘Test’ | Remove-InsiderRiskPolicy

or

Remove-InsiderRiskPolicy ‘Test’

As we can see, the cmdlets provide the same result:

Note that one Policy, whose name is in this format - IRM_Tenant_Setting_<GUID> - cannot be removed. Although if you try, no error will be returned, but the Policy is still in place. Secondly, you may need to use ‘-ForceDeletion’ in order to remove the Policy.

Policy Templates

Another item within Insider Risk Management that cannot be configured with PowerShell are the notification templates. If you wish to have a custom notification for alerting, review the Microsoft documentation present here:

https://docs.microsoft.com/microsoft-365/compliance/insider-risk-management-notices

Further Use Case Scenarios for Insider Risk

Importing HR data via an HR connector (Azure AD App) - https://docs.microsoft.com/en-us/microsoft-365/compliance/import-hr-data?view=o365-worldwide

** Evidence of this functionality is shown here: