Preventing inappropriate distribution of sensitive information for Australian Government compliance with PSPF

The purpose of this article is to help Australian Government organizations improve their information security posture. Advice in this article has been written to best align with requirements outlined in the Protective Security Policy Framework (PSPF) and Information Security Manual (ISM).

This article provides guidance for Australian Government organizations on configurations to reduce the risk of inappropriate disclosure of sensitive information via Microsoft 365 services. This article explores configurations that should be implemented in addition to those discussed in Preventing inappropriate distribution of security classified information. The reason for this is that sensitivity label or security classification isn't always the best method of determining item sensitivity.

Approving an external organization for access to security classified information doesn't automatically suggest that all users in the organization have need-to-know. Government organizations should apply configurations that provide granular visibility and control over the flow of sensitive information, independently of controls focused on sensitivity labels or classifications. These controls align with Protective Security Policy Framework (PSPF) Policy 9 Requirement 2.

Requirement	Detail
PSPF Policy 9 Requirement 2: Limiting access to sensitive and classified information and resources	To reduce the risk of unauthorized disclosure, entities must ensure access to sensitive and security classified information or resources is only provided to people with a need-to-know.

In addition to ensuring need-to-know, Data Loss Prevention (DLP) policies limit the distribution of sensitive information. DLP policies controlling the flow of sensitive information complement policies that limit the distribution of labeled items by providing an extra layer of data loss prevention. Examples of how content-based (rather than label-based), approaches help with this include situations where:

• A user maliciously downgrades the sensitivity label applied to an item (as discussed in reclassification considerations) and then attempts to exfiltrate it.
• A user copies sensitive information from classified document and pastes it into either an email or Teams chat.
• An adversary who has access via a compromised account sources bulk information from an internal service and attempts to exfiltrate it via email.

In each of these scenarios, approaches that assess actual content rather than the label applied to items are used to help prevent and limit data breach.

Note

Policies to protect sensitive information first depend on information being identified as sensitive. These concepts are covered in detail in identifying sensitive information.

Controlling email of sensitive information

Australian government organizations should ensure that their DLP configurations address:

• The use of Microsoft provided DLP policy templates for detection of sensitive information relevant to Australian data types.
• The use of Sensitive Information Types (SITs) to detect items that are potentially security classified via their protective markings.
• The use of custom SITs and classifiers to detect sensitive information relating Australian government initiatives or services.

Utilizing DLP policy templates for controlling email of sensitive information

An example of sensitive information that State and Federal Government organizations collect and work with is health information. Heath information could be identified via approaches discussed in Named entity sensitive information types.

Health information could be appropriately labeled, and label-based controls such as those included in preventing inappropriate distribution of security classified information applied to it. However, need-to-know still applies. External organizations, regardless of whether they're approved for access to classified information, shouldn't have the ability receive or access such information without a requirement to do so. Further granularity is essential to help address need-to-know.

The following example DLP rule is used to prevent external distribution of health records. This example policy makes use of the preconstructed policy template Australia Health Records Act (HRIP Act) Enhanced, modified to apply to the Exchange service only so that recipient-based restrictions are enforced.

This policy template, rather than just looking for health information, seeks to identify combinations of health information with other information types. Other types of information that is likely to signify a health records includes name, address, and other personal identifiers.

Microsoft provided policy templates allow for low and high-volume policy actions to be defined. By default, low volume is configured as 1 to 9 occurrences and high volume is over 10 occurrences. These thresholds can be further customized.

External organizations that have need-to-know for the information can be added to a list of approved domains via the rule's exception NOT list.

Rule name	Conditions	Action
Low volume of content detected Australia Health Records Act	Content is shared from Microsoft 365, With people outside of my organization AND Content contains any of: - Australia Tax File Number (0 to 9) - Australia Medical Account Number (0 to 9) - Australia Physical Addresses (0 to 9) AND Content contains: - All full names (0 to 9) AND Content contains: - All medical terms and conditions (0 to 9) AND Group NOT Recipient domain is: - List of domains approved for receipt of health information	Notify users with email and policy tips. Configure a policy tip of: "A recipient of this email is from an organization that isn't authorized for receipt of health 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 lower incident severity and appropriate notification options.
High volume of content detected Australia Health Records Act	Content is shared from Microsoft 365, With people outside of my organization AND Content contains any of: - Australia Tax File Number (10 to any) - Australia Medical Account Number (10 to any) - Australia Physical Addresses (10 to any) AND Content contains: - All full names (10 to any) AND Content contains: - All medical terms and conditions (10 to any) AND Group NOT Recipient domain is: - List of domains approved for receipt of health information	Notify users with email and policy tips. Configure a policy tip of: "A recipient of this email is from an organization that isn't authorized for receipt of health 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 high incident severity and appropriate notification options.

A significant benefit of such a DLP rule is that if a malicious user or compromised account were to attempt to exfiltrate a bulk quantity of health records to an unapproved email domain, the action is blocked and administrators notified. The organization can extend these controls to internal users to help ensure that external users engaged in unrelated business functions can't receive this type of health information. Other rules can also be created which apply the same controls to people inside my organization. These rules could make use of an internal group for exceptions rather than a list of external domains.

Note

In order to apply DLP conditions available to the Exchange service, such as recipient domain is, policy templates are applied to Exchange service only. This means each policy template being used multiple times, once for each service. For example:

1. Australia Health Record Act Enhanced for Exchange
2. Australia Health Record Act Enhanced for SharePoint and OneDrive
3. Australia Health Record Act Enhanced for Teams chat and channel messaging

Microsoft provided prebuilt DLP policy templates that should be considered by Australian Government organizations for implementation include:

• Australia Privacy Act Enhanced
• Australia Health Record Act Enhanced
• Australia Financial Data
• PCI Data Security Standard - PCI DSS
• Australia Personally Identifiable Information (PII) Data

Controlling email of marked information via DLP

Sensitivity labels should be used as a key indication of item sensitivity. In most cases, methods of protecting information based on applied labels, as covered in preventing inappropriate distribution of security classified information, provides adequate protection. However, we should also consider situations where:

• Content is copied from a classified item.
• Items are received from external government organizations and are marked but are yet to be labeled.
• Items were created prior to sensitivity label deployment and don't yet have labels applied to them.

In situations where items are yet to be labeled, a combination of client-based auto-labeling and service-based auto-labeling can be used to apply labels to items. Client-based recommendations are applied when a user opens a file. Service-based auto-labeling indexes and labels items at rest.

In order to further increase the layers of protections, content identification methods, as demonstrated in example SIT syntax to detect protective markings, can be used to find protective markings. Once identified, protections can be applied to items that align with the markings associated security classification. This allows for items to be protected in situations where users ignore client label recommendations or service-based auto-labeling hasn't yet processed items.

Tip

Australian Government organizations should implement DLP policies which check for protective markings in email. Policies should be created to target both PROTECTED and OFFICIAL: Sensitive markings. Additional configuration can be applied to the subsets such as markings with the CABINET caveat.

As an example, the following DLP rule applies to the Exchange service only. The rule identifies PROTECTED markings on email and then prevents all but approved organizations from receiving it.

Note

This rule is a copy of the example provided at example DLP Rule: Block PROTECTED email to nonapproved organizations. However, it uses SITs in policy conditions rather than sensitivity labels. It includes exceptions that ensure that it doesn't trigger against labelled items, which are also likely to contain the matching SITs.

Conditions

Action

Content is shared from Microsoft 365, with people outside of my organization AND Content contains Sensitive Info Type: - Select all PROTECTED SITs AND Group NOT Content contains Sensitivity label: - Select 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.

Implications to malicious label downgrade

Microsoft's trust but verify approach to security classification allows for users to change the sensitivity label applied to items. This capability aligns to PSPF Policy 8 requirement 3, which is discussed in reclassification considerations.

Requirement	Detail
PSPF Policy 8 Requirement 3 - Declassification (v2018.6)	The originator must remain responsible for controlling the sanitization, reclassification, or declassification of the information. An entity must not remove or change information's classification without the originator’s approval.

Email conversations that Australian government representatives participate in have protective makings applied to them. These are present in the email x-headers, but also in subject markings and text-based visual markings throughout the conversation history.

If a classification applied to an email conversation is downgraded, for example, from 'PROTECTED Personal Privacy' to 'UNOFFICIAL,' it triggers label change justification, generates auditable events, and is further factored into Insider Risk Management (IRM). Following this occurrence, the previously applied subject markings and text-based visual markings are identifiable in the emails previous replies via SIT. For example, a SIT with the following RegEx identifies 'PROTECTED // Personal Privacy' in an email header and [SEC=PROTECTED, Access=Personal-Privacy] in a subject marking:

PROTECTED(?:\s\|\/\/\|\s\/\/\s\|,\sACCESS=)Personal[ -]Privacy

The example DLP rules provided in the previous section (controlling email of marked information via DLP), identifies the item as PROTECTED and blocks exfiltration regardless of the applied sensitivity label. Careful DLP policy ordering, along with appropriate reporting actions, also allows for situations where an email is blocked due to SIT rather than label to be flagged with security teams as a priority incident.

An alternative method of addressing downgrade would be to implement a policy, which checks the applied label against markings that can be detected in the email's body. For example, Contains sensitivity label UNOFFICIAL, OFFICIAL, OFFICIAL: Sensitive AND Contains sensitive information type PROTECTED. Such incremental downgrade occurrences provide strong indication of inappropriate label downgrade and warrants further investigation. DLP policies making use of such conditional also provide a method of adhering with ISM-1089:

Requirement	Detail
ISM-1089 (v2018.6)	Protective marking tools don't allow users replying to or forwarding emails to select protective markings lower than previously used.

Note

Blocking distribution of information based on protective marking rather sensitivity label provides benefits in terms of data security but may lead to situations where items that have had their classifications intentionally lowered being blocked from distribution. Establishment of business rules regararding declassification and use DLP policy actions that permit override when there are business requirements to do so.

Controlling email of custom SITs via DLP

Information identification methods such as custom sensitive information types and other capabilities discussed in identifying sensitive information, provide a means to detect sensitive information relevant to an individual organization. SITs and trainable classifiers are created to address specific Australian Government information protection requirements. These SITs are then utilized in DLP policies that control the distribution of items containing the identified information.

An example of a requirement that is common across Australian government organizations is the need to protect accountable material, such as information relating to sensitive codewords or initiatives. To achieve this, a SIT or set of SITs could be created containing a list of keywords or terms. This SIT could then be utilized in a DLP policy to warn users, potentially requiring that they enter business justification before sending, or outright blocking the communication.

The following DLP rule example applies to the Exchange service. It detects email containing sensitive codewords and when detected, displays a policy tip to users. Users need to provide a business justification and acknowledge warnings before sending the email.

Conditions

Action

Content is shared from Microsoft 365, With people outside of my organization AND Content contains Sensitive Info Type: - Sensitive Codewords SIT

Configure a policy tip of: "This email contains a sensitive term, which may not be appropriate for a specified recipient. Ensure that all recipients are authorized for access to the enclosed information before sending." Allow users to override policy restrictions: - Require a business justification to override - Require the end user to explicitly acknowledge the override Configure appropriate incident severity and notification options.

Limiting external chat containing sensitive content

DLP policies can be configured to apply to Teams chat and channel messages. This configuration is most relevant to organizations who have implemented flexible collaboration options, such as the ability to chat with external users. Such organizations desire increased productivity through collaboration but is concerned about loss of sensitive information via collaboration avenues such as Teams chat and channel messaging.

Note

DLP policies for both Exchange and Microsoft Teams can target or exclude specific recipient domains. This allows for domain-based exceptions to be applied, helping to ensure need-to-know and alignment with PSPF Policy 9 Requirement 2.

DLP approaches for Teams should:

• Make use of Microsoft provided DLP policy templates for detection of sensitive information relevant to Australian data types.

  Microsoft provided DLP policy templates, as demonstrated in utilizing DLP policy templates for controlling email of sensitive information, should be used to identify, and protect sensitive information from being communicated via Teams.

• Include the use of SITs to detect protective markings that may have been pasted from classified items into the Teams application.

  Presence of a protective marking in Teams chat provides an indication of inappropriate disclosure. The policy demonstrated in controlling email of marked information via DLP identifies sensitive information via protective markings. If a similar policy configuration were applied to Teams, then it could identify markings that have been pasted into Teams chat. For example, content from a classified email discussion identified via the headers, footers or subject markings that may be present in this text-based data.

• Use custom SITs and classifiers to detect sensitive information relating Australian government initiatives or services.

  Custom SITs are used to identify sensitive keywords or terms being used in Teams chat or channel messaging. The example provided controlling email of custom SITs via DLP can be applied to the Teams service.

Monitoring external chat via Communication Compliance

Communication Compliance offers an alternative approach to DLP where events aren't necessarily blocked, but policy violations are flagged for review. Administrators can then view policy matches to better understand the full context of the situation and analyze appropriateness according to organizational policies.

Communication Compliance policies can be configured to review outgoing chat containing combinations of SITs. These policies can replicate the SIT combinations relevant to Australian data types used in utilizing DLP policy templates for controlling email of sensitive information.

Note

Communication Compliance includes Optical Character Recognition (OCR) capability which allows it to screen scanned documents for sensitive information.

Controlling sharing of sensitive information through DLP

Sensitivity labels are the primary method of identifying sensitive information. Label-based DLP controls, as discussed in preventing sharing of security classified information, should be considered our primary method of data loss prevention for sharing activities. In Microsoft Purview's layered approach, DLP policies can be further configured to identify sensitive content within items. Once content is identified, we can apply sharing restrictions independently of an item's sensitivity label. Doing so addresses situations where:

• Items have been mislabeled.
• Items have been received from external government organizations and are marked but are yet to be labeled.
• Items that were created prior to sensitivity label deployment and don't yet have labels applied to them.

Note

ASD's Blueprint for Secure Cloud includes guidance for SharePoint sharing configuration. This advice recommends restricting all sharing links to only people in your organization.

Australian Government organizations should consider DLP policies applying to SharePoint and OneDrive services that:

• Include the use of SITs to detect items that contain protective markings.

  Protective markings provide a backup method for identification of the sensitivity of items. DLP policies are configured using SITs provided in example SIT syntax to detect protective markings that align with security classifications (OFFICIAL: Sensitive and PROTECTED). Items containing these markings have sharing restrictions applied.

• Make use of Microsoft provided DLP policy templates for detection of sensitive information relevant to Australian data types.

  Microsoft provided DLP policy templates, as demonstrated in utilizing DLP policy templates for controlling email of sensitive information, identifies, and protects sensitive information being shared from SharePoint or OneDrive locations. Policy templates relevant to Australian Government include:

  • Australia Privacy Act Enhanced
  • Australia Health Record Act Enhanced
  • Australia Financial Data
  • PCI Data Security Standard - PCI DSS
  • Australia Personally Identifiable Information (PII) Data

• Use custom SITs and classifiers to detect sensitive information relating Australian government initiatives or services.

  Custom SITs are used to identify sensitive keywords or terms included in items that are being shared via SharePoint or OneDrive. The example provided controlling email of custom SITs via DLP could be applied to SharePoint and OneDrive services.

Monitor sharing of sensitive information with Defender for Cloud Apps

Microsoft Defender for Cloud Apps delivers protection for Software as a Service (SaaS) applications, including online applications and online storage services.

SharePoint sharing configuration allows a list of domains to be configured that are approved for the receipt of sharing links and is configured to align with PSPF Policy 9 Requirement 1:

Requirement	Detail
PSPF Policy 9 Requirement 1 - Formalized agreements for sharing information and resources	When disclosing security classified information or resources to a person or organization outside of government, entities must have in place an agreement or arrangement, such as a contract or deed, governing how the information is used and protected.

With Defender for Cloud Apps, we can extend our DLP monitoring capabilities. For example, a policy is created to check for the sharing of items that include a combination of SITs to anonymous email addresses. Administrators can remove sharing permissions for the external users and complete various reporting actions.

Defender for Cloud Apps also provides some aggregated reporting, alerting admin teams to users with abnormally high policy violations.

For more information on the use of Defender for Cloud Apps for monitoring or controlling sharing activities, see file policies in Microsoft Defender for Cloud Apps.

Monitoring sensitive information with insider risk management

Insider risk management is a compliance solution that helps minimize internal risks by enabling you to detect, investigate, and act on malicious and inadvertent activities in your organization.

For more information on insider risk management, see learn about insider risk management.

Monitoring the sharing of sensitive information and acting on occurrences of potential unauthorizes disclosure aligns with PSPF Policy 9 Requirement 2:

Requirement	Detail
PSPF Policy 9 Requirement 2 - Limiting access to security classified information and resources	To reduce the risk of unauthorized disclosure, entities must ensure access to security classified information or resources is only provided to people with a need-to-know.

Insider Risk Management records statistics on risk activities by users and provides metrics to security teams, allowing them to further investigate risk events.

Insider Risk Management policies can be configured to focus on activities surrounding sensitive information. Activities can include risk sequence detection, such as data theft by departing users and data leaks by risky users.

Insider Risk Management policies also be configured to align with DLP policies such as those suggested in this article. Suspicious activity surrounding sensitive information can be reported to security teams or automatically mitigated through Adaptive Protection.

Controlling sensitive information with Adaptive Protection

IRM integrates with Microsoft Purview DLP policies via a capability called Adaptive protection. IRM identifies users who are deemed as risky due them continually triggering configured policies. Adaptive protection automatically imposes restrictions on identified risky users, mitigating some risk until security teams can investigate.

When used in this way, Adaptive Protection aligns with PSPF Policy 8 Requirement 3:

Requirement	Detail
PSPF Policy 8 Core Requirement 3	Implement operational controls for these information holdings proportional to their value, importance, and sensitivity