Preventing data spillage for the Australian Government

This article provides guidance for Australian Government organizations on configurations to reduce the risk of data spill by preventing higher sensitivity security classifications from being received in lower sensitivity environments. Its purpose is to help organizations to improve their information security posture. Guidance in this article is intended to align with requirements outlined in the Protective Security Policy Framework (PSPF) and Information Security Manual (ISM).

To reduce the likelihood and potential damage of data spill, Microsoft 365 environments should be configured to:

• Assess protective markings on incoming items and block their receipt if necessary.
• Assess protective markings on items that have already been received and prevent any further disclosure if necessary.
• Trigger appropriate alerting and reporting.
• Provide a method of checking for items with higher than permitted classifications within an environment.

Assessment of protective markings

When security classifications are applied to items, such as via application of a sensitivity label, protective markings are also applied. Protective markings include content markings, such as headers and footers dicusussed in sensitivity label content marking. For email, protective markings also include x-protective-marking x-headers and subject-based markings. To provide the best possible coverage, approaches that utilize multiple methods of identifying nonpremitted classifications should be applied. Approaches for identifying security classifications should include evaluation of:

1. X-protective-marking x-headers Government organizations are required to stamp email metadata, in the form of x-headers, to generated email that identifies its security classification. An x-protective-marking x-header including SEC=SECRET denotes an item with a SECRET security classification.
2. Subject markings Government organizations will typically apply subject markings to email. Subject markings are more prone to tampering as they're end-user accessible, but still provide a good indication of security classification. A subject marking including [SEC=SECRET] denotes a secret item.
3. Sensitive Information Type (SIT) Sensitive Information Types (SITs) are keyword or pattern based identifiers that can be used to find content within items, including protective markings. A SIT could be configured to identify a content marking of SECRET in an email or document's header or footer. A keyword of SECRET is more prone to false positives that a keyword of SECRET CABINET Personal Privacy so some discretion with this technique is advised.
4. Sensitivity label Users shouldn't have the ability to apply sensitivity labels beyond the security classification permitted for an environment. However, configuring unpublished labels for higher than permitted classifications can be useful when paired with autolabeling configurations. For example, an autolabeling policy looking for a SECRET marking and applying a SECRET label could then encrypt any aligning items, preventing any further disclosure while security teams intervene. For more information, see labels for information that are beyond PROTECTED level.

The approaches used in this article utilize one or more of these methods of identifying security classifications.

Blocking receipt of email with nonpremitted classifications

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

Within this requirement, the term inappropriate protective markings is typically used to define higher than permitted classifications for an environment. To meet this requirement, Data Loss Prevention (DLP) policies should be configured to prevent the transmission, receipt, and further distribution of items with nonpermitted classifications.

Example DLP Rule: Block SECRET email

The following rule assesses email based on x-header, subject marking and sensitivity label. A condition assessing SITs hasn't been added to this rule due to risk of false positives, but this could be added after testing if deemed appropriate. This rule could be named EXO - Block SECRET email and added to a policy named EXO - Block nonpermitted classification email.

Blocking sharing of items with nonpermitted classifications

There are typically many different avenues for information to move into an environment. Email is one important avenue to cover, but we should also consider the many other ways that files could be received, and the risk that items with nonpermitted classifications might already exist in an environment.

Security classifications can be identified through Custom Sensitive Information Types, such as those detailed in Example SIT syntax to detect protective markings.

Once SITs have been configured, SharePoint works to index active items for SIT alignment. DLP policies can be created to protect items that are deemed to align with a SIT.

The following set of example SITs could be created to attempt to identify SECRET markings. Confidence levels will vary for these SITs as the more straightforward the markings, the higher the likelihood of false positives.

Example DLP rule: Block sharing of SECRET items

The following DLP rule could be named SPOD - Block SECRET sharing and added to a policy named SPOD - Block nonpermitted classification sharing.

Autolabeling of items with nonpermitted classifications

The DLP policies demonstrated above make use of conditions of content contains sensitivity label. In order to utilize these conditions we require a method of labeling items suspected of having a nonpermitted classification. This is achieved by using service-based autolabeling policies to check items at rest in SharePoint locations for SIT alignment. If an item is detected that contains a nonpermitted security classification, the item can then be labeled and protected. This configuration requires labels to be created and not published directly to end users. Instead, they need to be published to a service or break glass account to bring them within scope of the autolabeling service. Further information on expanding label taxonomies to nonpermitted classifications can be found at Labels for information beyond PROTECTED level.

Autolabeling configuration required to achieve this would be in line with examples provided in SharePoint-based policy configuration. Another example configuration is provided below. The following rules could be added to a policy named SPOD - Label SECRET items:

An advantage of that autolabeling provides beyond SIT based detection methods is that labeling will enable Data out of place alerting. This triggers whenever a higher sensitivity item is moved to a lower sensitivity location, alerting location owners, and users completing the move activity. Other alerting can be achieved via the use of mail flow rules.

Sensitivity labels created to catch and protect nonpermitted classifications could also be configured with sensitivity label encryption. These encryption settings could be configured in such a way that only teams required to investigate potential data spills have access to labeled items, greatly reducing the impact of potential spills. Such configuration would assist organizations to meet ISM-0133 data restriction requirements:

Identifying spilled data

Content Explorer is a Microsoft Purview capability that allows administrators to browse an organizations Microsoft 365 data estate by Sensitive Information Type, sensitivity label, trainable classifier, or retention label. After SITs to identify nonpermitted classifications have been created and/or sensitivity labels with associated autolabeling policies deployed, administrators will be able to browse for aligning items across SharePoint, OneDrive, Exchange, and Teams.

Microsoft Purview eDiscovery provides an alternative method for searching for items with nonpermitted classifications. An eDiscovery case can be created with search criteria looking for either sensitivity label or SIT. For more information on using eDiscovery for finding content, see Finding content in sites in eDiscovery.

Protecting unlabeled items

PSPF requires that information assessed for any potential risk or damage that could be caused by its disclosure:

When information has been assessed, its deemed level of risk is recorded by application of a security classification. Microsoft 365 provides for this via sensitivity labeling. Configurations like Mandatory labeling ensure that all items, such as documents or emails, have a label applied.

If a user hasn't applied a security classification to an item, then there's a good chance that risk of inappropriate disclosure hasn't been considered. Distribution of the contained information should then be considered a risk. Strategies for such scenarios should be considered and incorporated into an organizations DLP configuration.

Many Australian Government organizations also consider unlabeled items to be inappropriate as per ISM-0565:

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.

Applications and 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:

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

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