Microsoft Office 365 is now the most used enterprise cloud service by user count. However, while organizations are quickly adopting Office 365, a lot are still sitting on the sidelines when it comes to migrating their on-premises Exchange Server environments to Exchange Online, the Office 365 equivalent. According to McAfee’s (formerly Skyhigh Networks) latest Office 365 Adoption & Risk report, Exchange Online had the second highest penetration rate of Office 365 applications – 66.9% of enterprises have at least 100 users, however, only 7.9% of users actively use Exchange Online.
This is, in part, due to how mission-critical email systems built on Exchange Server are to most organizations. Any disruption to email, even for just a few hours, could result in millions of dollars of lost productivity, so organizations are migrating in phases. In this article (part of a series of posts on Exchange migrations to the cloud) I will cover how to configure different methods of encryption available in Exchange Online to ensure data security and compliance in the same way organizations have done in their on-premises Exchange environments.
Microsoft provides 3 ways to migrate from on-premises Exchange to Exchange online:
Regardless of the migration path, enterprises need to be able to apply the same security controls they had in their on-premises Exchange deployments to Exchange Online.
There are three flavors to email encryption when it comes to Exchange Online. One is the traditionally accepted S/MIME (Secure/Multipurpose Internet Mail Extensions) protocol where emails are digitally signed and encrypted before being sent. This method gives the recipient confidence that the message is, in fact, sent from the person that appears as the sender, thereby alleviating phishing concerns. S/MIME works with Outlook but is not supported by web-based email clients.
The second method is known as Office 365 Message Encryption (OME), where an Office 365 administrator (and not the user) determines which message should be encrypted by setting up transport rules in EAC. When this capability is enabled, recipients receive an email notification instructing them to click a button and go to a web portal where they authenticate and then view encrypted messages within their web browser, introducing an extra step to read messages as shown in the diagram below.
The last method is encryption via Information Rights Management (IRM).
There are advantages and disadvantages to each type of encryption that each more appropriate for specific use cases. Messages encrypted via S/MIME, for example, can’t be scanned for malware, spam, or policies determined by transport rules. Messages encrypted via OME can’t have usage restrictions applied to them (such as forwarding/printing), while IRM-encrypted emails might not be supported by some devices. In the same vein, IRM-encrypted emails are most appropriate when one wants to restrict usage such as a “do not forward” restriction, while OME-encrypted emails are better suited when a physician sends HIPAA protected data to a patient, and S/MIME is more appropriate for two government agencies communicating with each other.
Setting up S/MIME in Office 365 is slightly different from doing so in Exchange Server. The way to setup S/MIME in the scenarios where all users are hosted in the cloud is different from a hybrid model (not covered in this article) where some mailboxes are housed on premises and some in the cloud.
To setup S/MIME in a cloud-only deployment, you’ll need an .SST file (created from a certificate store) containing all root and intermediate certificates to be used when validating the S/MIME message in Exchange Online. You’ll also need unique certificates for all users (issued from Certificate Authorities (CA) either Windows based CA or Third party CA) for signing and encrypting the message.
You can either use Window’s PowerShell cmdlets or Certificate MMC to export the SST file. When using the Certificate MMC console, open certmgr.msc snap-in, open Trusted Root Certificate Authorities, go to certificates, click on the CA certificates which issued the certificates to end users for S/MIME and right click, select all tasks, then click export.
In the next step, the Certificate Export Wizard will open. S elect Microsoft serialized certificate store, click next, then save. You can then upload the .SST file to Office 365. You can use Exchange Online Powershell to enable command line configuration. Execute the below command:
$sst = Get-Content .sst -Encoding Byte
(replace “xyz” with the SST name)
Set-SmimeConfig -SMIMECertificateIssuingCA $sst
The admin will then need to Install the certificate on every user’s local machine who requires S/MIME encryption, and then publish it to the Exchange Online Global Address List via Outlook:
- Open Outlook, click “file,” then “options.”
- Go to “Trust Center,” click “settings” then “email security”
- Go to “settings” and choose the certificate issues by CA to be used for S/MIME. Here you’ll be able to also give the Security Settings a name, then click “choose” next to signing certificate and encryption certificate and pick the certificate assigned by CA that you selected earlier, while leaving “algorithm” section to default. Click “OK”, then click “Publish to GAL” button, and again click “OK”.
Configuring Office 365 Message Encryption
Office 365 Message Encryption (OME) is requires an organization to have Azure RMS. Administrators can setup rules that will encrypt messages based on transport rules, such as those that might contain a particular keyword. If a user triggers that rule, OME is applied to the message. The recipient can view the decrypted message in their web browser either by signing in with a Microsoft account or work account connected to Office 365, or with a one-time-use password. Since Office 365 can also encrypt replies to a message, admins can setup rules that will automatically decrypt replied messages.
The process of creating a OME rule is similar to creating DLP rules:
- Go to EAC, on the menu to the left, go to “mail flow”
- Select the “+” sign to create a new rule
- Select the rule that you want to add (such as email sent to a specific recipient)
- In the “Do the following,” pick “modify message security”, and “apply Office 365 Message Encryption.”
Configuring Information Rights Management-based Encryption
Enabling IRM encryption is fairly straightforward for organizations who have Azure RMS. Users can manually apply a IRM template (such as don’t print, forward, etc.) at the point of sending the email. IRM encryption only works for internal messages sent to recipients within an organization. Exchange Online administrators can also create transport rules (same way as how OME rules are setup, see above) and apply IRM restrictions.
About the Author
Categories: Cloud Security