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.
Thanks for the article! One query I have that I can’t seem to find an answer for – if there are on-premises applications in a hybrid setup that send mail through an on-premises relay up to EOP to go through DLP using ETRs, will this still work with Unified DLP. The email will be an anonymous sender so not sure how this would this work with licensing etc?
The key will be to have the messages pass through the transport service within Exchange Online. If that happens, the DLP rules will be executed. If not, they won’t.
Great article Tony! Have to agree with Tristan re the Microsoft wording, which IMO is very misleading to say the least.
No one said that engineers or program managers have to be great writers…
Hi Tony,
I noticed when playing around with DLP for Exchange Online email for PII UK, there isnt an option to block the email from sending if it violates – only the option for policy tips to warn the user and notify my admin account once sent (after it sends the sensitive data our).
When looking at the Actions in the DLP policy, they all related to blocking access to the content as though its a file in Sharepoint or OneDrive – no option to block email. Am i missing something here? Should i be able to deny the user sending the email?
Kind Regards
The wording says block access in Microsoft 365 locations. If you include Exchange in the locations for a DLP policy, it will block access to email which violate the policy rules.
This doesnt prevent the email from sending though as i have tested in my lab.
Surely this should prevent the email being sent out of the business or is the expectation that we still use EMC compliance DLP (which i believe is being phased out for this alternative in the Compliance centre)?
DLP is very effective at stopping people sending email which violates a policy. When it does, the sender receives a notification and the message is blocked. Here’s a sample notification.
Your email message conflicts with a policy in your organization. The message wasn’t delivered to all recipients. Issues:
• Message contains the following sensitive information: Azure Active Directory password
Blocked Message Details
Created Date: 8/23/2021 10:48:24 AM
Sender Address: Tony.Redmond@office365itpros.com
Blocked Recipient Address: Chris.Bishop@office365itpros.com
Subject: Passwords
You should you use the Microsoft 365 form of DLP whenever possible. The older Exchange-only DLP will be phased out in the future.
Thank you Tony, I tested further with Actions to achieve my desired outcome, set for High Volume instances.
I feel the descriptions and documentation have let me down here personally but now it does work as expected (and well).
Just in case its useful to anyone, to get this to work and block email i had to set an Action that “Restricts access or encrypts the content in M365 locations” then “Block only people outside the org”.
I feel these actions arent worded very well and the process isnt that well documented on MS Learn – could just be my perception though!
It’s hard to come up with wording that everyone understands immediately…
Agreed but by mentioning only Sharepoint, OneDrive and Teams in the configuration of the actions suggests Exchange Online isnt included in the scope, which is incorrect because it works for that service too. Thats quite confusing.