Secure configuration baselines: hardening that survives contact with production

Default configurations are built for compatibility, not security. Hardening replaces those defaults with a deliberate baseline - and the difficulty is never writing the baseline. It is that a fleet drifts away from it continuously, and nothing tells you unless you built something that looks.

Choosing a baseline rather than inventing one

Writing your own baseline from scratch means researching every setting yourself and maintaining it as platforms change. Established options:

• CIS Benchmarks - broad platform coverage, published in two profile levels: Level 1 for general use with low operational impact, Level 2 for high-security environments where some functionality loss is acceptable. Level 1 is the right default for most organisations.
• Vendor security baselines - Microsoft, cloud providers and major software vendors publish their own, which tend to integrate more cleanly with native tooling.
• DISA STIGs - stringent, aimed at defence environments; occasionally required contractually.

Pick one per platform and tailor it. Running two overlapping baselines on the same system produces contradictions nobody resolves.

Tailoring, and the deviation register

Some benchmark settings will break your applications. That is expected, and the answer is not to abandon the baseline or to apply it and let teams silently revert settings. It is a documented deviation register recording, for each setting you do not apply: the setting, why, what compensates, who approved it, and when it will be revisited.

An organisation applying 80% of a benchmark with 20% documented and justified is in far better shape than one claiming 100% and quietly running exceptions nobody wrote down. Auditors respond well to the first and dislike the second intensely.

Applying it: build it in, do not bolt it on

Hardening applied after deployment is hardening that gets skipped when someone is in a hurry. The durable pattern is to move it left:

• Golden images that are already hardened, so every instance starts compliant.
• Infrastructure as code with the baseline expressed in the templates, making the secure configuration the path of least resistance.
• Configuration management that continuously re-applies the desired state, which converts drift into a self-correcting condition.
• Policy enforcement at the platform level - cloud policy engines that refuse non-compliant resources at creation are far more effective than detecting them afterwards.

Drift is the real control

Systems move away from baseline constantly: emergency changes made at 2am, software installs that alter settings, a manual fix for an incident that nobody reverses, and new systems provisioned outside the standard process. None of it is malicious; all of it accumulates.

What a working drift programme needs:

• Scheduled scanning against the baseline - weekly for critical systems, monthly at minimum.
• Coverage measurement. Percentage of systems scanned matters as much as percentage compliant. High compliance across the 60% of the estate you can see is not reassuring.
• Alerting on high-severity drift, not just a monthly report nobody opens.
• Trend reporting. Direction of travel is more informative than an absolute number, and it is what moves this control up a maturity level.
• A route back. Detected drift needs an owner and a remediation path, or the scan output becomes a permanent backlog.

Scope beyond servers

Baselines are usually built for servers and stop there. The gaps that appear in assessments: end-user devices, network equipment, cloud service configuration (storage permissions, identity settings, logging), databases, containers and their base images, and SaaS platform admin settings. The last is increasingly where the real exposure sits - a misconfigured sharing default in a collaboration platform can expose more than an unhardened server.

Key takeaways

• Adopt an established benchmark and tailor it rather than writing your own.
• Document deviations - 80% applied and justified beats 100% claimed.
• Build hardening into images and code so compliance is the default state.
• Measure scan coverage as well as compliance, and trend both.