Deploying sensitivity labels with label policies for Australian Government compliance with PSPF
This article provides guidance for Australian Government organizations on Microsoft Purview sensitivity label policy configuration. Its purpose is to demonstrate how label policies can be configured to best align with requirements outlined in the Protective Security Policy Framework (PSPF) and Information Security Manual (ISM).
For sensitivity labels to be selectable by users for application to items, they need to be published via label policies. Label policies are configured within the Microsoft Purview portal under the information protection menu.
For step-by-step instructions on the process of creating a sensitivity label, see creating a sensitivity label.
Organizations with more granular requirements need extra policies. For example, an organization who wants their PROTECTED label and associated sublabels published to a subset of users, requires another policy to achieve this. A policy named protected label policy could be created, which has only the PROTECTED labels selected. The policy can then be published to a protected users group.
Important
Restricting the ability to apply a label doesn't prevent access to information that has the label applied. To apply access restriction in concert with the label policy, configuration including Data Loss Prevention (DLP), authentication context and label encryption must be applied.
Label policy settings
Sensitivity label policies contain various policy settings, which control the behavior of the sensitivity label-aware clients. These settings are important to allowing Australian Government organizations to meet some key requirements.
Default label
The Default label option tells Microsoft 365 to automatically apply the selected label to items by default. To meet Australian Government PSPF and ISM requirements, the default label settings be set to none.
| Requirement | Detail |
|---|---|
| PSPF Policy 8, Requirement 2 (Core Requirement) (v2018.6) | Assessing sensitive and security classified information: ... To decide which security classification to apply, the originator must: i. Assess the value, importance, or sensitivity of official information by considering the potential damage to government, the national interest, organizations, or individuals, that would arise if the information’s confidentiality was compromised... ii. Set the security classification at the lowest reasonable level. |
| ISM-0271 (June 2024) | Protective marking tools do not automatically insert protective markings into emails. |
Label change justification
For Australian Government organizations, Microsoft recommends that label change justification is enabled on all label policies.
For most organizations, information sensitivity can change over time, examples include embargoed information, media releases, and holding lines. Label change justification triggers in the event when a user attempts to remove or lower an applied label. This policy setting requires users to provide a reason for the change:
All label changes and their justification responses are recorded in the audit log and can be viewed by administrators in Microsoft Purview Activity Explorer.
Label change alerts
Label changes can be easily configured to alert in Microsoft Sentinel and other Security Information and Event Managements (SIEM).
Label alerts in government for all changes could cause unnecessary 'noise,' which can obfuscate alerts requiring further investigation. The following example demonstrates this configuration in a Government setting.
Label change justification don't automatically trigger for changes between sublabels. If using a label taxonomy similar to the configuration provided in this article, users can add or remove an Information Management Marker (IMM) without needing to justify the action. However, these label changes are recorded in the audit log.
Government organizations should consider label change justification retention requirements and configure audit log retention policies in line with these. More information on the audit log and options for log retention can be found in audit log.
Reclassification considerations
Label change justification is a feature where available options do differ from the intent of Government requirements. The PSPF states that the originator is defined the entity that initially generated or received the information, must remain responsible for controlling its declassification or reclassification:
| Requirement | Detail |
|---|---|
| PSPF Policy 8 Requirement 3 - Declassification (v2018.6) | The originator must remain responsible for controlling the sanitization, reclassification, or declassification of the information. An entity must not remove or change information's classification without the originator’s approval. |
In addition, the ISM-1089 states that:
| Requirement | Detail |
|---|---|
| ISM-1089 (March 2023) | Protective marking tools don't allow users replying to or forwarding emails to select protective markings lower than previously used. |
The approach used in Microsoft Purview is one of 'trust but verify,' which allows users with permission to edit items and to adjust the label applied to those items. Label change justification provides monitoring and accountability for any changes.
Those considering PSPF reclassification requirements in line with Microsoft's 'trust but verify' approach should be aware of the following available options.
Policy-based approach
Microsoft recommends Australian Government organizations lead with their own organizational policy-based controls as the primary method of meeting declassification requirements. Additionally, Microsoft recommends reinforcing policy-based controls with monitoring and alerting to detect inappropriate patterns. This is because the configuration prevents the changing of items. The consequence of 'locking' label result effects users and administrators, particularly when there's a change. For example, the 'locking' of a label on an item shared by an organization may require the use of encryption, which could impact on other services such as records management systems. These permissions may also need to be tied to a user's domain, which could be impacted by Machinery of Government (MoG) changes.
When Government organizations are considering the options available, it may be worth remembering that PSPF includes both a scale of maturity and categories of core and supporting requirements. Organizations need to make their own decisions regarding the importance of this supporting requirement to meeting their PSPF objectives and weigh the requirement against:
- usability
- potential user impact
- impact to overall PSPF maturity
- potential of MoG
DLP based approach
This approach uses extra Microsoft 365 capabilities that are layered with Microsoft Purview to mitigate risks relating to the exfiltration of information. An example of this is where DLP is used to block sensitive information from leaving the organization. Items can be identified as sensitive primarily based on their applied label but also based on the information that they contain. Implementing a second layer of DLP that focuses on content rather than only the label reduces malicious user's ability to exfiltrate information after lowering or removing a label. For more information on this layered approach, see preventing inappropriate distribution of security classified information and limiting distribution of sensitive information. These capabilities can also be extended to devices via Endpoint DLP and extended to other cloud applications via Defender for Cloud Apps.
Organizations can use DLP to identify and address declassification. An example of this is where the Sensitive Information Type (SIT) is used to identify 'SEC=OFFICIAL:Sensitive' in a subject marking but the email conversation was labeled as OFFICIAL. In the conversations body, a higher sensitivity marking is identified by DLP, so conversation can be blocked or directed to security teams for further action. An example of an approach that assesses markings applied to items rather than sensitivity label can be seen in Controlling email of marked information via DLP.
User-risk based approach
Organizations can extend DLP controls by correlating DLP information with a range of user signals that may indicate patterns of malicious behavior. This capability is made available through Microsoft Purview Insider Risk Management (IRM).
IRM alerts administrators users who repeatedly attempt to exfiltrate information as 'risky' and allow for security teams to intervene. This tool has the ability to ingest HR data feeds and correlate data exfiltration activities with HR signals, such as pending contract end date. This capability signals to administrators users with malicious intent can be identified and dealt with promptly, removing risk of malicious declassification and exfiltration.
To build on this even further, Adaptive Protection features can be enabled in IRM, which can automatically restrict risky user's access and ability to exfiltrate labeled information following a risk event. This can help to secure information by implementing controls immediately rather than waiting for security teams to act on alerting.
With information being protected by a layered approach, rigid reclassification restrictions is only needed to those records specified under the Archives Act with label locking for specified Archives Act Commonwealth records.
Preventing reclassification changes
There are two options for preventing reclassification useful for different use case requirements.
Encryption-based approach
Another option for preventing label changes is to make use of label-based encryption along with permissions that restrict user ability to modify item properties. Co-owner permissions permit property changes, including to the applied label, while co-author permissions allow for items to be edited but not their properties. Such a configuration would need to be backed by a group structure to support the allocation of such permissions to those that require them. This configuration would also need to consider the other aspects to label encryption that are discussed in sensitivity label encryption.
For more information on the required Azure Rights Management permissions to support this, see Configure usage rights for Azure Information Protection (AIP).
Label 'lock' approach
Section 24 and Section 26 of the Archives Act prohibits the disposal or alteration of certain Commonwealth records types. Label changes are metadata to a record and can constitute alteration of that record. To prohibit label changes, organizations can implement retention labels that utilize Microsoft Purview Records Management features to 'lock' items in a state. Once locked, items and their associated sensitivity label can't be changed, preventing reclassification. Configuring Microsoft 365 in such a manner helps organizations to meet both PSPF and Archive Act requirements for those Commonwealth records types.
For more information on preventing changes to items via records labels, see declare records by using retention labels.
Mandatory labeling
Label policies provide the ability to require users to select a label for documents and emails. This setting prompts users to select a label whenever they:
- Save a new item (file or email),
- Attempt to send an unlabeled email, or
- Change an item, which doesn’t already have a label applied.
This setting ensures that all items have protective markings and other associated controls applied.
| Requirement | Detail |
|---|---|
| PSPF Policy 8, Requirement 1 (Core Requirement) - Identifying information holdings (v2018.6) | The originator must determine whether information being generated is official information (intended for use as an official record) and whether that information is sensitive or security classified. |
| PSPF Policy 8, Requirement 2 (Core Requirement) - Assess the sensitivity and security classification of information holdings (v2018.6) | To decide which security classification to apply, the originator must: i. assess the value, importance, or sensitivity of official information by considering the potential damage to government, the national interest, organizations, or individuals, that would arise if the information’s confidentiality was compromised ... ii. set the security classification at the lowest reasonable level. |
Tip
While the mandatory labeling setting ensures that items have labels applied, it is recommended that client-based auto-labeling recommendations and configured and enabled to guide users on accurate label application. More information on this capability can be found in the Client-based Auto-labeling article.
Label inheritance
The label inheritance setting allows for emails to inherit the sensitivity of their attachments. This comes into effect if an item with a higher sensitivity is attached to an email with a lower sensitivity label applied. This setting helps to ensure that highly sensitive items aren't inappropriately disclosed via lower sensitivity emails.
As with all auto-labeling processes, automation won't override a manually applied label. To obtain most benefit, Australian Government organizations should select both options. Selecting both options allows for newly created items to inherit attachment sensitivity. In situations where a user has already applied a label, the second option comes into effect and recommend that the email's sensitivity is increased to match.
This setting aligns with the following requirements:
| Requirement | Detail |
|---|---|
| ISM-0270 (June 2024) | Protective markings are applied to emails and reflect the highest sensitivity or classification of the subject, body and attachments. |
| ISM-0271 (June 2024) | Protective marking tools do not automatically insert protective markings into emails. |
Label inheritance helps ensure that:
- Any mail-flow or DLP related controls that are tied to the email’s label (for example, those discussed in preventing email distribution of classified information) is applied based on the email's attachments.
- If the inherited label includes any advanced controls, such as label encryption, the email has these controls applied (as discussed in Sensitivity label encryption).
Custom help page
The custom help page option allows organizations to provide a link via a 'learn more' option displayed at the bottom of the label menu. The user is directed to the URL of a site providing information on how to correctly apply sensitivity labels and inform users of their marking or classification obligations.
Along with label tooltips, the 'learn more' website is be used by staff when determining which label is most appropriate for an item. This aligns with PSPF Policy 8 Requirement 2, as it assists users in their assessment of sensitive and security classified information.
| Requirement | Detail |
|---|---|
| PSPF Policy 8, Requirement 2 (Core Requirement): Assessing security classified information (v2018.6) | To decide which security classification to apply, the originator must: i. assess the value, importance, or sensitivity of official information by considering the potential damage to government, the national interest, organizations, or individuals, that would arise if the information’s confidentiality was compromised ... ii. set the security classification at the lowest reasonable level. |
Organizations typically make use of a staff intranet or similar location to publish content relevant to classification requirements and processes. This same site may be an appropriate target for this 'Learn More' link. There are other uses for such a site, which is further discussed in Data out-of-place alerting.
Policy ordering
As mentioned at the start of this article, multiple label policies can be configured to deploy different sets of labels or different policy options to group of users. In these scenarios, like with labels, policy ordering is important. Users within the scope of multiple policies receive all labels that have been assigned to them via their various policies, but they'll only receive settings from the policy with the highest order.
Example label policies
The following label example demonstrates a typical policy configuration for Australian Government organizations. The protected policy below is intended to demonstrate how a set of labels can be published only to a subset of users and won't be required by every organization:
| Policy name | Order | Labels published | Published to |
|---|---|---|---|
| All User Policy | 0 | - UNOFFICIAL - OFFICIAL - OFFICIAL: Sensitive - OFFICIAL: Sensitive Personal Privacy - OFFICIAL: Sensitive Legal Privilege - OFFICIAL: Sensitive Legislative Secrecy - OFFICIAL: Sensitive NATIONAL CABINET |
All Users |
| Test Policy | 1 | All | Test user accounts |
| Protected Policy | 2 | - PROTECTED - PROTECTED Personal-Privacy - PROTECTED Legal-Privilege - PROTECTED Legislative-Secrecy - PROTECTED CABINET - PROTECTED NATIONAL CABINET |
'Protected Users' Microsoft 365 group |
These policies can be configured with the following settings, which best align with Australian Government requirements:
| Policy option | Setting |
|---|---|
| Users must provide a justification to remove a label or lower its classification. | ON |
| Require users to apply a label to their emails and documents. | ON |
| Require users to apply a label to their Power BI content. | ON |
| Provide users with a link to a custom help page. | insert intranet-based help site URL |
| Default label for documents. | None |
| Default label for emails. | None |
| Inherit label from attachments. - Email inherits highest priority label from attachments. - Recommend users apply the attachment's label instead of automatically applying it. |
ON ON |
| Default label for meetings and calendar events. | None |
| Require users to apply a label to their meetings and calendar events. | ON |
| Default label for sites and groups. | None |
| Require users to apply a label to their groups or sites. | ON |
| Default label for Power BI. | None |
Label policy changes
Staff responsible for managing changes to label or label policy configuration should note that changes take a maximum of 24 hours for any changes to be deployed to users and to sync through to client devices. This should be factored into testing and technical change windows.
Tip
Where a configuration needs to be tested quickly by users, those users can sign out of their Microsoft 365 Apps Outlook or Office client and then sign back in. As the client signs in it will receive a newer copy of the allocated policies, speeding the label or policy deployment process.