Data-35018: Downgrade Justification Required for Sensitivity Labels #755
Conversation
There was a problem hiding this comment.
Pull request overview
This PR introduces a new security assessment test (ID: 35018) that verifies whether Microsoft 365 sensitivity label policies require users to provide justification when downgrading or removing classification labels. This control helps maintain audit trails and prevents silent reduction of data classification levels.
Key Changes:
- Added PowerShell test script to check if enabled label policies have the
requiredowngradejustificationsetting enabled - Created markdown documentation explaining the security rationale and remediation steps
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 6 comments.
| File | Description |
|---|---|
| src/powershell/tests/Test-Assessment.35018.ps1 | Implements the assessment logic to query label policies, parse settings, and evaluate downgrade justification requirements |
| src/powershell/tests/Test-Assessment.35018.md | Provides documentation on the security risk, remediation steps, and reference links |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| if ($investigateReason) { | ||
| $testStatus = 'Investigate' | ||
| } | ||
| elseif ($policiesWithDowngradeJustification.Count -gt 0) { | ||
| $testStatus = 'Pass' | ||
| } | ||
| else { | ||
| $testStatus = 'Fail' | ||
| } |
There was a problem hiding this comment.
When an error occurs in the inner try-catch block (lines 64-105), $investigateReason is set but the error is logged at Warning level instead of Error level. Additionally, the test continues processing other policies even when one policy fails. Consider whether partial failures should result in an 'Investigate' status or if successfully processed policies should still contribute to Pass/Fail determination. The current logic (line 109-117) will mark the test as 'Investigate' even if only one policy failed but others passed.
| When sensitivity label policies do not require users to provide justification when removing or downgrading labels, users can silently reduce the classification level of sensitive content without creating an audit trail explaining why. This creates a compliance and audit risk because organizations lose visibility into intentional label downgrades that may indicate inappropriate access to sensitive data. When a user removes a "Confidential" label and replaces it with "Internal" or no label at all, organizations should require explicit justification to create an audit record of this action. Downgrade justification is a lightweight control that increases accountability for label decisions without significantly impacting user workflows. When justification is not required, compromised user accounts or departing employees could systematically downgrade labels on sensitive documents to enable data exfiltration, leaving no clear audit trail of the unauthorized changes. Configuring downgrade justification requirements on sensitivity label policies ensures that any intentional reduction in classification level is logged with a user-provided business reason, supporting both compliance audits and insider threat investigations. Downgrade justification should be configured alongside other label controls (mandatory labeling, default labels, and mandatory enforcement) to create a comprehensive data governance framework. | ||
|
|
There was a problem hiding this comment.
Line 1 is extremely long (over 1000 characters) with no paragraph breaks, making it very difficult to read. Consider breaking this into multiple paragraphs to improve readability. For example, separate the problem statement, the risk explanation, and the solution recommendation into distinct paragraphs.
| When sensitivity label policies do not require users to provide justification when removing or downgrading labels, users can silently reduce the classification level of sensitive content without creating an audit trail explaining why. This creates a compliance and audit risk because organizations lose visibility into intentional label downgrades that may indicate inappropriate access to sensitive data. When a user removes a "Confidential" label and replaces it with "Internal" or no label at all, organizations should require explicit justification to create an audit record of this action. Downgrade justification is a lightweight control that increases accountability for label decisions without significantly impacting user workflows. When justification is not required, compromised user accounts or departing employees could systematically downgrade labels on sensitive documents to enable data exfiltration, leaving no clear audit trail of the unauthorized changes. Configuring downgrade justification requirements on sensitivity label policies ensures that any intentional reduction in classification level is logged with a user-provided business reason, supporting both compliance audits and insider threat investigations. Downgrade justification should be configured alongside other label controls (mandatory labeling, default labels, and mandatory enforcement) to create a comprehensive data governance framework. | |
| When sensitivity label policies do not require users to provide justification when removing or downgrading labels, users can silently reduce the classification level of sensitive content without creating an audit trail explaining why. This creates a compliance and audit risk because organizations lose visibility into intentional label downgrades that may indicate inappropriate access to sensitive data. | |
| When a user removes a "Confidential" label and replaces it with "Internal" or no label at all, organizations should require explicit justification to create an audit record of this action. Downgrade justification is a lightweight control that increases accountability for label decisions without significantly impacting user workflows. | |
| When justification is not required, compromised user accounts or departing employees could systematically downgrade labels on sensitive documents to enable data exfiltration, leaving no clear audit trail of the unauthorized changes. Configuring downgrade justification requirements on sensitivity label policies ensures that any intentional reduction in classification level is logged with a user-provided business reason, supporting both compliance audits and insider threat investigations. Downgrade justification should be configured alongside other label controls (mandatory labeling, default labels, and mandatory enforcement) to create a comprehensive data governance framework. |
| - [Plan for sensitivity labels](https://learn.microsoft.com/en-us/microsoft-365/compliance/sensitivity-labels#plan-for-sensitivity-labels) | ||
| - [Create and publish sensitivity labels](https://learn.microsoft.com/en-us/microsoft-365/compliance/create-sensitivity-labels) | ||
| - [Require users to provide justification to change a label](https://learn.microsoft.com/en-us/purview/sensitivity-labels-office-apps#require-users-to-provide-justification-to-change-a-label) | ||
| - [Plan your sensitivity label solution](https://learn.microsoft.com/en-us/microsoft-365/compliance/sensitivity-labels#plan-for-sensitivity-labels) |
There was a problem hiding this comment.
The link on line 14 appears to be a duplicate of the link on line 17. Both point to the same URL about planning for sensitivity labels. Consider removing one of these duplicate references to avoid redundancy.
| - [Plan your sensitivity label solution](https://learn.microsoft.com/en-us/microsoft-365/compliance/sensitivity-labels#plan-for-sensitivity-labels) |
| $policyDetail = [PSCustomObject]@{ | ||
| PolicyName = $policy.Name | ||
| Enabled = $policy.Enabled | ||
| RequireDowngradeJustification = $hasDowngradeJustification | ||
| PolicyScope = if ($policy.ExchangeLocation -and $policy.ExchangeLocation.Type.value -ne 'Tenant') { 'Scoped' } else { 'Global' } |
There was a problem hiding this comment.
The PolicyScope logic appears incorrect. It checks if ExchangeLocation.Type.value is not 'Tenant' to determine 'Scoped', but this will mark policies as 'Global' when ExchangeLocation is null or when Type.value equals 'Tenant'. This logic may not accurately distinguish between global and scoped policies. Consider verifying the correct property to check for policy scope, or implement a more robust check that handles null values and different location types appropriately.
| $policyDetail = [PSCustomObject]@{ | |
| PolicyName = $policy.Name | |
| Enabled = $policy.Enabled | |
| RequireDowngradeJustification = $hasDowngradeJustification | |
| PolicyScope = if ($policy.ExchangeLocation -and $policy.ExchangeLocation.Type.value -ne 'Tenant') { 'Scoped' } else { 'Global' } | |
| $policyScope = 'Unknown' | |
| if ($policy.ExchangeLocation) { | |
| $locType = $null | |
| if ($policy.ExchangeLocation.Type -and $policy.ExchangeLocation.Type.Value) { | |
| $locType = $policy.ExchangeLocation.Type.Value | |
| } | |
| if ($locType) { | |
| if ($locType -eq 'Tenant') { | |
| $policyScope = 'Global' | |
| } | |
| else { | |
| $policyScope = 'Scoped' | |
| } | |
| } | |
| } | |
| $policyDetail = [PSCustomObject]@{ | |
| PolicyName = $policy.Name | |
| Enabled = $policy.Enabled | |
| RequireDowngradeJustification = $hasDowngradeJustification | |
| PolicyScope = $policyScope |
| $key = $matches[1].ToLower().Trim() | ||
| $value = $matches[2].ToLower().Trim() |
There was a problem hiding this comment.
The regex pattern uses ToLower() on both key and value, which will convert boolean 'True'/'False' values to lowercase. While the comparison on line 85 correctly checks for 'true' in lowercase, this approach may cause issues if other settings have case-sensitive values. Consider preserving the original case for the value and only normalizing the key, or explicitly handle boolean values separately.
| if ($policySettings) { | ||
| foreach ($setting in $policySettings) { | ||
| # Parse [key, value] format | ||
| $match = $setting -match '^\[(.*?),\s*(.+)\]$' |
There was a problem hiding this comment.
The regex pattern '^[(.?),\s(.+)]$' uses a non-greedy match for the key but a greedy match for the value. If a value contains a comma, this could lead to incorrect parsing. Consider using a more specific pattern or a different parsing approach that handles edge cases like values containing commas or brackets.
| $match = $setting -match '^\[(.*?),\s*(.+)\]$' | |
| $match = $setting -match '^\[([^,]+),\s*([^\]]+)\]$' |
No description provided.