HCR: Host Configuration Review
What HCR looks for
The rule set at launch ship with the CIS Benchmarks for the platforms below. Each
rule maps to a specific control with a stable identifier (e.g. CIS-5.2.4 for SSH protocol
must be 2).
| Platform | Coverage |
|---|---|
| RHEL / CentOS / Rocky | CIS RHEL Benchmark |
| Ubuntu | Subset of CIS Ubuntu Benchmark |
| SUSE | CIS SLES Benchmark |
| Windows Server | CIS Windows Benchmark |
| Docker hosts | CIS Docker Benchmark |
| Kubernetes nodes | CIS Kubernetes Benchmark (node-level controls) |
How HCR scans without an agent
The trick is snapshot scanning. Ctadel takes a read-only snapshot of your VM's root disk via the cloud's snapshot API (EBS, Compute Persistent Disk, Scaleway Block Storage, Azure Managed Disk). The snapshot is mounted offline in our scanning worker and the filesystem is walked.
For every rule we read the relevant config files: /etc/ssh/sshd_config,
/etc/audit/auditd.conf, /etc/docker/daemon.json, /etc/systemd/system/kubelet.service.d/,
and so on. The result is a finding with the actual value, the expected value, and
the file path the rule looked at.
| Pros | Cons |
|---|---|
| No agent to deploy, coverage from day 1 | Slower to refresh |
| Cannot be tampered with by a compromised host | Cannot detect runtime behaviour (use CDR for that) |
| Doesn't consume host CPU | Requires snapshot permission in the cloud IAM |
What ends up in an HCR finding
| Field | Example |
|---|---|
| Rule key | CIS-5.2.4 |
| Host ID, name, type | host-prod-api-01, prod-api-01, linux |
| Actual value | Protocol 1,2 |
| Expected value | Protocol 2 |
| File path | /etc/ssh/sshd_config |
| Severity | Driven by the CIS scoring level |
Remediation tabs show the equivalent change in: bash one-liner, Ansible task, Terraform user_data block (when applicable).
What's next
- The HCR module
- Vulnerability management, sibling detector for CVEs in installed packages
- Agentless vs agent-based, why we chose this approach