Security & Efficacy - Securing UK Government Email Guide

This guide shows you how to implement the UK government's secure email guidance using Mimecast's services. Refer to/visit the Government's website for more information Securing Government Email. Ensure that your supplier can configure email services securely.

In summary, to improve email security and comply with government network policy, use:

• • • Encryption: Encrypt email in transit over the internet between government organizations using Transport Layer Security (TLS) version 1.2 or later.
    • Anti-spoofing: Put technical and business policies in place to check inbound and outbound government email using Domain Message Authentication Reporting and Conformance (DMARC), Sender Policy Framework (SPF), and Domain-Keys Identified Mail (DKIM). This ensures you're protected against senders yet to implement DMARC or have configured relaxed DMARC policies.
    • Assessment: Pass an assessment and commit to ensuring your email service is configured and run securely.

Organizations using cloud-based or internet-connected email services must follow this configuration guidance. Organizations using Public Services Network (PSN)-based email services are strongly recommended to follow this configuration guidance.

Encrypting Email Traffic Using TLS

Mimecast allows administrators to secure the communication channel used to transmit messages over the internet. This is achieved via the creation of the following policies:

• • • Secure Receipt Policies can be used to apply TLS to connections used to:
      • Send outbound email from a Mimecast customer.
      • Send inbound email from an external sender.
      • Enforce TLS connections when receiving messages.

• • • Secure Delivery Policies are applied to connections used to deliver messages from Mimecast. Specifically to:
      • Send inbound email from Mimecast to your organization.
      • Send outbound emails from Mimecast to external recipients.
      • Enforce TLS connections when receiving messages.

Secure Delivery policies must be configured to "Enforce TLS" and use the "Strict" encryption mode. This ensures that self-signed certificates are not accepted. See the SSL Certificates page for further information regarding the certificates that Mimecast supports.

These policies can be configured to be applied to the following scopes of users:

• • • Inbound, outbound, or all connections.
    • Specific domains (either by individual policy or using address groups).

If you don't want to reject a connection due to a TLS handshake failure, you can use Secure Messaging to send messages securely. This can be configured by using the Enforces TLS - Fallback to Secure Messaging value in the Select Option field of a Secure Delivery Policy

Securing Email Domains Using DNS Authentication Policies

DNS Authentication combines three industry-standard email authentication technologies: SPF, DKIM, and DMARC. These allow domain owners to control who sends on behalf of their domains, as well as validate the authenticity of inbound messages, thereby minimizing the volume of unwanted messages reaching end users.

Inbound DNS Authentication Policies

DNS Authentication: Inbound check policies allow you to prevent unwanted and potentially harmful messages from reaching users. They also protect the reputation of the domains under your control. When enabled, inbound DNS Authentication checks are performed against all messages regardless of any Auto Allow or Permitted Sender entries being present.

The following checks can be enabled in DNS Authentication - Inbound policies:

• • • SPF: You must include the Mimecast IP ranges in the SPF records for your domains. This ensures you don't experience email delivery disruption due to SPF failures for outbound mail flow. The example below is a relaxed SPF record:

      "v=spf1 include:_netblocks.mimecast.com ~all"    

See the Connect Application: Implementing SPF for Outbound Email Delivery page for examples of what an SPF record must look like for messages being sent outbound via Mimecast.

• • • DKIM: This requires a public DKIM key to be published in a TXT record in the DNS record for a particular domain by the domain owner.
    • DMARC: This requires a public DKIM key to be published in a TXT record in the DNS record for a particular domain by the domain owner. An example of a basic DMARC DNS Record is below that is configured not to apply an action when a DMARC check returns a failure result. However, failure reports are sent to the listed email recipient for review.

      v=DMARC1; p=none; rua=mailto:[e-mail]

Inbound DMARC checks must be configured to Reject any messages that result in a DMARC failure.

DMARC Reporting is currently not offered by Mimecast. While it is highly desirable, it doesn't stop you from successfully implementing the government's secure email guidance.

Outbound DNS Authentication Policies (DKIM Message Signing)

Outbound DKIM message signing is used to secure outbound emails leaving an organization via the use of special cryptographic message header entries. This enables the recipient's mail server to decrypt the header entry to determine if the message has been manipulated during transit. This is achieved by generating a public key entry via a DNS Authentication Outbound Signing Definition. This value is then inserted into the DNS Records of the domain you wish to secure. After which Mimecast will validate the DNS Record to ensure all is correct.

Here's an example of a DKIM DNS Record:

Mimecast-DKIM.example 86400   IN   TXT   "v=DKIM1\; k=rsa\; p=MIGg0TJUCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDMh5eyPRU0FRElhlG0S3PycQhKT7240KgVG/6Cs5cItlujmSfVJLjKz31b8gZhgbyrycVCgGeUgtkxaO7aCZJevl8I/rpbUciVHtZTarHwJ+LnGTH6r0sDf9yddnvYQypltKzmIzg+/nTR6/wtgTjJWJ19V3uyUTSdiL18ceKwlQIDAQAB"

We recommend that outbound message signing using DKIM is performed by the Mimecast Gateway rather than the sending mail server. This is because changes made to a message (e.g., adding stationery or disclaimers) can cause DKIM checks to fail.

Restricting TLS and Cipher Versions

Legislation mandated by National Cyber Security Centre (NCSC) means all public sector organizations must enforce at least TLS 1.2 or greater and use a specific set of ciphers for inbound email communication. See the NCSC page on Using TLS to protect data for more information.

To support the standards outlined by the NCSC, Mimecast offers the ability to restrict the versions of TLS that our MTAs accept during TLS negotiation to TLS 1.2 or greater. If a sender attempts to email a customer that has migrated to these hostnames using a TLS version lower than TLS 1.2 or using ciphers that are classed as insecure, the connection attempt is rejected.

Mimecast current only supports TLS 1.2 on the PSC hostnames.

To enforce compliance with the guidance outlined by the NCSC, the following steps must be taken:

1. Change your MX records to use the "eu-smtp-inbound-psc-1.mimecast.com" and "eu-smtp-inbound- psc-2.mimecast.com" domains rather than the default inbound Mimecast hostnames of "eu-smtp- inbound-1.mimecast.com" and "eu-smtp-inbound-2.mimecast.com". These domains enforce the updated restrictions.
2. Update the following policies to use the following configuration:

• • • Secure Delivery: Set the SSL Mode in the definition to a value of "NCSC Compliance". This supports compliance of the UK's National Cyber Security Centre (NCSC) standards regarding securing email communication using TLS. See the Configuring Secure Delivery Definitions and Policies page for full details.
    • Secure Receipt: Set the Select Option in the policy to a value of "TLS 1.2 or Greater + NCSC". The connection must be encrypted using TLS 1.2 or greater and using encryption standards that conform to the UK's National Cyber Security Centre's (NCSC) guidance for securing email. If encryption can't be negotiated, the message is not accepted by Mimecast. See the Configuring Secure Receipt Policies for full information.

See Also...

• • • TLS / SSL Cipher Suites