Chapter 13 — Web3, blockchain and cryptoasset security: risk scenarios
Lesson map
Lesson 13 published. Map, example, EX037.
flowchart TD
N0["Learning outcomes"]
N1["13.1 Writing scenarios"]
N2["13.2 Likelihood and impact"]
N3["13.3 Choosing treatments"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX037"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["13.1 Writing scenarios"]
N2["13.2 Likelihood and impact"]
N3["13.3 Choosing treatments"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX037"]
[Learning outcomes]
|
v
[13.1 Writing scenarios]
|
v
[13.2 Likelihood and impact]
|
v
[13.3 Choosing treatments]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX037]
Learning outcomes
You will (1) write realistic risk scenarios; (2) estimate likelihood and impact; (3) choose treatments.
13.1 Writing scenarios
A risk scenario describes a plausible event, its cause and its consequences. Lucas writes five for the makerspace: a signer loses their hardware device; the issuing service grants a week's credits twice; a node's disk fills and it stops; a member's phone with their wallet is stolen; and the rack provider has a day-long outage. Each scenario is written in plain language without technical attack detail. Scenarios make risks concrete for staff and the board, who can then discuss them sensibly and agree on what matters most.
13.2 Likelihood and impact
For each scenario Lucas estimates likelihood and impact on simple scales agreed with the manager. A full disk is likely but low impact if monitored. A double grant is unlikely after the new checks but would be moderately harmful. A day-long provider outage is unlikely but would stop all bookings. He explains the reasoning for each estimate and notes that they are judgements, not measurements. Estimating together with staff improves the estimates and builds shared understanding of why some risks receive more attention and budget than others.
13.3 Choosing treatments
Treatments can reduce, transfer, avoid or accept a risk. Lucas proposes: for the lost device, a tested replacement procedure; for double grants, the checks already added; for full disks, alerts at 80 percent; for stolen phones, member guidance and a process to move credits to a new address after identity checks; for the provider outage, accepting the risk with a paper booking fallback. The manager approves the plan. Recording accepted risks is important, because acceptance is a deliberate decision with an owner, not an oversight that someone forgot to address.
Worked example
Lucas writes five scenarios, rates them with staff and chooses treatments including disk alerts at 80 percent and an accepted provider-outage risk with a paper fallback.
Synthetic case. The scenarios and treatments are synthetic.
Errors and limits
Leaving a risk untreated without recording acceptance turns a decision into an oversight.
Exercises
- EX037 — Scenario example. Name one of Lucas's scenarios. Rubric: 3 = a signer loses their hardware device;; 2 = node disk fills;; 1 = meteor strike;; 0 = none.
- EX038 — Disk treatment. How is the full-disk risk treated? Rubric: 3 = alerts at 80 percent;; 2 = alerts;; 1 = accept;; 0 = none.
- EX039 — Accepted risk. Which risk is accepted, with what fallback? Rubric: 3 = provider outage, with paper booking;; 2 = paper fallback;; 1 = double grants;; 0 = none.
Synthesis
Concrete scenarios, shared estimates and recorded treatments make risk management practical.
Continue studying — chapter 13 of 30
← Chapter 12 (draft) · Course chapter index · Chapter 14 (draft) →