Cybersecurity

The survivability checklist

Here is the whole checklist first, because it is what a design review should walk through before the architecture sets, and because almost every line is cheap on the first device and a field retrofit on the thousandth. It is numbered so a line can be cited: "we fail 3.3" is a ticket, where "the update story feels weak" is a mood. The groups follow a system through its life — the decision about what to defend, the unit itself, every boot and every update, every dependency and every build, and the years it stays in service.

1. 1.The threat model

   1. 1.1It is written before the design, and its output is constraints the design has to meet rather than findings raised after it.
   2. 1.2It names the assets — this key material, this location history, this operator identity, this ability to command — never just "the system".
   3. 1.3It names the adversaries by what they can do: use weaknesses others found, find new ones, or plant their own in your supply chain.
   4. 1.4It states in writing what is NOT defended against, and names the person entitled to accept that risk.
   5. 1.5The design review records, in writing, what the system is for and what it must not be used for.

2. 2.Every device

   1. 2.1Each unit has its own identity, provisioned at manufacture, scoped to what that unit may do, and revocable from the fleet in minutes without touching any other unit.
   2. 2.2Keys live in hardware that will not export them — a secure element or a TPMTPMTrusted Platform Module — security chip on the boardA standard security chip on a computer’s board that holds keys it will not export, records what the device booted, and can release a secret only to that measured state. It raises the cost of pulling a key out of a captured device; it does not make it impossible for someone with a laboratory and time.All terms — and never in a file or in the firmware image.
   3. 2.3Data at rest is encrypted with the key held apart from it; only the working set is on board, and history leaves with the first link.
   4. 2.4The production image ships with debug ports, default passwords and service accounts closed, and a test on the image that actually ships proves it.
   5. 2.5Every link — command, telemetry and video alike — is encrypted and authenticated from the first version.

3. 3.Every boot and every update

   1. 3.1The boot chain is verified from a hardware root of trust, so replaced firmware produces a device that refuses to run.
   2. 3.2An update is signed, and the signature is checked by the bootloader — never by the application it is about to replace.
   3. 3.3The device refuses a downgrade, so nobody can reinstall last year’s signed version with last year’s hole.
   4. 3.4A new image is written beside the running one, and the device falls back automatically if it does not come up healthy.
   5. 3.5Rollout is staged, and no single credential, server or person can push code or commands to the whole fleet at once.

4. 4.Every dependency and every build

   1. 4.1Every dependency has an owner, a recorded source and a reason to exist; adding one is a decision, not a keystroke.
   2. 4.2Dependencies are pinned and mirrored, and no build fetches anything from a public registry.
   3. 4.3Every build produces an SBOMSBOMSoftware Bill of Materials — a list of what is insideA machine-readable inventory of every component a piece of software is built from, including the dependencies pulled in by other dependencies. It matters on the day a vulnerability is announced: without one, the question "are we affected?" is answered by guessing.All terms, so "are we affected?" is answered in minutes, not in a week of grep.
   4. 4.4The build is reproducible from the source repository, and build machines are run as production.
   5. 4.5Signing keys sit in an HSMHSMHardware security module — tamper-resistant key storeA tamper-resistant device that stores cryptographic keys and performs signing inside itself, so the key is used but never handed out. A compromised build server can still ask it to sign, which is why production signing also needs a log and a second person.All terms, never on a laptop or in a CICI/CDContinuous Integration / Continuous Delivery — automatic build, test and deliveryEvery commit is built and put through the tests automatically (CI), and a build that passes travels to the servers the same way (CD). The point is not automation for its own sake: it is that a breakage shows up in minutes instead of on release day.Full article →All terms variable; a release signature needs two people, and every signature is logged.
   6. 4.6Where the source, the builds and the keys physically live is checked against export control, because a repository’s region is an export decision.

5. 5.Every year in service

   1. 5.1Algorithms sit behind an interface and can be replaced by an update, because twenty years outlives the assumptions they were chosen under.
   2. 5.2Security events are logged in a form that whoever holds the device cannot quietly edit, and leave with the first link.
   3. 5.3There is a published way to report a vulnerability, and a named person whose job is to answer it.
   4. 5.4Keys are rotated on a schedule, and a retired unit is wiped by a documented procedure, not by whoever happens to decommission it.

The threat model is written first, and it names what it accepts

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 — line 1.1.

A usable model answers four questions in writing, and the fourth is the one usually skipped. What are we protecting — not "the system", but specific assets: this key material, this location history, this operator identity, this ability to command (line 1.2). Who is trying, with what resources and what patience (1.3). What each of them gains from succeeding. And what we are NOT defending against, stated explicitly (1.4) — because a model that claims to defend against everything has made no decisions, and will be quietly abandoned the first time it is inconvenient.

"Funded and patient" needs a scale, or it stays a mood. The one this field uses most comes from the US Defense Science Board’s 2013 report on resilient military systems. It sorts adversaries into six tiers by what they can do with vulnerabilities rather than by who they are, which is exactly what line 1.3 asks a threat model to write down.

Two things follow, and both surprise people. The bottom of the scale is not a formality to tick off on the way to the interesting threats: when GAO reviewed the US Department of Defense’s own weapon-system tests in 2018, the testers got in with simple tools, default passwords and unencrypted links. And the top of the scale is where line 1.4 earns its place. Nobody fully defends against an adversary who can spend years planting a weakness in a supplier. A model that pretends to has decided nothing; a model that says so can at least decide how much one such compromise is allowed to reach.

One more question belongs in the same document, and it is the one engineers most want to hand to somebody else. A great deal of this software is dual-use: the same detection pipeline serves search and rescue, wildlife surveys and border monitoring. That is a real property of the field, and it is not a licence to skip the question of what a particular system is for. Line 1.5 puts the answer in the design review, in writing, next to the threat model — partly because the intended use shapes the threat model, and partly because a decision nobody wrote down is a decision nobody made.

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 units will not come back, and some of those will be examined by someone with time, tools and motivation. It is not hypothetical: in December 2011 Iran put a largely intact US RQ-170 reconnaissance drone on television, and the US government asked for it back. Designing for that is not pessimism; it is the difference between losing a device and losing a fleet.

The third guarantee in the diagram 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. That is line 2.1, and the diagram below draws the two outcomes side by side.

The left panel is not a thought experiment. In 2016 the Mirai botnet grew to some 600,000 cameras and routers by trying a list of about sixty factory passwords, because whole product lines shipped with the same one — a fleet-wide secret in its purest form. Regulation has since caught up with the weakest version of line 2.1: since April 2024 the UK has banned universal default passwords on consumer devices. A defence system should not need a law to reach the floor that consumer cameras are now held to.

The chain of trust, and the update path as the best target you own

Every device needs a way to receive new code, and that mechanism deserves to be read plainly: it is the only component with authority over the entire fleet. Whoever controls it controls every unit at once, without touching any of them. That makes the update path the most attractive target you own, and it is the reason group 3 of the checklist exists.

The defence starts at power-on, with a chain of trust. The boot ROM is code fixed in silicon at manufacture, holding the hash of the one key it trusts; no update can change it, which is exactly why it can be trusted. It checks the bootloader’s signature before running it, the bootloader checks the kernel, and the kernel checks the application. Replace any link with something unsigned and the device refuses to run, rather than running the replacement — line 3.1. The same chain decides where an update is checked: in the bootloader, below the application being replaced, because an application cannot be trusted to vet its own successor — line 3.2.

The Viasat case is worth reading slowly, because nothing in it was forged. On 24 February 2022 attackers entered the satellite network’s management segment through a misconfigured VPNVPNVirtual private network — encrypted tunnel into a networkAn encrypted tunnel that lets a remote machine join a private network as if it were inside it. The appliance at the end of the tunnel is a door into everything behind it, so its configuration is as sensitive as any password.All terms appliance. Then they used the network’s own management function to send commands to tens of thousands of modems at once; a wiper overwrote their flash, and the modems never came back. Every check that asks "is this a genuine command from us?" would have answered yes. Line 3.5 is the one that helps: no single credential, server or person should reach the whole fleet in one step, so that even a genuine channel in the wrong hands meets a stage it cannot skip.

Every dependency is a decision with an owner

A funded adversary looks for the cheapest way in, and in a well-built product the cheapest way in is rarely the product. It is a dependency nobody reviews, a build machine nobody hardened, a signing key within reach of too many people. The diagram pins a documented attack to every stage between a commit and a device, and the pattern is the point: none of the six broke the product’s cryptography.

Line 4.4 carries more weight than it looks. In both SolarWinds and xz the source repository was clean: the malicious code existed only in what the build produced or in the archive the release shipped. A reproducible build — one where anyone can rebuild the artefact from the repository and get the same bytes — turns "the binary matches the source" from a belief into a check, and it is the only check on this page that would have caught either of them before release.

Line 4.6 is legal rather than technical, and worth knowing before taking the work rather than after. Much of this software is export-controlled, which restricts who may hold the source, where it may be built and who may be told what it does — a rule that reaches into decisions as ordinary as which cloud region a repository lives in. The rule binds your suppliers as much as you. In 2017 the Australian Signals Directorate described an intruder who spent months inside a 50-person aerospace subcontractor and took about 30 GB of data, including export-controlled material on the F-35 and the P-8 Poseidon. Internet-facing services there still had their default passwords: admin and guest.

Twenty years in service

Ten to twenty years in service is normal here, and it changes decisions that look settled. Every dependency will outlive its maintainers’ interest in it. Every algorithm will outlive the assumptions it was chosen under. And "we will rewrite it later" becomes a claim somebody will hold you to. Group 5 of the checklist is what keeps a system defensible in year fifteen, when nobody who designed it is still on the team.

Cryptography is where this is most concrete. NIST published its first post-quantum standards, FIPS 203, 204 and 205, in August 2024, and the NSA’s CNSA 2.0 guidance asks national security systems to prefer quantum-resistant signatures for software and firmware by 2025 and to use them exclusively by 2030. A device fielded today with one signature scheme fixed in its boot ROM will still be in service after that date. Line 5.1 is the answer — algorithms behind an interface, replaceable by an update — with one hard exception worth planning for: the ROM’s own check cannot be updated, so the choice made there has to anticipate the whole service life, for example by picking a chip that holds several root keys and can revoke one.

• Crypto you can replace (5.1)

  Algorithms behind an interface and negotiated rather than hardcoded, so an update can move the fleet to a new one. Everything above the ROM should be replaceable this way.

• Logs that survive the device (5.2)

  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.

• A way to receive bad news (5.3)

  A published contact, a policy for reports from outside, and a named person who answers. Researchers find things; the only question is whether they can tell you or have to tell somebody else.

• Retirement is a procedure (5.4)

  A unit leaving service still holds keys and data. Wiping it is a documented step with a record, and its identity is revoked in the fleet the same day, not whenever somebody notices.

Eight compromises, and the line that covers each

Defence programmes rarely publish their compromises, so most of these are civilian, and the page says so openly: the mechanisms transfer exactly. Two come from defence itself — the Predator video feeds and GAO’s review of weapon-system tests — and one hit military communications on the first day of a war. Each carries the checklist line that would have covered it.

Where it turns into theatre

The honest limit is the top of the adversary scale and the person already inside. An adversary who can spend years planting a weakness in your supply chain, or an insider with legitimate signing rights, will get past controls designed for everyone else. Hardware that refuses to export a key raises the cost of extracting it without making that cost infinite for someone with a laboratory and time. No builder-side decision removes those threats. What the decisions on this page do is bound them: per-device identity limits what one extracted key opens, staged rolloutstaged rolloutan update released to a growing share of usersReleasing an update to a small share of users first — 1%, then 5%, 20%, everyone — and checking crash and error rates before each step, so a bad release reaches a few people instead of all of them. It limits how many a bad release reaches, not whether it reaches them: on the app stores a halted rollout does not take the update back from those who already have it.All terms limits what one bad release reaches, and logs that survive the device make a compromise something you can find afterwards. The page stops there on purpose. How a fielded system is monitored, patched and defended day to day is operations, a different discipline with its own literature.

• A threat model that defends against everything and accepts nothing, so nobody consults it after the first deadline.
• A security review scheduled after the architecture freezes, where findings are argued with rather than fixed.
• "Air-gapped" in the design document, and a USB stick in the ground station.
• An SBOM generated on every build and read by nobody.
• "Encrypted at rest", with the key in the same flash as the data.
• Signed releases, signed by a key that lives in a CI variable.
• A penetration test before the first delivery, and never again across twenty years.
• A staged rollout whose stages all start within the same hour.
• A vulnerability inbox that nobody reads, so researchers report somewhere else.

When to use it

Related pages

• DeftechComputer visionComputer vision is the practice of turning camera images into detections a machine or a person can act on, and the model is rarely the hard part of it. What makes it hard here is that it runs on a device with a power budget and no network, on images unlike the ones it was trained on, feeding a decision where the two kinds of error are paid for by different people. The page opens with twelve field failures, the cause behind each and the check that catches it, then covers the budget on the device, the data problem, the threshold as a policy, what has to be recorded, and seven documented failures.
• DeftechData platformsA data platform is the stack that collects, stores and moves an organisation’s records, and one built for a reliable network sends first and stores as a side effect. Invert that assumption and the architecture inverts with it: the node writes locally and always, and sending becomes an opportunistic background activity that may not happen today. The page opens with twelve ways a disconnected platform loses or corrupts data, each with the design that prevents it, then covers the priority queue, the receiving side that expects to be interrupted, what every record carries, evidence as a deliverable, twenty years of formats, and seven documented cases.
• DeftechDrone softwareDrone software is the flight code on an uncrewed aircraft and the ground software commanding it, built to stay safe when the link, position or battery fails. An uncrewed aircraft is a distributed system in which one node falls out of the sky if it misses a deadline, and that one fact decides which code runs where, what may block and what may crash. The page opens with the twenty-five-line flight-readiness checklist, then covers the stack as a hierarchy of deadlines, the failsafe ladder as the real specification, the return decision as an energy calculation, autonomy as a list of decisions, simulation as the test environment, and seven documented accidents.