Trackr.Live The landing site for Trackr Services
§ Trackr.Live

CM — Configuration Management

Configuration Management decides whether the system an assessor walks up to is the system the paperwork describes. CM governs the known-good state: what the baseline is, how it was set, who is allowed to change it, and how changes get reviewed before they ship. It’s the family where the gap between the SSP and the running machine is widest, because configuration drifts on its own and nobody files a ticket when it does. Most other families assume CM is working. If your baseline is fiction, your scan results, your least-privilege story, and half your inherited controls are fiction too.

A golden master image on the left diverging from a running system on the right, with a diff highlighting drifted configuration settings between them.

CM is a control-catalog family in SP 800-53, not a phase of the RMF. The RMF is the SP 800-37 Rev 2 process: Prepare, Categorize, Select, Implement, Assess, Authorize, Monitor. CM controls get pulled into your control set at Select (the 800-53B baseline for your impact level decides which ones), stood up and written into the SSP at Implement, graded at Assess. Then they live or die in Monitor, which is really the family’s natural home: configuration management is a continuous-monitoring problem wearing a control-selection costume. A baseline is correct exactly once, at the moment you certify it, and decays immediately after.

What’s in the family

In Rev 5 the family runs CM-1 through CM-14, and unlike AC there are no withdrawn controls to flag here. CM-14 (Signed Components) is the last one; there is no CM-15. If you see a CM control cited above 14, someone invented it. A couple of the names changed in the Rev 4-to-Rev 5 pass (the catalog dropped “Information System” in favor of “System” everywhere), so CM-8 is System Component Inventory, not the old “Information System Component Inventory.” An SSP still using the longer name is quoting Rev 4.

The ones that carry the weight:

  • CM-2, Baseline Configuration. The documented known-good: hardware, software, firmware, and the settings that define them. CM-2(2) automates baseline maintenance, CM-2(3) retains previous versions so you can roll back, CM-2(7) handles baselines for systems going into high-risk areas (think travel laptops). The golden image, and the control most likely to be a lie by month three.
  • CM-3, Configuration Change Control. The change process and the board that runs it (CCB, or CAB if you came up through ITIL). CM-3(2) wants changes tested, validated, and documented before they go live. This is where the paper trail for every later “wait, when did that change” question either exists or doesn’t.
  • CM-4, Impact Analyses. The security impact analysis (SIA) you run before a change, not after the incident. CM-4(1) pushes that analysis into a separate test environment so you aren’t learning the blast radius in production.
  • CM-5, Access Restrictions for Change. Who can actually touch the config, enforced technically. This is CM’s tie into AC-6 least privilege and AC-3 enforcement; if anyone with a login can edit the baseline, CM-5 is decorative.
  • CM-6, Configuration Settings. The hardened settings themselves. For this audience that means DISA STIGs, SCAP-validated scanning, and CIS Benchmarks. CM-6(1) automates management and verification of those settings; CM-6(2) is about responding when something changes a setting it shouldn’t have. The most operationally loaded control in the family.
  • CM-7, Least Functionality. Turn off what you don’t need: ports, protocols, services, default features. CM-7(1) reviews what’s actually running, CM-7(2) prevents unauthorized program execution, and CM-7(4)/(5) are the deny-list / allow-list pair. Allow-listing is CM-7(5), not CM-10.
  • CM-8, System Component Inventory. Every component, tracked. CM-8(1) updates it on install and removal; CM-8(3) is automated detection of unauthorized components. The perennial finding lives here.
  • CM-9, Configuration Management Plan. The plan that ties the family together for the system. Usually first at Moderate.
  • CM-10, Software Usage Restrictions. Software license and copyright compliance, tracking usage against the terms you actually licensed. CM-10(1) covers open-source specifically. It is not the “only authorized software runs” control (that’s CM-7) and not the user-install control (that’s CM-11).
  • CM-11, User-Installed Software. What end users are allowed to install themselves, and the policy that bounds it.

CM-12 (Information Location) tracks where information and its processing actually live, for data-residency and scope; Moderate and up. CM-14 (Signed Components) requires verifiable signatures and is your supply-chain tie into the SR family, but like CM-13 it isn’t allocated to any security baseline; it only enters through tailoring or an overlay. CM-13 (Data Action Mapping) is the odd one out: it’s a privacy control. It maps data actions (collection, sharing, processing) to the system elements that perform them, for the privacy program, and it does not appear in the Low/Moderate/High security baselines at all. It rides in through privacy control selection. Any page telling you CM-13 maps data actions to the security controls that protect the data has it backwards.

Baselines and where the controls come from

The baselines moved out of the catalog in Rev 5 and now live in SP 800-53B, the document you tailor against. FIPS 199 sets your impact level, FIPS 200 sets the security floor, and 800-53B turns the impact level into a starting control set. National-security systems use the CNSSI 1253 overlay instead; FedRAMP and DoD (DoDI 8510.01) layer their own on top.

Most of the family starts at Low: CM-1, CM-2, CM-4, CM-5, CM-6, CM-7, CM-8, CM-10, and CM-11 are all allocated from Low up. CM-3 (formal change control) and CM-9 (the plan) typically first appear at Moderate, as does CM-12. Neither CM-13 nor CM-14 is in the security baselines at all; both ride in only through tailoring or an overlay. The enhancements are where the impact level really bites: CM-6(1) automation, CM-7(5) allow-listing, and CM-8(3) automated unauthorized-component detection get pulled in as you climb to High, and tailoring them back out is a conversation with the AO, not a checkbox.

Deeper: a baseline configuration is not a baseline control set, and people conflate them constantly. Two different things share the word “baseline” in this family. The CM-2 baseline configuration is a technical artifact: the golden image, the documented known-good build of this specific system. The 800-53B baseline is a control-selection artifact: the starting list of controls for your impact level, before tailoring. CM-2 is a thing you build and image; the 800-53B baseline is a thing you select from. When a reviewer asks “what’s your baseline,” figure out which one they mean first, because the evidence is completely different. For CM-2 it’s the image and the diff against running hosts. For the 800-53B baseline it’s the tailoring rationale in the SSP showing how you got from the impact-level starting set to your final control selection.

Control Typical first live at What an assessor actually checks
CM-2 Low The documented golden image, then a diff against a sample of running hosts. Drift between the doc and the box is the finding.
CM-3 Moderate Change records exist, each change went through the CCB, and there’s a CM-4 impact analysis attached. Pull a recent change and trace it end to end.
CM-5 Low Who can modify the config, enforced technically, mapped to AC-6. Not just a policy statement.
CM-6 Low STIG/CIS settings applied, verified by a SCAP-validated scan. Open findings either remediated or in the POA&M with a real rationale.
CM-7 Low Ports/protocols/services actually disabled, not just listed. On High, allow-listing (CM-7(5)) is enforced and the list is current.
CM-8 Low The inventory matches what a scan finds on the wire. Components on the network but not in the inventory = finding, every time.
CM-11 Low Users can’t install arbitrary software, and the control is enforced, not aspirational.

Treat the “first live at” column as directional. Your overlay moves things, and FedRAMP or a DoD overlay will pull enhancements in earlier than the bare 800-53B allocation.

Where it actually goes wrong

CM-2 baseline drift. The golden image is true the day it’s certified. Then a sysadmin patches a host out of band, an emergency change skips the imaging pipeline, a one-off fix lands on three of forty servers and never gets folded back into the master. The SSP still describes the clean image. Here’s the flag I’ll plant: the documented baseline almost always diverges from the running baseline, and assessors should diff, not trust the doc. Don’t read the CM-2 narrative and tick the box. Pull the master, pull a sample of live hosts, diff them. The divergence is the assessment. If you own the control, the honest fix is CM-2(2) automation plus configuration-as-code, so the running state and the documented state are the same artifact instead of two that agree on a good day.

CM-6 and the STIG-tailoring habit. CM-6 is where DISA STIGs and SCAP scanning meet the system. Run a SCAP-validated scanner (the DoD shop usually has SCC or the ACAS/Tenable SCAP content feeding the same machinery), get the findings, remediate or document. The failure mode is the POA&M dumping ground: a STIG finding gets tailored out as “operational impact” and parked with a rationale nobody revisits. Some are legitimate (the setting genuinely breaks a mission application). Plenty are not. Tailoring out CM-6 findings as “operational impact” is overused, and a sharp assessor will sample those POA&M entries and ask you to prove the impact is real. A CAT II finding deferred eighteen months because “the app team is busy” is not an operational-impact exception. It’s an open finding wearing a costume.

CM-8 inventory rot. The perennial finding, and it’s structural. An inventory is a snapshot of a thing that changes faster than anyone updates the snapshot. New VMs spin up, containers come and go, a contractor racks a box for a demo and forgets it, the asset database hasn’t been reconciled against the network since the last assessment. Then the SSP claims “automated inventory” because there’s a tool with a dashboard, and the dashboard covers the managed fleet but not the dev subnet, not the OT segment, not the three things behind the load balancer the agent never reached. Most “automated inventory” claims overstate their coverage. The tie that makes this matter: you cannot scan what you do not inventory, so CM-8 feeds RA-5 vulnerability scanning directly and rolls up into PM-5 at the organization level. An assessor who runs an independent discovery scan and finds live hosts missing from your CM-8 inventory has just falsified your RA-5 coverage in the same motion.

CM-3 change control that’s a rubber stamp. The CCB meets, the minutes exist, and the actual change went in on Tuesday and got “ratified” at the Thursday board because production already depended on it. The CM-4 security impact analysis, if it happened, was written to justify a decision already made. Pull a recent significant change and trace it: request, SIA, board approval, test evidence (CM-3(2)), implementation. If the timestamps run backward, the control is theater. On systems with a development pipeline this ties into SA-10 developer configuration management, because the change control that matters happens in the build, not at the board.

Artifacts

CM evidence lands in a few places. The SSP carries the per-control narrative, and catalog paraphrase fails here as everywhere in 800-53: an assessor wants the actual STIG baseline you applied, the actual scanner, the actual change process, not the control text read back. The CM plan (CM-9) is its own artifact, and assessors ask for it by name. Then the live evidence: the golden image, the SCAP results, the change records, the inventory export. The fastest way to fail a CM assessment is an SSP that says “the organization maintains a baseline configuration” with no image, no diff, no scan behind it. They’ve read the catalog. They want to know what your build actually looks like and whether the running fleet matches it.

If your CM narratives could be pasted into any other system’s SSP unchanged, they’re too generic to pass, and generic CM prose is one of the most common reasons these controls come back Other Than Satisfied.

Sources

Adjacent material on this site