DISA STIGs for Linux: what they are, who needs them, and how to check a server
Publisher: DISA (Defense Information Systems Agency, US Department of Defense) Full name: Security Technical Implementation Guides Applies to: DoD systems and the contractors and partners who connect to or operate them; often used elsewhere as a "very strict" baseline
A STIG is a detailed, checkable list of configuration rules for one specific product and version, for example "Canonical Ubuntu 24.04 LTS STIG" or "Red Hat Enterprise Linux 9 STIG". Each rule (a "finding") has an ID, a severity, a check (how to test it) and a fix. STIGs are much more prescriptive than the CIS Benchmarks and are updated on a regular cycle, roughly quarterly, so the version you scan against matters.
Facts checked 2026-09-29. STIG numbers change all the time: confirm the current release for your OS on https://public.cyber.mil/stigs/ before you audit.
Versions seen recently (as reported by vendor and tool pages)
Canonical Ubuntu 24.04 LTS STIG: v1r5, published May 13, 2026 (that update added one new check and modified 14 existing ones, including system journal, SSH cryptography, PAM authentication caching, kernel core dump controls, cron auditing, and no nfs-kernel-server package).
Red Hat Enterprise Linux 9 STIG: at v2r9 in mid-2026 per tool and vendor listings.
Red Hat Enterprise Linux 10 STIG: exists (first released in 2026 and revised since): check the current release.
"v1r5" means Version 1, Release 5: the version stays the same until a major rewrite, the release goes up with each update. Cite both in your audit notes.
How a STIG is organised
Severity categories: CAT I (highest risk, could directly allow a compromise), CAT II (medium), CAT III (low). Fix CAT I first.
Each rule has: a STIG ID (for example RHEL-09-xxxxxx), a title, the check text, the fix text and a status when you assess it:
Open You do not meet it (a finding).
NotAFinding You meet it.
Not_Applicable Does not apply to this system.
Not_Reviewed Not assessed yet.
Distribution formats: the STIG itself (XML/PDF), the free DISA STIG Viewer to browse it and record results in a checklist (.ckl or .cklb), and SCAP benchmarks to scan automatically.
What Linux STIGs tend to ask for (examples, not the full list)
- A DoD-style login banner on SSH and the console (the exact approved wording is in the STIG).
- FIPS-validated cryptography enabled (RHEL: FIPS mode) and strong SSH ciphers and MACs.
- Account and password rules: length and complexity, lockout after failed logins (pam_faillock), password aging, no empty passwords.
- Session controls: idle timeouts, limits on concurrent sessions, disabling Ctrl-Alt-Delete reboot.
- Auditing: an extensive set of auditd rules (account changes, privileged commands, file and kernel-module access, time changes) and protection of the audit logs.
- File and mount protections (separate partitions and options such as nodev, nosuid, noexec) and file permission checks.
- Removing unneeded packages and services (for example nfs-kernel-server on Ubuntu 24.04), and mandatory access control on (SELinux or AppArmor).
- Regular patching and, where required, a host intrusion-detection or file integrity mechanism.
- Kernel and network hardening (sysctl), core dump limits, and secure boot loader settings.
Some rules are very strict and can affect applications: read each one before you enforce it.
How to check and apply a STIG
Ubuntu (Ubuntu Security Guide, needs Ubuntu Pro):
sudo pro enable usg ; sudo apt install usg
sudo usg audit disa_stig # report goes to /var/lib/usg/ (on 22.04 the usg package must be recent enough)
sudo usg fix disa_stig # changes the system: test machine and snapshot first
Red Hat family (OpenSCAP with scap-security-guide, which ships a stig profile):
sudo dnf install openscap-scanner scap-security-guide
oscap info --profile stig /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml
sudo oscap xccdf eval --profile stig --results stig-results.xml --report stig-report.html /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml
# Red Hat provides no automated undo for remediation: generate the fix script, read it, test on a copy, snapshot first
Also available: DISA's own SCAP benchmarks (scan with SCC or oscap), community Ansible roles (for example the ansible-lockdown project publishes a RHEL 9 STIG role), Red Hat's STIG automation for RHEL 9, and the CIS "STIG benchmarks" (CIS publishes benchmarks that map STIG content, for example for RHEL 10 and Oracle Linux 9).
See the OpenSCAP, USG and Lynis sheet for commands and cautions.
FIPS mode on RHEL: check with fips-mode-setup --check and read the FIPS documentation before enabling it. It is generally best decided at install time. Switching it on later can break software that uses non-approved crypto, and needs a reboot.
A workable process
1. Pick the exact STIG (product and version) for your OS and note its v#r#.
2. Scan a test copy and save the report as your baseline.
3. Fix by severity: CAT I first, then CAT II, then CAT III.
4. For each finding you cannot fix, record why and how you reduce the risk. In DoD terms this becomes an entry in a Plan of Action and Milestones (POA&M) or a documented waiver approved by your authorising official.
5. Save the checklist (.ckl/.cklb) plus the scan report as evidence.
6. Rescan after every STIG update and after major system changes.
7. Build the hardening into your image or configuration management so servers start compliant.
STIG versus CIS (quick guide)
CIS Consensus, widely used everywhere, has Level 1 (practical) and Level 2 (stricter).
STIG DoD-driven, more prescriptive, updated on a regular cycle, uses CAT I/II/III severities, requires DoD-specific items (banner, FIPS).
Overlap Large. If you already meet CIS Level 2 you have done a lot of STIG work, but the two do not match one for one, and a few rules conflict.
If you are not in the DoD supply chain, CIS is usually the better fit: a full STIG can be more than your environment needs.
Common problems
"I hardened to the STIG and my application stopped": some rules restrict features apps use. Find the failing rule, decide whether the app or the setting changes, and document the outcome as an exception.
"My scan and my colleague's disagree": different STIG versions or different scanners. State the version (v#r#) and the tool version in every report.
"FIPS mode broke things": some tools, old SSH clients and custom crypto do not work in FIPS mode. Test before you enable it and enable it early in a build.
"The scan says Not_Reviewed for many rules": SCAP cannot check everything (policies, procedures, physical items). Those need a human review in STIG Viewer.
"A new STIG release added findings overnight": that is the update cycle. Schedule a rescan after each release.
"STIG or CIS?": follow the contract or the authorising official. If nothing forces you, start with CIS Level 1.
"The banner must contain exact wording": copy it from the STIG, not from memory.
Tips
Read the check text. Many failures are "the check looks for a specific file or setting and yours is different but equivalent": you may be able to adjust the setting to match, not the whole design.
Keep the last several STIG versions of your reports. The change between them is a useful record.
Automate the boring parts and keep the tricky ones in tickets.
Ubuntu and Red Hat both publish STIG tooling, so use it. Writing your own from the PDF is a long way to spend a weekend.
DISA stands for Defense Information Systems Agency. It does not stand for "Doesn't Interest Sysadmins Anywhere".
Sources (checked 2026-09-29)
DISA STIG library: https://public.cyber.mil/stigs/
Ubuntu STIG update (v1r5, May 13, 2026): https://forum.bigfix.com/t/updated-disa-stig-checklist-for-ubuntu-24-04-lts-server-published-2026-05-13/54554
Ubuntu, DISA-STIG compliance: https://ubuntu.com/security/disa-stig
Ubuntu, STIG hardening with USG: https://ubuntu.com/blog/disa-stig-ubuntu-22-04-usg
Red Hat, DISA STIG: https://access.redhat.com/compliance/disa-stig
Red Hat, compliance scanning (RHEL 9): https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/security_hardening/scanning-the-system-for-configuration-compliance-and-vulnerabilities_security-hardening
CIS Benchmarks June 2026 update: https://www.cisecurity.org/insights/blog/cis-benchmarks-june-2026-update