Chapter 18 — Web3, blockchain and cryptoasset security: controls
Lesson map
Lesson 18 published. Map, example, EX052.
flowchart TD
N0["Learning outcomes"]
N1["18.1 Configuring preventive controls"]
N2["18.2 Verifying controls"]
N3["18.3 Control ownership"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX052"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["18.1 Configuring preventive controls"]
N2["18.2 Verifying controls"]
N3["18.3 Control ownership"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX052"]
[Learning outcomes]
|
v
[18.1 Configuring preventive controls]
|
v
[18.2 Verifying controls]
|
v
[18.3 Control ownership]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX052]
Learning outcomes
You will (1) configure preventive controls; (2) verify they work; (3) document control ownership.
18.1 Configuring preventive controls
Lucas helps configure preventive controls. On the ledger: the 2-of-3 multisig for grants, the monthly per-member cap, and a 48-hour timelock on administrator actions. On nodes: firewall allow-lists, restricted programming interfaces and dedicated service users. In the booking system: two-step approval of workshops and multi-factor login for staff. Each setting is recorded with its intended value. Preventive controls stop many problems before they start, and documenting intended values makes it possible to detect when a setting drifts away from what was agreed.
18.2 Verifying controls
A control is only as good as evidence that it works. Lucas tests each on the test ledger: a single signer cannot complete a grant; a grant above the cap is refused; an administrator action waits 48 hours; an outside address cannot connect to a node; a staff login without the second factor fails. He records each test with date and result. One test fails: the cap on the test ledger is set higher than intended. The developer corrects it, and Lucas retests successfully. Testing turns assumed protection into demonstrated protection.
18.3 Control ownership
Every control needs an owner who ensures it keeps working. Lucas lists owners: the manager owns the multisig signer list, the developer owns contract settings, Lucas owns node configurations and the coordinator owns workshop approvals. Owners review their controls quarterly and after changes. Without owners, controls decay quietly as people come and go. He adds the owner list to the handover file. The OWASP Smart Contract Top 10 highlights access control failures, many of which arise when nobody is clearly responsible for keeping role settings correct.
Worked example
Lucas tests five controls, finds the test-ledger cap set too high, has it corrected and retested, and assigns an owner to each control.
Synthetic case. The controls and tests are synthetic; the OWASP Smart Contract Top 10 is a real source.
Errors and limits
Controls without owners decay quietly as people come and go.
Exercises
- EX052 — Timelock length. How long is the administrator timelock? Rubric: 3 = 48 hours;; 2 = 48h;; 1 = 1 hour;; 0 = none.
- EX053 — Failed control test. Which control test failed? Rubric: 3 = the cap was set higher than intended;; 2 = cap;; 1 = multisig;; 0 = none.
- EX054 — Signer list owner. Who owns the multisig signer list? Rubric: 3 = the manager;; 2 = manager, hedged with another option;; 1 = Lucas;; 0 = none.
Synthesis
Configured, tested and owned controls provide lasting protection.
Continue studying — chapter 18 of 30
← Chapter 17 (draft) · Course chapter index · Chapter 19 (draft) →