DDoS Distributed Denial of Service.

What a distributed denial of service attack actually does

A denial of service attack has one goal: make a service unavailable to the people who depend on it. The distributed version, DDoS, achieves that by sourcing the traffic from many machines at once, often a botnet of compromised devices, hijacked servers or rented attack infrastructure. Because the load arrives from thousands of distinct addresses, you cannot simply block one offender, and the sheer count of sources is what lets the attacker overwhelm capacity that a single machine never could. The target does not need to be breached or have data stolen. It only needs to be knocked offline, which makes DDoS an availability attack rather than a confidentiality or integrity one.

Practitioners usually sort DDoS into three layers, because the layer dictates the defence. Volumetric attacks try to saturate the bandwidth of the link itself, frequently using amplification where a small spoofed request triggers a large reply aimed at the victim. Protocol attacks exhaust state in network equipment and servers, for example by leaving half-open connections that never complete. Application-layer attacks are the quietest: they send requests that look legitimate, such as repeated calls to a search endpoint or a login page, and exhaust the application rather than the pipe. The last category is the hardest to separate from real users.

Why mitigation is no longer the hard part

Stopping DDoS traffic has become a commodity. Large providers such as Cloudflare, Akamai and AWS Shield absorb attacks at the edge of enormous networks, soaking up volumetric floods far upstream of the customer and filtering protocol and application abuse with scrubbing and rate limiting. For most organisations the technical question of whether an attack can be blocked has a confident yes, provided traffic is routed through that protection. The harder question, and the one a risk function should be asking, is one of coverage rather than capability.

The gap that hurts is the asset nobody routed through the shield. A public marketing site sits behind the CDN, but the API that the mobile app calls, the legacy origin IP that was never decommissioned, the partner integration endpoint or the regional service spun up by another team may resolve directly to the origin, bypassing the protection entirely. Attackers find those direct paths and aim there. Effective DDoS defence is therefore an inventory and routing problem first: knowing every internet-facing service, confirming each one is actually behind the mitigation, and proving the origin cannot be reached around it.

Where DDoS sits in continuity and standards

Because DDoS attacks availability, it belongs in the same conversation as business continuity management. An information security management system aligned to ISO/IEC 27001 treats availability as one of the three properties it protects, and a denial of service scenario is a textbook input to a business impact analysis: how long can each service be down, what depends on it, and what is the fallback. The response is rarely a single control. It combines upstream mitigation, an incident response runbook with named contacts at the mitigation provider, and continuity arrangements for the period an attack is being absorbed.

What practitioners actually do, beyond buying mitigation, is rehearse and verify. They keep an accurate inventory of internet-facing services, confirm each is behind protection, and test that the origin is unreachable directly. They tune rate limits and challenge pages for application-layer abuse, since those attacks mimic real traffic and cannot be solved by bandwidth alone. They write the escalation path before an incident, so that during a flood nobody is hunting for the right phone number. And they treat a DDoS event as a continuity exercise, with clear thresholds for invoking the plan, communicating to customers and standing services back up once the traffic subsides.