PR.PS-01 says configuration management practices are established and applied. Put simply: decide what a secure setup looks like for each kind of system, build every new system from that setup, and catch changes that move away from it.
CSF is voluntary guidance. There is no CSF certification, and no one can call you "NIST compliant".
What good looks like
Every server image, container base, laptop build, and cloud account has a documented baseline. The baseline turns off what is not needed, which NIST calls the principle of least functionality. Defaults that affect security are reviewed when software is installed or upgraded. Deviations are detected and either approved or corrected.
How to implement it
- Choose the baseline per asset type. Start with a public hardening guide for your operating system or cloud, then trim it to what you actually run.
- Express the baseline as code: infrastructure templates, image build scripts, or device management profiles. Store them in version control.
- Build new systems only from those templates. Block manual console changes in production where you can, and log them where you cannot.
- Review default settings during each install or major upgrade. Note the decisions in the ticket.
- Run a drift check on a schedule. Compare live settings to the template and open a ticket for every difference.
- Test baseline changes in staging first, then roll them out in stages.
A worked example
A 40 person company runs about thirty servers and a few hundred laptops. Servers were built by hand over several years, so each one differs slightly. The team picks one operating system image, hardens it using a public benchmark, and encodes it in an image build script. New servers come only from that image. A nightly job compares running servers to the image and reports differences. In the first month it finds eleven servers with an old remote access service still enabled. They are fixed or replaced, and the count of drifted servers becomes a metric the team watches.
For laptops, the same idea uses a device management profile: disk encryption on, screen lock timer set, firewall on, only approved apps installable. The report shows the percentage of devices matching the profile.
Baselines for cloud and application settings
Configuration management is not only about operating systems. Cloud accounts have baselines too: public storage blocked by default, logging enabled, multi factor authentication required for administrators, and unused regions disabled. Application platforms, databases, and SaaS tools each have settings that affect security. Pick the ten that matter most for each, write them down, and check them regularly.
Keeping drift under control
Drift happens because people fix problems at two in the morning. Accept that, and make it visible. Allow emergency manual changes but require a ticket afterward, and let the drift report remind everyone. If the same setting drifts repeatedly, the baseline is probably wrong or the process is too slow, and that is worth fixing.
Tools that help
You do not need a large budget. Device management platforms cover laptop and phone baselines. Infrastructure as code tools cover cloud and server settings. Cloud providers offer configuration checkers that flag public storage, open ports, and missing encryption. Open source benchmark scanners can test servers against published hardening guides. Choose one tool per asset class and make its report part of a monthly review.
Handling exceptions
Some systems cannot meet the baseline because of legacy software or vendor limits. Record each exception with the reason, the compensating control, the owner, and a review date. An exception without an expiry date is a permanent gap in disguise. Review all of them each quarter and close the ones that no longer apply.
Rolling out a baseline change
When you tighten a setting, test it on a small group first, such as the IT team or a staging environment. Watch for broken workflows for a week. Then expand in rings: ten percent, half, everyone. Keep notes on what broke so the next change is smoother, and tell users in advance when a change affects them.
Customer conversation
When a customer asks how you keep systems securely configured, the strongest answer is a short story with artifacts: the baseline, the build template, the drift report, and the count of exceptions. That beats a policy statement every time.
Evidence to collect
- The baseline documents or code, with commit history.
- A list of systems and which baseline each follows.
- Drift reports and the tickets that resolved them.
- Change approvals for exceptions.
Common gaps
Baselines that exist as a wiki page nobody follows. Hand built servers that were never replaced. No drift detection, so the baseline erodes silently. Exceptions with no owner and no expiry date.
Quick check
Is a hardening guide from a vendor enough?
It is a start. The outcome expects an established baseline you apply and monitor. Adapt the guide to your systems, apply it through code or device management, and check for drift.
What does least functionality mean here?
Only the services, ports, accounts, and features needed for the system's job stay enabled.
Sources
- NIST Cybersecurity Framework 2.0 (NIST CSWP 29), PR.PS-01 and its implementation examples.
