Preventing inappropriate distribution of security classified information for the Australian Government

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. Guidance in this article aligns with requirements outlined in the Protective Security Policy Framework (PSPF) and Information Security Manual (ISM).

Configuration of policies discussed in this article require knowledge of Microsoft Purview Data Loss Prevention (DLP). For introductory guidance on Microsoft Purview DLP, see Learn about data loss prevention.

Restricting email distribution of classified information

DLP policies protecting classified items will primarily utilize DLP policy conditions of item contains sensitivity label. Configuring Label inheritance and Client-based auto-labeling will help to ensure label accuracy, improving data security.

For the highest levels of flexibility in terms of DLP conditions and actions, policies applying to email should target the exchange service only. This ensures that policy conditions, such as recipient domain is, are available for selection.

DLP policies applying to sensitivity labels require the use of the custom policy template.

Restricting email distribution of classified information to unauthorized organizations

PSPF 2024 requirement 77 states that an agreement should be in place before classified information is shared with an external user or organization:

Requirement	Detail
PSPF Release 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.

In order meet this PSPF requirement, Government organizations should consider:

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

Organizations can expect to 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. Select a condition of content is shared from Microsoft 365, with people outside of my organization.
2. Select a second condition of content contains, sensitivity label and the appropriate labels selected (for example, PROTECTED label and associated sublabels).
3. Select 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. Select 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.

Conditions

Action

Content is shared from Microsoft 365, with people outside of my organization AND Content contains Sensitivity Labels: - All PROTECTED labels AND Group NOT Recipient domain is: - List of domains approved for receipt of PROTECTED email

Restrict access or encrypt the content in Microsoft 365 locations: - Block users from receiving email or accessing - Block everyone Configure a policy tip of: "A recipient of this email is from an organization that isn't authorized for receipt of PROTECTED information. This email is blocked unless unauthorized recipients are removed from the to field. If this is incorrect, contact support to discuss your requirement." Configure appropriate incident severity and notification options.

Tip

Australian Government organizations should consider configuring DLP rules restricting email to nonapproved organizations for both PROTECTED and OFFICIAL: Sensitive security classifications.

Further examples of DLP policies blocking email to nonapproved organizations can be found in ASD's Blueprint for Secure Cloud under Data Loss Prevention policies.

The previous DLP policy example applies to labeled email only. If a user replies to a legacy item from their inbox, they'll be asked to select a label to apply to it. Client-based auto-labeling will work to ensure that the label is accurate by checking for existing markings on the email. Service-based auto-labeling will ensure that the applied label aligns with any existing subject marking. These two capabilities work together to ensure label accuracy and that relevant DLP apply to items.

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.

Guest Scenario	Domain-based control only	Domain and guest-based control
Guest from unapproved domain	Risk mitigated Not able to receive security classified information1	Risk mitigated Not able to receive security classified information1
Guest from domain approved for security classified information	Risk present All domain users able to receive security classified information regardless of need-to-know	Risk mitigated Not able to receive security classified information2
Guest from unapproved domain	Risk mitigated Not able to receive security classified information1	Risk mitigated Not able to receive security classified information2
Guest from approved domain	Risk present All domain users able to receive security classified information regardless of need-to-know	Risk mitigated Not able to receive security classified information2
Guest from approved domain and part of protected guests group	Risk present All domain users able to receive security classified information regardless of need-to-know	Risk mitigated Only domain users who are added as protected guests are able to receive security classified information

Note

¹ Providing configurations outlined in preventing email distribution of classified information to unauthorized organizations have been followed.

² Providing receipt of classified information has been restricted to approved guests in addition to domain based controls.

Organizations using such a configuration require business processes to support the maintenance of guest group membership. Any protected guests or equivalent groups also need to be included as exceptions to DLP rules restricting the distribution of classified email.

To create a DLP rules to prevent the email-based distribution of security classified information to authorized guests:

1. Select a condition of content is shared from Microsoft 365, with people outside of my organization.
2. Select a second condition of content contains, sensitivity label and the appropriate labels selected (for example, PROTECTED label and associated sublabels).
3. Select 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. Select 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.

Conditions

Action

Content is shared from Microsoft 365: with people outside of my organization AND Content contains Sensitivity Labels: - All PROTECTED labels AND Group NOT Recipient domain is: - List of domains approved for receipt of PROTECTED email AND Group NOT Recipient is a member of: - Protected guests

Restrict access or encrypt the content in Microsoft 365 locations: - Block users from receiving email or accessing - Block everyone Configure an appropriate policy tip: "A recipient of this email isn't authorized for receipt of PROTECTED information. This email is blocked unless unauthorized recipients are removed from the to field. If this is incorrect, contact support to discuss your requirements." Configure appropriate incident severity and notification options.

Preventing email distribution of classified information to unauthorized users

PSPF 2024 Requirement 75 is concerned with the clearance levels required for access to security classified information:

Requirement	Detail
PSPF Release 2024 - 12. Information Sharing - Requirement 75	Access to security classified information or resources is only provided to people outside the entity with the appropriate security clearance (where required) and a need-to-know, and is transferred in accordance with the Minimum Protections and Handling Requirements.

In Government organizations with mixed security clearance user types, certain users won't have the required clearances to access types of information retained by the organization. Such organizations require controls to prevent users who shouldn't have access to security classified information from receiving it via email.

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 can be used for this (for example, a protected users group). Such groups can be 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 in the DLP policy.

DLP policy configuration to meet these requirements need:

• 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 condition group, which is linked via the AND operand. The second group set to NOT with contain a condition of recipient is a member of, protected users.
• Rules require an action that blocks or redirects email to recipients who aren't part of the configured 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.

Conditions	Action
Content is shared from Microsoft 365 Only with people inside my organization AND Content contains Sensitivity Label: - All PROTECTED labels AND Group NOT Recipient is a member of: - Protected users	Restrict access or encrypt the content in Microsoft 365 locations: - Block users from receiving email or accessing - Block everyone Configure an appropriate policy tip, for example: "A user that you specified isn't approved for access to PROTECTED items." Configure appropriate incident severity and notification options.

The effect of the above rule is that, providing auto-labeling has been configured in line with example of email-based auto-labeling configuration, marked email received from external organizations will be labeled on receipt. After being labeled, if the recipient isn't part of the Protected users group, receipt of the protected email will be blocked.

Adding consideration of protective markings

The following rule extends the example above by checking for PROTECTED markings applied via either x-protective-marking x-headers or subject markings. The rule then blocks the email if the recipient isn't part of the protected user's group.

Conditions	Action
Content is shared from Microsoft 365: only with people inside my organization AND Group NOT Recipient is a member of: - Protected users AND GROUP Header matches pattern: X-Protective-Marking : SEC=PROTECTED OR Subject matches pattern: \[SEC=PROTECTED	Restrict access or encrypt the content in Microsoft 365 locations: - Block users from receiving email or accessing - Block everyone Configure an appropriate policy tip, for example: "A user that you specified isn't approved for access to PROTECTED items." Configure appropriate incident severity and notification options.

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 item via a local storage, USB, or some other nonemail based method. The user then attaches the item to an email and sends it on to other noncleaed users. Checking that a user is authorized to send security classified information helps to reduce the risk of a data breach.

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

• A condition of Content contains any of these sensitivity labels with relevant labels (for example, all PROTECTED labels) selected.
• A condition group, which is linked via the AND operand. The second group set to NOT with contain a condition of recipient is a member of, protected users.
  • Contain a condition of sender is a member of, protected users.
• Rules will require an action that blocks or redirects email to recipients who aren't part of the configured group.

To ensure that both internal and external sending is protected, the rule should be duplicated with conditions for Content is shared from Microsoft 365 set to Only with people inside my organization and Only with people outside of my organization retrospectively.

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.

Rule	Conditions	Action
Restrict internal sending of PROTECTED email	Content is shared from Microsoft 365: Only with people inside my organization AND Content contains Sensitivity Label: - All PROTECTED labels AND Group NOT Sender is a member of: - Protected Users	Restrict access or encrypt the content in Microsoft 365 locations: - Block users from receiving email or accessing - Block everyone Configure policy tips if desired. Configure appropriate incident severity and alerting
Restrict external sending of PROTECTED email	Content is shared from Microsoft 365: Only with people outside of my organization AND Content contains Sensitivity Label: - All PROTECTED labels AND Group NOT Sender is a member of: Protected Users	Restrict access or encrypt the content in Microsoft 365 locations: - Block users from receiving email or accessing - Block everyone Configure policy tips if desired. Configure appropriate incident severity and alerting

Preventing sharing of security classified information

Note

ASD's Blueprint for Secure Cloud includes guidance for SharePoint sharing configuration. ASD recommends restricting all sharing links to only people in your organization. Setting all sharing to internal only is a good default state for organizations operating at PROTECTED level.

Some organizations need to adjust their sharing configuration to cater for advanced use cases such as secure collaboration with other organizations. Provided guidance 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 via 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 2024 Requirement 77.

Requirement	Detail
PSPF Release 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.

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, has limited sharing options while it is in a PROTECTED location. The configurations in example groups and sites configuration, restrict sharing from such locations to internal recipients only. If a PROTECTED item is moved outside of a PROTECTED location, Data out of place alerting will apply.

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:

Conditions	Action
Content is shared from Microsoft 365: Only with people outside my organization AND Content contains Sensitivity Label: - All PROTECTED labels	Restrict access or encrypt the content in Microsoft 365 locations: - Block users from receiving email or accessing - Block only people outside your organization Configure an appropriate policy tip, for example: "PROTECTED items aren't appropriate for sharing with external recipients." Configure appropriate incident severity and alerting

Tip

As SharePoint-based DLP policies are location rather than user-based, exceptions aren't applied per user or per group. However, policies applying to OneDrive can be scoped to specific users.

DLP policy tips can be configured to provide users with useful feedback. Files matching a policy tip that are stored within SharePoint locations benefit from icon markings within document libraries. As the previous 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.

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 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 applicable. However, policies that detect sensitive information and security markings are discussed in limiting external chat via DLP.

Other sharing scenarios

Other sharing scenarios that government organizations 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 needs 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. Security teams can be alerted via 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 might 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 can be configured to limit the sharing of items with certain labels from OneDrive. Policies can also applied via groups, allowing for approved users to share labeled items from their OneDrive locations with guests while restricting nonapproved users.

Important

A user who is authorized for access PROTECTED items can share such items from their OneDrive in line with both the organization's global OneDrive sharing configuration and the OneDrive sharing configuration applied to their account.

What if a malicious insider repeatedly attempts 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 capability is used to determine a user's risk level based on their activity. Insider Risk Management allows security teams to monitor for suspicious activity sequences, such as:

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

For recommendations on Insider Risk Management configurations relevant to Australian Government organizations, see Managing insider risk.

Note

Other methods of identifying and protecting security classified items via Sensitive Information Type (SIT) rather than sensitity label are covered under Preventing inappropriate distribution of sensitive information.

Preventing the upload of security classified items to unmanaged locations

Defender for Cloud Apps is a Microsoft solution that provides visibility and control over SaaS based applications. It offers integration with Microsoft Purview via DLP and data sharing controls.

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 2024 Requirement 77, which states that security classified items should only be shared with formally approved organizations:

Requirement	Detail
PSPF Release 2024 - Section 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.

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

Prevent copying or printing of security classified items

Government organizations should consider vectors of data loss that aren't internet based services, such as those that could be achieved via a user's device. For example, situations where:

• 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.
• Security classified items are printed and then the hard copy is lost or stolen.

Endpoint data loss prevention (Endpoint DLP) allows for DLP policies to apply to user actions on registered endpoints. For information about onboarding procedures for Endpoint DLP, see getting started with Endpoint DLP.

As a prerequisite to effective EndPoint DLP controls, Government organizations should limit web browsers to only those which are Microsoft 365 DLP-aware. Chromium is DLP-aware and both Google Chrome and Firefox 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)

Note

The EndPoint DLP allows organizations to configure a range of options, including applications, path exclusions, permitted browsers, allowed printers, and allowed USB devices. These settings can be used with policies to define situations where the use of labeled items is permitted.