Cybersecurity
Cybersecurity for defence systems starts from a different threat model than the rest of software: ordinary application security assumes an opportunist on the far side of a network boundary, and a patch you can ship on Tuesday. Neither assumption survives here: the adversary is funded and patient, the boundary eventually fails completely because the hardware ends up in someone else’s hands, and the fix may not reach the device for months. This page is about what a builder does in response — the capture assumption, the supply chain, key management, and an update path that is itself the most attractive target you own.
- Design assumption
- The device is lost
- Threat model is
- Written first
- Best target you own
- The update path
The threat model is written first, and it constrains the features
In most software a threat model is a review artefact: the design exists, someone walks it, a list of findings comes out, and a few of them get fixed before release. That ordering works when the findings are small and shippable. It fails completely when a finding means the architecture is wrong, because by then the architecture is what everyone is standing on. Here the model is written before the design and its output is a set of constraints the design has to satisfy.
A usable model answers four questions in writing, and the fourth is the one usually skipped. What are we protecting — not "the system", but the specific assets: this key material, this location history, this operator identity, this ability to command. Who is trying, with what resources and what patience. What does each of them gain from succeeding. And, critically, what are we NOT defending against, stated explicitly — because a model that claims to defend against everything has made no decisions and will be quietly abandoned the first time it is inconvenient.
Assume the device ends up in somebody else’s hands
This is the assumption that separates the domain, and it is worth stating as an expectation rather than a disaster. A deployed unit is unattended, sometimes for a long time, in a place you do not control. Some proportion of them will not come back, and a proportion of those will be examined by someone with time, tools and motivation. Designing for that is not pessimism; it is the difference between losing a device and losing a fleet.
The third guarantee in the diagram is the one that decides the size of the loss, and it is an architectural decision rather than a cryptographic one. If every device holds the same shared secret, or credentials that authenticate it as a general member of the network, then one device examined at leisure yields access to everything. If each device has its own identity, scoped to what that device is allowed to do, and the fleet can revoke it, then the same event costs you one device. The cryptography is standard in both cases; the difference is entirely in what the credential is allowed to open.
What holds after a loss
- A per-device identity, revocable from the fleet without touching any other unit.
- Keys held in hardware that will not export them, and erased when the enclosure is opened.
- Data encrypted at rest, with only the working set present and history already offloaded.
- A verified boot chain, so replacing the firmware produces a device that refuses to run.
What turns one loss into all of them
- A shared secret or a fleet-wide credential, so one unit authenticates as any unit.
- Keys in a file on the filesystem, which is a copy operation rather than an attack.
- A full local history of everywhere the device has been and everything it saw.
- A debug port or a service account left enabled because it was useful during development.
The supply chain, and the update path as a target
A funded adversary looks for the cheapest way in, and the cheapest way in is rarely the product. It is a dependency nobody reviews, a build machine nobody hardened, or the mechanism you built specifically to push code to every device at once. That last one deserves to be read plainly: the update path is the most attractive target you own, because it is the only component with authority over the entire fleet.
- Know what is in the build. A dependency inventory produced automatically at build time, so the question "are we affected by this" has an answer in minutes rather than a week of grep.
- Make the build reproducible, so an artefact can be rebuilt from source and compared. Without it, "the binary matches the source" is a belief rather than a check.
- Treat the build system as production. It holds signing keys and produces the thing everyone trusts; a build agent anyone can submit a job to is a signing service anyone can use.
- Sign the artefact and verify on the device, with the verification in the boot chain rather than in the application that is being replaced.
- Roll out in stages with an automatic rollback, because a bad update that reaches every device simultaneously is indistinguishable in effect from a successful attack.
- Make the device refuse a downgrade, or an adversary simply asks it to install last year’s version with the vulnerability you already fixed.
What this changes in ordinary development
None of the above requires exotic technique. It requires a handful of decisions to be made early, because each becomes progressively more expensive to retrofit, and a couple of practices that ordinary teams treat as optional.
Identity per device, from day one
Provisioned during manufacture, revocable, scoped. Adding this later means touching every device you have already shipped, which is why it is almost never added later.
Logs that survive the device
Security-relevant events offloaded when there is a link, and appended locally in a form that cannot be quietly edited by whoever holds the device afterwards.
Crypto you can replace
Algorithms behind an interface and negotiated rather than hardcoded, because a twenty-year lifecycle outlives the assumptions any particular algorithm was chosen under.
A way to receive bad news
A published contact and a policy for reports from outside. Researchers find things; the only question is whether they can tell you or have to tell somebody else.
Anti-patterns worth naming
- A shared secret across the fleet, which converts a single lost device into access to everything.
- A signing key on a laptop or in a CI variable, so compromising a developer compromises every device.
- An update path with no staged rollout, where a bad release has the same reach as a successful attack.
- A debug interface left enabled because it was useful during development, which is the first thing anyone looks for.
- A threat model that defends against everything, names nothing as accepted, and is therefore abandoned at the first deadline.
When to use it
Use it when
- Before the architecture is settled, because a threat-model finding that late is a rewrite rather than a fix.
- For any device that will be unattended in a place you do not control, which is the capture assumption.
- When designing the build and update path, which is the component with authority over the whole fleet.
- For long-lived systems, where crypto agility and a dependency inventory pay for themselves several times over.
Avoid it when
- As a substitute for a threat model specific to your system, which no page can supply.
- As a reason to defend against everything, which produces a document nobody uses and no decisions.
- As operational security guidance — this page is about what a builder decides, not about how a system is run.
- Where the device is never out of physical control and the fleet is small enough to update in a day.
Found this useful?
Share it with someone who is working on the same problem.