Exchange Online Transport Rule to Encrypt Sensitive Email

Email Encryption is Good, but Only Under Tenant Control

In January 2019, Microsoft revealed a plan to create a transport (mail flow) rule in Office 365 tenants to encrypt email containing sensitive data. For many reasons, not least that it’s not a good idea to interfere with the business logic a tenant chooses to apply to outbound email, Microsoft pulled back on the idea. On January 25, after a period of mature reflection, Microsoft decided to publish details of how to create the transport rule and leave it to tenants to decide if they want to use it. Those instructions are now online. This post explores the commands included in Microsoft’s instructions.

PowerShell Commands to Create Rule

The instructions use two PowerShell commands. The first runs the Set-IRMConfiguration cmdlet to update the rights management configuration for Exchange Online in the tenant. The command sets the DecryptAttachmentForEncryptOnly switch to $True to give recipients of messages protected with the default Encrypt-Only template full rights over any attachments. The default value of this setting is $False, which means that attachments remain encrypted.

Unfortunately, the command published in the article is incorrect as it uses DecryptAttachmentsForEncryptOnly instead of
DecryptAttachmentForEncryptOnly.The correct command is:

Set-IRMConfiguration -DecryptAttachmentForEncryptOnly $True

Microsoft’s New Transport Rule

The next command runs the New-TransportRule cmdlet to create the transport rule. The rule applies the Encrypt-Only template to protect any messages that include the following Office 365 sensitive data types:

• ABA Routing Number.
• Credit Card Number.
• Drug Enforcement Agency (DEA) Number.
• U.S. or UK Passport Number.
• U.S. Bank Account Number.
• U.S. Individual Taxpayer Identification Number (ITIN).
• U.S. Social Security Number (SSN).

The Encrypt-Only template is used because it is available to every Office 365 commercial tenant and any Outlook.com user. Any other recipient can go to the Office 365 Message Encryption portal to decrypt the content.

Checking the Rule

The sensitive data types are very U.S.-centric and might need to be adjusted for your tenant to include data types that are more commonly used in your organization. I imagine that Microsoft chose the set for the rule because they are well-known and prove the potential value of the rule rather than deciding that these types make sense for every Office 365 tenant. Remember that you can create your own custom data type and use it if needed.

Unhappily, the PowerShell gods conspired against this command as well because it also has an error. The command as given by Microsoft is:

New-TransportRule -Name "Encrypt outbound sensitive emails (out of box rule)" -SentToScope  NotInOrganization  -ApplyRightsProtectionTemplate "Encrypt" -MessageContainsDataClassifications @(@{Name="ABA Routing Number"; minCount="1"},@{Name="Credit Card Number"; minCount="1"},@{Name="Drug Enforcement Agency (DEA) Number"; minCount="1"},@{Name="U.S. / U.K. Passport Number"; minCount="1"},@{Name="U.S. Bank Account Number"; minCount="1"},@{Name="U.S. Individual Taxpayer Identification Number (ITIN)"; minCount="1"},@{Name="U.S. Social Security Number (SSN)"; minCount="1"}) -SenderNotificationType "NotifyOnly"

The problem is the last parameter where SenderNotificationType should be NotifySender. Change the command and replace the last parameter with NotifySender = “NotifyOnly” and PowerShell will happily create the new rule.

Adjusting for Your Office 365 Tenant

Before running New-TransportRule, remember to adjust the command to include the sensitive data types that you want to check for and any other changes deemed appropriate for your tenant. For instance, you might not want to encrypt email to every other domain and decide that protection should only be applied to specific domains.

If you don’t want to work with transport rules through PowerShell, you can run Microsoft’s command and then edit the transport rule through the Exchange Admin Center GUI. As you can see below, it is often easier to adjust settings through a GUI. In this case I limit the domains that receive protected email. If you choose to limit the rule to selected domains, you must also remove the notification to the sender as this setting conflicts with a domain list (for no apparent reason)

It is important to check that the new rule does not conflict with any other rule that already exists. For instance, you might discover that another rule does something else to messages sent to the selected domains and then exits rules processing, so messages will never be encrypted.

The old advice to never trust and always check code downloaded from the internet holds true, even when you download code written by Microsoft.

---

We cover rights management and email encryption in Chapter 24 of the Office 365 for IT Pros eBook while transport rules are described in all their glory in Chapter 17.