CIS Benchmarks (Linux)
CIS Benchmarks Linux control mapping — LinuxGuard agent and console capabilities aligned to per-distro hardening configurations with explicit separation from CIS Controls and Satisfies / Supports / Ou
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. For the vocabulary contract used here, see Audit & Comply.
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 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.
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 table or to a specific console page. See Audit & Comply 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.
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.
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.
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.
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.
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.
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.
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.
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 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:
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.
Customer defines the LinuxGuard baseline reflecting the Benchmark-aligned state — for SSHD config, the baseline captures the hardened
/etc/ssh/sshd_configcontents; for SUDO rules, the baseline captures the approved rule set; and so on.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.
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 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 Configurationrecommendations 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. 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 collecton each host produces a tar.zst archive with agent logs, redacted configuration, and a bundle manifest — see Support Bundles. 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.logand 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 for the per-file redaction status table.
Cross-references
CIS Controls — distinct from CIS Benchmarks: 18 strategic security control families. See the callout at the top of this page for the separation rationale.
Baselines — the load-bearing console surface for the baseline categories this Benchmark mapping references.
Audit & Comply — vocabulary contract, framework version pin reference, forbidden-words list, scope statement template.
Compliance Expansion — console pillar; canonical Evidence Location pointer set.
Support Bundles — per-file redaction status table; pre-share PII warning.
Log Management — log retention and rotation relevant to evidence retention.
Glossary — 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.
Last updated
Was this helpful?