Guidance

Microsoft Office 365 Security Guidance: Email

Updated 4 November 2015

This guidance was withdrawn on 11 July 2016

This content has been moved to the CESG website: https://www.cesg.gov.uk/cloud-security-collection

This document gives deployment security considerations when configuring email and hybrid deployments with the Microsoft Office 365 (O365) web service. The secure configuration of this cloud-hosted service aligns with government’s guidance on implementing the Cloud Security Principles. Please send any feedback you may have to enquiries@cesg.gsi.gov.uk.

1. Protecting email

The encryption of email at rest (for example, hosted by on-premise enterprise servers) and in transit (for example, to a cloud service) ensures secure delivery, maintaining both data integrity and confidentiality.

2. Transport Layer Security

CESG recommend that email sent between government departments and certain third parties be encrypted in transit. It is good practice to use end-to-end Transport Layer Security (TLS) to do this. By default, TLS will be used by O365 when it is supported by the other party. O365 should be configured so that:

• outbound email to specified servers is always sent encrypted

• email is routed through any third party cloud services (for example, an email scanner) via both inbound and outbound connections to the service, with all connections encrypted

• certificate pinning is enabled where high confidence is required in sending email to a known recipient organisation

• any third party email services being used are configured to encrypt email

O365 offers two ways to implement forced TLS:

• Connectors can be used to create a secure partnership between an enterprise’s tenant and an external domain, configured under Office 365 Admin Centre | Exchange Admin Centre | mail flow | connectors. This method requires a CA signed certificate .

• An email flow rule can be created under Exchange Admin Centre | mail flow | rules. This can be applied to all email or specified domains and addresses. This method requires a self-signed certificate.

In both cases, TLS can be configured for both inbound and outbound email. If a third party encryption service is used and unencrypted traffic needs to be routed to it, connectors can be used to route all email to a certain server unencrypted. CESG recommend that email is sent between government departments using secure partnerships.To do this, you should create connectors as an exception to any established email flow rules.

Microsoft offers a message encryption service for O365, with service information and an FAQ available. This service is policy-based, built on Azure Rights Management (RMS) and is controlled by the administrator; it does not rely on PKI. If message encryption is available, an email rule can be set up to apply it if the email contains sensitive information (for example, a credit card number). Exchange Online also supports the S/MIME protocol for sending signed and encrypted email. This is controlled by the individual user (including the cryptographic keys) who can choose whether to use it for each email sent.

3. Email flow

Outlook in O365 is designed to transmit all of an enterprise’s email and all incoming email to the enterprise’s domain name will be processed by Microsoft. By default, Exchange email servers deliver incoming email to the O365 inboxes of an enterprise’s users. If email is addressed to a user not registered in an O365 enterprise’s domain, this email will be discarded.

4. Outlook routing

The Exchange Admin Centre (EAC) allows an administrator to create message rules with the options to include the application of rights protection, applying a disclaimer, or sending messages to quarantine. These rules can be applied to a number of message criteria; for example, you can specify that all messages with executable content be sent to quarantine. CESG recommend that the administrator consider these options and apply the rules that are most appropriate for the enterprise. If Message Encryption is part of an enterprise’s Microsoft package, a rule can be created to apply it to all messages.

5. Outlook gateways and third party email services

An administrator of O365 can configure inbound and outbound email gateway servers to integrate with third party email services. For email scanning, this should be done in line with an enterprise’s existing email scanning policies, to filter email and to protect users (and those they communicate with) from spam, viruses, phishing attacks and data loss. It is possible to use a third party cloud service in addition to Microsoft’s own Outlook scanning service. The third party service can provide scanning of:

• inbound traffic to limit the risk of unsolicited and harmful email reaching user mailboxes

• outbound traffic to ensure that viruses are not sent from an enterprise’s network while also reducing the possibility for exploitation of an enterprise’s email domains by malicious actors (for example, spoof email masquerading as being sent by the enterprise)

Configuring gateways and third party services will be most effective when:

• SMTP traffic has been restricted to the service’s cloud server IP ranges. Limiting traffic to between the enterprise’s internet gateway and the cloud will help prevent spam and viruses being sent directly to or from the enterprise email servers and which bypass the cloud service.

• Enterprise SMTP servers are not using third party/open relay services. Open relay email servers can accept email from any domain and forward it to another sender without verification. It is exploitable by malicious actors and presents a security risk that should be mitigated.

• email protection to the cloud service has been ensured by secure delivery and where possible, TLS has been enforced to only deliver email when a secure connection can be established with the recipient

Outgoing email from an on-premise email service will be filtered by Exchange Online using Exchange Online Protection for malicious content before reaching external contacts. Information on Exchange Online anti-spam and anti-malware protection and O365 email anti-spam protection is available. Exchange Online filters spam through policies defined under three categories: connection, content and outbound spam. Policies are not removable but are customisable under OAC | Admin | Service Settings | Mail.

Microsoft provides information on the security and compliance features of Exchange Online service.

6. MX Records

MX records will need to be reconfigured when changing email providers or redirecting email to a remote server. When handling MX records it is worth noting that:

• Microsoft offer both generic and host-specific advice on how to set up MX records

• care should be taken when changing MX records in administrative settings to ensure that email is routed via known and trusted parties

• if an external organisation manages an enterprise’s MX records, they should be made aware of any intended changes to email services in a timely manner; this will avoid denial of service scenarios for an enterprise’s email users should problems arise during deployment

• 72 hours should be allowed for MX record changes to fully propagate across the Internet and deployments staged accordingly

7. Hybrid deployments

An O365 hybrid deployment resolves an on-premise email Exchange Server and a cloud-hosted O365 email service (Exchange Online) into a consistent email service with a single shared domain namespace. Users with mailboxes in both locations can find each other in a common Global Address List, share calendar data and send and receive email regardless of where their email resides. Hybrid deployment is operable in all O365 plans that support Windows Azure Active Directory (Azure AD) synchronisation. An administrator of a hybrid deployment can manage both Exchange Server and Exchange Online via the EAC.

Building, rolling out and managing a successful hybrid deployment between Exchange Server and Exchange requires careful planning and implementation. Both Exchange Server 2010 SP3 and Exchange Server 2013 CU2 support hybrid deployments using the Hybrid Configuration Wizard (HCW), a tool that can be used with the Microsoft Exchange Deployment Assistant to support administrators during a hybrid deployment rollout. For the best performance, CESG recommend keeping Exchange Server updated to the latest patch version and using Microsoft Outlook 2013 or 2010 as the email client.

8. Trust and certificates

Hybrid deployments must have trust ensured between the enterprise’s on-premise Exchange Server and O365 Exchange Online instances. This trust is brokered by Microsoft’s cloud-based Federation Gateway or Azure AD authentication system and is automatically configured on O365 activation.

Hybrid deployments have specific certificate requirements for secure operation:

• Some hybrid deployment services (for example, Active Directory Federation Services) will require certificates. CESG recommend that dedicated certificates for each server are used rather that running a single certificate over multiple servers, so that renewal and replacement of individual certificates will not necessarily introduce a denial of service.

• if a hybrid deployment has Exchange Servers deployed in multiple AD forests, a separate third party CA certificate must be used for each forest

• existing certificates that support Exchange Server may need to be modified to include additional domains

• a server running a hybrid deployment service may require configuration for multiple Fully Qualified Domain Names and certificates should be purchased that can accommodate this

9. Microsoft and hybrid deployments

Hybrid deployments are automatically configured to use TLS to encrypt, authenticate and so protect email between Exchange Server and Exchange Online services. The certificate is selected in the HCW and installed on the Exchange Server and client access servers. Mailboxes moved to Exchange Online are automatically provided with antivirus and anti-spam security by Exchange Online Protection. The appropriateness of these services for migrated on-premise email and their continuity with existing on-premise antivirus and anti-spam services should be assessed in line with existing enterprise antivirus policy. An administrator should also take care when using a hybrid deployment that mailbox permissions are consistent across the entire enterprise.

10. Single Sign-On and hybrid deployment

Single Sign-On (SSO) can be implemented with O365 hybrid deployment to provide a seamless user authentication experience. CESG recommend that SSO is employed with AD synchronisation and SSO enabled ahead of using the HCW as hybrid deployment prerequisites. Further information on understanding SSO with hybrid deployments is available in addition to CESG’s deployment security considerations document covering single sign-on and remote access.

11. References

In addition to the web pages referenced above, Microsoft provides documentation to support hybrid deployments:

• Exchange Server 2010 SP3 guidance
• Exchange Server 2013 guidance
• Managing a hybrid deployment (Exchange Server 2010)
• Managing a hybrid deployment (Exchange Server 2013)
• Troubleshooting hybrid deployments (Exchange Server 2013)

Microsoft offer a remote connectivity analyser tool to check external connectivity from an enterprise’s Exchange Server in advance of hybrid deployment rollout.