Security and Privacy Function Verification SI-6

System and Information Integrity · High baseline ✗ Not implemented

Status — program-wide

What references this control

No risks name this control in their Framework field yet.

No policies reference it yet.

Link a risk or policy to this control

Attaching adds SI-6 to the item's Framework field; the ✨ AI button suggests the best match. You can also edit the Framework field on a risk / policy directly.

Source: NIST SP 800-53 Rev.5, System and Information Integrity family NIST SP 800-53 Rev.5. The baseline shows the lowest SP 800-53B baseline (Low / Moderate / High) this control appears in NIST SP 800-53B.

Control guide — plain-English, per NIST SP 800-53

SI-6 (Security and Privacy Function Verification) asks a simple question: are your security controls actually working right now, or do you just assume they are? You pick the functions that matter, test that they operate correctly on a schedule or at set events, alert someone when a test fails, and decide what the system does on failure. It is a technical, hands-on control, and it sits in the High baseline — aimed at the most sensitive systems.

What good looks like

Pick the security functions to verify — for example, the host firewall, the mandatory access control layer (AppArmor or SELinux), time sync, and logging.
Test that each one is really operating, not just installed — a running service can still be misconfigured or quietly disabled.
Run the checks on a schedule (for example, daily by cron) and also at key events like startup or after a change.
Alert a named person when a verification test fails, so a broken control does not stay broken quietly.
Decide the failure action up front — log and alert, restart the function, or in the strictest cases shut the system down.

Framework mapping

How to move it toward Implemented

Write a small verification script that checks the key functions — for example ufw status verbose, aa-status (or sestatus), timedatectl, and systemctl is-active auditd — and exits non-zero on any failure.
Schedule it with cron and have a failure send mail or write to /var/log/, so someone is alerted rather than the check failing silently.
Run it once by hand and save the dated output showing each function passing.
Attach that verification output as hardening evidence on the asset, naming SI-6 in the Requirement field — that moves it from ‘To assess’ toward ‘Completed’.