In a payments back office, which Tampering control stops an operator authorized to edit the settlement file between extract and load?
answer
- the danger is at rest, not in flight
- per-hop versus end-to-end scope
- ask where the key lives
- an authorized writer passes every check
- narrow authorization or verify semantically
basics
~20 sProtect the artifact end to end, not the hops: the extract job signs the file with a key operators cannot reach, and the loader refuses an unverified one. Then narrow write access and reconcile totals.
solid answer
~50 sThe tampering happens at rest in the drop directory, between two hops that are each individually protected, so transport controls answer nothing here — the classic per-hop-versus-end-to-end trap. The right shape is that the extract job produces an integrity value over the file and the loader verifies it before loading, so the drop directory is never trusted; the key must live where the operator's account cannot reach it, or the signature only proves that someone with the key wrote the file. Next I ask whether the operator needs write at all — often read is the real requirement, and removing write is stronger and cheaper than any cryptography. Where a human must correct a file, route it through an approved path with a second approver. Finally, reconcile counts and control totals against the source system, because an authorized writer's change passes every integrity check by construction.
go deeper
Notice that a file waiting in a shared directory is exposed even when both transfers are protected, and that whoever can write the file can usually write the checksum next to it.
Explain end-to-end versus per-hop integrity, and why the location of the signing key decides whether the signature means anything against this particular attacker.
Demonstrate that you sized the attacker's position first: argue for removing write access before reaching for cryptography, bind metadata to defeat replay, and add reconciliation for the authorized-but-wrong case.
Own the trade between prevention and detection across the estate — where signing at origin is worth the key-management burden, where segregation of duties is the cheaper control, and how much residual risk you accept on reconciliation alone.
## The scenario A nightly extract produces a settlement file. It lands in a shared drop directory. An hour later an ETL job loads it and money moves against those figures. Operations staff have access to that directory — they use it to investigate failed runs — and that access includes write. The attacker position here is a **malicious or coerced insider with legitimate access**, and the assets are **money** and **audit truth**: the loaded figures become the record of what happened. ## Why the obvious controls do nothing **Transport protection.** The extract-to-drop hop and the drop-to-loader hop may both run over authenticated channels. That protects bytes *while they move*. The tampering happens while they *sit*. Any control scoped to a hop leaves every resting place between hops unprotected, and a batch pipeline is mostly resting places. Recognising per-hop versus end-to-end scope is the core insight of this question. **A checksum written by the same job into the same directory.** Whoever can rewrite the file can rewrite the checksum beside it. An integrity value only means something when producing a valid one requires something the tampering party does not have — a key, or a write path they cannot reach. **A signature whose key the tampering party can obtain.** If the signing key sits on a share the operators administer, or in a config file on a host they log into, the signature proves only 'someone with the key made this'. Key placement is the whole control. The signing key belongs on the extract host under an identity operators do not hold, ideally in hardware or a key service that will sign but not export. ## Controls that actually address it, in the order I would argue for them 1. **Remove the write.** Ask what the operators actually need. Usually it is read, for diagnosis. Split the directory: a landing path only the extract identity may write and only the loader may read, and a separate copy for humans. This is the strongest and cheapest control because it changes the attacker's position rather than adding a check they can pass. 2. **End-to-end integrity over the artifact.** The extract job computes a signature or message authentication code over the file contents plus its identifying metadata — run date, sequence number, record count — and the loader verifies before it processes a single record and fails the run loudly if verification fails. Binding the metadata matters: otherwise an insider can replay yesterday's genuinely signed file, which is tampering with the *stream* rather than the file. 3. **Separation of duties on the exception path.** There is always a legitimate reason a human must fix a broken file. Do not solve it by leaving write access on; provide a correction workflow where the person who prepares a change cannot approve it, and the corrected artifact re-enters the pipeline through the signing step rather than around it. 4. **Reconciliation.** Have the loader, or a downstream check, compare record counts and control totals against figures the source system publishes independently. This is the only control in the list that catches the case every integrity primitive is blind to: a change made by a party who *is* authorized and whose artifact therefore verifies perfectly. 5. **Attributable, tamper-evident records of who touched the artifact**, as a detective complement — not a substitute for the prevention above. ## The general principle to state out loud An integrity control excludes exactly the parties who lack the key or the permission. It does nothing against a party who holds them. So when a Tampering threat names an insider or a trusted partner, you have only two real moves: **narrow the authorization** so that party no longer qualifies, or **move verification up a level** to something semantic — reconciliation, plausibility checks, independent recomputation — that can disagree with a perfectly valid artifact. The same shape appears with a data partner who is allowed to write into a model-training bucket. Every object they upload is authorized, signed by their credentials, and structurally valid; poisoned training data is Tampering with a store whose damage only shows up much later, in model behaviour. No signature check will ever flag it. What helps is per-record provenance, so you can attribute and roll back a contributor's slice; validation and distribution checks on ingest; and a detection path that works long after the write. ## What the interviewer is listening for Three things. That you noticed the tampering happens at rest, not in flight. That you asked where the key lives instead of stopping at 'sign it'. And that you separated the case an integrity control can solve from the case only reconciliation and reduced privilege can solve. Candidates who answer 'use TLS and hashes' have not modelled the attacker's position at all.
- The insider cannot forge the signature, so they resubmit last week's genuinely signed file. Does your control hold?Not unless the signed content binds identifying metadata. A signature over the bytes alone proves origin but not freshness, so a replay of an authentic earlier file is still a Tampering threat against the stream. I would cover run date, sequence number and record count in what is signed, and have the loader reject a sequence it has already processed or one that is out of order, so replay fails as loudly as forgery.
- A vendor is authorized to write into your model-training bucket and uploads poisoned data. What changes?Nothing about the integrity primitives helps, because every write is authorized and structurally valid. This is Tampering with a store where the damage surfaces much later, in model behaviour rather than in a failed check. The controls that work are per-contributor provenance so a slice can be attributed and removed, validation and distribution checks at ingest, and evaluation that can detect the effect long after the write.
- Operations insist they must be able to hand-correct a broken settlement file. How do you accommodate that?Accept the requirement and move it onto a controlled path rather than leaving standing write access. The correction is prepared as a request, approved by a different person, and re-enters the pipeline through the same signing step as a normal extract, so the loader's rule never weakens. Standing write access for a rare exception is exactly the pattern that makes the threat easy; a slower, attributable path for the exception is the trade worth making.
saying these in an interview costs you the question
- Answers with transport encryption for data sitting at rest
- Signs the file with a key the tampering party can read
- Puts the checksum in the same writable directory
- Assumes a valid signature means the contents are correct
- Ignores that the insider is an authorized writer
- Offers logging as the primary preventive control