Lesson 1 of 2 · 20 min read

Chain of Custody, Evidence Preservation, and Legal Admissibility

The gap between “technically correct” and “legally admissible” is where many IR cases fall apart. Technical evidence that cannot be authenticated in court is worthless for prosecution.

Evidence Documentation Framework

# Evidence Collection Log Template
# Complete this BEFORE touching any evidence

cat << 'EOF' > evidence_log_$(date +%Y%m%d_%H%M%S).txt
EVIDENCE COLLECTION LOG
=======================
Case Reference: [IR-YYYY-XXX]
Date/Time (UTC): $(date -u)
Collector Name: [Full Name]
Collector Role: [Title]
Witness Present: [Full Name, Title]
Location: [Physical address, room]

SCENE CONDITION:
[Describe exactly what was found, system state, any anomalies]

EVIDENCE ITEMS:
Item 1:
  Type: [Hard drive / USB / Laptop / Server]
  Make/Model/Serial: 
  Capacity:
  Current State: [Powered on/off, screen contents if on]
  Collection Method: [Live acquisition / Dead imaging]

COLLECTION METHOD:
  Tool Used: [FTK Imager / dd / KAPE / etc.]
  Tool Version:
  Verification Hash (MD5): 
  Verification Hash (SHA-256):
  Image File Path:
  Image File Size:

CHAIN OF CUSTODY:
  Time Out of Collector's Possession: [or N/A if maintained]
  
Collector Signature: _______________  Date: _________
Witness Signature: ________________  Date: _________
EOF

Hash Verification — Proof of Evidence Integrity

# Compute hash of physical drive BEFORE imaging (source hash)
# Using write-blocker or read-only mode

# Linux: compute SHA-256 of source device
sha256sum /dev/sdb | tee source_hash_$(date +%Y%m%d).txt

# Windows (FTK Imager): hash is computed and stored in the .txt case file automatically

# After imaging: verify the image matches the source
sha256sum evidence_$(date +%Y%m%d).dd
# This value MUST match the source hash — discrepancy = evidence is inadmissible

# For E01 images, verification is built in:
# FTK Imager → Verify Drive/Image → compares stored hash to current hash

# Log the verification:
echo "SOURCE HASH: $(cat source_hash_$(date +%Y%m%d).txt)" >> evidence_log.txt
echo "IMAGE HASH: $(sha256sum evidence_$(date +%Y%m%d).dd)" >> evidence_log.txt
echo "VERIFICATION: $([ source_hash == image_hash ] && echo MATCH || echo MISMATCH)" >> evidence_log.txt

# Make working copy (for analysis — never work on the master image)
cp evidence_$(date +%Y%m%d).dd working_copy_$(date +%Y%m%d).dd
# Verify working copy matches master before analysis
sha256sum working_copy_$(date +%Y%m%d).dd

Physical Evidence Handling

Evidence handling for physical media:

EVIDENCE SEAL LOG
Item: Hard Drive #1 [Serial: XXXX]
Bag #: EVB-20240901-001
Sealed by: [Name] at [Time]
Seal intact when received by: [Name] at [Time]
Seal broken for analysis by: [Name] at [Time], witnessed by: [Name]
Re-sealed with Bag #: EVB-20240901-002 at [Time]

When Law Enforcement is Involved

Engaging law enforcement changes evidence handling requirements:

LAW ENFORCEMENT ENGAGEMENT CHECKLIST

Before contacting LE:
☐ Obtain legal counsel approval for LE engagement
☐ Document the decision-making rationale (why LE is being engaged)
☐ Prepare evidence summary (not the raw evidence — the summary)
☐ Identify what the organization is willing/able to share vs. keep confidential

When LE arrives:
☐ Request all LE personnel sign a non-disclosure agreement (where legally permissible)
☐ Provide copies of evidence, NOT originals — LE gets a forensic copy
☐ Document what was provided to LE (date, time, person who received, copy hash)
☐ Obtain a receipt for any physical evidence LE takes

After LE engagement:
☐ LE may ask you to stop your own investigation — comply if instructed (evidence contamination concern)
☐ Document all communications with LE (dates, what was discussed, any instructions given)
☐ Understand: LE investigation timeline (months/years) differs from IR timeline (days/weeks) — coordinate with counsel on parallel workstreams