Chapter 14 — Digital forensics and malware analysis: automation
Lesson map
Lesson 14 published. Map, example, EX053.
flowchart TD
N0["Learning outcomes"]
N1["14.1 What to automate"]
N2["14.2 Small scripts"]
N3["14.3 Review before use"]
N4["14.4 Read-only by design"]
N5["14.5 Scheduled checks"]
N6["14.6 Failure handling"]
N7["14.7 Records"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX053"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["14.1 What to automate"]
N2["14.2 Small scripts"]
N3["14.3 Review before use"]
N4["14.4 Read-only by design"]
N5["14.5 Scheduled checks"]
N6["14.6 Failure handling"]
N7["14.7 Records"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX053"]
[Learning outcomes]
|
v
[14.1 What to automate]
|
v
[14.2 Small scripts]
|
v
[14.3 Review before use]
|
v
[14.4 Read-only by design]
|
v
[14.5 Scheduled checks]
|
v
[14.6 Failure handling]
|
v
[14.7 Records]
|
v
[Worked example] --> [Exercise EX053]
Learning outcomes
You will (1) identify repeatable tasks worth automating; (2) write simple, reviewed scripts; (3) keep automation safe; (4) record automated outputs.
14.1 What to automate
Repeated, well-defined tasks: hashing and manifest checks, retention checks, USB serial searches, and timeline merges. Judgement steps, such as deciding containment, stay manual.
The tasks chosen are the ones Sana repeated during the case, such as hashing manifests and searching USB records for SN-7731. Containment and reimaging decisions stay manual because they weigh clinical impact and need a person who can be held accountable. Automating them would hide judgement inside code that ward managers cannot question. Automated checks report to people, who still decide what to do with each result.
14.2 Small scripts
The labs in this book are examples: short standard-library scripts that read exported records and print results. Short scripts are easy to review.
Each lab in this book is under twenty lines and reads exported records without touching any system. Short scripts can be reviewed in minutes by Owen, which is what makes review realistic for a small team. Longer tools are bought or adopted only after they have passed the hospital's validation. Each script's readme names its inputs and outputs, so a reviewer knows what it should touch.
14.3 Review before use
Every script is reviewed by a second person and tested on synthetic data with known answers before it touches case data. The script's version and hash are recorded with each use.
Testing on synthetic data with known answers shows the script does what it claims before it touches real evidence. The manifest verification script, for example, was tested with a deliberately changed file to confirm it reports MISMATCH. Recording the version and hash at each use ties every result to reviewed code.
14.4 Read-only by design
Case scripts open evidence read-only and write output to a separate folder. A script that could modify evidence is rejected at review.
Writing output to a separate folder means a mistake in a script can produce a wrong result but never a changed exhibit. Review checks file modes in the code, and any script that opens evidence for writing is sent back. The read-only evidence folder adds a second barrier if a script is wrong. Output folders are dated and named after the case reference.
14.5 Scheduled checks
After the incident, the retention check runs weekly and the USB serial search runs daily for SN-7731 and any serial newly linked to incidents. Alerts go to the security mailbox.
Running the search every day means a second copy of the rota stick, or SN-7731 itself reappearing on any PC, would be noticed within a day. The weekly retention check catches settings that drift after updates. Because the mailbox is shared, an alert is still seen when one member of the team is away.
14.6 Failure handling
Scripts report errors loudly. A silent failure — a script that prints nothing because a file was missing — could be mistaken for "nothing found". Scripts print a line count of input processed.
The daily serial search printing 'input: 0 records' is the case example: without the count, the output would have looked like a quiet day. Every script now prints how many lines it read and how many it could not parse. A run that reads nothing is treated as a failure to investigate.
14.7 Records
Automated outputs are saved with date, script version and input hash.
These three fields let anyone rerun a past check exactly and see whether a difference comes from the data or the script. Outputs are kept in a dated folder beside the ticket. Sana cites the output file in her notes rather than retyping its numbers. The input hash ties each output to the exact export it read, even if a later export of the same system differs. Owen samples one output each month to confirm the three fields are present.
Sharing scripts
Reviewed scripts live in a version-controlled folder with a short readme stating purpose, inputs, outputs and known limits. Colleagues use the shared copy, not private edits, so every case uses the same tested logic.
Worked example
Sana's daily serial search prints "input: 4,812 USB records; SN-7731: 0 new sightings". One morning it prints "input: 0 records" — the export job had failed. Because input counts are shown, the failure is caught and the export fixed the same day.
Synthetic case. The outputs are invented.
Errors and limits
Automation repeats mistakes faithfully; a wrong script gives wrong answers quickly.
Exercises
- EX053 — Choose tasks. Name two tasks to automate and one to keep manual. Rubric: 3 = e.g. hashing, retention check; containment decision manual; 2 = partial; 1 = all automated; 0 = none.
- EX054 — Review. What happens before a script is used on case data? Rubric: 3 = second-person review, synthetic test with known answers, version/hash recorded; 2 = partial; 1 = vague; 0 = none.
- EX055 — Silent failure. How did input counts help? Rubric: 3 = showed 0 records, exposing failed export; 2 = partial; 1 = vague; 0 = none.
- EX056 — Read-only. Why must case scripts be read-only? Rubric: 3 = never modify evidence; output separate; 2 = partial; 1 = speed; 0 = none.
Synthesis
Automate the repeatable, review and test scripts, keep them read-only and make failures visible.
Continue studying — chapter 14 of 18
← Chapter 13 (draft) · Course chapter index · Chapter 15 (draft) →