Security Baseline Change Request

  • 9 minutes to read

Purpose

This SOP outlines the process for requesting, reviewing, approving, and implementing changes to the security baseline configuration. The security baseline configuration is defined as any endpoint device policy setting provided by Nimbus Logic at the time of onboarding. This procedure ensures that all security changes align with compliance requirements and business needs while maintaining system integrity.

Scope

This procedure applies to all organizations utilizing Compliance-as-a-Service and includes actions for both the Organization seeking certification (OSC) and the External Service Provider (ESP).

Section 1: Organization seeking certification (OSC) Steps

While the OSC is using a managed baseline security configuration, provided by Nimbus Logic, there is allowance for modifications to the baseline configuration. The following is a pre-defined listed of allowed modifications that can be requested by the OSC.

  • User onboarding & offboarding
  • Device onboarding & offboarding
  • USB whitelisting
  • Entra ID role adjustments
  • SharePoint Online role adjustments
  • Application whitelisting
  • Controlled Folder Access exclusions
  • Application registration for purposes of SSO with Entra Id
  • MFA Factor adjustments
  • Configuration settings that are more restrictive than baseline provides, such as requiring TLS 1.3+, password complexity, password history, session frequency, etc.

Step 1: Submit a Security Baseline Change Request

  • Requests must be submitted via email to support@nimbus-logic.us.
  • Only authorized personnel in the following role may submit requests:
    • Authorized Managers
  • The request must include:
    • Proposed configuration change details
    • Business justification for the change, if modifying technical configuration settings.

Step 2: Await Review and Notification

  • The request will be reviewed by the ESP IT team to determine its compliance and security impact.
  • Additional information may be requested if necessary.
  • The requester will receive notification on the status of the request after review.

Section 2: External Service Provider (ESP) IT Team Steps

Prerequisites

  • Confirm that the requestor has the necessary role authorization.
  • Ensure all required information is included in the request.

Reviewing the Security Baseline Change Request

  1. Assess the request against compliance and security requirements by reviewing affected controls.
  2. Determine the impact of the requested change.
  3. Provide recommendations on risks and required mitigations.
  4. Advise the requester and relevant stakeholders on findings for further approval.

Implementing the Security Baseline Change

  1. Upon approval, make the necessary configuration changes as per security best practices.
  2. Validate the change to ensure no unintended security gaps are introduced.
  3. Generate and document the new configuration settings.
  4. Provide the updated configuration export document to the client for record-keeping purposes.

Monitoring and Compliance

  • Regularly audit changes to ensure adherence to security policies.
  • Maintain logs of all approved changes for compliance tracking.
  • Review baseline settings periodically to align with evolving security standards.

Section 3: Full Formal Change Control Procedures

These change control procedures will be used when making any changes to the Compliance as a Service security baseline.

Change Request to Official Baseline

For any changes made to a security baseline, an official change proposal document will be created using the template found on this page. Once the proposal has been drafted, an official review will be discussed amongst the Nimbus Logic compliance officers to discuss all areas of proposal. Formal proposals are necessary for configuration changes as they relate to device security, or additional security controls in the Microsoft cloud. Modifications that include role modifications, new Sentinel connectors and other non-configurational changes are not required to have a proposal written, and only require communication between ESP & OSC.

Upon acceptance, each member is to sign and date the proposal document. After signing, the document is to be stored in the cmmc-baseline GitHub repository, in the baseline-changes folder.

Execution of the proposed change is to begin according to the timeline established in the proposal. An Asana project will be created to track the change for all CAAS clients. A notice will be sent to the compliancealerts@domain.com distribution group email, as well as all authorized managers of each tenant, to notify of upcoming configuration changes.

Technical Configuration Change Proposal Template

Project Title:
IT Security Baseline Configuration Update – [Insert Specific Change Details]

Date:
[Insert Date]

Prepared By:
[Insert Preparer’s Name, Title, Department]

Reviewed By:
[Insert Reviewer’s Name, Title, Department]

1. Executive Summary

Provide a high-level overview of the change, its purpose, and anticipated benefits. This section should briefly explain why the change is necessary, addressing any regulatory requirements under CMMC 2.0 and the potential positive impacts on security and compliance.

Example:
This proposal outlines a technical configuration change to enhance our organization’s security baseline to meet the requirements of CMMC 2.0 Level 2 compliance. The proposed change will involve updating firewall settings to strengthen access controls and improve monitoring capabilities, helping to ensure data integrity and confidentiality for Controlled Unclassified Information (CUI).

2. Background and Justification

Explain the context for the change and the specific CMMC 2.0 control requirements that the change will address. Include any identified gaps in current configurations and a justification for why this change is necessary to meet compliance and security standards.

Example:
According to the recent GAP analysis conducted by [Gap Accelerator], our firewall settings do not fully meet the Access Control (AC) and Audit and Accountability (AU) requirements under CMMC 2.0 Level 2. This configuration change is critical to strengthening perimeter defenses and ensuring compliance with security requirements, especially for handling CUI.

3. Scope of Change

Define the scope of the proposed change, including affected systems, networks, applications, or user groups. Be as specific as possible to limit the change scope.

Example:
The scope of this configuration change includes:

  • Updating firewall rules for all servers handling CUI.
  • Implementing new access control measures on VPN and remote access points.
  • Configuring additional logging to comply with AU requirements on systems within the production network.

4. Objectives

List the specific objectives of the configuration change, mapping them to relevant CMMC 2.0 controls or other security benchmarks.

Example:

  • Enhance access controls to meet AC.1.001 and AC.3.001 requirements.
  • Improve logging and monitoring in alignment with AU.2.041 and AU.3.045 standards.
  • Mitigate vulnerabilities identified in the recent GAP analysis for [specific system or component].

5. Change Details and Specifications

Describe the technical aspects of the change. This section should include:

  • Configurations: Describe specific configuration updates, such as firewall rule changes, security group adjustments, or logging settings.
  • Implementation Plan: Outline steps for implementing each configuration change.
  • Rollback Procedures: Define a rollback plan in case issues arise during the change.

Example:
Configurations will include adjustments to inbound and outbound firewall rules to restrict IP ranges to authorized users. Implementation will be staged over a two-week period, with monitoring and validation conducted at each phase.

6. Impact Assessment

Assess the potential impact of the change on users, systems, and operations. Include any expected performance improvements, possible disruptions, or downtime. List potential risks associated with the change, including compliance risks if the change is not implemented. Specify mitigation strategies for each risk.

Example:
This change will enhance security but may temporarily impact system performance during implementation. Users with access to CUI will be required to authenticate via multi-factor authentication (MFA) following the update, potentially impacting login times by a few seconds.

7. Testing and Validation

Detail the testing plan to validate the configuration change post-implementation. Include specific tests and criteria for success.

Example:
Testing will involve:

  • Conducting a vulnerability scan to confirm no unauthorized access.
  • Verifying that audit logs capture all access attempts and monitor remote access.

8. Timeline

Provide a timeline for each stage of the implementation, testing, and validation processes.

Example:

  • Week 1: Configuration adjustments on non-production systems.
  • Week 2: Implementation on production systems.
  • Week 3: Validation and final compliance check.

9. Approval and Sign-off

Provide spaces for signatures from key stakeholders, including IT, Security, Compliance, and affected department heads.

Signature: ___________

Name: ___________

Date: ____________

Review & Maintenance

This SOP will be reviewed on a quarterly basis or as required by changes in compliance regulations or security policies.