Playbook: Hardening Baselines That Survive Change

Hardening is easy to do once and hard to keep. A server built to a good baseline in January has drifted by June: an emergency change, a vendor patch that reset a setting, a new team that copied an old image. This playbook sets out how to define a baseline, enforce it, and detect when reality departs from it.

Start with what NIST means by a baseline

NIST SP 800-128 defines a baseline configuration as a set of specifications for a system, or a configuration item within it, that has been formally reviewed and agreed at a given point in time, and which can be changed only through change control procedures. It is the basis for future builds, releases and changes. The guide’s configuration management plan has four parts: a configuration control board, identification of configuration items, change control, and configuration monitoring. Monitoring means assessing compliance with the baseline and reporting on status.

The NIST CSF 2.0 places this in Protect, Platform Security, as PR.PS-01: configuration management practices are established and applied. Our reading: most organizations have a baseline document and an image. Fewer have the monitoring part, which is what makes a baseline a control.

Playbook

1. Choose the configuration items. List the platforms that matter: server operating systems, container base images, cloud accounts, network devices, endpoints. Rank by exposure and by what they protect. Start with the top three.

2. Write the baseline as testable statements. Each setting needs a value, a reason, an owner and a check. ‘Disable unused services’ is intent. ‘Service X is not running and port Y is closed’ can be tested. Use an established benchmark as the starting point and record every deviation and why.

3. Build once, deploy from the build. The baseline lives in the image, template or code that creates the system. A hardened document that people apply by hand will drift.

4. Put change control on the baseline, not only on systems. When the baseline changes, run a security impact analysis (NIST SP 800-128 gives a template) and roll it to existing systems on a plan.

5. Monitor continuously and report drift. A scan that runs at build time proves little. Compare running systems with the baseline on a schedule and send each deviation to a named owner.

6. Handle exceptions in writing. A deviation needs an owner, a compensating control and an end date.

Typical drift sources

The firewall and network layer

NIST SP 800-41 Revision 1 (2009) recommends that firewall policy start from deny by default: traffic not expressly permitted should be blocked. It also says rulesets should be as specific as possible, managed through a formal change control process, and subject to periodic review or testing. These are baseline statements for network devices and can be tested the same way.

A current example shows why firmware and version matter as part of the baseline. CISA Emergency Directive 25-03 (25 September 2025) addressed a campaign against Cisco ASA devices that used two zero-day vulnerabilities, CVE-2025-20333 and CVE-2025-20362, and manipulated read-only memory so the compromise survived reboot and upgrade. It required US federal agencies to inventory affected devices, apply the first updates by 26 September 2025, and apply later updates within 48 hours of release. The inventory report was due on 2 October 2025. A November 2025 implementation note says some agencies had marked devices patched while still on a vulnerable version. The directive binds federal agencies only. Others may follow the same instructions. The lesson for any baseline is that the recorded version must be the verified version.

Measures that tell you the baseline works

Decision

Decision: if you can only fund one thing, fund the monitoring. A baseline you cannot measure against is a document.

What this evidence does not show

NIST SP 800-128 is guidance from 2011 with updates to 2019, and SP 800-41 Revision 1 is from 2009. Both describe principles that still apply. Neither describes current cloud-native controls in detail. The CISA directive is the agency’s account of one campaign. We did not verify vendor advisories for the named CVEs.

A short test

Pick one platform. Find its written baseline, the system that enforces it, and the last drift report. If any of the three is missing, you have a baseline in name only.

Sources

1. NIST SP 800-128, Guide for Security-Focused Configuration Management of Information Systems, August 2011 (updates as of 10 Oct 2019). Accessed 9 October 2026. nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-128.pdf

2. NIST SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy, September 2009. Accessed 9 October 2026. nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-41r1.pdf

3. NIST Cybersecurity Framework 2.0 (CSWP 29), 26 February 2024. Accessed 9 October 2026. nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf

4. NIST SP 800-55 Vol. 1, Measurement Guide for Information Security, December 2024. Accessed 9 October 2026. nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-55v1.pdf

5. CISA Emergency Directive ED 25-03, Identify and Mitigate Potential Compromise of Cisco Devices, 25 September 2025. Accessed 9 October 2026. cisa.gov/news-events/directives/ed-25-03-identify-and-mitigate-potential-compromise-cisco-devices