Separation of System and User Functionality SC-2

System and Communications Protection · Moderate 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-2 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-2 (Separation of System and User Functionality) says keep the administrative side of a system apart from the everyday user side. The tools and interfaces used to manage the machine — the privileged, system-management functions — should be separated, physically or logically, from the interfaces that ordinary users touch, so that simply using the system does not hand someone the controls to run it. It is an SC (System and Communications Protection) control in the Moderate baseline.

What good looks like

Separate management functions from user functions so ordinary use never exposes administrative tools — use different accounts, interfaces, ports, or hosts.
Perform administration through privileged, separately authenticated paths — for example, an admin signing in with their own account and elevating with sudo — not through the same interface end users get.
Keep management interfaces off the general user network where you can: bind them to an internal or management address rather than a public one.
On this Linux server that means no routine work as root — people use named accounts, and administrative actions are elevated deliberately.
Where a service ships a web admin console, place it on a separate address, port, or virtual host with its own access control.

Framework mapping

How to move it toward Implemented

Confirm interactive root login is off (PermitRootLogin no in /etc/ssh/sshd_config) and that admins use their own accounts plus sudo.
Keep the set of people who can elevate small, and review it with getent group sudo, removing anyone who no longer needs it.
Bind management services (a database, an admin UI) to 127.0.0.1 or a management interface rather than 0.0.0.0, firewall the admin port to trusted sources, and save the sshd_config excerpt, the group listing, and an ss -tlnp capture as one dated file.
Attach that dated file as hardening evidence on the asset, naming SC-2 in the Requirement field — that moves it from ‘To assess’ toward ‘Completed’.