What is a STIG?
A STIG, or Security Technical Implementation Guide, is a detailed configuration standard for one specific product, such as Windows Server 2022, Red Hat Enterprise Linux 9, a model of Cisco router, a web server or a database. The Defense Information Systems Agency (DISA) publishes STIGs, and U.S. Department of Defense (DoD) systems are required to be configured to the ones that apply to them. Defense contractors and other government agencies commonly adopt them too, and because most STIGs can be downloaded free, some private companies use them as an unusually strict benchmark.
STIGs sit under broader Security Requirements Guides (SRGs). An SRG states requirements for a whole class of technology, such as all operating systems or all web servers; a STIG translates them into exact settings for one product.
How a STIG is organized
A STIG is a list of individual rules. Each rule carries a vulnerability ID and rule ID so findings can be tracked from one release to the next, a severity category, check text describing exactly how to test the system, and fix text describing how to bring it into compliance.
Severity comes in three categories:
- CAT I: the most serious findings, where exploitation could directly and immediately cost confidentiality, integrity or availability.
- CAT II: findings that could lead to such a loss.
- CAT III: findings that weaken the protections against a loss.
Teams fix CAT I findings first, and an open CAT I finding is often enough to hold up a system's authorization to operate until it is fixed or formally mitigated.
Checking a system against a STIG
Many STIGs have a matching SCAP benchmark, so most rules can be tested automatically with DISA's SCAP Compliance Checker or OpenSCAP. Rules a tool cannot test, such as whether a documented procedure exists, are checked by hand. Results go into a checklist, commonly kept in DISA's STIG Viewer, where every rule is marked Open, Not a Finding, Not Applicable or Not Reviewed. Part of a Linux server checklist might read:
| Severity | Rule | Status |
|---|---|---|
| CAT I | The telnet-server package must not be installed | Open |
| CAT II | The DoD Notice and Consent Banner must appear before logon | Not a Finding |
| CAT II | Changes to /etc/sudoers must generate audit records | Open |
The fix text for the first row tells the administrator to remove the package. After removal, the rule is checked again and marked Not a Finding. A rule the team cannot meet is not simply left open; it is documented with a mitigation and an approval. For Windows, DISA also publishes Group Policy packages that apply many STIG settings across a domain at once.
STIG vs. CIS Benchmark
| STIG | CIS Benchmark | |
|---|---|---|
| Publisher | DISA, part of the DoD | Center for Internet Security |
| Who must use it | Required on DoD systems | Voluntary unless a contract or regulation requires it |
| Severity model | CAT I, II and III per rule | Level 1 and Level 2 profiles |
| Strictness | Usually stricter, written for defense networks | Level 1 is practical for most systems |
Both are benchmarks: published recommendations an organization turns into its own secure baseline. A STIG is a mandatory standard inside the DoD and a guideline for everyone else.
STIG on the CompTIA Security+ exam
The STIG acronym is not on the SY0-801 acronym list, and STIGs come up on the exam as one source of benchmarks: as a starting point for hardening and secure baselines under objective 4.1, as content that compliance scanners check hosts against under objective 4.4, and as a kind of benchmark among the governance guidelines in objective 5.1. A scenario about a contractor that must configure systems to Department of Defense requirements points to STIGs, and one that ranks findings as CAT I, II or III points to STIG severity. Distractors include CIS Benchmarks, which are not DoD mandates; SCAP, which is the format and tooling used to check a STIG rather than the guide itself; and NIST frameworks, which describe whole security programs rather than product settings.