DDoS and Availability Attacks: Keeping the Lights On Under Pressure

The third letter of the triad nobody plans for

Security teams pour energy into confidentiality and integrity — encryption, access control, tamper detection — and quietly treat availability as an SRE problem. But the "A" in the CIA triad is there for a reason, and for a lot of teams it's the letter an attacker reaches for first. A distributed denial-of-service flood, a brute-force login storm, a scraper hammering an expensive endpoint, or an application bug that lets one request consume all your resources — they all end the same way: the site is down, and the people who depend on it can't tell whether it's an outage or an attack.

That ambiguity is the trap. If your uptime monitoring and your security monitoring live in separate worlds, an availability attack gets handled as a routine ops ticket — restart the box, scale up, move on — while the actual cause goes uninvestigated and unmitigated. The first move in defending availability is simply to treat "we're down and we don't know why" as a possible incident, not just an outage.

The attacks that take you offline

Availability attacks come in a few recognizable shapes, and the defense differs for each:

Volumetric DDoS. Sheer traffic — a botnet sending more requests or raw bandwidth than your origin can absorb. The defense is not a bigger server; it's putting capacity in front of you that's larger than any attacker can muster.
Application-layer floods. Fewer requests, but each one expensive — a search query, an export, a login attempt — aimed at the endpoints that cost you the most CPU or database time. These slip past crude bandwidth defenses because the volume looks modest.
Resource exhaustion. Not always external: a misconfiguration or an unbounded query that lets a single request (or a clumsy crawler) exhaust connections, memory, or rate limits and take the whole service down.
The availability half of ransomware. When an attacker encrypts or deletes, the immediate symptom is the same — systems unavailable — which is why backup and recovery is an availability control as much as an integrity one.

What a lean team can actually do

You don't need a dedicated scrubbing appliance to be resilient. The highest-leverage availability defenses are configuration choices, not purchases:

Front everything with a CDN and a WAF. A content-delivery network with DDoS protection puts vastly more absorption capacity in front of your origin than you could ever provision yourself, and a web application firewall filters the malformed and abusive requests before they reach you. This is the single biggest step, and the managed versions are within a lean team's budget.
Rate-limit at the edge. Per-IP and per-account limits on expensive and authentication endpoints turn an application-layer flood into a throttled trickle. The same limits blunt credential-stuffing and scraping.
Design for graceful degradation. Cache aggressively, fail static, and shed non-essential load under pressure so a surge degrades the experience instead of collapsing the service.
Wire detection to your alerting. A latency cliff plus a surge in inbound requests looks like a DDoS, not a bad deploy — your log and detection pipeline should make that distinction loud, so the on-call human reaches for the right playbook.
Rehearse it. Add an availability-attack scenario to your tabletop exercises: who flips on "under attack" mode, who talks to customers, who decides to block a region? Deciding that mid-flood is too late.

Availability is a posture dimension, too

An exposed origin with no CDN in front of it, a missing rate limit on an expensive endpoint, or an unbounded query waiting to be triggered is a finding like any other — routed to an owner with a severity set by what it protects, using the same exposure-first triage as everything else. And readiness drifts: a new endpoint ships without a rate limit, a service gets a public route that bypasses the CDN, a config change reopens the origin. "Is our availability defense actually in place and configured?" is a continuously verified dimension of your posture, not a box checked at launch.

It feeds the audit, too. Availability is an explicit criterion in SOC 2 and a core expectation of any business-continuity review — assessors ask how you protect against and respond to availability threats. Your CDN/WAF configuration, rate-limit policy, and the incident records from any real event are exactly the evidence they want.

One honest caveat: a platform can help you track whether your availability defenses are configured, surface the gaps as findings, and keep that evidence current for an auditor — it organizes, tracks, and proves the work. It does not absorb a flood, stand in front of your origin, configure your CDN or rate limits, make you compliant, or grant or guarantee any certification; the edge protection, the architecture, and the response on the day are operational steps your team owns, and which availability obligations apply to you is a question for counsel.

The attack most likely to take you offline targets availability, and the defense isn't a bigger server — it's borrowed capacity at the edge, rate limits on your expensive endpoints, graceful degradation, and detection wired to your alerts. Treat "down and don't know why" as a possible incident, and rehearse it before the flood arrives.

DDoS and Availability Attacks: Keeping the Lights On Under Pressure

The third letter of the triad nobody plans for

The attacks that take you offline

What a lean team can actually do

Availability is a posture dimension, too

See Hosting Security in action

Related articles

Cyber Threat Intelligence Without a Team: Making Threat Data Actually Change What You Do

SPF, DKIM, and DMARC: Stopping Attackers From Sending Mail as You

Security Awareness Training That Actually Changes Behavior

Related articles

Threat Detection
Cyber Threat Intelligence Without a Team: Making Threat Data Actually Change What You Do
Threat intelligence has a reputation as an enterprise luxury — expensive feeds, a dedicated analyst, a wall of dashboards nobody reads. The useful version is almost the opposite: a small, deliberate habit of letting real knowledge about who is attacking businesses like yours change a handful of concrete decisions. A practical guide to the three altitudes of threat intel, the free sources a lean team can actually use, and the one discipline that separates intelligence that sharpens your defenses from a feed that just adds noise.

Threat Detection
SPF, DKIM, and DMARC: Stopping Attackers From Sending Mail as You
Without email authentication, anyone can send mail that says it is from your domain — and your customers will believe it. How SPF, DKIM, and DMARC work together to stop spoofing, and why DMARC enforcement is the step most teams never finish.

Threat Detection
Security Awareness Training That Actually Changes Behavior
Phishing is the top way attackers get in, and the annual click-through training module does almost nothing about it. What measurable, behavior-changing awareness programs do differently — and the metric that proves they work.