Email marking strategies using Microsoft Purview for Australian Government compliance with PSPF
Article
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.
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.
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:
X-Protective-Marking x-header (primary method)
Subject-based marking (auxiliary method 1)
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.
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
Modify subject, remove text that matches: \s*?\[SEC=.*?\] Insert this replacement text: [SEC=PROTECTED, ACCESS=Legal-Privilege] Position: Remove matches and append
Modify subject, remove text that matches: \s*?\[SEC=.*?\] Insert this replacement text: [SEC=PROTECTED, ACCESS=Legislative-Secrecy] Position: Remove matches and append
Modify subject, remove text that matches: \s*?\[SEC=.*?\] Insert this replacement text: [SEC=PROTECTED, CAVEAT=SH:CABINET] Position: Remove matches and append
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.