LEARN. PRACTICE. GROW.Define what the evidence supports
The lab creates synthetic files inside its own temporary directory. Its purpose is to compare bytes, observed identity and transfer records without investigating a real system. Before acquisition, assign an evidence identifier and record the claimed source, authorized scope, method and responsible person. The exercise manifest contains the copy’s size and SHA-256. These fields support checking changes against a retained reference, but do not independently establish source authenticity or incident completeness. Two paths can contain identical bytes and produce the same digest. Operationally, the account of origin therefore needs additional evidence and a controlled process. Keep a separate working copy for analysis and make clear which object each result describes.
Recognize an inconsistent copy
In the controlled run, the source contains 4096 A bytes. After an unbuffered read obtains the first 1024, the script itself replaces the content with 4096 B bytes. The copy ends with 1024 A and 3072 B: size is preserved, but content differs from both initial and final versions. The expected result rejects the stable-acquisition claim and retains information about the attempt. In an initial buffered execution, the library read ahead and the mixture did not appear; that result was also recorded. The final reader uses buffering=0 to make the injection observable at the intended point. Neither case establishes behavior for every filesystem. Reading before and after detects the injected changes but does not create an atomic snapshot or exclude adversarial transient changes.
Distinguish paths, descriptors and write protection
Another run opens a file and then replaces its path with a different object. The open descriptor continues reading the old bytes, while a new lookup finds another identity. The lab compares identity and hashes to reject the stable-source conclusion for that path. It then applies mode 0400 to the copy and demonstrates that the owner can restore write permission and alter it. The protection reduces accidental changes under some conditions but is not immutable storage against that user. The script calls fsync before continuing and records success; it does not simulate power loss. In a technical report, distinguish each mechanism from the guarantee sought. A matching hash, restricted permission and completed call answer different questions.
Verify the chain and protect its reference
The model records transfer events linked through the previous digest. Editing an actor, removing a middle entry or changing the order breaks verification against the original final reference. Removing the last entry is also detected when that reference is retained. The exercise then lets the same user rewrite every record and replace the reference. The forged chain passes against the new reference, exposing an inadequate trust boundary. This is not a SHA-256 collision. The model simply recomputes data controlled by that user. An operational design must define who can write, who retains the reference, how events are authenticated and which retention requirements apply. The lab provides no trusted timestamps, independent witness or WORM storage.
Run and explain the laboratory results
Run the script with Python 3.13.1 or a compatible environment, save its JSON to your own location and inspect results before drawing conclusions. Both recorded runs contain 25 checks covering stable acquisition, changes during reading, path replacement, equal bytes, permissions, the record chain and cleanup. Predict which checks reject changed data and which expose insufficient protection. Confirm that the synthetic source remains intact in the stable test and the temporary directory is removed. Compare the script’s SHA-256 with the recorded value to connect evidence with the executed version. All data belongs to the exercise. Do not direct this script at production logs or present it as a forensic collection tool; its purpose is to explain bounded mechanisms through reproducible observations.
Report an incomplete result transparently
The final case imposes a twenty-minute evidence delivery deadline. The copy has the expected size, but initial-source, copy and final-source hashes differ. Preserve the results and classify the attempt as inconsistent. Assess a new authorized acquisition from a stabilized source or suitable mechanism, with specialist support where needed. Do not replace the reference hash with the copy’s hash to make comparison pass or conclude that the difference proves an attack. Report observation, limitation, analytical consequence and next step. Time pressure warrants escalation and a deadline decision without changing the facts. Summarize the lesson: byte-relative integrity, observed identity, provenance and authorization each need their own evidence; no single manifest field establishes all these properties.
python3 content/labs/securityx-operations-contracts/run.py --output /tmp/securityx-operations-evidence.json
# Inspect passed/failed, changedDuringAcquisition and pathReplacement.
# Synthetic ordinary files only; no production paths are accepted.
# Actual recorded runtime: Python 3.13.1. No forensic imaging or trusted custody service.A 4096-byte copy mixes two versions while preserving size. Three different hashes prevent declaring acquisition stable.
Common pitfalls
Treating a hash as provenance, mode 0400 as WORM, an editable chain as an independent witness or equal size as stable copying.
Related topics: Response and recovery · Telemetry and detection quality · Governance and risk
Connect every conclusion to the object and mechanism actually checked, preserving results that constrain interpretation.
Reference: Guide to Integrating Forensic Techniques into Incident Response · CAS-005 / SecurityX V5; objectives 3.0; launched 2024-12-17