Secure Linux Baseline: Building a Versioned, Auditable Standard

A secure Linux baseline is a formally reviewed, versioned configuration specification for a defined class of systems. It is not a hardening script run once at provisioning. NIST’s glossary definition of a baseline configuration describes a documented set of specifications, reviewed and agreed upon at a point in time, that can be changed only through change-control procedures. In Linux operations this means that the distribution release, benchmark version, accepted exceptions, and verification method are recorded together, so that every future build can be compared with a known reference.

This article sets out what such a baseline should contain, how the CIS Benchmarks and related federal checklists fit into it, how the audit-then-remediate workflow operates, and where SELinux belongs in the specification.

TL;DR

• A baseline is a controlled reference for builds and changes, not a one-time checklist; it must name the distribution, release, benchmark version, and approved exceptions.
• CIS Benchmarks are release-specific, so the baseline should pin an exact benchmark version rather than citing “CIS Linux” generically.
• Audit first, review failures, tailor rules that conflict with the workload, test remediation in a representative non-production system, then audit again.
• SELinux should remain in enforcing mode wherever the distribution supports it; permissive mode is a diagnostic state, not a configuration target.
• A passing benchmark score does not establish that a system is secure or fit for its business purpose; prioritize exposed services, privileged access, patching, logging, and recovery.

Table of Contents

• What a Linux baseline must specify
• Choosing the benchmark: why release pinning matters
• Tailoring: no single correct control set
• The audit-then-remediate workflow
• Sequencing the work by risk
• SELinux policy basics within the baseline
• Making the baseline repeatable and resistant to drift
• Our perspective
• Support for baseline and risk review work
• FAQ
• Sources

What a Linux baseline must specify

The term is often used loosely to mean a list of hardening settings. The NIST usage is narrower and more useful: the baseline is the agreed reference against which deviation is measured. A defensible Linux specification therefore records the following elements:

The last row is frequently omitted and is arguably the most informative. A baseline without a recorded exception list conceals the decisions that were made, and it gives auditors no means of distinguishing a considered deviation from an oversight.

Choosing the benchmark: why release pinning matters

The CIS Benchmarks are consensus-based configuration recommendations, published separately for each operating system family and release. As of October 2026 the published examples include Ubuntu Linux 26.04 LTS 1.0.0, Ubuntu 24.04 LTS 2.0.0, Red Hat Enterprise Linux 10 1.0.1, and Debian Linux 13 1.1.0. The practical consequence is that a benchmark written for one release can yield inaccurate checks, or harmful remediation, when applied to another. The baseline document should state, for example, “CIS Ubuntu Linux 24.04 LTS Benchmark v2.0.0, Level 1 Server,” and not merely “CIS hardened.”

Release-specific guidance exists for the major families, including Ubuntu, Red Hat Enterprise Linux, and Debian. Each is available in PDF form, and the profile structure (Level 1 and Level 2, server and workstation) allows the control set to be matched to the role. Level 1 is generally the practical starting point for a general-purpose server, while Level 2 introduces settings that more often constrain functionality and therefore demand more testing.

Federal checklists and SCAP content

Organizations with procurement, audit, or federal-control mapping requirements have a second source. The National Checklist Program repository lists Linux security checklists and machine-readable SCAP content, with metadata identifying the target, the authority, the version, and associated resources. SCAP allows validated security products to automate configuration checking, which makes the repository particularly relevant where results must be reproducible by a third party. For Ubuntu, Canonical also documents DISA-STIG profiles; its announcement of the Ubuntu 22.04 STIG profile describes how the profile was released following DISA’s publication of the corresponding guide.

Provider baselines are narrower than they appear

Cloud providers publish their own baselines, and these should be read for what they cover. Microsoft’s documentation of the Azure security baseline for Linux, dated March 10, 2025, states that it applies to Azure virtual machines and Azure Arc-enabled machines, is audited through Azure Policy, and covers around 63% of CIS Distro Independent Benchmark 2.0.0. The same page describes audit-and-configure remediation as preview functionality and notes that certain settings, such as the expected SSH port, cannot be customized through policy parameters. A provider baseline is therefore a useful control layer for a defined platform, but it should not be represented as a complete Linux security or compliance assessment. Identity management, vulnerability handling, logging, backup, incident response, and application-level controls require separate treatment.

Tailoring: no single correct control set

The most common error in baseline work is to treat a benchmark as an inflexible mandate. NIST’s security-control guidance in SP 800-53 Revision 4 frames low-, moderate-, and high-impact baselines as starting points; organizations are expected to select and tailor controls according to mission, business priorities, information sensitivity, and operating environment. The guidance is explicit that no single set of controls suits every information system, and that priority codes sequence implementation without implying that partial implementation achieves a defined level of risk reduction.

Canonical’s own guidance on its Ubuntu Security Guide makes a consistent point from an operational direction: the CIS benchmark contains hundreds of configuration recommendations, and applying them without customization to an environment can produce functional problems. Tailoring, in this sense, is a documented process rather than an act of weakening. A rule that conflicts with the system’s purpose is recorded as an exception, accompanied by a compensating control where one exists.

Three criteria help determine whether a given deviation is defensible:

1. Necessity. The workload demonstrably cannot function with the recommended setting.
2. Containment. The exposure created is bounded by another control, such as network segmentation or a service-level sandbox.
3. Reviewability. The exception has an owner and a date on which it will be reassessed.

The audit-then-remediate workflow

The sequence matters because remediation applied to an unaudited system alters its state without a record of what existed before. Canonical’s Ubuntu Security Guide documentation describes a workflow that generalizes well to other distributions: install the required tooling, run an audit, review failures and exceptions, generate a tailoring file where necessary, test remediation, apply fixes, reboot if required, and audit again. The documented commands include usg audit cis_level1_server and usg fix cis_level1_server, and a tailoring file may be produced with usg generate-tailoring. Exact commands and profile availability depend on the Ubuntu release and on subscription and tooling state, so the baseline should record which tooling version produced the result.

On the Red Hat family, the equivalent mechanism is OpenSCAP. A Red Hat walkthrough of CIS compliance using OpenSCAP distinguishes the scanner package from the scap-security-guide package, which holds the data-stream files with the profiles and the remediation content, including Ansible playbooks and shell scripts. The article demonstrates scanning a RHEL 8 server against a CIS benchmark and then applying remediation through Ansible, which illustrates why remediation should be treated as code subject to review.

Verification and the limits of a score

CIS-CAT Pro supports automated assessment for 136 benchmarks as of October 2026, including Ubuntu 24.04 and 26.04, Debian 13, RHEL 10, Rocky Linux 10, Oracle Linux 10, and Amazon Linux 2023. Automation reduces manual effort, but tool support must still be verified against the exact distribution, release, benchmark, and content format. More importantly, a passing score does not by itself establish that a system is secure or fit for its business purpose. A host may satisfy every filesystem and permission check while exposing an unpatched application service, and a benchmark does not evaluate that risk.

Sequencing the work by risk

Because partial implementation does not map to a defined level of risk reduction, the order of work should follow exposure and not the numbering of benchmark sections. A defensible sequence is:

1. Remove or restrict externally reachable services, and confirm that each listening port has an owner.
2. Constrain privileged access: key-based authentication, restricted root login, and sudo policy. The SSH hardening guide on this site sets out a staged rollout with a copyable sshd_config.
3. Eliminate unsupported software and establish a patch cadence; the patch management strategy article treats testing windows of 30 to 90 days.
4. Enable logging and detection with defined retention and time synchronization.
5. Verify backup and recovery, since a hardened host that cannot be restored remains an availability risk.
6. Address controls tied to contractual or regulatory obligations.
7. Only then pursue remaining benchmark items that improve the score without altering the risk profile materially.

A broader treatment of control categories and their measurement appears in the system hardening checklist, which maps seven categories to measurable outcomes.

SELinux policy basics within the baseline

Mandatory access control is a distinct layer from file permissions, and the baseline should state its expected mode. According to Red Hat’s documentation on getting started with SELinux, SELinux runs in one of three modes: enforcing, permissive, or disabled. Enforcing is the default and recommended mode, in which the loaded policy is applied across the entire system. Permissive mode labels objects and records denials in the logs without actually denying operations, which makes it suitable for diagnosis but not for production. The same documentation explains that processes run in domains, and that policy rules define how those domains access files and other processes, which is how SELinux can limit the consequences of privilege escalation.

For baseline purposes, four statements are usually sufficient:

• The required mode (enforcing) and the policy type in use.
• The procedure for investigating a denial before any change is made, so that the response is a corrected label or a narrowly scoped boolean rather than disabling the mechanism.
• A record of any custom policy modules, with their justification and owner.
• A verification check, so that drift to permissive or disabled mode is detected.

On Debian-family systems, AppArmor fulfils a comparable role, and the same principle applies: the baseline names the mechanism, the expected state, and the method of verification. Service-level confinement can further bound exposure, as described in the systemd hardening guide.

Making the baseline repeatable and resistant to drift

A baseline that exists only as a document decays. Configuration management supplies the enforcement layer, but it introduces its own hazard: automation reproduces an outdated assumption as faithfully as a correct one. Hardening content should therefore be tested in staging, versioned, and promoted deliberately; the Ansible hardening article describes this staging discipline for administrators. Scheduled verification, canary hosts, and staged rollouts reduce the likelihood that a change breaks production, a subject treated in the Linux automation guide.

The maintenance cycle can be summarized as follows:

Our perspective

Our experience in Linux infrastructure and automation work is that baseline projects fail more often through process than through technical error. A team adopts a benchmark, applies the remediation in bulk, and discovers in production that a service no longer starts; the usual response is to abandon the standard rather than to tailor it. We therefore advise clients to treat the exception register as a first-class deliverable, to run the audit before any change is made, and to document the reason for every deviation at the moment it is accepted.

We also regard the final score as a weak indicator by itself. A baseline is valuable to the extent that it makes the next build, the next change, and the next audit predictable. Where the environment is small, with limited staff, the most productive use of effort is typically a narrow baseline that is fully verified and maintained, in place of a comprehensive one that nobody can reproduce.

— Jesse Hart

Support for baseline and risk review work

Organizations that need an independent review of an existing Linux estate, or help defining and automating a baseline, can consult the technical consulting and systems risk review page, which covers systems and risk review as well as infrastructure automation and review. Independent consultants and small firms seeking tooling and advisory support can see Project Praxis, listed at $99 per month.

FAQ

Is the CIS Benchmark the same as a secure Linux baseline?

No. The benchmark is an input to the baseline. The baseline is the organization’s own reviewed specification, which names a benchmark version and profile, records tailoring decisions, and defines how compliance is verified. Two organizations may adopt the same benchmark and arrive at different baselines because their workloads differ.

Which CIS profile should be applied first?

Level 1 is the usual starting point for general-purpose systems, because its recommendations are intended to be practical with limited effect on functionality. Level 2 should be applied where the data or regulatory context warrants it, and only after testing in a representative non-production system. The role (server or workstation) must match the profile chosen.

Can SELinux be set to permissive to avoid breaking applications?

Permissive mode is appropriate for short diagnostic work, since it logs denials without blocking operations, but Red Hat’s documentation does not recommend it for production systems. The preferable response to a denial is to examine the log, correct the file label or enable a narrowly scoped boolean, and retain enforcing mode. Any lasting departure belongs in the exception register.

Does a cloud provider’s baseline replace a Linux hardening program?

It does not. Microsoft’s Azure baseline for Linux, for instance, covers around 63% of one CIS benchmark and restricts customization of some settings. It addresses the platform layer, whereas identity, patching, logging, backup, and application controls remain the organization’s responsibility.

Sources

• NIST CSRC: baseline configuration glossary entry
• CIS Benchmarks list
• CIS Ubuntu Linux Benchmarks
• CIS Red Hat Enterprise Linux Benchmarks
• CIS Debian Linux Benchmarks
• CIS-CAT Pro supported benchmarks
• NIST National Checklist Program repository (Linux)
• NIST SP 800-53 Revision 4, final public draft
• Canonical: Ubuntu Security Guide documentation
• Canonical: CIS benchmark compliance with the Ubuntu Security Guide
• Canonical: DISA-STIG for Ubuntu 22.04 LTS with USG
• Microsoft Learn: Azure security baseline for Linux
• Red Hat: Getting started with SELinux
• Red Hat: CIS compliance in RHEL using OpenSCAP

Recommended

• Systemd Hardening: A Methodical Guide to Sandboxing Services
• 7-Category System Hardening Checklist for IT Ops, Measured and Mapped
• SSH Hardening for Sysadmins: Five‑Stage Rollout and Copyable sshd_config
• 30/90/365 Document Version Control for Teams: Operations First