Microsoft Reverses Course
On January 8, I reported how Microsoft planned to install an Exchange transport (mail flow) rule into the configurations used by Office 365 tenants to automatically encrypt outbound email holding sensitive data. On the surface, the idea is a good one, but when you understand how transport rules are used in production environments, it loses it shine. Making the rule an op-out rather than an opt-in feature, and the fact that Microsoft shouldn’t ever alter customer Office 365 data without permission, caused the idea to founder.
On January 25, Microsoft announced (Message Center notification 170958) that they had withdrawn the idea. Instead, they would give instructions about how to create a rule to encrypt email containing sensitive data and leave it to tenants to decide if they wish to deploy the rule as is or tweak it for their environment. For instance, it is generally a good thing to put rules that encrypt email at the end of rule processing so that encryption happens after any other changes are made to messages.
The Right Approach
Delivering a optional rule for email encryption is the right way to help Office 365 tenants understand the value of email encryption and how they can exploit the work Microsoft has done since 2016 to make rights management-based encryption easier to use. All tenants are now automatically enabled for information protection, the Office 365 Message Encryption (OME) portal has been refreshed, and the Encrypt-Only default template introduced.
Even after making encryption easier for Office 365 tenants to use, the user experience is still not seamless enough for many. This is where encryption applied by transport rules can help by making sure that the right type of email is protected in the right manner, no matter what client someone uses.
Too Many Ways to Protect
Outlook desktop and OWA currently support the ability to select a template to protect a message (Outlook Mobile will be able to do this soon). Although it’s fantastic to be able to choose from all the templates published within a tenant, sometimes the choice can overwhelm users. The problem is that few of the total user population in a tenant usually understand rights management. Unless they are told, they don’t know that templates can be scoped so that only certain groups can read protected content. Nor will they know that sending encrypted content outside the tenant won’t work unless the recipient is given the rights to read that content.
When Protection Goes Wrong
In fact, using the wrong template is the biggest problem that I experience with receiving encrypted email. Every Office 365 tenant includes the default Encrypt-Only and Do Not Forward templates, so no problems exist with email protected using these templates. It’s when people choose a custom template that problems arise.
The typical flow is that Outlook can’t decrypt a message to display its content inline (the Outlook clients, including Outlook mobile automatically fetch the necessary licenses to decrypt content for display). Instead of the message text, the recipient sees text with a link to bring them to go to the Office 365 Message Encryption (OME) portal to read the protected content (Figure 1). When they follow the link, OME checks the recipient against the permissions included in the template, finds that they have no permission, and declines to decrypt the content. Cue frustration for both sender and recipient.
Some Help from Sensitivity Labels
The user interface for current Outlook clients isn’t ready for Office 365 Sensitivity Labels yet. After Microsoft updates Outlook and the Office online apps, it will be easier for users to apply labels. And if a label is linked to a rights management template, the message will be encrypted. Some education and support will still be needed to coach users into what labels to use for outbound email as otherwise they’ll get into the same problems as described above.
Transport Rules Do the Job
Transport rules can apply encryption for both on-premises Exchange and Exchange Online. The same method is used in both cases, but you do need to do the work to deploy a Rights Management Services server (a Windows server role) before creating and publishing templates on-premises. The work to enable rights management is done automatically for Office 365 E3 and E5 tenants.
Applying encryption via transport rules solve the problem of making sure that specific traffic is protected, no matter who sends the email or what device they use. The conditions in a transport rule are very flexible. You can:
- Apply a selected rights management template. Unless you use the default Encrypt-Only or Do Not Forward templates, the selected template must contain permissions for the target domains.
- Limit protection to specific domains or recipients. For instance, encrypt everything sent to Microsoft.com.
- Limit protection to email containing sensitive data.
- Limit protection to email sent by specific people.
- Limit protection to email that has a specific word or phrase in its subject line. For example, “highly confidential.”
The wide range of conditions and predicates available in transport rules makes them a powerful way for an organization to control how messages are processed. An organization can deploy tens or even hundreds of transport rules to achieve precisely the processing they need, including blocks between different user groups (ethical firewalls), insertion of disclaimer text (auto-signatures), highlighting external email, and protection.
Some Value in the Original Plan
Although I think Microsoft’s original plan to install a transport rule for encrypting email was flawed, they might have done us a favor by highlighting how effective transport rules are in applying protection. Once Microsoft publishes the documentation covering their suggested approach to protecting email containing sensitive data, it might just be a good idea to consider how to deploy such a rule.
If it were me, I would proceed cautiously at first by limiting the rule to selected domains. Any domain that uses Office 365 is a good choice (like Microsoft.com) because you know that recipients in those domains likely use clients that can handle protected messages. Go forth and deploy your rules!