Hardening

Hardening is the practice of strengthening a system or a network by configuring them to expose and permit as little as possible. The aim is to reduce the attack surface: disable the services that are not used, remove the exploitable default configurations, and leave only the permissions that are needed. It applies not only to the operating system but to applications, network devices and any component that runs third-party code.

In practice it runs on four fronts. Secure configuration of systems, applications and network equipment. Updates and patches kept current, which is a separate and complementary job, that of patch management. Account and access management, with strong passwords, unnecessary accounts removed and least privilege. And monitoring and logging of activity, because a hardened system that leaves no trace cannot be audited afterwards.

Software ships configured to work everywhere for everyone. That means services enabled that most installations never use, legacy protocols left on for compatibility, permissions granted broadly so nothing breaks during setup, and verbose defaults that help an administrator and help an attacker equally. Hardening is the process of subtracting from that.

It works on four layers, and they are usually owned by different people, which is why it drifts. Remove what is not needed: roles, packages, sample content, unused network services. Close the defaults: default credentials, anonymous access, permissive shares, legacy authentication protocols, enabled-but-unused management interfaces. Restrict what remains: bind services to the interface they belong on, run them as accounts with the rights they need, require encryption. And prove the state: apply the configuration from a baseline that is enforced continuously rather than typed once.

The baselines themselves are published rather than invented. CIS Benchmarks cover most common operating systems, databases and cloud services with a rationale per item. In the Spanish public sector the CCN-STIC guides are the reference and are not optional: an ENS audit expects to see the relevant guide applied, or a documented reason it was not. Vendors publish their own security baselines for their platforms. Choosing which set you follow is a decision to make once and record.

The reason hardening matters more than its unglamorous reputation suggests is timing. Patching fixes a known flaw after it is known. Hardening decides what an attacker can do on the day a flaw is not yet known, and it decides what they can reach after a phishing email works. Those are the two situations where everything else has already failed.

Hardening is applied at build and then nothing enforces it. Six months of changes later, a service was re-enabled to make an integration work, a permission was widened during an incident and never narrowed, an exception was granted for a supplier’s agent. The build was hardened; the estate is not. On engagements the difference between the gold image and the live host is where we work.

The gold image itself is the second problem. It is cloned, and everything in it is cloned with it: the local administrator password, the agent that was installed with an embedded credential, the certificate, the scheduled task pointing at a share. One image compromised once is every host built from it.

The third is the exception that becomes permanent. Legacy authentication is the clearest case. It is disabled as part of a baseline, one department’s device cannot cope, an exception is written for that department, and two years later the exception is estate-wide because nobody re-tested it. That exception is the reason multi-factor authentication can be bypassed on a tenant that believes it is enforced everywhere, and it is one of the first things we look for.

The fourth is what a hardened host still trusts. We reach a workstation configured exactly to the benchmark, and it holds a cached credential, a mapped drive to a share with broad permissions, and a management agent that can be instructed from a server we can reach. Hardening the host did not change what the host was allowed to talk to, and lateral movement does not need a misconfigured host when a correctly configured one has the same access.

Organisations argue about this and the argument is usually about obligation rather than technical merit. The three overlap heavily on the substance.

The practical guidance: if you are in scope for the ENS, start from the CCN-STIC guide for the category, because that is what the auditor will ask for. Otherwise start from CIS for the operating system and the vendor’s own baseline for the vendor’s own platform, since the vendor knows which settings break their product. What matters far more than the choice is that one is chosen, applied by policy, and measured continuously.

Applying a benchmark wholesale in production. Some items break real workloads. Test, decide per item, and record the decision with an owner. A benchmark applied blindly and then rolled back leaves you with neither the setting nor the record.

Hardening the operating system and ignoring the identity layer. A perfectly configured server whose local administrator group contains a domain group with two hundred members is not hardened in any way that changes an attacker’s day.

Treating it as a project. Configuration drifts continuously, so the control is continuous measurement, not an exercise with a completion date.

Confusing it with patch management. They solve different halves. Patching removes known flaws; hardening reduces what any flaw reaches. An estate that only patches is fully exposed on the day a new flaw appears.

Leaving the same local administrator password on every host. It is the single fastest route across an estate and it converts one compromised workstation into all of them.

Move the configuration into code and apply it continuously. A configuration management tool, a cloud policy engine or a group policy that reapplies on a schedule turns drift into a measurement rather than a discovery. What matters is not that a setting was made, but that it is remade every time something changes it.

Then measure against the baseline and report the exceptions, not the compliance percentage. A percentage hides the two hosts that matter. The list of exceptions with an owner and a date is the artefact worth reviewing.

Randomise local administrator passwords per host so the credential recovered on one machine is worth nothing on the next. Disable legacy authentication protocols centrally and audit for the exceptions monthly. Bind management interfaces to a management network. And re-run the measurement after every platform upgrade, because upgrades reintroduce defaults.

Hardening pairs directly with attack surface reduction: one removes what is reachable from outside, the other removes what is usable once inside.

Configuration review is part of most internal and cloud engagements, and the finding is written against the setting and the host group, with the benchmark item referenced where one exists, so the client can act without a translation step. We record the observed value, the expected value, and what the gap allowed us to do, because the last part decides the priority.

Severity is not the benchmark’s severity. It is what the misconfiguration gave us in this estate. The same permissive share is an observation on an isolated test host and a critical finding when it holds a script with a service account password in it. A configuration finding with no demonstrated consequence is written as one, honestly, rather than inflated.

Baseline work on collaboration platforms and identity tenants is the subject of a dedicated review of Microsoft 365 configuration, where the default settings are permissive by design and the gap between default and hardened is unusually large.

What is the difference between hardening and patching? Patching removes specific known flaws. Hardening reduces what any flaw, known or not, can reach and reuse. You need both, and hardening is what carries you through the window between a flaw existing and a patch being applied.

Which hardening baseline should we use? Whichever one your obligations point at, applied consistently. CCN-STIC where the ENS applies, CIS Benchmarks for broad coverage, the vendor’s baseline for the vendor’s own platform. Consistency and continuous measurement matter more than the choice between them.

Does hardening break things? Some items do, which is why they are applied by testing rather than by decree. The honest process is to apply the baseline in a test environment, record the exceptions you need with a reason and an owner, and revisit them, rather than to abandon the baseline after the first outage.

Is bastionado the same as hardening? Yes. It is the standard Spanish term for the same work, and it is used in the CCN-STIC guides and in ENS documentation.