Session Authenticity SC-23

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-23 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-23 (Session Authenticity) is about protecting the authenticity of a communications session — making sure the far end of a connection really is who it claims to be, and that the session cannot be hijacked, replayed, or quietly intercepted in the middle. It is a System and Communications Protection control that appears at the Moderate baseline.

What good looks like

Carry every session over a strong, authenticated channel — TLS (Transport Layer Security) for web and application traffic, SSH (Secure Shell) for administration — so both ends are verified, not just encrypted.
Verify the identity behind the session: a valid TLS certificate for servers, a known host key for SSH, so a client cannot be tricked into talking to an impostor.
Give each session a unique, server-generated identifier, and invalidate it at logout (enhancement SC-23(1)) so a stolen token cannot be reused.
Refuse weak or legacy protocol versions and ciphers that allow a downgrade or replay attack.
Protect session tokens and cookies in transit and in storage — for web sessions set Secure, HttpOnly, and SameSite on cookies.

Framework mapping

CIS Controls v8 — Control 12 — Network Infrastructure Management

How to move it toward Implemented

Enforce modern protocols only: set ssl_protocols TLSv1.2 TLSv1.3; (and a strong cipher list) in /etc/nginx/nginx.conf, then confirm with nmap --script ssl-enum-ciphers -p 443 <host>.
Harden the SSH session crypto in /etc/ssh/sshd_config (strong KexAlgorithms, Ciphers, and MACs), reload sshd, and dump the effective settings with sshd -T.
For application sessions, issue a fresh server-side session identifier on login and destroy it on logout; mark cookies Secure; HttpOnly; SameSite=Strict.
Attach that server config together with the scan output showing only strong protocols and ciphers as hardening evidence on the asset, naming SC-23 in the Requirement field — that moves it from ‘To assess’ toward ‘Completed’.