Fail in Known State SC-24

System and Communications Protection · 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 SC-24 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 Communications Protection 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

SC-24 (Fail in Known State) is about how the system behaves when something breaks. Rather than failing open in an unpredictable way, or losing important data, the system should fail into a defined, safe, known state — and preserve the state information you decided matters. It is a System and Communications Protection control reserved for the High baseline, where the cost of an unpredictable failure is highest.

What good looks like

Decide in advance what your known state is. For most security functions that means fail closed (deny access) rather than fail open.
Name the failures that trigger it — power loss, a crashed service, a full or faulty disk, a kernel panic — and the state information that must survive, such as logs and in-flight records.
Make services come back in a safe posture, not a degraded-but-open one.
Preserve evidence: make sure logs and critical state are written to durable storage before or during the failure.
Test the failure paths. A known-state design you never exercise is only a guess.

Framework mapping

NIST CSF 2.0 — PR.IR-03 — Mechanisms are implemented to achieve resilience requirements in normal and adverse situations

How to move it toward Implemented

Make the firewall fail closed: set the default policy to drop in nftables (nft ... policy drop) or iptables so a rule-load failure leaves the host closed rather than open.
Have the filesystem fail to a safe state: add errors=remount-ro to the mount options in /etc/fstab so a disk error remounts read-only instead of corrupting further.
Preserve logs across a crash: set Storage=persistent in /etc/systemd/journald.conf, and use a systemd OnFailure= unit to alert and move a failed service to a defined safe state.
Rehearse it: stop the service or simulate a disk error, then confirm the host lands closed and the logs survived, and save that test transcript.
Attach those unit and mount configs together with the failure-test transcript as hardening evidence on the asset, naming SC-24 in the Requirement field — that moves it from ‘To assess’ toward ‘Completed’.