Chapter 10 — Web3, blockchain and cryptoasset security: control configuration
Lesson map
Lesson 10 published. Map, example, EX037.
flowchart TD
N0["Learning outcomes"]
N1["10.1 Configuring node controls"]
N2["10.2 Service and ledger controls"]
N3["10.3 Checking against the record"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX037"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["10.1 Configuring node controls"]
N2["10.2 Service and ledger controls"]
N3["10.3 Checking against the record"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX037"]
[Learning outcomes]
|
v
[10.1 Configuring node controls]
|
v
[10.2 Service and ledger controls]
|
v
[10.3 Checking against the record]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX037]
Learning outcomes
You will (1) configure controls on nodes and services; (2) document intended settings; (3) check settings against the record.
10.1 Configuring node controls
Aiko helps configure node controls: peer allow-lists limited to the three nodes, programming interfaces limited to the deposit service, node software running as dedicated users, time synchronisation enabled and log retention set to ninety days. Each setting has an intended value agreed with Mr Kowal. She applies changes through the library's change process, one node at a time, confirming the ledger keeps running after each. Configuring controls carefully and in order prevents the common mistake of locking out a needed service or taking two nodes offline at once.
10.2 Service and ledger controls
For the deposit service Aiko confirms it holds only the credentials it needs, cannot issue tokens and can request releases only for loans marked returned. On the ledger, the developer confirms the 2-of-3 staff multisig for issuing, the 48-hour administrator timelock and two-person pause. Aiko records each setting with its location and owner. The ConsenSys best practices encourage simple, well-documented controls. She notes that a control documented clearly is easier to check and harder to change by accident during later maintenance.
10.3 Checking against the record
Aiko writes a read-only script that reads node configuration files and compares each setting with the intended value. The first run finds node one keeping logs for thirty days instead of ninety, a leftover from initial setup. It is corrected through a change ticket and the script rerun shows no differences. She schedules the check weekly and after every maintenance. Comparing actual settings with a record is the simplest way to catch drift, which otherwise goes unnoticed until it causes a problem during an incident or audit.
Worked example
Aiko applies node controls one node at a time and her comparison script finds node one keeping logs for thirty days instead of ninety.
Synthetic case. The controls and findings are synthetic; ConsenSys best practices is a real source.
Errors and limits
Changing controls on several nodes at once risks taking the ledger offline.
Exercises
- EX037 — Interface restriction. Who may reach node programming interfaces? Rubric: 3 = only the deposit service;; 2 = deposit service;; 1 = everyone;; 0 = none.
- EX038 — Service limit. What can the deposit service not do? Rubric: 3 = issue tokens;; 2 = cannot issue;; 1 = read data;; 0 = none.
- EX039 — Drift found. What did the first comparison find? Rubric: 3 = node one logs kept for thirty days instead of ninety;; 2 = log retention;; 1 = vague;; 0 = none.
- EX040 — Check schedule. When does the comparison run? Rubric: 3 = weekly and after every maintenance;; 2 = weekly;; 1 = never;; 0 = none.
Synthesis
Carefully configured, documented and regularly compared controls stay effective.
Continue studying — chapter 10 of 18
← Chapter 09 (draft) · Course chapter index · Chapter 11 (draft) →