Chapter 25 — Design studio I | Engineering OT, IoT and cyber-physical security

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 25 — Design studio I

Lesson map

Lesson 25 published. Map, example, EX073.

flowchart TD
  N0["Learning outcomes"]
  N1["25.1 Studio problem"]
  N2["25.2 Trade-offs"]
  N3["25.3 Decision record"]
  N4["Practice note"]
  N5["25.1b Constraint cards and gallery"]
  N6["Field note — labelling before layout"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX073"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["25.1 Studio problem"]
  N2["25.2 Trade-offs"]
  N3["25.3 Decision record"]
  N4["Practice note"]
  N5["25.1b Constraint cards and gallery"]
  N6["Field note — labelling before layout"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX073"]

[Learning outcomes]
    |
    v
[25.1 Studio problem]
    |
    v
[25.2 Trade-offs]
    |
    v
[25.3 Decision record]
    |
    v
[Practice note]
    |
    v
[25.1b Constraint cards and gallery]
    |
    v
[Field note — labelling before layout]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX073]

Learning outcomes

You will (1) sketch the allow/deny pipeline for ABP's serial monitor; (2) justify trade-offs in a short design review; (3) produce a one-page decision record.

25.1 Studio problem

Design: input frame to decode to load ConduitSet/allow-list to evaluate permit to emit event to forward or drop. Options: embed policy in code vs signed data file; sync vs async alerts on denies.

Lena's studio team at ABP sketches the whole path on one page and labels where a frame is denied if the policy is missing. The two choices debated were whether the allow-list lives in code or in a signed data file, and whether alerts about denies are sent synchronously or queued. Each option is written down with its consequences before anyone argues for one.

25.2 Trade-offs

Policy-as-signed-data lets updates ship without redeploying firmware but needs signature verification and fail-closed on bad signatures. Async alerts scale but can reorder; for SIS-path denies, prefer sync alert.

Lena's team agrees that a bad signature must stop all non-essential traffic, exactly as requirement S-1 demands for a missing policy. Sync alerts are kept for denies on write codes and SIS-related paths, where delay matters; routine read denies are queued. The team also records what happens if the signing key is lost: the monitor keeps the last valid list and alarms, and no unsigned update is accepted.

25.3 Decision record

One page: context, options, decision, consequences, date, owners. Store next to the code.

Synthetic case — Ashford Batch Plant. Studio chose signed JSON allow-lists, sync path for denies that touch write codes, async bulk for routine reads. ADR-004 captures it.

ADR-004 records the studio's decision on signed JSON allow-lists in this format, with Lena and the control-engineering lead as owners. It sits in the repository next to the policy code, so anyone changing the loader can read why it works the way it does.

25.4 Errors and limits

Studios that skip safety requirements produce pretty diagrams that fail open.

Lena's studio refuses to review a design until it shows where the monitor denies traffic when the allow-list is missing or its signature fails. Designs that cannot answer are sent back before any discussion of layout or tools. The constraint cards make the safety requirements visible on the table from the first minute, so they cannot be forgotten in enthusiasm for a clever architecture. Rejected designs are recorded too.

Practice note

Facilitators pause the room with: Where do we DENY if policy is missing? If nobody can answer, architecture is not ready.

25.1b Constraint cards and gallery

Hand each studio team constraint cards: residency, two-engineer ops, fail-closed, no empty scores, SIS independence. Designs that violate a card are rejected before aesthetic debate. Studios end with a gallery: teams post ADR drafts and others try to find a fail-open path in five minutes.

A studio sketch must name trust boundaries, data stores and the fail-closed path in writing. Ten minutes of labelling beats an hour of aesthetic layout. Fail-open paths found in the gallery are written into the ADR before it is accepted.

Field note — labelling before layout

Studio teams that spent the first twenty minutes naming DENY points and trust boundaries produced ADRs that survived review. Teams that started with colour palettes rediscovered fail-open paths during gallery. CNHP now requires a labelled fail-closed path on the whiteboard photograph attached to every ADR.

Exercises

EX073 — Options. Two options for policy delivery and one risk each. Rubric: 3 = two + risks; 2 = options; 1 = one; 0 = none.
EX074 — ADR. Decision line for sync deny alerts on write codes. Rubric: 3 = clear decision + why; 2 = decision only; 1 = vague; 0 = none.
EX075 — Review. Three questions a reviewer must ask. Rubric: 3 = fail-closed, authn of policy, latency budget; 2 = two; 1 = one; 0 = none.

Synthesis

Studio work ends in a recorded decision, not a vibe.

Continue studying — chapter 25 of 50

← Chapter 24 (draft) · Course chapter index · Chapter 26 (draft) →