Monitoring Microsoft Information Protection with Microsoft Sentinel

Exploring Use Cases for Data Ingestion

Microsoft Information Protection (now called Microsoft Purview Information Protection and used interchangeably in this article) enables organizations to protect documents and emails by applying sensitivity labels to restrict user access to documents and emails. Compliance administrators can limit both the permissions (edit, print, etc.) and the scope of those permissions (to named users or groups of users).

In busy tenants, Microsoft Information Protection (MIP) can generate many audit events daily as users apply or downgrade labels, or as auto-label policies apply sensitivity labels to data at rest. A lot of information is available for an administrator to review and detect anomalies.

By combining Information Protection with Microsoft Sentinel, administrators can gain the following advantages:

• Visualize data using Microsoft Sentinel Workbooks,
• Receive notifications when certain events happen using analytic rules,
• Execute automatic response with Microsoft Sentinel Playbooks.

If you are unfamiliar with Microsoft Sentinel, read my introduction to Sentinel to get your bearings. This blog assumes some basic knowledge of the product and assumes that a Microsoft Sentinel environment already exists.

In this post, I explain the process to set up the data ingestion of Microsoft Information Protection events and explore the use cases for this data within Microsoft Sentinel.

Introducing the Ingestion Process from Microsoft Information Protection to Microsoft Sentinel

To push data into Microsoft Sentinel (called ‘data ingestion’) you need to set up a data connector. By creating a data connector, you configure a product to forward its data to Microsoft Sentinel.

Microsoft Purview Information Protection is somewhat special as it doesn’t have its own connector. Instead, it uses the ‘Microsoft 365 Defender’ connector. There are a few intermediate steps in this process, seen in Figure 1.

1. To audit events in your Microsoft 365 environment, the first step is to enable the Office 365 Audit Log as described here. Information Protection events are captured within the Unified Audit Logs.
2. Next, set up Office 365 as a connected app within Microsoft Defender for Cloud Apps. This enables the Office 365 audit data to be uploaded to Microsoft Defender for Cloud Apps.
3. Microsoft Defender for Cloud Apps is a part of the ‘Microsoft 365 Defender XDR’ system, so the Office 365 audit data is automatically synched to a table called ‘CloudAppEvents’ within Microsoft 365 Defender.
4. Finally, enable the Microsoft 365 Defender data connector within Microsoft Sentinel, to allow events to flow through to your workspace.

Check out the Top 10 Security Events to Monitor in Azure Active Directory and Office 365 in this eBook.

Walking Through the Prerequisites

Before we set up the ingestion, it is important to be aware of the prerequisites. Each step in the ingestion process requires different prerequisites:

• Microsoft Information Protection
  • Before you can use ‘Microsoft Purview Information Protection’, the correct license needs to be available in the tenant. For more information on licensing, check out this article.
• Office 365 Audit Log (see above).
• Microsoft Defender for Cloud Apps
  • Microsoft Defender for Cloud Apps (MDCA) comes in two flavors:
    • Cloud App Discovery, part of the Azure Active Directory P1 license. This is all you need.
    • The full MDCA product, part of the E5 Security and Compliance add-on.
• Microsoft 365 Defender
  • Microsoft 365 Defender is available when you purchase any of the underlying products (such as Defender for Cloud Apps). An overview of licenses including Microsoft 365 Defender is available here.
• Microsoft Sentinel
  • Microsoft Sentinel is built on top of Microsoft Azure, which means you need a valid Azure subscription before you can enable Sentinel.
  • It is important to note that Microsoft Sentinel is billed per MB ingested. The more data ingested, the higher the cost.

Creating the data connector

When all the prerequisites are met, it’s time to enable data ingestion into Microsoft Sentinel. To start, navigate to the Azure portal and select “Microsoft Sentinel.”

Within Microsoft Sentinel, select “Data Connectors” and search for “Microsoft 365 Defender” in the list. After selecting Defender, you can select “Open connector page” at the bottom right to open the configuration.

Now select the CloudAppEvents table underneath “Microsoft Defender for Cloud Apps” and save your changes. This action enables the ingestion of these event logs into Microsoft Sentinel. It might take a minute before this synchronization starts to ingest new events into your Microsoft Sentinel environment.

Before enabling the connector, be aware that there are potential cost implications in synchronization. The Microsoft 365 Defender connector can send a lot of data to Sentinel, which means the ingestion cost rises significantly. Microsoft Sentinel offers discounts for Microsoft E5 customers, but this discount doesn’t cover the entire cost. I recommend monitoring Azure costs closely in the days after enabling this connector, so that understand and manage the cost.

Exploring the Data

All events are stored in the “CloudAppEvents” table within Microsoft Sentinel. The CloudAppEvents stores both MIP events along with other Office 365 events. The table has an “ActionType” column which allows us to identify the action correlated to a given log.

To search for MIP events, look for an action type containing the word “sensitivity” or “MIPlabel” using a KQL query like:

CloudAppEvents 
| where ActionType contains "Sensitivity" or ActionType == "MipLabel"

This query retrieves every MIP event for the organization. To focus on specific type of events, filter against the “ActionType.” Table 1 lists some action types which you might find useful:

To filter on a specific action type, use a KQL query like this:

CloudAppEvents 
| where ActionType == "SensitivityLabelRemoved"

Once you find data for events of interest, you can explore the data manually or create analytic rules to automatically create incidents when certain events happen.

Check out the Top 10 Security Events to Monitor in Azure Active Directory and Office 365 in this eBook.

Use Cases for Analytic Rules

A Microsoft Sentinel analytic rule defines a query and certain conditions when an alert and/or incident should be created. By using this technique, you don’t need to query the data manually, Microsoft Sentinel will do this periodically for you.

Creating an analytic rule requires a few different steps. This configuration is outside of the scope of this blog. However, a complete tutorial is available in the Microsoft docs.

Deciding which analytic rules to create depends entirely on your use cases. I recommend following the less-is-more principle. If you create analytic rules which generate 200 incidents daily, they won’t have much value because you won’t have the bandwidth to manage them all.

Some of the more interesting use cases include:

• Mass removing or downgrading of a label in a specific timespan
• Super user actions
• Monitoring of critical files (such as these specific to a classified project or group of people)
• Connect MIP events to other sources, for example, a risky sign-in followed by removal of labels.

Microsoft currently offers a limited number of rule templates. Some samples are available in GitHub, which can be deployed by using the ARM template functionality in Microsoft Sentinel.

Visualizing Data in Workbooks

Besides creating incidents based on Microsoft Information Protection data, Microsoft Sentinel also supports creating workbooks to visualize the data set.

What to visualize depends on your business cases and what is important in your organization. I often use these kinds of reports to provide insights to management or C-level personnel about the data available in the environment. Some interesting visualizations are:

• Showing what label actions (removal/rename/addition) are happening
• Identify peaks in usage (specific to users or labels)

The Microsoft Purview Information Protection team shares a sample workbook on their GitHub repository.

Conclusion for Microsoft Information Protection Monitoring

The goal of this article was to provide an overview on how Microsoft Information Protection integrates with Microsoft Sentinel and what use cases exist for the data ingested into Sentinel.

Your organization might not have a use case for such an integration, which is fine. Don’t integrate Sentinel with MIP just because you can. Ingesting MIP data into Microsoft Sentinel comes with a cost, so a business justification should exist before proceeding.

If you enable this integration, you can create incidents based on MIP data and provide custom visualizations to add to the information already available from the Microsoft Purview Compliance portal.