We can seal it, not open it
Emergency plans usually sit in exactly the system that is gone when it matters. Our new emergency kit therefore starts from an uncomfortable assumption: in an emergency, the platform itself is the compromised side.
Most emergency plans share one fate. They are carefully written, regularly reviewed, neatly linked, and they sit in the system that has just been encrypted.
We built a module for exactly that case. It produces an encrypted, signed emergency package with its own offline viewer from existing data and places it on emergency laptops. Without a network and without servers, the crisis team reaches recovery plans, the BIA including RTO and RPO, backup plans with storage locations, asset, rack and network inventory, contact details and the released documents.
What is interesting is less what goes in. What is interesting is the assumption behind it.
The threat model includes us
The data model states the sentence that governs everything else: in an emergency the platform is the compromised side. Anyone planning for a ransomware incident has to plan for the ISMS being affected too. If a recoverable secret sat on the server, an attacker with database access would hold not one emergency package but every one of them.
So there is none. The platform only knows the public part of the key. The private part is created exactly once, in the response to the request that generates it, and is overwritten server-side immediately after. From then on it exists only on paper, in the safe.
The result is a capability you rarely see phrased this way: we can seal packages and open none of them.
What is deliberately not in the package
Credentials. No passwords, no keys, no tokens. What is in there is where to find them, in the form a human can use at three in the morning: which envelope, which safe, which room, which person.
That is not a technical gap but a boundary. An emergency package containing credentials is loot. One that only names their place of custody is not.
The test that actually proves something
The module distinguishes three kinds of evidence, and the difference is the point.
Signature verification shows that a file exists, is validly signed and matches its checksum. Nothing more. The opening test shows the package can actually be unsealed. And the exercise shows that people manage it under time pressure.
Only the second finds the case that really hurts. After a mainboard swap or a reset TPM the file is flawless, the signature valid, the checksum correct, and the device key is gone. A pure file check reports green at that point.
So the module tracks measured time-to-open as a metric of its own. It is the only number that says anything about the real event, and in our experience the one an auditor asks for.
Green does not mean ready
The same distinction applies to the emergency laptops. Designated devices hold not just the portable extract but a full instance image, from which a productive instance can be rebuilt after the crisis.
Until recently the platform only knew whether that package was fresh. Whether the device even had a container runtime and whether the stack had ever come up was recorded nowhere. A node could look green for months and turn out to be nothing more than a laptop with an encrypted file on it. That gap is now closed.
The status indicator, by the way, measures the age of the data, not the last agent contact. An emergency laptop in a safe is offline for weeks, and that is precisely the intended state.
More on the emergency kit module page.
Questions about this update?
Talk to us – we are happy to show you this feature in a demo.