Skip to main content
  1. Index/

DISA STIG

Table of Contents

DISA STIGs (Security Technical Implementation Guides) are published by the Defense Information Systems Agency (DISA), the US Department of Defense (DoD) agency responsible for IT infrastructure security standards. STIGs provide extremely prescriptive, line-item security configuration requirements for specific technology products — each STIG contains hundreds of individual “findings” (rules) specifying exact settings, permissions, and configurations required to harden a system. Unlike flexible frameworks (NIST 800-53) or guideline-oriented benchmarks (CIS), STIGs are mandatory for all DoD information systems and are referenced by the broader US federal government, defense contractors (via CMMC), and intelligence community systems. Each finding is categorized by severity: CAT I (high — failure could directly lead to loss of confidentiality, integrity, or availability), CAT II (medium), and CAT III (low). Systems must achieve full CAT I compliance and substantially address CAT II/III findings to receive an Authority to Operate (ATO). DISA publishes STIGs for hundreds of products and regularly updates them (typically quarterly). STIGs are developed in collaboration with the vendor — Red Hat, for instance, works directly with DISA to produce the RHEL STIG — and are made available to the public through DoD Cyber Exchange (public.cyber.mil). STIG compliance is verified using DISA’s STIG Viewer or automated tools like OpenSCAP that consume the machine-readable XCCDF/SCAP content.

Red Hat has the most comprehensive DISA STIG coverage of any Linux vendor. DISA publishes official STIGs for RHEL 7, 8, 9, and 10, Red Hat OpenShift Container Platform, Red Hat Ansible Automation Controller, and JBoss Enterprise Application Platform — all developed in direct collaboration with Red Hat’s security team. Red Hat ships STIG content directly in RHEL: the scap-security-guide package includes the XCCDF profile (xccdf_org.ssgproject.content_profile_stig) enabling administrators to scan and remediate systems using oscap immediately after installation. RHEL can be installed in STIG-compliant mode from day one by selecting the STIG profile during the Anaconda installer’s security policy selection. For OpenShift, the Compliance Operator provides dedicated STIG profiles (ocp4-stig, ocp4-stig-node, rhcos4-stig) supporting the latest DISA STIG V2R3, automating cluster-wide scanning and producing machine-readable results suitable for upload to DoD’s eMASS (Enterprise Mission Assurance Support Service). Red Hat’s STIG implementation requires FIPS mode to be enabled (a prerequisite DISA mandates), which RHEL supports natively. The combination of RHEL’s built-in STIG content, OpenShift’s Compliance Operator, and Ansible’s ability to enforce STIG configurations at scale means DoD organizations and defense contractors can achieve and maintain STIG compliance as a continuous, automated property of their infrastructure rather than a periodic manual exercise.

Additional Information
#

Related

CIS Benchmarks

CIS Benchmarks are detailed, prescriptive security configuration guidelines published by the Center for Internet Security (CIS), a US-based non-profit organization. They are developed through a consensus process involving cybersecurity practitioners, vendors, and government agencies, and cover over 100 technology families — operating systems (Linux, Windows, macOS), cloud platforms (AWS, Azure, GCP), container orchestrators (Kubernetes, Docker), databases, web servers, and network devices. CIS Benchmarks are international in applicability — they are not tied to any single jurisdiction — and are referenced by regulatory frameworks worldwide (NIST, PCI-DSS, HIPAA, FedRAMP, NIS2 national implementations). Each benchmark provides two recommendation levels: Level 1 (practical hardening that does not significantly impact functionality) and Level 2 (defense-in-depth settings for high-security environments). CIS Benchmarks are voluntary — no law mandates CIS compliance directly — but they are frequently required by procurement contracts, industry standards, and as evidence of “reasonable security measures” in regulatory audits. The CIS also offers CIS Controls (formerly the SANS Top 20), a prioritized set of cybersecurity best practices, and the CIS Hardened Images program for pre-configured virtual machine images.

FIPS 140-2 / FIPS 140-3

FIPS 140 (Federal Information Processing Standard, Publication 140) is the US and Canadian government standard that defines security requirements for cryptographic modules — the hardware, software, or firmware components that perform cryptographic operations (encryption, decryption, hashing, signing, key management). It is published by NIST (National Institute of Standards and Technology) and jointly administered with CCCS (Canadian Centre for Cyber Security) through the Cryptographic Module Validation Program (CMVP). The standard has two active versions: FIPS 140-2 (published 2001, no longer accepting new submissions since April 2022) and FIPS 140-3 (effective September 2020, the current standard for all new validations). FIPS 140-2 certificates remain valid until 21 September 2026, after which they move to the Historical list — meaning only FIPS 140-3 validated modules will be accepted for new federal procurements. FIPS 140 defines four security levels (Level 1 through Level 4), with Level 1 being the baseline for software modules and Level 4 requiring physical tamper-active hardware. Compliance is mandatory for all US federal agencies and their contractors under FISMA, for Canadian federal systems, and is widely adopted by regulated industries (finance, healthcare, critical infrastructure) globally. Non-validated cryptography is treated as providing no protection — effectively plaintext — regardless of the algorithm strength. Validation is a formal, lab-based process: vendors submit modules to accredited Cryptographic and Security Testing (CST) laboratories, which test against the standard and submit results to CMVP for certificate issuance.

FedRAMP

The Federal Risk and Authorization Management Program (FedRAMP) is a US government-wide program, codified into law by the FedRAMP Authorization Act of 2022, that provides a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services used by federal agencies. FedRAMP is administered by the General Services Administration (GSA) and is mandatory — any cloud service (SaaS, PaaS, IaaS) that stores, processes, or transmits federal data or metadata must achieve FedRAMP authorization before it can be used by US government agencies or their contractors. The program defines three impact levels: Low (limited adverse effect), Moderate (serious adverse effect), and High (severe or catastrophic effect — applies to law enforcement, emergency, financial, and health systems). Each level maps to NIST SP 800-53 Rev 5 control baselines: FedRAMP High requires implementation of approximately 421 controls. Authorization is achieved through either an Agency ATO (a specific agency sponsors the assessment) or the newer FedRAMP 20-X experimental accelerated path. Once authorized, cloud service providers (CSPs) must maintain continuous monitoring — monthly vulnerability scans, annual penetration testing, and Plan of Action & Milestones (POA&M) reporting — or risk revocation. Authorized services are listed on the FedRAMP Marketplace.