What NIST actually calls a baseline
Ask a network team for its baseline configuration and you’ll usually get a folder of running configs, pulled nightly by a backup job. That archive is useful. It isn’t what SP 800-53 Rev. 5 means by the word. The glossary defines a baseline configuration as a documented set of specifications “that has been formally reviewed and agreed on at a given point in time, and which can be changed only through change control procedures.” The CM-2 discussion says the same thing in fewer words: baselines are “documented, formally reviewed, and agreed-upon specifications.”
A config pulled at 2 a.m. fails both tests. Nobody reviewed it, and it records whatever the device looked like that night, including last Tuesday’s change that never went past the change board. It’s evidence of the actual state. The baseline is the approved state, and the distance between the two is exactly what an assessor is looking for.
One more trap: “baseline” means two things in NIST documents. A control baseline (Low, Moderate, High) is a set of controls, and since Rev. 5 those live in SP 800-53B. A baseline configuration is a device-level specification under CM-2. This post is about the second one, and it doesn’t assume which control baseline you tailored.
CM-2: keep an approved state, and the ones before it
CM-2 asks you to “Develop, document, and maintain under configuration control, a current baseline configuration of the system,” and to review it on a schedule you set, when circumstances you define require it, and “When system components are installed or upgraded.” For a network, the baseline is more than a stack of configs. It’s the hardening standard for each platform, the approved rule base as of its last review, and the topology your architecture describes.
CM-2(2) asks for automated mechanisms that keep the baseline current, complete, accurate and available. This is where a collector earns its place. It can’t tell you what the baseline should be, but it can tell you on every sync where a device has moved away from it. CM-2(3) asks you to keep a number of previous versions “to support rollback.” A snapshot history gives you those versions. The rollback itself is still a person working a change ticket.
CM-3 has two halves, and a tool only covers one
Configuration change control reads like one requirement, but it splits cleanly. Items a to d and g are the decision half: define which changes are controlled, review and approve them with their security impact in mind, record the decisions, carry out only what was approved, and run a change board. Items e and f are the record half: “Retain records of configuration-controlled changes to the system for” a period you define, and “Monitor and review activities associated with configuration-controlled changes to the system.”
Change detection belongs to the record half. It gives you a timestamped diff for every change, attributed to an admin, and it keeps working when the device’s own audit log doesn’t. The decision half belongs to your change process, and no read-only tool should pretend otherwise. CM-3(1) makes the split obvious, because one ID holds six separate requirements.
CM-3(7) is the review assessors actually test
The enhancement that fits config monitoring best is CM-3(7): “Review changes to the system [Assignment: organization-defined frequency] or when [Assignment: organization-defined circumstances] to determine whether unauthorized changes have occurred.” If your control mapping still cites CM-5(2) for this, update it. Rev. 5 withdrew CM-5(2) and folded it into CM-3(7).
In practice the review is a reconciliation. Pull every change detected in the window, not just the ones the audit log recorded, match each one to an approved ticket, and treat whatever is left over as a finding.
Two details decide whether this review holds up. First, the input has to come from the devices’ actual state. Audit logs miss bulk imports, configuration restores and some automation runs, which is why snapshot-based change detection finds changes a log review can’t. Second, the parameters are yours. Set the frequency (weekly, for example) and the circumstances, such as after every incident or every emergency change, and write both down.
A tool can tell you what changed. Only your change records can tell you whether it was allowed.
CM-4 happens before the change, CM-4(2) after it
CM-4 asks you to analyze changes “prior to change implementation.” That’s a human review of a proposed change, done before anyone touches the device. A tool can help by giving the reviewer facts about today’s policy, such as what can already reach the affected segment, but the analysis and the decision stay with people.
CM-4(2) is the check afterwards: “After system changes, verify that the impacted controls are implemented correctly, operating as intended, and producing the desired outcome.” Re-running effective access and path simulation after the change shows, from configuration, what the policy now allows. That’s evidence for the first part of the sentence. Whether traffic really behaves that way is a test, not a config read. The Policy Analyzer covers the configuration side.
Deviations, drift, and the control that moved to SI-7
CM-6 ties device settings to a secure configuration standard. It asks you to “Identify, document, and approve any deviations” and to “Monitor and control changes to the configuration settings.” Tracked waivers document the deviations and compliance checks cover the monitoring. The approval is yours.
Plenty of control mappings still cite CM-6(3) for unauthorized change detection. Rev. 5 withdrew it and incorporated it into SI-7, which asks you to “Employ integrity verification tools to detect unauthorized changes to the following software, firmware, and information” and leaves the list to you. The base control never mentions configuration. The link is in the SI-7(7) discussion: “Security-relevant changes include unauthorized changes to established configuration settings or the unauthorized elevation of system privileges.” If you want SI-7 to cover firewall and switch configs, name them in the parameter. Otherwise an assessor can fairly read your SI-7 as software and firmware only.
What a collector can’t do for you
Here’s where SAMURAI fits, and where it stops. It snapshots configuration and state from your firewalls, switches, routers and controllers, diffs every sync against the last one, and attributes each change to an admin (commit-correlated on PAN-OS, time-windowed on FortiOS). It catches changes the audit log missed, runs compliance checks with waivers, and exports the results for the evidence file. That’s evidence for CM-2(2), CM-3 e and f, CM-3(7), CM-4(2) and CM-6 d. It’s not the control.
- It doesn’t approve anything. Approval, the change board and the rest of the CM-3(1) workflow belong to your change system.
- It doesn’t test a change before it ships. CM-3(2) and CM-4 happen before the device changes; SAMURAI sees a change once it’s there.
- It doesn’t roll back. It’s read-only, so the previous version it kept is a reference for a person, not a button.
- It can’t decide that a change was unauthorized. That verdict needs your change records.
- It can miss a change that was made and reverted between two snapshots. A shorter interval narrows the gap, and the device’s own audit log covers the rest.
None of that makes the baseline less important. It makes it the first thing to write down. With an approved baseline and a change log, snapshots turn a CM-3(7) review into an afternoon. Without them, every diff is just a question. The firewall audit checklist covers the rest of what an audit asks, and the firewall audit tool page lists what SAMURAI reads from each vendor.