A secret store records only successful reads of stored credentials — which questions can that record no longer answer?
answer
- read, write, list, refusal
- listing is disclosure, not lesser reading
- a write dates the version
- a negative claim needs emitted events
- a stolen credential succeeds
basics
~20 sIt cannot say who changed a value or when a version appeared, who enumerated the names without reading them, or who was refused. Listing is disclosure, and an empty refusal history proves nothing if refusals were never emitted.
solid answer
~40 sA success-only record answers "who read it" and nothing else. It cannot say who **wrote** the value or when a version came into existence, so you cannot bound which consumers ever held the exposed copy. It cannot say who **listed** a branch of the name space — and listing is disclosure, because knowing which credentials exist, for which systems, is valuable even where every read is refused. It cannot say who was **refused**, so "nobody else tried" is unprovable rather than false. One caveat that matters: recording refusals is for attribution and scoping, not for catching theft. A stolen credential authenticates correctly and is allowed, so it appears as an ordinary successful read.
go deeper
Remember that a store can be asked to do four different things — read, write, list, refuse — and a record of only the first answers only the first.
Explain what each event family uniquely establishes, and why enumerating the names under a branch discloses something real even when every read is denied.
Demonstrate the scoping work: date the version from the write, bound the readers from the reads, and say plainly that a stolen credential shows up as an allowed read, not a refusal.
Treat event coverage as a requirement the estate sets before choosing or configuring a store, and state the claims the organisation must be able to support afterwards.
## Success-only is the default, and it is the default failure When a store's access record grows out of its debugging output, it records what the code path that served a value happened to emit: a successful read. Every other thing an identity can do to the store is either missing or thinned. That shape survives because it looks complete — the record is full of entries, queries against it return rows, and nothing announces the three questions it silently cannot answer. ## The four event families | Event | What only it can tell you | The cost of not having it | |---|---|---| | **Read** | which identity obtained the value, when, and which version | none — this is the family that is always present | | **Write** | who put this value here, and when this version came into existence | you cannot date the copy, so you cannot bound which consumers ever held it | | **List** | who enumerated what exists under a branch of the name space | disclosure of the estate's shape leaves no trace at all | | **Refusal** | which identity asked for something it was not granted | "no one else tried" is unprovable; a probe leaves nothing | ## Listing is disclosure, not a harmless subset of reading The instinct is to treat listing as a weaker read — you saw the names, not the values, so nothing escaped. That is wrong in a specific way. The names under a branch tell you which systems exist, which of them have credentials held centrally, which teams own what, and where the interesting material is. An identity that can list broadly but read narrowly has a map, and a map is what turns an opportunistic foothold into a targeted one. So a right to list is a grant worth recording and worth reviewing, and a record that does not distinguish a list from a read cannot support either. ## Refusals: what they are for, and what they are not for Refusal entries earn their place on two grounds. First, **attribution**: an identity that asked for something it was never granted has shown interest, and that request is often the only trace it leaves before it stops. Second, **provability**: after an exposure, the claim you actually want to make is a negative one — that no other identity was refused this value in that window — and a negative claim requires the events to have been emitted in the first place. An empty refusal history where refusals are not recorded proves nothing whatsoever; the same emptiness where they are recorded is evidence. The direction matters and is frequently stated backwards. **Refusals do not catch a stolen credential.** A stolen credential is a valid credential: it authenticates, it satisfies the rule, and the store serves it. It appears in the record as an ordinary allowed read, indistinguishable at the entry level from the workload that was supposed to make it. Judging which allowed reads look wrong is a separate discipline with its own baselines, and it is not what refusal alerting does. Anyone who tells you a refusal alert would have caught the theft has inverted the mechanism. ## What a complete record lets you claim With all four families present, these statements become checkable rather than asserted: 1. **These identities, and only these, read this value between these dates** — from reads, provided nothing was refused and nothing is missing. 2. **This version came into existence on this date and was served to these consumers** — reads joined to the write that created it. 3. **No identity enumerated this branch of the name space outside the expected set** — from list events. 4. **These identities asked for the value and were refused** — the population that showed interest without obtaining anything. ## Designs differ, so measure yours Stores differ in what they emit and how completely: some record every operation including refusals and listings, some record reads and writes only, some record administrative changes in a separate place from data access. Some emit a refusal for an unauthorised request but nothing at all for a request whose name does not exist, which quietly turns name-probing into a silent operation. The only reliable way to know is to perform each of the four operations deliberately against a value you own and go look for the four entries. Do that before an incident asks you to, because the answer you get during one is the answer you already had.
- Why does a write entry help scope an exposure, when the leak is about reading?It dates the version. Knowing when this copy came into existence bounds the set of reads that could have obtained it, and separates consumers that only ever held the earlier value from those that took the exposed one. Without it, every read of that name in the record is a candidate and the scope inflates to the whole retention window.
- An identity has list rights over a branch but read rights on nothing. Why review that grant at all?Because enumeration is disclosure. The names tell an attacker which systems hold centrally managed credentials, who owns them and which are worth a targeted attempt, turning a broad foothold into a specific one. The grant is cheap to hold and rarely questioned, which is exactly why it drifts.
- The record shows no refused reads for the whole period. What have you established?Only that no refusal entries exist, which is a statement about the record and not about the world. It becomes evidence once you have confirmed the store emits refusals at all, that the emitter was running, and that the sequence of entries is unbroken across the window. Establish those first, then the emptiness means something.
saying these in an interview costs you the question
- Treating refused reads as noise not worth recording
- Claiming refusal alerts would have caught a stolen credential
- Treating list as a harmless subset of read
- Recording reads but not who wrote the new version
- Reading an empty refusal history as proof nobody tried