Server hardening workbook

What hardening is actually for

Hardening does not stop an intrusion. It reduces what an intruder can do once they are in, and it removes the easy paths that turn a foothold into a compromise. Framed that way, the priorities change: the controls that matter most are the ones limiting lateral movement and privilege escalation, not the ones that make a scanner report look tidy.

The second purpose is consistency. An estate where every server is configured differently cannot be assessed, patched or recovered predictably. A baseline that is merely adequate but universally applied beats an excellent configuration on a third of the fleet.

That is why this workbook is organised around a baseline and its exceptions rather than as a list of settings.

The controls that carry the most weight

• Remove standing administrative access; elevate when needed, log the session
• Disable or remove services and packages that are not required, which shrinks the attack surface permanently
• Enforce authentication that cannot be replayed: keys rather than passwords, no shared accounts
• Restrict outbound traffic, because exfiltration and command traffic both leave rather than arrive
• Log to a destination the host cannot modify, so an intruder cannot erase their own trail
• Patch on a schedule that is measured rather than intended, with an exception process for what cannot be patched

Where hardening programmes fail

Drift. A baseline applied once and never enforced diverges within months. The control that matters is configuration management, not the initial hardening pass, and organisations that do the pass without the enforcement are back where they started by the next audit.

Exceptions with no expiry. Every estate has systems that cannot meet the baseline. That is acceptable if each exception is recorded, owned, justified and given a review date. Exceptions without dates become permanent and invisible.

Logging that goes nowhere useful. A host writing security events to its own disk is providing evidence to whoever compromises it.

Hardening applied to servers and not to the things that administer them. A locked down fleet managed from an unhardened jump host has moved the problem rather than solved it.

Evidence, and how this maps to your obligations

Configuration management appears explicitly in ISO 27001:2022 as one of the newer controls, and it is where many organisations have the thinnest evidence because it was not a control in the 2013 revision.

For CERT-In purposes, the logging decisions here determine whether you can actually meet the 180 day retention requirement against systems that matter. Retention on firewalls and thirty days on servers is a common and expensive shape.

For PCI DSS, hardening standards and the evidence that they are applied and maintained are examined directly, and the exception register is part of that evidence rather than an embarrassment to hide.

Keep the baseline, the exceptions and the enforcement evidence together. Auditors ask for all three and organisations usually have only the first.