Preventing inappropriate distribution of security classified information for Australian Government compliance with PSPF

This article provides guidance for Australian Government organizations on configurations to reduce the risk of inappropriate disclosure of security classified information via Microsoft 365 services. Its purpose is to help organizations to improve their information security posture. Advice in this article aligns with requirements outlined in the Protective Security Policy Framework (PSPF) and Information Security Manual (ISM).

The Protective Security Policy Framework (PSPF) covers more than just x-protective-marking x-headers and covers a range of other requirements and controls. This article focuses requirements that are concerned with limiting the disclosure of security classified or otherwise sensitive information required in PSPF Policy 9: Access to information.

This article provides advice and discusses configurations relevant to:

• Exchange Online email scenarios,
• Microsoft Teams chat and channel messaging,
• Sharing scenarios via SharePoint and OneDrive,
• Upload to cloud storage services, and
• Download or printing on managed devices.

Preventing email distribution of classified information

Data Loss Prevention (DLP) policies in this section target the exchange service only in order to enable the required policy conditions, such as recipient domain is, which isn't available if other services are selected.

To meet PSPF requirements, DLP policies also require use of the custom policy template. Along with DLP policies, label inheritance for email attachments, as covered in label inheritance, should be enabled. Label inheritance ensure that, if an email's sensitivity is lower than an attachment, a recommendation is triggered requesting that the user elevate the email's label to align with the attachment. The recommendation, and approval by agency of the user, brings the email into the scope of any policies applying to the classification of higher sensitivity attachments.

Preventing email distribution of classified information to unauthorized organizations

PSPF Policy 9 requirement 1 states that security classified information should only be disclosed to approved organizations:

To meet the PSPF requirement, Government organizations are required to have:

• Business processes to identify, establish, and review formal agreements with entities that they share security classified information.
• Technical change processes for configuration modifications to allow or prevent users from sending security classified information to external organizations.

Organizations have different information security requirements for each security classification or subset (for example, Information Management Marker (IMM) or Caveat). Separate policies or rules should be created to address the requirements for each classification or subset.

To create a DLP rule to prevent the email-based distribution of security classified information to nonapproved organizations:

1. Create a condition of content is shared from Microsoft 365, with people outside of my organization.
2. Create a second condition of content contains, sensitivity label and the appropriate labels selected (for example, PROTECTED label and associated sublabels).
3. Create a second condition group linked via the AND operand.
   1. The second group is set to NOT.
   2. The second group contains a condition of recipient domain is along with a list of domains that are approved for receiving the selected security classifications.
4. Create an action, which blocks or redirects email to recipients who aren't from one of the configured recipient domains.

Example DLP Rule: Block PROTECTED email to nonapproved organizations

The following rule restricts sending of PROTECTED email to organizations that aren't listed as approved for receipt of the information. While a user is drafting an email with a PROTECTED label applied, if a user adds a recipient from a nonapproved organization, a DLP policy tip appears to warn the user. The email is blocked if the user ignores the policy tip and tries to send it.

Permitting email distribution of classified information to authorized guests

With the requirement of need-to-know, Government organizations should integrate a domain based approach with guest access, and multiple levels of guest access depending on applied label and guest group or domain.

Authorized guest permission is achieved by either:

• Creation of manually maintained groups (for example, protected guests), which contains guests from approved external organizations who have had their clearance status checked; or

• Creation of dynamic groups configured to include guest accounts from specified domains. This could be achieved via the use of dynamic queries assessing user's User Principal Names (UPNs). For example:

  (user.userPrincipalName -match "#EXT#") and (user.userPrincipalName -match "microsoft.com")

For more information on dynamic group membership, see dynamic membership rules for groups in Microsoft Entra ID.

The benefits of limiting the ability to receive PROTECTED information to a subset of domains AND guest accounts is demonstrated in the following email-based scenarios.

Organizations using such a configuration require business processes to support the maintenance of guest group membership. The organization also needs to add their protected guests groups as exceptions to DLP rules restricting the distribution of classified email.

DLP rules to permit the email-based distribution of security classified information to authorized guests are:

1. Create a condition of content is shared from Microsoft 365, with people outside of my organization.
2. Create a second condition of content contains, sensitivity label and the appropriate labels selected (for example, PROTECTED label and associated sublabels).
3. Create a second condition group, which is linked via the AND operand.
   1. The second group is set to NOT.
   2. It contains a condition of recipient is a member of, protected guests.
4. Create an action, which blocks or redirects email to recipients who aren't part of the selected group.

Example DLP Rule: Block PROTECTED email to nonapproved guests

The following rule builds on the previously provided example, to permit the sending of PROTECTED email to users who are both from approved domains AND who are included in a protected guests group.

Preventing email distribution of classified information to unauthorized users

PSPF Policy 9 Requirement 3 is concerned with the clearance levels required for access to security classified information:

In Government organizations that have environments with mixed security cleared user types, certain users don't have required clearances to access types of information retained by the organization (or don't have need-to-know). These organizations require controls to prevent users who shouldn't have access to security classified information, and from receiving it via email. Such configuration is achieved via DLP.

DLP rules restricting email to uncleared users require a method of determining which internal users are permitted to receive classified information. As with the previous example, a group is used for this (for example, a protected users group). This group is dynamic with membership maintained based on attributes aligning with each individuals security clearance. This can be sourced from HR or identity systems. Alternatively, conditions of recipient AD attribute match pattern can be configured directly in the DLP policy.

A DLP rule included in a new policy or added to the policy demonstrated in the previous section. The rule has:

• A condition of Content is shared from Microsoft 365, with people inside my organization.
• A condition of Content contains any of these sensitivity labels with relevant labels (for example, all PROTECTED labels) selected.
• A second condition group, which is linked via the AND operand. The second group is set to NOT. It contains a condition of recipient is a member of, protected users.
• A policy that needs an action, which blocks or redirects email to recipients who aren't part of the selected group.

Example DLP Rule: Block PROTECTED email to noncleared internal users

This rule blocks users who aren't part of a protected user's group from receiving email with PROTECTED labels applied.

The result is that where auto-labeling is configured in line with the example of email-based auto-labeling configuration, marked email received from external organizations are labeled on receipt and then blocked to uncleared users. The use of auto-labeling requires E5 or equivalent licensing. However, Organizations who choose not to use auto-labeling capabilities can still meet PSPF Policy 9 Requirement 3 by assessing markings rather than sensitivity labels.

The following rule checks for PROTECTED markings applied to either x-protective-marking x-headers or subject markings and blocks the email if the recipient isn't part of the protected user's group.

Preventing email of classified information by unauthorized users

Preventing unauthorized users from receiving classified information already within a tenant is important. However, consider a situation where a user gains access to a PROTECTED file via a local storage, USB, or some other nonemail based method. The user then attaches the item to an email and sends it. Checking that a user is authorized to send security classified information reduces the risk of a data breach.

The DLP rules to check if a user is authorized for access to classified information before they can send it are:

1. Create a condition of Content contains any of these sensitivity labels with relevant labels (for example, all PROTECTED labels) selected.
2. Create a second condition group, which is linked via the AND operand.
   1. The second group is set to NOT.
   2. It contains a condition of sender is a member of, protected users.
3. The policy needs an action, which blocks or redirects email to recipients who aren't part of the selected group.

Example DLP rules restricting the distribution of security classified email by unauthorized users

The following DLP rules ensure that only users who are authorized for access to PROTECTED information are able to send it. These rules ensure that in a security event (for example, accidental or malicious oversharing, inappropriate permissions or security configurations), uncleared users who gain access to classified items aren't able to exacerbate a data breach by further distributing security classified information.

Preventing distribution of security classified items via Teams chat

For information regarding the use of Microsoft Purview DLP to protect Microsoft Teams, see loss prevention and Microsoft Teams.

File sharing activities in Teams work via sharing links and are therefore labeled items can be protected via the DLP policy settings discussed in preventing sharing of security classified information.

A Teams chat can't have a sensitivity label applied to it. Therefore, classification based DLP policies aren't directly applicable. However, policies that detect sensitive information and security markings are discussed in limiting external chat via DLP.

Preventing sharing of security classified information

Some organizations need to adjust their sharing configuration to cater for advanced use cases such as secure collaboration with other organizations. Provided advice such as that included in High external collaboration control and other relevant sections of ASD's Blueprint for Secure Cloud have been followed, then this can be done with a low level of risk and can easily result in a configuration that better caters for information security than traditional approaches of emailing file attachments.

Each organization has a default sharing configuration, which is configured SharePoint sharing configuration. This allows for a list of domains to be configured that are approved for the receipt of sharing links. Such configuration is aligned with PSPF Policy 9 Requirement 1 - Formalized agreements for sharing information and resources.

Label group and site settings can further restrict sharing of items from labeled locations, as discussed in label sharing configuration. With the setting configured, a security classified item such as a PROTECTED document, have limited sharing options from PROTECTED locations. The configurations in example groups and sites configuration, restrict sharing from such locations to internal recipients only.

In addition to location-based sharing restrictions, organizations should implement DLP policies to block, or warn and dissuade users from external sharing of items that aren't appropriate for external distribution. The following example policy applies to the PROTECTED documents, preventing them from being shared with external users:

DLP policy tips can be configured to provide users with useful feedback. Files matching a policy tip that is stored within SharePoint based locations benefit from icon markings within document libraries. As the example DLP policy contains a policy tip and the policy imposes access restrictions, an icon showing a circle with a hyphen in it's visible in the document library to remind users that the item is subject to restrictions:

When a user ignores the policy tip and attempts to share a PROTECTED item externally, the policy tip displays in the sharing dialogue:

If a user attempts to bypass the DLP policy by, for example, emailing a more permissive link type to an external user, such as an anyone link, the DLP policy will still trigger, generate reporting and, if configured, send the user a DLP notification.

Other sharing scenarios

Other sharing scenarios that government organizations will find applicable are discussed in this section.

What if a member of a secure location, such as a PROTECTED team, shares an item inappropriately?

Microsoft's trust but verify approach allows all users within a team to share content in line with the location's sharing policy. If further restrictions are needed, options include:

• Sensitivity label groups and sites configuration are used to enforce conditional access policies for labeled locations. Authentication context also checks the user is part of a group of authorized users before allowing access to content in a labeled location.

• Labeled locations can be further restricted. Using PowerShell to set a label's configuration to MemberShareNone puts site or Team owners in control of the distribution of information from locations with the label applied. For more information on member sharing restrictions, see member sharing.

• Information barriers Implicit Microsoft 365 Group controls can be used to block the sharing of items with nonteam members. This capability is appropriate for situations where communication and collaboration are needed to be prevented between groups of users.

What if a user moves a PROTECTED item to another location where sharing is more permissive?

• If a user attempts to bypass sharing and access controls by moving a PROTECTED item to a lower sensitivity location, such as another Team where sharing is more permissive, then:

  1. Data Out of Place alerting will trigger, cautioning the user of the action.
  2. Alert security teams as per configuration of monitoring data out of place alerting.

• SharePoint sharing configuration is used to configure a list of domains that users are permitted to share with. Once configured, users can't share items outside of approved organizations.

• A OneDrive location may have a more permissive sharing policy than that applied to a labeled location. To mitigate risks relating to users sharing from OneDrive to bypass location-based controls, DLP policies are configured to limit the sharing of items with certain labels from OneDrive. Policies are also applied to groups of users to allow only trusted users to share labeled items from their OneDrive locations with guests.

What if a malicious insider repeatedly attempts to share activities to exfiltrate security classified information?

A motivated malicious insider is likely to perform numerous attempts to circumnavigate data security controls presented in this article. Microsoft's Insider Risk Management (IRM) capability is used to determine a user's risk profile based on their activity. IRM allows security teams to monitor for suspicious sequences of users, such as:

• Downloading information from Microsoft 365 locations with certain labels applied and then copying them to USB.
• Lowering or removing a label and then sharing it with an external user.
• Obfuscating information, which has been identified as sensitive and then exfiltrating it via a cloud service.

IRM integrates with Microsoft Purview DLP policies via a capability called adaptive protection. This identifies users who are deemed as risky due them continually triggering configured policies, and also automatically imposes extra restrictions on them to mitigate risk until security teams can investigate.

Preventing the upload of security classified items to unmanaged locations

Defender for Cloud Apps helps the security posture of an organization's use of cloud services. It does this by providing granular visibility into and control over user activities and sensitive information.

Defender for Cloud Apps policies are configured within the Microsoft 365 Defender console under the Cloud apps > Policies menu. Administrators can create a policies targeting files with PROTECTED labels and preventing them from being shared with unapproved domains. This configuration aligns with PSPF Policy 9 Requirement 1, which states that security classified items should only be shared with formally approved organizations.

For more information on integrations between Defender for Cloud Apps and Microsoft Purview Information Protection, see Microsoft Purview Information Protection integration.

Prevent download or printing of security classified items

This section addresses the risk that security classified items or information could be copied to locations outside of control of the Microsoft 365 tenant. For example:

• A user copies a PROTECTED item to an unencrypted USB drive, which is then lost or stolen.
• PROTECTED items are copied to an on-premises network share or location, which is inappropriate for the storage of PROTECTED items.
• Information contained within PROTECTED items is copied and pasted into a new item without the same controls applied, allowing for exfiltration of the information.

Endpoint data loss prevention (Endpoint DLP) is used to address these risks. For information about onboarding procedures for Endpoint DLP, see getting started with Endpoint DLP.

Government organizations need limit to use only Microsoft 365 DLP-aware browsers. Chromium is DLP-aware and Google Chrome can be made DLP aware via a browser add-in. For more information on the Microsoft Purview Chrome extension, see getting started with the Microsoft Purview Chrome Extension.

To target devices with Endpoint DLP, create a DLP policy that is scoped to the Devices location.

As with other DLP examples, policies can be configured with content contains, Sensitivity Label as conditions. Under policy actions, you can opt to Audit, Block with override, or Block the following actions:

• Upload item to a restricted cloud service domain (for example, Google Drive) (common to Block in Government organizations)
• Copy from item to clipboard
• Copy item to a removeable USB (common to Block with override in Government organizations)
• Copy to a network share
• Print
• Copy or move using unallowed Bluetooth app (common to Block in Government organizations)
• Copy or move using Remote Desktop Protocol (common to Block in Government organizations)