OpenCyber AcademyLesson map
Lesson 17 published. Map, example, EX049.
flowchart TD
N0["Learning outcomes"]
N1["17.1 Needs"]
N2["17.2 Selection criteria"]
N3["17.3 Validation"]
N4["17.4 The kit"]
N5["17.5 Updates"]
N6["17.6 Case documentation"]
N7["17.7 Scripts"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX049"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["17.1 Needs"]
N2["17.2 Selection criteria"]
N3["17.3 Validation"]
N4["17.4 The kit"]
N5["17.5 Updates"]
N6["17.6 Case documentation"]
N7["17.7 Scripts"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX049"]
[Learning outcomes]
|
v
[17.1 Needs]
|
v
[17.2 Selection criteria]
|
v
[17.3 Validation]
|
v
[17.4 The kit]
|
v
[17.5 Updates]
|
v
[17.6 Case documentation]
|
v
[17.7 Scripts]
|
v
[Worked example] --> [Exercise EX049]
Learning outcomes
You will (1) select forensic tools for a small organisation; (2) validate tools before use; (3) maintain a tool kit; (4) document tool use in cases.
17.1 Needs
Alder Falls needs memory capture, triage collection, disk imaging, log parsing and timeline building, plus a safe way to hand files to analysts.
Each need maps to a question from the CLERK-03 case: memory capture answered whether a remote tool was running on PLAN-07; triage collection gathered logs and registry data quickly; imaging preserves a full copy if needed later; log parsing and timelines joined the hosts; safe handover moved helper.exe and svc.exe to the analyst. A tool that serves none of these needs does not belong in the kit.
17.2 Selection criteria
Validated or testable; documented; supported; suitable licence; runs offline; produces verifiable output (hashes, logs).
Running offline matters because a tool that contacts the internet during collection changes the suspect machine's network records and may alert an intruder. Verifiable output means the tool writes hashes and logs of what it did, so Renata can show later exactly how each item was produced. Jonah scores candidate tools against these criteria in a short table kept with the kit records. A cheaper tool that fails a criterion is rejected.
17.3 Validation
Before use, each tool is tested on synthetic data with known contents. NIST CFTT publishes test reports for some imaging and write-blocking tools; for others, the city runs its own small tests and records results.
The city's own tests are simple but recorded: a synthetic machine with known files and known logons, the tool run against it, and a check that every expected item appears with the right hash. The test result, date and tool version go in the kit log. When the triage collector changed its folder layout, this testing caught the problem before a real case.
17.4 The kit
A labelled, write-protected USB drive with collection tools, a checksum list of the tools themselves, and a printed procedure. A second drive is kept offsite.
The printed procedure matters when stress is high and screens are unfamiliar. It lists the steps in order, the commands to type, and where to write times and hashes. The checksum list lets Jonah confirm before each use that the tools on the drive are the validated versions and have not been altered since the last test.
17.5 Updates
Tool updates are tested before replacing the kit version; old versions are archived so past cases can be reproduced.
Archiving old versions means a result produced last year can be reproduced with the exact tool that produced it, which matters if a case is reopened or challenged. Jonah keeps each version with its test record and the date it entered or left the kit. Updating in the middle of a case is avoided unless a fault forces it, and then both versions are recorded.
17.6 Case documentation
Every case records tool names, versions and the hash of the kit drive's tool list.
For the CLERK-03 case, the notes list the memory capture tool and version, the triage collector and version, Jonah's manifest script version and the hash of the kit's tool list on the day of collection. A reviewer can then check that each tool was the validated one. Without these details, a question about a tool's behaviour cannot be answered for this specific case. The same notes list any tool that failed.
17.7 Scripts
In-house scripts (manifest builder, log parser) are versioned and tested like any other tool.
The manifest builder and the log parser are as important to the case as any commercial tool: a bug in either could hide data, as the parser bug with millisecond timestamps later showed. Each script has tests, a version number and a commit history, and the version used is recorded in every case where it runs. Scripts written during a case are reviewed by Renata before their output is used, and are added to the kit only after passing the same tests as the rest.
Training on the kit
Every IT staff member who might respond practises with the kit twice a year on a synthetic machine: collect memory, run triage, build the manifest, hand over. Jonah times each step and notes where the printed procedure confused people, then revises the wording. Practice turns a rarely used kit into something staff can use calmly under pressure, and it shows which steps need better labels or clearer screenshots.
Worked example
A new version of the triage collector changes its output folder layout. Jonah's manifest script misses one folder. Testing on synthetic data before deployment reveals the miss; he updates the script and records both versions in the kit log.
Synthetic case. The update is invented.
Errors and limits
Validation on synthetic data covers tested cases; unusual systems may behave differently.
Exercises
- EX049 — Criteria. List four tool selection criteria.
Show marking criteria
Rubric: 3 = validated, documented, supported, licence, offline, verifiable output (any four); 2 = three; 1 = one; 0 = none. - EX050 — Kit integrity. How is the kit drive's integrity protected?
Show marking criteria
Rubric: 3 = write-protected; checksum list of tools; offsite copy; 2 = two; 1 = one; 0 = none. - EX051 — Layout change. What did testing catch with the new collector version?
Show marking criteria
Rubric: 3 = manifest script missed new folder; fixed before use; 2 = partial; 1 = vague; 0 = none.
Synthesis
A validated, versioned, documented kit makes collection repeatable and defensible.
Continue studying — chapter 17 of 30
← Chapter 16 (draft) · Course chapter index · Chapter 18 (draft) →