In STRIDE, which property does Denial of Service violate, and how does it appear on a process, a store and a flow?
answer
- one of the classic security triad
- not secrecy, not correctness
- some finite resource runs out
- processes, stores and flows each differ
- the property quotas and redundancy defend
basics
~20 sDenial of Service violates availability - legitimate users stop being served. On a process it exhausts CPU, memory or threads; on a store it fills or locks storage; on a flow it saturates or cuts the channel.
solid answer
~50 sThe D in STRIDE is the availability letter — the threat that a legitimate user cannot use the system when they need it. Each element type on a data-flow diagram fails differently. A **process** runs out of a finite resource: CPU, heap, threads, file handles, database connections, or its own dependency budget. A **data store** fills to capacity, has its writes blocked by a lock or a hot partition, or is left in a state that needs operator recovery. A **data flow** is saturated, dropped, or delayed past its useful deadline. External entities are not something you can harden, so in the classic STRIDE-per-element chart they carry only spoofing and repudiation — you deny an external user service by taking down the process or flow they depend on. The answering control family is bounding and duplicating: quotas, timeouts, caps on input-driven work, backpressure, and redundancy for anything on the critical path.
go deeper
Be ready to name the property the D violates and give one concrete example on each of a process, a store and a flow. Knowing that availability is what is under attack is the recall that gets asked.
Explain the mechanics: which finite resource each element type runs out of, why a slow dependency denies service as effectively as a crashed one, and why external entities carry no D in the per-element chart.
Show you enumerate the unglamorous ones in real designs — the log store filling, the poison message, the expiring certificate, the unbounded retry — and that you separate temporary exhaustion from failures needing operator recovery.
Own the framing that availability is a security property, not a separate reliability budget, so outage threats get modeled, rated and funded alongside the other five letters rather than deferred to another team.
## 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.
- Can an external entity on a data-flow diagram be the target of a Denial of Service threat?In the classic STRIDE-per-element chart external entities carry only spoofing and repudiation, because they sit outside your design and you cannot harden them. You deny that user service by exhausting or breaking the process, store or flow they depend on, so the D entries belong on the elements you own and operate.
- What is the difference between a temporary and a permanent denial of service, and why track it?Temporary means the resource is consumed while the pressure lasts and recovers on its own — a saturated pool, contended bandwidth. Permanent means the system cannot recover without a human: a filled disk, a wedged lock, a poison message that crashes every consumer on redelivery. Permanent ones deserve more design effort because outage length is set by response time, not by the attacker stopping.
- Give a Denial of Service threat that has no attacker in it at all.A single dependency on the critical path with no fallback: when it is unavailable, every request fails. Or a retry loop with no backoff that turns a brief blip into a self-sustaining storm. Threat modeling asks what could go wrong, so these belong in the model as D entries even though nobody is attacking.
saying these in an interview costs you the question
- Says denial of service only means flooding a server with traffic
- Maps the D in STRIDE to confidentiality or integrity
- Believes a denial-of-service threat requires an external attacker
- Looks only at the web tier and never at stores or batch jobs
- Assumes every denial of service recovers by itself