Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
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 the 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 user authentication and authorization for access to the content. 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 can prevent users from actions like editing contents, saving items, printing, copying content or forwarding them to other users.
Scenarios relevant to label encryption
Government organizations should use label encryption in line with access, and transmission requirements summarized in encryption overview. These requirements state that encryption is required for transmission of OFFICIAL: Sensitive or PROTECTED information across public or nonprotected networks. Although innate Microsoft 365 capabilities like TLS encryption for communications between client and servers help to meet these requirements, there are certain scenarios where the use of Azure Rights Management encryption can strengthen protection.
Examples of scenarios where enablement of label-based Azure Rights Management encryption can strengthen controls include situations where security classified items are:
- 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
Azure Rights Management encryption isn't a hard requirement for the deployment of Microsoft Purview or for the protection of information in Microsoft 365 services. However, label-based encryption is considered one of the most effective methods of ensuring that data originating from or residing on Microsoft 365 environments is protected from unauthorized access, especially once it has left the organization.
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 that 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:
- Read and understand 2.6.3 LabelInfo versus Custom Document Properties.
- 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
andClassificationContentMarkingFooterText
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
Within Australian Government, collaboration and information distribution requirements vary depending on the type of organization. Some organizations work largely in isolation, making encryption configuration straightforward. Others have requirements to continually share sensitive information with other organizations and need to plan accordingly.
Australian government organizations using label-based encryption should be using this capability to ensure alignment with PSPF 2024 Requirement 77 and 133:
Requirement | Detail |
---|---|
PSPF 2024 - 12. Information Sharing - Requirement 77 | An agreement or arrangement, such as a contract or deed, that establishes handling requirements and protections, is in place before security classified information or resources are disclosed or shared with a person or organization outside of government. |
PSPF 2024 - 17. Access to Resources - Requirement 133 | Personnel requiring access to caveated information meet any clearance and suitability requirements imposed by the originator and caveat controlling authority. |
To ensure that only users from authorized external organizations can access encrypted items, the following approaches can be used:
- Lists of approved external domains can be added to Azure Rights Management permissions, similar to the DLP approaches outlined in preventing email distribution of classified information to unauthorized organizations.
- Groups containing guest accounts can be used to grant permissions to only an authorized set of users from approved external domains. This approach is similar to permitting email distribution of classified information to authorized guests.
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. Keep in mind that encryption is only one layer of protection which can be supplemented with DLP to help ensure need-to-know.
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 isn't 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 can be 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 can be 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 can be 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 might or might 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 2024 Requirement 77.
Multiple sets of permissions can be 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:
- 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.
- 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 2024 Section 17. Access to resources:
Requirement | Detail |
---|---|
PSPF 2024 - 17. Access to resources - Requirement 122 | A risk assessment determines whether a person is granted temporary access to security classified information or resources. |
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 2024 Requirement 71. 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 |
Note
ASD's blueprint for Secure Cloud recommends similar label encryption configurations, which can be seen under the Access Control configuration for PROTECTED labels. For example, PROTECTED sensitivity label.