Chapter 8 — Web3, blockchain and cryptoasset security: supervised case analysis
Lesson map
Lesson 08 published. Map, example, EX036.
flowchart TD
N0["Learning outcomes"]
N1["8.1 The synthetic incident"]
N2["8.2 Facts and assumptions"]
N3["8.3 Lessons and actions"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX036"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["8.1 The synthetic incident"]
N2["8.2 Facts and assumptions"]
N3["8.3 Lessons and actions"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX036"]
[Learning outcomes]
|
v
[8.1 The synthetic incident]
|
v
[8.2 Facts and assumptions]
|
v
[8.3 Lessons and actions]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX036]
Learning outcomes
You will (1) analyse a synthetic incident under supervision; (2) separate facts from assumptions; (3) produce lessons and actions.
8.1 The synthetic incident
Ms Holm presents a synthetic case. A staff member at another fictional charity receives an urgent email appearing to come from their director, asking them to approve a treasury transfer to a new exchange address before the end of the day. The staff member prepares the proposal and a second signer approves it without checking the address against an allow-list. Funds are sent to an address the charity does not control. The case is presented at a high level, without technical detail, so participants focus on controls and decisions.
8.2 Facts and assumptions
Marcus separates facts from assumptions. Facts: the request came by email; the address was new; two signers approved; no allow-list existed; funds left the treasury. Assumptions to test: that the email truly came from the director; that signers had time to verify; that the exchange could help recover funds. He notes that many incident analyses go wrong by treating assumptions as facts. He also identifies what went right: the charity noticed within hours and reported promptly to the exchange and the authorities, as its plan required.
8.3 Lessons and actions
Marcus draws lessons: new destinations must be verified through an independent channel, such as a phone call to a known number; allow-lists prevent last-minute address changes; urgency in a request is a warning sign that should slow approval, not speed it; and second signers must verify independently rather than trust the first. He compares them with Bayview's workflow and finds that the allow-list and device checks already address most points. He adds a rule to confirm any new destination by phone. Ms Holm grades his analysis highly for clarity.
Worked example
Marcus separates five facts from three assumptions in the case and adds phone confirmation for any new destination to Bayview's workflow.
Synthetic case. The incident and both charities are synthetic.
Errors and limits
Treating assumptions as facts in incident analysis leads to wrong lessons.
Exercises
- EX036 — Request channel. How did the fraudulent request arrive? Rubric: 3 = an urgent email appearing to be from the director;; 2 = email;; 1 = phone;; 0 = none.
- EX037 — Missing control. Which control was missing in the case? Rubric: 3 = an allow-list of destinations;; 2 = allow-list;; 1 = multisig;; 0 = none.
- EX038 — Assumption to test. Name one assumption to test. Rubric: 3 = that the email came from the director;; 2 = signers had time;; 1 = funds left;; 0 = none.
- EX039 — Urgency lesson. How should urgency in a request be treated? Rubric: 3 = as a warning sign that slows approval;; 2 = warning sign;; 1 = speed up;; 0 = none.
- EX040 — Added rule. What rule does Marcus add at Bayview? Rubric: 3 = confirm any new destination by phone;; 2 = phone confirmation;; 1 = vague;; 0 = none.
Synthesis
Supervised case analysis turns others' incidents into concrete, proportionate actions.
Continue studying — chapter 08 of 12
← Chapter 07 (draft) · Course chapter index · Chapter 09 (draft) →