For a court e-filing system, how do you write security goals that can be falsified?

## Falsifiability is the whole test A security goal is useful when someone can describe a situation and you can answer, without argument, whether the goal held. That is what makes goals and threats fit together: a **threat is a hypothesised falsification of a stated goal**. If the goal cannot be falsified, threats cannot be tested against it, and triage has nothing to push against — every threat becomes arguable and the loudest voice wins. "The system shall be secure", "follow best practice", "protect the integrity of the docket" all fail this test. None of them can be shown false by any scenario, which is why they survive every review unchallenged. ## Anatomy of a goal that works A usable goal names four things: 1. **The asset** — what specifically is at stake. 2. **The property** — confidentiality, integrity, availability, authenticity, non-repudiation, privacy. 3. **The scope** — which actors, which data, which window. 4. **Who must be satisfied** — the receiving system, or a third party who was not there. The fourth matters more than people expect, because it is what separates authenticity from non-repudiation and therefore what a court system actually needs. ## The court e-filing case Start from what the system is for. The record is **largely public by design** — the court wants filings readable. So the confidentiality reflex misleads: it points a whole modelling session at the wrong threats. What genuinely destroys this system is a filing that is fake, altered, or disowned, and the interesting adversary is not an outsider but **an authenticated attorney denying a submission they made**. The asset is audit truth: the ability of the record to be relied on later. Written as falsifiable statements: - *A filing recorded as submitted by a bar member was submitted by that member.* Falsified by: an impersonated submission. Property: authenticity. - *An attorney who submitted an accepted filing cannot later credibly deny submitting it, to a party who was not present.* Falsified by: a plausible denial the court cannot resolve. Property: non-repudiation. - *The document the court reads is the document the submitter approved.* Falsified by: substitution or alteration between approval and docketing. Property: integrity. - *A sealed filing is readable only by the parties named in the sealing order.* Falsified by: any other reader. Property: confidentiality, deliberately scoped narrowly. - *A filer can submit during the final hour before a deadline.* Falsified by: a deadline-hour flood. Property: availability, with a window attached. Notice confidentiality did not disappear — it was **scoped** rather than dropped. Sealed material is a small, well-defined exception, and writing it as its own goal is far stronger than attaching a caveat to a system-wide confidentiality goal that is false for most of the record. ## Do not smuggle controls into goals The most common corruption is writing a mechanism where the outcome belongs. "Every submission must be signed" and "all actions must be recorded" are **controls**: they fix the answer before the question has been asked. State the outcome instead — the submitter cannot credibly deny the submission — and three things become possible: you can argue about which mechanism meets it, you can notice when the chosen mechanism does not, and you can tell whether a proposed replacement is adequate. A goal that names a mechanism can only ever be checked for the presence of that mechanism. Keep the four levels distinct while you are at it. A **goal** is what must hold. A **threat** is a way it might not. A **vulnerability** is the specific flaw that lets the threat happen. A **control** is what you do about it. Collapsing goal into control is the version that quietly ruins the model, because the model then stops being able to ask whether the control works. ## Availability and reputation goals These are the two most often written unfalsifiably. "Highly available" cannot be violated on paper; give it a scale, a window, and a subject — a legitimate filer submitting in the deadline hour — and a flood immediately becomes a threat against a stated goal rather than a vague worry. Reputation goals need an observable of the same kind, or they are slogans. ## Using goals in triage Once the goals are written, they become the contract that decides what stays. A threat that violates **no** stated goal is one of two things: genuinely out of scope, in which case say so and move on; or evidence that a goal is missing, in which case add it. Both outcomes are productive, and both are unavailable when the goals are unfalsifiable — with a goal like "be secure" on the page, every threat technically violates it and triage collapses. Finally, order the goals. Not all of them are equal here: authenticity and non-repudiation lead, integrity follows, availability is scoped to deadlines, confidentiality is scoped to sealed material. That ordering is a decision the business owns, and it is what a threat model is measured against later.