Operating System Hardening Review

We review Windows and Linux builds that have a published baseline we can measure them against, which in practice covers current Windows Server and Windows desktop editions and the mainstream Linux distributions, Ubuntu, RHEL and Debian among them. The constraint is not the operating system itself but whether a CIS Benchmark, a DISA STIG or a Microsoft security baseline exists at a version close enough to yours to be meaningful. Where a host runs something older than the published baselines, or a distribution nobody benchmarks, we still review it: the automated scorecard gives way to a manual pass over authentication, services, logging and file permissions, and the finding is written against NIST SP 800-123 rather than a control identifier. Tell us your operating system inventory on the scoping call, which runs thirty to forty-five minutes, and the written scope will say which builds get a benchmark score and which get the manual treatment.

Both approaches are on the table, and the choice is yours to make during scoping. Agent-based collection runs an assessment binary on the host and reads local security policy, service state, package inventory, account settings and file permissions directly, which gives the fullest picture and is the quickest way to cover a sample. Agentless collection reaches the host over an authenticated session, remote policy export on Windows and an authenticated compliance audit on Linux, and leaves nothing installed behind it, which suits regulated production estates and change-freeze windows. What agentless work tends to miss is depth: permission sweeps across large directory trees and some registry-level settings are slower or partial remotely, so the scorecard carries fewer proven checks. On most engagements we run agents against a representative host from each golden image and collect agentlessly from production, then reconcile both into one evidence set.

A golden image review measures the build at the moment it leaves your pipeline; a fleet review measures what that build became after months of operational change. We do both in one engagement, and the gap between them is the interesting part. Reading the image tells you which weak settings you are manufacturing, and those fixes are cheap because they land once. Reading a sample of live hosts per role tells you how far drift has carried them: services enabled for a support call and never turned off, audit policy loosened during troubleshooting, local administrator passwords reused across machines. Findings are grouped by image rather than by hostname for exactly that reason, so your platform team hardens once instead of chasing hosts individually. If budget forces a choice, start with the image, because a hardened image quietly improves each host rebuilt from it afterwards.

We do not change your configuration. This is a read and advise engagement: we collect evidence, compare it against the baseline, prove the risky settings by hand and hand you a runbook, and your platform team applies the settings on your change process and your schedule. Specifically, we do not edit Group Policy, alter registry or sysctl values, disable services, change password or lockout policy, remove local accounts, reset administrator credentials, or push a configuration role into your estate. We also do not place collection agents outside the sample you approved, and we do not leave collection tooling behind once the evidence pass ends. Where a setting looks risky to change, the finding says so and proposes a staged rollout with a rollback, because a hardening step that breaks a payroll application on a Monday morning costs more than the weakness it closed.

You receive hardening guidance written so it can be transcribed into whatever manages your builds, plus sample automation to start from: Ansible roles for Linux and Group Policy objects for Windows, matching the settings in the findings report. Treat those samples as reference material rather than production content, because they are written against the benchmark, not against your variables, inventory layout or agreed exceptions, and they need review and testing in your pipeline before they touch a host. What makes them usable is the shape of the guidance: a hardening step names the setting, the safe value, the control it satisfies and whether it belongs in the image or in runtime configuration, so translating it into your own roles, desired state configurations or policy baselines is mechanical rather than interpretive. Once your team applies the changes we re-scan the hardened build and reissue the scorecard.