Before
- Copy useful-looking files
- Normalize the original log
- Treat matching hashes as proof of trust
Module 3 of 17
Evidence Acquisition, Provenance, and Chain of Custody
Preserve trustworthy evidence and document every transformation before drawing a conclusion.
Start here
Learning objectives
- Prioritize evidence sources according to volatility, incident needs, authority, and collection risk.
- Create a provenance record with identifiers, timestamps, hashes, source, collector, and transformations.
- Distinguish evidence integrity from evidence meaning and explain the limits of a checksum.
- Build an investigation timeline that preserves source time zones, clock uncertainty, and conflicting observations.
After
- Collect for an authorised decision
- Preserve originals and trace derivatives
- Separate byte identity from authenticity and meaning
Ask What Decision the Evidence Must Support
Collection is not a contest to gather everything. Start with the incident decision: Do we need to contain a host, determine affected identities, validate a release, restore a service, or preserve material for a formal investigation? The decision defines which evidence is relevant and how quickly it is needed.
Collect only within authority. Coordinate with incident response, legal, privacy, and system owners when the evidence could include personal information, customer data, employee activity, credentials, or regulated records. A technically complete collection can still be operationally harmful if it expands access unnecessarily.
Prioritize Volatile and Authoritative Sources
Some evidence changes quickly: running processes, active connections, memory-resident data, temporary files, and short-retention logs. Other evidence persists longer: signed release manifests, version-control history, package lockfiles, immutable audit logs, disk images, and backups. Prioritize volatile evidence only when collecting it is authorised, necessary, and unlikely to cause greater harm.
Authority matters as much as volatility. A screenshot may be useful for orientation but weaker than an exported event with a stable identifier and source metadata. A local timestamp may disagree with a central log because clocks drift. Keep both observations; do not silently replace the inconvenient one.
| Source | Useful for | Important limitation |
|---|---|---|
| Process and service events | Execution sequence and parent-child relationships | Coverage depends on sensor policy and retention |
| Package lockfile and provenance | Expected dependency identity and build inputs | Does not prove the deployed bytes match without verification |
| Central identity audit | Account use and control-plane changes | Time and field semantics vary by provider |
| File metadata and hash | Identity comparison and triage | Metadata may change; a hash says nothing about intent |
Record Provenance and Chain of Custody
Provenance answers where an item came from and how it was produced. Chain of custody records who handled it, when, why, where it was stored, and which authorised transformation occurred. Both are needed for reproducibility. The course manifest records a stable artifact ID, descriptive name, source, acquisition time, collector, original hash, size, storage location, handling events, derivative IDs, and notes.
Work on a verified copy and preserve the supplied original read-only. A decompressed log, normalized timestamp file, parsed table, or screenshot is a derivative. Give it a new identifier and record the tool, version, configuration, input ID, output hash, and time. Never overwrite the source to make it easier to read.
A cryptographic hash helps detect whether the bytes changed. It does not establish that the bytes are safe, truthful, complete, or collected lawfully. Signatures and provenance claims also need trust-policy validation: which identity signed, whether the certificate or key was valid under policy, and whether the subject describes the artifact being reviewed.
Build a Timeline With Uncertainty
Normalize times for comparison but preserve the original value, time zone, precision, and source. Record known clock offset rather than silently correcting it. If one source reports seconds and another reports milliseconds, do not invent precision. Events with the same displayed time may still have an unknown order.
A useful timeline row contains event ID, normalized time, original time, source, asset, identity, action, object, evidence reference, confidence, and analyst note. Separate the event from the interpretation. “Process A created file B” can be an event; “this established persistence” is an interpretation that needs additional evidence and is outside the safe behavior implemented by course fixtures.
Make Collection Reproducible
Another authorised engineer should be able to reproduce the transformation and arrive at the same output hash or explain why the source is inherently variable. Pin tool versions, keep commands or UI steps, record filters, and retain schemas. Validate a sample manually so automation does not turn a parsing mistake into a confident timeline.
In production, route investigation data into access-controlled case storage with retention, audit, and deletion policies. Do not paste real artifacts, secrets, or customer data into course notes, public repositories, tickets with broad access, or external AI services.
Suggested Study Plan (6 hours)
The published duration includes active practice, not video playback alone. Complete each block with the course-owned evidence and retain the stated deliverable so another reviewer can reproduce your reasoning.
| Study block | Time | Required evidence |
|---|---|---|
| Guided lesson and primary-source review | 1h 12m | Annotated notes that separate observations, hypotheses, limits, and version-sensitive facts. |
| Worked evidence walkthroughs | 1 hour | Reproduce the lesson's tables or decision flow and challenge at least two assumptions. |
| Independent practice rounds | 1 hour | Apply the method to two alternate records in the sanitized evidence pack and compare the conclusions. |
| Required lab | 2 hours | A verified evidence manifest, custody log, derivative record, and source-linked timeline with explicit clock uncertainty and no modified originals. |
| Knowledge check and review | 48 minutes | Answer the evidence check, review the rubric, and record one production follow-up. |
Evidence Check
Question: Two copies of an evidence file have the same SHA-256 hash. What can the investigator conclude?
Reveal the defensive reasoning
The copies contain the same bytes with overwhelming practical confidence under the chosen hash. The hash alone does not prove the bytes are safe, complete, authentic, lawfully collected, or correctly interpreted. Those conclusions require provenance, authority, source context, and validation.
Primary References
Use these primary sources for the current standard or tool behavior. The course records framework versions so mappings can be reviewed when upstream guidance changes.
Real world
Where this shows up
- Comparing a deployed package with a signed build manifest.
- Reconstructing an endpoint incident from central and local logs with different clocks.
- Handing evidence between development, security operations, and an external responder.
Production notes
Keep these close
- Use access-controlled case storage with audit trails, retention rules, and approved encryption.
- Keep original evidence immutable and generate derivatives through versioned, reviewable transformations.
- Record collection gaps caused by retention, sensor policy, outage, or unavailable authority.
- Minimize personal and confidential data in collections and reports.
Common mistakes
What usually breaks
- Editing the original log while normalizing timestamps or columns.
- Assuming matching hashes establish trust or safety.
- Discarding an event because its clock conflicts with the preferred timeline.
- Collecting broad data without a decision, authority, or retention plan.
Security risks
Threats to watch
- Overcollection can expose credentials, personal data, and confidential business information.
- Untracked transformations can make conclusions irreproducible.
- Clock errors can reverse an apparent sequence and misdirect containment.
- Weak case-storage permissions can turn an investigation into a second data exposure.
Tradeoffs
Design choices you should be able to defend
Broad collection
Pros
- May preserve context before short-retention data disappears
- Supports later hypotheses
Cons
- Higher privacy and storage risk
- Longer processing time
- More unrelated data to protect
Decision-focused collection
Pros
- Lower data exposure
- Faster analysis
- Clearer relationship to containment or recovery
Cons
- Requires a well-formed question
- May need an authorised second collection if the hypothesis changes
Think like an engineer
Questions to answer before shipping
- Which decision will change because this source is collected?
- What property does the hash prove, and which properties remain unproven?
- Can another authorised analyst reproduce every derivative from the record?
- What is the smallest collection that answers the question without unnecessary data exposure?
Key terms
Vocabulary used in this module
Provenance
The documented origin and production history of an artifact or dataset.
Chain of custody
The record of possession, handling, storage, and authorised transformation of evidence.
Derivative
A new item created from evidence by parsing, normalizing, filtering, extracting, or another documented transformation.
Volatility
How quickly a source can change or disappear.
Clock offset
The measured or estimated difference between a source clock and a reference clock.
Exercises
Practice inside the lesson
Build a Defensible Evidence Manifest and Timeline
Verify inert course fixtures, document their provenance, create a derivative, and produce a timeline that exposes uncertainty.
- Read the supplied case authorization and identify the decision the evidence must support.
- Verify the SHA-256 values of the instructor-authored text, JSON, and metadata fixtures against the signed course manifest.
- Create a chain-of-custody record for each supplied item without changing the original fixtures.
- Normalize a copy of the synthetic event timestamps while preserving original values, source time zones, precision, and known clock offsets.
- Hash the normalized derivative and record its input IDs, transformation method, tool version, output ID, and output hash.
- Build a timeline that separates observed events, analyst inferences, conflicts, and unanswered questions.
Expected evidence
A verified evidence manifest, custody log, derivative record, and source-linked timeline with explicit clock uncertainty and no modified originals.
Assessment criteria
- Every item has a stable ID, source, collector, acquisition time, size, and verified hash.
- The derivative is traceable to its inputs, transformation, tool version, and new hash.
- Original timestamps and precision are preserved alongside normalized values.
- Timeline facts, inferences, conflicts, and unknowns are visibly separated.
Course-owned resources
Teardown
- Delete temporary working copies.
- Retain only the written defensive analysis.
Recap
Key takeaways
- Collect evidence to support an authorised decision, not simply because it is available.
- Preserve originals and treat every transformation as a new, traceable derivative.
- A checksum verifies byte identity, not safety, authenticity, or meaning.
- Timelines must preserve original time, precision, source, and uncertainty.
- Reproducible analysis records tool versions, inputs, configuration, and outputs.
Related resources