Requiring TLS encryption for sensitive email transmission for Australian Government compliance with PSPF

This article provides guidance for Australian Government organizations on the use of Transport Layer Security (TLS) to help protect security classified information. Its purpose is to help government organizations to understand their encryption requirements as well as how Microsoft 365 can be configured to assist with this. Advice in this article has been written to best align with requirements outlined in the Protective Security Policy Framework (PSPF) Policy 8: Sensitive and classified information and the Information Security Manual (ISM).

TLS is a type of encryption that can be used to ensure that data can't be intercepted during transmission. By default, Exchange Online always uses opportunistic TLS. Opportunistic TLS means Exchange Online always tries to encrypt connections with the most secure version of TLS first, then works its way down the list of TLS ciphers until it finds one on which both parties can agree. Importantly, TLS is applied at the mail server and applies to all email sent from the server, rather than at the user or client level. For more information on TLS in Microsoft 365, see how Exchange Online uses TLS to secure email connections..

The default setting of TLS in Exchange Online meets the Information Security Manual (ISM) requirements.

Requirement Detail
ISM-0572 (June 2024) Opportunistic TLS encryption is enabled on email servers that make incoming or outgoing email connections over public network infrastructure.

Opportunistic TLS configuration is also discussed in ASD's Blueprint for Secure Cloud.

Keeping email encryption optional for highly sensitive information increases risks of information loss. A compromised or poorly managed environment within a cluster of Government or external partner organizations could lead to sensitive information being sent across the public internet in plain text. Opportunistic TLS ensures that messages are encrypted to highest level possible such that the intended receiver is able to receive the information, as intended. Government organizations have a transport topology that makes use of connectors that require TLS for transmission of all items between Government organizations.

Such configurations help to ensure that all email-based communication between a fixed list of organizations is encrypted. However, it doesn't allow for TLS encryption to be required for recipients outside of the predefined list of organizations. For example, consider a contracted firm such as a lawyer, who requires sensitive information to be sent to them. Being outside of the fixed list of domains that require TLS could lead to items being sent insecurely.

The Exchange Online Outbound Message Report provides reporting on the percentage of emails being sent with and without TLS encryption. For more information on the outbound message reports, see messages reports in Exchange Online.

Organizations with a low percentage of unencrypted email might consider a forced TLS approach for all outgoing mail. This configuration may prevent nonsensitive email from reaching its intended destination when an email is sent outside of the fixed list of domains (for example, UNOFFICIAL emails). To align with Protective Security Policy Framework (PSPF) Policy 8 Annex A (summarized in encryption requirements) encryption is required for transmission of 'OFFICIAL: Sensitive' and 'PROTECTED' email. TLS is required at these levels.

Note

For many Government organizations, particularly the service based agencies, the bulk of their information falls into OFFICIAL category and requiring TLS for this volume of email may have significant impacts on business with individuals and organizations who don't have TLS. A risk based approach, tempered to the business need is recommended for forced TLS at this level versus opportunistic TLS.

To require TLS encryption for higher sensitivity email, an Exchange online mail flow rule can be used. This rule inspects the x-headers of items being sent. Where items are identified as having certain sensitivity labels applied, applies an action, which requires TLS encryption for transmission of the item.

To construct these mail flow rules, we need to understand how labels are applied to email. When a label is applied, it can be seen in the email's x-headers. The header containing label information is named msip_labels and includes a label ID, which corresponds to the label applied to an item.

Mail flow rules can check the msip_labels header to see if any relevant labels are applied via their label ID, or GUID.

In order to obtain the label Globally Unique Identifiers (GUIDs) for an environment, security, and compliance PowerShell can be used. The command required to view an environment's labels and associated GUIDs is:

Get-label | select displayname,guid

The PowerShell command returns a list of sensitivity labels along with their label GUIDs.

Note

Label GUIDs are specific to a single Microsoft 365 tenant only. Two tenants with the same label naming will not share the same GUID.

Once obtained, these label names and GUIDs should be recorded so you can use them for Exchange mail flow rule configuration.

Administrators need to use the Exchange Online Admin Center to create rules that look for the msip_labels header. A single mail flow rule can be used to check for multiple label GUIDs. Ensure you include Enabled=True after the label GUID when creating the rule. The following example checks for the six variations of PROTECTED labels (including Information Management Markers and Caveats) within an environment.

Example mail flow rule for requiring TLS

This mail flow rule is intended to prevent security classified or sensitive email from being transmitted over the internet without TLS encryption.

Rule Name Apply this rule if Do the following
Require TLS for PROTECTED email Apply this rule if the recipient is internal/external:
- Outside the organization
AND
The message headers…
Include any of these words:

Header: msip_labels
Words:
- PROTECTED GUID
- PROTECTED Personal Privacy GUID
- PROTECTED Legal Privilege GUID
- PROTECTED Legislative Secrecy GUID
- PROTECTED CABINET GUID
- PROTECTED NATIONAL CABINET GUID
- Modify the message security
- Require TLS encryption

Note

Before implementing such rules, also consider your strategy for monitoring rule impact and actioning items that are delayed or blocked due to the receiving organization not supporting TLS.