Chapter 22 — Digital forensics and malware analysis: automation
Lesson map
Lesson 22 published. Map, example, EX064.
flowchart TD
N0["Learning outcomes"]
N1["22.1 What to automate"]
N2["22.2 What not to automate"]
N3["22.3 Idempotency"]
N4["22.4 Logging"]
N5["22.5 Safe testing"]
N6["22.6 Scheduled integrity checks"]
N7["22.7 Failure handling"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX064"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["22.1 What to automate"]
N2["22.2 What not to automate"]
N3["22.3 Idempotency"]
N4["22.4 Logging"]
N5["22.5 Safe testing"]
N6["22.6 Scheduled integrity checks"]
N7["22.7 Failure handling"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX064"]
[Learning outcomes]
|
v
[22.1 What to automate]
|
v
[22.2 What not to automate]
|
v
[22.3 Idempotency]
|
v
[22.4 Logging]
|
v
[22.5 Safe testing]
|
v
[22.6 Scheduled integrity checks]
|
v
[22.7 Failure handling]
|
v
[Worked example] --> [Exercise EX064]
Learning outcomes
You will (1) automate repetitive collection and verification steps; (2) make automation idempotent and logged; (3) keep humans in decision points; (4) test automation safely.
22.1 What to automate
Hashing and manifest creation, log export from known sources, timeline merging, and daily integrity checks of the evidence store. These are repetitive and error-prone by hand.
These tasks share three features: they follow fixed rules, they are done often, and a human doing them by hand makes small errors that are hard to spot. In the CLERK-03 case, hashing 47 files and checking each value by eye would have taken time and invited a transcription mistake. A script does the same job identically each time, and its log shows exactly what it did and when.
22.2 What not to automate
Decisions to isolate, collect from personal devices, or rebuild systems stay with people, because they need judgement and authority.
Isolating a server may stop a city service; collecting from a personal phone raises legal and privacy questions; rebuilding a machine destroys evidence. Each needs someone with authority to weigh the situation and accept responsibility. Automation can prepare these decisions, for example by gathering the facts Renata needs, but the final step is taken by a named person whose choice is recorded with a reason.
22.3 Idempotency
Running an automation twice on the same input should give the same output and not duplicate or alter evidence. Jonah's manifest script produces identical manifest hashes on repeated runs.
Idempotency protects evidence from a common accident: a job that runs twice because of a retry or a scheduling mistake. If the manifest script appended duplicate entries or rewrote files on the second run, the record would change without anything real having changed. Jonah's test runs each script twice on the same synthetic folder and compares the two manifest hashes; any difference fails the test.
22.4 Logging
Every automated run logs start, inputs, outputs with hashes, errors and version.
The log of each run is itself a record for the case. If the nightly integrity job reports a mismatch, the log shows which file, which expected and actual hashes, and which version of the job produced the result. Logs are written to the central collector so a failure on the machine running the job does not also destroy the record of what it did. Run logs are kept for as long as the evidence they describe.
22.5 Safe testing
Automations are tested on synthetic data in a test environment before touching the evidence store.
The test environment mirrors the evidence store's folder layout with synthetic files whose hashes are known. Jonah also tests failure cases: a missing file, a changed file, a file being written during the check. Only when the automation handles each one correctly, by reporting rather than altering anything, is it pointed at the real store. Results of each test run are kept with the script version that passed, so the decision to go live can be traced later.
22.6 Scheduled integrity checks
A nightly job rehashes stored evidence and compares with manifests; mismatches alert Renata.
A nightly check catches changes close to when they happen, which makes the cause easier to find. The mismatch found after a spreadsheet program re-saved a log export is an example: because it was caught the next morning, the colleague remembered the action and the original could be restored from the write-once backup. Weekly checks would have left a longer gap. Each alert is closed only with a recorded cause and the action taken.
22.7 Failure handling
If a step fails, the automation stops and reports, rather than continuing with partial data.
Continuing after a failure could produce a manifest that looks complete but lacks files, or an integrity report that silently skips part of the store. Stopping and reporting makes the failure visible at once. Jonah's scripts exit with a clear message naming the step that failed and leave partial outputs marked as incomplete, so nobody mistakes them for finished work. A rerun starts from the beginning, never from the middle of a failed run.
Scheduling and dependencies
The nightly integrity job runs after backups complete, so it checks the stored copy rather than a file being written. Jonah adds a dependency so the job waits for the backup's success signal and alerts if the backup failed. Running checks against half-written files had produced false mismatches in testing, which wasted an hour of investigation before the cause was found and documented.
Worked example
The nightly check reports a mismatch for one log export. Investigation shows the file was moved and re-saved by a colleague's spreadsheet program, which changed line endings. The original is restored from the write-once backup; the evidence folder is made read-only for all staff except the evidence custodian.
Synthetic case. The mismatch is invented.
Errors and limits
Automation repeats mistakes as efficiently as correct steps; review its logic and outputs regularly.
Exercises
- EX064 — Automate or not. Give one task to automate and one to leave to people. Rubric: 3 = e.g. manifests vs rebuild decisions, with reason; 2 = examples only; 1 = reversed; 0 = none.
- EX065 — Idempotent. What does idempotent mean for Jonah's script? Rubric: 3 = same manifest hash on repeat runs; no duplicates or changes; 2 = partial; 1 = fast; 0 = none.
- EX066 — Nightly mismatch. What caused the mismatch, and what changed? Rubric: 3 = spreadsheet re-save changed line endings; restore, read-only folder; 2 = partial; 1 = vague; 0 = none.
Synthesis
Automate repetitive integrity work idempotently and with logs; keep judgement calls with people.
Continue studying — chapter 22 of 30
← Chapter 21 (draft) · Course chapter index · Chapter 23 (draft) →