Where does spoofing sit on a flow where a ward terminal reaches its formulary service by hostname alone, and what closes it?

## Reading the flow The diagram has an external-facing process (the formulary service), a client process on a terminal inside a ward, and an arrow between them crossing a trust boundary — the hospital LAN, which is shared with printers, contractors' laptops, medical devices and anyone who reaches a network port in a corridor. The terminal's only statement about who it is talking to is a hostname. STRIDE walks the arrow's ends. The callee end carries **Spoofing**: something other than the formulary service can be what answers. The asset is not a database of records — it is the correctness of a dispensing decision, which makes the impact a safety and integrity impact rather than a privacy one, and that reframing usually changes the priority of the finding. ## Why a name is not an identity Name resolution answers the question *where do I send the bytes*. It does not answer *who is on the other end*. On a network segment you do not fully control, the party that manages to answer to a name is the party the client will talk to, and the client has no way to notice — the response looks exactly like a valid response, because there is nothing in it to check. That is the whole finding, and you can state it without naming any particular network technique: **the client accepts an answer from whoever holds the name, and the model must not assume the network decides identity honestly.** The corollary is the trust-boundary rule of thumb: if you would not accept the flow from an arbitrary machine on that segment, then the segment is not inside your boundary, and the boundary must be enforced by something the client verifies rather than by where the wire runs. ## What actually closes it The answering family is **server authentication**: the terminal verifies a credential that is cryptographically bound to the expected service name, chained to a trust anchor the terminal carries rather than one supplied by the network, and it refuses the connection when verification fails. Three details do the real work in a review: 1. **Verification, not encryption.** A channel can be encrypted and still terminate at an impostor. Confidentiality answers Information Disclosure; only verification answers Spoofing. "We use TLS" is not a mitigation until someone says what the client validates and what happens when validation fails. 2. **The trust anchor is part of the model.** If the terminal will accept anything signed by any anchor in a broad, unmanaged trust store, the anchor set becomes the attack surface. A device with a narrow, pinned or organisation-controlled anchor set has a much stronger claim. 3. **Fail closed.** A client that falls back to an unverified connection when verification fails has a control that any attacker can switch off by causing a failure. ## The other direction, and the other shape One-way authentication proves exactly one end. Ask what the service does with what the terminal sends. If it only serves read-only lookups, the caller end may genuinely not need proving, and saying so explicitly is a legitimate modeling decision. If the service accepts an override, a refill or anything that changes state, then the caller end is unauthenticated and carries its own spoofing threat — anything on the LAN can also pose as a ward terminal. That is when the answer becomes **mutual authentication**, both ends proving an identity to the other. The mirror-image shape is worth recognising because it looks different and is the same threat: an inbound callback whose only protection is an unguessable URL — for example a carrier posting shipment-delivered events that release a payment. Here the receiver, not the caller, is the one with no verifiable claim, and the attacker is any anonymous party on the internet who learns the URL rather than someone on the local network. A URL is not an identity: it cannot be attributed to one sender, cannot be scoped to what that sender may assert, and cannot be revoked for one caller without breaking all of them. It is a secret in the same sense a shared password is, and it leaks the same ways — logs, referrers, browser history, screenshots, a support ticket. ## Weak answers to expect and to reject - *"It is an internal network."* That claims a trust boundary exists where the diagram shows one does not. Make it explicit and see whether anyone will sign it. - *"We allowlist the terminal's address."* An address is a routing locator that the network assigns; it is an obstacle, not an identity claim you can verify, attribute or revoke. - *"The traffic is encrypted."* See above: the wrong property. - *"The device is physically inside a controlled ward."* Physical control of one endpoint says nothing about the other end of the flow. ## Writing the finding A usable entry names the element, the claim and the consequence: *Threat: the terminal accepts formulary responses from any host answering the service name on the ward network (Spoofing, callee end). Impact: falsified dosing data reaches a dispensing decision. Control: verify a service credential bound to the expected name against a device-held trust anchor, fail closed. Open question: does the service accept state-changing calls, and if so does the caller end need proving too?* That last line is what turns a category into a design conversation.