NIST SP 800-53 hardening guide

Date: 2026-10-20 Version: 1.0 Check it: neuralmind hardening [project_path] [--json] (v4.19.0+)

1. What this is

SP800-53.md says which SP 800-53 Rev. 5 controls NeuralMind touches and what stays yours. This page is the configuration that goes with it: 17 rules, each tied to the controls it supports, that together put NeuralMind in its hardened state on one host. It is your CM-6 baseline for NeuralMind; adopt it as is, or record each deviation in your System Security Plan.

Every rule is checked automatically. neuralmind hardening reads the settings as NeuralMind enforces them (the machine policy included), the volume and the OS FIPS mode, the audit log and its checkpoints, forwarding, and the running daemon, and reports each rule:

$ neuralmind hardening /srv/app
NeuralMind SP 800-53 hardening baseline — /srv/app
============================================================
  [pass] NMH-01 The hardened profile is on (CM-6, CM-7, SC-8)
         security.profile: cui
  ...
  [FAIL] NMH-09 Checkpoint signing runs in a FIPS-mode OpenSSL (SC-13, AU-9(3))
         checkpoint signing runs in OpenSSL 3.5.4 without FIPS mode; ...
         -> pip install --force-reinstall --no-cache-dir --no-binary cryptography cryptography, ...
============================================================
16 of 17 rule(s) pass; 1 fail.

• Exit codes: 0 when every rule passes (or doesn’t apply on this platform: the permission rules on Windows, the OS FIPS mode on macOS), 1 when any fails.
• A rule that can’t be checked fails. An OS FIPS mode that can’t be read, or a volume whose encryption can’t be verified, is not a pass.
• --json prints the baseline name, the NeuralMind version, the project, pass/fail counts and each rule’s id, title, controls (OSCAL control IDs such as au-9.3), status (pass, fail, n/a), detail and fix. Keep it as assessment evidence.
• Run it as the account that runs NeuralMind, on each host, on a schedule (CA-7), and after each upgrade. It reads and writes nothing in the project.

neuralmind doctor already reports most of these, as warnings sized for a developer. hardening is the stricter baseline for an authorized system: every rule here must pass.

2. The baseline

3. Setting it up

On a Linux host, as root, then as the administrator who holds the checkpoint key. The CUI enclave walkthrough has the same steps with more on each, and Windows equivalents.

# NMH-01, NMH-02: the profile, machine-wide
sudo mkdir -p /etc/neuralmind
printf 'security:\n  profile: cui\n' | sudo tee /etc/neuralmind/policy.yaml
sudo chmod 755 /etc/neuralmind && sudo chmod 644 /etc/neuralmind/policy.yaml

# NMH-08: the OS FIPS mode (RHEL 9; reboot after)
sudo fips-mode-setup --enable

# NMH-09: checkpoint signing in the system OpenSSL
pip install --force-reinstall --no-cache-dir --no-binary cryptography cryptography

# NMH-13, NMH-14: the checkpoint key and the anchor directory (administrator)
neuralmind audit keygen /home/admin/.neuralmind/audit-key.pem   # prints the public key
sudo install -d -o admin -m 755 /var/lib/neuralmind-anchor

The project file, writable by its owner only (NMH-05):

# neuralmind-backend.yaml
security:
  profile: cui
  users:
    alice: builder
    bob: reader
  audit_checkpoint_key: MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE...   # from audit keygen
  audit_anchor_dir: /var/lib/neuralmind-anchor
  audit_syslog: /dev/log

Then point the host’s syslog daemon at the SIEM over TLS (the rsyslog example is in the security guide), schedule neuralmind audit checkpoint /srv/app --key /home/admin/.neuralmind/audit-key.pem daily from the administrator’s account, and run neuralmind hardening /srv/app.

4. Checked by you

These are part of the hardened state, and NeuralMind can’t see them, so hardening doesn’t check them:

Related

• SP 800-53 controls and what stays yours, and the OSCAL component definition
• NIST: what applies, where it stands, what’s next
• Security guide
• CLI reference: hardening
• Use NeuralMind in a CMMC CUI enclave