Chapter 24 — Web3, blockchain and cryptoasset security: controls
Lesson map
Lesson 24 published. Map, example, EX070.
flowchart TD
N0["Learning outcomes"]
N1["24.1 Selecting controls"]
N2["24.2 Balancing usability"]
N3["24.3 Verifying controls work"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX070"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["24.1 Selecting controls"]
N2["24.2 Balancing usability"]
N3["24.3 Verifying controls work"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX070"]
[Learning outcomes]
|
v
[24.1 Selecting controls]
|
v
[24.2 Balancing usability]
|
v
[24.3 Verifying controls work]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX070]
Learning outcomes
You will (1) select controls for keys, contracts and operations; (2) balance security with usability; (3) verify controls work.
24.1 Selecting controls
Sofia selects controls for each risk area. For keys: hardware devices, a 2-of-3 multisig, and documented recovery. For contracts: role restrictions, the weekly cap, a pause function, a timelock on administration and events for every change. For operations: daily reconciliation, monitoring of privileged actions and a tested incident procedure. She links each control to a risk from her earlier asset list, so every control has a reason and no important risk is left uncovered. The board can see why each control exists and what would be lost if it were removed to save effort.
24.2 Balancing usability
Controls that are too hard to use are bypassed. Sofia notices that requiring two keyholders for every small mint batch causes delays, because keyholders are volunteers with jobs. She proposes one weekly batch at a fixed time, so keyholders can plan, instead of nightly batches. Members' wallets stay simple; the cooperative's custodial option remains for those who prefer it. She explains that good security fits the way people actually work. The ConsenSys best practices note that complexity increases the chance of errors, and that applies to procedures just as much as to code.
24.3 Verifying controls work
A control that has never been tested may not work. Sofia schedules tests: a keyholder signs a test transaction on the test ledger each month to confirm devices work; the pause function is exercised on the test network each quarter; reconciliation is run against a deliberately altered synthetic dataset to confirm it detects the change. Each test result is recorded. She finds that one keyholder's device firmware needs an update before it will sign, which would have caused a delay in a real emergency. Testing controls turns assumptions into evidence and reveals problems while there is still time.
Worked example
Sofia moves to one weekly mint batch for usability and finds through monthly testing that one keyholder device needs a firmware update.
Synthetic case. The controls and tests are synthetic; ConsenSys best practices is a real source.
Errors and limits
Assuming an untested control works can fail exactly when it is first needed.
Exercises
- EX070 — Key controls. Name one key control. Rubric: 3 = hardware devices;; 2 = 2-of-3 multisig;; 1 = shared password;; 0 = none.
- EX071 — Batch change. Why move to a weekly batch? Rubric: 3 = volunteer keyholders can plan, avoiding delays;; 2 = usability;; 1 = cheaper gas;; 0 = none.
- EX072 — Test discovery. What did monthly signing tests reveal? Rubric: 3 = a keyholder device needed a firmware update;; 2 = firmware;; 1 = vague;; 0 = none.
Synthesis
Risk-linked, usable and regularly tested controls provide real protection.
Continue studying — chapter 24 of 40
← Chapter 23 (draft) · Course chapter index · Chapter 25 (draft) →