Edit

Share via

Sensitivity label taxonomy for Australian Government compliance with PSPF

  • Article

This article provides guidance for Australian Government organizations on required sensitivity labels to align with data security classifications. Its purpose is to assist organizations to decide on an appropriate sensitivity label taxonomy to deploy to their Microsoft 365 environments. Advice in this article has been written to align with Protective Security Policy Framework (PSPF) Policy 8: Sensitive and classified information.

Australian Government organizations need to determine an appropriate sensitivity label taxonomy before deploying the capability. Required labels vary between organizations depending on the types of information that they work with.

Standard configuration

Typical label requirements include a combination of security classifications, often combined with an Information Management Marker (IMM) and/or caveats. Organizations with high compliance maturity are also likely to include labels to cater for various data security requirements. For example, labels that apply Azure Rights Management encryption to ensure that only authorized users can access items.

The following example demonstrates basic markings for Australian Government organization:

Marking or classification Information Management Marker Caveat
UNOFFICIAL
OFFICIAL
OFFICIAL: Sensitive
PROTECTED		 Personal Privacy
Legal Privilege
Legislative Secrecy		 CABINET
NATIONAL CABINET

Labels are singular and only one label can be applied to an item or location. Any required combination of these three items need to be assembled into a singular label to meet requirements. For example, if an item is required to be classified as PROTECTED, and it also contains CABINET information, then a single label containing these elements needs to be provided; PROTECTED CABINET.

The following example demonstrates basic labels for Australian Government organizations. This list makes use of a combination of parent labels (categories) and sublabels:

  • UNOFFICIAL
  • OFFICIAL
  • OFFICIAL Sensitive (Category)
    • OFFICIAL Sensitive
    • OFFICIAL Sensitive Personal Privacy
    • OFFICIAL Sensitive Legal Privilege
    • OFFICIAL Sensitive Legislative Secrecy
    • OFFICIAL Sensitive NATIONAL CABINET
  • PROTECTED (Category)
    • PROTECTED
    • PROTECTED Personal Privacy
    • PROTECTED Legal Privilege
    • PROTECTED Legislative Secrecy
    • PROTECTED CABINET

Government organizations with more complex requirements need extra labels. The maximum number of labels an organization wants to deploy is more relevant to usability constraints than technical limitations. However, there's a limit of 500 labels that can be created per organization.

The use of sublabels in the previous list is intended to improve user experience but also has some beneficial impacts to label behavior. For example, label change justification won't trigger when a user changes between sub-labels. This allows users to apply different IMMs, caveats, or security controls and only trigger justification if they attempt to lower the applied security classification by moving outside of a label category.

Organizations that work at OFFICIAL

Australian Government organizations are able to configure their Microsoft 365 environments to store information up to PROTECTED.

For Microsoft Infosec Registered Assessors Program (IRAP) documentation, see the Microsoft Service Trust Portal.

Many Australian Government organizations have purposefully limited the maximum sensitivity level for data that they allowed to be stored within the tenancy, which in turn reduces other requirements. For example, staff clearances can be maintained at a lower level sufficient for the data held.

Use of multiple IMMs

Some Australian Government organisations make use of classification taxonomies that allow for the application of more than one Information Management Marker (IMM) to each item. For example: 'OFFICIAL: Sensitive Legislative Secrecy Personal Privacy.' While this type of configuration can be achieved, requirements should be considered, in particular:

  • IMMs are derived from the Australian Government Recordkeeping Metadata Standard (AGRkMS) where it specifies that a single IMM value can be applied.
  • Protective Security Policy Framework (PSPF) Policy 8 states that IMMs are optional.

Microsoft's recommendation is to keep things as simple as possible. Only deploying labels that your organization actually needs will improve the user experience as users have fewer labels to navigate. Having a smaller taxonomy also eases administration as there's less configuration to maintain, particularly across DLP and auto-labeling policies.

Organizations considering the use of multiple IMM combinations should consider the following potential complications:

  • Auto-labeling complications: Items with multiple IMMs applied are more difficult to match via auto-labeling as expressions to interpret subject markings or x-headers need to be able to accommodate them via the policies discussed in service-based auto-labeling recommendations.
  • Subject length: Email clients will often truncate or make it difficult to view long email subjects. In situations where multiple markings have been applied to a single email, users may be unaware of IMM or Caveat markings as they aren't visible.
  • X-header length: X-Protective-Marking x-headers, which are discussed in marking strategies are used to apply classification metadata to email. The amount of metadata that be applied to an email is dependent of several factors, including the email client being used. Organizations applying multiple IMMs to emails are likely to exceed the permitted x-header length, resulting in some classification metadata being truncated.

If multiple labels are required, ensure that elements are ordered from least to most important to your organization. For example:

  1. Security classification
  2. Caveat (if necessary)
  3. Most sensitive IMM
  4. Less sensitive IMM

Organizations that work at PROTECTED

Microsoft 365 is rated to be able to hold data up to and including PROTECTED.

For Microsoft Infosec Registered Assessors Program (IRAP) documentation, see the Microsoft Service Trust Portal.

Labels for information beyond PROTECTED level

Organizations that hold SECRET and above data need to utilize an on-premises enclave. The organization must implement network separation and a wide range of other measures to stop this information from leaving the enclave. If an item containing a SECRET marking appeared in a Microsoft 365 location, then the occurrence requires the organizations IT Security Advisor (ITSA) to perform data spill management. ASD provides guidance on how to manage remediation activities, see ASD data spill management guide

Government organizations should implement labels for information that shouldn't reside in their Microsoft 365 services. However, these labels aren't applied directly by users, but are used to assist with the automated identification of items that shouldn't be on the platform. This assists security teams with identification and remediation activities.

Labels vary for this type of use varies between organizations, but should include:

  • PROTECTED (for organizations who work with highest data being OFFICIAL in their tenant)
  • SECRET
  • TOP SECRET

As per ISM-0272, these labels shouldn't publish to users, as if the service isn't authorized to host such information, users shouldn't be able to apply the labels to items:

Requirement Detail
ISM-0272 (June 2024) Protective marking tools don't allow users to select protective markings that a system hasn't been authorized to process, store or communicate.

Note

Unpublished labels refers to labels, which aren't published to end users. In order for a label to be considered by the auto-labeling service, they need to be published to a single user, such as an administrative account.

Organizations that require advanced DLP of highly sensitive data in the Microsoft 365 platform, for example via email or sharing, can layer extra security measures with 'unpublished labels,' including:

Labels for organizations with differing label taxonomies

Some Australian State Governments, such as the New South Wales and Queensland, make use of classification taxonomies that don't fully align with PSPF Policy 8. This can create some challenges for how Federal Government organizations interpret the sensitivity of information that they receive from State Governments. Similar challenges exist for Federal Government organizations that correspond with foreign Governments, as classifications aren't likely to align.

The data security frameworks and standards applied by external organization's that your organization communicates with are highly relevant to your label taxonomy. External markings can be utilized with the following methods:

  • Markings applied by external organizations can be converted to a tenant equivalent

    For example, if an item with a 'QLD Government SENSITIVE' marking applied to it, is received by a Federal Government organization, the marking provides useful information on the item's sensitivity. A user could apply a label of 'OFFICIAL Sensitive' to the item to bring it into scope of the tenant's label-based protections. Alternatively, auto-labeling could be configured to automatically map this QLD marking to the OFFICIAL Sensitive label.

  • Organizations can maintain external classifications, and appropriate protections to information while they are custodians of it

    Rather than reclassifying items that don't align with your environment's sensitivity labeling, Microsoft Purview could be configured with a set of 'unpublished labels' that align with external classifications. These labels don't need to be selectable by users within label-aware clients. Instead they can apply service-based auto-labeling. Once received items are labeled, users aren't prompted to apply a label to them. The labels can also be aligned with a set of DLP and other controls to ensure that the contained information isn't inappropriately disclosed.

Label configuration should be made with organizations, which they interact with the goal of alignment in classification terminology, as this allows for simpler configuration. If this isn't achievable, agreement on classification equivalencies provides the next best outcome. The situation that should be avoided is external markings being completely disregarded, as this is likely to lead to data security incidents such as a data spill.

  1. Classification alignment (recommended, best practice)
  2. Classification equivalence (recommended if option one not possible)
  3. Classification disregard (not recommended, increases risk of data spill)

Note

Where Government organisations interact with foreign Governments, the PSPF Policy 7 – Security Governance for International Sharing provides detailed guidance.

The following table is an example of how unpublished labels are implemented with auto-labeling in order to maintain markings applied by external organizations. The example shows a set of PSPF labels, the bulk of which appear as sublabels to the OFFICIAL Sensitive parent label. Underneath this parent label, the user can choose to include labels that align with NSW and QLD equivalent Information Management Markers (IMMs):

PSPF labels
(published to all users)		 NSW Government
(unpublished labels)		 QLD Government
(unpublished labels)
UNOFFICIAL
OFFICIAL
OFFICIAL: Sensitive
- OFFICIAL: Sensitive
- OFFICIAL: Sensitive Personal Privacy
- OFFICIAL: Sensitive Legal Privilege
- OFFICIAL: Sensitive Legislative Secrecy
- OFFICIAL: Sensitive NATIONAL CABINET		 - OFFICIAL Sensitive NSW Cabinet
- OFFICIAL Sensitive Legal
- OFFICIAL Sensitive Law enforcement
- OFFICIAL Sensitive Health information
- OFFICIAL Sensitive Personal
- OFFICIAL Sensitive NSW Government		 - SENSITIVE

The benefits to the previous approach are:

  • Information labeled with NSW or QLD labels benefit from OFFICIAL: Sensitive data out of place alerting (further explained in data out-of-place alerting), which alerts and assists the prevention of data from being moved to locations where it could be inappropriately disclosed.
  • NSW or QLD sublabels are included in OFFICIAL: Sensitive DLP and Defender for Cloud Apps policies, protecting from inappropriate disclosure via your organization (as introduced in preventing inappropriate distribution of security classified information).
  • Data identification services, such as Content Explorer, can be used to identify where state-owned or generated sensitive information may reside across Microsoft 365 services1.

Note

1 This configuration is advanced and is recommended for organizations familiar with Microsoft Purview.

Azure Rights Management encryption

Azure Rights Management is used to ensure that only authorized users can access content with a label applied.

For information on setting up Azure Rights Management encryption, see how to set up message encryption

The following is an example applicable to Australian Government.

  • A sublabel marked as Internal Only could be used to allow users to restrict items to internal users only.
  • A sublabel of Recipients Only could be used to ensure that emails can't be forwarded to unauthorized recipients.
  • A sublabel of Project Budgerigar Only could be used to ensure that only the subset of users who have need-to-know for Project Budgerigar and related information can access items.

Using these labels and associated controls alongside the basic set of OFFICIAL: Sensitive labels, the topology result is:

  • OFFICIAL: Sensitive
    • OFFICIAL: Sensitive Internal Only
    • OFFICIAL: Sensitive Recipients Only
    • OFFICIAL: Sensitive Project Budgerigar Only
    • OFFICIAL: Sensitive (no protection)
    • OFFICIAL: Sensitive Personal Privacy
    • OFFICIAL: Sensitive Legal Privilege
    • OFFICIAL: Sensitive Legislative Secrecy
    • OFFICIAL: Sensitive NATIONAL CABINET

There are some obvious challenges with the previous example, including:

  • The list of labels is a lot longer, which could impact usability.
  • The extra labels results in more configuration requirements in associated services, such as DLP, increasing complexity.
  • The previous set of label options require users need to make decisions around whether to apply an IMM, CAVEAT, or encryption configuration, which presents a problem.

In such situations, the protections provided by encryption should be the top priority. IMMs are considered optional according to PSPF so should be regarded as lower priority. Caveats, such as NATIONAL CABINET, are likely more important than IMMs and shouldn't be omitted. What this is likely to lead to are extra label requirements as organizations seek to apply newer protections to items.

The example demonstrates that label requirements are likely to grow over time. Starting with a large set of labels will result in even more complexity in future. Microsoft recommends limiting published labels to a core set required by users, and omitting any IMM and Caveat combinations that aren't likely to be required by your organization. By limiting users to a core set, it allows room for the configuration to grow without impacting usability or complexity.