If someone handed you a stack of STIGs and told you to “get compliant,” and you’re trying to figure out how to apply STIGs without drowning, this is the practical workflow — the same one I run as an ISSO. A STIG (Security Technical Implementation Guide) is a hardening standard from DISA that tells you exactly how a piece of software or hardware must be configured to be secure enough for a DoD network. Applying one means configuring your system to match those rules, testing whether it does, and documenting the result. That’s the whole game: configure, check, document.
The official DISA documentation explains what STIGs are but is close to unreadable when you just need to get the work done. So here’s the field version, in the order you’ll actually do it.
What a STIG Is and Why the DoD Requires Them
Every operating system, database, browser, and network device on a DoD network has to be locked down to a known-good baseline. STIGs are that baseline. There’s a Windows Server STIG, a Red Hat Enterprise Linux STIG, an Apache STIG, a Cisco IOS STIG — hundreds of them. Each is a list of individual rules, and each rule has a severity: CAT I (a direct, exploitable hole), CAT II (a serious weakness), or CAT III (a hardening gap). Your assessor will scan against these, and open STIG items become findings that land in your POA&M. Applying STIGs up front is how you keep that list short.
Step 1: Get the Right STIGs and Set Up Your Tools
Download the current STIGs from DISA’s Cyber Exchange (public.cyber.mil). Match versions to what you actually run — the Windows Server 2022 STIG, the specific RHEL version, the right browser. Then set up the two tools you’ll live in:
- STIG Viewer — DISA’s tool for reading a STIG and recording your compliance status rule by rule into a checklist (.ckl) file. This is your documentation of record.
- SCC (SCAP Compliance Checker) — runs automated SCAP content against a host and tells you which rules pass or fail without manual checking. It won’t cover every rule, but it does the heavy lifting.
The workflow most ISSOs use: run SCC first to auto-evaluate everything it can, import those results into STIG Viewer, then manually work the rules SCC couldn’t check.
Step 2: Learn to Read a STIG Rule
Every rule has the same anatomy, and once you can read one you can read all of them:
| Element | What it tells you |
|---|---|
| Rule title & ID | What the rule enforces and its unique identifier (V-number / Rule ID) for tracking |
| Severity (CAT I/II/III) | How bad it is if left open — drives your remediation priority |
| Discussion | Why the rule exists — useful when you need to justify a deviation |
| Check text | The exact procedure to determine compliant vs. not — run this to get your status |
| Fix text | The exact procedure to make it compliant — your remediation instructions |
Work CAT I rules first, always. A single open CAT I can stall an authorization on its own, so those get remediated or formally mitigated before anything else.
Step 3: Apply the STIGs — Manual vs. Automated
You have two ways to push settings, and mature shops use both:
- Automated. For Windows, DISA publishes Group Policy Objects (GPOs) that apply large chunks of a STIG at once — import them and a big share of the checklist flips to compliant. For Linux, configuration-management tooling like Ansible (DISA and the community publish STIG roles) applies and re-applies hardening consistently across many hosts. Automation is how you STIG 40 servers without STIGing each one by hand.
- Manual. Some rules can’t be safely automated — they’d break the application, or they depend on your specific architecture. Those you apply by hand using the fix text, one at a time, testing as you go.
Critical practice: apply hardening in a staging environment first, then validate the system still functions before you touch production. A STIG that locks down a service your application depends on will pass the scan and break the mission — test before you push.
Step 4: Document Results and Handle Open Items
After you’ve applied and scanned, every rule ends in one of three states in your checklist: Open (not compliant), Not a Finding (compliant), or Not Applicable (the rule doesn’t apply to this system — and you document why). For any rule you can’t fix immediately, write a comment explaining the situation and roll it into a POA&M item with a mitigation and a scheduled fix date. Open STIG items are normal; undocumented open items are what get you in trouble.
Those checklist files and POA&M entries feed directly into the authorization package — they’re part of the evidence trail that carries a system through the ATO process, and keeping them current is a core piece of ongoing continuous monitoring.
Common STIG Mistakes That Generate CAT I Findings
- STIGing the wrong version. Applying last year’s STIG to this year’s OS leaves new rules unaddressed — always match the STIG version to the deployed software.
- Trusting automation blindly. GPOs and Ansible roles don’t cover 100% of rules. The gap between “scan is green” and “checklist is complete” is where findings hide.
- Marking things Not Applicable without justification. An assessor will challenge every N/A. If you can’t explain why the rule doesn’t apply, it’s Open.
- Never re-STIGing after a change. A patch, an update, or a config change can silently undo hardening. Re-scan after significant changes, not just at assessment time.
- Applying to production first. The fastest way to an outage — and an emergency rollback that leaves the system half-hardened.
Keep your hardening evidence organized
STIG checklists, scan exports, and POA&M items all have to line up when the assessor arrives. The RMF Checklist ($27) gives you the artifact structure to track hardening evidence alongside every other control in your package.
Final Thoughts
Knowing how to apply STIGs comes down to a repeatable loop: pull the right STIG, read the rule, apply the fix (automated where you can, manual where you must), test in staging, scan, and document every result — including the open ones. Do it in that order and STIGs stop being a wall of red and become a routine part of standing a system up clean. The teams that struggle are the ones treating STIGs as a one-time scramble before assessment; the ones that cruise treat it as continuous hygiene.
Leave a Reply