skip to content

Three nurses share one cabled ward terminal per shift — how do you decide whether to bind their sessions at all?

level: principalimportance: should knowfreq 38%

answer

  1. stable properties, changing person
  2. count both rates first
  3. zero true positives here
  4. an update ends every session at once
  5. challenge, never lock out

basics

~20 s

Price both sides before choosing. On a fixed shared terminal the address and agent never vary, so a binding yields no true positives and only correlated false positives when a fleet update lands. The defensible answer there is to bind nothing and detect instead.

solid answer

~50 s

Start from what the signals would actually measure in **this** deployment. The terminal is cabled, so its network position never changes; the client is managed, so its agent string is identical on every terminal and changes only when operations pushes an update to all of them at once. A binding therefore has two measurable properties: a true-positive rate of roughly zero, because anyone attacking from that ward network presents the same values, and a false-positive rate of zero until an update night, when it ends every session in the building simultaneously. That is the worst possible shape for a control — invisible benefit, correlated harm. What remains useful is behavioural detection on request shape, a short inactivity window, and per-action attribution of who did what; and any suspicion routes to a challenge rather than a lockout, because a clinician locked out of a chart at a bedside has a clinical cost the risk does not justify.

code

json · 13 lines
json
{
  "scope": "ward bedside terminals (cabled, shared across a nursing shift)",
  "signalsConsidered": ["network address", "client agent string", "derived client fingerprint"],
  "measuredVariance": {
    "networkAddress": "none across a shift; changes only on subnet maintenance",
    "clientAgentString": "none; managed fleet update roughly monthly",
    "derivedFingerprint": "none; every terminal runs an identical managed image"
  },
  "expectedTruePositivesPerShift": 0,
  "expectedFalsePositivesPerFleetUpdate": 1200,
  "decision": "bind no client property; detect on request shape; route suspicion to a challenge",
  "reopenWhen": "terminals become wireless carts, or the application is reachable off the ward network"
}

go deeper

for a junior

Notice that a terminal several people share breaks the usual one-device-one-person assumption, so anything the server observes about the machine says nothing about which human is typing.

for a middle

Explain why a signal that never varies produces neither false positives nor true positives, and what a fleet-wide client update does to an exact-match binding overnight.

for a senior

Bring numbers to the argument: measured variance per signal, expected forced sign-ins per update event, and the routing choice that keeps a suspicion from becoming a lockout at a bedside.

for a principal

Own the trade explicitly and record it — signals considered, both rates, the decision, and the deployment change that would reopen it — so the judgment survives the people who made it.

## The deployment that breaks the usual assumption Every binding scheme rests on one unstated premise: **stable client properties imply a stable person**. A fixed, shared clinical terminal falsifies both halves at once. The properties are perfectly stable — same cable, same subnet, same managed client image — and the person changes every twenty minutes as nurses come and go from the bedside. A scheme whose premise is false in your deployment does not degrade gracefully; it simply measures nothing while still being able to fail. So the decision is not "which signal do we bind" but "does binding have any measurable value here at all", and that is a question with an arithmetic answer. ## Pricing it with numbers rather than caveats Take a ward estate of roughly 400 terminals, three clinicians per terminal per shift, three shifts a day. - **Network address.** Variance across a shift: none. False positives per year: zero, except on a re-addressing event during maintenance, which then hits every terminal on that subnet in the same minute. True positives: zero, because an attacker who reaches that record — from a compromised terminal, from a workstation on the same ward network, or from the bedside itself — presents the identical address. - **Client agent string.** Variance across a shift: none. A managed update lands roughly monthly and rewrites the string on the whole fleet overnight; with exact matching that is about **400 terminals x 3 sessions = 1,200 forced sign-ins clustered in one window**, typically the night shift with the fewest staff. True positives: zero, for the same reason as above. - **Derived client fingerprint.** More stable and more discriminating in principle, but every terminal in the estate is an identical managed image, so the derived value is identical too. It also creates a record about a device that the ward may not be permitted to retain, and a caller who can read it can usually reproduce it. The summary line for a design review: **expected true positives per shift, zero; expected false positives per update event, four figures.** That is not a trade-off, it is a cost with no matching benefit. ## What binding would need to catch here, and cannot The realistic threat on a shift-shared terminal is not a remote thief replaying a copied reference from another country. It is the **next clinician continuing under the previous one's still-open session**, so that an action is attributed to the wrong person in a record with legal weight. Against that threat every bound property is identical on both sides of the hand-off. No choice of signal, no amount of tuning, and no fingerprint changes that: the two callers are indistinguishable by construction. ## What to buy instead 1. **Behavioural detection on shape.** Request rate, ordering, and the breadth of records touched are the only family that still discriminates when every property matches, and they are what would actually catch bulk extraction from a bedside terminal. 2. **A short inactivity window,** so an abandoned session at a bedside closes itself rather than waiting for a human to notice. The clocks themselves are an ordinary lifecycle decision; what belongs to this decision is recognising that they are the substitute for the binding you are declining. 3. **Per-action attribution** — a cheap, fast re-identification at the point of a consequential write, so the record names the human who acted rather than the human who signed in ninety minutes ago. 4. **Routing suspicion to a challenge, never to a lockout.** A false positive that costs seconds is affordable at a bedside; one that costs access to a chart during a deteriorating patient is not, and that asymmetry is the whole argument. ## Write the decision down and say when it expires The reason to record this as a decision rather than a configuration is that it is **deployment-specific and will stop being true**. Replace the cabled terminals with wireless carts, or let clinicians reach the same application from outside the ward network, and the variance changes, the true-positive rate stops being zero, and the whole calculation must be redone. A decision record that names the signals considered, the measured variance, the expected rates on both sides, the choice, and the condition that would reopen it is the difference between an engineering judgment and a habit nobody can defend two years later.

  • What would change your answer about binding on these terminals?
    Variance. Replace the cabled terminals with wireless carts crossing subnets, or let staff reach the same application from off the ward network, and the properties start to differ between an honest caller and an attacker. The true-positive rate stops being zero and the arithmetic has to be redone, which is why the decision record names that condition.
  • If binding is declined, what is the honest residual risk you are accepting?
    That a copied session reference used from inside the ward network is indistinguishable from the legitimate clinician on every property, and only a behavioural anomaly would surface it. You accept that in exchange for never locking a clinician out of a chart at a bedside, and you write the acceptance down rather than leaving it implicit.
  • Who should own this decision, and what do they need to see?
    Whoever owns the clinical-risk trade, not the engineer implementing it. They need both numbers — expected true positives and expected false positives with the population each falls on — plus the proposed routing for a suspicion, so the choice is made against stated costs rather than against a general preference for more security.

A smoke alarm mounted over a commercial kitchen range: it fires on every service and never on a fire, so within a week the staff have taken the battery out. A detector whose false positives dominate is not a weak control, it is a control that will be removed.

saying these in an interview costs you the question

  • Enables a binding because it is standard practice, without pricing it
  • Assumes stable client properties mean the same person is present
  • Counts a control's benefit without counting its false positives
  • Ends sessions on a suspicion where a lockout has a safety cost
  • Treats a shared terminal as one device with one user