In a previous post, I provided an overview of creating policies within Insider Risk Management (IRM). Once those policies are created, the activities of the users within the organization will begin to generate alerts. The alerts can be caused by accidental or benign activities, or they can be truly malicious in nature. It will be up to the analysts and investigators to determine the intent if they choose, but whether the intent is malicious or not, the user may simply need to be educated on the proper management of the organization’s data. This post will illustrate the process for reviewing alerts in Insider Risk Management and review the information a report will provide.
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
- Reviewing Alerts In Insider Risk Management (this post)
- Escalating an Alert in Insider Risk Management
Reviewing Alerts In Insider Risk Management
When an alert is generated in IRM, the system provides administrators and analysts with activities that lead to the alert being generated and can provide up to six (6) months’ worth of risky indicators as configured within the monitored workloads. Additionally, it will provide a risk score based on the thresholds defined by the policy itself. This allows analysts to quickly review alerts to determine if additional investigation is required and to “paint” an overall picture of the activities of the user in question. Let’s break down the components of an alert.
The Alert View
As activities are tracked within the organization, they will generate alerts for Insider Risk Management. To view the alerts:
- Navigate to Insider Risk Management (https://purview.microsoft.com/insiderriskmgmt)
- Click on Alerts
This view presents new and existing alerts. In most cases, when an alert is generated, it is added to the Alert dashboard with the status of “Needs Review.” It also provides information about who the actor is (if not obfuscated), which policy is acting on the alert when it was detected, and more. Like many dashboards in Puview, the view can be updated with other columns to meet the needs of the investigator(s).
As stated above, new alerts have the default status of “Needs review.” However, if an alert for that user already exists with a case, the status will automatically be updated to “Confirmed” and assigned to the case. This is illustrated in the following screenshot. A user in my tenant, Jason Bourne, triggered an alert about five months ago. That alert was confirmed as valid, and a case was created. When new policies were created, this user triggered alerts again. Because of the existing confirmed alert and existing case, the new alerts were automatically set to a confirmed status and added to the existing case.
The Overview (aka All Risk Factors view)
Selecting an alert brings up the details of the alert. The initial view breaks down what caused the alert and provides an overview of the different activities that further built up the creation of the alert and the scoring it received. Within the summaries, links are provided to dig into the details of each context. The following screenshots illustrate the components of this view:
Activity Explorer
This view is very similar to the activity explorer within Purview itself. It provides insight into the files accessed and the activities the user acted on of the files themselves.
The view is broken down into three main components.
- Activity Summary List:
- Along the left-hand side of the view.
- Provides a summary of the activities starting from the trigger to the latest recorded activity
- Each activity summary contains the events themselves that support it.
- Clicking on the event filters the file view to allow the analyst to review the files or emails that are part of the event.
Selecting a file within the event brings up a details blade that provides additional information pertaining to the file and location.
Looking for a Sequence Activity
Something that may be very important in an IRM alert is the discovery of a sequence of activity within the events. A sequence activity is when a user performs a number of questionable activities on the same file or files in sequence, usually indicating a risky behavior is occurring. Sequence activities are often a good indicator of malicious activities (though not all the time). A good example is downloading the files, renaming them (obfuscating), exfiltrating, and then performing a clean-up (removing them from the computer). As you can see in the next screenshots, the alert is reporting on a sequence activity, and the activity details actually show the various activities that made up the sequence activity in detail.
User Activity View
The user activity view provides a more visual view of the user’s activities by displaying their risky and non-risky activities on a scatter graph. The intent of this view is to provide the analyst with a more visual view of the types of activities the user is acting upon. Note: the following screenshots will likely show a much higher risk chart than a regular user will display because my threshold settings are quite low for testing.
Clicking on a plot within the scatter graph will provide a view similar to the activity summary. Clicking on an event within the plot details will redirect you to the Activity Explorer view to gather details on the files involved.
That’s the summary of an Insider Risk Management alert. In the next post I’ll cover adding an alert to a case and the next steps in the investigation.
Thanks for reading!
Leave a Reply