Microsoft Plans to Launch Automatic Email Encryption for Office 365 Tenants
Spoiling the Success of Information Protection
I like what Microsoft’s Information Protection team has done recently to make encryption more accessible to Office 365 tenants. Changes to Office 365 Message Encryption, including the introduction of the Encrypt-Only feature supported by Outlook clients, have improved the ability of Office 365 tenants to protect critical information.
And then something comes along to upset the apple cart. In this case, according to documentation published on 13 December 2018, it’s Microsoft’s plan to create a transport (mail flow) rule in Office 365 tenants to encrypt outbound messages that hold sensitive data.
According to the documentation, Microsoft “will be creating a new automatic policy in Office 365 tenants,” but they don’t say when. Microsoft does say that they will give tenants a 30-day notice via the Office 365 Message Center to prepare for the change and to opt-out if desired. I can’t find any evidence of the intention to introduce a new encryption policy in the Office 365 roadmap.
Say Goodbye to Traditional PC Lifecycle Management
Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.
Good in Theory, Horrible in Practice
On the surface, this seems like a tremendous idea that demonstrates the value of integration of different components across the Office 365 suite. The transport rule will use the special Encrypt-Only template to encrypt all outbound email with a set of sensitive data types like credit card or password numbers (which might differ based on an organization’s locale). Office 365 tenants can sit back and relax and let Microsoft do the heavy lifting to protect their email traffic.
Using well-established sensitive data types proven in Office 365 Data Loss Prevention policies to detect email that should be protected is reasonable, even if some unexpected consequences can sometimes flow when these data types are used. For instance, last August Microsoft had to tweak the GDPR DLP policy because it blocked email that included mobile phone numbers.
But when you stand back and consider the idea in the round, many reasons exist why this plan should be consigned to the great byte wastebasket.
Opt-In Rather Than Opt-Out
First, although Microsoft gives tenants a way to opt out and avoid the creation of the transport rule, anything that introduces a new policy into a tenant should be an opt-in choice. Microsoft tells customers that data in Office 365 is their data. Tenants should always have the right to decide how their data is processed.
To opt-out, connect to Exchange Online with PowerShell and run the command:
Set-IRMConfiguration -AutomaticServiceUpdateEnabled $false
You can apply the change to the IRM configuration now. It seems like a good idea to update your tenant’s configuration, just in case.
Messing with Email Transport is not a Good Idea
Second, like the ill-fated attempt to create Office 365 Groups for every manager and their direct reports that sank without trace in 2017, this is an idea that seems great on paper but quickly runs into practical difficulties in the field.
For instance, enterprise tenants often run quite complex sets of transport rules. Inserting an automatically-generated transport rule into the mix without warning or testing is a recipe for disaster that could interfere with the reliability of mail flow within the organization.
There’s also the case that many ISV products can’t deal with protected content. I recently pointed out the difficulties that autosignature products have in processing protected email. Introducing a transport rule to encrypt even more messages without knowledge of the ISV products in use by a tenant is simply inconceivable.
And Microsoft has no idea about the client or server mix used by important customers of an Office 365 tenant. Suddenly finding that email sent to an important customer or partner is encrypted and forces the recipient to go to the Office 365 Message Encryption portal to read the content is unlikely to be a popular advance.
The biggest problem with the plan is that processing tenant data without their approval undermines the bond of trust that connects Microsoft as a service provider with their customers. The Office 365 Trust Center is clear on this point. It says that tenants own and control their data (Figure 1). Well, encrypting data without warning is not giving control to tenants.
Good Demo, Bad Plan
Overall, this is a plan that works well for greenfield tenants (or demo tenants shown at technology exhibitions) but not in production. Launching encryption upon email for Office 365 tenants without so much a by-your-leave is not what we expect from Microsoft. With nearly 23 years of experience of Exchange and how customers use Exchange, you’d expect a more measured and nuanced approach to helping customers protect email. The sentiments behind the idea are good; the implementation is horrible.
I hope Microsoft will do the right thing and pull the plug on this idea – or at least make it an opt-in choice for their customers.