Denial-of-service Protection SC-5

System and Communications Protection · Low 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-5 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-5 (Denial-of-Service Protection) is about keeping the system available when someone — or something — tries to overwhelm it. A denial-of-service (DoS) event floods a machine with traffic or requests until real users cannot get through. This control asks you to decide which DoS event types matter to you and to put concrete protections in place to blunt them. It is an SC (System and Communications Protection) control in the Low baseline.

What good looks like

Decide which DoS event types you are protecting against — a traffic flood, connection exhaustion, a resource-hungry request — and write them down.
Limit the blast radius with rate limits and connection caps so one source cannot consume everything.
Use boundary protection — a host firewall and, where available, upstream filtering — to drop obvious flood traffic before it reaches services.
Cap resource use per process and per user so a runaway or hostile workload cannot starve the whole box.
Monitor for the early signs (spiking connections, CPU, or memory) so you notice an attack rather than only its aftermath.

Framework mapping

NIST CSF 2.0 — PR.IR-01 — Networks and environments are protected from unauthorized logical access and usage
NIST CSF 2.0 — DE.CM-01 — Networks and network services are monitored to find potentially adverse events

How to move it toward Implemented

Turn on host-firewall rate limiting for exposed ports — for example, ufw or nftables limit rules, or iptables -m limit — to throttle connection floods.
Set per-process and per-user resource caps with systemd limits (TasksMax, MemoryMax) or /etc/security/limits.conf so no single workload starves the box.
Enable kernel flood defenses such as TCP (Transmission Control Protocol) SYN cookies (net.ipv4.tcp_syncookies=1 in /etc/sysctl.conf), and save the firewall rules, resource limits, and sysctl values as one dated file.
Attach that dated file as hardening evidence on the asset, naming SC-5 in the Requirement field — that moves it from ‘To assess’ toward ‘Completed’.