STIGs Explained

What Is a STIG?

A Security Technical Implementation Guide (STIG) is DISA's prescriptive, technology-specific hardening standard. There's no such thing as a generic STIG: there's one for Red Hat Enterprise Linux, one for PostgreSQL, one for Apache, one for custom application development, and so on, one per product or platform. Each STIG is a checklist of individually numbered findings, called Vuln IDs (for example V-222607), and each finding carries:

• a severity category, CAT I, II, or III, roughly critical, high, and medium risk if left unaddressed;
• a check, the exact steps to test whether the system is compliant;
• a fix, the exact change to make if it isn't.

None of that is invented in isolation. Every STIG finding traces back to one or more DoD CCIs (Control Correlation Identifiers), and every CCI in turn traces back to one or more NIST SP 800-53 controls. A STIG is, in effect, a 800-53 control translated into something a system administrator can actually go and check.

Not every DISA checklist is a STIG, though. A Security Requirements Guide (SRG), like the AAA Services SRG → loaded in this project, covers a category of technology generically (authentication and accounting services, in that case) rather than one specific product. Vendors use an SRG as the starting point when DISA hasn't published a STIG for their product yet. The structure, and the trace back through CCIs to NIST SP 800-53, is identical either way.

From Control to Configuration

This is a real, live example from this project, not a hypothetical. NIST SP 800-53 control SI-10 (Information Input Validation) is decomposed into CCI-001310, which is implemented as STIG finding V-222607 in the Application Security and Development STIG, which resolves to an actual fix in the system.

Open this finding on the STIG explorer →

How STIGs Are Applied

1. Identify the applicable STIGs. Every distinct technology in the system, operating system, database, web server, custom application, network device, gets matched to its own STIG from DISA's library.
2. Scan against the checklist. Manually with STIG Viewer, or automated with tooling like SCAP Compliance Checker (SCC) or Evaluate-STIG, which encode the same checks as machine-readable rules.
3. Remediate. Apply the fix text where possible. Where a finding genuinely can't be remediated, document a compensating control or risk acceptance in a POA&M instead of ignoring it.
4. Re-scan and capture evidence. Re-run the checks and keep the pass/fail results as evidence of the system's hardened state.
5. Roll it into the authorization package. Evidence from every applicable STIG, across every technology in the system, feeds the RMF assessment package supporting an Authorization to Operate (ATO).

What They Achieve

• A consistent, testable hardening baseline for each technology, instead of ad hoc configuration.
• Direct traceability from a specific configuration check back to a NIST SP 800-53 control.
• A meaningfully reduced attack surface before the system ever goes into service.
• A defensible, auditable artifact when it's time to authorize the system for operation.

A Real System Has More Than One STIG

A "system" up for authorization is rarely one piece of software. Take a RHEL server hosting a database and a web application: that's at least four distinct technologies stacked on top of each other, and each one gets its own STIG. The system's overall security posture is the combination of all of them, not just whichever layer happens to be easiest to check.

Four STIGs, four different technologies, four different sets of check and fix text, and none of them overlap in what they check. But because every finding in every one of them still resolves through a CCI, they all land in the same place: one NIST SP 800-53 control baseline for the system as a whole. That's the point of the CCI layer, it lets completely unrelated technologies be assessed on their own terms while still rolling up into a single, coherent authorization package.