SC-5 asks you to protect against, or limit the effects of, the types of denial of service events you define, and to employ specific controls to meet that objective. You choose the event types and the controls. That flexibility is also the trap, because a vague answer gives an auditor nothing to test.
800-53 binds US federal systems and contractors. For a small or mid size company it is the reference behind questions about DDoS protection and availability commitments.
What it means in practice
NIST notes that these events have internal and external causes. An adversary is one. A lack of planning for capacity and bandwidth is another. Your own marketing launch can look exactly like an attack.
The guidance names two families of defense. Boundary protection devices can filter certain packets so internal components are not hit directly, and are not used to attack others. Added network capacity and bandwidth combined with service redundancy reduce susceptibility. It also notes attacks can use any protocol, including IPv4 and IPv6.
Three enhancements give structure:
- SC-5(1) Restrict Ability to Attack Other Systems, which limits what your systems can send out if compromised.
- SC-5(2) Capacity, Bandwidth, and Redundancy.
- SC-5(3) Detection and Monitoring.
Evidence to collect
- A written list of the denial of service scenarios you plan for, such as volumetric floods, application layer request floods, and resource exhaustion by one customer.
- Configuration of a DDoS protection service, content delivery network or web application firewall with rate limits.
- Auto scaling and redundancy design: multiple zones, health checks, capacity headroom.
- Load test results showing the system behavior at multiples of normal traffic.
- Monitoring and alert rules for traffic and error rate spikes.
- Egress filtering rules that stop your servers from joining an attack.
- A runbook for responding, and the record of any past event.
Common gaps
Protection at the website but not the API or the DNS. A single region or a single database that all traffic depends on. Rate limits applied per IP only, so a distributed flood passes. Alerts that go to a mailbox nobody reads at night. A runbook that has never been practiced. No egress filtering, so a compromised host can attack others.
How to implement it
- List what must stay available and what dependencies it has, including DNS and identity.
- Put a filtering layer in front of public endpoints and set rate limits per client, per key and per endpoint.
- Add redundancy across zones and keep headroom. Load test twice a year.
- Restrict outbound traffic from servers to what they need.
- Alert on traffic anomalies and saturation, and route alerts to a person who can act.
- Write the runbook: who decides, how to turn on stricter filtering, how to talk to customers.
Detection is the part teams skip. The continuous monitoring demo shows how checks that run all the time make evidence easier to produce.
Click through it at your own pace, or open it full screen.
Quick check
Can a denial of service happen without an attacker?
Yes. NIST lists a lack of planning for capacity and bandwidth as a cause.
Which enhancement covers monitoring?
SC-5(3), Detection and Monitoring.
