What Is a STIG? DISA Security Configuration Baselines

DISA develops and maintains the STIG catalog, sometimes independently and sometimes with the product's manufacturer or another government body. The requirement behind it is policy: DoD Instruction 8500.01 directs that DoD information technology be configured in accordance with DoD-approved security configuration guidelines and tasks DISA with producing them. The output is distributed as human-readable documents alongside machine-readable XCCDF bundles, so the same content can be read by an engineer or loaded into a scanner.

A single STIG rule is more than a setting. It carries an identifier, a discussion explaining why the setting matters, check text describing exactly how to determine the current state, fix text describing how to change it, a severity category, and one or more Control Correlation Identifiers. A CCI is the decomposition of a higher-level policy control into a discrete, measurable item, and each one maps back to a control in NIST SP 800-53. That crosswalk is what makes a STIG usable as authorization evidence rather than merely as a hardening checklist: a finding on a specific rule can be traced to the control it fails, and the control to the framework the system is assessed under.

A Security Requirements Guide (SRG) sits one level above a STIG. It describes the vulnerabilities and requirements that apply to a whole technology area — an operating system, an application server, a network device — with generic check and fix language that is not tied to any one product. A STIG is the product-specific instantiation of the relevant SRG: the same requirement, expressed as the actual command, registry value, or configuration line for one named product at one named version.

The practical consequence for a buyer is that "is there a STIG for this?" has three possible answers, not two. There may be a product STIG for exactly what you are buying. There may be no product STIG, in which case the program works from the SRG and writes its own product-specific interpretation, which is real engineering labor that has to be scoped. Or there may be a STIG for the product but for a different version than the one being quoted, which is the answer that most often surprises people. DISA also runs a Vendor STIG process through which a manufacturer collaborates on a guide for its own product, so catalog coverage tracks vendor engagement at least as much as it tracks market share.

Every requirement carries a severity category. A CAT I finding is one whose exploitation would directly and immediately result in a loss of confidentiality, availability, or integrity — the most severe rating in the catalog. A CAT II finding may result in such a loss and plausibly provides a path toward a CAT I. A CAT III finding degrades measures that contribute to defense in depth without, on its own, creating a direct exposure.

Those categories drive triage and authorization language rather than academic classification. Programs commonly require zero open CAT I findings before a system is permitted on the network, with CAT II and CAT III findings documented, justified, and scheduled on a plan of action and milestones. This is why a system described as STIG compliant almost never means every rule passes: it means the open findings are known, categorized, deliberately accepted, and tracked. A checklist with no open findings at all is rarer than the phrase suggests, and a supplier who promises one should be asked which version of which guide they mean.

Where a matching benchmark exists, checking is automated. SCAP — the Security Content Automation Protocol — is the specification family for machine-readable security content, and DISA publishes SCAP benchmark versions of part of its catalog. The scanner most commonly used inside the department is the SCAP Compliance Checker, developed by the Naval Information Warfare Center Atlantic and distributed at no cost; it performs an authenticated scan against benchmark content and returns a pass or fail for each rule it can evaluate.

Only a portion of the catalog ships with a matching SCAP benchmark, however. Everything else is evaluated by hand or with third-party tooling and recorded in DISA's STIG Viewer, which produces a checklist file marking each rule as Open, Not a Finding, Not Applicable, or Not Reviewed. Manual review is where most of the effort lives, and it is also where the quarterly cadence bites: each release can add rules, revise existing ones, or retire checks that a vendor patch has made obsolete, so a system's checklist is a living artifact maintained against the current revision rather than a one-time deliverable filed at handover.

The mandate reaches Department of Defense information technology, and the assessment machinery around it is the Risk Management Framework, operationalized for the department by DoD Instruction 8510.01. Contractors inherit the obligation through contract language for systems they build or operate on the department's behalf. It is worth separating that from a different obligation that is often conflated with it: a contractor's own corporate network handling controlled unclassified information is governed by NIST SP 800-171 and the CMMC program built over it, which is an assessment framework rather than a configuration catalog. STIG hardening is not itself a CMMC requirement, though a specific program can and does impose it contractually.

Outside that mandate, adoption is voluntary and common, for the straightforward reason that the guides are free, maintained by someone else, and defensible to an auditor. The usual alternative is the CIS Benchmarks, maintained by a private nonprofit and structured differently. Where a program is DoD-connected and a STIG exists, the STIG governs. Where an organization is choosing freely, the important discipline is to choose one and stay with it: mixing two baselines across an estate produces settings that contradict each other and an evidence trail nobody can reconstruct at audit time.

Three questions belong on the requisition rather than in the deployment. First, does a guide exist for the exact product and the exact version being quoted, and if the version differs, who reconciles the gap? Second, does the platform actually support the settings the guide requires without disabling the function the equipment was bought for — a genuine constraint on appliances, printers, cameras, and embedded devices, where a hardening rule and a feature can be mutually exclusive. Third, who applies the baseline, and who re-applies it each quarter for the life of the asset, because the answer to that question is an operating cost rather than a purchase.

It is worth being blunt about what a supplier can and cannot deliver here. There is no such thing as a STIG-certified product; a STIG describes how to configure something, and configuration status belongs to the running system and to the authorizing official who accepts it. What can be arranged commercially is narrower and still useful: a customer-supplied baseline applied during configuration and staging so hardware arrives built to the standard rather than retrofitted afterward, or a hardening pass written into a deployment scope with the configuration baselines and change records captured as the work happens. Both are quote-time conversations, and both want the applicable guide and revision named in writing.