A decommissioned volume from a secret store node and a months-old store backup turn up on a workstation - is either a disclosure?
answer
- the artefact alone decides nothing
- ask where the opening material lived
- co-located key means no protection
- an old copy opens under old material
- bound it by what was replaced since
basics
~20 sYou cannot tell from the artefacts. It turns on custody: whether the material that opens each copy ever sat with it, whether it still exists and is reachable, and which values inside have been replaced since.
solid answer
~50 sNeither artefact answers the question by itself - ciphertext plus the key that opens it is plaintext, and ciphertext without it is noise, so the finding is about custody, not about the files. I would establish three things for each copy. First, was the opening material ever stored alongside it: a backup written into the same archive as the material that unwraps it is a disclosure outright. Second, does that material still exist and can this holder reach it - and note that an older copy opens under whatever was current when it was written, so a later change of the protecting key does not close it unless the earlier material was actually destroyed. Third, which values inside have been replaced since the copy was taken, because that is what bounds the exposure. I would also check whether the volume carries plaintext the store wrote outside its dataset files.
code
pseudocode · 18 lines// foundCopy: a volume image or a backup file recovered from outside the fleet
if openingMaterial.wasStoredWith(foundCopy):
disclosure = every value in foundCopy // ciphertext and key travelled together
else if openingMaterial.versionThatOpens(foundCopy).stillExists():
disclosure = values in foundCopy
where not replacedSince(foundCopy.takenAt)
else if destructionOf(openingMaterial).isEvidenced():
disclosure = none // claim, not assumption - needs evidence
else:
disclosure = unknown -> treat as every value not replacedSince(foundCopy.takenAt)
// applies to a volume image regardless of the branch above:
alsoInspect(foundCopy) for plaintext written outside the store's dataset files:
temporary files, diagnostic output, paged-out memory, a crash dump of the store processgo deeper
Recall that ciphertext plus the key that opens it is plaintext, so the first question about any recovered copy is where that key was kept and where it is now.
Explain why an older copy still opens: it was written under the material current at the time, and a later change of protecting key does not reach backwards unless the earlier material was destroyed.
Run the triage out loud - custody, reachability, which material opens it, what has been replaced since - and state the bound you would put in the finding rather than a verdict of safe or burned.
Decide what the organisation must be able to prove about copies it no longer controls, and make custody and replacement records exist before an incident needs them.
## Why the artefacts tell you almost nothing Two objects have surfaced: a volume that left a store node during a decommissioning, and a backup file some months old. Both are, on their face, ciphertext. That fact alone supports no conclusion in either direction, because the value of ciphertext is entirely a function of who can reach the material that opens it. The finding you are writing is about **custody and time**, not about the bytes. The instinct to close this as 'no impact, the store encrypts at rest' is the specific error this scenario is designed to catch, and so is the opposite instinct to declare every value in the estate burned. ## The four questions that decide it 1. **Was the opening material ever co-located with the copy?** A backup written into the same archive as the material that unwraps it, or a volume image that includes whatever the node used to unlock itself, is plaintext in a thin wrapper. This is the single most common way an encrypted backup turns out not to be one. 2. **Does that material still exist, and can this holder reach it?** Ciphertext is inert only while that stays true. A copy sitting in a desk drawer is a disclosure deferred: it becomes one the day the material surfaces, and it does not expire on its own. 3. **Which version of the protecting material opens this copy?** An older copy opens under whatever was current when it was written. Changing the protecting key afterwards bounds future copies; it does not close this one unless the earlier material was genuinely destroyed everywhere it existed. 4. **Which of the values inside have been replaced since?** This is what turns an unbounded finding into a bounded one. A copy whose every value has since been replaced exposes credentials that no longer work anywhere; a copy full of values untouched for two years exposes live access. ## The volume needs one extra check A block-level copy of a store node captures the store's dataset files, which are ciphertext, and that is the reassuring half. The unreassuring half is anything the node wrote **outside** those files while it was running: temporary files, diagnostic output, memory paged out by the operating system, or a crash dump of the serving process. None of that is covered by the store's own file encryption, and a volume taken from a machine that was serving is exactly where it accumulates. Treat the volume as two artefacts in one. ## Two clocks run against the backup Age cuts both ways and settles nothing by itself: - **In your favour:** the older the copy, the more of its values have probably been replaced since, so the live exposure shrinks over time - but only if replacement actually happened, and you should confirm that per value rather than assume a schedule ran. - **Against you:** the older the copy, the more likely its opening material has been copied, escrowed, re-homed or simply forgotten in a place with weaker controls than the store itself. ## What the finding should say The honest default is to treat each copy as a disclosure of **every value in it that has not been replaced since it was taken**, and to downgrade only on evidence, not on the presence of encryption. Evidence means both halves: that the opening material was never stored with the copy and is now beyond this holder, and that the values inside have been replaced. One half alone leaves you guessing. The remediation follows from the bound, not from the artefact: replace the values that are still live, in an order you choose deliberately, and then destroy the copies. Destroying the copies first feels decisive and fixes nothing, because you have no way to know whether they were read while they sat there. ## What this scenario is really testing Interviewers use it because it separates two mental models. The weaker one treats 'encrypted at rest' as a property of the system that travels with any copy of its data. The stronger one treats it as a statement about one specific attacker - the offline holder - and immediately asks where the key is, how long it has been that way, and what the contents are still worth. Everything else in the answer follows from asking those three things out loud.
- What evidence would let you downgrade this from a disclosure to a near miss?Both halves, documented. That the material opening that copy was never stored with it and is now destroyed or beyond this holder, and that every value inside has since been replaced. With only the first you are trusting a custody claim nobody verified; with only the second you have bounded the damage rather than ruled it out.
- Why does the age of the backup not settle the question on its own?Two clocks run in opposite directions. Values inside may have been replaced many times since, shrinking what the copy still exposes; meanwhile the material that opens it has had longer to be copied, escrowed or re-homed somewhere with weaker controls. Age favours neither side until you check both.
- The team wants to shred both artefacts immediately. What do you say?Shredding is the last step, not the first. Destroying the copies removes nothing that was already read from them and destroys the evidence of what they contained. Establish what is inside, replace the values still live, and then destroy the copies and record that you did.
saying these in an interview costs you the question
- Closes it as no impact because the store encrypts at rest
- Assumes changing the protecting key made the old backup unreadable
- Treats ciphertext as safe forever rather than until the key surfaces
- Ignores plaintext the node wrote outside the store's dataset files
- Destroys the artefacts before establishing what was in them
- Declares the whole estate compromised without bounding it by replacement