Security Function Isolation SC-3
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-3 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-3 (Security Function Isolation) goes a step beyond SC-2. It asks that the parts of the system that enforce security — the access-control checks, the security-relevant code, and its configuration — be kept isolated from the ordinary, non-security parts, so that a bug or compromise in general software cannot reach in and tamper with the security machinery. It is an SC (System and Communications Protection) control in the High baseline, usually met by the operating system’s own design plus the boundaries you keep intact.
What good looks like
- Keep security-enforcing components separated from general application code — rely on the kernel’s boundary between kernel space and user space, and do not weaken it.
- Enforce least privilege so ordinary processes cannot read or change security functions or their configuration.
- Run a mandatory access control (MAC) layer — SELinux (Security-Enhanced Linux) or AppArmor — to confine services so a compromised application cannot reach security-relevant files.
- Protect the integrity of the security functions: restrict who can change files under paths like
/etc/selinux,/etc/sudoers, and the loaded kernel module set. - Do not run untrusted or general-purpose workloads in the same trust domain as security functions — isolate them with separate accounts, containers, or hosts.
Framework mapping
- NIST CSF 2.0 — PR.PS-03 — Hardware is maintained, replaced, and removed commensurate with risk
- CIS Controls v8 — Control 3 — Data Protection
How to move it toward Implemented
- Check that a MAC layer is enforcing —
sestatusfor SELinux oraa-statusfor AppArmor — and switch it from permissive or disabled to enforcing if needed. - Verify ownership and permissions on the security-relevant files (
/etc/sudoers,/etc/selinux/) and confirm no world-writable path holds security configuration. - Separate or confine general workloads so they do not share a trust domain with security functions (dedicated service accounts, containers, or a separate host), and save the MAC status and permission checks as one dated file.
- Attach that dated file as hardening evidence on the asset, naming
SC-3in the Requirement field — that moves it from ‘To assess’ toward ‘Completed’.