Last year Microsoft released additional functionality to Office 365 Message Encryption (OME) including a new encryption template “
Clearly, there was a feeling that the move was going to cause too much disruption. For many
The original Microsoft intention was to encrypt messages that contained the following sensitive information types:
- ABA routing number
- Credit card number
- Drug Enforcement Agency (DEA) number
- U.S./U.K. passport number
- U.S. bank account number
- U.S. Individual Taxpayer Identification Number (ITIN)
- U.S. Social Security Number (SSN)
If you want to apply this transport rule you can still complete this by manually configuring the transport rule and message encryption settings in Office 365. Firstly, you should connect to Exchange Online PowerShell using instructions in this post. Then, run the following command to update the Office Message Encryption settings:
Set-IRMConfiguration -DecryptAttachmentForEncryptOnly $true
This command configures OME to only encrypt the email itself, and not the attachments contained within the email. This means that once the user has decrypted the email by logging in or verifying their identity, they have full access to open, edit, print or forward the attachment as with any other email. If you don’t run this command when the user decrypts the email, the attachments will remain protected and Read-Only.
Once the attachment configuration has been updated you can then create the transport rule using the following command:
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"}) -NotifySender "NotifyOnly"You can then view and update the transport rule from within the Exchange Online Admin Center should you want to. You could also add any custom sensitive information types you might have configured in your tenant to this same rule should you want to.
Although there seems to be a general consensus that this rule shouldn’t be added or enabled by default, as I mentioned before, a move to encrypting more email by default should be considered, and you don’t need to limit the scope of this to only sensitive information type. You can apply the Encrypt template to any emails you can identify using an Exchange Online transport rule.
For example, you could target specific recipient domains:
Or you could encrypt messages with a specific subject string:
This is one of many ways for you to apply encryption automatically to best suit your organisation, and better yet to protect your users from data leaks and improve data security.
The Real Person!
The Real Person!
In modern Outlook per default we can use “Encrypt” and “Do not Forward” templates when sending emails. In classic Outlook there are two more, meaning “Confidential All Employess” and “High Confidential All Employees”. How can we get rid of these 2 templates in classic outlook?
I am trying for a while to setup a rule in Exchange Online to encrypt messages with a RMS template, but for some reason i cant choose for an encryption with code, so that if you receive the message, you ask for a code to get the original message.
Does anyone know how to fix this?
It depends on the client being used by the recipient and their account. Accounts in M365 tenants using clients that know how to interact with MIP will fetch the necessary use licenses etc. and display the decrypted content inline. Others will prompt for a code to allow them to read the message via the MIP portal. AFAIK, you can’t force an “enlightened” client to use a code because this would be too disruptive to the flow of receiving and reading messages.
Please tell me this encrypt policy doesn’t send a separate email through the same potentially compromised mail channel with the password? LOL? Maybe they should come up with an “auto stickie note” that pops up in the receiver’s screen with the password? How dumb is that.
I had tested a year or so back with the ome version and had a rule with keyword and an auto encrypt that would look for sensitive info like socials etc. Completely working. Fast forward, none of that works so I switched to the new 365 encryption. The keyword rule works fine but the auto encrypt for sensitive info does not. Microsoft claims i need an e5 license despite having the Azure information protection. I’m completely lost on this. They are all the time changing things and it’s almost a full time job just to read updates. Anyone know if this is true or do you have an auto rule setup to encrypt with the new encryption that is working? I have business premium and azure information protection.
Ryan
I am having similar situation. My rule stopped working and now I can not make it work nor with the old OME encryption neither with the new 365. I have an on premises exchange routed thru online exchange. A guy in support told me that I have to migrate to online for it to work. I don’t believe what he said I will have to get someone else from support
Mike, Really appreciate the guide. I wrote a script to semi-automate adding domains to such a rule set, in a case where your org wants to sort of ‘OME if TLS fails’ type of situation. Theres a write up over on Tech Community : https://techcommunity.microsoft.com/t5/exchange/forcing-message-encryption-on-certain-domains/td-p/1133382#.XjB3O6gUt4Y.link Let me know your thoughts.
Thanks for the tips here. I’m using Tor private browser and Surfshark VPN, but I guess it’s time to upgrade my security level and learn how to send encrypted emails. I was thinking about getting something like Protonmail, would you say it’s safe to use?
In your fist example when sending an email to practical365.com and cc’ing a friend on gmail the email to *both* will be encrypted which is a pain.
Is there a way to avoid this scenario so the gmail side never sees the encryption?
we have enabled this AIP flag but the end user not able to open the email in the outlook client. any thoughts
This is really useful, thanks
Microsoft also warned that OME won’t coexist normally with old on-premise RMS services, so RMS has to be deprovisioned first or OME should be disabled (at least partly, updates to OME functionality should be disabled with a command).