Chapter 23 — Digital forensics and malware analysis: threat and failure analysis
Lesson map
Lesson 23 published. Map, example, EX067.
flowchart TD
N0["Learning outcomes"]
N1["23.1 Threat analysis"]
N2["23.2 Failure modes"]
N3["23.3 Ranking"]
N4["23.4 Mitigations"]
N5["23.5 Residual risk"]
N6["23.6 Malware in evidence"]
N7["23.7 Review cadence"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX067"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["23.1 Threat analysis"]
N2["23.2 Failure modes"]
N3["23.3 Ranking"]
N4["23.4 Mitigations"]
N5["23.5 Residual risk"]
N6["23.6 Malware in evidence"]
N7["23.7 Review cadence"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX067"]
[Learning outcomes]
|
v
[23.1 Threat analysis]
|
v
[23.2 Failure modes]
|
v
[23.3 Ranking]
|
v
[23.4 Mitigations]
|
v
[23.5 Residual risk]
|
v
[23.6 Malware in evidence]
|
v
[23.7 Review cadence]
|
v
[Worked example] --> [Exercise EX067]
Learning outcomes
You will (1) identify threats to an evidence system; (2) perform failure mode and effects analysis; (3) rank risks; (4) choose mitigations.
23.1 Threat analysis
Who might want to change evidence records? A party to a case, an insider covering a mistake, ransomware. What could they target? Custody logs, digests, images. Priya lists threats with the asset, actor and impact.
Impact depends on what the attacker gains. A party to a case altering one digest might cast doubt on an exhibit. An insider rewriting custody entries might hide a lost item. Ransomware encrypting the records could stop casework altogether. Each threat row also notes what would currently detect it, which is often nothing, and those rows become design priorities.
23.2 Failure modes
Not every risk is malicious. FMEA lists each component, how it could fail, the effect, and how the failure would be detected. Example: disk fills during imaging → truncated image → detected by size check and hash mismatch.
Another example: the server clock drifts after a firmware update. The effect is custody events with wrong times, detected by comparing the server against the reference time source in the daily check. A third: a label printer smudges a barcode, so a scan fails or reads the wrong item. The check digit detects that. Each row ends with whether detection is automatic or relies on someone noticing.
23.3 Ranking
Each failure gets severity, likelihood and detectability scores; their product ranks priorities. A failure that is severe and hard to detect ranks highest.
On a scale of one to five for each factor, silent corruption of an archived image might score severity 5, likelihood 2 and detectability 5 (hard to detect), giving 50. A smudged label scores lower because the check digit catches it. Priya uses the ranking to decide test effort, and she also notes that the scores are judgements, so two reviewers score independently and discuss differences.
23.4 Mitigations
Hash chain on the custody log (detects edits); write-once storage (prevents overwrite); disk-space check before imaging (prevents truncation); offline backups (restores after ransomware).
Each mitigation is traced back to the threats or failures it addresses and forward to a test. Write-once storage, for example, is tested by trying to overwrite a stored record with a privileged account and expecting refusal. Where a mitigation only detects rather than prevents, the response is written down too: who is alerted and what they do first.
23.5 Residual risk
Some risk remains: a corrupt insider with full access could fabricate an entire new history before anyone notices. Separation of duties and periodic external review reduce it.
Separation of duties means fabricating a history would require collusion, because corrections need a second approver. Periodic external review compares EvidenceDesk records with physical labels, storage logs and imaging station logs, which a single insider cannot all control. The residual risk is recorded with the lab manager's signature, which makes accepting it a deliberate decision rather than an oversight.
23.6 Malware in evidence
Evidence may contain malware. EvidenceDesk never opens evidence content; it only hashes bytes.
Hashing reads bytes as data and never runs them, so a malicious file on an image is harmless to the verifier. The risk comes from features that might parse content, such as previews or metadata extraction. Priya excludes those from EvidenceDesk by design. Any later proposal to add them would need its own threat analysis and would run in the isolated analysis zone. Files are opened as raw byte streams, with no file associations.
23.7 Review cadence
The analysis is revisited when components change or an incident occurs.
Triggers include a new storage platform, a change in who administers the server, a reported defect with integrity implications, or an incident at another lab using similar tools. Each review records the date, the participants, threats added or removed and changes to rankings. An unchanged analysis after a review is fine, as long as the review shows it was actually considered. Without a scheduled trigger, reviews tend to happen only after an incident, which is the worst time to discover that an assumption has gone stale.
Supply chain
EvidenceDesk depends on Python itself and the operating system. Priya records versions, obtains Python from the official source with its published checksums, and plans how a vulnerability in either would be assessed. Because the code uses only the standard library, there are no third-party packages whose compromise could alter records.
Worked example
Top-ranked failure: an examiner verifies the wrong copy because file names are similar. Severity high, detectability low. Mitigation: EvidenceDesk verifies by item ID and stored path, not by name typed by the user.
Synthetic case. The scores are invented.
Errors and limits
Scores are judgements; record who scored and why.
Exercises
- EX067 — Disk full. What is the effect and detection of a full disk during imaging? Rubric: 3 = truncated image; size check and hash mismatch; 2 = one; 1 = vague; 0 = none.
- EX068 — Ranking logic. Why does a severe, hard-to-detect failure rank highest? Rubric: 3 = high damage and likely unnoticed; 2 = partial; 1 = random; 0 = none.
- EX069 — Wrong copy. How does EvidenceDesk prevent verifying the wrong copy? Rubric: 3 = verifies by item ID and stored path; 2 = partial; 1 = training; 0 = none.
Synthesis
Threat analysis and FMEA together show where EvidenceDesk must detect, prevent or recover.
Continue studying — chapter 23 of 50
← Chapter 22 (draft) · Course chapter index · Chapter 24 (draft) →