Configuration Management (CM)

Configuration Management (CM)

This guide was developed to simplify and explain the key elements of Chapter 5 of the CMS Risk Management Handbook, which focuses on Configuration Management (CM). Its goal is to help users understand and implement CM controls more easily by breaking the requirements into clear, actionable steps. This family of controls is taken from the National Institute of Standards and Technology (NIST) Special Publication 800-53 and tailored to the CMS environment in the CMS Acceptable Risk Safeguards (ARS).

The guide provides user-friendly explanations of how to establish baseline configurations, control system changes, automate configuration tracking, manage inventory, and reduce unnecessary system functionality. It serves as a practical tool to reinforce compliance and maintain the integrity and availability of CMS information systems.

What is Configuration Management (CM)

Configuration Management is a process that helps CMS keep track of all the parts of its information systems—such as software, hardware, and network settings. It ensures that everything is set up correctly, stays secure, and is updated in a controlled way. Think of it like maintaining a blueprint for your systems. Whenever something changes—like adding a patch, updating software, or changing settings—it gets recorded, reviewed, and approved. That way, CMS always knows exactly what’s in the system, what changed, who changed it, and why. This helps prevent mistakes, reduces security risks, and keeps systems running smoothly.

Understanding Configuration Management: The Basics

Baseline Configuration is an established version of a system’s setup that has been officially approved. It’s used as the starting point for any future updates or changes. Think of it like a saved template that can’t be changed unless someone follows the proper approval process.

A Configuration Management Plan (CM Plan) is a comprehensive description of the roles, responsibilities, policies, and procedures that apply when managing the configuration of products and systems. The basic parts of a CM Plan include:

• Configuration Control Board (CCB): A team that reviews and approves changes.
• Configuration Item Identification: A process for naming and keeping track of important parts of a system.
• Configuration Change Control: A step-by-step process for making updates the right way.
• Configuration Monitoring: Regular checks to make sure the system stays in its approved state.

These practices help CMS understand how each part of a system is set up, how changes are made, and how everything fits together. This is especially important for keeping systems secure and managing risk.

To keep things simple, CM can be broken into four main phases:

• Planning – Decide how configuration management will be handled.
• Identifying & Implementing – Choose what needs to be tracked and apply the correct settings.
• Monitoring – Regularly check that systems are still set up correctly.
• Controlling Changes – Review, approve, and document any updates.

By following these steps, CMS can keep its systems running safely and smoothly, even as they change over time.

Configuration Management Controls

CM controls are security measures that ensure IT systems remain in a secure, approved, and consistent state by tracking system components and managing changes. They help prevent unauthorized modifications, reduce vulnerabilities, and maintain the integrity of hardware, software, and settings across the system lifecycle. The following controls are further explained:

Baseline Configuration

This control ensures CMS creates and maintains a clear, approved setup for each information system—known as a baseline configuration. This includes things like installed software, operating system versions, configuration settings, and how all system components are arranged. Think of it like taking a detailed system snapshot at a point in time. Once approved, that setup becomes the official version, and any changes must go through a formal process.

The baseline configuration process begins with the System Owner and CCB identifying approved settings using CMS standards, which are then documented by the Developer and Maintainer. When a change is needed, the ISSO’s team plans and assesses the impact through PIA and SIA, designs and tests any necessary security features, implements and validates the changes, addresses any issues with POA&Ms, and requests a new or updated Authorization to Operate (ATO).

Reviews and Updates

To keep systems secure, CMS must regularly review and update its baseline configurations:

• Every 180 days for high-impact systems
• Every 365 days for moderate-impact systems
• Or when events such as system upgrades, emergency changes, or critical patches occur

Automation Support

CMS uses tools to automatically gather and track configuration information. This helps:

• Keep data accurate and current
• Support continuous monitoring
• Detect deviations from approved configurations

Retention of Previous Configurations

CMS keeps at least one backup of a system’s configuration. This allows quick recovery if something goes wrong during an update or patch.

Backups should include:

• Software and firmware versions
• System settings
• Connection and access details

Contingency Planning and System Recovery

CM is a key enabler of contingency planning and disaster recovery at CMS. Proper contingency planning ensures:

• Backups of configuration data are required to support rapid system recovery
• Resilience and the ability to maintain essential operations during and after disruptions
• Regular testing of backup and restore processes is essential for organizational resilience

More detailed information is located in the Information System Contingency Plan (ISCP).

Travel to High-Risk Areas

If CMS staff must travel to high-risk countries, they must:

• Use a loaner laptop (not their permanent GFE device)
• Notify appropriate teams in advance
• Receive a pre-travel security briefing
• Submit the device for post-travel inspection before reconnecting to the network

Configuration Change Control

Configuration Change Control is about managing changes to CMS systems in a secure, organized way. All changes—whether to hardware, software, or services—must be reviewed and approved before being made. The goal is to:

• Prevent unauthorized or risky changes
• Protect data confidentiality, integrity, and availability (CIA)
• Keep a clear record of who changed what, when, and why

CMS uses a Change Control Board (CCB) to review, approve, and track changes. This ensures decisions are made by a group—not just one person—and that security is always considered.

CMS manages configuration changes through a structured process that begins with planning and defining Configuration Items (CIs), documented in a Change Management Plan. A CCB—including the ISSO, developer, and other key stakeholders—reviews and approves change requests based on impact and security. Approved changes are implemented, documented, and audited to ensure compliance with CMS policy. All changes are recorded and retained for at least three years, with ongoing audits to maintain alignment with approved baselines.

Automating Change Control

CMS uses automation to notify decision-makers when changes are proposed, flag unapproved or overdue requests, and alert stakeholders when changes are completed. These automated tools help save time, improve traceability, and prevent missed steps or unauthorized changes.

Testing and Validating Changes

Before making any change in a live (production) environment, it must be thoroughly tested to prevent service disruptions and ensure the change does not cause unintended issues. Testing should be done in a separate environment that closely mirrors production, with all tests and their results documented. Changes should only be implemented in production if they successfully pass all checks.

Following this structured, secure process ensures that CMS systems stay stable, secure, and compliant with policy—while still allowing necessary updates to move forward efficiently.

Security Impact Analysis

Before CMS makes any changes to its systems, it’s important to understand how those changes might affect security. That’s where Security Impact Analysis (SIA) comes in.

SIA is a structured review done by cybersecurity professionals (e.g., ISSOs, engineers, system admins) to identify risks and decide if new protections are needed. It should be done before changes are made—but also in emergencies when changes happen quickly. The SIA helps CMS avoid surprise vulnerabilities and keeps systems secure, stable, and compliant.

For more information on how SIA maps to CM, visit the Security Impact Analysis (SIA) Cybergeek page.

Access Restrictions for Change

Controlling who can make changes to CMS systems is important to protect their security and stability. This control ensures that only authorized individuals can make changes, and that both physical and digital access is restricted and documented. This means:

• CMS limits access to system components and files to prevent unauthorized changes.
• Only approved individuals (such as those on the CCB) can approve and implement changes.
• Access controls include both technical (such as user permissions) and physical (such as locked rooms) safeguards.

As part of the CMS system development life cycle, OIT defines various access restrictions, including administrative, role-based, discretionary, and physical controls. The System Owner incorporates these into the system’s baseline configuration. The ISSO plays a key role by developing any missing physical access controls, documenting all access controls in CFACTS, and partnering with the Business Owner (BO) to review and approve changes. If a proposed change is not approved, the ISSO ensures it is properly documented as a Risk Acceptance Request in CFACTS.

Automated Access Enforcement/Auditing

This enhancement uses automation to check who accesses the system and whether they’re allowed to. It logs these actions so they can be audited later. This means:

• Systems must verify that users are authorized before allowing access.
• Logs must be kept to track who accessed what and when.
• This is especially important for changes to hardware, software, and firmware.

Review System Changes

Regular reviews are essential for catching unauthorized or unintentional system changes. The Change Control Board (CCB) should conduct weekly reviews and perform additional checks whenever performance issues or suspected unauthorized changes arise. The CCB conducts weekly reviews by comparing the current system configuration to the approved baseline and investigates any unusual performance or unapproved changes immediately. All unauthorized changes must be reported to the ISSO within 24 hours.

Signed Components

CMS requires that certain software and firmware be verified through digital signatures before installation so that it comes from trusted sources. These requirements help prevent unauthorized or malicious code from being installed and ensure software integrity.

Configuration Settings

Configuration settings define how CMS systems are securely set up and maintained. These settings are guided by standards from HHS and the U.S. Government Configuration Baseline (USGCB). If USGCB doesn’t apply, CMS uses the National Checklist Program or industry best practices such as CIS benchmarks. The goal is to apply consistent, secure configurations across all systems to reduce risk and simplify management.

Documenting Deviations from Baselines

When configurations deviate from the approved baseline due to operational needs, CMS uses a Risk Acceptance process to document all deviations with justifications. The ISSO reviews deviations and works with the BO to complete the Risk Acceptance form, then logs the request in CFACTS, which is reviewed annually for possible re-certification.

Centralized Management

CMS uses automation to centrally manage, apply, and verify settings across its infrastructure to ensure:

• System Developer sets up tools for automated management.
• ISSO coordinates with CMS’s Continuous Diagnostics and Mitigation (CDM) program.
• Regular scans are conducted to ensure compliance with configurations.
• Only approved changes are applied using automated tools.

Responding to Unauthorized Changes

When unauthorized changes are detected:

• System tools stop unauthorized changes and generate alerts.
• CDM alerts ISPG’s Incident Management Team or the responsible party, depending on the nature of the change.
• If needed, the team rolls back changes to restore the approved configuration and may stop system processing if there’s a risk.

This layered approach protects systems from unintended or malicious changes while ensuring transparency and accountability across CMS.

Least Functionality

Control Requirement: CMS limits or prohibits high-risk system services, ports, network protocols, and functions that are not absolutely required. This includes disabling anything that’s not essential, keeping a record of what’s allowed, and documenting everything in the CM Plan.

Periodic Review

Periodic reviews at CMS help reduce risk by identifying weaknesses and anomalies introduced through ongoing change management. Aligned with the Least Functionality control, these reviews minimize the attack surface and ensure that system scans and evaluations stay in step with changes to maintain security across the network.

Best practices to follow:

• The CDM team runs scans every 72 hours to check for changes or unauthorized functions.
• The ISSO reviews results at least every 30 days using CDM reports and compares them to the system’s design in CFACTS.
• If something shows up that shouldn’t be there, the developer and ISSO—with help from the CRA—disable it immediately.

Turning off unnecessary features shrinks the system’s attack surface—meaning fewer ways for bad actors to get in. Regular reviews help catch anything that may have changed without approval. It’s about staying secure and staying ahead of risk.

Prevent Program Execution

This control helps reduce risk by preventing unauthorized or dangerous software from running. It also ensures compliance with licensing laws and supports security principles like separation of duties. It helps protect CMS systems and ensure software is used safely and legally. CMS prevents users from running any software that isn’t properly licensed, approved, and configured for CMS use, and assigned to an authorized user.

Authorized Software/Allowlisting

CMS uses a process called “allowlisting” to maintain a list of software that is permitted to run. If software isn’t on the list, it can’t be used. This approach increases security by blocking unknown or unauthorized software, reducing the chance of malware running, and keeping CMS systems compliant and efficient.

Information System Component Inventory

CMS tracks all system components—hardware, software, and firmware—that process, store, or transmit CMS information. Every component must be uniquely identified, typically through an asset tag issued by the property office, and documented in the system inventory. This inventory includes key information like the component’s name, location, owner, description of use, and other operational attributes. The inventory must also integrate with CDM tools to support security monitoring and component accountability.

Configuration Management Plan

A CM Plan is a key part of the CMS System Development Life Cycle (CMS-SDLC). It lays out how configuration management will be handled for a system—including who is responsible for what, what processes will be followed, and which configuration items (CIs) are being tracked. The CM Plan defines roles and responsibilities to help CMS keep systems secure, consistent, and resilient. It supports effective change tracking, prevents unauthorized updates, and enables faster issue resolution and recovery.

Once finalized, the CM Plan must be protected just like a system’s configuration baseline—ensuring that only authorized users can access or change it.

Software Usage Restrictions

CMS requires that only authorized software be used on its information systems, and that it complies with all licensing and contractual obligations. Both CMS employees and contractors must follow proper procedures for installing, managing, and using software. Unauthorized software is prohibited and will be removed. CMS also restricts peer-to-peer (P2P) file sharing unless explicitly approved by the CIO.

This control protects CMS from legal and security risks, such as:

• Violations of software licensing agreements
• Unauthorized use or distribution of copyrighted material
• Potential malware exposure through unapproved applications

User-Installed Software

To reduce risk to CMS systems, only approved personnel can install software. Most CMS-issued devices (government-furnished equipment, or GFEs) will block regular users from installing programs. Privileged users (e.g., administrators) must follow specific CMS procedures to install any software. Unauthorized software installations can introduce malware, cause compatibility issues, or violate software licensing agreements. This control ensures that CMS systems stay secure, stable, and compliant. CMS requires the following:

• Users cannot install software on GFEs.
• Privileged users may install software only using approved procedures listed in the System Security and Privacy Plan (SSPP).
• Monthly monitoring is conducted to verify compliance with this policy.
• Software monitoring tools must meet CMS’s CDM requirements to ensure standardization across systems.

Summary of Configuration Management within CMS

In summary, the CMS Configuration Management Guide provides a structured, practical approach to maintaining secure, consistent, and well-documented information systems. By aligning with NIST standards and tailoring controls to the CMS environment, the guide helps ensure that every system change is tracked, reviewed, and authorized—minimizing risks and maintaining compliance. With clear procedures for baseline management, automation, access control, inventory tracking, and software restrictions, this guide empowers CMS stakeholders to protect system integrity, support mission continuity, and respond effectively to evolving cybersecurity threats.