Earlier this month, Thijs Lecomte laid the case out for why Microsoft 365 tenants should use Microsoft Sentinel and compares its functionality against Microsoft Defender. Thijs then followed up with another article to explain how to use Sentinel as a single pane of glass for security data. It’s a good example of using Sentinel’s log aggregator capabilities.
I haven’t spent too much time with Sentinel in the past, but there’s nothing like a practical workout to discover how things work. In this article, I discuss how to use Sentinel to visualize information based on events ingested from the Office 365 audit log. If an Azure subscription is available (a pay as you go subscription works nicely), any Microsoft 365 tenant can follow my steps by exploiting the 31-day trial for Microsoft Sentinel.
Creating a Log Analytics Workspace for Office 365 Audit Data
To start, I went to the Microsoft Sentinel page in the Azure admin center to create a new log analytics workspace and add Sentinel to it. The workspace is associated with a subscription and can be part of an existing resource group or a new one. Add the name of the workspace and the Azure region it is managed in. Click Review and Create and after the validation test for the new workspace passes, click Create to complete the creation of the new workspace.
Wait for the deployment of the new workspace to finish. Select the workspace and click Add to add Microsoft Sentinel to the workspace. This will take a moment or so.
The next step is to configure a workbook within the workspace. Many different workbook templates are available to analyze data with Microsoft Sentinel, including a workbook created by Microsoft to analyze Office 365 data imported from the audit log (other workbook templates are available to build out the analysis of data associated with Office 365 operations). You can also create custom workbooks from scratch or customize a workbook created from a template. For now, we’ll concentrate on adding the Office 365 workbook to our workspace.
When the new workspace is available, select Workbooks under the Threat management section. Search for the Office 365 workbook (Figure 2). Select the workbook and Click Save to add the workbook to the workspace. Sentinel prompts you to select an Azure region. It’s best to use the same value as the workspace.
Next, we configure the workbook. Azure checks to make sure that the account connecting Office 365 data to the workbook holds either the tenant administrator or security administrator role. You can select which of the three available data types defined in the workbook that Azure Sentinel should import through the Office 365 connector (Exchange, SharePoint, and Teams). Select all three and click Apply Changes (Figure 3).
You can now open the saved workbook. Before doing so, give Microsoft Sentinel some time to begin fetching data from Office 365. The Office 365 workbook uses the Office 365 Connector to fetch audit log data from Office 365 and ingest it into Microsoft Sentinel. This process occurs in the background. You can see details of the connector in the workbook properties. In Figure 3, the connector shows up as “not connected” because the workbook has not been saved. Once the connector is active and begins to receive data, you’ll see information about its activities (Figure 4).
To see the visualization of the collected data, go back to Workbooks, select Office 365 from My Workbooks and then View saved workbook. Sentinel then displays the information it ingests from the Office 365 audit log (Figure 5). The charts and tables focus on user activity across the three data types. You can select different time periods from the last five minutes to ninety days. Other filters include the workloads and user types. For example, show Exchange Online events for administrator accounts.
Workbooks aren’t fixed objects. You can edit the queries for each of the charts and graphs displayed in the workbook and make whatever changes you like to meet the needs of your organization. Editing a workbook requires a certain familiarity with the Kusto Query Language used by Microsoft Sentinel to extract log data from a workspace. Many articles are available online to educate yourself on the intricacies of Kusto. I like the description given in the read me for Matt Zorich’s GitHub repository of Microsoft Sentinel Queries (ask questions to @reprise_99). In addition to Office 365, the repository includes sample queries for other workloads like Azure AD, DNS, and Microsoft Defender for Endpoint.
It’s important to understand what actions generate the underlying data and what it contains. In the case of the Office 365 audit log, data often reflects the heartbeat of user activity through a trail of individual audit events rather than singular discrete events. For example, the SharePoint Online version history for this article tells me that AutoSave created sixteen versions as I edited the document. SharePoint logs a separate audit event for each file modification, meaning that the 4.73K SharePoint events shown in Figure 5 represent fewer activities than you might imagine. By comparison, if you ingest Azure AD sign-in data into a workbook, a failed sign-in is a discrete event that stands on its own merits and might require investigation to discover why the sign-in failed.
The Office 365 data ingested by Microsoft Sentinel helps to understand the ebb and flow of user activity across three major workloads. However, because the data used is captured for audit purposes, it might not deliver the same insight as available through other methods, such as the Microsoft 365 User Analytics for Power BI app. This app uses data gathered from user activity in the Microsoft Graph rather than audit events and is more precise and informative about how people use Exchange Online, SharePoint Online, Teams, and OneDrive for Business. The User Analytics app has some of its own flaws, notably its focus on driving user adoption rather than in-depth analysis of what people do.
From an Office 365 perspective, Microsoft Sentinel scores by being able to:
- Hold log data for as long as you are willing to pay (instead of the 90 days for Office 365 E3 users and 365 days for Office 365 E5).
- Integrate Office 365 log data with information from other sources, such as Azure AD.
- Apply intelligence to the data stored in workspaces using analytics rules.
Like any other software, Microsoft Sentinel is a tool. If you take the time to master Sentinel, it can deliver impressive results. So can other tools, so it’s important to consider your needs before deciding what tool to use.
Visualization by Sentinel
The Office 365 audit log collects large quantities of data from different workloads. Although the audit data is enormously valuable when the time comes to investigate events like who sent a message from a shared mailbox, it’s not very approachable in terms of overall tenant activity. In this article, we cover how to use the standard Microsoft workbook to visualize Office 365 audit data. This is relatively basic stuff and once you have an Azure subscription, it shouldn’t take too long to get Office 365 data flowing into Microsoft Sentinel. After that, it’s up to you to decide how to customize workbooks, combine different forms of data to make them more useful, and visualize your way to happiness.
Can we use this office activity data for further machine learning use cases like abnormal behavior or anomaly detection may be azure ml or sentinel notebook? If yes can you guide me how?
I imagine that you can, but I have never done it. If I was to, I would start by investigating how to ingest data into whatever tool you want to use for analysis and then figure out how to extract the data from the unified audit log (probably with PowerShell) for ingestion and processing.
If I have 2 tenants, can I ingest data from Tenant A into Sentinel of Tenant B? I cannot find such an option in the Data Connector. Is there a way to customize it?
I imagine that a Sentinel connector would be the right way: https://learn.microsoft.com/en-us/azure/sentinel/connect-data-sources
How? Only single-tenant connection is allowed. You cannot use data from other tenants:
2. Previously connected tenants
Microsoft Sentinel now enables Office 365 single-tenant connection. You can modify your previously connected tenants and click Save.
Looks like you need a separate workspace per tenant: https://learn.microsoft.com/en-us/azure/sentinel/extend-sentinel-across-workspaces-tenants
Thanks for the wonderful article; it really helps in explaining the topic in detail. I have a question related to SharePoint Online logs being sent to Sentinel. Can we define the SharePoint Online logs we wanted to send to Sentinel instead of sending all the logs?
Besides that, what is the KQL query we need to run to extract logs from Sentinel if the user has modified a file, deleted a file or created a file on Sharepoint Online?
Thanks and Regards
I don’t think you can customize the set of operations ingested from SharePoint into Sentinel. It seems like the connector takes what it can.
As to the KQL query, check out https://learn.microsoft.com/en-us/azure/sentinel/audit-sentinel-data to find out how to build KQL queries. And this article from Thijs, of course: https://practical365.com/use-kql-to-master-sentinel-data/
Another way to attack the problem is to use the events in the unified audit log to detect when people create, update, or delete a SharePoint file. Sentinel gets its data from the audit log, so I would go there in the first instance.
Here’s an example of using the audit log to track SharePoint file deletions: https://office365itpros.com/2021/12/16/sharepoint-online-deletion/