In STRIDE, which security property does Spoofing violate, and which DFD element types can be spoofed?

## What the S actually names STRIDE is a threat-enumeration mnemonic: each letter names a **security property under attack**, not a named exploit. Spoofing pairs with **authentication** — the ability to know that a party is who or what it claims to be. The other five pairings, for orientation only, are Tampering with integrity, Repudiation with non-repudiation, Information Disclosure with confidentiality, Denial of Service with availability, and Elevation of Privilege with authorization. Saying this precisely matters because the four words are routinely blurred: - a **threat** is what could go wrong — *a caller could pose as the payments service*; - a **vulnerability** is the flaw that lets it — *the endpoint accepts any caller that knows the URL*; - a **risk** is the rated consequence — *funds released on a forged callback*; - a **control** is what you do about it — *authenticate the caller and reject unauthenticated callbacks*. Spoofing is a threat about the identity claim itself. Whether the attacker got there by guessing a shared secret, by holding a device, or by answering to a name on the network is the mechanism, and the mechanism does not change the category. ## Which elements carry the threat STRIDE-per-element assigns categories by element type, which is what makes the enumeration mechanical rather than inspired: | DFD element | Spoofable? | What the claim looks like | |---|---|---| | External entity (user, partner system, device) | Yes | Something presents itself as that user, partner or device | | Process (service, daemon, function) | Yes | Something answers in place of that service, or poses as it to a peer | | Data flow (an arrow) | No | A flow is tampered with, read or starved — there is no identity to impersonate | | Data store (database, bucket, log, queue) | No | A store is modified or disclosed; impersonating the *store* is really spoofing the process that fronts it | A useful sharpening: when someone insists the database is being spoofed, what they are describing is a client that resolves and connects to something claiming to be the database. That is spoofing of the **process/endpoint**, and it lands on the element that answers. ## External entities: the mitigation lands on your side External entities are drawn precisely because they are outside your control — you cannot patch a customer, a partner or a shipping carrier. So a spoofing threat against an external entity is never mitigated *inside* that entity; it is mitigated **at the boundary where your process accepts input from it**, by requiring and verifying a credential you can check and revoke. This is why the threat sits on the entity but the control sits on your process. Two shapes recur on a flow: - **Spoofed sender.** Your process accepts an inbound call and has no verifiable claim about who made it. A carrier status callback that releases payment, protected only by an unguessable URL, is the canonical version: knowledge of a URL is not an identity — you cannot attribute it, scope it, or revoke it for one caller. - **Spoofed server/peer.** Your client reaches out and accepts an answer from whatever responds to a name. On a network you do not fully control, a name is a lookup result, not an identity. ## The answering control family The control family for Spoofing is authentication, and threat modeling cares about three things about it rather than the implementation: 1. **Direction.** One-way authentication proves exactly one end. If both ends act on what the other says, you need mutual authentication. 2. **Granularity.** *Which* identity does the verifier actually learn — this device, or any member of a group that shares one secret? 3. **Lifecycle.** Can that identity be issued, rotated and revoked for one party without disrupting the rest? Encryption is not on this list. A confidential channel to an impostor is a confidential channel to an impostor; confidentiality answers Information Disclosure, not Spoofing. ## Common confusion with Elevation of Privilege Both can end with an attacker acting as an administrator, which is why interviewers probe the difference. Spoofing is a **false claim about who you are** that the system believes; elevation is **acting beyond what your identity is permitted**, once identity is settled. If the system correctly identified the actor and still let it do too much, that is an authorization failure and belongs under E; if the system was wrong about who the actor was, it is S. Categorising it correctly matters because the two point at different control families and usually different owners. ## How to use this at the whiteboard Walk the diagram element by element. For each external entity and each process ask: what identity is being claimed here, what does the receiver verify, against what trust anchor, and what happens when that anchor or credential is wrong? Anything you cannot answer is a spoofing finding, whether or not you can name the technique that would exploit it.