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.

Stating conditions in a rule for a unified DLP policy
Figure 1: Stating conditions in a rule for a unified DLP policy

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).

A report received after DLP detects a policy violation
Figure 2: A report received after DLP detects a policy violation

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.

About the Author

Tony Redmond

Tony Redmond has written thousands of articles about Microsoft technology since 1996. He is the lead author for the Office 365 for IT Pros eBook, the only book covering Office 365 that is updated monthly to keep pace with change in the cloud. Apart from contributing to Practical365.com, Tony also writes at Office365itpros.com to support the development of the eBook. He has been a Microsoft MVP since 2004.

Comments

  1. Dave

    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?

  2. Keith

    Great article Tony! Have to agree with Tristan re the Microsoft wording, which IMO is very misleading to say the least.

  3. Tristan

    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

      1. Tristan

        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)?

        1. Avatar photo

          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.

          1. Tristan

            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).

      2. Tristan

        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!

          1. Tristan

            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.

Leave a Reply