Infrastructure Hardening
Secure by default — and it stays that way.
A report full of findings changes nothing on its own. Hardening is the work that turns those findings into a baseline your systems are held to — written as code, so it is enforced on every deployment instead of remembered by whoever was there at the time.
The problem
Configuration drifts back.
Someone hardens a server in March. In July an incident needs a quick fix, in September a new engineer copies an old template, and by December the machine is roughly where it started. Nobody did anything wrong; the baseline simply had nowhere to live.
The fix is unglamorous: express the desired state as code, apply it automatically, and make the drift visible when it happens. Then hardening is a property of the system rather than an event in its history.
Enforced, not documented. If the only record of a control is a paragraph in a policy document, it will be true until the first time somebody is in a hurry. We measure hardening by whether a non-compliant change is rejected, not by whether it is discouraged.
Scope
The layers we work through.
From the outside in. Each layer has a defined target state and a way to check it automatically.
- Identity and accessLeast privilege in practice: role design, joiner–mover–leaver, break-glass accounts, and multi-factor where it actually matters.
- Network segmentationReachability reduced to what is needed, verified by testing the paths rather than by reading the rule set.
- Secrets managementCredentials out of repositories and environment files, rotated on a schedule, with an inventory of what exists.
- Patch and update disciplineA cadence that is realistic for your operations, plus a path for the emergency case that does not require heroics.
- Logging and detectionCoverage where it matters, retention that survives an investigation, and alerts a human will still read in month six.
- Backup and restorationTested restores, not just successful backups. The difference is discovered at the worst possible moment.
Sequence
From findings to enforced baseline.
Establish the target
Pick the baseline, adjust it to your reality, and write down every deliberate exception with a reason and an owner.
Codify
Express the target state in infrastructure and configuration code, in your existing toolchain rather than a new one.
Roll out in waves
Non-production first, then production in stages, each with a rollback. Hardening that takes the business down does not survive.
Keep it honest
Continuous checks against the baseline, drift reported as it appears, and a quarterly review of the exception list.
Deliverables
What is on the table at the end.
Baseline as code
In your repository, in your pipeline, reviewable and reversible like any other change.
Compliance check
An automated report of where reality matches the baseline and where it does not, runnable on demand.
Exception register
Every accepted deviation with its reason, its owner and the date it gets looked at again.
Have a report and no plan?
Send us the findings — ours or someone else’s. We will tell you which of them are a configuration change, which are a project, and which are not worth the effort.