NIST 800-53 CM-2 Baseline Configuration and What to Show an Auditor

CM-2 is the baseline configuration control, and most of the Configuration Management family leans on it. Change control, settings, inventory and monitoring all assume a known starting point. Without that, there is nothing to compare against.

The statement has two parts. Develop, document and maintain under configuration control a current baseline configuration of the system. Then review and update it at a frequency you define, when required because of events you define, and when components are installed or upgraded.

800-53 binds US federal systems directly and others by contract. For a small or mid size company it is a reference, and customers asking how you keep systems consistent are usually asking CM-2 questions.

What the control asks

NIST describes baselines as documented, formally reviewed and agreed upon specifications for a system or the configuration items inside it. A baseline includes connectivity, operational and communications aspects. It also covers security and privacy control implementations, operational procedures, component information, network topology and the logical placement of components in the architecture.

Baselines serve as the basis for future builds, releases and changes. The guidance adds that new baselines are created as systems change, and that baselines reflect the current enterprise architecture. A baseline is not a one time snapshot.

What it means in practice

For a cloud native team a baseline is mostly code. Machine images, container base images, infrastructure templates, Kubernetes manifests and policy files, stored in version control, are the documented and controlled specification. For a mixed shop it also includes golden images for laptops and servers, network diagrams and a standard build checklist.

The words "under configuration control" matter. Changes to the baseline go through a process that records who changed what and why. That links CM-2 directly to CM-3.

Evidence to collect

• The baseline itself, such as image definitions, infrastructure as code repositories and build checklists.
• Version history showing changes, authors and approvals.
• The topology and architecture diagrams, dated.
• Review records, showing the last scheduled review and any event driven updates.
• Records of baseline updates after installs or upgrades.
• A comparison between the baseline and running systems, showing drift is detected.

Common gaps

• Baseline is a wiki page, while real servers were built by hand.
• No review is recorded, so the baseline falls behind reality.
• Production is built from one image, development from another, and nobody has documented the difference.
• Old baselines are discarded, so you cannot answer what a system looked like before an incident. CM-2.3, Retention of Previous Configurations, addresses this.
• Topology diagrams do not match what is deployed.

How to implement it

1. Choose the scope. Start with production workloads and the laptops that touch them.
2. Express the baseline as code or as an image, and store it in version control with branch protection.
3. Define what triggers a rebaseline. Common triggers are an operating system major version, a new region, a significant security advisory and a new service type.
4. Schedule a review, quarterly or twice a year, and attach it to a ticket that records the outcome.
5. Compare running systems to the baseline automatically and route differences to a person.

The enhancements show where maturity goes next. CM-2.1 is Reviews and Updates, CM-2.2 is Automation Support for Accuracy and Currency, CM-2.3 is Retention of Previous Configurations, CM-2.4 is Unauthorized Software, CM-2.5 is Authorized Software, CM-2.6 is Development and Test Environments, and CM-2.7 is Configure Systems and Components for High risk Areas. Pick the ones your risk calls for. High risk areas, such as travel laptops, are a good example of a place for a tighter baseline.

Mapping to other frameworks

Mappings vary by source and version. If you need to show CM-2 against SOC 2, ISO 27001 or another framework, check an authoritative crosswalk for the exact versions you are assessed against and do not assume a one to one match.

Quick check

Sources

• NIST SP 800-53 Rev 5, CM-2 Baseline Configuration
• NIST OSCAL SP 800-53 Rev 5 catalog