📋 STIG Hardening Without Locking Yourself Out: An OpenSCAP Remediation Workflow

The fastest way to fail a DISA STIG hardening project is to succeed at it too literally. Run an OpenSCAP scan against a working system, see a few hundred failed rules, pipe the datastream’s remediation content straight into the box, and reboot — and there is a real chance you have just locked yourself out over SSH, broken the application you were hardening, or both. STIG remediations are aggressive by design: they tighten ciphers, disable services, enforce restrictive mount options, and reshape account policy, and some of those fixes are exactly the ones that sever your own access. Hardening to a STIG is not a bulk operation. It is a triage-and-stage discipline, and that is what this workflow covers.

A Raw Scan Is a List of Suspects, Not a To-Do List

When you run oscap against a system that is currently doing useful work, the failed-rules list conflates three very different things:

oscap xccdf eval \
  --profile xccdf_mil.disa.stig_profile_stig \
  --results-arf arf.xml --report report.html \
  /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

Some of those failures are genuine gaps you should fix. Some are controls that are actually met another way OpenSCAP cannot observe — a network control enforced at a firewall the scanner does not see, for instance. And some are fixes that would break a function the system is required to perform, which means they belong in a documented deviation, not a remediation. Treating all three as “fix it” is how box-checking produces both outages and audit failures.

Triage Into Three Buckets

Before touching anything, sort each failed rule:

• True failure to fix — a real gap with a safe remediation. Most rules.
• False positive / met elsewhere — the control objective is satisfied by a compensating mechanism the scanner cannot see. Document why; do not “fix” it into a regression.
• Documented deviation — the prescribed fix would break a required function. Accept the risk formally, with a justification and a compensating control.

That third bucket is where compliance maturity shows. An undocumented deviation fails an audit exactly as surely as an unremediated finding — the auditor does not care whether you skipped a control by accident or on purpose, only whether the decision is recorded and justified. Drafting that justification is real work, and it is part of the remediation, not an afterthought.

Blast Radius Is the Field That Saves You

For every remediation you intend to apply, the most important annotation is not the rule ID — it is what operationally changes. STIG fixes cluster into a few high-blast-radius categories that deserve special handling:

• SSH and crypto policy — tightening ciphers, MACs, and key exchange can drop your current session’s compatibility or lock out clients. The fix that hardens SSH is the fix that can lock you out of the box.
• PAM and account policy — lockout thresholds, password complexity, and account expiry can lock out users, including you.
• Firewall and services — disabling a service or default-deny on a port can sever the very access path you are using.
• Mount options — noexec, nosuid on partitions can break applications that legitimately need those.

The rule of thumb: any change to how you reach the machine gets validated on a second, independent session before you commit it.

# Apply the new sshd hardening, then VALIDATE on a separate connection BEFORE reloading.
sshd -t                       # syntax check the new config
# Open a SECOND ssh session and confirm you can authenticate with the new settings.
# Only then:
systemctl reload sshd

That second-session check is the single habit that prevents the most common and most painful STIG self-inflicted outage.

Use SCAP Fix Content as a Draft, Not a Hammer

The SSG datastreams ship remediation content — bash and Ansible — generated to satisfy each rule. It is genuinely useful, but it is blunt: it applies the prescriptive fix without knowing your system’s role. For low-blast-radius rules (file permissions, sysctl values, audit rules), the generated fix is usually safe to apply directly. For the high-blast-radius categories above, treat it as a starting point to read and tailor — the same way you would treat any generated CIS-style hardening content. Never auto-apply the full fix set blindly to a production system that is currently working.

Sequence, Window, and Re-Scan

Order the remediations so the dangerous ones come last and behind a validation step, and mark which need a maintenance window or a reboot (kernel parameters, mount-option changes, some PAM changes). Apply the safe bulk first, validate access-affecting changes individually, then re-scan to confirm the score moved without regressions:

oscap xccdf eval \
  --profile xccdf_mil.disa.stig_profile_stig \
  --results-arf arf-after.xml --report report-after.html \
  /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

The re-scan is not just a victory lap — it catches the case where a fix you applied tripped a different rule, which happens more than you would expect when controls interact.

AI for Triage and Deviation Drafting

The triage-and-blast-radius pass is exactly the kind of structured judgment a model accelerates, and the deviation justifications are tedious to write by hand — both are good to draft with AI and verify yourself:

Prompt: “Triage these failed OpenSCAP STIG rules for an internet-facing RHEL 9 web server that must keep serving HTTPS and allow admin SSH from a bastion. For each: classify as fix / false-positive / documented-deviation with the deciding fact, and state the operational blast radius. Flag any rule that could sever my SSH or break HTTPS. For deviations, draft an auditor-grade justification with a compensating control. Don’t tell me to bulk-apply the fix content.”

Output (excerpt): “Rule (sshd Ciphers): FIX, but HIGH blast radius — restricting to FIPS ciphers may drop older clients; validate on a second session before reload. Rule (disable firewalld http): DEVIATION — this server must serve HTTPS; document deviation, justification: ‘host’s required function is public HTTPS; port 443 governed by an explicit allow rule and fronted by a WAF’ (compensating control). Rule (audit rules missing): FIX, LOW blast radius — safe to apply from SCAP content directly.”

The model’s blast-radius flags and draft justifications save real time, but you stage the changes, run the second-session checks, and own every accepted deviation — the AI drafts, you verify. For a full structured pass over your scan with the lockout checks and deviation drafting built in, the STIG OpenSCAP remediation prompt triages each rule and orders the remediation so you do not lock yourself out of your own server.