Email marking strategies using Microsoft Purview for Australian Government compliance with PSPF

This article provides guidance for Australian Government organizations on the use of Microsoft Purview for the marking of email. Its purpose is to demonstrate that Microsoft Purview can integrate with Microsoft Exchange to apply protective markings in alignment with PSPF the Protective Security Policy Framework (PSPF), including PSPF Policy 8 Annex F: Australian Government Email Protective Marking Standard. The purpose of this guidance is to help Australian Government organizations to protect information and increase their information security maturity.

Protective Security Policy Framework (PSPF) Policy 8 Requirement 4 states that information, including email, must be clearly identified using appropriate protective markings:

Requirement	Detail
PSPF Policy 8 Requirement 4: Marking Information (v2018.6)	The originator must clearly identify sensitive and security classified information, including emails, using applicable protective markings by using text-based protective markings to mark sensitive and security classified information (and associated metadata), unless impractical for operational reasons.

Protective markings can be applied in many ways, such as via label content markings, discussed in sensitivity label content marking. However, it's possible for recipients to modify text-based protective markings in their reply emails. PSPF Policy 8 Annex F: Australian Government Email Protective Marking Standard provides extra guidance on the marking of email. Annex F includes marking syntax that can be applied to email subject or email metadata in the form of x-headers.

The following graphic demonstrates the various marking methods available and discussed in this article:

X-Protective-Marking x-headers

By default, a sensitivity label, which is configured within one environment and which has a set of controls configured against it to protect associated information, isn't automatically applied in external environments. Items sent to an external organization have metadata and visual markings applied. It's then up to the receiving organization to ensure that the contained information is adequately protected.

In order to ensure that information is treated appropriately by receiving organizations, it's important to mark items with indicators to assist its security classification to be interpreted. Once interpreted, the item is then brought into the scope the second organizations security controls. Translation of classifications between organizations is achieved for email using Microsoft Purview Data Loss Prevention (DLP) and service-based auto-labeling. DLP stamps emails with markings that service-based auto-labeling (or an equivalent service) interprets at the receiving end:

Email x-headers provide a marking method that is less about user visibility and more about ensuring that systems can interpret markings applied to email. From the perspective of email platforms, x-headers are the most reliable source of information regarding an item's classification as they can't be easily manipulated by users.

To ensure that email-based information is appropriately controlled and protected as it moves between Government organizations, the PSPF x-protective-Marking x-header is used. This x-header is read and interpreted by email platforms for all email entering a Government environment, and used to apply controls appropriate to the sensitivity of the contained information.

Important

Consistent use of x-headers is key to the success of this process as receiving organizations use x-headers to interpret markings and apply relevant controls.

To ensure that x-headers are consistent between organizations, PSPF Policy 8 Annex F: Australian Government Email Protective Marking Standard defines the following x-header configuration:

Requirement	Detail
PSPF Policy 8 Annex F X-Protective-Marking Syntax	X-Protective-Marking: VER=[version], NS=gov.au, SEC=[SecurityClassification], CAVEAT=[CaveatType]:[CaveatValue], EXPIRES=[genDate]\|[event], DOWNTO=[SecurityClassification], ACCESS=[InformationManagementMarker], NOTE=[comment], ORIGIN=[authorEmail]

Components that are commonly configured are:

• VER, which lists the version of the standard that the system is configured to (currently v2018.6).
• NS, which is the domains that the marking is relevant for State Government organizations who are using this guide, the configuration differs. For example, the Victorian Protective Data Security Framework (VPDSF) states that a domain of vic.gov.au is used here.).
• SEC aligns with either a marking or classification (UNOFFICIAL, OFFICIAL, OFFICIAL Sensitive, or PROTECTED).
• CAVEAT is populated if a Caveat such as CABINET is applied to the content.
• ACCESS is populated if an Information Management Marker (IMM) is applied to the content.

Origin header

Within organization, and outbound content

The PSPF Policy 8 Annex F states that the ORIGIN field: 'captures the author's email address so that the person who originally classified the email message is always known. This isn't necessarily the same as that in the RFC5322 from field.'

Important

A common error is to configure the ORIGIN field via a Mail Flow Rule which stamps the sender's address to the origin field of outgoing email. This configuration results in the field changing each time a reply or forward activity occurs. This configuration does not meet the PSPF requirement as the ORIGIN field shouldn't change once set.

External and inbound content

The most important element of the ORIGIN field is the originating entity. PSPF policy 8 defines origin as 'the entity that initially generated the information or received the information from outside the Australian Government.' In order to capture originating entity information in the ORIGIN field, we could use of a generic email address. For example, info@entity.gov.au. This email address is stamped in the origin field of all email generated by an organization, allowing for the intent of the requirements to be met.

If more information on an email's specifics, such as the original sender, recipient, or person who forwarded an email is required, then services like Message trace in Exchange Online and eDiscovery Content search can be used to surface such information.

Use of colon in header fields

RFC 5322: Internet message format and RFC 822: Standard for the format of ARPA internet text messages standards state that the colon special character is to be used as a delimiter between an x-headers field names and field body.

The Microsoft Purview interface within Microsoft 365 services adheres to RFC standards and allow for a colon : and are processed as intended for Australian customers.

Risk of x-header stripping

When Australian Government organizations work with nonenterprise email platforms and clients, the other organization's system may remove x-headers from reply emails. Enterprise email platforms such as Exchange Online and clients such as Outlook, ensure that when users reply to emails, important email metadata, including x-headers are maintained. Other clients, including anonymous email platforms and native mobile device email clients, are likely to remove any email metadata that they don't understand. This impacts both email security and user experience, unless factored into design.

An email sent from a typical Australian Government organization to a non-Microsoft 365 user will have x-protective-marking headers and other Microsoft specific label metadata (such as msip_labels headers) applied. This metadata that can be used to ensure that each email in a conversation inherits the label that was applied to the previous message. When a non-Microsoft 365 user replies to a marked email, their reply can be stripped back to only essential email metadata. The result of this is that the reply email, when received by your organization's email platform, won't be labeled. The user will then be required to select and apply a new label on their reply, manually align with the marking of the original item. This approach creates declassification risks.

Although x-headers are the ideal method of marking emails as they aren't able to be easily modified by recipients, Microsoft recommends that multiple marking methods are configured and used in auto-labeling policies for Australian Government:

1. X-Protective-Marking x-header (primary method)
2. Subject-based marking (auxiliary method 1)
3. Label visual markings to be interpreted by SITs (auxiliary method 2)

When applying multiple marking and auto-labeling approaches, the highest sensitivity label detected in an item applied to the item and/or recommended to the user. This reduces any likelihood of content being mislabeled due to recipient manipulation or header stripping.

Auto-labeling approaches to help mitigate risks relating to header stripping are further discussed in Client-based auto-labeling recommendations for Australian Government and Service-based auto-labeling recommendations for Australian Government.

Applying X-Protective-Marking headers via DLP policy

A DLP policy can be used to apply x-protective-marking headers to email.

New DLP policies can be created from within Microsoft Purview compliance portal. Such policies should be created from a custom policy template and should apply to the Exchange service only. Selecting only this service allows for all of the exchange specific conditions to be visible. If other services are selected, the list will only show conditions that are common to all selected services.

The policy should contain a rule for each sensitivity label that is published to users.

Important

A single DLP policy containing multiple rules that apply x-header and subject markings is recommended rather than multiple DLP policies. A policy achieving these actions for all required labels has been included in example DLP policy applying x-headers and subject markings.

Each rule should be named based on its purpose. For example, a rule name of Apply UNOFFICIAL x-Header. For rules accommodating combinations of markings, label names can exceed the length permitted for DLP rule names. For this reason, truncation is required. In Example DLP Policies to apply x-headers and subject markings the caveat or IMMs have been shortened to account for this.

The rules should have a condition of content contains > sensitivity label and then have the label relevant to the rule selected.

Options to evaluate predicate for message or attachment should be selected as this helps to ensure that the x-headers applied to emails account for higher sensitivity attachments, extending capabilities discussed in label inheritance.

Administrators should be mindful of the fact that x-protective-marking x-headers could contain other data, for example, values for EXPIRES or DOWNTO. Presence of this information is unlikely for many organizations due to its limited use but, if the data exists, it should be maintained. To achieve this, create a condition group using the NOT operand. This ensures that if a header already exists on an item, it isn't overwritten:

Rule actions are configured to set headers. The header value should then align with the x-protective-marking value for the applied label.

Tip

If copying x-header values from a formatted file such as a Word document, some special characters could have been be replaced by an equivalent. Examples of characters that may have been replaced due to formatting include inverted commas or hyphens. The Microsoft Purview interface ensures configuration hygine through form validation. This may cause forms to not accept certain pasted text values. If issues are encountered, retype the special characters using the keyboard rather than depending on pasted values.

Testing X-Protective-Marking headers

DLP policies outlined in this article should be tested within test environments to ensure correctness and alignment with the PSPF framework. Email x-headers can be viewed via most email clients. In Outlook, depending on the client version, headers can be viewed by either opening an email and selecting File > Properties, or opening a message and selecting View > View message properties.

Microsoft Message Header Analyzer is used to view header information, which is located at https://mha.azurewebsites.net/.

PSPF Policy 8 Annex F provides examples, which you can compare to your own configuration.

Subject-based markings

An alternative approach to email marking relies on email subject fields, which can be modified to include a marking at the end of an email subject. For example, 'Test email subject [SEC=PROTECTED]'.

As explained in PSPF Policy 8 Annex F, subject based markings can be easily manipulated during email generation or transport. However, as a mitigation to risk of x-header stripping, subject-based markings help situations where email platforms or clients have removed email metadata. Therefore subject-based marking should be used as an auxiliary method to x-headers.

Requirement

Detail

PSPF Policy 8 - Applying protective markings through metadata

For emails, the preferred approach is for entities to apply protective markings to the internet message header extension, in accordance with the Email Protective Marking Standard at Annex G. This helps with construction and parsing by email gateways and servers, and allows for information handling based on the protective marking. Where an internet message header extension isn't possible, protective markings are placed in the subject field of an email.

Note

Although subject-based marking is less technical than x-header based approaches, it is still a completly valid method of applying markings to email.

Applying subject-based email markings

As with x-headers, subject-based markers are applied via DLP policies. Policies should be created from the custom policy template and apply to the Exchange service only.

Ensure the policy contains a rule for each sensitivity label. An appropriate rule name example is Apply UNOFFICIAL subject marking. As with x-header based rules, rule names are likely to exceed permitted values when combinations of markings are being used. For this reason, the examples in example DLP policies to apply x-headers and subject markings apply truncation to caveat or IMMs names.

These rules need a condition of content contains and then the relevant sensitivity label for the rule. There's no need to apply exceptions for rules applying subject markings.

Rule action should be configured to modify subject.

The modify subject action should be configured with a Regular Expression (RegEx) of \s*?\[SEC=.*?\]. This RegEx checks for and removes values within data within square brackets that starts with [SEC=. It also removes space characters before markings.

Using this RegEx based method to reapply subject markings ensures that duplication of markings doesn't occur (for example, [SEC=UNOFFICIAL] [SEC=UNOFFICIAL]). DLP policies can do this by removing and replacing the subject marking with the value from the source of truth, which in this case is the email's label.

In the Insert this replacement text field, enter text that is used as the subject based marking. It's desirable to prefix the marking applied via replacement text with a space character (for example, ' [SEC=UNOFFICIAL]') as it will ensure that a space is present after the end of the email subject and before the marking. Ensure your RegEx includes detect spaces (\s*?) in the modify subject pattern keeps the experience consistent. Without the RegEx, spaces could easily stack before the marking.

Position of the replacement text should be set to remove matches and append replacement text to subject.

Important

A single DLP policy containing multiple rules that apply x-header and subject markings is recommended rather than multiple DLP policies. A policy achieving these actions for all required labels has been included in example DLP policy applying x-headers and subject markings.

Example DLP Policy to apply x-headers and subject markings

The following DLP policy is intended to apply x-protective-marking x-headers and subject markings to emails.

Policy Name: Add PSPF x-header and subject marking

Applicable Services: Exchange

Rule	Conditions	Actions
UNOFFICIAL append subject	Content Contains Sensitivity Label: UNOFFICIAL	Modify subject, remove text that matches: \s*?\[SEC=.*?\] Insert this replacement text: [SEC=UNOFFICIAL] Position: Remove matches and append
UNOFFICIAL add x-header	Content Contains Sensitivity Label: UNOFFICIAL	Set header:X-Protective-Marking:VER=2018.6, NS=gov.au, SEC=UNOFFICIAL Except if header matches patterns: X-Protective-Marking:SEC=UNOFFICIAL
OFFICIAL append subject	Content Contains Sensitivity Label: OFFICIAL	Modify subject, remove text that matches: \s*?\[SEC=.*?\] Insert this replacement text: [SEC=OFFICIAL] Position: Remove matches and append
OFFICIAL add x-header	Content Contains Sensitivity Label: OFFICIAL	Set header: X-Protective-Marking:VER=2018.6, NS=gov.au, SEC=OFFICIAL Except if header matches patterns: X-Protective-Marking:SEC=OFFICIAL
OFFICIAL Sensitive append subject	Content Contains Sensitivity Label: OFFICIAL Sensitive	Modify subject, remove text that matches: \s*?\[SEC=.*?\] Insert this replacement text: [SEC=OFFICIAL:Sensitive] Position: Remove matches and append
OFFICIAL Sensitive add x-header	Content Contains Sensitivity Label: OFFICIAL Sensitive	Set header: X-Protective-Marking:VER=2018.6, NS=gov.au, SEC=OFFICIAL:Sensitive Except if header matches patterns: X-Protective-Marking:SEC=OFFICIAL[-: ]Sensitive
OFFICIAL Sensitive PP append subject	Content Contains Sensitivity Label: OFFICIAL Sensitive Personal Privacy	Modify subject, remove text that matches: \s*?\[SEC=.*?\] Insert this replacement text: [SEC=OFFICIAL:Sensitive, ACCESS=Personal-Privacy] Position: Remove matches and append
OFFICIAL Sensitive PP add x-header	Content Contains Sensitivity Label: OFFICIAL Sensitive Personal Privacy	Set header:X-Protective-Marking:VER=2018.6, NS=gov.au, SEC=OFFICIAL:Sensitive, ACCESS=Personal-Privacy Except if header matches patterns: X-Protective-Marking:SEC=OFFICIAL[-: ]Sensitive, ACCESS=Personal-Privacy
OFFICIAL Sensitive LP append subject	Content Contains Sensitivity Label: OFFICIAL Sensitive Legal Privilege	Modify subject, remove text that matches: \s*?\[SEC=.*?\] Insert this replacement text: [SEC=OFFICIAL:Sensitive, ACCESS=Legal-Privilege] Position: Remove matches and append
OFFICIAL Sensitive LP add x-header	Content Contains Sensitivity Label: OFFICIAL Sensitive Legal Privilege	Set header: X-Protective-Marking:VER=2018.6, NS=gov.au, SEC=OFFICIAL:Sensitive, ACCESS=Legal-Privilege Except if header matches patterns: X-Protective-Marking:SEC=OFFICIAL[-: ]Sensitive, ACCESS=Legal-Privilege
OFFICIAL Sensitive LS append subject	Content Contains Sensitivity Label: OFFICIAL Sensitive Legislative Secrecy	Modify subject, remove text that matches: \s*?\[SEC=.*?\] Insert this replacement text: [SEC=OFFICIAL:Sensitive, ACCESS=Legislative-Secrecy] Position: Remove matches and append
OFFICIAL Sensitive LS adds x-header	Content Contains Sensitivity Label: OFFICIAL Sensitive Legislative Secrecy	Set header: X-Protective-Marking:VER=2018.6, NS=gov.au, SEC=OFFICIAL:Sensitive, ACCESS=Legislative-Secrecy Except if header matches patterns: X-Protective-Marking: SEC=OFFICIAL[-: ]Sensitive, ACCESS=Legislative-Secrecy
OFFICIAL Sensitive NC append subject	Content Contains Sensitivity Label: OFFICIAL Sensitive NATIONAL CABINET	Modify subject, remove text that matches: \s*?\[SEC=.*?\] Insert this replacement text: [SEC=OFFICIAL:Sensitive, CAVEAT=SH:NATIONAL-CABINET] Position: Remove matches and append
OFFICIAL Sensitive NC add x-header	Content Contains Sensitivity Label: OFFICIAL Sensitive NATIONAL CABINET	Set header: X-Protective-Marking:VER=2018.6, NS=gov.au, SEC=OFFICIAL:Sensitive, CAVEAT=SH:NATIONAL-CABINET Except if header matches patterns: X-Protective-Marking:SEC=OFFICIAL[-: ]Sensitive, CAVEAT=SH[-: ]NATIONAL-CABINET
PROTECTED append subject	Content Contains Sensitivity Label: PROTECTED	Modify subject, remove text that matches: \s*?\[SEC=.*?\] Insert this replacement text: [SEC=PROTECTED] Position: Remove matches and append
PROTECTED add x-header	Content Contains Sensitivity Label: PROTECTED	Set header: X-Protective-Marking:VER=2018.6, NS=gov.au, SEC=PROTECTED Except if header matches patterns: X-Protective-Marking:SEC=PROTECTED
PROTECTED PP append subject	Content Contains Sensitivity Label: PROTECTED Personal Privacy	Modify subject, remove text that matches: \s*?\[SEC=.*?\] Insert this replacement text: [SEC=PROTECTED, ACCESS=Personal-Privacy] Position: Remove matches and append
PROTECTED PP add x-header	Content Contains Sensitivity Label: PROTECTED Personal Privacy	Set header: X-Protective-Marking:VER=2018.6, NS=gov.au, SEC=PROTECTED, ACCESS=Personal-Privacy Except if header matches patterns: X-Protective-Marking:SEC=PROTECTED, ACCESS=Personal-Privacy
PROTECTED LP append subject	Content Contains Sensitivity Label: PROTECTED Legal Privilege	Modify subject, remove text that matches: \s*?\[SEC=.*?\] Insert this replacement text: [SEC=PROTECTED, ACCESS=Legal-Privilege] Position: Remove matches and append
PROTECTED LP add x-header	Content Contains Sensitivity Label: PROTECTED Legal Privilege	Set header: X-Protective-Marking:VER=2018.6, NS=gov.au, SEC=PROTECTED, ACCESS=Legal-Privilege Except if header matches patterns: X-Protective-Marking:SEC=PROTECTED, ACCESS=Legal-Privilege
PROTECTED LS append subject	Content Contains Sensitivity Label: PROTECTED Legislative Secrecy	Modify subject, remove text that matches: \s*?\[SEC=.*?\] Insert this replacement text: [SEC=PROTECTED, ACCESS=Legislative-Secrecy] Position: Remove matches and append
PROTECTED LS add x-header	Content Contains Sensitivity Label: PROTECTED Legislative Secrecy	Set header: X-Protective-Marking:VER=2018.6, NS=gov.au, SEC=PROTECTED, ACCESS=Legislative-Secrecy Except if header matches patterns: X-Protective-Marking: SEC=PROTECTED, ACCESS=Legislative-Secrecy
PROTECTED CABINET append subject	Content Contains Sensitivity Label: PROTECTED CABINET	Modify subject, remove text that matches: \s*?\[SEC=.*?\] Insert this replacement text: [SEC=PROTECTED, CAVEAT=SH:CABINET] Position: Remove matches and append
PROTECTED CABINET add x-header	Content Contains Sensitivity Label: PROTECTED CABINET	Set header: X-Protective-Marking:VER=2018.6, NS=gov.au, SEC=PROTECTED, CAVEAT=SH:CABINET Except if header matches patterns: X-Protective-Marking:SEC=PROTECTED, CAVEAT=SH[-: ]CABINET
PROTECTED NC append subject	Content Contains Sensitivity Label: PROTECTED NATIONAL CABINET	Modify subject, remove text that matches: \s*?\[SEC=.*?\] Insert this replacement text: [SEC=PROTECTED, CAVEAT=SH:NATIONAL-CABINET] Position: Remove matches and append
PROTECTED NC add x-header	Content Contains Sensitivity Label: PROTECTED NATIONAL CABINET	Set header: X-Protective-Marking:VER=2018.6, NS=gov.au, SEC=PROTECTED, CAVEAT=SH:NATIONAL-CABINET Except if header matches patterns: X-Protective-Marking:SEC=PROTECTED, CAVEAT=SH[-: ]NATIONAL-CABINET

Note

The previous DLP rules use [-: ] in RegEx which allows for either hyphen, colon or a space to be matched. This is intended to accommodate for organizations are sending you information, but due to lower compliance maturity or outdated configuration, can't apply colon characters to x-headers.