DDoS Resilience and Preparedness Review
Evaluate how well the environment withstood the attack and identify specific architectural, contractual, and operational changes needed to improve resilience against the next one.
Actions
- 1
Evaluate mitigation latency: time from attack start to detection, time to scrubbing activation, time to full mitigation. Compare to SLAs and target goals.
- 2
Evaluate capacity: at peak, what percentage of attack traffic was mitigated upstream, at the CDN, at the WAF, at origin? Identify the layer closest to origin that became saturated.
- 3
Evaluate architectural resilience: are origins behind scrubbing protected by IP allowlisting? Are DNS TTLs short enough for rapid redirection? Is there geo-redundant failover?
- 4
Evaluate cost: attack-window CDN/bandwidth costs, scrubbing costs, legitimate-traffic conversion loss. Document so contracts can be negotiated on real numbers.
- 5
Review runbook effectiveness: which steps worked, which were missing, which staff were unavailable? Update the runbook concretely.
- 6
Plan an exercise or tabletop within 90 days to validate fixes under a simulated repeat attack.
Queries
Do our DNS TTLs allow rapid redirection to scrubbing, or did they delay our response?
Is our origin protected from direct attack if scrubbing is bypassed?
Notes
DDoS is a volume-plus-speed problem. Architectural choices (CDN fronting, IP allowlisting on origin, DNS TTL) often matter more than any single tool.
Post-incident reviews that produce vague "improve DDoS resilience" recommendations are wasted; require specific controls with owners and dates.