Chapter 14 — Web3, blockchain and cryptoasset security: methods I

Chapter 14 — Web3, blockchain and cryptoasset security: methods I

Lesson map

Lesson 14 published. Map, example, EX040.

flowchart TD
  N0["Learning outcomes"]
  N1["14.1 Operational checklists"]
  N2["14.2 Standards as criteria"]
  N3["14.3 Recording findings"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX040"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["14.1 Operational checklists"]
  N2["14.2 Standards as criteria"]
  N3["14.3 Recording findings"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX040"]

[Learning outcomes]
    |
    v
[14.1 Operational checklists]
    |
    v
[14.2 Standards as criteria]
    |
    v
[14.3 Recording findings]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX040]

Learning outcomes

You will (1) use checklists to review ledger operations; (2) apply standards as criteria; (3) record findings consistently.

14.1 Operational checklists

Lucas builds a checklist for reviewing ledger operations. Questions include: are all nodes on the approved client version, is each node's programming interface restricted, are signer keys on hardware devices, are backups recent and tested, are privileged actions matched to approved changes, and are monitoring alerts reviewed. Each question needs evidence, not just a yes. He runs the checklist monthly. Checklists help technologists cover the same ground every time, reducing the chance that an important item is forgotten during a busy week at the makerspace.

14.2 Standards as criteria

For contract-related items Lucas refers to the EEA EthTrust Security Levels specification and the SWC registry, and for development practices to the ConsenSys best practices. He does not review contract code deeply himself, but he checks that the developer's documentation shows the contract was reviewed against these standards and that the compiler version is fixed. Using recognised standards makes findings credible and easy to discuss. He notes that EthTrust itself states that meeting its requirements does not guarantee the absence of weaknesses, and he says so in his reports.

14.3 Recording findings

Each finding gets an identifier, description, evidence, severity and recommended action. In his first monthly review Lucas records three findings: one node runs an older client version, monitoring alerts were not reviewed for a week during holidays, and a backup restore has not been tested for two months. All are rated low or medium. He agrees owners and dates with the manager. Consistent records let progress be tracked over months and make it easy to show the board how the makerspace's security has improved over time.

Worked example

Lucas's first monthly checklist review records an old client version, a week of unreviewed alerts and an untested backup, each with an owner and date.

Synthetic case. The checklist review is synthetic; EEA EthTrust, the SWC registry and ConsenSys best practices are real sources.

Errors and limits

Answering checklist questions without evidence turns review into guesswork.

Exercises

• EX040 — Checklist question. Name one checklist question. Rubric: 3 = are signer keys on hardware devices;; 2 = are backups tested;; 1 = is the office tidy;; 0 = none.
• EX041 — Standard caution. What caution does EthTrust state? Rubric: 3 = meeting requirements does not guarantee no weaknesses;; 2 = no guarantee;; 1 = full guarantee;; 0 = none.
• EX042 — Review finding. Name one finding from the first review. Rubric: 3 = an older client version on one node;; 2 = untested backup;; 1 = stolen key;; 0 = none.

Synthesis

Evidence-based checklists anchored in standards make reviews consistent and credible.

Continue studying — chapter 14 of 30

← Chapter 13 (draft) · Course chapter index · Chapter 15 (draft) →