Hardening isn’t one-and-done — configurations drift and new gaps appear. Scan against a benchmark, automate the baseline, and re-check continuously so security holds.
Why: you cannot trust that a system is hardened without measuring it, so a configuration audit against a benchmark (CIS/STIG) reports exactly which controls pass and which are missing — turning "we hardened it" into evidence. When: scan after hardening and on a schedule; the report is your prioritized to-do list. Where: this closes the loop with the harden-to-a-baseline principle from the first lesson, and mirrors the defender side of a vulnerability assessment.
# Audit a Linux host against hardening best practices:
lynis audit system # produces findings + a hardening index
# Automated CIS/STIG scanning:
oscap xccdf eval --profile cis \
--results scan.xml /usr/share/xml/scap/ssg/content/ssg-ubuntu.xml
# The report is a prioritized to-do list: fix the failed controls first.Why: applying hardening by hand does not scale and drifts over time, so the baseline is codified as configuration-as-code and applied automatically to every system, guaranteeing consistency. When: manage hardening with Ansible/Puppet or golden images so a new server is born hardened. Where: infrastructure-as-code makes hardening repeatable and reviewable — the same discipline as the IaC and MLOps courses, applied to security.
# Codify hardening so every host is configured identically (Ansible example):
# - name: Disable root SSH login
# lineinfile:
# path: /etc/ssh/sshd_config
# regexp: '^PermitRootLogin'
# line: 'PermitRootLogin no'
# notify: restart sshd
# Ready-made hardening roles exist (e.g. CIS/DevSec Ansible baselines).
# New server -> hardened from birth, not hardened later by hand. No drift.Why: even a perfectly hardened system drifts — someone opens a port, disables a control, installs software — so continuous monitoring re-checks compliance and alerts on deviations, keeping security from silently eroding. When: re-scan on a schedule and alert when a system falls out of baseline. Where: this makes hardening a living process rather than a one-time project, and the drift alerts themselves become detection signals.
Hardening is CONTINUOUS, not a one-time project:
[ ] re-scan against the benchmark on a schedule (config drift is constant)
[ ] alert when a host falls out of baseline (a port opened, a control off)
[ ] file-integrity monitoring on critical configs (AIDE / Tripwire)
[ ] re-apply the codified baseline automatically to correct drift
[ ] feed drift + integrity alerts into the SIEM as detection signals
Configurations rot. Continuous validation is what keeps them hardened.