Practical Protection: Five Things To Know About Microsoft 365 Auditing 

Back when I was in the Marine Corps, my boss was a salty old staff sergeant named Staff Sergeant Travis. If, at any point, one of his subordinates would admit to not knowing something, his usual sarcastic response was, “If you don’t know, you better ask somebody!” This wasn’t very funny at the time, but I appreciate it more now, and it actually turns out to be a pretty good mantra for recognizing when you need to know stuff. 

In a completely related vein, ex-NSA staffer and malware-hunting legend Jake Williams (@malwarejake on Twitter and Mastodon) had a very similar suggestion the other day: 

This is great advice for every Microsoft 365 administrator. Most of us don’t spend much time poking around in the unified audit log, but all of us probably should. I’m going to assume that you’re familiar with the concept of the unified audit log (here’s a quick refresher if you’re not), so instead of teaching you the basics, I want to talk about a few finer points of Microsoft 365 auditing that will be useful to you as you take Jake’s advice. 

You’ll Probably Have to Pay 

Microsoft has changed the way they manage auditing over time. One way they’ve changed is by adding more depth and texture to the audit data, including support for auditing actions (including file open and data changes) in Visio documents and Planner plans. Another way they’ve changed is by changing the underlying licenses required before you can see certain types of auditing data. For example, you’ll only see Planner audit data for users who have the Microsoft Purview audit (premium) license. In general, the sad truth is that the things you are most likely to want to audit all require this premium license. For example, the Send, MailItemsAccessed, and SearchQueryInitiated audit events for Exchange Online are only generated for users who have this license. The only way to ensure that you have complete audit coverage is to pay for E5 licenses for your users: a Microsoft 365 E5 license, an Office 365 E5 license, the Microsoft 365 E5 Compliance, or Microsoft 365 E5 eDiscovery and Audit add-on licenses.  

Auditing isn’t Real-time 

It’s tempting to think of audit data as being available in real-time, but that’s not how it works. In reality, audit data entries are mostly generated by individual servers that take action, and then they are collected and aggregated by a number of back-end services running inside Microsoft 365. Microsoft explicitly doesn’t guarantee any particular timeframe for audit data arrival. Instead, they say that “For core services (such as Exchange, SharePoint, OneDrive, and Teams), audit record availability is typically 60 to 90 minutes after an event occurs. For other services, audit record availability may be longer.” It’s better to think of the unified audit log as a way to reconstruct what did happen instead of a way to monitor what is now happening. 

Absence of Evidence is not Evidence of Absence 

There are multiple ways to search the audit log: you can use Purview, you can use the Exchange PowerShell cmdlet Search-UnifiedAuditLog, or you can use Microsoft Graph. However, if you run the same search using all of those methods, you may find that you see different results—it appears that there are still some bugs or limitations in the Graph endpoints used for searching the log (see this example from Office 365 MVP Glen Scales). Just because you run a search of the audit log using Graph and don’t find any results, you may not be able to assume that the activity you’re looking for didn’t occur.  

Audit Enablement isn’t Automated 

This one surprised me a bit when I first learned it: it isn’t sufficient to just add the correct license to a user to audit all actions on that account. You may also have to enable specific audit actions. In particular, you may need to enable the SearchQueryInitiated and SearchQueryInitiatedSharePoint events. In fact, if you want to audit the Planner/To Do actions I mentioned earlier, you have to enable those as well. In general, any time Microsoft releases new audit events you should plan on enabling them for the desired users yourself. The good news is that you can automate this enablement—Nathan McNulty has a great example showing how to use Azure Automation to do this, or you can do it using whatever other provisioning tools you find convenient in your environment.  

Audit Data has an Expiration Date 

By default, your audit data will only be retained for 90 days. You can extend this period by buying the aforementioned E5 licenses; when you do, you’ll get a default audit data retention policy that keeps audit log data for one year for Exchange Online, SharePoint, OneDrive, and Azure AD activities. You can also create retention policies that keep audit data for longer or shorter periods or apply different periods to specific data types. However, these policies only allow you to keep data for specific periods (7 days, 30 days, 6 months, 9 months, 1 year, 3 years, 5 years, or 7 years). You can buy a separate audit log retention license that will allow you to create a 10-year retention policy if you need to. Before changing these retention policies, though, you should ensure that you have a good understanding of how you will use the audit log data for incident response or other uses. There’s no point in keeping data that you won’t or can’t use, especially when you have to pay Microsoft more to do so. 

What’s in your Logs? 

Armed with this information, you’ll be in a better position to take Jake’s advice to poke around in your logs and see what’s what. Try a few searches with the Purview portal, then try a few with Search-UnifiedAuditLog and see which you prefer. Get comfortable with the process of searching and exporting audit log data now, so that if you ever need to do it in a hurry, you’ll be fluent. And if you don’t know how to do something audit-related… go ask somebody.