Hardening is the practice of reducing what a system can do to the set of things it needs to do. Configuration management is the practice of keeping it that way. The first is a project and is routinely completed. The second is an operating discipline and is routinely not, which is why so many environments were secure at build time and are not now.
This article covers where baselines come from, what hardening actually involves across the estate, how drift occurs, and what a working detection and correction loop looks like.
Why configuration is a security control at all
A large share of real incidents involve no software vulnerability. An exposed management interface, a default credential never changed, an overly permissive storage container, a legacy protocol still enabled, a debug feature left on after a deployment. None of those requires an exploit. They require somebody to find them.
Configuration is therefore not a hygiene matter adjacent to security. It is a primary control surface, and in cloud environments it is arguably the primary one.
Where baselines come from
A baseline is the documented target state for a class of system. Writing one from scratch is unnecessary because several credible starting points exist, and the work is in the adaptation rather than the authorship.
Published benchmarks give a defensible starting position. The CIS Critical Security Controls give the surrounding programmatic structure, including the secure configuration expectations that sit behind them, and are discussed in the CIS Critical Security Controls. For organizations working to a federal control catalog, NIST SP 800-53 supplies configuration management controls within a set where the controls are flexible and customizable and implemented as part of an organization-wide process to manage risk.
The adaptation is the real work. A benchmark written for a general population will break specific applications, and an organization that applies one wholesale without testing will spend the following week reverting it and will conclude that hardening is disruptive. Each deviation from the benchmark should be recorded with its reason, which produces the organization's own baseline rather than an aspiration.
What hardening covers
The surface is wider than most baselines address.
- Operating systems and servers. Unnecessary services and roles removed, local accounts controlled, logging enabled beyond defaults, secure protocol versions enforced, administrative access restricted by source.
- Cloud environments. Identity and permission boundaries, network rules, storage exposure, encryption settings, control plane logging and the guardrails that prevent a resource being created outside policy. Covered further in cloud security.
- Network devices. Management plane separated from data plane, default credentials removed, unused ports and protocols disabled, configuration backed up and diffed. See network security.
- Applications. Debug and verbose error handling disabled in production, default accounts removed, session and authentication settings, administrative interfaces restricted.
- Databases. Authentication, network exposure, encryption at rest and in transit, privilege separation between application and administrative accounts, and auditing of privileged operations.
- Administrative interfaces. Treated as a category of their own, because they are the highest value target on any system and are the thing most often left reachable from more places than intended.
Drift, and why it is inevitable
Drift is the divergence between the baseline and reality. It is not a sign of an undisciplined team. It is what happens when systems are operated.
The common causes are ordinary. A change made during an incident to restore service and never reverted. A vendor requirement that a port be opened for support. A new host built from an older template. A container rebuilt from a stale base image. A cloud resource created by a team that did not know the standard existed. An application upgrade that resets a configuration file.
Because drift is inevitable, a program that depends on it not happening will fail. What works is assuming it and building the loop that finds it.
The detection and correction loop
Four components, and the gap is usually the last one.
A stated baseline that exists as a machine readable definition rather than a document, because a baseline nobody can evaluate against is an aspiration.
Regular evaluation of the running estate against it, ideally continuous, producing a list of deviations with the system and the setting.
Triage of those deviations, because some are drift to be corrected and others are legitimate local requirements that should be added to the baseline as recorded exceptions. Treating every deviation as a fault trains people to ignore the report.
Correction, applied and verified. This is the component most often missing. Organizations frequently evaluate diligently and produce a deviation report each month that grows.
Immutable infrastructure changes the problem
Where infrastructure is rebuilt from definitions rather than modified in place, drift behaves differently. A system rebuilt from a hardened image each deployment cannot drift far, because it does not live long enough.
The control surface moves accordingly: it becomes the image, the definition and the pipeline that applies them. That is a genuine improvement, and it introduces its own failure, which is a hardened definition and a stale base image nobody updates. The baseline discipline does not disappear; it relocates.
Change management, without the ceremony
Configuration management and change management are adjacent, and the security value of change control is often overstated. A heavyweight approval process does not prevent drift. It records it.
What actually helps is narrower: privileged configuration changes are logged where somebody will see them, production changes are traceable to a person and a reason, and emergency changes carry a mandatory review afterwards so that the temporary fix is either reverted or adopted deliberately. The audit trail matters more than the approval queue.
Who owns the baseline
A baseline with no owner decays into a document. Ownership has to be explicit, and it is usually split: the security function owns what the target state should be, and the platform or infrastructure team owns applying and maintaining it.
That split works when the two agree a route for exceptions. It fails when security publishes a standard over the wall and infrastructure discovers it during an audit, or when infrastructure adopts a vendor default and security learns about it after an incident. The practical fix is unglamorous: the baseline is reviewed jointly on a schedule, and every exception carries both an operational reason and a security acceptance.
The legacy system that cannot be hardened
Every estate has one. An application that requires an outdated protocol, a server that cannot be patched without breaking a dependency, an appliance whose vendor withdrew support.
The wrong responses are equally common: pretend it is compliant, or refuse to accept it and leave the argument unresolved while the system keeps running. The workable response is to treat it as a recorded exception with compensating controls, usually network isolation, tighter monitoring and restricted administrative access, and to attach a date at which the underlying problem is revisited.
That converts an indefensible finding into a managed risk with an owner. It also makes the replacement business case concrete, because the compensating controls have a cost that can be compared against the cost of removing the system.
Evidence, and what an auditor will ask
Hardening is one of the easiest areas to evidence well and one of the most commonly evidenced badly. A screenshot of a compliant setting on one server proves that one server, on that day.
What holds up is the baseline document with its recorded deviations, a dated evaluation across the estate showing the compliance rate, the deviation register with owners and dates, and evidence that corrections were applied and verified. That set answers the question an assessor is actually asking, which is whether the control operates rather than whether it exists. The wider practice is covered in continuous security and compliance monitoring.
Where this sits in the service
Hardening is a project. Configuration management is a subscription, and the distinction is the same one that runs through the managed cybersecurity lifecycle. Most organizations can harden an estate once. Keeping it hardened through two years of ordinary change is the part that needs an owner.
LABUSA operates baselines, drift detection and correction within managed cybersecurity services. The configuration findings it produces feed the same remediation queue as the software findings described in vulnerability management, because to an attacker the distinction between a missing patch and a permissive setting is academic.
Sources
- NIST, Security and Privacy Controls for Information Systems and Organizations, SP 800-53 Rev. 5.
- Center for Internet Security, The 18 CIS Critical Security Controls.
- NIST, Guide to Enterprise Patch Management Planning, SP 800-40 Rev. 4.