DISA STIGs are publicly published hardening guides for operating systems, applications and network devices. They are used as a reference standard even outside their original environment, because they are freely available and fairly detailed.
What a DISA STIG is
A STIG (Security Technical Implementation Guide) is a document published by DISA (Defense Information Systems Agency) – an agency of the US Department of Defense. Each supported platform (a specific operating system, database, web server, network device, and so on) has its own STIG with a set of concrete rules for how the system should be configured. STIGs are freely available at public.cyber.mil.
A STIG isn't just a text document – it is also distributed as a machine-readable benchmark (SCAP/XCCDF format) that can be loaded into tools such as STIG Viewer or into automated compliance scanners.
The structure of a single rule
Each STIG rule typically has:
- a Vulnerability ID (
V-XXXXXX) – the identifier of a specific finding; - a Rule ID and STIG ID – identifiers of the rule within the document;
- a Severity – the severity category (CAT I, II, or III);
- check text – how to verify whether the system meets the rule;
- fix text – how to remediate a gap.
Severity categories (CAT I/II/III)
- CAT I – the highest severity. Non-compliance can lead to a direct compromise of the system, data loss, or a complete bypass of security mechanisms (for example remote code execution or unrestricted privilege escalation).
- CAT II – medium severity. Non-compliance increases risk but usually does not by itself lead to immediate compromise – it's a weaker, but still significant, weakening of security.
- CAT III – the lowest severity. Non-compliance is closer to recommended practice than to an acute risk; the impact of a single rule is limited.
The category sets the priority of the fix, not whether the rule applies at all.
How rules are evaluated, and why not applied blindly
A STIG check finding is usually recorded in a checklist (.ckl) with one of these statuses:
- Open – the system does not meet the rule;
- NotAFinding – the system meets the rule;
- Not Applicable – the rule does not apply to this system;
- Not Reviewed – not yet evaluated.
Not every rule makes sense to apply across the board. A STIG is written for a general platform, not for a specific deployment – a typical example is a rule about disabling a wireless interface on a machine that has no wireless hardware at all, or a rule for a service that isn't running on the system in the first place. In such cases the rule is marked Not Applicable, but always with a justification, never silently.
Where a rule is relevant but strict compliance isn't possible for operational reasons, there is a formal exception path – typically a documented remediation plan (POA&M, Plan of Action and Milestones) or an approved waiver. “It can't be met” is not by itself a justification; it has to be accompanied by a rationale and, where applicable, compensating controls.
Why STIGs are used outside military environments too
Because STIGs are public, detailed and regularly updated, they are used as a hardening baseline in commercial operations as well – as a source of concrete, verifiable checks that an automated compliance scan can build on, without having to invent a rule set from scratch.