ASD's Blueprint for Secure Cloud

Migrating from old labelling schemes

Organisations intending to migrate from currently in-place labelling schemes to newer sensitivity label naming, priority ordering or grouping, or to use revised PSPF markings in emails, should consider the following priority outcomes:

• The new scheme is correct in terms of label naming, priority ordering and grouping from a user experience perspective
• Implementing the new scheme incurs minimal impact to business operations
• Data security controls associated with labelling are maintained

The simplest approach can be to delete old sensitivity labels and all label-dependent configurations and start again from first principles. However this may not be possible while ensuring the above outcomes. The following caveats should be considered before proceeding with any label migration activity.

Duplicate label identifiers

Sensitivity labels have several distinct identifiers including a GUID for programmatic use and service integration, a name which is used an administrative identifier, and a display name which is presented for selection by users in applications and workflows. Conflicts can arise when creating labels with the same name, or same display name:

• Purview will prevent the use of duplicate label names
• Purview will only permit the use of duplicate label display names if the labels are created as sub-labels under different parent labels
• Purview will prevent label priority ordering changes to move labels into, or out of, label groups
• Azure Rights Management will prevent the creation of new labels with the same name as those used with archived protection templates (from a deleted label)

Relabelling

It is currently not possible to use conventional Purview mechanisms, like auto-labelling and data loss prevention, to detect the existence of old sensitivity labels and apply new ones. It is possible to manipulate the labels applied to information via a combination of PowerShell or Power Automate flows with Graph API calls, or Defender for Cloud Apps with the apply a label governance action. Whether such an approach should be invested in will largely depend on the extent to which old labels have been used.

Managing old labels

Deleting old sensitivity labels and not relabelling relies on the lifecycle of information for new labels to be applied as users access and modify old labelled information. While this approach may result in some information never getting labels reapplied, the information would appear similarly to other information created pre-Purview. Old-labelled information would still have content markings in place after label deletion.

Leaving old sensitivity labels in place is simple in terms of upfront effort, but may require ongoing maintenance to keep label and related policy configurations maintained. Even though old labels would not be published, they would continue to appear associated with emails, documents and containers; users would need to be made aware of the variation, which could also be used as a prompt to manually relabel information as it’s noticed. Old labels can also have their display name renamed to indicate their deprecated status. Data loss prevention policies and other label-based security mechanisms can also remain in place, continuing to protect information.

Azure Rights Management

Azure Rights Management usage rights associated with old sensitivity labels can add complexity to a decision to relabel information, or to maintain or delete old labels:

• If the intent is to relabel information and the old label usage rights do not permit reprotection, the usage rights may need modification.
• If a label is deleted, the usage rights and protection template associated with that label remain archived in the Azure Information Protection tenant, allowing information associated with the old label to still be accessed. If the archived protection templates are to persist after label deletion, and if usage rights associated with new equivalent labels were ever updated, the old protection templates also require updating to maintain parity.

Label migration plan

The following steps are example of how to migrate from one labelling scheme to another.

Backup old label metadata

The metadata associated with old sensitivity label configurations may be the only links to match dangling label configurations or implement relabelling after a label has been deleted. Before deleting any old labels, back up the old label metadata as well as any Azure Rights Management usage rights and protection template metadata.

Implement the new labelling scheme

1. Create the new labels in accordance with the Blueprint
2. Modify publishing policies to use the new labels
3. Modify auto-labelling policies to use the new labels
4. Modify data loss prevention policies to use the new labels

In the example table below:

• The OFFICIAL Sensitive label can exist as a top-level label and as a sub-label under the OFFICIAL Sensitive (group) parent label, as long as the new label’s name is different, for example OFFICIAL Sensitive v02.
• The old labels pending deletion can have their display names renamed to highlight their status, for example renaming OFFICIAL Sensitive to OFFICIAL Sensitive deprecated (or an equivalent abbreviation).

Migrate old-labelled information to the new labelling scheme

The utility of old sensitivity labels is limited if not associated with any policies. However, depending on the how long the old labels were available to users, they could have been associated with a large number of emails, documents or containers. The options to relabel information vary in complexity and effort depending on where labels have been applied and how extensively they’ve been used. The following steps may assist organisations seeking to migrate old-labelled information to a new labelling scheme.

1. Create an eDiscovery Content search

Before deleting any sensitivity labels, create an eDiscovery Content search using condition builder to specify the labels to search for across your tenant data sources. Download the search exports and analyse the content for where to focus relabelling efforts.

2. Relabel Teams, M365 groups and SharePoint sites

Containers can be relabelled via the Security & Compliance PowerShell using the relabelling-like process documented in Microsoft’s convert classifications for Microsoft 365 groups to sensitivity labels guidance.

3. Relabel emails

Methods to relabel existing email messages do not currently exist. However, considering the primary security mechanisms associated with labelled emails are applied when they’re in transit (not at rest in a mailbox or copied to a file system); and considering that emails associated with deleted labels will be treated as unlabelled (and the user forced to label them when replying or forwarding); the implications of not relabelling email are less significant.

Emails secured with Azure Rights Management are the exception, and should not have their associated protection templates deleted to ensure continued protection.

4. Relabel documents

Relabelling documents in SharePoint and OneDrive requires the use of a protected Graph API for the driveItem: assignSensitivityLabel function.

Relabelling documents stored locally on desktop endpoints (not in OneDrive) can be performed via the Purview Information Protection client, and using the Set-FileLabel command.

5. Repeat the eDiscovery Content search

Ensure that relabelling efforts have been completed to the required degree by redoing the initial eDiscovery Content search.

Delete old label configurations

Delete any policies or rules associated with old sensitivity labels after any relabelling has been completed. After such policies have been deleted, the labels themselves can be deleted.

If relabelling was not performed and a label deleted the information will appear unlabelled, triggering the require users to apply a label to their emails and documents publishing policy setting.

Related information

Security & Governance

• Guidelines for email

Design

• Azure Rights Management
• Email handling
• Data Loss Prevention
• Labelling and classification

Configuration

• Sensitivity labels

References

• Australian Government Email Protective Marking Standard
• Australian Government Protective Security Policy Framework (PSPF)
• Configure usage rights for Azure Information Protection
• driveItem: assignSensitivityLabel
• Microsoft Purview Information Protection client
• Overview of Content search
• Removing and deleting labels
• Set-FileLabel
• Use PowerShell to convert classifications for Microsoft 365 groups to sensitivity labels