> For the complete documentation index, see [llms.txt](https://docs.linuxguard.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.linuxguard.io/audit-and-comply/audit-comply/cis-benchmarks.md). # CIS Benchmarks (Linux) > **Note**: This page maps LinuxGuard against the **CIS Benchmarks for Linux distributions** (per-distro versioning — see the version table below). Last verified against the published Benchmarks on 2026-05-31. Canonical framework documents: [CIS Benchmarks — Linux/Unix Operating Systems](https://www.cisecurity.org/cis-benchmarks#linux-unix). For the vocabulary contract used here, see [Audit & Comply](/audit-and-comply/audit-comply.md). > **Important — Not the same as CIS Controls**: CIS Benchmarks are OS-specific *configuration hardening guides* — distro-by-distro prescriptive settings for `/etc/sshd_config`, kernel sysctls, package selection, filesystem permissions, audit daemon rules, and similar host-level configuration. CIS Controls v8.1 are 18 *strategic* security control families addressing organizational program scope (e.g., "Audit Log Management"). The two are produced by the same organization (Center for Internet Security) for related but distinct purposes: Benchmarks for system administrators tuning a single host; Controls for security program owners defining what the organization should do. See [CIS Controls](/audit-and-comply/audit-comply/cis-controls.md) for the strategic mapping that complements this host-level Benchmark mapping. ## Scope This page maps LinuxGuard's agent and console capabilities against the CIS Benchmarks for Linux distributions in scope of LinuxGuard's per-distro support (Debian/Ubuntu, RHEL/CentOS, SUSE/openSUSE, Alpine Linux). The mapping is scoped to Benchmark recommendations that LinuxGuard's baseline detection surface — SSH server configuration, SSH client configuration, account inventory, group inventory, SUDO aliases, SUDO defaults, SUDO rules — observes and reports drift against. Benchmark recommendations covering filesystem mount options, kernel sysctl parameter values, package selection, auditd rule sets, AppArmor / SELinux profile content, firewall rule sets, systemd unit configuration, and per-service hardening (Apache, nginx, PostgreSQL, etc.) are out of scope for this product and are listed in the mapping table as `Out of scope` rather than omitted. This mapping is informational and not a substitute for an independent audit by a qualified assessor. Customers remain responsible for selecting the appropriate Benchmark profile (Level 1 vs Level 2; Server vs Workstation) for their deployment scenario, applying the Benchmark recommendations through configuration management (Ansible, Chef, Puppet, kickstart, cloud-init), and engaging in the per-distro hardening workflow that produces the configured state LinuxGuard's baseline detection observes. ## Shared responsibility > LinuxGuard is a security monitoring agent and console. Compliance with any framework requires customer-side controls in addition to LinuxGuard's capabilities. This mapping is informational and not a substitute for an independent audit by a qualified assessor. The shared-responsibility framing for CIS Benchmarks Linux: * **LinuxGuard responsibility.** Detect drift from the customer's baseline configuration of SSH server, SSH client, accounts, groups, SUDO aliases, SUDO defaults, and SUDO rules. The agent compares the current OS-layer configuration state against the customer-defined baseline on each scan cycle and surfaces deviations as Config Drift events. Maintain the framework version pin and per-recommendation evidence pointers. * **Customer responsibility.** Select the applicable Benchmark profile (Level 1 baseline vs Level 2 defense-in-depth; Server vs Workstation), apply the Benchmark recommendations to the host via configuration management or per-distro hardening workflow, define the baseline content in LinuxGuard reflecting the Benchmark-aligned state, and address Benchmark recommendations outside LinuxGuard's baseline surface (filesystem mount options, kernel sysctls, package selection, auditd, AppArmor/SELinux, firewall, systemd, per-service hardening). * **Out-of-scope domains for this framework.** Filesystem mount options, kernel sysctl parameter values, package selection and removal, auditd rule sets, AppArmor / SELinux profile content, firewall rule sets, systemd unit configuration, per-service hardening (Apache, nginx, PostgreSQL, etc.), and the Benchmark application workflow itself (LinuxGuard does not apply hardening — it observes the configured state). ## Per-distro Benchmark version pins The customer's audit period typically pins a specific Benchmark version per in-scope distribution. The table below lists the LinuxGuard-supported distributions, the corresponding CIS Benchmark family, and the load-bearing version-pinning consideration for each. | Distribution family | LinuxGuard support scope | CIS Benchmark name | Version-pinning notes | | ------------------- | --------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Debian / Ubuntu | Debian 12, Ubuntu 22.04 LTS, Ubuntu 24.04 LTS | CIS Debian Linux 12 Benchmark; CIS Ubuntu Linux 22.04 LTS Benchmark; CIS Ubuntu Linux 24.04 LTS Benchmark | Each distro release has its own Benchmark family with independent versioning. Pin the specific Benchmark version (e.g., "CIS Debian Linux 12 Benchmark v1.0.0") at the start of the audit period. | | RedHat / CentOS | RHEL 9, CentOS Stream 9, Rocky Linux 9, AlmaLinux 9 | CIS Red Hat Enterprise Linux 9 Benchmark | The RHEL 9 Benchmark also applies to the RHEL-compatible derivatives (Rocky, Alma, Oracle Linux 9). Pin a single version per audit period. | | SUSE / openSUSE | SUSE Linux Enterprise Server 15, openSUSE Leap 15 | CIS SUSE Linux Enterprise 15 Benchmark | SLES 15 service pack (SP4, SP5, SP6) may affect specific recommendations — verify the Benchmark version covers the customer's SP. | | Alpine Linux | Alpine 3.18, 3.19, 3.20 | CIS Alpine Linux 3 Benchmark | Alpine's musl libc and OpenRC init differ from glibc / systemd-based distros — many Linux-generic recommendations require Alpine-specific adaptation. Verify the Benchmark covers the customer's Alpine minor version. | > **Important — Pin vs floating**: CIS publishes updated Benchmark versions on a per-distro cadence (typically annually or per distro major release). Customers running long audit periods should pin a specific Benchmark version at the start of the period and assess against that version throughout, rather than tracking "latest" — a Benchmark version bump mid-period changes the recommendation set and breaks the audit-period continuity. Document the pinned version in the customer's audit narrative and the LinuxGuard baseline configuration metadata. ## Control mapping The Tier column uses one of three labels and only those three: `Satisfies`, `Supports`, `Out of scope`. The Evidence column points to a row of the canonical [Evidence Location](/concepts/concepts/console/compliance-expansion.md#evidence-location) table or to a specific console page. See [Audit & Comply](/audit-and-comply/audit-comply.md) for the three-tier vocabulary contract. The Recommendation ID column references the recommendation category common across the per-distro Benchmarks; per-distro recommendation numbering varies. | Recommendation category | Description | Tier | Evidence | Notes | | ------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------- | -------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | SSH server (sshd) configuration | Ensure `sshd_config` hardening — `PermitRootLogin no`, `PasswordAuthentication no`, `Protocol 2`, `MaxAuthTries`, `ClientAliveInterval`, `LoginGraceTime`, `Banner`, ciphers and MACs allowlist, key exchange algorithm allowlist, `AllowUsers` / `AllowGroups` | `Satisfies` | Console Baselines → SSHD config; Console Zero Trust Enforcement → Config Drift | The SSHD config baseline captures `/etc/ssh/sshd_config` and `/etc/ssh/sshd_config.d/*` contents; drift detection surfaces any change to the file (including reversions of hardening). See [Baselines § SSHD config](/concepts/concepts/console/baselines.md#sshd-config). | | SSH client (ssh) configuration | Ensure `/etc/ssh/ssh_config` hardening — outbound cipher choices, `StrictHostKeyChecking`, `ForwardAgent`, `IdentityFile` preferences | `Satisfies` | Console Baselines → SSH config; Console Zero Trust Enforcement → Config Drift | The SSH config baseline captures `/etc/ssh/ssh_config` and `/etc/ssh/ssh_config.d/*` contents; drift detection surfaces deviations including package-upgrade-induced changes. See [Baselines § SSH config](/concepts/concepts/console/baselines.md#ssh-config). | | Account inventory and lifecycle | Ensure local user accounts match the expected inventory; ensure no unauthorized accounts; ensure UID consistency where required; ensure account removal on employee departure | `Satisfies` | Console Baselines → accounts; Console Zero Trust Enforcement → Config Drift | The accounts baseline records the expected user accounts (optionally with UID, primary GID, home directory, login shell); drift detection surfaces unexpected creation, deletion, or modification. See [Baselines § Accounts](/concepts/concepts/console/baselines.md#accounts). | | Group inventory and membership | Ensure groups match the expected inventory; ensure sensitive group membership (wheel, sudo, docker, adm) is restricted | `Satisfies` | Console Baselines → groups; Console Zero Trust Enforcement → Config Drift | The groups baseline records expected group memberships with sensitive groups receiving stricter scrutiny in drift attribution. See [Baselines § Groups](/concepts/concepts/console/baselines.md#groups). | | SUDO aliases | Ensure `Host_Alias`, `User_Alias`, `Runas_Alias`, `Cmnd_Alias` definitions in `/etc/sudoers` and `/etc/sudoers.d/*` match the expected set | `Satisfies` | Console Baselines → SUDO aliases; Console Zero Trust Enforcement → Config Drift | The SUDO aliases baseline catches aliases gaining unexpected entries (a `Cmnd_Alias DEPLOY` gaining `/bin/bash`) that expand the reach of rules referencing the alias. See [Baselines § SUDO aliases](/concepts/concepts/console/baselines.md#sudo-aliases). | | SUDO defaults | Ensure `Defaults` lines in sudoers configuration match the expected set — `timestamp_timeout`, `passwd_tries`, `env_reset`, `secure_path`, `requiretty`, `logfile` | `Satisfies` | Console Baselines → SUDO defaults; Console Zero Trust Enforcement → Config Drift | The SUDO defaults baseline catches changes that weaken audit posture (a `logfile` removal) or relax authentication friction (`timestamp_timeout` extension). See [Baselines § SUDO defaults](/concepts/concepts/console/baselines.md#sudo-defaults). | | SUDO rules | Ensure user / group / runas / command rule lines in sudoers match the approved rule set | `Satisfies` | Console Baselines → SUDO rules; Console Zero Trust Enforcement → Config Drift | The SUDO rules baseline catches rule additions, modifications, and removals — the core surface of who-can-do-what under privilege escalation. See [Baselines § SUDO rules](/concepts/concepts/console/baselines.md#sudo-rules). | | Filesystem configuration | Ensure separate filesystems for `/tmp`, `/var`, `/var/log`, `/var/log/audit`, `/home`; ensure mount options (nodev, nosuid, noexec) on temporary and removable media | `Out of scope` | n/a | Filesystem mount configuration is not addressed by LinuxGuard. | | Kernel sysctl parameters | Ensure kernel parameter hardening — `net.ipv4.tcp_syncookies=1`, `kernel.randomize_va_space=2`, `fs.suid_dumpable=0`, IPv6 redirect / source-routing disabling | `Out of scope` | n/a | Kernel sysctl parameter values are not addressed by LinuxGuard. | | Package management | Ensure unauthorized packages removed (telnet, rsh, talk, ypbind, tftp); ensure mail and DNS clients restricted; ensure package signature verification enabled | `Out of scope` | n/a | Package selection and removal are not addressed by LinuxGuard. | | Audit daemon (auditd) rules | Ensure `auditd` running, audit log retention, audit rule set covering account changes, system administration, file access, login events | `Supports` | Agent log (raw events); Console Compliance Expansion → History | LinuxGuard's own audit log surface (eBPF-based authentication and file integrity events) provides additional audit coverage independent of auditd. Customer responsible for auditd configuration, rule set, and audit log retention. | | AppArmor / SELinux | Ensure mandatory access control enabled and enforcing; ensure profile / policy set covers in-scope services | `Out of scope` | n/a | MAC enforcement is not addressed by LinuxGuard. The console's [Zero Trust Expansion → SELinux status](/concepts/concepts/console/zero-trust-expansion.md) surface reports SELinux mode but does not enforce. | | Firewall configuration | Ensure firewall enabled (iptables, nftables, firewalld, ufw); ensure default-deny inbound; ensure rule set covers in-scope services | `Out of scope` | n/a | Firewall rule sets are not addressed by LinuxGuard. | | systemd unit hardening | Ensure systemd unit `RestrictNamespaces`, `NoNewPrivileges`, `ProtectSystem`, `ProtectHome`, `PrivateTmp` directives configured per service | `Out of scope` | n/a | systemd unit configuration is not addressed by LinuxGuard. | | Per-service hardening | Ensure Apache, nginx, PostgreSQL, MySQL/MariaDB, Bind, NTP, time daemons hardened per service-specific Benchmark sections | `Out of scope` | n/a | Per-service application hardening is not addressed by LinuxGuard. | > **Important**: Every Satisfies claim cites a specific agent feature and a specific evidence pointer. Every Supports claim states what the customer must implement to achieve full satisfaction. Every Out-of-scope row carries a one-line note explaining why — silence is interpreted as an implicit Satisfies claim. ## LinuxGuard relationship to CIS Benchmarks LinuxGuard's relationship to CIS Benchmarks is observation, not enforcement. The agent does not apply Benchmark recommendations to the host — applying recommendations is the customer's responsibility, handled through configuration management or a one-time hardening campaign. The agent observes the configured state and, given a customer-defined baseline reflecting the Benchmark-aligned state, surfaces drift when the host's configuration moves away from the baseline. The practical workflow: 1. **Customer applies the CIS Benchmark** to the host through Ansible, Chef, Puppet, kickstart, cloud-init, or a manual hardening pass. The host reaches a Benchmark-aligned configured state. 2. **Customer defines the LinuxGuard baseline** reflecting the Benchmark-aligned state — for SSHD config, the baseline captures the hardened `/etc/ssh/sshd_config` contents; for SUDO rules, the baseline captures the approved rule set; and so on. 3. **LinuxGuard's baseline scan cycle** compares the current OS-layer configuration against the baseline on each run. The scan cadence is configurable; defaults are documented in [Baselines § Baseline settings](/concepts/concepts/console/baselines.md#baseline-settings). 4. **Drift events surface in Zero Trust Enforcement → Config Drift** when the host's configuration deviates from the baseline. Drift attribution identifies the change source where the agent can determine it. The Baselines pillar in the console is the canonical surface for this workflow — see [Baselines](/concepts/concepts/console/baselines.md) for the per-category capabilities. The baseline content itself (the configured state the customer declares as "expected") encodes the Benchmark recommendation; LinuxGuard does not ship pre-built CIS-Benchmark-aligned baseline templates. ### What LinuxGuard does not do The boundary is sharp at a few points worth naming explicitly: * **No Benchmark-as-a-service hardening engine.** LinuxGuard does not apply CIS Benchmark recommendations to hosts. Customers run their own hardening workflow. * **No Benchmark recommendation-to-baseline auto-translation.** The customer manually translates the Benchmark recommendation set into the baseline content (e.g., reading `5.2.x SSH Server Configuration` recommendations and reflecting them in the SSHD config baseline). There is no automated import of a CIS Benchmark profile into a LinuxGuard baseline. * **No coverage of Out-of-scope recommendation categories.** Filesystem mount options, kernel sysctls, package selection, auditd rules, AppArmor/SELinux profiles, firewall rule sets, systemd unit hardening, and per-service hardening are observed neither at the baseline layer nor at the drift layer. * **No remediation action on drift.** Drift detection surfaces deviations but does not revert them. The customer's incident response and configuration management workflows determine remediation. The boundary is the source of the "Satisfies" rating on the seven baseline categories above and the "Out of scope" rating on everything else — the Benchmark's coverage is broader than the baseline pillar's coverage, and the page names which subset overlaps. ## Profile selection CIS Benchmarks ship in profile variants per distro. The customer selects the profile matching the deployment scenario before applying recommendations. * **Level 1 — Server profile.** Baseline hardening recommendations applicable to most servers. The default starting point for production server hardening. * **Level 1 — Workstation profile.** Baseline hardening recommendations applicable to most workstations. Differs from Server in service expectations (X11, browser plugins, etc.). * **Level 2 — Server profile.** Defense-in-depth recommendations on top of Level 1 Server. Higher friction; reserved for high-risk servers. * **Level 2 — Workstation profile.** Defense-in-depth recommendations on top of Level 1 Workstation. LinuxGuard does not select a profile for the customer. The mapping above is profile-agnostic — the baseline categories (SSH server, SSH client, accounts, groups, SUDO aliases, SUDO defaults, SUDO rules) apply across all profiles, with the customer's baseline content encoding the profile-specific settings. ## How to share with auditor Three export paths are available, depending on the auditor's evidence preference: * **Console Compliance Expansion reports.** Console pillar → Compliance Expansion → Reports produces dated, signed, auditor-shareable evidence packages (PDF / CSV / JSON) per [Compliance Expansion](/concepts/concepts/console/compliance-expansion.md#reports). Each report includes the framework version (the pinned per-distro Benchmark version), last-verified date, per-recommendation-category coverage, per-server pass / fail breakdown, suppressions in effect, and a manifest with SHA-256 verification. * **Support bundles for host-level evidence.** `support-bundle collect` on each host produces a tar.zst archive with agent logs, redacted configuration, and a bundle manifest — see [Support Bundles](/operate/operate/support-bundles.md). Bundles are useful when the auditor wants raw host-level telemetry rather than a console-rendered report. * **Console CSV / JSON export per recommendation category.** Compliance Expansion → CIS Benchmark → recommendation category detail → Evidence tab exports per-category evidence in machine-readable form for auditors who want to ingest evidence into their own GRC tooling. > **Security Note**: Support bundles include the raw `agent.log` and rotated segments. Attribute-key redaction (api\_key / \*\_token / \*\_secret) is applied; PII (hostnames, IPs, usernames, paths, command args) is NOT additionally redacted. Review every evidence package before sharing externally. See [Support Bundles](/operate/operate/support-bundles.md) for the per-file redaction status table. ## Cross-references * [**CIS Controls**](/audit-and-comply/audit-comply/cis-controls.md) — distinct from CIS Benchmarks: 18 strategic security control families. See the callout at the top of this page for the separation rationale. * [**Baselines**](/concepts/concepts/console/baselines.md) — the load-bearing console surface for the baseline categories this Benchmark mapping references. * [**Audit & Comply**](/audit-and-comply/audit-comply.md) — vocabulary contract, framework version pin reference, forbidden-words list, scope statement template. * [**Compliance Expansion**](/concepts/concepts/console/compliance-expansion.md) — console pillar; canonical Evidence Location pointer set. * [**Support Bundles**](/operate/operate/support-bundles.md) — per-file redaction status table; pre-share PII warning. * [**Log Management**](/operate/operate/log-management.md) — log retention and rotation relevant to evidence retention. * [**Glossary**](/reference/reference/glossary.md) — framework acronyms and compliance vocabulary definitions. *** *Last reviewed: 2026-05-31 against the per-distro CIS Benchmarks listed in the Per-distro Benchmark version pins table above.* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.linuxguard.io/audit-and-comply/audit-comply/cis-benchmarks.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.