Chapter 8 — Digital forensics and malware analysis: failure modes | Technical 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 08 published. Map, example, EX029.

flowchart TD
  N0["Learning outcomes"]
  N1["8.1 Defensive failures"]
  N2["8.2 Response failure modes"]
  N3["8.3 Ranking"]
  N4["8.4 Mitigations"]
  N5["8.5 Learning from the pilot"]
  N6["8.6 Communication"]
  N7["8.7 Review"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX029"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["8.1 Defensive failures"]
  N2["8.2 Response failure modes"]
  N3["8.3 Ranking"]
  N4["8.4 Mitigations"]
  N5["8.5 Learning from the pilot"]
  N6["8.6 Communication"]
  N7["8.7 Review"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX029"]

[Learning outcomes]
    |
    v
[8.1 Defensive failures]
    |
    v
[8.2 Response failure modes]
    |
    v
[8.3 Ranking]
    |
    v
[8.4 Mitigations]
    |
    v
[8.5 Learning from the pilot]
    |
    v
[8.6 Communication]
    |
    v
[8.7 Review]
    |
    v
[Worked example] --> [Exercise EX029]

Learning outcomes

You will (1) analyse how the incident's defences failed; (2) analyse how the response could fail; (3) rank failure modes; (4) propose mitigations.

8.1 Defensive failures

Removable media allowed to run shortcuts and scripts; application control only piloted on Ward 2; the shared rota stick moved between home and work; no alert on script host launching from removable media.

Each failure links to evidence collected earlier: the shortcut and hidden script ran on Ward 4 and in pharmacy, the pilot blocked them only on Ward 2, and the stick's history included a home PC. No alert fired when wscript.exe started the hidden script from drive E: on either PC. Sana lists them without assigning blame to staff who used the stick.

8.2 Response failure modes

A well-meaning colleague could reimage the PC before collection; EDR containment could be lifted too early; evidence exports could be altered by editors; ward staff could keep using the stick.

These risks come from the response itself rather than from the attacker. Early reimaging would destroy memory and local logs, and lifting containment early would let the tool reach its server again. Editors re-saving exports would change hashes, and continued use of the stick would infect more PCs. The day-two reimage attempt shows the first risk was real, not hypothetical.

8.3 Ranking

Each failure mode gets severity, likelihood and detectability. Early reimaging scores high: severe, likely under pressure, and detected only afterwards.

Sana scores each mode from one to three on the three factors and multiplies them, so a high score means severe, likely and hard to detect. Early reimaging scored highest because the helpdesk wanted Ward 4 working and nothing would warn anyone until the evidence was gone. Continued stick use ranked lower once the stick was bagged as WB-USB-01. The ranking decides which mitigations are put in place first.

8.4 Mitigations

Reimage only with security sign-off (runbook gate); containment changes logged and approved; evidence folders read-only; stick quarantined and staff told to use the shared drive for rotas.

Each mitigation targets one failure mode and names an owner, such as security for the runbook gate and the network team for logging containment changes. The read-only evidence folder answers the editor problem that later appears as the usb_log.csv mismatch. Using the shared drive for rotas removes the stick's purpose altogether.

8.5 Learning from the pilot

Application control blocked the attack on Ward 2. Extending it is the strongest preventive mitigation.

The pilot gives the trust a tested rule rather than a theory, because the same shortcut that ran on two PCs was stopped on the third. Extending it still needs care, since a rule that blocks clinical software could harm patients. Ward managers agree each rollout, and the rule starts in audit mode where wards use unusual software. The test shortcut later run on a lab PC confirms the extended rule blocks the same chain.

8.6 Communication

Ward staff receive a short notice: do not use removable media for rotas; report pop-ups.

The notice is sent through ward managers rather than as a general IT email, because staff are more likely to read it from their own manager. It gives two instructions and one reason, and names the shared drive as the place for rotas. Sana keeps it short enough to pin beside a ward PC. The notice also asks staff to report any pop-up to the IT helpdesk immediately and not to close it first.

8.7 Review

The failure-mode table is reviewed after the incident closes.

The review checks whether each mitigation was carried out and whether any new failure mode appeared during the incident. The day-two reimage attempt is one example that was already on the list and was caught by the gate. Anything new, such as the editor re-save, is added with its score. The table is reviewed with Owen and the ward managers, who score clinical impact better than IT staff can. Scores are updated in place, with the old values kept in the table's history.

Human factors

Several failures trace to reasonable human choices under pressure: sharing rotas on a stick was quicker than the shared drive, and the technician wanted Ward 4 working. Sana's analysis avoids blame and asks what would make the safe choice the easy one — a rota page on the intranet, and a runbook gate that explains why it is holding a job rather than just refusing. Ward managers review the proposals before they go to the IT board.

Worked example

On day two, a helpdesk technician schedules WARD4-PC2 for reimaging to "get Ward 4 back". The runbook gate blocks the job pending Owen's sign-off; collection is confirmed complete at 14:00 and the reimage proceeds at 14:30.

Synthetic case. The events are invented.

Errors and limits

Failure-mode lists reflect what the team imagines; incidents reveal new ones.

Exercises

EX029 — Defensive failures. Name three defensive failures.
Show marking criteria
Rubric: 3 = media scripts allowed, app control pilot only, stick home/work, no alert; 2 = two; 1 = one; 0 = none.
EX030 — Top response risk. Why does early reimaging rank high?
Show marking criteria
Rubric: 3 = severe, likely under pressure, detected late; 2 = partial; 1 = rare; 0 = none.
EX031 — Gate in action. How did the runbook gate work on day two?
Show marking criteria
Rubric: 3 = blocked reimage pending sign-off; proceeded after collection; 2 = partial; 1 = vague; 0 = none.
EX032 — Strongest prevention. What is the strongest preventive mitigation, and why?
Show marking criteria
Rubric: 3 = extend app control; it blocked attack on Ward 2; 2 = partial; 1 = training; 0 = none.

Synthesis

Analyse both defensive and response failure modes; mitigations that worked in a pilot point the way.

Continue studying — chapter 08 of 18

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