Service-based auto-labeling recommendations for Australian Government compliance with PSPF
This article provides guidance for Australian Government organizations on configurations to help protect security classified information through the use of service-based sensitivity auto-labeling policies. Its purpose is to help government organizations to improve their information security posture, particularly for scenarios where information is passed between government organizations. Advice in this article has been written to best align with requirements outlined in the Protective Security Policy Framework (PSPF) (in particular PSPF Policy 8 Annex F: Australian Government Email Protective Marking Standard) and the Information Security Manual (ISM).
The previous article, Auto-labeling overview, provides additional high level information on where the use of auto-labeling is suitable in a modern Government work environment and how it helps to reduce data security risks.
Service-based auto-labeling capability enables:
- Scanning emails for sensitive content and applying labels to them during transport: Australian Government organizations can use this capability to:
- Label marked email received from other Protective Security Policy Framework (PSPF) or equivalent enabled organizations.
- Labeling email received from non-PSPF enabled organizations via the detection of sensitive information or other identifiers.
- Scanning existing items in SharePoint locations (SharePoint/OneDrive/Teams) for protective markings or sensitive content and applying labels to them: Australian Government organizations can use this capability to:
- Label existing Microsoft 365 data at rest.
- Migrate from legacy classification tools or taxonomies.
Labeling of email during transport
This article is an extension of the concepts covered under email marking strategies where methods of applying markings to email are discussed.
Service-based auto-labeling policies configured for the Exchange service check for markings on email and apply appropriate labels. Incoming email could have markings or sensitivity labels already applied by sender organizations but these won't, by default, apply any of your organizations label-based protections. Converting external markings or labels into internal labels ensure that Data Loss Prevention (DLP) and other relevant controls are applied.
In the context of Australian Government, identifying characteristics of email would typically include:
- X-Protective-Marking x-headers
- Subject markings
- Text-based headers and footers
Email-based policy configuration
Service-based auto-labeling policies are configured in the Microsoft Purview portal under Information Protection > Policies > Auto-labeling policies.
Auto-labeling policies are similar to DLP policies to create, but unlike the DLP recommendations, a single auto-labeling policy is needed for each label that we want to apply for email-based configuration.
Auto-labeling policies checking for PSPF markings are created from the custom policy template and are named based on the action. For example, Label incoming UNOFFICIAL Email. Policies should also be applied to the Exchange service only to ensure that the required options such as subject contains available to the interface.
To achieve a high level of PSPF maturity, auto-labeling policies should be implemented to complete the following:
- Auto-label based on x-headers applied to incoming email.
- Auto-label based on subject markings applied to incoming email.
- Auto-label based on Sensitive Information Types (SITs) present within the body of incoming email (optional).
One auto-labeling policy is required for each label, potentially with multiple rules within it (one for each of the above scenarios). Settings to automatically replace existing labels aren't required.
Rules checking for x-headers
Rules created to check email X-Protective-Marking x-header's should be named appropriately, for example, 'check for OFFICIAL x-header.'
They need a condition of header matches patterns with a header name of 'x-protective-marking' and a Regular Expression (RegEx) value that can match the x-protective-marking header on incoming email. For example, syntax to identify items marked as 'OFFICIAL: Sensitive Personal Privacy' is:
X-Protective-Marking : SEC=OFFICIAL[-: ]Sensitive(?:,)? ACCESS=Personal-Privacy
In this expression, [-: ] matches either a hyphen, colon, or space, allowing for some flexibility in how the headers are applied, noting that the PSPF specifies a colon.
The pattern of (?:,)? allows for items to be matched regardless of whether a comma is included between security classification and IMM.
Rules checking subject markings
Auto-labeling policies should include a second rule, which checks for subject-based markings. These rules should be named appropriately, for example, 'Check OFFICIAL subject.'
The rules need a condition of subject matches patterns with a value of an appropriate regular expression. For example:
\[SEC=OFFICIAL[-: ]Sensitive(?:,)? ACCESS=Personal-Privacy
In the previous example, the \ escape character is required to ensure that the brackets are treated as part of the email subject and not part of the regular expression.
This syntax doesn't include a closing bracket (\]). The reasoning for this is discussed in approaches for multiple Information Management Markers (IMMs).
Rules checking for SITs
In identifying sensitive information we recommended a set of SITs to identify protective markings. These SITs can also be used in auto-labeling policies applying to email. SITs provide a third method of identifying incoming email classifications and also helps to remediate x-header stripping.
The logic rules require a condition of content contains, sensitive information type and then have the SIT relevant to the classification selected.
Tip
SIT-based rules can generate more false positives than x-header or subject based approaches. Government organizations new to this may consider ttarting with x-header and subject-based rules only, and then stepping up to adding SIT-based rules when comfortable.
Examples of false positives are discussions around classifications and service generated alerts that refer to or include item content, such as DLP alerts. Because of this, SIT based auto-labeling rules should receive extra testing or an extended period of monitoring before full implementation in order to weed out false positives and apply exceptions. Example exceptions would include the 'microsoft.com' domain, which service based alerts are sent from.
There are significant advantages to including SIT based rules. Consider label change justification and the risk of users maliciously lowering the label applied to an email conversation. If a PROTECTED email is lowered to UNOFFICIAL but we can detect '[SEC=PROTECTED]' in the email conversation's body, we could then automatically reapply the PROTECTED label. Doing so brings it back into the scope of the tenant's PROTECTED DLP policies and other controls. There are situations where items are intentionally reclassified to a lower state, for example, a release of a Budget Estimates media brief, which has been embargoed until a specific time, so SIT configuration needs to consider these use cases in the Government Organization.
SIT-based rules can also help to accommodate smaller government organizations who generate email but have lower compliance maturity. Such organizations could be missing more advanced marking methods like x-headers.
Approaches for multiple IMMs
Information Management Markers (IMMs) originate from the Australian Government Recordkeeping Metadata Standard (AGRkMS) and are an optional way to identify information that is subject to nonsecurity related restrictions. As introduced in use of multiple IMMs, AGRkMS defines an IMM or 'rights type' value, which is recorded as a single property. Some Australian Government organizations have extended their use of IMMs by classification taxonomies that allow for multiple IMMs to be applied (for example, 'PROTECTED Personal Privacy Legislative Secrecy').
Use of multiple IMMs can complicate DLP and auto-labeling configurations as regular expressions checking the markings applied to incoming items need to be more complex. There's also a risk that email marked with multiple IMMs, when sent to external organizations, could be misinterpreted by receiving email gateways. This increases the risk of information loss. For these reasons, the examples included in sensitivity label taxonomy and email marking strategies have applied single IMMs only as per the AGRkMS rules.
Organizations using single IMMs only
In order for organizations using single IMMs only to accommodate email received from external organizations with multiple IMMs applied, closing square brackets ('\]') have been omitted from subject-based auto-labeling rules. This allows us to label email based on the first IMM applied to its subject. This approach ensures that items are protected via label-based controls regardless of whether your label taxonomy fully aligns with other government organizations that may send you email.
In terms of x-header based approaches, those applying multiple IMMs to X-Protective-Marking x-headers are likely to do so via the following approach:
X-Protective-Marking : SEC=<Security Classification>, ACCESS=<First IMM>, ACCESS=<Second IMM>
If there are no closing brackets included in the X-Protective-Marking syntax, the item would be labeled based on the first IMM present in the marking. The item would then be protected via the first IMMs controls and visual markings for the second IMM would still be in place on the item.
Organizations applying multiple IMMs
For those who decide they do want to expand their label taxonomy and other configurations to accommodate multiple IMMs outside of AGRkMS rules, they need to ensure that their auto-labeling rules accommodate any possible conflicts. For example, a rule checking for 'SEC=OFFICIAL:Sensitive, ACCESS=Legislative-Secrecy' need to exclude any values with a second IMM applied as otherwise items could be incorrectly labeled with the single IMM only.
Exclusions can be applied by either adding exceptions to auto-labeling rules. For example:
Except if header matches patterns:
X-Protective-Marking : SEC=OFFICIAL:Sensitive, ACCESS=Legislative-Secrecy, ACCESS=Personal-Privacy
X-Protective-Marking : SEC=OFFICIAL:Sensitive, ACCESS=Legislative-Secrecy, ACCESS=Legislative-Secrecy
X-Protective-Marking : SEC=OFFICIAL:Sensitive, ACCESS=Legislative-Secrecy, ACCESS=Legal-Privilege
Or alternatively accommodating for exceptions in the rule's RegEx:
Header matches patterns:
X-Protective-Marking ：SEC=OFFICIAL[-: ]Sensitive, ACCESS=Legislative-Secrecy(?!, ACCESS=)
For SIT-based rules, the syntax included in example SIT syntax to detect protective markings accommodates single IMMs only. These SITs would need to be modified to eliminate false positives and other SITs would need to be added to align with the extra labels.
Auto-labeling information from foreign governments
Many Australian Government organizations deal with marked or classified information from foreign governments. Some of these foreign classifications have equivalence within the PSPF classification taxonomy, which is defined in PSPF Policy 7: Security governance for international sharing. Organizations communicating with foreign governments can use approaches outlined in this guide for translating foreign markings into their PSPF equivalent.
Dealing with legislative secrecy markings
Legislative secrecy shouldn't be applied to items without an indication of the specific legislative secrecy requirements that apply to the information:
| Requirement | Detail |
|---|---|
| PSPF Policy 8 C.4 - Information Management Markers | The legislative secrecy IMM is used to draw attention to the applicability of one or more specific secrecy provisions. The Department of Home Affairs recommends that the recipient is informed of the specific provision by including a warning notice placed at the top or bottom of each page of a document or in the body of an email that expressly identifies the specific secrecy provisions under which the information is covered. |
Microsoft recommends using Legislative Secrecy labels via a label aligned directly with the legislation in question. For example, consider a label structure of:
OFFICIAL Sensitive
- OFFICIAL Sensitive
- OFFICIAL Sensitive Legislative Secrecy
- OFFICIAL Sensitive Legislative Secrecy Example Act
With such a label structure, users working with information relating to the 'Example Act' would apply the 'OFFICIAL Sensitive Legislative Secrecy Example Act' label to relevant information. This label's visual markings should also indicate the act in question. For example, they could apply headers and footers of 'OFFICIAL: Sensitive Legislative Secrecy (Example Act).'
Note
The label of 'OFFICIAL Sensitive Legislative Secrecy Example Act' could have its label display name shortened to 'OFFICIAL Sensitive Example Act' to improve labeling user experience. However, the label's visual marking would need to include all elements in order to support approaches to auto-labeling.
The label and markings provide an indication of the items security classification, the fact that it's relevant to legislative secrecy requirements and the specific legislation being referenced. Markings applied in this order will also allow external organizations that receive the information but don't have the 'Example Act' label configured will identify and treat the information in line with their Legislative Secrecy label. Treating the 'Example Act' as legislative secrecy allows for protections to be applied to the enclosed information.
The Government organization generating the information may require to distinguish the following:
- Their information relating to the 'Example Act,'
- Information relating to other legislation; and
- Information generated externally that relates to legislation that other departments work with.
To implement this, the administrator splits the auto-labeling rules in two and makes use of a SIT to identify information relating to the 'Example Act':
| Rule Name | Condition | Label to apply |
|---|---|---|
| Check for OS LS x-header | Header matches pattern: X-Protective-Marking : SEC=OFFICIAL[-: ]Sensitive, ACCESS=Legislative-Secrecy AND Group NOT Content Contains: Sensitive Information Type Example ACT Keyword SIT containing: (Example Act) |
OFFICIAL Sensitive Legislative Secrecy |
| Check for OS LS subject | Subject matches pattern: \[SEC=OFFICIAL[-: ]Sensitive(?:,)? ACCESS=Legislative-Secrecy AND Group NOT Content Contains: Sensitive Information Type: Example ACT Keyword SIT containing: (Example Act) |
OFFICIAL Sensitive Legislative Secrecy |
| Check for OS Example Act x-header | Header matches pattern: X-Protective-Marking : SEC=OFFICIAL[-: ]Sensitive, ACCESS=Legislative-Secrecy AND Content Contains: Sensitive Information Type Example ACT Keyword SIT containing: (Example Act) |
OFFICIAL Sensitive Example Act |
| Check for OS Example Act subject | Subject matches pattern: \[SEC=OFFICIAL[-: ]Sensitive(?:,)? ACCESS=Legislative-Secrecy AND Content Contains: Sensitive Information Type: Example ACT Keyword SIT containing: (Example Act) |
OFFICIAL Sensitive Example Act |
Example email-based auto-labeling configuration
The example auto-labeling policies listed here automatically apply sensitivity labels to incoming email based on the marking applied by external Government organizations.
The following example policies shouldn't be the entirety of an organizations auto-labeling configuration as other scenarios such as those listed labeling existing items at rest should also be considered.
Policy Name: Label incoming UNOFFICIAL Email
| Rule Name | Condition | Label to apply |
|---|---|---|
| Check for UNOFFICIAL x-header | Header matches pattern: X-Protective-Marking : SEC=UNOFFICIAL |
UNOFFICIAL |
| Check for UNOFFICIAL subject | Subject matches pattern: \[SEC=UNOFFICIAL\] |
UNOFFICIAL |
Policy Name: Label incoming OFFICIAL Email
This policy needs to ensure that items, which are marked as OFFICIAL aren't incorrectly labeled as OFFICIAL Sensitive. It uses the not RegEx operand (?!) for x-headers and closing brackets (\]) in the email subjects to achieve this:
| Rule Name | Condition | Label to apply |
|---|---|---|
| Check for OFFICIAL x-header | Header matches pattern: X-Protective-Marking : SEC=OFFICIAL(?![-: ]Sensitive) |
OFFICIAL |
| Check for OFFICIAL subject | Subject matches pattern: \[SEC=OFFICIAL\] |
OFFICIAL |
Policy Name: Label incoming OFFICIAL Sensitive Email
This policy needs to ensure that items, which are marked with extra IMMs (personal privacy, etc.) or caveats aren't incorrectly labeled as OFFICIAL Sensitive. To do this, it looks for IMMs or caveats applied to the x-header and closing brackets (\]) in the subject.
This example checks for a caveat for NATIONAL CABINET as it is the only caveat defined for use in combination with OFFICIAL Sensitive in this recommended configuration. If your organization makes use of other caveats in its taxonomy, the caveat should also be accounted for in the expression to help ensure that received items have the correct label applied to them.
| Rule Name | Condition | Label to apply |
|---|---|---|
| Check for OS x-header | Header matches pattern: X-Protective-Marking : OFFICIAL[:\- ]\s?Sensitive(?!, ACCESS)(?!, CAVEAT=SH[-: ]NATIONAL[- ]CABINET) |
OFFICIAL Sensitive |
| Check for OS subject | Subject matches pattern: \[SEC=OFFICIAL[-: ]Sensitive\] |
OFFICIAL Sensitive |
Policy Name: Label incoming OFFICIAL Sensitive Personal Privacy Email
| Rule Name | Condition | Label to apply |
|---|---|---|
| Check for OS PP x-header | Header matches pattern: X-Protective-Marking : SEC=OFFICIAL[-: ]Sensitive, ACCESS=Personal-Privacy |
OFFICIAL Sensitive Personal Privacy |
| Check for OS PP subject | Subject matches pattern: \[SEC=OFFICIAL[-: ]Sensitive(?:,)? ACCESS=Personal-Privacy |
OFFICIAL Sensitive Personal Privacy |
Policy Name: Label incoming OFFICIAL Sensitive Legal Privilege Email
| Rule Name | Condition | Label to apply |
|---|---|---|
| Check for OS LP x-header | Header matches pattern: X-Protective-Marking : SEC=OFFICIAL[-: ]Sensitive, ACCESS=Legal-Privilege |
OFFICIAL Sensitive Legal Privilege |
| Check for OS LP subject | Subject matches pattern: \[SEC=OFFICIAL[-: ]Sensitive(?:,)? ACCESS=Legal-Privilege |
OFFICIAL Sensitive Legal Privilege |
Policy Name: Label incoming OFFICIAL Sensitive Legislative Secrecy
| Rule Name | Condition | Label to apply |
|---|---|---|
| Check for OS LS x-header | Header matches pattern: X-Protective-Marking : SEC=OFFICIAL[-: ]Sensitive, ACCESS=Legislative-Secrecy |
OFFICIAL Sensitive Legislative Secrecy |
| Check for OS LS subject | Subject matches pattern: \[SEC=OFFICIAL[-: ]Sensitive(?:,)? ACCESS=Legislative-Secrecy |
OFFICIAL Sensitive Legislative Secrecy |
Policy Name: Label incoming OFFICIAL Sensitive NATIONAL CABINET
| Rule Name | Condition | Label to apply |
|---|---|---|
| Check for OS NC x-header | Header matches pattern: X-Protective-Marking : SEC=OFFICIAL[-: ]Sensitive, CAVEAT=SH[-: ]NATIONAL[- ]CABINET |
OFFICIAL Sensitive NATIONAL CABINET |
| Check for OS NC subject | Subject matches pattern: \[SEC=OFFICIAL[-: ]Sensitive(?:,)? CAVEAT=SH[-: ]NATIONAL[- ]CABINET |
OFFICIAL Sensitive NATIONAL CABINET |
Policy Name: Label incoming PROTECTED Email
This policy ensures that items that are marked with extra IMMs or caveats aren't incorrectly labeled as PROTECTED. To do this, it looks for IMMs or caveats applied to the x-header and closing brackets (\]) in the subject.
| Rule Name | Condition | Label to apply |
|---|---|---|
| Check for PROTECTED x-header | Header matches pattern: X-Protective-Marking : SEC=PROTECTED(?!, ACCESS)(?!, CAVEAT=SH[-: ]CABINET)(?!, CAVEAT=SH[-: ]NATIONAL[- ]CABINET) |
PROTECTED |
| Check for PROTECTED Subject | Subject matches pattern: \[SEC=PROTECTED\] |
PROTECTED |
Policy Name: Label incoming PROTECTED Personal Privacy Email
| Rule Name | Condition | Label to apply |
|---|---|---|
| Check for PROTECTED PP x-header | Subject matches pattern: X-Protective-Marking : SEC=PROTECTED(?:,)? ACCESS=Personal-Privacy |
PROTECTED Personal Privacy |
| Check for PROTECTED PP Subject | Header matches pattern: \[SEC=PROTECTED(?:,)? ACCESS=Personal-Privacy |
PROTECTED Personal Privacy |
Policy Name: Label incoming PROTECTED Legal Privilege Email
| Rule Name | Condition | Label to apply |
|---|---|---|
| Check for PROTECTED LP x-header | Header matches pattern: X-Protective-Marking : SEC=PROTECTED(?:,)? ACCESS=Legal-Privilege |
PROTECTED Legal Privilege |
| Check for PROTECTED LP Subject | Subject matches pattern: \[SEC=PROTECTED(?:,)? ACCESS=Legal-Privilege |
PROTECTED Legal Privilege |
Policy Name: Label incoming PROTECTED Legislative Secrecy Email
| Rule Name | Condition | Label to apply |
|---|---|---|
| Check for PROTECTED LS x-header | Header matches pattern: X-Protective-Marking : SEC=PROTECTED(?:,)? ACCESS=Legislative-Secrecy |
PROTECTED Legislative Secrecy |
| Check for PROTECTED LS Subject | Subject matches pattern: \[SEC=PROTECTED(?:,)? ACCESS=Legislative-Secrecy |
PROTECTED Legislative Secrecy |
Policy Name: Label incoming PROTECTED CABINET Email
| Rule Name | Condition | Label to apply |
|---|---|---|
| Check for P C x-header | Header matches pattern: X-Protective-Marking : SEC=PROTECTED, CAVEAT=SH[-: ]CABINET |
PROTECTED CABINET |
| Check for PROTECTED C subject | Subject matches pattern: \[SEC=PROTECTED(?:,)? CAVEAT=SH[-: ]CABINET |
PROTECTED CABINET |
Policy Name: Label incoming PROTECTED NATIONAL CABINET Email
| Rule Name | Condition | Label to apply |
|---|---|---|
| Check for P NC x-header | Header matches pattern: X-Protective-Marking : SEC=PROTECTED, CAVEAT=SH[-: ]NATIONAL[- ]CABINET |
PROTECTED NATIONAL CABINET |
| Check for P NC subject | Subject matches pattern: \[SEC=PROTECTED(?:,)? CAVEAT=SH[-: ]NATIONAL[- ]CABINET |
PROTECTED NATIONAL CABINET |
SIT-based auto-labeling are created following the advice in rules checking for SITs.
Labeling existing items at rest
Auto-labeling policies can be configured to scan items residing in OneDrive and SharePoint locations (which includes Teams underlying team sites) for protective markings or sensitive information. Policies can be targeted at the individual OneDrive locations of specific users, a set of SharePoint sites, or the entire service.
Policies can be configured to look for each of the information identification methods that were introduced under identifying sensitive information. These include:
- Prebuilt SITs, such as those created by Microsoft for the identification of information relating to the Australian Privacy Act or Australian Health Records Act.
- Custom SITs that may be created to identify government or organization specific information, such as Clearance IDs, Freedom of Information (FOI) Request number, etc.
- Exact Data Match SITs that have been generated based on actual exports of information.
- Any combination of Prebuilt, Custom and/or Exact Data Match SITs that might accurately identify sensitive information.
There are also newly released contextual predicate capabilities that can be configured to identify items based on document property, file extension, or document name. These predicates are useful for organizations wanting to consider classifications that have been applied via non-Microsoft classification tools, which typically apply document properties to items. For more information on contextual predicate, see learn how Microsoft Purview Information Protection discovers and protects your most sensitive data.
The primary use case for these capabilities is to ensure that existing information has the correct label applied. This ensures that:
- Legacy information, including that uploaded from on-premises locations, is protected via Microsoft Purview's label-based controls.
- Files marked with historical classifications or via non-Microsoft tools have a label applied and are therefore protected by label-based controls.
SharePoint-based policy configuration
SharePoint based auto-labeling policies are configured within the Microsoft Purview compliance portal under Information Protection > policies > auto-labeling policies.
Policies should target SharePoint based services. As a policy is required for each sensitivity label that is auto applied, the policies should be named appropriately. For example, 'SPO - label OFFICIAL Sensitive PP items.'
Policies can make use of custom SITs constructed for identifying marked items. For example, a SIT including a registry expression of the following identifies OFFICIAL Sensitive Personal Privacy markings applied by either the text-based visual markings that are applied at the top and bottom of documents or email subject markings:
OFFICIAL[:\- ]\s?Sensitive(?:\s|\/\/|\s\/\/\s|,\sACCESS=)Personal[ -]Privacy
A full set of SITs aligning with boilerplate Australian Government markings has been provided in example SIT syntax to detect protective markings.
The auto-labeling policy contains a rule with conditions of content contains, sensitive info types,* followed by the SIT aligning with the protective marking.
Once created, this policy runs in simulation mode allowing administrators to validate the configuration before any automated application of labels.
Once enabled, the policy works in the background applying labels, to up to 25,000 office documents per day.
Example SharePoint-based auto-labeling policies
The following scenarios and example configurations mitigate information risks by ensuring that all items are within the scope of appropriate data security controls.
Auto-labeling post sensitivity labeling deployment
After an organization deploys sensitivity labeling, any documents created from that point forward will have sensitivity labels applied. This is due to mandatory labeling configuration. However, items created before this point are at risk. To address this, organizations can deploy a set of auto-labeling policies that look for markings applied to documents. If a marking is identified that aligns with a sensitivity label, the policy then completes this labeling activity.
These auto-labeling policy examples make use of the SITs defined in example SIT syntax to detect protective markings. The auto-labeling policies need to include a condition of content contains, sensitive information type and then include the SIT aligning with the policies label:
| Policy name | SIT | Sensitivity label |
|---|---|---|
| SPO - label UNOFFICIAL items | UNOFFICIAL Regex SIT | UNOFFICIAL |
| SPO - label OFFICIAL items | OFFICIAL Regex SIT | OFFICIAL |
| SPO - label OFFICIAL Sensitive items | OFFICIAL Sensitive Regex SIT | OFFICIAL Sensitive |
| SPO - label OFFICIAL Sensitive PP items | OFFICIAL Sensitive Personal Privacy Regex SIT | OFFICIAL Sensitive Personal Privacy |
| SPO - label OFFICIAL Sensitive LP items | OFFICIAL Sensitive Legal Privilege Regex SIT | OFFICIAL Sensitive Legal Privilege |
| SPO - label OFFICIAL Sensitive LS items | OFFICIAL Sensitive Legislative Secrecy Regex SIT | OFFICIAL Sensitive Legislative Secrecy |
| SPO - label OFFICIAL Sensitive NC items | OFFICIAL Sensitive NATIONAL CABINET Regex SIT | OFFICIAL Sensitive NATIONAL CABINET |
| SPO - label PROTECTED items | PROTECTED Regex SIT | PROTECTED |
| SPO - label PROTECTED PP items | PROTECTED Personal Privacy Regex SIT | PROTECTED Personal Privacy |
| SPO - label PROTECTED LP items | PROTECTED Legal Privilege Regex SIT | PROTECTED Legal Privilege |
| SPO - label PROTECTED LS items | PROTECTED Legislative Secrecy Regex SIT | PROTECTED Legislative Secrecy |
| SPO - label PROTECTED NC items | PROTECTED NATIONAL CABINET Regex SIT | PROTECTED NATIONAL CABINET |
| SPO - label PROTECTED C items | PROTECTED CABINET Regex SIT | PROTECTED CABINET |
Auto-labeling items with historical classifications
As discussed in recommendations based on historical markings, Australian Government marking requirements do occasionally change. In 2018, PSPF requirements were simplified, which included consolidation of several Dissemination Limiting Markers (DLMs) into a single 'OFFICIAL: Sensitive' marking. PSPF Policy 8 Annex E provides a full list of historical classifications and markings along with their current handling requirements. Some of these historical DLMs have equivalent markings in the current framework. Other don't but handling requirements still apply. Labels can be useful in helping organizations to ensure that they're able to meet their handling requirements.
There are two possible approaches to this:
- Apply a modern equivalent of the historical label.
- Implement the historical label transparently. Include DLP and other policies to protect the information but don't publish the label to users.
To implement the first of these approaches, a mapping strategy needs to be developed which aligns historical to current markings by the organization. This alignment can be complex as not all markings have a current equivalent and some will require government organizations to make decisions around whether existing items should have IMMs applied to them. The following table is provided as an example only.
| Historical marking | Sensitivity label |
|---|---|
| For Official Use Only (FOUO) | OFFICIAL Sensitive |
| Sensitive | OFFICIAL Sensitive |
| Sensitive: Legal | OFFICIAL Sensitive Legal Privilege |
| Sensitive: Personal | OFFICIAL Sensitive Personal Privacy |
| Sensitive: Cabinet | PROTECTED CABINET |
After organizations define a mapping, SITs need to be created to identify the historical markings. For markings like 'For Official Use Only (FOUO),' this is as simple as creating a keyword SIT including this term. However, this approach might not be appropriate for less descriptive markings such as 'Sensitive' which is likely to result in numerous false positives.
Government organizations should assess legacy data to determine if there are any other characteristics that could be used to more accurately identify historical markings, such as disclaimers, document properties, or other markers that may be present on historical items.
Following analysis of legacy data, creation of SITs to identify marked items and Auto-labeling policy deployment, administrators can run a simulation to determine label application accuracy and expected timeframe for completion. Auto-labeling application to legacy files can then run in the background, monitored by Microsoft 365 organizational administrators.
Auto-labeling following Machinery of Government change
Machinery of Government (MoG) changes typically involve movement of responsibilities and resources between government organizations. When a function moves from one organization to another, it's common for the information relating to that function to also require handover. As sensitivity labels are only relevant within a single Microsoft 365 environment, when items are passed to a second organization, their applied label isn't carried over. Protective markings still apply but controls such as label-based DLP and data out of place alerting are likely to slip. To address this, auto-labeling policies could be run over content received from external sources to ensure that the right labels are applied based on the item's existing protective markings.
The configuration to achieve this is the same as described under auto-labeling post sensitivity labeling deployment. The only exception is that policies are targeted at the specific locations that received items are stored.