Microsoft Closes the DLP Gap for Office 365 Workloads
In a surprisingly understated manner, Microsoft announced the general availability of a bunch of new data loss prevention (DLP) functionality, including the ability to replace Exchange DLP policies.
Why is this important? Well, Microsoft introduced DLP policies in Exchange Server 2013 and subsequently in Exchange Online. These policies are otherwise known as ETRs (Exchange transport rules and not Exchange transfer rules as Microsoft’s blog says) because transport rules are the backstop for DLP checks. Client-side DLP checks in Outlook and OWA can pick up the presence of sensitive data, like credit card numbers, but a guarantee to block information leaks is only viable when data flows through a point where a policy engine can examine the halt and block it if a violation occurs. The Exchange transport service is that choke point.
The Introduction of Unified DLP
Roll forward a couple of years to 2016 and Microsoft introduced unified DLP policies. Instead of limiting processing to Exchange messages, Microsoft designed the unified 365 DLP engine to apply policy to items originating in multiple workloads, like email, documents, and chats. To support DLP, each workload has its own choke point (for SharePoint Online and OneDrive for Business, it’s document indexing, for Teams, it’s the chat aggregator). Some workloads have their own peculiarities (for example, Teams requires Office 365 E5 licenses while the others require E3), but the point is that a uniform DLP service is available.
That is, unless you depended on some of the finer points of the wide set of conditions, exceptions, and actions supported for message processing by Exchange transport rules. Since their introduction in 2016, unified DLP policies have supported a smaller set of conditions for email, forcing organizations which depended on ETRs to stay with this technology rather than moving to unified policies.
Closing the Email Gap for DLP
The big news is that organizations can finally replace those ETRs because unified DLP policies now support an expanded range of email conditions, actions, and exceptions that’s on par with ETRs. In fact, unified DLP policies are more powerful than ETRs because they support other conditions, like checking for custom sensitive information types or sensitivity labels in content.
To test, I created a DLP policy to look for email sent to a specific domain tagged with a specific sensitivity label (Figure 1). When the DLP engine detects messages matching the criteria, it generates a report and adds a user as a CC recipient (acting in the role of a compliance manager) to the message. While perhaps not realistic, this is an example of the kind of processing that’s now available in unified DLP policies.
After saving the policy, it takes a little time to make workloads aware of the new policy. Once active, the policy worked flawlessly. Mail flowed and arrived complete with the CC recipient and a nominated mailbox received a DLP violation report (Figure 2).
Not All Sweetness and Light
Good as it is that Microsoft has finally closed the functionality gap for unified DLP policies, it’s not all sweetness and light if you have ETRs in production. Even with the same set of conditions, actions, and exceptions available, the process of moving from ETRs to unified DLP policies is a manual process. Administrators must build and test new unified DLP policies, and then move into production. Rules must be checked to ensure that no conflicts exist and that messages will pass through the DLP engine and come out the other side as expected. Hybrid organizations need to check that the same processing happens in both on-premises and cloud systems. It will all take time and great attention to detail.
Long-term Gain for Short-term Pain
But the long-term importance of the move is profound. Workload-specific processing isn’t a good idea in a cloud ecosystem which values common processing across workloads. Unified DLP policies pick up advances in associates technologies like trainable classifiers, sensitive information types, AI-based recognition, and so on. The expectation is that processing will become smarter over time to reduce the number of false positives and be more capable of blocking real attempts to leak information. That’s a big deal if you’re concerned about information protection and governance.