Hardening Servers Shouldn't Need a Compliance Team: Building SysHardn.

The CIS Benchmarks for Linux and Windows run to hundreds of pages, a long list of settings you are meant to check and lock down, and there is no easy way to actually verify any of it on a machine you run. So most teams skip hardening, write a few scripts that rot within a couple of months or pay for a commercial tool to do it for them.

A few open source tools do exist, but each leaves a gap. Lynis audits thoroughly but only reports what’s wrong, OpenSCAP can remediate and generate fix scripts, but it's built around SCAP and XML, and once a change is applied there's no built in way to rollback. Ansible hardening roles work well if you already run Ansible, and they rarely make a change reversible either. SysHardn is built to address that gap. It's a cross-platform CLI that reads hardening rules from plain YAML and runs them on Windows or Linux, telling you exactly what's compliant and what isn't. Checking compliance turned out to be the simpler problem. The harder part was making remediation safe, every fix needed to be backed up and reversible, since a hardening tool that can lock you out of your own server defeats its own purpose.

The talk gets into the parts that actually took work. How one YAML rule becomes both a check and a remediation. How the same rule format handles a numeric check like password history from net accounts on Windows and a string setting like PermitRootLogin in sshd_config on Linux, without the author writing anything OS specific. Because the rules are just files, you can keep them in version control, review a change in a pull request, and write your own to cover a distro or benchmark we don't ship yet. These rules run as root or admin, so we will talk about where they come from and why you should read one before you run it. Along the way we will show the tool live in action.

SysHardn runs on Windows and Linux today and ships as a single self-contained binary you can download and try. We will close with a candid look at its current limits, and what we are working towards next.

1. How a CIS control becomes runnable code: a check, an expected value for each strictness level, and a remediation. Compliance stops being a PDF you tick off by hand and becomes something you can version, diff, and re-run.
2. Why remediation is harder than auditing, and why an apply with no tested rollback is how hardening tools lock people out.
3. A practical model for changing live systems safely: read-only by default, privileged applies, a verify step, and backups you can restore from.
4. Enough of the YAML rule format to write and version control your own checks and fixes.