Chapter 23 — Web3, blockchain and cryptoasset security: threat and failure analysis
Lesson map
Lesson 23 published. Map, example, EX067.
flowchart TD
N0["Learning outcomes"]
N1["23.1 Systematic identification"]
N2["23.2 Ranking"]
N3["23.3 Mapping to controls"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX067"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["23.1 Systematic identification"]
N2["23.2 Ranking"]
N3["23.3 Mapping to controls"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX067"]
[Learning outcomes]
|
v
[23.1 Systematic identification]
|
v
[23.2 Ranking]
|
v
[23.3 Mapping to controls]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX067]
Learning outcomes
You will (1) identify threats and failures systematically; (2) rank them by impact and likelihood; (3) map them to controls.
23.1 Systematic identification
Jonas works through each component and interface, asking what could go wrong from malicious action, error or failure. He uses weakness classes from the SWC registry and the OWASP Smart Contract Top 10 as prompts for contract threats, and adds operational failures: lost administrator keys, validator outages, meter firmware faults and gateway bugs. Each item records the component, cause, effect on members and existing controls. A systematic method ensures familiar risks are not the only ones considered. He reviews the list with the developer.
23.2 Ranking
He ranks each threat and failure by impact on members and likelihood given current controls, using a simple three-level scale and a short justification. Highest-ranked items include a compromised gateway key minting excessive credits, a contract error allowing balances to go negative, and loss of two board keys preventing governance actions. Lower items include temporary loss of one validator. Ranking is judgement, so Jonas records reasons and asks a partner engineer to challenge the top ten. The challenge moves two items up a level.
23.3 Mapping to controls
Each high-ranked item maps to controls from the architecture: the gateway key is in a two-of-three multi-signature with the hourly cap and monitoring; negative balances are prevented by checks and tested as an invariant; board key loss is handled by five keyholders with a threshold of three and a documented key replacement procedure. Items without adequate controls become actions with owners. Mapping threats to controls shows whether the design addresses what matters, and exposes gaps for the next design iteration.
Worked example
Jonas lists 34 threats and failures, ranks three as highest, and maps each to controls, leaving two actions for the design studio.
Synthetic case. Threats, rankings and actions are synthetic; the SWC registry and OWASP Smart Contract Top 10 are real sources.
Errors and limits
Considering only well-publicised contract attacks misses operational failures like lost keys.
Exercises
- EX067 — Prompt sources. What prompts contract threats? Rubric: 3 = SWC registry and OWASP Smart Contract Top 10;; 2 = registries;; 1 = news;; 0 = none.
- EX068 — Top threat. Name a highest-ranked item. Rubric: 3 = compromised gateway key minting excess;; 2 = negative balances;; 1 = one validator down;; 0 = none.
- EX069 — Key-loss control. How is board key loss addressed? Rubric: 3 = five keyholders, threshold three, replacement procedure;; 2 = 3 of 5;; 1 = vague;; 0 = none.
Synthesis
Systematic, ranked and mapped threat analysis connects risks to concrete controls.
Continue studying — chapter 23 of 50
← Chapter 22 (draft) · Course chapter index · Chapter 24 (draft) →