DDoS Readiness Assessment: How Prepared Is Your Network?

Readiness assessments are usually run by people selling something, which makes them reliable at finding gaps that a particular product closes and unreliable at everything else.

This one is arranged the other way round. It starts with the areas where the fix is free, because that is where most organisations actually lose incidents.

At a glance

Appliance	Area	The question	What a weak answer looks like
Visibility	Would you know within two minutes?	A customer usually tells us
Upstream	Who do you call, and have you called them?	A number in a document nobody has dialled
Capacity	What are your own peaks and ceilings?	Bandwidth only, and no packet-rate figure
Response	Who decides, at 03:00, without waiting?	Escalation to someone who is asleep and not on call
Evidence	Can you reconstruct it a week later?	A dashboard that only shows the present
Practice	When did you last rehearse this?	The last real incident, which nobody wrote up

Four of these six cost nothing but attention. They are also, consistently, where the lowest scores are, which is why a readiness exercise usually pays for itself before any purchase.

Scoring

Each item scores 0 if it does not exist, 1 if it exists on paper, 2 if it exists and has been demonstrated within twelve months. The distinction between 1 and 2 is the whole value of the exercise: a contact list that has never been dialled and a contact list that was dialled in March are different things, and only one of them will work.

Area 1 — Visibility

1. Traffic volume alerting exists on the internet-facing path, with thresholds someone chose deliberately.
2. Flow records are exported and retained for at least 30 days.
3. Per-service request-rate metrics exist, separate from bandwidth.
4. Session-table utilisation is monitored on every stateful device in the path.
5. An alert reaches a human within two minutes, out of hours, and this has been tested.

Item 4 is failed by most estates. Bandwidth is monitored everywhere; session-table utilisation almost nowhere — and it is the resource that runs out first under a transport-layer attack.

Area 2 — Upstream

6. You know which provider carries each internet circuit, and their support path.
7. You have a named contact and an out-of-hours number for DDoS specifically, not general support.
8. You know what filtering they will apply on request, and how long it takes.
9. You know whether they support customer-triggered filtering — RTBH or FlowSpec — and whether it is enabled on your circuits.
10. You have contacted them about a DDoS event or a test within twelve months.

Item 10 separates the estates that will get help quickly from the ones that will spend the first forty minutes of an incident establishing who to talk to.

Area 3 — Capacity

11. Circuit capacity is documented per site, including planned changes.
12. Legitimate peak is measured in bits per second and packets per second.
13. New sessions per second at peak is measured.
14. The packet rate your circuit can deliver at 64-byte frames is calculated and written down.
15. You know what each stateful device does when its table fills: refuse, overwrite, or pass.

Item 15 has a factual answer that is rarely known, and the three possible answers are a degraded service, broken conversations, or an open perimeter. The arithmetic behind item 14 is in the capacity planner and the reasoning in capacity sizing.

Area 4 — Response

16. A written runbook exists, naming who does what in the first fifteen minutes.
17. Decision authority for disruptive action is delegated in writing, with named alternates.
18. The escalation path works out of hours and has been tested out of hours.
19. Customer and public communication is pre-drafted, with an owner.
20. A status page exists that is not hosted on the infrastructure being attacked.

Item 20 fails more often than it should, and it fails at the worst moment. Item 17 is the one that costs the most minutes: a defensible action that nobody present is allowed to authorise is an action that will not happen until someone wakes up.

Area 5 — Evidence

21. Logs from the edge devices are retained long enough to cover your reporting obligation.
22. Incident telemetry survives a failure of the central logging system.
23. Packet-level capture is available for at least a sample of an incident.
24. Timestamps across devices are synchronised and demonstrably so.
25. A post-incident report has been produced for the most recent event.

Item 22 matters for a reason described in the smokescreen argument: a flood multiplies events, and a pipeline at its ceiling drops the security events that were not about the flood.

Area 6 — Practice

26. The runbook has been rehearsed as an exercise, with the people who would actually be called.
27. A mitigation control has been deliberately triggered in a controlled window.
28. Failover or bypass has been tested, with the failover time measured.
29. Threshold calibration has been reviewed within twelve months.
30. Lessons from the last exercise or incident produced a change that was implemented.

Reading the result

Total out of 60. The number is less interesting than the shape.

Low in Visibility means you will find out from a customer, and everything downstream starts late. Fix this first regardless of the other scores; it is mostly configuration.

Low in Upstream means you have no answer to volumetric saturation, which is the one thing no equipment you own can solve. Also mostly free to fix.

Low in Capacity means any procurement you run will be badly specified, and a supplier will size your defence from their product line instead of your network.

Low in Response means the technology will work and the organisation will not.

Low in Evidence means you will meet a reporting deadline without the material to meet it.

Low in Practice with high scores elsewhere is the most common shape in well-funded estates, and it is the one that surprises people during a real event.

Take the two lowest areas and close the zero-cost items in the next quarter. Then, if a purchase is still indicated, the sizing record and the tender questions are already half-written by this exercise. Where the estate should be heading over years rather than quarters is the subject of the maturity model.