DISA STIG OpenSCAP Remediation Triage Prompt
Triage an OpenSCAP STIG scan — separate true failures from false positives and accepted-risk findings — and produce reviewed remediation with the operational blast radius of each fix called out.
- Target user
- Compliance and platform engineers hardening Linux to a DISA STIG baseline who must justify every deviation
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT
The prompt
You are a senior systems-security engineer who hardens Linux to DISA STIG baselines and writes the documented deviations auditors accept, balancing compliance against keeping the system functional. I will provide: - The OpenSCAP/oscap results (XCCDF/ARF or a sample of failed rules) — [SCAN RESULTS] - The STIG/SCAP profile and OS — [PROFILE + OS] - The system's role (workload, network exposure, what it must keep doing) — [SYSTEM ROLE] - Any existing waivers or organizational tailoring — [TAILORING] Your job, step by step: 1. **Triage each failed rule** — classify as: true failure to fix, false positive (the control is met another way oscap can't see), or candidate for documented deviation (the fix would break a required function). State the deciding fact for each. 2. **Call out blast radius** — for every remediation, state what operationally changes: STIG fixes routinely tighten SSH ciphers, disable services, set restrictive mount options, and enforce password policy in ways that lock out users or break apps. Flag the high-blast-radius ones (e.g. ones that could sever your own access) explicitly. 3. **Sequence safely** — order remediations so you do not lock yourself out (e.g. validate new SSH config on a second session before reloading), and mark which ones require a maintenance window or a reboot. 4. **Remediation form** — give the fix as the relevant config/command, and note where the SCAP `fix` content (Ansible/bash from the datastream) can be used versus where it is too blunt and needs tailoring. 5. **Document deviations** — for each accepted-risk finding, draft the justification and compensating control an auditor would accept, mapped to the rule ID. 6. **Re-scan plan** — give the oscap command to re-evaluate and confirm the score moved without regressions. Output as: (a) the triage table (rule ID, classification, deciding fact, blast radius), (b) the ordered remediation steps with windows/reboots marked, (c) drafted deviation justifications, (d) the re-scan command. Present as a remediation plan for review before any change — never apply an SSH or auth hardening rule without the lockout check, and never auto-apply the full SCAP fix content blindly.
Why this prompt works
A raw OpenSCAP STIG scan against a working system returns a long list of failures, and the naive response — bulk-apply the datastream’s fix content — is how teams lock themselves out of production or break the app they were hardening. STIG rules tighten SSH ciphers, disable services, and enforce restrictive mount and account policies, and some of those are exactly the fixes that sever your own access. This prompt makes blast radius a first-class output, flagging the high-risk remediations before anything is touched.
The triage discipline is what separates real STIG work from box-checking. Not every failed rule is a true failure: some controls are met another way oscap cannot see, and some fixes would break a required function and belong in a documented deviation instead. The prompt forces that three-way classification with a deciding fact per rule, and — critically for compliance — drafts the auditor-grade justification and compensating control for each accepted-risk finding, because an undocumented deviation fails an audit just like an unremediated one.
The senior framing carries the safety posture: validate SSH and auth changes on a second session before reloading, sequence to avoid lockout, and never auto-apply bulk SCAP fix content blindly. The result is a reviewable remediation plan with windows and reboots marked and a re-scan command to confirm progress — a draft a human stages and verifies, which is the only safe way to harden a system that is currently doing its job.