#14.8 DDoS and Service Unavailability

Playbook ID: PB-DDOS | Default severity: SEV-2 (escalate to SEV-1 if a revenue-generating or safety-relevant service is fully unavailable, if shared infrastructure such as DNS or the identity provider is targeted, or if any concurrent intrusion indicator appears) | Owner: Operations Lead

#When to run this

Availability degrades and the cause is inbound traffic rather than your own change. Triggers:

• External synthetic checks fail from three or more geographies while internal health checks on the same service pass.
• Your edge or scrubbing provider raises an attack event — a Cloudflare DDoS Overview spike, an AWS Shield Advanced CloudWatch alarm, an Azure DDoS Protection metric breach.
• Edge request rate, packets-per-second or bandwidth departs from baseline by an order of magnitude while application error rates stay flat. The app is fine; it just cannot be reached.
• Your ISP calls you — often the first signal for an organization with no scrubbing contract.
• An extortion note demands payment to stop or prevent an attack.
• DNS, VoIP or firewall unavailability, which CISA counts as DDoS symptoms alongside web outage (CISA/FBI/MS-ISAC, March 2024).

Not this playbook: an outage from your own deploy or capacity miss (change management). Ransomware-driven unavailability → 14.1. Resource exhaustion from exploitation of an application flaw → 14.13, or of a perimeter appliance → 14.12. If the flood turns out to be the visible half of an intrusion, run both playbooks in parallel — not one after the other.

#What you are dealing with

DDoS is the one attack class where the adversary needs no cleverness or patience. They need capacity, and capacity is now cheap and enormous. Cloudflare mitigated 47.1 million DDoS attacks in 2025, averaging 5,376 an hour, and the largest peaked at 31.4 Tbps and lasted 35 seconds (Cloudflare Q4 2025). Thirty-five seconds. Your on-call engineer has not finished reading the page alert.

That is not an outlier, it is the shape of the problem: 71% of HTTP DDoS attacks and 89% of network-layer attacks end in under ten minutes (Cloudflare Q3 2025). If your response depends on waking someone for approval, the attack ends before the approval lands — and returns tomorrow on a different vector. CISA sorts the technique space three ways, and the distinction drives what you do next: volumetric (saturate the pipe), protocol (exhaust state on firewalls, balancers and hosts — SYN floods, reflection/amplification), and application-layer (cheap requests that buy expensive work). Layer 7 is the one your bandwidth graph will not show you: small, indistinguishable from customers, and able to "critically overload CPUs and databases" (CISA DDoS Quick Guide). Map as T1498 Network Denial of Service, T1498.001 Direct Network Flood, T1498.002 Reflection Amplification.

Now the mistake, and it is why this playbook sits in a book about intrusion response. A DDoS is a very loud thing to have happening to you, and loud is useful cover. CISA states these attacks "can be launched in conjunction with other types of attacks"; ransomware crews list DDoS as a standard triple-extortion pressure layer beside exfiltration (BleepingComputer). Pulling a fire alarm empties a building, but it is an even better way to walk out the back with the safe while everyone stands in the car park counting heads. Every responder staring at a traffic graph is a responder not watching the identity plane. Actionable takeaway: the first structural decision here is not a mitigation setting. It is splitting the team, and you make it at T+10m.

#Roles for this incident

Two markers in the tables. TIP-OFF — observable by whoever is attacking you; it tells them which control landed and what to change. EVIDENCE — reshapes or ages out the traffic evidence; the preceding capture step must be complete first.

#Phase 1 — Detection and Triage

# What does the public world resolve to, from an off-net resolver?
dig +short A app.example.com @1.1.1.1

# Is the origin answering directly — i.e. is the edge being bypassed?
# A 200 here means your CDN is optional to the attacker.
curl -sS -o /dev/null -w '%{http_code} %{time_total}s\n' \
  --resolve app.example.com:443:<origin-ip> https://app.example.com/

# Half-open connections on a suspected SYN-flood target (Linux origin or LB)
ss -tan state syn-recv | wc -l

# Bounded evidence capture. -s 96 keeps headers only; -c bounds the file
# so a flood cannot fill the evidence disk.
tcpdump -n -i eth0 -s 96 -c 200000 -w /evidence/ddos-$(date -u +%Y%m%dT%H%M%SZ).pcap

#Phase 2 — Containment

Order is deliberate: cheapest-for-legitimate-users first, most user-hostile last. Reversing it breaks your own customers before you have tried the controls that would not have.

#Phase 3 — Eradication

No malware to remove. Eradication here means taking away the leverage — the exposed origin, the amplifiable service, the expensive endpoint — and closing the intrusion question.

#Phase 4 — Recovery

#Phase 5 — Post-Incident

#Decision points

#Communications and notification triggers

A pure availability event usually does not start a personal-data breach clock. Three other clocks may already be running.

• Contractual. Customer SLAs and uptime commitments carry their own notification windows and service-credit triggers. Legal Liaison pulls the affected contracts at T+1h, not at the post-mortem.
• Sector and regulator. Financial, healthcare, telecom and critical-infrastructure operators frequently sit under availability-incident reporting obligations distinct from data-breach rules, and materiality-based securities disclosure can be triggered by significant operational disruption. Chapter 15 holds the matrix. Use it; do not reason from memory at 03:00.
• The one that catches people. If the Intrusion Watch finds unauthorized access, the breach clock starts from that discovery, not from the moment the flood stopped.

Externally, publish what customers can act on: which services are affected, whether their data is involved (say "no evidence of data access" only if the Intrusion Watch supports it), and when the next update comes. Never publish which vector you filtered or which control you applied — that is tuning notes for the person attacking you.

#Automation notes

With 71% of HTTP and 89% of network-layer attacks finishing inside ten minutes, a mitigation gated on a human approval arrives after the incident. Automation is not an optimization here. It is the only way to be on time.

Automate without a gate — reversible, scoped, evidence-producing: correlation across synthetic checks, edge metrics and provider alerts; evidence capture (flow export, bounded pcap, provider attack record, edge log snapshot); channel and ticket creation; status-page draft for human approval; managed-ruleset escalation to the documented High posture; rate-limit rules deployed in Count mode; auto-paging the Intrusion Watch role whenever this playbook opens.

Require a named human approver — irreversible, or blast radius scaled by a false positive: switching any rule from Count to Block, global Under Attack Mode, geography or ASN blocking, blackhole requests to the upstream, BGP announcement changes, origin IP rotation. This is the book's general gate rule: automation may gather, enrich, correlate and recommend freely; it may act only where the action is reversible, scoped and rate-limited.

Two conditions on every automated mitigation. It must auto-expire — a mitigation with no expiry becomes permanent shadow configuration nobody remembers approving. And it must write its evidence to the incident record as it fires, because an automated block with no captured rationale is indistinguishable from a misconfiguration when someone asks in six weeks why a whole country cannot reach your site.

#Pitfalls