redcap-compliance — Hardening baseline audits

redcap-compliance — Hardening baseline audits

Wraps ComplianceAsCode/content — the Red Hat-maintained upstream source of truth for SCAP / STIG / CIS / PCI-DSS / OSPP hardening rules. Covers RHEL, Fedora, Ubuntu, Debian, SUSE, and generic Linux.

Prerequisites

The skill expects the fork cloned to:

~/Documents/GitHub/content

Optional: for live SCAP evaluation, install OpenSCAP:

# macOS
brew install openscap
# Debian / Ubuntu
sudo apt install libopenscap8 ssg-base ssg-debian
# RHEL / Fedora
sudo dnf install openscap-scanner scap-security-guide

Live SCAP evaluation is optional — the skill can work purely from ComplianceAsCode source (reading YAML rule files) even when OpenSCAP isn't installed.

Corpus structure

content/
├── products/                       # per-product config
│   ├── rhel9/, rhel10/, ubuntu2404/, fedora/, sle15/, ...
├── controls/                       # named control frameworks
│   ├── stig_rhel9.yml, cis_rhel9_l1.yml, cis_rhel9_l2.yml, pci-dss_3.2.1.yml, ...
├── shared/
│   ├── references/                 # cross-references (NIST, PCI, etc.)
│   ├── templates/                  # shared rule templates
│   └── checks/                     # OVAL / shell / ansible checks
├── linux_os/guide/                 # the big rule tree
│   └── <category>/<subcategory>/<rule>/
│       ├── rule.yml                # description, CCE, severity, check, fix
│       ├── oval/                   # OVAL check logic
│       ├── bash/                   # bash remediation
│       └── ansible/                # ansible remediation
└── docs/

Each rule has:

• title / description — what the rule requires
• rationale — why the rule exists
• severity — high / medium / low / unknown
• CCE / CCI / NIST / STIG / CIS references — cross-map to other frameworks
• OVAL check — machine-readable verification
• Bash / Ansible fix — machine-readable remediation

Workflow

Use case A — "What's the hardening baseline for X?"

# Find relevant product
ls ~/Documents/GitHub/content/products/

# Find control profile
ls ~/Documents/GitHub/content/controls/ | grep -i <framework>

# Read the profile
head -200 ~/Documents/GitHub/content/controls/stig_rhel9.yml

Summarize top-severity rules for the user. Cite CCE / STIG IDs so they can cross-reference.

Use case B — "Audit this system config against a baseline"

1. Identify the target's product family (e.g., rhel9, ubuntu2404, generic).
2. Pick a profile (stig, cis_l1, cis_l2, pci-dss, ospp, usgcb).
3. For each rule in the profile:
   • Read rule.yml for the check logic
   • Run the check against the target (Bash / OVAL / Ansible where available)
   • Record PASS / FAIL / NOT_APPLICABLE + any context
4. Emit a deviation report (see format below).

Live evaluation with OpenSCAP:

oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_stig \
  --results results.xml \
  --report report.html \
  /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

Or offline rule-by-rule against extracted system config using the Bash checks in content/linux_os/guide/.../bash/.

Use case C — "Compare an owned device's exposed config to baselines"

For a consumer device (router, IoT, hotspot, embedded system) running Linux:

1. Pull the device's config via its admin API / shell / firmware unpack (if accessible).
2. Map its config knobs to the nearest Linux baseline rules. Even if the device isn't technically RHEL or Ubuntu, many web admin, firewall, and logging rules apply.
3. Flag gaps: insecure defaults, missing firewall, disabled logging, weak TLS, default credentials, etc.
4. Present as a device security audit — suitable for consumer-rights reporting or public disclosure (redact device-specific secrets first).

This pairs with redcap-kernel on unpacked firmware: after unpacking, cross-check /etc/, /lib/systemd/, /var/log/ config against the nearest appropriate profile.

Use case D — "What should this system look like if it were hardened?"

Reference query — no target to audit. Walk the relevant profile, extract high-severity rules, present as a hardening checklist.

Deviation report format

## Hardening deviation report — <target> vs. <profile>

**Profile:** stig_rhel9 (DISA STIG for RHEL 9)
**Target:** <hostname / device>
**Date:** <date>
**Total rules evaluated:** <n>

### Summary

| Severity | Pass | Fail | Not Applicable |
|---|---|---|---|
| High | 12 | 3 | 1 |
| Medium | 28 | 7 | 4 |
| Low | 42 | 5 | 6 |

### Failures (sorted by severity, high first)

#### HIGH — CCE-86207-9 — "Ensure SSH does not permit root login"

- **STIG ID:** RHEL-09-255040
- **Source:** `linux_os/guide/services/ssh/ssh_server/sshd_disable_root_login/rule.yml`
- **Observed:** `PermitRootLogin yes` in `/etc/ssh/sshd_config`
- **Expected:** `PermitRootLogin no`
- **Remediation:** `sed -i 's/^PermitRootLogin .*/PermitRootLogin no/' /etc/ssh/sshd_config && systemctl restart sshd`
- **Rationale:** Root SSH login bypasses individual user accountability and is a common attack vector. Disabling it forces users to authenticate as themselves and use sudo for privileged actions.

(...additional failures...)

### Recommendations

1. Apply all HIGH remediations immediately.
2. Review MEDIUM failures against the target's operational constraints.
3. Re-audit after remediation to confirm.

Pairing with other siblings

• redcap-kernel: unpack a firmware dump, then audit its on-disk config against a relevant baseline — find deviations BEFORE the device is deployed (useful for consumer-device security-audit reports).
• redcap-payloads: for each failed auth / access-control rule, correlate to known attack payloads that exploit that specific gap. Builds a "what would have blocked this?" narrative for post-engagement reports.
• redcap-droid: if the baseline covers Android-adjacent rules (MDM, CIS mobile), apply them to a decompiled APK's AndroidManifest + network-security-config.
• redcap-gpt: after a successful engagement, map each exploit used to the baseline rule that would have blocked it — feedback loop for the target's defenders.

Safety

• This skill READS baselines and applies them to targets. It does not modify targets unless the user explicitly runs a remediation script.
• Remediation scripts from ComplianceAsCode are IDEMPOTENT and well-tested, but always review the fix before running against production. A remediation that disables a service may interrupt legitimate workloads.
• oscap can be run as a non-root user for read-only scans. Only run as root when applying remediation.