Chapter 32 — Digital forensics and malware analysis: reliability
Lesson map
Lesson 32 published. Map, example, EX094.
flowchart TD
N0["Learning outcomes"]
N1["32.1 Reliability defined"]
N2["32.2 Single points of failure"]
N3["32.3 Backups"]
N4["32.4 Restore tests"]
N5["32.5 Long-term formats"]
N6["32.6 Media ageing"]
N7["32.7 Reliability metrics"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX094"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["32.1 Reliability defined"]
N2["32.2 Single points of failure"]
N3["32.3 Backups"]
N4["32.4 Restore tests"]
N5["32.5 Long-term formats"]
N6["32.6 Media ageing"]
N7["32.7 Reliability metrics"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX094"]
[Learning outcomes]
|
v
[32.1 Reliability defined]
|
v
[32.2 Single points of failure]
|
v
[32.3 Backups]
|
v
[32.4 Restore tests]
|
v
[32.5 Long-term formats]
|
v
[32.6 Media ageing]
|
v
[32.7 Reliability metrics]
|
v
[Worked example] --> [Exercise EX094]
Learning outcomes
You will (1) define reliability for EvidenceDesk; (2) identify single points of failure; (3) design backup and restore; (4) test recovery.
32.1 Reliability defined
Reliability is the probability a system performs its function over a period. For EvidenceDesk, the function is keeping complete, correct records available when needed — possibly years later for appeals.
The phrase 'over a period' matters here, because a custody log that works today but cannot be read during an appeal in 2034 has failed at the moment it was needed. Priya therefore writes down two horizons: daily availability while a case is open, and readable, checkable records for at least the lab's retention period after it closes. Each later design choice is judged against both horizons, not just the first.
32.2 Single points of failure
The server disk, the server itself and the one administrator who knows the setup. Mitigations: mirrored disks, a documented rebuild procedure, and a second trained administrator.
Hugo asks Priya to walk through each one by imagining it gone on a Monday morning. A dead disk is the easiest case, since the mirror carries on. A dead server means rebuilding from the written procedure, which is why that procedure is tested on spare hardware. The administrator is the hardest, because knowledge leaves with a person; the second administrator performs a full rebuild alone once a year to prove the documentation is enough.
32.3 Backups
Daily backups to write-once media, weekly copies stored offsite, all verified by hash. Backups include the custody chain anchors so restored data can be checked.
Write-once media stop a later attacker or a mistaken script from altering a backup after it is made. Hashing each backup set at creation and again after copying offsite shows that the copy matches the original. Including the anchors matters because a restored chain that only checks against itself proves little; checking it against values emailed and printed months earlier shows the restored history is the real one.
32.4 Restore tests
Quarterly, Priya's procedure restores the latest backup to a spare machine and verifies the chain against the anchors. A backup that has never been restored is an assumption, not a control.
The test records how long the restore took, which files failed to read, and whether the chain verified. In the first run, Priya finds that the records restore correctly but the anchor file, kept in a separate folder, was never in the backup set, so the restored chain had nothing external to be checked against. The gap is fixed, the backup list updated, and the next quarter's test confirms the change.
32.5 Long-term formats
Records in plain JSON and images in documented formats remain readable as software changes.
A proprietary database file may need a specific product version to open, and that version may not install on hardware available ten years from now. JSON lines can be read with any text editor, and the field meanings are written in a schema document stored alongside the data. For images, Priya keeps the raw format as the reference copy, since a raw image needs no special software at all to read its bytes.
32.6 Media ageing
Storage media degrade; periodic integrity checks and migration to new media keep evidence readable.
Hard disks fail mechanically, flash cells leak charge when left unpowered, and optical discs vary widely in lifespan by brand and storage conditions. Northfield's schedule rereads every archived image yearly and compares its hash with the stored value. Any mismatch or read error triggers a copy from the second set. Media are migrated to new hardware every five years, with hashes checked before and after each move.
32.7 Reliability metrics
Mean time between failures and mean time to restore are tracked; restore time must meet the lab's needs for urgent court requests.
Mean time between failures shows how often something breaks; mean time to restore shows how long the lab is without records when it does. The second matters more to Northfield, since a court can ask for a custody report at short notice. Priya sets a target of four working hours for restoring read access and compares each real or rehearsed incident against it, noting the cause whenever the target is missed.
Availability during outages
If the server fails during a court week, examiners need custody records quickly. Priya's procedure keeps a nightly signed export on an offline laptop in the safe, so records can be produced while the server is rebuilt. The export is checked against the anchors every month, and staff rehearse retrieving it twice a year so the procedure works under pressure.
Worked example
The first restore test fails: the backup omitted the anchor file stored in a separate folder. Priya adds it to the backup set, reruns the test, and documents both runs.
Synthetic case. The test is invented.
Errors and limits
Reliability figures from short trials are rough; collect operational data over years.
Exercises
- EX094 — SPOF list. Name three single points of failure and mitigations. Rubric: 3 = disk/server/admin with mirrors, rebuild doc, second admin; 2 = two; 1 = one; 0 = none.
- EX095 — Restore failure. Why did the first restore test fail? Rubric: 3 = anchor file omitted from backup; 2 = partial; 1 = media fault; 0 = none.
- EX096 — Untested backup. Why is an untested backup "an assumption"? Rubric: 3 = no evidence it restores correctly; 2 = partial; 1 = it is fine; 0 = none.
Synthesis
Reliable evidence systems remove single points of failure and prove recovery by restoring.
Continue studying — chapter 32 of 50
← Chapter 31 (draft) · Course chapter index · Chapter 33 (draft) →