How would you build a DDoS incident response runbook?

Question

Accepted Answer

A DDoS runbook turns panic into a checklist. Its core principle: **prepare before the attack, not during it** — accounts provisioned, contacts known, and dashboards built, so the response is execution, not improvisation.

## Prepare in advance

- Have a **CDN/scrubbing provider already integrated** (DNS pointed through it, an "under attack" mode you can flip).
- Keep **baseline dashboards and alerts** for traffic, error rate, and cache-hit ratio so anomalies surface fast.
- Pre-write **WAF rules and rate-limit tiers** you can tighten instantly.
- Maintain a **contact list**: on-call, CDN/ISP support, leadership, and a ready **status-page** template.

## The runbook steps

1. **Detect and declare** — an alert or correlated anomaly (see DDoS detection) triggers an incident. Assign an incident commander immediately.
2. **Identify attack type and target** — is it Layer 3/4 (volumetric) or Layer 7 (HTTP flood)? Which endpoint, IP, or region? The type dictates which controls you engage.
3. **Engage defenses** — turn on CDN "under attack" mode / scrubbing, **tighten WAF rules**, and **lower rate limits**. Start with the cheapest, broadest controls.
4. **Block / null-route sources** — block offending IP ranges or geos at the edge; as a last resort, ask the ISP to **null-route** the targeted IP to save the rest of the platform.
5. **Communicate** — post to the **status page**, update stakeholders, and keep a timeline. Clear comms prevents a second crisis of confusion.
6. **Scale if needed** — autoscale or overprovision origin capacity to absorb traffic that gets through while filters tighten.
7. **Post-incident review** — once stable, run a blameless retro: what worked, what was slow, which rules to make permanent, and which gaps to close.

```text
DETECT -> IDENTIFY -> ENGAGE (CDN/WAF/rate-limit) -> BLOCK/null-route
       -> COMMUNICATE -> SCALE -> POST-INCIDENT REVIEW
```

## Why it matters

Under a real attack, latency and adrenaline make people skip steps and make things worse. A runbook gives a known sequence, pre-built tooling, and clear roles, so the team mitigates in minutes instead of debating options while the site is down. The most valuable line in any DDoS runbook is the preparation done beforehand — you cannot integrate a scrubbing provider or find the ISP's emergency number while you are being flooded.