Hashing, canonical payloads, immutable storage and the run metadata that lets an auditor re-derive an artefact you collected nine months ago.
50 min 210 XPSkills: Integrity, Evidence, Storage
Brief
An auditor does not only ask whether the control worked. They ask how they can know the artefact in front of them is the one the system produced, unaltered, on the date it claims. That is integrity, and it is a property of the pipeline, not of the file.
Integrity has three parts: a canonical form of the payload, a digest over that canonical form, and a record of who or what could have touched it since. Miss any one and the artefact degrades into a screenshot with extra steps.
Evidence you cannot re-derive is testimony. Evidence you can re-derive is measurement.
Custody is a chain, and it starts at collection
The chain runs source → collector → canonical payload → digest → store → reader. Each hop must record what it received and what it emitted. If the collector reformats JSON, sorts keys differently, or drops a timezone, the digest changes for reasons that have nothing to do with the control, and every hash comparison becomes noise.
That is why canonicalisation comes before hashing: fix key order, encoding, number format and timestamp representation, then digest the bytes you fixed.
Every hop records what it received and what it emitted. A gap is a break.
Where you put it decides what it proves
A bucket the collector can overwrite proves the artefact existed at read time and nothing more. Object-lock, write-once retention or an append-only ledger changes the claim from 'this is what we have' to 'this is what was written, and nothing since could change it'.
Retention is part of the same argument. If the audit period is a year and your lifecycle policy deletes objects after ninety days, you have built a pipeline that destroys its own evidence on schedule.
Overwritable storage cannot support a claim about the past.
Run metadata is the other half of the artefact
A stored payload without run metadata is unmoored. Record the run id, the query or endpoint issued, the window it covered, the records evaluated and the collector version. Those five fields are what let a reader in month eleven reconstruct what a green result in month two actually examined.
This is also the defence against the most common integrity failure of all: an empty file that means 'nothing was wrong' being indistinguishable from an empty file that means 'nothing ran'.
Hash the payload; sign the run. One proves the bytes, the other proves the collection.
Tasks
Answers are graded on the server: the answer key never reaches your browser.
Task 1: The hash that changed on its own
Scenario sim+70 XP
Name the missing pipeline step, then what should be digested.
Incident brief
The evidence store recomputes digests nightly and alerts on mismatches. In March it fires on 140 artefacts at once and the security team opens a suspected-tampering incident.
Nothing was tampered with. The collector library was upgraded and now serialises JSON with keys in insertion order rather than sorted, and writes timestamps with an offset instead of Z.
An engineer proposes turning off the nightly comparison because it 'produces false tampering alerts'.
1.2Name what the digest should be taken over. (two words)
Task 2: Deleted on schedule
Scenario sim+70 XP
Name the storage property that is missing, then the policy that destroyed evidence.
Incident brief
Evidence lands in a bucket the collector writes to with full permissions, because early on the team needed to re-run collections and overwrite bad files.
In November the auditor requests January artefacts. They are gone: a lifecycle rule added in June deletes objects after ninety days to control storage cost. Some February artefacts exist but their digests differ from the ones in the run log.
The team offers to re-run the collectors for January.
Term bank, not all of these are right
immutabilityretention policyencryptionversioningavailabilityaccess control
2.1Name the missing storage property. (one word)
2.2Name the setting that destroyed January's evidence. (two words)
Task 3: Signed by the intern's laptop
Scenario sim+70 XP
Name what breaks the chain here, then the field that would identify the producer.
Incident brief
Artefacts are hashed and stored immutably. The digests are recorded in a spreadsheet a contractor maintains, and the collection runs from a laptop using a personal API token because the service account was never provisioned.
The contractor's engagement ends in April. In September the auditor asks who or what produced the July artefacts and how the digest list is protected from edits.
Everyone agrees the data itself is fine.
Term bank, not all of these are right
chain of custodyrun metadataprovenanceintegrityretentionsampling
3.1Name the property this breaks. (three words)
3.2Name what should identify the producer of each artefact. (two words)
Labs
80 bonus XP
Hands-on work. You edit the artefact, the server runs the checks: the expectations and the reference solution never reach your browser.
The evidence store manifest for the MFA collector was written when "we hash everything" was the whole integrity strategy. The nightly digest comparison now alerts whenever the collector library changes its serialisation, and the team wants the comparison switched off.
Fix the manifest instead. It needs deterministic canonicalisation before hashing, a real digest algorithm, a store that cannot be overwritten, retention that outlives the audit period plus report lag, and run metadata that makes an empty result provable.
Store review notes and programme requirements
incident: 140 digest mismatches in March, caused by a library upgrade
(key order changed, timestamps written with offset instead of Z)
programme requirements:
audit period : 12 months
report lag : up to 3 months after period end
evidence retention: 7 years (2555 days)
digest algorithm : sha256 or stronger; sha1 and md5 are prohibited
storage : write-once; the collector must not be able to overwrite
auditor question that must be answerable:
"how many accounts were evaluated on 14 August?"
An internal review of the evidence store produced eight observations. You can escalate only the ones that would stop an auditor relying on the artefacts.
Raise what genuinely compromises integrity, custody or availability of evidence. Leave the housekeeping.
List only the lines that qualify, worst first. Severity is one of: critical | high | medium | low. Add or delete rows as needed.
Evidence store review: observations
I-1 The collector holds write and delete permissions on the bucket; February digests no longer match the run log.
I-2 Run log timestamps are recorded in local time rather than UTC.
I-3 A lifecycle rule deletes objects after 90 days; the audit period is twelve months and reports land three months later.
I-4 Object names still contain the pre-rebrand project code.
I-5 The digest register is a spreadsheet maintained by a contractor whose engagement ended in April.
I-6 Stored payloads carry no run id, so an artefact cannot be traced to the execution that produced it.
I-7 The storage console lists artefacts in a different order than the review checklist.
I-8 Bucket storage cost rose 12% after the estate grew.
1
2
3
4
5
6
7
8
9
10
11
12
Checks
The right findings are raised
Benign lines are left out
Severity matches the actual exposure
Ranked worst first
Next on your path · Data & Evidence
Control Health Metrics & Scorecards
Coverage, freshness, pass rate and exception aging, and the denominators that turn a reassuring dashboard into a lie.
