Chapter 10 — Digital forensics and malware analysis: quality and troubleshooting | Professional Digital forensics and malware analysis

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Lesson map

Lesson 10 published. Map, example, EX046.

flowchart TD
  N0["Learning outcomes"]
  N1["10.1 Quality checks"]
  N2["10.2 Problem one: missing sign-ins"]
  N3["10.3 Problem two: duplicated rows"]
  N4["10.4 Problem three: time zone"]
  N5["10.5 Honesty about errors"]
  N6["10.6 Improving procedures"]
  N7["10.7 Peer review"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX046"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["10.1 Quality checks"]
  N2["10.2 Problem one: missing sign-ins"]
  N3["10.3 Problem two: duplicated rows"]
  N4["10.4 Problem three: time zone"]
  N5["10.5 Honesty about errors"]
  N6["10.6 Improving procedures"]
  N7["10.7 Peer review"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX046"]

[Learning outcomes]
    |
    v
[10.1 Quality checks]
    |
    v
[10.2 Problem one: missing sign-ins]
    |
    v
[10.3 Problem two: duplicated rows]
    |
    v
[10.4 Problem three: time zone]
    |
    v
[10.5 Honesty about errors]
    |
    v
[10.6 Improving procedures]
    |
    v
[10.7 Peer review]
    |
    v
[Worked example] --> [Exercise EX046]

Learning outcomes

You will (1) apply quality checks to forensic work; (2) troubleshoot export and analysis problems; (3) handle tool errors honestly; (4) improve procedures from problems found.

10.1 Quality checks

Before a report leaves the team: every finding cites a record; every evidence item has a hash and custody entry; times share one zone; a peer has reproduced key steps; the supervisor has signed. In Marlow's case each check had a real job: the hash check caught the edited message_trace.csv, the single-zone rule exposed the proxy export's local time, and peer reproduction confirmed the session link. The list is short enough to run on every report, and Lena ticks it in the ticket before asking Dev to sign.

10.2 Problem one: missing sign-ins

Lena's first sign-in export showed nothing before 2 March. Cause: the console's default range was 48 hours. She re-exported with an explicit range from 1 March and recorded the correction. A 48-hour export taken on 3 March left out 1 March, which was inside the approved scope. The first-seen check depends on that history, because a shorter baseline makes more addresses look new. The superseded export stays in the evidence share with its own hash, marked as superseded, so the correction can be traced by Dev or a later reviewer.

10.3 Problem two: duplicated rows

Merging two exports produced duplicate events. Each record has a unique event ID; de-duplicating by ID fixed counts. Lena notes that counts in the first draft were wrong and corrected. Duplicates arose because two exports covered overlapping periods, so some events appeared in both. Duplicated rows inflate counts such as the number of sign-ins or forwarded messages, which go straight into the report and the data protection briefing. Removing duplicates by eye risks deleting two real events with the same time, so the unique event ID is the only safe key.

10.4 Problem three: time zone

The proxy export used local time while others used UTC, putting the page visit an hour off. Converting fixed the order. The case notes record the conversion. An hour's shift matters when events are minutes apart: the 09:10 page visit landed after the 09:14 sign-in, which would make the sign-in appear to come before the password was captured. That ordering was impossible for the case, which is what made the error visible. The conversion is noted with the proxy's original zone, so a reviewer can redo it.

10.5 Honesty about errors

Each problem is written in the case log with cause and fix. Hiding an error, even a corrected one, would undermine trust if found later. In Marlow's log each problem has an entry: the 48-hour range, the duplicated rows and the proxy zone, together with the working-copy edit caught by the manifest. Dev sees them before the report, and the report's limits mention any correction that affected a figure. A reviewer who later finds a superseded export finds the explanation beside it.

10.6 Improving procedures

The runbook now says: set explicit date ranges; de-duplicate by event ID; convert all exports to UTC before merging. Each line maps to a problem from this case, so the runbook grows from evidence rather than guesswork. The explicit range answers the missing sign-ins, de-duplication by event ID answers the inflated counts, and conversion before merging answers the shifted page visit. A fourth change, keeping notes in a separate file from working copies, comes from the manifest mismatch. Dev approves the changes, and the next case will test whether they work.

10.7 Peer review

A peer checks a sample of findings against raw records each month. The peer picks findings at random from recent cases, opens the raw records behind them and checks that each one says what the finding claims. For the Marlow case a sample might include the 09:14 sign-in, the 09:20 rule creation and the count of eleven forwarded messages. Disagreements are recorded and discussed with the analyst, not settled quietly. Monthly sampling catches drifts in practice that a single case review would miss.

Reading error messages

When a console shows an error, Lena copies its exact text into the log rather than paraphrasing it. Exact wording lets the vendor or a colleague search for the cause and avoids a second failed attempt.

Worked example

Lena's log: "13:30 — sign-in export incomplete (default 48 h range). Re-exported 1–3 March; new hash recorded; old export retained and marked superseded. Runbook update requested."

Synthetic case. The problems are invented.

Errors and limits

Quality checks catch common errors, not every error; keep humility in conclusions.

Exercises

EX046 — Quality list. List four quality checks before release.
Show marking criteria
Rubric: 3 = findings cite records, hashes/custody, one time zone, peer reproduction, sign-off (four); 2 = three; 1 = one; 0 = none.
EX047 — Default range. What caused the missing sign-ins, and how was it fixed?
Show marking criteria
Rubric: 3 = 48-hour default; explicit re-export, new hash, old marked superseded; 2 = partial; 1 = wrong; 0 = none.
EX048 — Duplicates. How were duplicate rows removed?
Show marking criteria
Rubric: 3 = de-duplicate by unique event ID; correction noted; 2 = partial; 1 = deleted by eye; 0 = none.
EX049 — Zone error. What did the proxy time zone error do?
Show marking criteria
Rubric: 3 = put page visit an hour off; converted to UTC; 2 = partial; 1 = vague; 0 = none.
EX050 — Recording errors. Why record corrected errors in the case log?
Show marking criteria
Rubric: 3 = transparency; hidden errors damage trust if found; 2 = partial; 1 = no need; 0 = none.

Synthesis

Check quality systematically, fix problems openly and turn them into better procedures.

Continue studying — chapter 10 of 12

← Chapter 09 (draft) · Course chapter index · Chapter 11 (draft) →