Microsoft’s Glacial Progress to Improve Purview Audit

Purview Audit Standard Searches Still Malfunctioning

In early September, I discussed the effect of changes Microsoft made to the way that the Search-UnifiedAuditLog cmdlet. Essentially, if you run an audit search without using the SessionCommand parameter, Purview returns just 120 audit records even if many more matching records are available. No warning about potential data loss is included in the cmdlet documentation. It’s a scandalous situation caused by Microsoft without any communication to customers.

Eight weeks later, Microsoft hasn’t said anything to customers about how best to use the Search-UnifiedAuditLog cmdlet to search the audit log. At least, I haven’t seen anything. The net result is that customers could be running scripts to retrieve audit data that now fetch partial results. For instance, customers who extract audit data using PowerShell to later ingest that data into an SIEM for long-term storage and analysis might well have large holes in data retrieved from the audit log since August 2023. That’s an unacceptable situation and the silence from Microsoft is deafening.

The Costs of Meeting Customer Commitments

This brings me to another monumental screw-up involving the audit log. On July 19, following pressure from the U.S. Cybersecurity and Infrastructure Security Agency (CISA), Microsoft agreed to increase the retention period for audit events from 90 to 180 days for customers with Microsoft Purview Audit (Standard) licenses saying “Over the coming months, we will include access to wider cloud security logs for our worldwide customers at no additional cost.”

At a practical level, the decision meant that tenants with Office 365 E3 licenses would benefit from the expanded retention period. Increasing the retention period was a good decision, even if Microsoft was forced to concede something that should have been the basic level of service long ago. It’s long been common knowledge that many attacks start penetration and exploration several months before exploitation. Clearing audit data that could help to identify how attackers compromised a tenant after three months was never good practice. Microsoft should have upgraded customers to a 180-day minimum audit retention years ago.

As usual, it all comes down to money. Increasing the retention period for audit records costs Microsoft money. Audit records consume storage. Expanded searches over longer data ranges absorb additional CPU cycles because there’s more data involved. When you operate at the scale of Office 365 (still growing at 10% year over year according to Microsoft’s FY24 Q1 results), costs mount quickly. Only tenants with Office 365 and Microsoft 365 licenses that include Microsoft Purview Audit (Standard) generate extra data. Those with Audit (Premium) licenses retain audit events for 365 days while those without an audit license don’t generate any audit events (that’s another matter – without audit records, how can you know what happens inside a tenant?). Even so, extending Audit (Standard) audit event retention from 90 to 180 days might involve 100 million accounts, and that’s a lot of extra resources to pay for.

Given that the Microsoft Cloud is very profitable (73% gross margin on $31.8 billion revenue in the last quarter), delivering the extra resources probably wouldn’t budge the needle. After all, if Microsoft can afford to spend $10.7 billion in a single quarter (Q4 FY23) for additional resources to support artificial intelligence services like Microsoft 365 Copilot, I’m sure they can find the funding to make sure that customers have access to essential audit data.

But spending needs to be justified and spending on the delivery of extra resources to customers without additional revenue is never popular when management decisions are often dominated by spreadsheet analysis. Which might be the reason why it’s taking Microsoft so long to meet the commitments made on July 19.

Roll-Out for Extended Audit Event Retention Starts in October 2023

In an October 18 article, Microsoft CVP Rudra Mitra says that the extended retention period began to roll out in October 2023. Commercial customers are receiving the update first (covered by Microsoft 365 roadmap item 171160) with government tenants scheduled to receive the update in November (Microsoft 365 roadmap item 171161).

Mitra says that Microsoft is using its standard service rollout process, so I assume that tenants will receive notifications in the Microsoft 365 message center when the update lands. The assumption might be code for hope as the article includes no extra detail about how customers might know when their audit log events last 180 rather than 90 days. I guess you could check by running an audit search for users with Purview Audit (Standard) licenses to see when events older than 90 days begin to feature. Let’s hope that we don’t have to do that.

The Trouble with the MailItemsAccessed High-Value Audit Event

In January 2019, Microsoft announced the MailItemsAccessed event, the first of a set of high-value audit events of special interest to investigators. In April, they ran into software bugs before eventually moving forward again in June 2019. Finally, in October 2019, Microsoft decided that customers would need a new license before Exchange Online would generate the MailItemsAccessed event. In short, despite the value to audit investigations to know about when messages are accessed in a mailbox, the MailItemsAccessed event has had a checkered history.

Another episode in history is now developing. According to Microsoft 365 roadmap item 182259 (Figure 1), Microsoft plans to make the MailItemsAccessed audit event available to Audit (Standard) customers in preview in June 2024 with a full roll-out scheduled for September 2024.

Microsoft’s October 18 article says that “Audit (Standard) license holders will be able to access an additional 30 audit logs, shown in the table below over the next several months.” They’re absolutely correct that the discussion isn’t all about the MailItemsAccessed event. Microsoft plans to make other events covering data access originating from SharePoint Online, Stream, and Teams available to Audit (Standard) customers, and that’s a welcome move.

Investigators Love MailItemsAccessed

The problem is that MailItemsAccessed is the richest source of information for investigators seeking signs of compromise. It’s common for attackers to access mailboxes and read messages to look for indications that someone might be a good target, like a corporate executive or someone holding a privileged role. The value of the information captured in MailItemsAccessed events for forensics is why Microsoft introduced it as the first high-value audit event in 2019. Few attackers will run to check a Stream video transcript or check details of a Teams meeting participant when they probe accounts to select a target when mailboxes are available to investigate. Deployment of the other audit events can wait, but hanging on for another eight months before deploying the MailItemsAccessed event to Audit (Standard) customers is simply unacceptable.

At a technical level, I don’t understand why Microsoft made this decision. Exchange Online generates MailItemsAccessed events based on a license check. It’s surely not outside the competence of Microsoft developers to update the Exchange Online code to check two licenses. That would make the events available for Audit (Standard) accounts quickly without going through the palaver of a preview.

It’s true that generating MailItemsAccessed events for both Audit (Standard) and Audit (Premium) customers will consume more storage, but this growth will be a pinprick when compared to the overall storage picture for Microsoft 365.

Some Good Stuff Coming

In all the doom and gloom around the delivery of extended audit events to Audit (Standard) customers, some good stuff is coming to help with the audit infrastructure. My favorite is the introduction of an Audit Search Graph API (Microsoft 365 roadmap item 117587), due in November.

Perhaps the Graph API will make audit searches more reliable and robust. That remains to be seen. Even if the Graph API delivers improvements, it’s still not an excuse for Microsoft to mess around with the Search-UnifiedAuditLog cmdlet. Seven years of customer dependency on scripts using the cmdlet can’t be eliminated by the introduction of a new Graph API. Microsoft needs to fix the cmdlet and make the MailItemsAccessed event available to Audit (Standard) customers ASAP. I’ll be a happy camper then.