"A hacker breaches the plant historian, causing a security breach" — what standard do you set for threat statements?

## What is actually wrong The sentence has an actor and an impact, so it passes a naive structural check. It still fails, because both slots are filled with placeholders. **"A hacker"** describes no position. Threat statements are argued over access: can this person reach that interface at all, and with what credentials? "A hacker" pre-empts that conversation by asserting an unbounded adversary, which means every statement written with it is simultaneously true and useless. It also invites the escalating-label failure — "a nation-state actor" is not more bounded, it is just a bigger word. **"A security breach"** is not a loss. Nothing an engineer or an operations manager does is changed by it. The impact slot exists so that someone outside the security team can weigh the statement, and a phrase only security people use defeats that purpose. The combined effect is an **unfalsifiable** statement: nobody can dispute it on facts, nobody can build a test that would show it no longer holds, and "closed" can only ever be a judgement call. A backlog of these is why threat models get waved through and then ignored. ## The rewrite For a district-heating operator's process historian: > *A maintenance contractor's laptop, attached to the plant network for a scheduled service visit and holding the historian's shared service credentials, writes falsified temperature and pressure points into the archive, so operators and the annual safety review see a heating loop that never exceeded its limits when it did — hiding an over-pressure event and deferring a repair.* Every part of that can now be argued. Does the contractor laptop actually reach the historian, or only a jump host? Are the credentials genuinely shared? Does anything downstream consume archived points for the safety review, or only live values? Each of those is a question an engineer who owns the system can answer in a sentence, and any "no" either kills the statement or sharpens it. That is what a good statement buys you. ## The standard, in three rules 1. **Actors come from a shared list of positions, not from imagination.** Publish six to eight positions the organisation actually faces — anonymous internet client, authenticated low-privilege user of another tenant, employee with a legitimate console login, contractor device on an operations network, compromised build or dependency, compromised vendor or operator — and require every statement to pick one and say what access that position already holds. This one lever removes more vagueness than any amount of template. 2. **Impact is stated in the owner's vocabulary.** Not "integrity is violated" but "the archive no longer reflects what the plant did." Not "availability impact" but "dispatch decisions are made blind during a cold snap." The test is whether someone who has never read a security document can tell you whether they would care. 3. **A statement is finished when it is disputable and testable.** The owning engineer can name a change that would answer it and a check that would show it no longer holds; a peer can argue it is wrong. If neither is possible, the statement is not ready, whatever slots it has filled. ## The tradeoff a lead actually owns There is real tension between rigor and throughput. Insisting on polished statements inside the modeling session kills the session — the value in the room is breadth, and people stop volunteering ideas when each one is edited in front of them. Insisting on nothing produces the sentence at the top of this question. What works is splitting the two: rough phrasing in the room, tightened by the scribe within a day or two, then walked past the component owner. The tightening pass is where the actor gets bounded and the impact gets translated, and it is short because the shared actor list does most of the work. Resist making the template heavier. A gate that rejects statements on format teaches people to write for the gate; you get five perfectly-slotted sentences describing the same tedious threat and nothing about the one that matters. Coach at review time instead, and use a handful of exemplar statements from your own systems as the reference — engineers copy examples far more reliably than they follow forms. Finally, be explicit about the audience. Threat statements are written for the engineer who has to answer them, not for a report or an external reader. When statements start being drafted to look thorough rather than to be answered, the vocabulary drifts back toward "a hacker" and "a breach", because those are the phrases that survive being read by someone who will never act on them.