Chapter 18 — Security architecture

Chapter 18 — Security architecture

Lesson map

Lesson 18 published. Map, example, EX052.

flowchart TD
  N0["Learning outcomes"]
  N1["18.1 Trust boundaries"]
  N2["18.2 Defence in depth"]
  N3["18.3 Architecture document"]
  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 Trust boundaries"]
  N2["18.2 Defence in depth"]
  N3["18.3 Architecture document"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX052"]

[Learning outcomes]
    |
    v
[18.1 Trust boundaries]
    |
    v
[18.2 Defence in depth]
    |
    v
[18.3 Architecture document]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX052]

Learning outcomes

You will (1) define trust boundaries for the platform; (2) choose defence in depth; (3) document the security architecture.

18.1 Trust boundaries

A trust boundary is where data or control passes between parts with different levels of trust. Jonas marks boundaries on the context diagram: between meters and the gateway, between the internet and the member app, between the cooperative's systems and partner validators, and between administrators and contracts. Each boundary needs checks: authentication, validation or authorisation. Boundaries also show where an assumption about trust is being made, such as trusting partner validators to follow the agreed software version. He lists the check required at each boundary.

18.2 Defence in depth

Jonas layers protections so no single failure causes harm. For minting, the gateway checks capacity, the contract enforces an hourly cap, the minting role requires a multi-signature, a timelock delays role changes and monitoring alerts on anomalies. If any one layer fails, others still limit damage. He documents which threat each layer addresses and what happens if it fails. Defence in depth is especially valuable in contract systems because a single unnoticed flaw can otherwise have permanent effects. The board reviews the layers yearly.

18.3 Architecture document

The security architecture document describes components, trust boundaries, data flows, privileged roles, key management, monitoring and incident response. It references public guidance, including EthTrust's discussion of upgradeable contracts and ConsenSys best practices. Jonas presents it to Dr Nwosu and a partner engineer, who ask him to add how validator software upgrades are coordinated. The document becomes the reference against which later designs and reviews are checked. He adds the requested section, records the reviewers' comments and their resolution, and stores the document with the decision records so that later changes to the architecture can be compared against it.

Worked example

Jonas marks four trust boundaries, layers five protections around minting and writes a security architecture document reviewed by two engineers.

Synthetic case. Components and reviews are synthetic; EEA EthTrust and ConsenSys best practices are real sources.

Errors and limits

Relying on a single control for a high-value function leaves no protection if it fails.

Exercises

• EX052 — Boundary example. Name one trust boundary. Rubric: 3 = meters to gateway;; 2 = admin to contracts;; 1 = vague;; 0 = none.
• EX053 — Minting layers. How many layers protect minting? Rubric: 3 = five;; 2 = 5;; 1 = one;; 0 = none.
• EX054 — Review addition. What did reviewers ask to add? Rubric: 3 = coordination of validator software upgrades;; 2 = upgrades;; 1 = vague;; 0 = none.

Synthesis

Clear trust boundaries and layered controls, documented in one architecture, guide secure design.

Continue studying — chapter 18 of 50

← Chapter 17 (draft) · Course chapter index · Chapter 19 (draft) →