Denial of Service

## What the D in STRIDE actually claims STRIDE is a threat taxonomy: each letter names a **security property under attack**, not a named exploit. Spoofing attacks authentication, Tampering attacks integrity, Repudiation attacks non-repudiation, Information Disclosure attacks confidentiality, **Denial of Service attacks availability**, and Elevation of Privilege attacks authorization. So the question the D asks of every element in your design is one sentence long: *what would stop this from serving a legitimate request?* That framing matters, because Denial of Service is the letter people most often narrow too far. It is not a synonym for a network flood. It is any way the system stops being usable — including ways with no adversary at all, which is why a threat model treats reliability failures and hostile exhaustion under the same heading. The threat is the outcome (service denied); the flood, the poison message, the missing timeout and the single dependency are just different causes. ## How it lands on each element type A data-flow diagram has four element shapes, and the D reads differently on each. | Element | What denial of service looks like | |---|---| | Process | Exhaustion of a finite resource: CPU, heap, thread pool, connection pool, file handles, disk for temp files. Also a crash loop from a message it cannot parse. | | Data store | Capacity exhausted (disk full, quota hit, partition hot), writes blocked by long-held locks, or the store left needing manual recovery. | | Data flow | Bandwidth saturated, connection dropped, latency pushed past a deadline so callers time out even though the far end is alive. | | External entity | Not a target you can harden — in the classic STRIDE-per-element chart, external entities carry only S and R. You deny that user service by hitting the process or flow they depend on. | The chart is a prompt, not a law. Its value is that walking every element with only its applicable letters makes the D findings show up in places people skip — the batch job, the log store, the certificate that expires, the queue with no dead-letter path. ## The resource lens The practical way to enumerate D threats is to ask, per element: **which finite resource does this consume, who can make it consume more, and what happens when it runs out?** Finite resources are broader than CPU and bandwidth: memory, disk, inodes, sockets, database connections, locks, entropy, quota against a paid third party, licences, identifiers in a bounded key space, and the time budget of an upstream caller. The last one is often the sharpest: a slow dependency denies service just as thoroughly as a crashed one, because the callers holding threads waiting on it exhaust their own pools. ## Temporary versus permanent Distinguish the two, because they have different mitigation costs. - **Temporary**: the resource is consumed while the pressure lasts and recovers on its own — a saturated thread pool, a full queue, bandwidth contention. - **Permanent**: the system cannot recover without operator action — a filled disk, a poison message that crashes every consumer on redelivery, a corrupted config or cache written by the failure, a wedged lock, an exhausted identifier space. Permanent denial deserves disproportionate attention in a design review, because the recovery cost and the outage length are set by human response time, not by the attacker walking away. ## Who does it D threats span every attacker position, and naming the position sharpens the mitigation. An anonymous internet caller triggering expensive work; an authenticated low-privilege tenant consuming a shared pool; an insider issuing an unbounded query; a compromised dependency changing resource behaviour; a component with no adversary at all, retrying a failed call in a tight loop. If the position is *nobody* — a single dependency whose outage stops everything — that is still a legitimate D entry in the model. Threat modeling asks what could go wrong, not only who is trying. ## The answering control family Availability is defended by **bounding** and **duplicating**: - Bound the work: timeouts everywhere, caps on request and response size, limits on recursion, nesting and expansion, cost-based limits rather than count-based ones, bounded pools that reject fast rather than queue forever. - Bound the consumer: per-principal quotas and concurrency slots, fair scheduling between classes of work, load shedding by priority, backpressure that propagates instead of buffering. - Duplicate and degrade: redundancy for anything single on the critical path, caches and locally held state that let the system serve a reduced answer, circuit breakers, retry with backoff and jitter, a defined degraded mode. ## Boundary Volumetric flooding at the network layer is a real availability threat, but its attack classes and mitigations belong to network defence, not to this design-time analysis. Likewise, *rating* how bad an outage threat is comes later, in risk rating. What this step owns is the enumeration: for each process, store and flow, one written threat sentence naming the resource, the actor who can exhaust it, and the effect on legitimate users.