Your ballot-tabulation threat model assumed operators are always supervised; that assumption drops. What changes?

## The scenario A ballot-tabulation network is modeled with an assumption that was never argued because it looked like a fact: *only credentialed poll workers ever touch a machine, and always under supervision.* The assumption now drops — the same credentialed operator can have unsupervised time with the hardware. No component changed. The design is identical. The model is not. The asset here is **audit truth**: the property that the reported count corresponds to the votes cast and can be shown to correspond. That framing matters, because most instinctive controls protect confidentiality, and confidentiality is not what is at stake. ## First move: redraw the boundary, do not re-enumerate everything A common wrong answer is "we start the model again". The right answer is bounded: only the threats whose *reachability* rested on the dropped assumption change status. Concretely: - The operator was an external entity you drew on the **trusted** side. They stay where they are on the diagram, but the trust label comes off. - Local interfaces you never drew as flows — service ports, maintenance modes, removable media, the boot path — become flows crossing a boundary, because time and privacy are what turned them from theoretical into usable. - Anything reachable only from the public internet is **unaffected**. Saying so out loud is part of the answer: a re-model that changes every rating is a re-model nobody will trust. ## Which threats survive, in STRIDE terms - **Tampering** dominates. With unsupervised time, modification of the counting software, its configuration, or the stored tallies moves from "requires a chain of unlikely steps" to "requires patience". This is the threat the asset is defined against. - **Repudiation** becomes first-class. If credentials are shared per shift or per station, no action can be attributed to a person, so an integrity failure cannot even be investigated afterwards. Under the old assumption, supervision *was* the attribution mechanism. - **Elevation of privilege** re-enters through local paths: maintenance and recovery modes, physical reset, debug interfaces — capabilities deliberately given to a trusted operator role. - **Spoofing** shifts meaning. The actor does not need to spoof to get in; the concern is impersonating *another* operator to shift blame, which is really an attribution problem again. - **Information disclosure** is largely unchanged, and **denial of service** is now trivially available but was already accepted as a procedural risk. Naming these as unchanged is as valuable as naming what got worse. ## Which controls stop being defensible This is the part interviewers listen for. Several controls were resting on supervision without ever saying so: | Control | Why it stops holding | | --- | --- | | Tamper-evident seals checked by the same operator | The checker and the assumed actor are the same person | | Two-person procedural rules | Only as strong as the supervision that was just removed | | Local audit logs on the machine | Writable by an actor with unsupervised administrative access | | "Only staff can reach this network" | Restates the assumption you just dropped | What survives is anything whose strength comes from a party **outside** the assumed actor's control: an independently held record that can be checked against the electronic count, verification performed by someone who is not the operator, evidence written to a place the operator cannot rewrite, and totals published early enough that a later change is visible as a change. ## Rating moves too Threats that were rated low because they required a chain of coincidences are now rated on patience alone. A rating that quietly encoded "someone would be watching" has to be redone, not carried forward. If your model records a rationale per rating, this pass is mechanical; if it records only a number, you cannot tell which ratings were assumption-dependent — which is the practical argument for writing rationales down in the first place. ## The general lesson The exercise generalises to any actor change. Substitute a compromised package maintainer inside your build for the operator at the machine and the shape repeats: the actor arrives inside a process you drew as yours, build-time flows you never diagrammed become in-scope, and controls aimed at the network edge do nothing about them. The method is the same four steps — restate the dial that moved, mark the elements it now reaches, revive threats that were triaged out because of it, and re-test every control whose strength came from it. ## What a strong answer sounds like "The design did not change, the assumption did. Tampering and repudiation now dominate because the asset is the truth of the count; supervision was load-bearing for three of our controls and all three are now unsupported; internet-facing threats are unchanged; and the fix direction is evidence that a hostile operator cannot edit and verification by someone outside their control."