DISA STIGs. Product-Specific Hardening Verified Continuously.

Security Technical Implementation Guides (STIGs) are the Department of Defense's authoritative source for product-specific security hardening. Published by the Defense Information Systems Agency (DISA), each STIG provides a complete set of configuration requirements for a specific technology: an operating system, a database engine, a web server, a network device, a container platform. STIGs do not exist in isolation. They derive from Security Requirements Guides (SRGs), which define security requirements at a product category level (General Purpose Operating System SRG, Application Security SRG, Network Device SRG). SRGs themselves derive from NIST 800-53. This three-tier hierarchy means every STIG check traces back through the SRG to a specific 800-53 control. STIGs are mandatory for all DoD information systems. Any system operating on the DoD Information Network (DoDIN) must comply with every applicable STIG before receiving an Authority to Operate (ATO). Civilian agencies and defense contractors increasingly adopt STIGs as hardening baselines because they represent the most granular, prescriptive security configuration guidance available for common technology products.

Each STIG contains hundreds of individual checks, called rules or findings. Every rule is assigned a severity category. CAT I findings represent high-severity vulnerabilities: exploitation could result in direct loss of confidentiality, integrity, or availability. An open CAT I finding on a production system is a critical risk that demands immediate remediation. CAT II findings represent medium-severity vulnerabilities: exploitation could degrade system security posture significantly but may require additional conditions or access to exploit. CAT II findings constitute the bulk of most STIG checklists and represent the operational hardening baseline that organizations must achieve. CAT III findings represent low-severity issues: exploitation potential is limited, but the configuration still deviates from the prescribed secure baseline. The severity categorization directly influences remediation priority, POA&M timelines, and ATO decisions. A system with open CAT I findings will not receive an ATO. A system with manageable CAT II findings may receive a conditional ATO with a remediation timeline. The categorization is not advisory. It is binding for DoD systems and increasingly referenced in contractor security requirements.

The structural relationship between these three tiers is deterministic and consequential. NIST 800-53 defines the security control (for example, AC-2: Account Management). The SRG translates that control into a technology-category requirement (for example, the General Purpose OS SRG specifies that the operating system must enforce approved authorizations for controlling the flow of information). The STIG translates that SRG requirement into a product-specific check (for example, the RHEL 9 STIG specifies that the system must use a specific PAM module configuration to enforce account lockout after a defined number of failed authentication attempts). Each layer adds specificity. Each layer narrows from policy intent to technical implementation to verifiable configuration. This traceability is what makes STIGs valuable beyond the DoD context. Organizations pursuing CMMC, FedRAMP, or NIST 800-53 compliance can use STIG scan results as direct evidence for the underlying 800-53 controls. A passing RHEL 9 STIG scan does not just prove the operating system is hardened. It proves specific 800-53 controls are implemented at the configuration level, with product-specific evidence the assessor can verify independently.

STIGs operate as overlays within the NIST compliance architecture. An overlay modifies or extends a base framework by adding product-specific, environment-specific, or mission-specific requirements. In the STIG context, the overlay chain has three layers. The base layer is NIST 800-53, which defines security controls at the policy level: what capability must exist. The middle layer is the SRG, which defines how a category of technology must implement those controls: what the operating system, database, or network device must do. The top layer is the STIG, which defines the exact configuration: what specific setting, parameter, or file permission satisfies the SRG requirement on a specific product. This layered architecture means organizations do not choose between framework compliance and technical hardening. Technical hardening IS framework compliance, expressed at the configuration level. Each STIG check is a concrete, verifiable instantiation of an abstract security control.

The composition engine in Redoubt Forge stacks these layers automatically. When you activate a STIG overlay for a system, the platform resolves the full derivation chain: 800-53 control to SRG requirement to STIG rule. This resolution is not a flat lookup table. It accounts for the hierarchical relationships between controls. A single 800-53 control may generate multiple SRG requirements (because the SRG decomposes the control into technology-specific aspects), and each SRG requirement may generate multiple STIG checks (because the product implements the requirement through several distinct configurations). The composition engine maintains these one-to-many relationships at every layer. When a STIG scan reports a finding, the platform traces it back through the SRG to the 800-53 control, determining exactly which base framework control is affected by the product-specific configuration gap. This traceability transforms STIG scan results from an isolated technical checklist into compliance evidence with full provenance.

Rampart maintains the full derivation chain for every STIG rule in the catalog. Each rule displays its SRG parent, the 800-53 control it traces to, and every framework assessment that references that 800-53 control. When you remediate a STIG finding on a RHEL 9 server, Rampart traces the impact upward: the STIG rule is satisfied, the parent SRG requirement advances, the 800-53 control gains additional evidence, and every framework that references that control (CMMC, FedRAMP, NIST 800-171) reflects the improvement. This upward propagation happens automatically as scan results arrive. You do not manually map STIG findings to framework controls. You do not maintain a separate crosswalk spreadsheet. The derivation chain is structural, maintained by the platform, and resolved in real time as your security posture changes. One STIG remediation action generates compliance evidence across every framework that traces to the same 800-53 lineage.

Operating system STIGs represent the largest and most granular hardening checklists in the DISA catalog. The RHEL 9 STIG alone contains over 300 individual checks. Each check specifies an exact configuration requirement: a file permission, a kernel parameter, a PAM module setting, an audit rule, a service state, a mount option. The supported operating system STIGs span the platforms most commonly deployed in DoD and defense contractor environments. RHEL 7, RHEL 8, and RHEL 9 cover the Red Hat Enterprise Linux ecosystem across its active and extended lifecycle versions. Ubuntu 20.04 and Ubuntu 22.04 cover the Canonical LTS releases increasingly deployed in cloud and containerized environments. Windows Server 2019 and Windows Server 2022 cover the Microsoft server operating systems used in Active Directory, file services, and application hosting. Windows 10 and Windows 11 cover endpoint operating systems for user workstations. Each platform has distinct STIG content reflecting its unique security architecture, configuration mechanisms, and hardening surfaces.

The key check areas across operating system STIGs follow consistent patterns despite the platform differences. File permissions checks verify that critical system files, configuration directories, and executable paths have ownership and permission settings that prevent unauthorized modification. Service configuration checks verify that unnecessary services are disabled, required services are running with appropriate privileges, and network-facing services are configured with secure defaults. Authentication checks verify password complexity requirements, account lockout thresholds, session timeout settings, and multi-factor authentication enforcement. Auditing checks verify that the operating system records security-relevant events: successful and failed login attempts, privilege escalation, file access on sensitive directories, system configuration changes, and audit subsystem integrity. These check categories map directly to 800-53 control families: AC (Access Control), AU (Audit and Accountability), CM (Configuration Management), IA (Identification and Authentication), and SC (System and Communications Protection).

Vanguard executes STIG scans against connected operating systems and produces raw results for every applicable check. Each scan result captures the rule identifier, the check status (Open, Not a Finding, Not Applicable, Not Reviewed), the actual configuration value observed, and the expected value defined by the STIG. For Linux systems, Vanguard evaluates kernel parameters, file permissions, PAM configurations, audit rules, SSH settings, and service states. For Windows systems, Vanguard evaluates Group Policy settings, registry values, Windows Firewall configurations, audit policies, and user rights assignments. Sentinel schedules these scans on a continuous basis and monitors for configuration drift between scan cycles. When Sentinel detects that a previously compliant setting has changed (a kernel parameter modified, a service re-enabled, a file permission altered), it fires a drift event that triggers re-evaluation of every STIG rule affected by the change. The result is continuous STIG compliance monitoring, not periodic scan-and-forget checklists that go stale between assessment cycles.

Container platforms introduce security considerations that traditional operating system hardening does not address. The Docker Enterprise STIG covers the container runtime layer: daemon configuration, storage driver security, network isolation between containers, logging driver settings, content trust enforcement, and resource constraints. The Kubernetes STIG covers the orchestration layer: API server authentication and authorization, etcd encryption, kubelet security settings, network policy enforcement, pod security standards, RBAC configuration, and audit logging for the control plane. These STIGs exist because containers and orchestrators are distinct technology categories with their own threat models. A hardened host operating system running an unhardened container runtime creates a security gap that the OS STIG alone cannot close. The container and orchestration STIGs layer on top of the OS STIG to address the full stack from kernel through runtime through orchestration.

The key check areas for container STIGs reflect the unique security architecture of containerized environments. Image provenance checks verify that container images are pulled only from trusted registries, that content trust (image signing) is enabled, and that images are scanned for vulnerabilities before deployment. Runtime security checks verify that containers run with minimal privileges: no privileged mode, no host namespace sharing unless required, read-only root filesystems where possible, dropped Linux capabilities, seccomp profiles applied, and AppArmor or SELinux enforcement active. Orchestration hardening checks verify that the Kubernetes control plane is secured: API server uses TLS with strong cipher suites, etcd data is encrypted at rest, anonymous authentication is disabled, RBAC policies follow least privilege, and admission controllers enforce pod security standards. Network policies checks verify that pod-to-pod communication is restricted by default and explicitly allowed only for documented traffic flows, preventing lateral movement within the cluster.

Vanguard scans container environments against both the Docker Enterprise STIG and the Kubernetes STIG simultaneously. For Docker, Vanguard evaluates the daemon configuration file, running container settings, image trust policies, and network configurations. For Kubernetes, Vanguard evaluates the API server manifest, controller manager settings, scheduler configuration, kubelet parameters, etcd encryption configuration, and active network policies. Each scan produces results at the individual rule level, with the observed configuration value compared against the STIG requirement. Findings are categorized by severity (CAT I, CAT II, CAT III) and mapped through the Container Platform SRG to the underlying 800-53 controls. Sentinel monitors the container environment continuously between scans: new pods deployed without required security contexts, network policies modified or deleted, RBAC bindings added that expand access beyond the documented baseline. Each detected change triggers re-evaluation of the affected STIG checks, maintaining continuous compliance visibility across the containerized estate.

Database systems store the data that frameworks exist to protect. The PostgreSQL STIG, MySQL STIG, and Oracle STIG each define product-specific hardening requirements for the database engine, its authentication mechanisms, its encryption capabilities, and its audit logging configuration. These STIGs derive from the Database SRG, which translates 800-53 controls into database-specific security requirements. A database that stores Controlled Unclassified Information must satisfy every applicable STIG check for the database product in use. The database STIG does not replace the operating system STIG for the host; they stack. The host runs a hardened operating system (RHEL 9 STIG), the database runs on that host with its own hardening requirements (PostgreSQL STIG), and both layers contribute evidence to the same 800-53 controls. The layered composition ensures that every level of the technology stack is hardened according to its product-specific requirements, not just the operating system surface.

The key check areas for database STIGs target the data protection and access control capabilities specific to database systems. Authentication checks verify that database connections require strong credentials, that password policies enforce complexity and rotation requirements, and that host-based authentication files restrict connections to authorized network addresses and users. Encryption checks verify that data is encrypted in transit (TLS connections between clients and the database engine) and at rest (tablespace encryption for sensitive data stores). Audit logging checks verify that the database records all security-relevant events: login successes and failures, privilege changes, schema modifications, data access on sensitive tables, and administrative actions. The audit log must be protected from modification by database administrators, typically by forwarding to a centralized log collection system that the DBA cannot access. Access control checks verify that role-based permissions follow least privilege: application accounts have only the permissions their functions require, administrative access is restricted to named individuals, and default accounts are disabled or secured. Backup checks verify that database backups are encrypted, stored securely, and tested for recoverability on a defined schedule.

Vanguard scans database configurations against each product-specific STIG. For PostgreSQL, Vanguard evaluates postgresql.conf settings, pg_hba.conf authentication rules, role permissions, extension configurations, SSL/TLS settings, and audit logging via pgaudit. For MySQL, Vanguard evaluates my.cnf parameters, user privilege grants, TLS enforcement, audit plugin configuration, and password validation settings. For Oracle, Vanguard evaluates init.ora parameters, listener configuration, role grants, audit trail settings, and Transparent Data Encryption status. Each scan produces per-rule results with observed values, expected values, and finding status. Results feed through the Database SRG derivation chain into Rampart, where they map to 800-53 controls and advance compliance posture across every framework that references those controls. Sentinel monitors database configurations continuously, detecting changes to authentication settings, permission grants, encryption configurations, and audit logging parameters between scheduled scans.

Web servers and network devices sit at the boundaries of every system. They handle traffic ingress, enforce routing policies, terminate TLS connections, and control access between network segments. The Apache STIG and Nginx STIG define hardening requirements for the two most widely deployed web servers: TLS configuration (protocol versions, cipher suites, certificate management), access logging, error handling (suppressing version strings and stack traces), request filtering, directory traversal protections, and module configuration. The network device STIGs cover Cisco IOS and Cisco NX-OS for routing and switching infrastructure, Juniper for enterprise and service provider networks, and Palo Alto for next-generation firewalls. These STIGs derive from the Web Server SRG and the Network Device SRG, respectively, which translate 800-53 controls into technology-category requirements. The AWS Foundations STIG extends this model into cloud infrastructure, defining hardening requirements for AWS account configuration, IAM policies, logging services, and network architecture.

Web server STIG checks focus on the HTTP layer and its security properties. TLS configuration checks verify that only approved protocol versions (TLS 1.2 and 1.3) are enabled, that cipher suites meet FIPS 140-2 requirements, and that certificates are valid, properly chained, and managed through an approved certificate authority. Access logging checks verify that every HTTP request is logged with sufficient detail for forensic analysis: client IP, request method, URI, response code, user agent, and timestamp. Security header checks verify that responses include appropriate headers: Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, and X-Frame-Options. Network device STIGs focus on management plane security (SSH access controls, SNMP community string restrictions, NTP authentication), control plane security (routing protocol authentication, spanning tree protections, ARP inspection), and data plane security (access control lists, traffic filtering, VLAN segmentation). AWS Foundations checks cover IAM password policies, CloudTrail logging, VPC flow logs, security group configurations, S3 bucket policies, and encryption settings for storage and transit.

Vanguard scans web server configurations by evaluating the server configuration files (httpd.conf for Apache, nginx.conf for Nginx), module loadouts, TLS settings, and virtual host configurations. For network devices, Vanguard evaluates the running configuration against the applicable STIG checklist: interface configurations, access control lists, management access settings, logging configurations, and protocol-specific hardening parameters. For AWS Foundations, Vanguard evaluates account-level settings through the AWS API: IAM policies, CloudTrail configuration, S3 bucket policies, security group rules, and encryption settings across services. Each scan produces results at the individual STIG rule level with full derivation chain traceability through the applicable SRG to 800-53. Sentinel monitors these devices and services continuously. When a network device configuration changes, a web server setting is modified, or an AWS security group rule is altered, Sentinel detects the change and re-evaluates every affected STIG check. Drift from the hardened baseline is detected in real time, not discovered during the next scheduled scan.

STIG scanning produces evidence at the individual rule level, and the granularity requirements are precise. Each scan targets a specific STIG checklist against a connected system and captures every check: the STIG rule identifier (V-number and SV-number), the rule title, the severity category (CAT I, CAT II, CAT III), the check status (Open, Not a Finding, Not Applicable, Not Reviewed), the observed configuration value on the target system, and the expected value defined by the STIG. These raw results must be structured, machine-readable, and timestamped. Narrative summaries and aggregated scores are not sufficient; assessors require granular, per-rule evidence they can verify independently. STIG scanning must cover the full catalog: operating systems, containers, databases, web servers, network devices, and cloud foundations. Scans should be executable on demand for immediate assessment, schedulable on a recurring basis for continuous compliance, and integratable into deployment pipelines as gates that prevent non-compliant configurations from reaching production environments.

Between full STIG scans, configuration drift is the primary threat to compliance accuracy. A file permission altered, a service started, a network rule modified, or a database setting updated can affect STIG compliance without triggering a rescan. Organizations that rely solely on scheduled scans operate in a state of unknown compliance between scan windows. The challenge is event-driven evidence collection: evaluating each configuration change against every STIG rule that references the affected parameter so the compliance state remains current. Evidence freshness matters at the per-rule level. A scan result from last week may still be valid for rules governing static configurations, but rules governing dynamic parameters like service states or network rules require more frequent validation. Each evidence artifact needs full provenance metadata: the source system, the collection timestamp, the collector identity, the integrity hash, and the derivation chain linking the evidence to the specific STIG rule it supports. Evidence that requires human verification (physical security checks, personnel interviews, manual process observations) presents additional challenges, as these artifacts expire on their own schedules and require escalation workflows to ensure timely renewal.

Scan results and continuously collected evidence feed into Rampart for scoring and mapping. Rampart resolves each STIG finding through the derivation chain: STIG rule to SRG requirement to 800-53 control. An open finding on a RHEL 9 STIG check maps to a specific SRG requirement in the General Purpose OS SRG, which maps to a specific 800-53 control (for example, AU-12 for audit generation). That 800-53 control is referenced by every framework assessment in Rampart: CMMC, FedRAMP, NIST 800-171, and others. A single STIG remediation action generates compliance improvement across the full framework portfolio. Rampart displays the aggregate STIG compliance status per system (total checks, passing, failing by category), the per-rule detail with evidence and derivation chain, and the upstream impact on every framework assessment that references the affected 800-53 controls. The scoring is continuous. As new scan results arrive and Sentinel detects configuration changes, Rampart recalculates compliance status in real time.

The STIG to SRG to 800-53 derivation chain is deterministic and fully traceable. Consider a concrete example. The RHEL 9 STIG contains rule V-257844: "RHEL 9 must use a separate file system for /var/log/audit." This rule derives from SRG-OS-000480-GPOS-00227 in the General Purpose Operating System SRG. That SRG requirement derives from NIST 800-53 control AU-4 (Audit Log Storage Capacity). AU-4 requires that the information system allocates audit log storage capacity in accordance with audit log storage requirements. The STIG translates this abstract requirement into a verifiable configuration check: is /var/log/audit on a separate partition? The answer is binary. The evidence is a mount table entry. The chain from STIG rule to SRG requirement to 800-53 control is documented, published, and auditable. This is not an interpretive mapping. It is a structural derivation maintained by DISA and NIST. Every STIG rule in the catalog carries this full chain, and the platform preserves it end to end.

STIG compliance advances NIST 800-53 and CMMC posture simultaneously because both frameworks derive from the same control catalog. When your RHEL 9 systems pass their STIG scan for AU-4, that evidence supports the same AU-4 control in your NIST 800-53 assessment. It also supports CMMC practice AU.L2-3.3.4 (Audit Storage Capacity), which derives from NIST 800-171 requirement 3.3.4, which traces back to 800-53 AU-4. If you are pursuing FedRAMP, the same AU-4 control appears in the FedRAMP Moderate baseline with FedRAMP-specific parameter values. The STIG evidence proves the control is implemented at the configuration level. One STIG remediation generates evidence that propagates through every framework in the derivation chain. Organizations that view STIG compliance as a separate activity from framework compliance are doing the same work twice. STIG findings are framework findings expressed at the product configuration level. Closing STIG gaps is closing framework gaps. The derivation chain makes this structural, not interpretive.

Rampart resolves STIG-to-framework relationships through five mapping strategies. Direct derivation follows the published STIG to SRG to 800-53 chain for every rule. Cross-framework propagation traces the 800-53 control outward to every framework that references it: CMMC, FedRAMP, NIST 800-171, SOC 2, ISO 27001, and others. SRG aggregation groups STIG findings by their parent SRG requirement, showing which SRG requirements are fully satisfied and which have remaining open findings. Control family analysis aggregates STIG results by 800-53 control family (AC, AU, CM, IA, SC, SI), providing a view of which control families have the strongest technical evidence from STIG scans and which have gaps. Coverage gap identification identifies 800-53 controls that are referenced by your active framework assessments but have no STIG coverage, highlighting where STIG scan results provide evidence and where other evidence sources are needed. These five strategies transform STIG scan data from an isolated technical report into an integrated component of your compliance posture across every framework in the catalog.