Baseline Configuration Change Log

  • 44 minutes to read

Welcome to the public changelog for Compliance-as-a-Service by Nimbus Logic.

About This Log

This changelog tracks formal and informal changes made to the managed baseline security configuration for Compliance-as-a-Service (CaaS) clients. It includes:

  • Change proposals for configuration settings
  • Approved modifications requested by OSCs
  • Security-focused technical adjustments made by the ESP

All baseline changes listed here have been reviewed and approved by both the OSC and ESP prior to implementation.

Baseline changes are versioned by Year-Quarter-CATEGORY-Number (e.g., 2025-Q1-INT-001 for Intune) and grouped by technology domain for ease of navigation.

Q2 - 2025

🔐 Conditional Access (CA)

2025-Q2-CA-001 – CAAS - BLOCK - O365 Services from Admins

Project Title:
CAAS - BLOCK - O365 Services from Admins

Change Identifier:
2025-Q2-CA-001

Date:
2025-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

To enforce least privilege and align with CMMC Level 2 access control requirements, a Conditional Access policy titled “CAAS - BLOCK - O365 Services from Admins” is being proposed. This policy will block administrative users from accessing Exchange Online and SharePoint Online, both of which may contain, or process Controlled Unclassified Information (CUI).

This proposed change directly supports CMMC controls AC.L2-3.1.1 (limit access to authorized users) and AC.L2-3.1.5 (separate duties). It aims to reduce the risk of data exposure from compromised privileged accounts, minimize access misuse, and enforce Zero Trust principles by ensuring that admin-level users are not granted default access to CUI-hosting services unless explicitly needed.

2. Background and Justification

Currently, administrative accounts retain unrestricted access to core Microsoft 365 services, including Exchange and SharePoint. These services may contain CUI or other sensitive data. Without controls in place, this creates a risk of privilege misuse, accidental exposure, or lateral movement in the event of credential compromise.

Implementing Conditional Access to restrict such access helps enforce proper role separation and aligns with CMMC Level 2 requirements, improving overall compliance and reducing attack surface.

3. Impacted Controls

  • AC.L2-3.1.1
  • AC.L2-3.1.2
  • AC.L2-3.1.4
  • AC.L2-3.1.5
  • AC.L2-3.1.6

4. Scope of Change

  • Create and deploy a Conditional Access policy titled “CAAS - BLOCK - O365 Services from Admins.”
  • Targeted Apps: Exchange Online, SharePoint Online
  • Excluded Apps: Microsoft Graph
  • Targeted Users: Scoped to admin roles (excluding break-glass and service accounts)
  • Policy Mode: Report-only initially, then Block after validation

5. Objectives

  • Prevent administrative users from accessing Exchange and SharePoint by default
  • Enforce least privilege and separation of duties as required by CMMC Level 2
  • Reduce the risk of data compromise via admin-level account misuse
  • Support Zero Trust architecture by limiting access to only what is explicitly needed

6. Change Details and Specifications

Configurations:

  • Policy Title: “CAAS - BLOCK - O365 Services from Admins”
  • Resources Targeted: Exchange Online, SharePoint Online
  • Excluded Resources: Microsoft Graph
  • Users: Scoped to admin roles (with exclusions as needed)
  • Access Control: Block access
  • Conditions: None initially
  • Deployment: Report-only mode for 5–7 days

Implementation Plan:

  • Review scoped users/groups
  • Apply exclusions for break-glass and service accounts
  • Deploy in Report-only mode
  • Monitor impact and adjust as needed
  • Enable enforcement after validation

Rollback Procedures:

  • Disable or delete the policy
  • No persistent tenant changes will remain

7. Impact Assessment

This policy significantly enhances compliance with the Cybersecurity Maturity Model Certification (CMMC) by implementing strict access boundaries for users in privileged roles. Specifically, it enforces the principle of least privilege by restricting access to Exchange Online and SharePoint Online resources while a user holds an active privileged role (such as Global Administrator or other elevated roles).

This change is designed to minimize the attack surface and reduce the risk of data exposure or misuse by ensuring that administrative accounts are used strictly for administrative functions. As a result, users with privileged roles will experience a high impact: they will no longer be able to access their email, calendars, or SharePoint content while their privileged role assignment is active. This separation between administrative and productivity functions is a key CMMC control and aligns with best practices for securing sensitive environments.

This policy change may require updates to internal workflows and role management procedures but is a critical step toward achieving and maintaining CMMC compliance.

8. Testing and Validation

Initial Phase:

  • Deployed in Report-only mode and monitored sign-in logs for 5–7 days

Access Audit:

  • Confirmed no disruptions; admin/service accounts scoped appropriately

Enforcement:

  • Successfully transitioned to Block mode with intended access restrictions enforced

9. Timeline

  • Testing: Completed
  • Implementation: 3–5 business days
  • Validation: 1–2 business days

10. Special Note on PIM Access

Due to Microsoft Conditional Access limitations, navigating to PIM (Privileged Identity Management) via the Azure Portal UI may be blocked when O365 services are restricted. Users should use the following direct URLs to manage PIM:

These URLs allow users to elevate roles or end active PIM sessions, as PIM is not accessible via the Azure Portal while privileged users are elevated. Ensure Microsoft Graph remains excluded to support this functionality.

11. Approval and Sign-off

Signature: Christopher Denno
Date: 05/12/2025

2025-Q2-CA-002 – CAAS - GRANT - Require MFA to enroll a device

Project Title:
CAAS - GRANT - Require MFA to enroll a device

Change Identifier:
2025-Q2-CA-002

Date:
2025-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

A Conditional Access policy has been created to require multi-factor authentication (MFA) prior to device enrollment. This measure strengthens the enrollment process by ensuring that only verified users with secure authentication can enroll devices into Microsoft Intune or Entra ID, reducing the risk of unauthorized or rogue device access.

2. Background and Justification

Unrestricted or weakly authenticated device enrollments can introduce significant security risks, especially in federal and high-assurance environments. Requiring MFA during the enrollment process aligns with Zero Trust principles and compliance mandates by validating user identity at a critical control point.

3. Impacted Controls

  • AC.L2-3.1.1
  • IA.L2-3.5.2
  • IA.L2-3.5.3

4. Scope of Change

  • Create a Conditional Access policy titled “CAAS – GRANT - Require MFA for Device Enrollment.”
  • Target the Microsoft Intune Enrollment cloud app via Entra Conditional Access.
  • Apply grant controls: Require multi-factor authentication

5. Objectives

The objective is to enforce secure, validated enrollment of new devices by requiring MFA for all users attempting to register or enroll a device. This control reduces the risk of compromised credentials being used to onboard unauthorized endpoints.

6. Change Details and Specifications

Configurations:

  • Resources Targeted: User action – Register or join devices
  • Policy Settings: Grant Controls: Require multi-factor authentication

Rollback Procedures:

  • If rollback is needed, change Enable policy status to “Report-only”.

7. Impact Assessment

This policy will require users to perform MFA before enrolling devices, which may introduce a slight delay during setup but enhances security posture. No impact to existing enrolled devices or ongoing device management operations.

8. Testing and Validation

Policy Assignment Verification:

  • The Conditional Access policy was successfully assigned to all users attempting to register or join devices.
  • Validation confirmed that the policy correctly required users to provide MFA to register or join devices without overlap or misconfiguration.

Enrollment Attempt Validation:

  • A test device was enrolled using an account within the policy scope.
  • The enrollment process was appropriately interrupted until multi-factor authentication was completed.
  • Upon successful MFA verification, the enrollment proceeded without issue, confirming the expected enforcement behavior.

Sign-In Log Review:

  • Entra ID Sign-In Logs were reviewed and confirmed that MFA requirements were enforced during device registration attempts.
  • Failed or incomplete MFA attempts were correctly logged and blocked from completing enrollment, as intended.

Access Control Confirmation:

  • Enrollment was attempted using credentials without MFA enabled, and access was successfully blocked, validating the control.
  • Users with valid MFA credentials experienced no unexpected delays or disruptions beyond the expected MFA prompt.

9. Timeline

  • Testing: Completed
  • Implementation: 3–5 business days
  • Validation: 1–2 business days

10. Approval and Sign-off

Signature: Christopher Denno
Date: 5/8/2025

2025-Q2-CA-003 – CAAS – SESSION – Admin Reauthentication

Project Title:
CAAS – SESSION – Admin Reauthentication

Change Identifier:
2025-Q2-CA-003

Date:
2025-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

A Conditional Access policy has been implemented to increase the security of privileged administrative sessions within Microsoft 365 and Azure environments. This policy forces all administrative roles to reauthenticate every time a new session is initiated by disabling persistent browser sessions and enforcing hourly sign-in frequency. The goal is to reduce session persistence risks and ensure continuous identity verification.

2. Background and Justification

Administrators have elevated privileges that, if compromised, can lead to significant damage across an organization’s cloud environment. By default, persistent browser sessions may allow long-lasting authentication tokens, which could be exploited if a device or session is left unattended or compromised. Requiring admins to reauthenticate per session aligns with Zero Trust principles and supports compliance efforts across CMMC, FedRAMP, and NIST frameworks.

3. Impacted Controls

  • AC.L2-3.1.11
  • IA.L2-3.5.3

4. Scope of Change

  • Create a Conditional Access policy titled “CAAS – SESSION – Admin Reauthentication”
  • Target all users assigned to privileged roles, including but not limited to:
    • Global Administrator
    • Security Administrator
    • Exchange Administrator
  • Apply session controls:
    • Enforce sign-in frequency: 1 hour
    • Disable persistent browser sessions
  • Target all cloud apps used for administrative purposes

5. Objectives

  • Require reauthentication each time an administrator initiates a new session
  • Minimize the attack surface created by long-lived session tokens
  • Support Zero Trust authentication practices
  • Enforce stronger controls around privileged access in line with federal security and compliance standards

6. Change Details and Specifications

Configurations:

User Scope:

  • Assigned to all privileged administrator roles

Cloud Apps:

  • All cloud apps (All cloud apps selected in policy)

Policy Settings:

  • Sign-in frequency: 1 hour
  • Persistent browser session: Disabled

Implementation Plan:

  • The policy will be applied with report-only mode for 48 hours to validate no unexpected behaviors. After successful observation, it will be enforced for all administrative roles.

Rollback Procedure:

  • If authentication issues arise, the policy can be disabled or scoped back to a test group for further tuning.

7. Impact Assessment

This policy will prompt administrators to log in more frequently, especially when launching new browser sessions or switching devices. While this adds a small burden, it significantly reduces risk exposure associated with dormant or hijacked sessions. No impact is expected on service accounts or non-admin users.

8. Testing and Validation

Policy Assignment Verification:

  • The policy was applied in Report-only mode to all users in privileged administrative roles, including Global Administrator, Security Administrator, and Exchange Administrator.
  • Non-admin users and service accounts were successfully excluded from the policy scope, as verified through group membership reviews and policy filters.

Session Control Behavior Testing:

  • Administrative users logged into various cloud apps, including the Microsoft 365 admin center and Azure portal, to evaluate session control behavior.
  • Reauthentication prompts occurred every hour as configured, and persistent browser sessions were effectively disabled.
  • Token expiration behavior aligned with expected policy enforcement, confirming that session tokens were invalidated and reissued per the hourly reauthentication schedule.

Sign-In Log Monitoring:

  • Microsoft Entra ID Sign-In Logs were reviewed and showed consistent enforcement of session controls during the report-only phase.
  • Logs confirmed the presence of session re-prompt events and recorded credential challenges during session transitions, validating policy effectiveness.

9. Timeline

  • Testing: Completed
  • Implementation: 3–5 business days
  • Validation: 1–2 business days

10. Approval and Sign-off

Signature: Christopher Denno
Date: 5/12/2025

2025-Q2-CA-004 – CAAS - SESSION - Cloud PC Reauthentication

Project Title:
CAAS - SESSION - Cloud PC Reauthentication

Change Identifier:
2025-Q2-CA-004

Date:
2025-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

A Conditional Access policy has been introduced to enhance the security posture of Windows 365 Cloud PC access by enforcing frequent reauthentication. This policy leverages Microsoft Entra Conditional Access session controls to require reauthentication every hour and disables persistent browser sessions.

2. Background and Justification

Windows 365 (Cloud PC) access is persistent by default, allowing users to remain authenticated for extended periods. This may introduce security risks in high-assurance environments. By enforcing regular reauthentication, we ensure that only currently authenticated users can access Cloud PC resources, aligning with Zero Trust principles.

3. Impacted Controls

  • AC.L2-3.1.11
  • IA.L2-3.5.3
  • SC.L2-3.13.9

4. Scope of Change

  • Create a Conditional Access policy titled “CAAS - SESSION - Cloud PC Reauthentication”
  • Target the Windows 365 and Cloud PC app ID via Entra Conditional Access
  • Apply session controls:
    • Enforce sign-in frequency: Every time
  • Assign policy to CAAS – Users group

5. Objectives

This policy ensures that users must reauthenticate regularly when accessing Cloud PCs, helping to prevent unauthorized session persistence.

This strengthens authentication requirements in line with federal compliance frameworks and internal security baselines.

6. Change Details and Specifications

Configurations:

  • Cloud app targeted: Windows 365 (App ID: 76d8c060-f0c4-4d9f-8c9f-1f3b0c5e3f4d)
  • Policy Settings:
    • Sign-in frequency: Every time
    • User scope: Applied to CAAS - Users group

Implementation Plan:

  • This change is low impact, scoped to a test group, and can be safely expanded once validated.

Rollback Procedures:

  • If rollback is needed, delete policy.

7. Impact Assessment

This policy will increase session security for Cloud PC users. Users may experience more frequent login prompts but no loss in functionality. Admins and service accounts are excluded from this policy to prevent disruption.

8. Testing and Validation

Policy Assignment Verification:

  • The Conditional Access policy was successfully assigned to the CAAS – Users group within Microsoft Entra.
  • Verification confirmed that all administrative and service accounts were explicitly excluded from the policy scope to prevent unintended disruption.

Session Control Behavior Validation:

  • A test user within the assigned group logged into a Windows 365 Cloud PC, triggering the Conditional Access policy.
  • The user was prompted to reauthenticate upon initial access and again after one hour, confirming the hourly sign-in frequency enforcement.

Access Continuity Check:

  • After each reauthentication, the user successfully resumed access to previously open applications and in-session data without interruption.
  • No data loss, session termination, or abnormal behavior was observed during the reauthentication cycle.

Entra Sign-In Log Review:

  • Microsoft Entra Sign-In Logs were reviewed, and reauthentication events were consistently recorded at the expected intervals.
  • Session control flags were present in token issuance logs, validating proper enforcement and policy behavior.

9. Timeline

  • Testing: Completed
  • Implementation: 3–5 business days
  • Validation: 1–2 business days

10. Approval and Sign-off

Signature: Christopher Denno
Date: 5/12/2025

🛡️ Defender (DEF)

2025-Q2-DEF-001 – CAAS - Defender Machine Risk Compliance

Project Title:
CAAS - Defender Machine Risk Compliance

Change Identifier:
2025-Q2-DEF-001

Date:
2025-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 project involves separating the Microsoft Defender for Endpoint (MDE) device risk condition from an existing compliance policies into its own dedicated policy. In addition, Microsoft Intune has been configured to mark devices as noncompliant immediately when Defender detects a risk status change. This change enhances visibility, simplifies policy management, and strengthens enforcement of Zero Trust controls.

2. Background and Justification

The current compliance policy includes multiple conditions, including device risk from Microsoft Defender for Endpoint. Managing Defender risk independently allows for more granular policy control and faster enforcement actions. By marking devices as noncompliant immediately upon detection of a high-risk status and blocking access through a separate compliance policy, we align more closely with Zero Trust and CMMC principles, reduce exposure windows, and improve threat response times.

3. Impacted Controls

  • AC.L2-3.1.2
  • AC.L2-3.1.5
  • IR.L2-3.6.1
  • IR.L2-3.6.2
  • SI.L2-3.14.1
  • SI.L2-3.14.2
  • SI.L2-3.14.5
  • SI.L2-3.14.6

4. Scope of Change

  • Remove defender risk compliance setting from existing CAAS – W365 Desktop policy
  • Create new compliance policy targeting defender machine risk score “CAAS - Defender Machine Risk Compliance”
  • Enable Defender for Endpoint compliance policy setting to require the machine risk score to be at or under “Medium”
  • Set Defender high-risk devices to be marked noncompliant immediately within Intune compliance policies, and to send an email
  • Assign policy to test group “CAAS - Users”

5. Objectives

  • Improve control over enforcement of Defender device risk signals
  • Enable immediate Conditional Access blocking based on MDE risk alone
  • Align with Zero Trust principles and minimize policy complexity
  • Enhance responsiveness to high-risk endpoints with automated enforcement

6. Change Details and Specifications

Configurations:

  • Create new compliance policy targeting defender machine risk score “CAAS - Defender Machine Risk Compliance”
  • Enable Defender for Endpoint compliance policy setting to require the machine risk score to be at or under “Medium”
  • Create new Intune notification for machine compliance (immediate)
  • Set Defender high-risk devices to be marked noncompliant immediately within Intune compliance policies, and to send an email

Implementation Plan:

  • Remove MDE risk condition from existing compliance policy
  • Create and apply new dedicated MDE risk policy
  • Create new Intune notification for immediate notice for out-of-compliance devices
  • Validate device compliance state transitions in response to Defender risk levels

Rollback Procedures:

  • Disable or delete the new MDE risk compliance policy
  • Restore the Defender risk condition to the original compliance policy if necessary

7. Impact Assessment

Users with devices flagged as high risk by Microsoft Defender for Endpoint will experience immediate loss of access to corporate resources. This is by design to reduce potential exposure. Standard users on healthy or low/medium-risk devices will not be affected. No downtime or service impact is expected for compliant users.

8. Testing and Validation

Policy Assignment Verification

  • The new compliance policy was successfully deployed to the CAAS – Users test group in Microsoft Intune.
  • The Defender machine risk setting was removed from the original CAAS – W365 Desktop policy to ensure independent management and enforcement.

Risk-Based Compliance Response

  • A high-risk Defender alert was simulated on a test device using controlled threat simulation.
  • Intune responded immediately by marking the device as noncompliant upon risk elevation, confirming proper real-time enforcement.

Conditional Access Behavior

  • Conditional Access policies were triggered as expected based on the new noncompliant state.
  • Access to corporate resources was blocked for the high-risk device, and access was automatically restored once the device risk score returned to an acceptable level.

Notification Functionality

  • Email notifications were successfully triggered and sent immediately when a device transitioned to a noncompliant state due to high risk.
  • Notification logs confirmed prompt and accurate delivery without delay.

Compliance State Monitoring

  • Compliance status changes were observed and verified in the Intune portal under Devices > Monitor > Compliance Status.
  • All transitions were logged correctly, and the audit trail reflected the policy evaluation events as expected.

9. Timeline

  • Testing: Completed
  • Implementation: 3–5 business days
  • Validation: 1–2 business days

10. Approval and Sign-off

Signature: Christopher Denno
Date: 5/12/2025

💠 Intune (INT)

2025-Q2-INT-001 – CAAS - Interactive logon message for users

Project Title:
CAAS - Interactive logon message for users

Change Identifier:
2025-Q2-INT-001

Date:
2025-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

To support Controlled Unclassified Information (CUI) handling requirements and enhance user awareness, an interactive logon banner has been implemented via Microsoft Intune. This banner displays a legal notice and DoD-compliant language before a user signs into a Windows 10/11 device. The message ensures users are informed about authorized use, monitoring, and the presence of CUI, aligning with NIST and DoD cybersecurity standards.

2. Background and Justification

Federal systems, including environments processing CUI, must display warning banners during the sign-in process. This requirement is referenced in NIST 800-171, DFARS, and DoD policies. As more devices are managed through Microsoft Intune, configuring this message through a cloud-based policy ensures consistent application across all enrolled Windows endpoints. Failure to present such banners may result in compliance gaps during audits or assessments.

3. Impacted Controls

  • AC.L2-3.1.9
  • AT.L2-3.2.1

4. Scope of Change

  • Modify Device Configuration Profile in Microsoft Intune titled “CAAS - Interactive logon message for users”
  • Use the Settings Catalog > Local Policies Security Options
  • Configure the following interactive logon settings:
    • Title: “WARNING:”
    • Text:

      This [Legal Organization Name] information system is for authorized use only. Usage may be monitored, recorded, and subject to audit. Unauthorized access is strictly prohibited and may result in criminal and civil penalties. By using this system, you consent to monitoring and recording. This system contains Controlled Unclassified Information (CUI) subject to Department of Defense requirements. Additional restrictions may apply to certain types of CUI, such as Export Controlled Information.

  • Assign the policy to all Intune-managed Windows devices or a scoped security group

5. Objectives

  • Enforce CUI compliance by displaying a logon banner aligned with federal guidance
  • Notify users of system monitoring and authorized use policy
  • Support audit readiness for DFARS, NIST 800-171, and CMMC Level 2 compliance
  • Ensure consistency across all Intune-managed devices with a cloud-delivered configuration

6. Change Details and Specifications

Configurations:

  • Platform: Windows 10 and later
  • Profile Type: Settings Catalog > Local Policies Security Options
  • Settings Modified:
    • Interactive logon: Message title for users attempting to log on → WARNING
    • Interactive logon: Message text for users attempting to log on → [See full text above]
  • Deployment Group: CAAS - Users

Implementation Plan:

  • Deploy to a test device group for 48 hours to confirm behavior
  • Expand to production Windows endpoints post-validation

Rollback Procedure:

  • Unassign the policy in Intune
  • Devices revert to default (no banner) on next sync and restart

7. Impact Assessment

Users will encounter a mandatory legal notice before reaching the Windows login screen. This change introduces no technical impact or workflow disruption and is limited to informational purposes only. It will not affect login speed, network connectivity, or endpoint performance.

8. Testing and Validation

Policy Deployment Verification:

  • Successfully deployed to CAAS – Users group with “Succeeded” status in Intune

Logon Banner Appearance Check:

  • Verified display on a Windows 10/11 Cloud PC
  • Message appeared before sign-in screen as intended

Formatting and Text Accuracy:

  • Banner formatting was complete and legible with no issues

9. Timeline

  • Testing: TBD
  • Implementation: 3–5 business days
  • Validation: 1–2 business days

10. Approval and Sign-off

Signature: Christopher Denno
Date: 5/8/2025

2025-Q2-INT-002 – CAAS - W365 Configuration Profile

Project Title:
CAAS - W365 Configuration Profile

Change Identifier:
2025-Q2-INT-002

Date:
2025-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

A configuration profile has been implemented via Microsoft Intune to enforce a 15-minute idle session timeout on Windows 365 Cloud PCs. This policy ensures inactive sessions are automatically locked after a short period of inactivity, supporting data protection, access control, and alignment with cybersecurity compliance frameworks such as CMMC, NIST 800-171, and DoD instructions for Controlled Unclassified Information (CUI).

2. Background and Justification

Windows 365 Cloud PCs, like traditional desktops, can remain idle for extended periods if not actively monitored. In high-security environments handling sensitive data, including CUI, this can result in unauthorized access risks if sessions are left unlocked. Enforcing an idle session timeout ensures unattended sessions self-lock and helps reduce risk from internal or external threats, aligning with Zero Trust principles and physical access safeguards.

3. Impacted Controls

  • AC.L2-3.1.10

4. Scope of Change

  • Modify Intune Configuration Profile titled “CAAS - W365 Configuration Profile”
  • Configure system idle lock timeout policy via Settings Catalog:
    • Session Time Limits: Idle session limit (Device): 15 minutes
    • Set time limit for active but idle Remote Desktop Services sessions: Enabled

5. Objectives

  • Automatically lock Cloud PC sessions after 15 minutes of user inactivity
  • Reduce unauthorized access risks from unattended sessions
  • Improve compliance posture for handling CUI and meeting NIST 800-171
  • Standardize idle timeout across all Cloud PCs

6. Change Details and Specifications

Configurations:

  • Platform: Windows 10 or later
  • Profile Type: Settings Catalog
  • Settings:
    • Idle session limit (Device): 15 minutes
    • RDS idle session timeout: Enabled

Implementation Plan:

  • Deploy policy to the CAAS – Users group

Rollback Procedure:

  • Remove configuration profile from the group in Intune
  • Devices revert to system default settings on next sync/reboot

7. Impact Assessment

Users will experience session lock after 15 minutes of inactivity. There’s no data loss, and users can resume work by signing back in. This improves security without disrupting application states or user data.

8. Testing and Validation

Policy Deployment Verification:

  • Successfully assigned to CAAS – Users test group
  • Deployment confirmed as “Succeeded” in Intune portal

Device Compliance Check:

  • Cloud PC locked after 15 minutes idle
  • User resumed session normally after sign-in

Functional Confirmation:

  • Consistent enforcement across devices
  • No issues observed
  • Audit logs confirmed correct behavior

9. Timeline

  • Testing: Completed
  • Implementation: 3–5 business days
  • Validation: 1–2 business days

10. Approval and Sign-off

Signature: Christopher Denno
Date: 5/8/2025

2025-Q2-INT-003 – CAAS - W365 Device Filter

Project Title:
Modify W365 device filter to include “Windows 365” and “Cloud PC”

Change Identifier:
2025-Q2-INT-003

Date:
2025-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

A device filter in Microsoft Intune has been modified to accurately target all Windows 365 Cloud PCs by identifying both “Windows 365” and “Cloud PC” strings in the device model. This filter allows for precise assignment of compliance policies, configuration profiles, and Conditional Access policies to Cloud PC environments. This change ensures more consistent policy enforcement across all Windows 365 deployments regardless of naming convention.

2. Background and Justification

Microsoft 365 Cloud PC models can appear under different names in device inventory depending on the provisioning method or updates to Microsoft’s backend systems. Previously, the filter only recognized “Windows 365” as the device model, potentially excluding Cloud PCs reported as “Cloud PC”. By modifying the filter to include both naming patterns, we ensure complete coverage for policy targeting and avoid misconfigured or unprotected Cloud PCs.

3. Impacted Controls

  • CM.L2-3.4.1
  • CM.L2-3.4.2

4. Scope of Change

  • Modify existing “CAAS - W365 Devices Filter”
  • Modify expression to include devices where:
    device.model -contains "Windows 365"
  • Keep intact expression:
    device.model -contains "Cloud PC"

5. Objectives

  • Ensure all Windows 365 Cloud PCs are accurately targeted in policy assignments.
  • Prevent any policy gaps caused by incomplete model detection.
  • Maintain clean and centralized targeting logic for use in Conditional Access, compliance, and configuration policies.

6. Change Details and Specifications

Configurations:

  • Device Filter Name: CAAS - W365 Device Filter
  • Filter Rule Expression:
    (device.model -contains "Windows 365") or (device.model -contains "Cloud PC")

Implementation Plan:

  • Modify the existing filter in Microsoft Intune under Devices > Filters.
  • Use rule builder or rule syntax to update the logic.

Rollback Procedures:

  • If any issues arise, revert the filter to its previous state by removing the "Cloud PC" expression.

7. Impact Assessment

This update has no impact on end-user experience. It enhances backend accuracy in policy assignment. All future and existing Cloud PCs, regardless of naming, will now receive the correct profiles and Conditional Access enforcement. No devices outside of the Windows 365 ecosystem will be affected.

8. Testing and Validation

Filter Logic Verification:

  • The modified filter expression was confirmed to correctly include devices with model names containing either “Windows 365” or “Cloud PC.”
  • The logic was reviewed and validated using the rule syntax editor in Microsoft Intune.

Policy Targeting Accuracy:

  • The updated filter was applied to a test compliance policy and Conditional Access policy.
  • Testing showed that only Windows 365 Cloud PCs were included, and no unintended devices were affected by the filter.

Device Inclusion Review:

  • The Intune portal was used to view all devices matched by the new filter criteria.
  • Devices labeled as either “Windows 365” or “Cloud PC” were successfully captured, confirming both naming conventions were properly recognized.

9. Timeline

  • Testing: Completed
  • Implementation: 3–5 business days
  • Validation: 1–2 business days

10. Approval and Sign-off

Signature: Christopher Denno
Date: 5/8/2025

📊 Sentinel (SENT)

2025-Q2-SENT-001 – CAAS - Sentinel Workbook Dashboard

Project Title:
IT Security Baseline Configuration Update – Sentinel Workbook Dashboard

Change Identifier:
2025-Q2-SENT-001

Date:
2025-Q2

Prepared By:
James Paul
MS 365 Tier 2 Support / Compliance Officer
Government Operations

Reviewed By:
Christopher Denno
Senior Compliance Officer
Government Operations

1. Executive Summary

To improve visibility into security operations and meet key CMMC Level 2 requirements, a custom Microsoft Sentinel workbook titled “CMMC Dashboard” has been developed and deployed. This dashboard provides a centralized, real-time view of audit logging health, user sign-in activity, incident trends, privileged access events, and inactive user accounts, all mapped directly to relevant CMMC controls.

The workbook enables continuous monitoring across core areas such as audit log ingestion (AU.L2-3.3.4), least privilege enforcement (AC.L2-3.1.5), and account deactivation (AC.L2-3.5.6). It supports both security operations and compliance stakeholders by consolidating essential telemetry into a single pane of glass, improving detection, reporting, and readiness for regulatory assessments.

The implementation is non-intrusive, introduces no operational risk, and significantly enhances the organization’s ability to validate and maintain CMMC control coverage in real time.

2. Background and Justification

Microsoft Sentinel provides powerful data collection and alerting capabilities, but it lacks a built-in, centralized dashboard tailored to compliance frameworks such as CMMC Level 2. Prior to this implementation, analysts and compliance personnel were required to manually query data or review multiple disconnected dashboards to track user activity, audit log health, role elevation, and inactive accounts.

3. Impacted Controls

  • ACL.L2-3.1.5
  • IA.L2-3.5.6
  • AU.L2-3.3.2
  • AU.L2-3.3.4
  • IR.L2-3.6.1

4. Scope of Change

  • Deployment of a custom Sentinel workbook titled “CMMC Dashboard” to enhance visibility into audit logging, user activity, and access control. The workbook includes multiple tabs displaying real-time data related to sign-in events, security incidents, privileged role usage, and inactive accounts.
  • Deployment of the CMMC Dashboard workbook within Microsoft Sentinel.
    • Visualization of data from key tables (e.g., SigninLogs, AuditLogs, SecurityAlert, AzureActivity).
    • Control alignment with CMMC Level 2 requirements including AU.L2-3.3.4, AC.L2-3.1.5, and AC.L2-3.5.6.

5. Objectives

  • The objective of the CMMC Dashboard workbook is to provide a centralized, real-time view of key security and compliance data within Microsoft Sentinel.
  • To enable monitoring of audit log health, privileged access activity, and inactive user accounts, all mapped to CMMC Level 2 controls.
    • This improves operational visibility, supports proactive compliance tracking, and streamlines daily oversight for security and compliance teams.

6. Change Details and Specifications

Configurations:

  • Deploy custom Sentinel workbook titled “CMMC Dashboard”

Workbook includes the following visual tabs:

  • Sign-In Activity:
    Interactive visualizations of recent user sign-ins and anomalies
  • Incidents:
    Overview of triggered Sentinel incidents
  • Account Control:
    • Privileged Role Activity → AC.L2-3.1.5
    • Inactive AAD Accounts → AC.L2-3.5.6
  • Audit Logging:
    Displays latest log timestamps from key connectors to verify ingestion → AU.L2-3.3.4

Implementation Plan:

  • The workbook is read-only and non-intrusive
  • It pulls data from existing tables and is safe to deploy immediately

Rollback Procedure:

  • Delete the workbook from the Sentinel > Workbooks blade
  • No system configurations or policies are modified

7. Impact Assessment

This change improves audit log visibility and ensures early detection of connector failures, supporting CMMC AU.L2-3.3.4. It simplifies compliance validation, enhances monitoring, and carries no operational risk.

8. Testing and Validation

Data Verification:

  • Each visual tab successfully pulled real-time data from SigninLogs, AuditLogs, SecurityAlert, and AzureActivity
  • Data aligned with expected outputs

Query Integrity:

  • All KQL queries reviewed for syntax and logic
  • Filters (e.g., time ranges, event types) confirmed correct

Tab Functionality:

  • All interactive controls, charts, and tables rendered correctly
  • Navigation was smooth; visuals responded without error

Control Mapping Review:

  • Visuals cross-referenced with CMMC control objectives
  • Each dashboard tab confirmed alignment with compliance expectations

9. Timeline

  • Testing: Complete
  • Implementation: 3–5 business days
  • Validation: 1–2 business days

10. Approval and Sign-off

Signature: Christopher Denno
Date: 5/12/2025

2025-Q2-SENT-002 – CAAS - Sentinel Data Connector Analytic Rule

Project Title:
IT Security Baseline Configuration Update – Sentinel Data Connector Analytic Rule

Change ID:
2025-Q2-SENT-002

Date:
Q2 2025

Prepared By:
James Paul
MS 365 Tier 2 Support / Compliance Officer
Government Operations

Reviewed By:
Christopher Denno
Senior Compliance Officer
Government Operations

1. Executive Summary

To strengthen audit logging integrity and meet CMMC Level 2 compliance requirements, an analytic rule has been implemented in Microsoft Sentinel to detect when critical data connectors have not ingested logs within the past 72 hours. This rule provides proactive alerting for audit pipeline failures, ensuring visibility into potential logging gaps that could otherwise go unnoticed.

The rule evaluates key log sources such as AuditLogs, SigninLogs, SecurityAlert, and AzureActivity, all essential for security monitoring and regulatory reporting. If any of these connectors fail to send data within the defined window, the rule generates a high-severity alert, allowing timely investigation and remediation.

This analytic rule directly supports CMMC AU.L2-3.3.4 (Alert on Audit Log Failure) and complements broader logging and visibility efforts across the environment.

2. Background and Justification

Audit logs are a foundational component of cybersecurity monitoring, forensic investigation, and regulatory compliance. Microsoft Sentinel relies on a wide range of data connectors to continuously ingest telemetry from sources such as Azure AD, Microsoft 365, Defender, and other cloud and endpoint platforms. However, Sentinel does not natively alert when a data connector stops sending logs, creating a blind spot in log continuity.

3. Impacted Controls

  • AU.L2-3.3.4
  • SI.L2-3.14.3

4. Scope of Change

  • Microsoft Sentinel analytic rule creation and deployment
  • Monitoring of log ingestion from the following tables:
    • AuditLogs
    • SigninLogs
    • OfficeActivity
    • AzureActivity
    • SecurityAlert
    • DeviceEvents
    • DeviceLogonEvents
    • DeviceProcessEvents, etc.
  • Alerts notify security/compliance teams when ingestion lapses occur

5. Objectives

  • Detect when critical Microsoft Sentinel data connectors stop ingesting logs for 72+ hours
  • Support CMMC AU.L2-3.3.4 compliance
  • Reduce risk of undetected telemetry gaps
  • Enable prompt response to potential audit log failures

6. Change Details and Specifications

Configurations:

  • Analytic Rule Title:
    “Audit Log Ingestion Failure – 72 Hour Threshold”

  • Schedule:
    Runs every 72 hours

  • Evaluation Logic:
    Checks the most recent TimeGenerated timestamp for each connector.
    Triggers an alert if no logs have been ingested in the past 72 hours

  • Severity:
    High

  • Notification Mechanism:
    Action group – email or ticket to security/compliance team

Implementation Plan:

  • Non-disruptive and safe to deploy immediately
  • No impact to existing Sentinel functionality
  • No changes made to tenant configuration

Rollback Procedures:

  • Disable or delete the analytic rule from Sentinel > Analytics
  • No residual changes after removal

7. Impact Assessment

This change improves audit log visibility and ensures early detection of data connector failures. It supports CMMC compliance (AU.L2-3.3.4) and enhances security operations. The implementation is low-risk and does not interfere with production services.

8. Testing and Validation

Simulated Scenario:

  • Disabled a low-volume connector in a test environment to simulate log failure
  • Rule correctly triggered once threshold was met

Rule Execution Verification:

  • Rule ran on schedule and detected absence of log data
  • Results matched expected behavior

Alert Generation Check:

  • Alert included connector name, last log timestamp, and severity
  • Reviewed for accuracy and completeness

Notification / Action Validation:

  • Alerts triggered email and playbook actions to response teams
  • Routed correctly without delay

False Positive Screening:

  • Rule did not trigger on known inactive connectors
  • Demonstrated appropriate selectivity

9. Timeline

  • Testing: Complete
  • Implementation: 3–5 business days
  • Validation: 1–2 business days

10. Approval and Sign-off

Signature: Christopher Denno
Date: 5/12/2025

📌 Q2 2025 Summary – CAAS Security Baseline Updates

The Q2 2025 baseline updates reflect a comprehensive push toward Zero Trust alignment and CMMC Level 2 compliance across all major control domains. Conditional Access policies were enhanced with new MFA enforcement and privileged session reauthentication. Intune configurations improved endpoint hardening and policy targeting, including idle timeouts, device filters, and mandatory login banners. Microsoft Sentinel saw the introduction of a purpose-built CMMC Dashboard and automated ingestion monitoring, improving audit log reliability and control mapping. Lastly, Defender for Endpoint risk posture was elevated through standalone compliance enforcement and real-time remediation triggers. Collectively, these changes tighten access control, elevate telemetry fidelity, and reduce compliance friction through automation and visibility.