Sensitivity label encryption for Australian Government compliance with PSPF

This article provides guidance for Australian Government organizations on the use of sensitivity label encryption. Its intent is to help Australian Government organizations to strengthen their approaches to data security. Recommendations in this guide closely align with requirements outlined in the Protective Security Policy Framework (PSPF) and Information Security Manual (ISM).

Microsoft Purview provides the option to encrypt items with a sensitivity label applied via Azure Rights Management. Azure Rights Management is used to confirm both authentication and authorization. For a user to access an encrypted item, they need to authenticate to the Microsoft 365 service and be granted permission to access the item. Azure Rights Management is used to apply usage restrictions to items. These restrictions prevent users from actions like editing contents, saving items, printing, copying content or forwarding them to other users.

Label encryption requirements

Government organizations need to use label encryption in line with access, and transmission requirements summarized in encryption requirements. These requirements state that encryption is required for transmission of OFFICIAL: Sensitive or PROTECTED information across public or nonprotected networks.

Tip

Organizations who frequently communicate with external organisations and entities at OFFICIAL and higher may need to risk assess this posture based on their business requirements. For more information, see encryption overview.

Enablement of label-based encryption to OFFICIAL: Sensitive and PROTECTED items strengthen Government organization's ability to meet requirements for encryption during transmission and ensures that labeled items are encrypted when:

  • Copied to USB storage.
  • Uploaded to non-Microsoft cloud services, including cloud storage services.
  • Saved to potentially unsafe devices (for example, devices without BitLocker encryption).
  • Emailed to external recipients who can violate need-to-know by further distributing the information.

Australian Government organizations typically implement extra strategies and solutions to address these risk vectors. For example, use of encrypted USB drives, Cloud Access Security Broker (CASB) solutions and device management platforms. Label-based encryption isn't intended to replace these solutions. However, it's used to supplement these solutions by providing extra protection from accidental misuse and malicious insiders.

Label encryption considerations

For information on the standard considerations and potential impacts of enabling sensitivity label encryption, see considerations for encrypted content.

There are other considerations more specific to Australian government organizations. These include changes to document metadata and requirements relating to information sharing.

Encrypted coauthoring changes

Microsoft 365 supports coauthoring on encrypted documents.

Enablement of encrypted coauthoring introduces changes to how sensitivity label metadata is applied to Office document and the use of MSIP_labels document properties. Following enablement of encrypted coauthoring, metadata on encrypted items is moved from the traditional document property location to a document's internal xml. For more information, see metadata changes for sensitivity labels.

Australian Government organizations who apply rules on email gateways that check for attachment classification via document properties, need to be aware of metadata changes so that their configurations are aligned. Microsoft Exchange administrators should:

  1. Read and understand 2.6.3 LabelInfo versus Custom Document Properties.
  2. Assess their organizations Data Loss Prevention (DLP), mail flow rule, or transport rule syntax on non-Microsoft email gateways for potential issues.

An example of why this is important is a mail flow or transport rule that checks for PROTECTED attachments via label GUID in a document property doesn't work correctly once document metadata moves from the document property to the LabelInfo location.

As alternatives to the document property based approaches:

  • ClassificationContentMarkingHeaderText and ClassificationContentMarkingFooterText document properties are used. These properties appear after encrypted coauthoring enablement and is populated with the visual marking text applied to Office documents.
  • Mail flow methods are transitioned to a newer DLP based approach where sensitivity labels can be queried natively as part of a DLP policy.

External user access to encrypted items

Australian government organizations using label-based encryption are doing so in line with Protective Security Policy Framework (PSPF).

Requirement Detail
PSPF Policy 9 Requirement 1 - Formalized agreements for sharing information and resources When disclosing security classified information or resources to a person or organization outside of government, entities must have in place an agreement or arrangement, such as a contract or deed, governing how the information is used, and protected.

To ensure that only users from authorized external organizations can access encrypted items, the following approaches can be used:

Tip

Aligning your organization's approach for DLP with that for label encryption for classified information simplifies administration. The result is a robust and consistent approach to the handling of classified information where only authorized users can both be sent classified information and have access to it.

Enabling label encryption

For information on the prerequisites and steps required to enable sensitivity label encryption, see restrict access to content by using sensitivity labels to apply encryption.

The following label encryption configurations have special relevance to Australian government requirements and are discussed in detail.

Assign permissions now

Assign Permissions Now provides consistent control of access to labeled items across an entire environment. Via this configuration, when a label with encryption settings is applied to an item, encryption of the content is triggered immediately.

When the assign permissions now option is selected, administrators need to configure permissions to be applied to labeled items. The available options are:

  • All users and groups in your organization: This option adds permission for all users in the environment, excluding guest accounts. This is a good introductory point for organizations wanting to restrict access to labeled items to internal users only.

    This is a good option for organizations wanting to encrypt 'OFFICIAL: Sensitive' information and ensure it can be opened by the entire organization.

  • Any authenticated user: This option allows access to any user who is authenticated to Microsoft 365 via an account such a Microsoft 365 account, a federated social provider, or an external email address, which is registered as a Microsoft Account (MSA). This option ensures that items are sent and stored in encrypted format but is the most open in terms of access to items. This option isn't suitable in terms of ensuring need-to-know and PSPF alignment in Australian Government.

Important

Any authenticated user is not a good option for Australian Government organizations for application to security classified items due to the open nature of the applied permissions.

  • Add users or groups: This option allows for individual users (for example, individual organizational users or guests) to be specified. It allows for permissions to be allocated to groups.

    There are several uses of this option for government organizations. For example:

    • This option is used to ensure need-to-know by limiting access to labeled content to a subset of internal users who meet a requirement. For example, authorized users with baseline clearance are grouped into a protected users group, which gives permissions to PROTECTED content. Users outside the group are prevented from accessing any PROTECTED items.
    • For organizations with high external collaboration control (as discussed in high external collaboration control), a dynamic group is created which contains all guest accounts. This group could be granted permissions to encrypted items, allowing for items to be distributed externally with reduced risk of access by entities outside of the group. Such a configuration also needs to align with DLP controls discussed in permitting email distribution of classified information to authorized guests.
      • For organizations with relatively low external collaboration control (as discussed in low external collaboration control), a security group is maintained containing guests who are authorized for access to encrypted content.
      • For organizations wanting to provide guest access to content without making a label's content accessible to an entire domain, a dynamic group is created to grant access to guests from an organization, for example, 'Departmental guests.' This approach is discussed in permitting email distribution of classified information to authorized guests.
  • Add specific email addresses or domains This option allows for the individual email addresses of external users, who may or may not be a guest, to be granted permissions. It can also be used to grant permission to an entire domain. For example, Contoso.com. Organizations who have complex information collaboration and distribution requirements or a need to distribute OFFICIAL: Sensitive or PROTECTED information to other government organizations can consider adding a list of the domains of all organizations, which they're distributing such information to. Such a list should align with domains that your organization has formalized agreements with for sharing information and resources, as defined in PSPF Policy 9 Requirement 1.

Multiple sets of permissions are added to a label's configuration to achieve the desired outcome. For example, All users and groups can be used in combination with a set of dynamic groups containing guests from other organizations plus a list of authorized department domains that your organization regularly collaborates with.

Assign permissions to users, groups, or domains

For each user, group of users or domain that is granted access, specific permissions also need to be selected. These permissions are grouped into typical sets such as Co-Owner, Co-Author or, Reviewer. Custom sets of permissions can also be defined.

Encryption permissions are granular so organizations need to complete their own business analysis and risk assessments to determine the most valid approach. The following is an example approach.

User Category Contains Permissions
All users and groups All internal users Co-Owner (Grants all permissions)
Guests from other departments with collaboration requirements Dynamic Microsoft 365 Groups:
- Guests from Department 1
- Guests from Department 2
- Guests from Department 3
Co-Author (Restricts edit, export content, and change permissions)
Cleared guests from partner organizations Security Groups:
- Guests from Partner 1
- Guests from Partner 2
- Guests from Partner 3
Reviewer (Restricts print, copy and extract, export content and change permissions)

Let users decide

An approach to encryption is to let users choose what permissions to apply when they select a label.

The behavior of items labeled via this method varies depending on the application. For Outlook, the available options are:

  1. Do Not Forward: When this option is selected, emails are encrypted. The encryption applies access restrictions so that recipients are able to reply to the email but options to forward, print, or copy information aren't available. Azure Rights Management permissions are applied to any unprotected Office documents attached to the email. This option ensures need-to-know by preventing email recipients from forwarding items on to those who weren't specified on the original email.

  2. Encrypt Only: This option encrypts items and grants recipients all usage rights except for save as, export and full control. It's useful for meeting encrypted transmission requirements but doesn't apply any access restrictions (the result is need-to-know controls aren't applied).

These options provide a great deal of granularity. However, as permissions are applied at item level, these options can result in inconsistent configuration as the options selected by different users vary.

By providing don't forward or encrypt only options to users as sublabels, an organization can provide users with a method of protecting communication when deemed necessary. For example:

  • UNOFFICIAL
  • OFFICIAL
  • OFFICIAL Sensitive (Category)
    • OFFICIAL Sensitive
    • OFFICIAL Sensitive Recipients Only

Labels with these configurations applied should be published only to users who require such capabilities.

Microsoft Purview is capable of alignment with PSPF with the requirement of including Information Management Markers (IMMs) and Caveats and addition of sub-Labels to meet specific organizational requirements. For example, a group of users who are required to communicate 'OFFICIAL: Sensitive Personal Privacy' information with external users can have a 'OFFICIAL: Sensitive Personal Privacy ENCRYPT-ONLY' label published to them.

Content Access Expiry

Content expiry options allow permission to access encrypted items with the label applied to be denied either on a date or after a period of time. This capability is used to ensure that items are no longer accessible from a time regardless of where they reside or the permissions that have been applied to them.

This option is useful for achieving requirements for the time-bound access to information, where Government organizations need to provide temporary access to information or resources. These situations are covered under PSPF Policy 9:

Requirement Detail
PSPF Policy 9 Requirement 4: Temporary access to classified information and resources Entities may provide a person with temporary access to security classified information or resources on the basis of a risk assessment for each case. In such cases, entities must:
a. Limit the duration of access to security classified information or resources: i. To the period in which an application for a security clearance is being processed for the particular person, or ii. Up to a maximum of three months in a 12-month period
b. Conduct recommended employment screening checks (see the PSPF policy: Eligibility and suitability of personnel)
c. Supervise all temporary access
d. For access to TOP SECRET information, ensure the person has an existing Negative Vetting 1 security clearance, and
e. Deny temporary access to classified caveated information (other than in exceptional circumstances, and only with approval of the caveat owner).

This approach ensures the need for supervision of temporary access and to ensures that the temporary user only has access to what has been allowed, and only for the time required.

Azure Rights Management encryption applied via label and with access expiry configuration allows for sensitive items to be shared with individuals or organizations without the need to create full accounts.

An example of this is a Government organization has a set of design documents that need be made available to a fictional Government contracting organization, named Contoso. A label named 'OFFICIAL Sensitive – Contoso Temp Access' is created and published with permissions granting access to an approved list of Contoso email addresses. A copy of the design documents then has this label applied, which start a 30-day access timer. The documents are then shared with Contoso who can access the items on their own systems until the timer expires and access is revoked regardless of where the items reside.

As content expiry is applied to a label rather than to permissions, dedicated labels are required to achieve this. This, and other access expiry scenarios are niche and aren't applicable in most Government organizations. This example builds on and extends foundational PSPF Microsoft Purview Information Protection configuration being applied as advised in this guide.

Offline access

Offline access options allow configuration a period of time that users can access items without needing to reauthenticate or reauthorize their Azure Rights Management permissions. Offline access is useful to ensure that, for example, offline files can be accessed if a network or service outage. When this option is configured, items are still encrypted and their permissions are cached on client devices.

Government organizations who deploy encryption generally opt for an offline access period of three to seven days to ensure that users are able to work offline and as a disaster mitigation measure.

A risk assessment of cached access to items against the usability impact of no access when users are working without network access by a Government organization should be completed when considering this approach.

Example label encryption configuration

Note

These examples are intended to demonstrate label encryption configuration with operational controls proportional to the value of the information, which aligns with PSPF Policy 8 Requirement 1. Government organizations need to complete their own business analysis, risk assessment and testing before enabling any such configuration.

Sensitivity label Encryption Permissions
UNOFFICIAL - -
OFFICIAL - -
OFFICIAL Sensitive (Category) - -
OFFICIAL Sensitive Assign permission now All users and groups in your organization:
Co-Owner

Add specific email addresses or domains:
List of external domains approved for access - Co-Author
PROTECTED (Category) - -
PROTECTED Assign permission now Add users or groups:
Protected users group - Co-Owner

Protected guests group - Co-Author

Microsoft Purview Message Encryption

Microsoft Purview Message Encryption is a Microsoft 365 encryption capability built on Azure Rights Management. As with label-based Azure Rights Management encryption, Microsoft Purview Message Encryption confirms identity through authentication, and authorization through application of permission to items.

For information on Microsoft Purview Message Encryption, see how message encryption works.

A key advantage of Microsoft Purview Message Encryption is where both sender and recipient mailboxes are hosted in Exchange Online, with clients that support Microsoft Purview Message Encryption (including Microsoft 365 Apps, mobile and web-based clients), the encryption process including recipient access to the received email, is seamless. The recipient can receive and view the message as they would any nonencrypted email. However, if the recipient isn't using Exchange Online and/or a Microsoft Purview Message Encryption capable email client, rather than receiving a full email message, they receive a *wrapper that advises them of their receipt of a protected email and directs them to a Microsoft portal where they can authenticate in order to access the information in a secure manner. These wrapper messages are fully customizable so can be modified to suit your organization.

Authentication for Microsoft Purview Message Encryption is handled differently to label-based Azure Rights Management as permissions don't need to be defined on a label. This allows for greater flexibility in terms of who might be able to receive encrypted correspondence, which may be desirable for some use cases.

There are three categories of authentication relevant to Microsoft Purview Message Encryption message recipients:

  • If recipients are using Microsoft 365 identities via Exchange Online, then their existing credentials and/or tokens used for their current session can be used for authentication and authorization.
  • If recipients are using supported external identities, such as those provided by Gmail or Yahoo, then they'll need to authenticate via these credentials in order to access the wrapper email and connect to the Microsoft 365 provided portal to access the message.
  • If recipients are using a nonsupported identity, then they'll receive the wrapper email and can select the link to access the Microsoft 365 provided portal at which time they'll be asked to set up their email address as a Microsoft account (MSA). This Microsoft account will associate a password and other information with the user's email address, which is used for future authentication.

Microsoft Purview Message Encryption is also used to ensure confidentially and provide recipients with assurance that their information is being treated securely. For example, HR teams can use of Microsoft Purview Message Encryption when discussing potential employment with a job candidate. Microsoft Purview Message Encryption is useful when discussing sensitive financial matters with a member of the public. Universities and other education providers can utilize Microsoft Purview Message Encryption when corresponding with students regarding academic matters.

The following are use cases for Microsoft Purview Message Encryption that are relevant to Australian Government organizations:

  • Application of Microsoft Purview Message Encryption to all emails with a label (for example, OFFICIAL Sensitive), sent to a list of external organizations. This list includes other Government organizations that the organization has formalized agreements with (as per PSPF Policy 9, Requirement 1).
  • Application of Microsoft Purview Message Encryption to emails containing sensitive information (identified via SIT), that are being sent to a list of other non-Government organizations where there's a relationship. Due to these organizations not necessarily requiring to comply with Australian Government security requirements, these environment's status is unknown.

For more information on Microsoft Purview Message Encryption capabilities and potential uses, see Set up Microsoft Purview Message Encryption

Configuration to apply Microsoft Purview Message Encryption to email can be applied via Exchange Mail Flow Rules. Any messages matching a sensitivity label trigger a rule, which applies a Microsoft Purview Message Encryption template to the email. These rules require GUID-based method of identifying labeled emails.