Baseline Change Log for Quarter 2, 2026

32 minutes to read

Cloud App Security (CAS)

2026-Q2-CAS-001 – CAAS - CONFIG - Enable App Governance for Cloud Apps

Project Title:
CAAS - CONFIG – Enable App Governance for Cloud Apps

Change Identifier:
2026-Q2-CAS-001

Date:
2026-Q2

Prepared By:
James Paul
Tier 2 Support and Compliance Officer
Government Operations

Reviewed By:
Christopher Denno
Senior Compliance Officer
Government Operations

1. Executive Summary

This change enables App Governance within Microsoft Defender for Cloud Apps to improve visibility, monitoring, and control over OAuth-enabled cloud applications that can access Microsoft 365 and other connected cloud data. App Governance provides security and policy management capabilities for OAuth-enabled apps registered in Microsoft Entra ID. The feature helps identify risky applications, excessive permissions, unverified publishers, unusual data usage, anomalous behavior, and applications that may require approval, restriction, or remediation.

The initial implementation will focus on visibility, alerting, and review. Enforcement actions, such as banning or disabling applications, should only be applied after business ownership and operational impact are validated.

2. Background and Justification

A review of the current Microsoft 365 security configuration identified that OAuth-enabled cloud applications may be granted access to organizational data without sufficient centralized governance. These applications can receive delegated permissions to access mail, files, calendars, users, groups, and other Microsoft 365 resources depending on the permissions granted by users or administrators.

Without App Governance enabled, administrators may have limited visibility into which OAuth applications have access, what permissions were granted, which users consented to the applications, whether publishers are verified, and whether the applications are using excessive or unusual levels of data. This creates a risk where malicious, overprivileged, unused, or unapproved applications could access organizational data without timely detection or remediation.

The selected solution is to enable App Governance in Microsoft Defender for Cloud Apps. This provides enhanced application visibility, policy-driven alerting, anomaly detection, app risk insights, and remediation support for OAuth-enabled cloud applications. This change supports least privilege, access control, auditability, security monitoring, and protection of organizational data.

3. Impacted Controls

AC.L2-3.1.5
AC.L2-3.1.20
AU.L2-3.3.1
AU.L2-3.3.3
CM.L2-3.4.6
CM.L2-3.4.7
SI.L2-3.14.6
SI.L2-3.14.7

4. Scope of Change

Enable App Governance within Microsoft Defender for Cloud Apps.
Review OAuth-enabled applications registered in Microsoft Entra ID and supported connected platforms.
Identify applications with risky attributes, including excessive permissions, high privilege access, unused permissions, unused applications, unverified publishers, and unusual data usage.
Review user consent activity and applications authorized by users.
Create custom App Governance policies as needed to align with organizational risk tolerance.
Route App Governance alerts through Microsoft Defender XDR for security

5. Objectives

The objective of this change is to improve visibility and control over OAuth-enabled cloud applications that can access M365. Enabling App Governance will allow the organization to detect risky applications, identify applications with excessive or unnecessary permissions, monitor anomalous application behavior, regulate applications with risky attributes, and support remediation decisions when applications present security or compliance risk.

This change is intended to strengthen cloud app governance, support least privilege enforcement, improve security monitoring, and reduce the chance of unauthorized or excessive third-party application access to organizational data.

6. Change Details and Specifications

Configurations:

Enable App Governance from Microsoft Defender XDR under Settings > Cloud Apps > App governance.
Confirm the tenant has an active Microsoft Defender for Cloud Apps license.
Confirm Defender for Cloud Apps and Microsoft Defender XDR have both been provisioned by accessing their respective portals at least once.
Confirm the Microsoft 365 connector is enabled in Defender for Cloud Apps to improve visibility into activities and specific resources accessed by OAuth apps.
Confirm administrative access is assigned using an appropriate role, such as Security Administrator, Compliance Administrator, Compliance Data Administrator, or another supported app governance role.
Review the App Governance overview page after provisioning completes. Microsoft notes that provisioning can take up to 10 hours after enabling App Governance.

Rollback Procedures:

Disable or tune newly created App Governance policies if unexpected alert noise or operational impact occurs.
If an application is incorrectly banned or disabled, review the application in App Governance and Microsoft Entra ID, then restore access only after business owner validation and security approval.

7. Impact Assessment

This change is expected to improve the organization’s security posture by increasing visibility into OAuth-enabled cloud applications and providing a centralized method to detect, investigate, and respond to risky application behavior. The initial impact to users should be minimal because App Governance can be enabled for visibility and alerting before any blocking or remediation actions are applied.

Potential user impact may occur if an OAuth application is later banned, disabled, or restricted. This could affect access to third-party tools that rely on Microsoft 365 permissions. To reduce disruption, administrators should first review discovered applications, validate business justification, confirm application ownership, and document approved applications before applying enforcement actions.

This change may generate new alerts in Microsoft Defender XDR and Defender for Cloud Apps. Security administrators should review alert volume after enablement and tune policies as needed to reduce unnecessary noise while still detecting meaningful risk.

8. Testing and Validation

Policy Assignment Verification:

Verified App Governance Enablement in Microsoft Defender
App Governance was verified as enabled in Microsoft Defender XDR > Settings > Cloud Apps > App governance.
The Cloud Apps > App governance page was confirmed to load successfully.
The signed-in administrator was confirmed to have access to view App Governance data.

Functional Validation:

Verified App Governance Visibility and Detection
The App Governance dashboard was reviewed to confirm OAuth application visibility.
App Governance was confirmed to be available for detecting risky, overprivileged, suspicious, or malicious cloud applications.
App Governance alerts were confirmed to appear in Microsoft Defender XDR under Incidents & Alerts when detections are generated.

Security Validation:

Verified Risk Monitoring Capability
App Governance was confirmed to provide monitoring for risky OAuth app access, excessive permissions, unverified publishers, anomalous app activity, and malicious app behavior.
No production applications were blocked, banned, or disabled as part of this initial enablement.
The change was validated as an enablement and monitoring improvement with no expected user disruption.

9. Timeline

Testing: Completed
Implementation: 1-2 business days
Validation: 1 business day

10. Approval and Sign-off

Signature: Christopher Denno
Date: 05/13/2026

11. Policy Modification

Objective: 3.1.5 (a) – Privileged functions are authorized

Policy Statement:
[Organization] shall implement governance and monitoring controls for OAuth-enabled cloud applications by:

Reviewing applications granted delegated or privileged access to Microsoft 365 resources
Identifying applications with excessive, high-risk, or unnecessary permissions
Validating application access against business and operational requirements
Supporting remediation decisions for applications determined to present elevated organizational risk

Objective: 3.1.20 (a) – External connections and systems are controlled

Policy Statement:
[Organization] shall regulate access by external and third-party cloud applications through App Governance capabilities by:

Monitoring OAuth-enabled applications connected to Microsoft 365 and supported cloud platforms
Reviewing user consent activity and administrator-approved application access
Identifying applications from unverified publishers or applications exhibiting risky behavior
Supporting restriction or remediation actions for applications that violate organizational security requirements

Objective: 3.3.1 (a) – System monitoring is performed

Policy Statement:
[Organization] shall implement continuous monitoring of OAuth-enabled cloud applications through Microsoft Defender for Cloud Apps by:

Enabling App Governance visibility and monitoring capabilities
Monitoring application activity, data access patterns, and anomalous behavior
Providing centralized visibility into application usage and permission assignments
Routing App Governance alerts through Microsoft Defender XDR for security operations review

Objective: 3.3.3 (a) – Audit records are reviewed and correlated

Policy Statement:
[Organization] shall review and analyze App Governance activity and alerts by:

Reviewing detected risky application activity and anomalous behaviors
Correlating OAuth application events with security monitoring and incident response workflows
Monitoring user consent activity and application permission changes
Supporting investigation of suspicious or malicious cloud application activity

Objective: 3.4.6 (a) – Least functionality is implemented

Policy Statement:
[Organization] shall enforce least functionality principles for cloud application access by:

Reviewing OAuth application permissions for excessive or unnecessary access
Identifying unused applications and unused granted permissions
Supporting remediation of applications that exceed operational requirements
Reducing unnecessary third-party application access to organizational resources

Objective: 3.4.7 (a) – Nonessential functionality is restricted

Policy Statement:
[Organization] shall identify and regulate nonessential cloud application functionality by:

Monitoring applications with high-risk or unnecessary privilege assignments
Reviewing applications with anomalous or excessive data usage patterns
Supporting restriction, disablement, or remediation of applications that present unnecessary organizational risk
Ensuring cloud application access aligns with approved business use cases

Objective: 3.14.6 (a) – System monitoring includes detection of unauthorized activity

Policy Statement:
[Organization] shall implement monitoring mechanisms to detect suspicious or unauthorized cloud application behavior by:

Monitoring for anomalous OAuth application activity
Detecting malicious, suspicious, or risky application behavior through App Governance analytics
Identifying applications with unusual access patterns or excessive data interaction
Generating alerts for security review and investigation of detected cloud application risks

Objective: 3.14.7 (a) – Identified security risks are addressed

Policy Statement:
[Organization] shall support remediation and response activities for risky cloud applications by:

Reviewing App Governance alerts and identified application risks
Validating business ownership and operational requirements prior to enforcement actions
Supporting restriction, disablement, or banning of applications determined to present security or compliance risk
Continuously reviewing App Governance policies and tuning configurations to improve risk detection effectiveness

Defender (DEF)

2026-Q2-DEF-001 – CAAS – CONFIG – Web Content Filtering

Project Title:
CAAS - CONFIG - Web Content Filtering

Change Identifier:
2026-Q2-DEF-001

Date:
2026-Q2

Prepared By:
James Paul
Tier 2 Support and Compliance Officer
Government Operations

Reviewed By:
Greg Rowe
Chief CMMC Strategist

1. Executive Summary

This change enables Web Content Filtering within Microsoft Defender for Endpoint to enhance web protection by regulating access to websites based on content categories and organizational risk tolerance. The implementation will allow the organization to block or audit access to selected web categories that may pose security, compliance, or acceptable use concerns, helping reduce exposure to malicious or inappropriate content while improving visibility into web activity. This change strengthens preventative security controls, supports policy enforcement across managed devices, and improves the organization’s overall defensive posture through centralized monitoring and category-based access restrictions.

2. Background and Justification

Web content filtering is being implemented to strengthen preventative security controls and provide greater oversight of user web access across managed devices. This capability allows the organization to regulate access to website categories that may introduce security risk, compliance concerns, or productivity impacts, while supporting monitoring of permitted web activity for informed policy decisions. By leveraging category-based filtering and centralized reporting within Microsoft Defender for Endpoint, this change improves protection against web-borne threats, supports acceptable use enforcement, and enhances visibility for security operations. The change aligns with the organization’s broader security hardening objectives and supports risk reduction through proactive control enforcement.

3. Impacted Controls

AC.L2-3.1.20
SI.L2-3.14.6
SC.L2-3.13.13

4. Scope of Change

Enable Web Content Filtering within Microsoft Defender for Endpoint.
Configure and apply web content filtering policies to designated managed device groups.
Implement category-based controls to audit and/or block selected website categories based on organizational security requirements.
Enable centralized logging, monitoring, and reporting of web access activity and policy enforcement events.
Apply the change to in-scope managed endpoints covered by the organization’s Defender deployment; no changes to user roles, business applications, or core network architecture are included in this change.

5. Objectives

The objective of this change is to strengthen web-based threat protection by restricting access to high-risk or non-approved website categories, improve enforcement of acceptable use and security policies through category-based web access controls, and increase visibility into user web activity through centralized monitoring, auditing, and reporting. Collectively, these measures help reduce risk from web-borne threats while enhancing security oversight and policy enforcement across managed devices.

6. Change Details and Specifications

Configurations:

Enable Web Content Filtering within Microsoft Defender for Endpoint.
Configure web content filtering policy settings and assign policy to designated device groups.
Define approved blocked and audited web content categories based on organizational security requirements and acceptable use standards.

Rollback Procedures:

If rollback is needed, disable Web Content Filtering in Microsoft Defender.

7. Impact Assessment

This change is expected to have a positive security and compliance impact by improving control over web access, reducing exposure to web-borne threats, and enhancing monitoring visibility across managed devices. User impact is expected to be minimal, though access to websites in blocked categories may be restricted and users may receive notifications when attempting to access prohibited content. Operational impact is low, as the change leverages existing capabilities within Microsoft Defender for Endpoint and is not expected to disrupt core business functions.

8. Testing and Validation

Policy Assignment Verification:

The Intune configuration policy was successfully deployed to the test device group.
Validation confirmed that the policy settings were applied without errors.

Functional Validation:

Test access was performed against websites in both allowed and blocked categories.
Blocked categories were enforced as expected, and users received block notifications when applicable.

Security Validation:

Access to restricted or high-risk website categories was successfully prevented based on policy.
Web activity events, category matches, and enforcement actions were captured in Microsoft Defender for Endpoint reporting as expected.

9. Timeline

Testing: Completed

Implementation: 1-2 business days

Validation: 1 business day

10. Approval and Sign-off

Signature: Christopher Denno

Date: 05/13/2026

2026-Q2-DEF-002 - SBC Update - CAAS - Outbound Firewall Default Deny Implementation

Project Title:
CAAS - UPDATE - Outbound Firewall Default Deny Implementation
Change Identifier: 2026-Q2-DEF-002
Date:
2026-Q2-DEF-002

Prepared By:
James Paul
Tier 2 Support and Compliance Officer
Government Operations

Reviewed By:
Christopher Denno
Senior Compliance Officer

1. Executive Summary

A firewall configuration update has been implemented to enforce a default-deny outbound network policy across all managed systems. This change establishes an explicit deny-by-default outbound network communications posture, where all outbound traffic is blocked unless explicitly authorized through defined firewall rules. Outbound traffic is restricted to a defined set of approved ports required for business and system functionality.

2. Background and Justification

Previously, outbound network traffic was broadly permitted, with only a limited number of ports explicitly restricted. This approach relied on monitoring and selective blocking of outbound activity rather than enforcing a deny-by-default posture.

This configuration did not meet the requirement to explicitly deny outbound network communications unless they are explicitly authorized.

The updated configuration enforces a default-deny outbound policy, where only explicitly approved ports are permitted and all other outbound traffic is blocked. This change aligns the environment with CMMC requirements for controlling outbound communications.

3. Impacted Controls

SC.L2-3.13.1
SC.L2-3.13.5
CM.L2-3.4.6
CM.L2-3.4.1
AC.L2-3.1.3

4. Scope of Change

Modify the configuration policy titled “CAAS – Windows Defender Firewall.”
Configure default inbound and outbound actions to Block across Domain, Private, and Public profiles.
Create a firewall rule titled “CAAS – OB – Port Exclusions.”
Allow outbound traffic on approved ports: 443, 80, 53, 123, 9350–9354, 5986, 3389, 445, 389, 636, 587, 22, 3306, 1433, 4022, 135, 1434.
Endpoint-level firewall configuration (Windows Defender Firewall) deployed via Intune to all in-scope managed endpoints within the CUI boundary

5. Objectives

The objective is to restrict outbound network communications to only approved ports required for business operations and system functionality. This control ensures that systems cannot initiate outbound connections over non-approved ports.

6. Change Details and Specifications

Configurations:

Default Inbound Action: Block
Default Outbound Action: Block
Firewall Profiles: Enabled for Domain, Private, and Public networks
Outbound Allow Rule: Defined port-based exceptions for approved services
All outbound traffic not explicitly allowed is blocked by default

Rollback Procedures:

If rollback is needed, remove or disable the outbound deny configuration and revert to the previous firewall baseline.

7. Impact Assessment

This change restricts outbound network communications to approved ports only. Systems will no longer be able to initiate outbound connections on non-approved ports.

Applications or services that rely on non-approved outbound ports may require review and formal exception approval to restore functionality.

8. Testing and Validation

Policy Assignment Verification:

The firewall policies were successfully assigned to all targeted systems.
Validation confirmed that default outbound action was set to Block across all profiles.

Outbound Connectivity Validation:

Outbound connections over approved ports were tested and confirmed to function as expected.
Outbound connections over non-approved ports were tested and confirmed to be blocked.

Configuration Verification:

Firewall rules were reviewed to confirm the presence of defined outbound allow rules.

Log Review:

Firewall and endpoint logs were reviewed to confirm denied outbound connection attempts on non-approved ports and successful outbound connections only on explicitly allowed ports.

Effective Enforcement Confirmation:

Effective firewall configuration was validated on endpoints to ensure the policy was applied as intended.
Observed behavior aligned with expected enforcement of the default-deny outbound policy.

9. Timeline

Testing: Completed

Implementation: 3-5 business days

Validation: 1-2 business days

10. Approval and Sign-off

Signature: Christopher Denno
Date: 04/10/2026

Intune (INT)

2026-Q2-INT-001 - CAAS - CONFIG - Restrict Printer Mapping (Disable Client Printer Redirection)

Project Title: CAAS - CONFIG - Restrict Printer Mapping (Disable Client Printer Redirection)

Change Identifier: 2026-Q2-INT-001

Date:
2026-Q2

Prepared By:

James Paul
Tier 2 Support and Compliance Officer
Government Operations

Reviewed By:
Greg Rowe
Chief CMMC Strategist

1. Executive Summary

An Intune configuration policy has been implemented to disable client printer redirection on managed devices. This change prevents printers from being mapped into remote sessions such as RDP, Azure Virtual Desktop, and Windows 365 Cloud PCs, ensuring that print jobs cannot be redirected to unmanaged or non-approved devices where Controlled Unclassified Information (CUI) may be exposed.

2. Background and Justification

Validation of remote access sessions confirmed that network printers are currently being redirected into Cloud PC and RDP environments. Review of Intune configuration profiles identified that no policy is enforcing the “Do not allow client printer redirection” setting. Allowing printer redirection introduces risk by enabling sensitive data to be printed outside of controlled environments. Enforcing this restriction ensures that print activity is limited to authorized and managed destinations, supporting the protection of sensitive data.

3. Impacted Controls

AC.L2-3.1.3
AC.L2-3.1.12
AC.L2-3.1.20
CM.L2-3.4.6
CM.L2-3.4.7

4. Scope of Change

Configure an Intune Settings Catalog policy to enforce printer redirection restrictions.
Enable the “Do not allow client printer redirection” setting to block local printer mapping in remote sessions.
Enable Point and Print restrictions to prevent connections to unauthorized print servers.
Set driver installation and update behavior to require warning and elevation prompts.

5. Objectives

The objective is to prevent printers from being redirected into sessions and ensure that printing is restricted to controlled, approved, and auditable destinations within the managed environment.

6. Change Details and Specifications

Configurations:

Policy Name / Platform / Profile Type → CAAS - Restrict Printer Mapping / Windows 10 and later / Settings Catalog
Policy Settings: Do not allow client printer redirection → Enabled
Policy Settings: Do not allow client printer redirection → Enabled
Policy Settings: Point and Print Restrictions → Enabled
Policy Settings: When installing drivers for a new connection → Show warning and elevation prompt
Policy Settings: When updating drivers for an existing connection → Show warning and elevation prompt

Rollback Procedures:

If rollback is needed, disable the Intune policy or revert the configuration settings to allow printer redirection.

7. Impact Assessment

This configuration will prevent users from printing to locally attached printers during remote sessions, which may impact workflows that rely on local printing. If no approved printing solution is available, printing from these environments will be restricted. This change improves control over data handling and reduces the risk of unauthorized data exfiltration through unmanaged print devices.

8. Testing and Validation

Policy Assignment Verification:

The Intune configuration policy was successfully deployed to the test device group.
Validation confirmed that the policy settings were applied without errors.

Functional Validation:

Remote sessions were initiated using Cloud PC’s.
Network printers were no longer redirected into the session.
No redirected printer objects were visible during active sessions.

Security Validation:

Print jobs could not be sent to unmanaged printers.
Controlled environment restrictions were enforced as expected.

Access Control Confirmation:

Printer redirection was blocked from controlled remote sessions to unmanaged local devices.
The applied configuration enforced the expected restriction without disrupting policy deployment.

9. Timeline

Testing: Completed

Implementation: 1-2 business days

Validation: 1 business day

10. Approval and Sign-off

Signature:Greg Rowe
Date:5/13/2026

Teams

2026-Q2-TEAMS-001 - CAAS - Enforce Lobby in Teams for External Users (No Automatic Join)

Project Title: CAAS - CONFIG - Enforce Lobby in Teams for External Users (No Automatic Join)

Change Identifier: 2026-Q2-TEAMS-001

Prepared By:
James Paul
Tier 2 Support and Compliance Officer
Government Operations

Reviewed By:
Christopher Denno
Senior Compliance Officer

1. Executive Summary

A Microsoft Teams Meeting Policy configuration has been implemented to prevent automatic meeting admission for external users. This change enforces lobby placement for all users outside of the organization, ensuring that meeting organizers explicitly review and admit external participants before granting access to meetings where Controlled Unclassified Information (CUI) may be discussed.

2. Background and Justification

Allowing external or unauthenticated users to automatically join meetings presents a risk of unauthorized access to sensitive discussions or shared content. Enforcing lobby placement for outside users ensures that external participants are subject to manual admission by authorized meeting personnel before entering the session. This strengthens access control over Microsoft Teams meetings and supports protection of sensitive collaboration sessions.

3. Impacted Controls

AC.L2-3.1.2
AC.L2-3.1.3
AC.L2-3.1.12
IA.L2-3.5.1
IA.L2-3.5.2
AC.L2-3.1.20

4. Scope of Change

Configure Microsoft Teams Meeting Policy settings for meeting join and lobby behavior.
Set the “Who can bypass the lobby” option to “People in my org” to prevent outside users from automatically joining meetings.
Set the “People dialing in can bypass the lobby” option to Off to require dial-in callers to wait in the lobby.

Set the “Who can admit from the lobby” option to “Organizers, co-organizers, and presenters”.

5. Objectives

The objective is to prevent automatic join for external users and require them to remain in the Teams meeting lobby until explicitly admitted. This control reduces the risk of unauthorized external access to meetings where sensitive information may be discussed.

6. Change Details and Specifications

Configurations:

Policy Settings: Who can bypass the lobby → People in my org
Policy Settings: People dialing in can bypass the lobby → Off
Policy Settings: Who can admit from the lobby → Organizers, co-organizers, and presenters

Rollback Procedures:

If rollback is needed, restore the previous Teams Meeting Policy join and lobby settings.

7. Impact Assessment

This configuration will require external users to wait in the meeting lobby before being admitted, which may introduce a slight delay for outside participants. Internal users will continue to join according to the configured bypass setting. This change improves control over external meeting access without materially affecting internal meeting operations.

8. Testing and Validation

Policy Assignment Verification:

The Teams Meeting Policy was successfully updated for the targeted meeting join and lobby settings.
Validation confirmed that outside users were not allowed to bypass the lobby.

External User Join Validation:

A test meeting was created and joined using an external account.
The external user was placed in the lobby and was unable to automatically join the meeting.
Admission required manual approval from an authorized meeting participant, confirming the expected behavior.

Internal User Validation:

Internal join behavior was reviewed to confirm no unexpected disruption to in-organization participants.
Meeting access for internal users continued according to the configured bypass setting.

Access Control Confirmation:

Outside users remained subject to lobby admission before entering the meeting.
Authorized meeting personnel retained control over whether external participants were admitted.

9. Timeline

Testing: Completed

Implementation: 1-2 business days

Validation: 1 business day

10. Approval and Sign-off

Signature: Christopher Denno
Date: 04/10/2026

Sentinel (SENT)

2026-Q2-SENT-001-Sentinel Anaytic Rule severity 26

Project Title:
CAAS – Sentinel Alert Query

Date:
2026-Q2

Prepared By:
Sydney Knoelk
Compliance Officer

Reviewed By: Christopher Denno

Sentinel Alert Query Tuning

1. Executive Summary

To improve security monitoring effectiveness and reduce alert fatigue, a set of updates to Microsoft Sentinel alert queries is being proposed. These changes will refine detection logic, thresholds, and query conditions to ensure that alerts generated are actionable, relevant, and aligned with real security events.

This change directly supports CMMC controls SI.L2-3.3.1 (System Monitoring) and SI.L2-3.3.2 (Event Monitoring) by improving the organization’s ability to identify, analyze, and respond to potential security incidents in a timely and efficient manner. The objective is to enhance visibility while minimizing noise, ensuring security teams can focus on legitimate threats.

2. Background and Justification

Currently, Microsoft Sentinel generates a high volume of alerts, many of which are low-value or false positives. This creates alert fatigue and increases the likelihood that critical security events may be delayed or overlooked.

By tuning alert queries, thresholds, and logic, the organization can significantly improve signal-to-noise ratio, enabling faster triage and more accurate incident detection. This aligns with CMMC Level 2 monitoring requirements and strengthens the overall security posture.

3. Impacted Controls

SI.L2-3.3.1
SI.L2-3.3.2
SI.L2-3.3.6

4. Scope of Change

Modify existing Microsoft Sentinel alert rules and queries.

Targeted Components:

Sentinel Analytics Rules
Kusto Query Language (KQL)
Alert thresholds and conditions

Policy Mode:

Iterative tuning with validation during implementation

5. Objectives

Reduce false positives and alert noise
Improve detection accuracy for real security events
Enhance incident response efficiency
Align monitoring capabilities with CMMC Level 2 requirements

6. Change Details and Specifications

Configurations:

Update KQL queries for alert rules
Adjust thresholds for triggering alerts
Change Alert Severities and Thresholds
- Reduce severity to Low:
  - User added to Microsoft Entra ID Privileged Groups
  - User Assigned Privileged Role
  - New User Assigned to Privileged Role
  - User added to Microsoft Entra ID Privileged Groups (variant)
  - New User Assigned to Privileged Role (variant)
  - Block download based on real-time content inspection
  - Block download based on real-time content inspection (variant)
- Modify Alert Threshold and Logic:
  - Sentinel data connector has not received data – Modify threshold to 3 business days, and make alert dependent on tenant sign-ins in the last 3 business days (>1 sign-in)
  - Sentinel data connector has not received data (variant) – Modify threshold to 3 business days, and make alert dependent on tenant sign-ins in the last 3 business days (>1 sign-in)

Implementation Plan:

Review existing alert rules and identify high-noise alerts
Modify queries and thresholds
Validate alert accuracy in staging/controlled testing
Deploy updated queries to production
Monitor alert volume and effectiveness

Rollback Procedures:

Revert to previous query versions
Re-enable prior alert configurations if needed

7. Impact Assessment

This change improves compliance with CMMC by strengthening continuous monitoring and ensuring that security alerts are meaningful and actionable. By aligning alerting mechanisms with real-world threat scenarios, the organization enhances its ability to detect and respond to incidents affecting Controlled Unclassified Information (CUI).

From a client perspective, the impact is low and primarily beneficial. End users will not experience any direct changes. Security and administrative teams will see a reduction in unnecessary alerts and improved clarity in identifying real threats. This results in faster response times, improved operational efficiency, and reduced risk of missed critical events.

8. Testing and Validation

Initial Phase:

Review and test updated queries in a controlled environment

Validation:

Compare alert volume before and after tuning
Confirm reduction in false positives
Ensure critical alerts are still generated

Enforcement:

Fully deploy tuned queries into production monitoring

9. Timeline

Testing: 3–5 business days
Implementation: 2–3 business days
Validation: 2–3 business days

10. Special Notes

Alert tuning will be an ongoing process and may require periodic refinement based on emerging threats and environment changes.

11. Approval and Sign-off

Signature: Christopher Denno
Date: 04/9/2026