DISA STIGs: Severity Categories, SRGs, and Working Through a Checklist

Security Technical Implementation Guides are hardening standards published by the Defense Information Systems Agency. They are mandatory for US Department of Defense systems, and they are used well beyond that because they are free, detailed, and maintained — for many products a STIG is the most thorough public hardening guidance available.

What is in one

A STIG covers one product or product family: an operating system version, a database, a browser, a network operating system, an application server. Inside are individual requirements, each with a stable identifier, a severity category, a statement of the requirement and why it exists, an explicit check procedure describing how to determine compliance, and an explicit fix procedure describing how to remediate.

The check-and-fix pairing is what distinguishes STIGs from most hardening guidance. A requirement is not a suggestion to "restrict access" — it is a specific command to run, a specific expected output, and a specific change to make. That precision is why they are usable for audit as well as for configuration.

Security Requirements Guides sit one level above. An SRG states technology-class requirements — what any database must do — and a STIG is the product-specific implementation of an SRG. Where no STIG exists for a product, the SRG is what you assess against, documenting how the product meets each requirement.

Severity categories

Three levels, and the definitions are worth knowing precisely because they drive remediation deadlines.

CAT I findings directly and immediately allow loss of confidentiality, availability or integrity. These are the ones that get systems refused authorization to operate, and they are expected to be fixed before deployment.

CAT II findings may result in loss and are the bulk of any STIG. CAT III findings degrade defence in depth without directly enabling compromise — still real, and lower priority.

A first assessment against a STIG typically returns hundreds of findings across all three, which is normal and not a crisis. Work CAT I first, then CAT II by exposure, and treat CAT III as a backlog.

Findings, exceptions and POA&Ms

Every requirement resolves to one of a few states. Open means non-compliant. Not a finding means compliant. Not applicable means the requirement does not apply to this configuration — a wireless requirement on a system with no radio — and needs a recorded justification. Not reviewed means nobody has looked yet, which is the state most checklists are actually in.

Where a requirement cannot be met — an application breaks, a vendor does not support the setting — the answer is a documented exception with a risk acceptance signed by someone with the authority to accept it, plus compensating controls. Undocumented deviations are the finding; documented ones are a decision.

Open findings that will not be fixed immediately go into a Plan of Action and Milestones: what the weakness is, who owns it, what will be done, and by when. The POA&M is what turns a list of problems into a managed remediation programme, and in regulated environments it is what the authorizing official actually reads.

Automating the assessment

Manual checklist work does not scale past a handful of systems. The tooling ecosystem exists for this: benchmark content published in machine-readable form, scanners that evaluate a system against it, and viewers that manage checklists and generate the reports.

The machine-readable content uses the same protocol suite as other configuration assessment work, carrying the standard identifiers so results are comparable across tools — the SCAP framework, with the individual settings identified as described under CCE and configuration baselines.

Better still, apply the hardening as code rather than assessing it after the fact. Publicly maintained configuration management content exists for most major STIGs, so a system can be built compliant and kept compliant automatically, which turns configuration drift from an annual discovery into a reverted change.

Using them outside the DoD

STIGs are free and public, and the guidance is sound for any organization. Two cautions apply. They are written for a specific threat model and can be more restrictive than a commercial environment needs — applying every requirement to a general-purpose corporate estate will break things. And they are one option among several; the CIS Benchmarks cover similar ground with tiered levels that are often easier to adopt incrementally.

Pick one baseline, document deviations, and assess continuously. On Linux hosts the baseline includes mandatory access control settings such as SELinux enforcing mode, which is exactly the kind of requirement quietly disabled during troubleshooting and never restored. Two competing baselines applied partially is worse than either applied consistently.

Exam angles

Know STIGs as DISA-published, product-specific configuration hardening standards with check and fix procedures, and SRGs as the technology-class requirements above them. Know CAT I, II and III by definition, with CAT I as directly exploitable. Recognize documented exceptions with risk acceptance as the response to unmeetable requirements, and POA&Ms as the tracking mechanism. Identify SCAP-based tooling as the automation path and CIS Benchmarks as the common alternative baseline.