Preventing data spillage via receipt of inappropriate classifications for Australian Government compliance with PSPF

This article provides guidance for Australian Government organizations on configurations to reduce the risk of data spill by monitoring and preventing items with inappropriate classifications from being received by 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).

Government organizations are required to ensure that highly sensitive information is protected from being passed into lower sensitivity environments. This includes information with classifications applied that are higher than that permitted by the organization and information inappropriate for use within Microsoft 365 cloud environments (for example, SECRET and TOP SECRET information).

Blocking transmission of inappropriately labeled email

ISM-0565 mandates measures to protect from data spills via email:

Requirement	Detail
ISM-0565 (June 2024)	Email servers are configured to block, log, and report emails with inappropriate protective markings.

In addition to ISM-0565, the controls in this guide align with the Protective Security Policy Framework (PSPF). Within Microsoft 365, security classifications are aligned with the ISM (Information Security Manual) and PSPF security controls using sensitivity labels. Items must have sensitivity labels in Government, because prescribed security controls and management are associated with the item.

Microsoft Purview deployments for Australian Government organizations are typically paired configuration that requires label application to all items. This mandatory labeling configuration allows organizations to meet PSPF Policy 8 requirement 1 as when an item is created, a label is applied to it. Having labels applied to all items ensures that they receive appropriate protection and reduces the risk of compromise.

Data Loss Prevention (DLP) policies are configured to both:

• Prevent data spillage by preventing transmission, receipt, and further distribution of items of a higher classification than permitted in the environment (referred to in this article as nonpermitted classifications); and
• Prevent the transmission of unlabeled emails, which haven't been assessed for sensitivity or which can indicate an attempt to bypass security controls.

Blocking transmission of nonpermitted classifications

In order to block the receipt and/or further transmission of classified items, and items that shouldn't exist in the platform, methods of identifying such information must first be established. Such methods include:

• The evaluation of subject markings and email x-protective-marking x-headers to determine the classification that is applied to incoming items.
• The use of a Sensitive Information Types (SITs) (as discussed in identifying sensitive information) to identify information that shouldn't exist on the platform. These SITs include keyword identifiers such as 'SEC=SECRET' and 'SEC=TOP-SECRET' and other Government keywords that exist in highly sensitive items.
• The use of unpublished sensitivity labels in combination with auto-labeling as method to identify items that shouldn't exist on the platform. For more information, see labels for information that are beyond PROTECTED level.

To block spillage of nonpermitted classifications, a set of DLP policies are used. Because policy conditions available depend on the services used by the organization, several policies are required to cover all available communication channels. Policies addressing the Exchange service is a recommended starting point for most organizations.

DLP policies contain one or more rules, which would make use of conditions such as:

• Content contains, sensitive information type, Secret Keywords SIT, OR
• Content contains, sensitivity label, SECRET, OR
• Header matches pattern, X-Protective-Marking : SEC=SECRET, OR
• Subject matches pattern, \[SEC=SECRET

Rules should have an action of block everyone, which is available under restrict access or encrypt the content in Microsoft 365 locations option.

ISM-0133 is relevant DLP to reporting actions:

Requirement	Detail
ISM-0133 (June 2024)	When a data spill occurs, data owners are advised and access to the data is restricted.

Alerting actions are important for preventing any further data spillage and for expediting cleanup activities. Multiple actions can be configured in a single DLP rule. Organizational security teams to determine appropriate alerting actions. Options available via the DLP interface are extended via Power Automate and Security Information and Event Management (SIEM) solutions such as Sentinel.

The following is an example of a completed DLP rule to identify and stop distribution of SECRET items on Exchange:

Policy name: EXO - Block nonpermitted classifications

Rule name	Conditions	Action
Block SECRET items	Content contains, Sensitive Info Type: Secret Keywords custom SIT containing terms likely to align with a SECRET classification. OR Header matches patterns: X-Protective-Marking : SEC=SECRET OR Subject matches patterns: \[SEC=SECRET OR Content contains sensitivity Label: SECRET	Restrict access or encrypt the content in Microsoft 365 locations: - Block users from receiving email - Block everyone Configure appropriate incident severity and alerting.

The logic applied in the previous rule can be used to create more DLP policies to block the distribution of nonpermitted classifications across other services including:

• SharePoint
• OneDrive
• Teams chat and channel messages (excluding sensitivity label condition)
• Devices via EndPoint DLP (including nonpermitted networks, USB, locations, etc.)
• Upload to cloud services via Defender for Cloud Apps
• On-premises file repositories

Blocking transmission of unlabeled email

To block the transmission of unlabeled email, a DLP policy can be configured based on the custom policy template and applying to the Exchange service.

A blocking transmission of unlabeled email policy requires two rules:

1. The first rule for outgoing items via the content that is shared from Microsoft 365, with people outside my organization condition.
2. A second rule applying to content that is shared from Microsoft 365, only with people inside my organization.

Rules need an exception, which is applied via a condition group with the NOT operand enabled. The condition group includes a condition of content contains, sensitivity labels and have all labels available in the environment selected.

Services that generate email are outside of Mandatory labeling configuration that applies to Microsoft 365 Apps clients. Therefore, this DLP policy triggers whenever nonuser generated email is sent. It triggers against security alerts generated by Microsoft services, email from scanners and multi-function devices (MFDs), and email from applications such as human resources or payroll systems. To ensure that the policy doesn't block essential business processes, exceptions need to be included in the NOT group. For example:

• OR sender domain is microsoft.com, which captures security and SharePoint alerting.
• OR sender is a member of group, with a group containing accounts authorized to bypass this requirement.
• OR sender IP address is, along with addresses of office MFDs.

The rule triggers whenever an email is sent that doesn't contain one of the listed sensitivity labels unless the sender is exempt via one of the configured exceptions.

These DLP rules should have an action of block everyone along with appropriate severity and reporting actions.

The following alerting requirement is relevant to the DLP rule applying to outgoing items:

Requirement	Detail
ISM-1023 (June 2024)	The intended recipients of blocked inbound emails, and the senders of blocked outbound emails, are notified.

To meet this requirement, the DLP rule applying to outgoing items is configured to notify the user who attempted to send the item.

Tip

Government organizations who are transitioning to sensitivity labeling, can choose to configure a policy tip rather than block or alert actions. Such policies could be used to suggest label selection without configuring it as a hard requirement. Although this doesn't strictly meet the requirement in the ISM, it can allow for a more graceful deployment of Microsoft Purview capabilities for users.

Example DLP policy blocking unlabeled email

The following DLP policy applies to the Exchange service and prevents loss of information via unlabeled email:

Policy Name: EXO - Block unlabeled email

Rule	Conditions	Action
Block outgoing unlabeled email	Content is shared from Microsoft 365, with people outside of my organization AND Condition Group NOT Content contains sensitivity labels: - Select all labels OR Sender domain is: - microsoft.com - include other exceptions	Restrict access or encrypt the content in Microsoft 365 locations: - Block users from receiving email - Block everyone