◇ OpenCyber Academy
Engineering · Chapter 45 · English

Chapter 45 — Independent design review

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 45 — Independent design review

Lesson map

Lesson 45 published. Map, example, EX133.

flowchart TD
  N0["Learning outcomes"]
  N1["45.1 Reviewer"]
  N2["45.2 Findings"]
  N3["45.3 Response"]
  N4["45.4 Recording"]
  N5["45.5 Value"]
  N6["Preparing for review"]
  N7["Follow-up"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX133"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["45.1 Reviewer"]
  N2["45.2 Findings"]
  N3["45.3 Response"]
  N4["45.4 Recording"]
  N5["45.5 Value"]
  N6["Preparing for review"]
  N7["Follow-up"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX133"]

[Learning outcomes]
    |
    v
[45.1 Reviewer]
    |
    v
[45.2 Findings]
    |
    v
[45.3 Response]
    |
    v
[45.4 Recording]
    |
    v
[45.5 Value]
    |
    v
[Preparing for review]
    |
    v
[Follow-up]
    |
    v
[Worked example] --> [Exercise EX133]

Learning outcomes

You will (1) undergo independent review; (2) address findings; (3) improve the design.

45.1 Reviewer

An engineer from another council reviews the design and evidence.

The reviewer runs public computers for a neighbouring council's libraries and has faced similar problems. She has no connection to the project or to Fernhill's staff. Mateo gives her the full package in advance, as described below, and asks her to judge the design and the evidence, not just the documents. She is free to ask for any record or to see a lab PC running. Her travel costs are covered by Fernhill.

45.2 Findings

Strong restore and layering; weaker monitoring of firmware versions; signing key storage needs improvement.

Her praise for the restore and the layering confirms the core of the design. The two weaknesses are specific and fixable. Firmware versions were recorded in the inventory but not monitored, so a downgrade or an unapproved update could go unnoticed. The signing key, held on Marta's workstation as noted in the identity chapter, was the most serious single point of failure in the design. She ranked the key issue first.

45.3 Response

Firmware versions join the dashboard; signing keys move to a hardware security module service.

Both responses were planned within a week of the review. The dashboard change was quick, since firmware versions were already collected. Moving the signing key needed a documented procedure and two people present, as described below. Mateo also added the nightly check for firmware downgrades that the worked example describes. Each response is linked to the finding it answers. Both changes were tested on lab PCs before release.

45.4 Recording

Findings and responses are recorded.

Each finding is recorded with the reviewer's words, Mateo's response, the action taken, its owner and the date it was closed. Findings he decided not to act on are recorded with reasons, such as the deferred attestation work. The record goes into the evidence dossier and is shared with the reviewer, who confirms that the actions match her intent. The reviewer receives the completed record a month later, with links to evidence for every closed action, and is invited to comment on anything that still concerns her.

45.5 Value

External eyes see what the team overlooked.

The team had lived with the design for a long time and stopped noticing some of its assumptions, such as the key on a workstation that everyone knew about. A reviewer who sees the system fresh notices those things at once. Her experience with another network also brought knowledge the team did not have. Mateo recommends that Fernhill repeat the review when the design changes significantly. Marta agreed and added the review to the annual checklist.

Preparing for review

Mateo sends the reviewer the requirements, design records, test evidence and measurements a week in advance, with a short guide to where things are. Preparation lets the reviewer spend time on judgement rather than searching. The review meeting lasts two hours, with findings written up the next day.

He treats every finding as useful, even ones he disagrees with, and records reasons when he decides not to act.

Follow-up

Actions from the review are tracked to completion and shown to the reviewer.

Firmware dashboard

The dashboard now shows firmware versions by model.

Key ceremony

Key moves follow a documented procedure with two people present.

Reviewer independence

The reviewer had no part in the design, so findings are independent.

Thanks

Mateo thanks the reviewer.

Outcome

The design is improved in two areas.

Records

Findings are stored.

Timing

Actions finish within a month.

Value of outside views

The reviewer's experience with another council's kiosks brought practical knowledge Mateo lacked, such as how often firmware settings reset after hardware repairs.

Recording disagreements

One suggestion, adding full attestation, is deferred with reasons: it needs new tooling.

Final review status

All review actions are closed and confirmed with the reviewer within a month.

Worked example

The reviewer asks how the team would notice a firmware downgrade. Mateo adds a check comparing firmware versions to the approved list nightly.

Synthetic case. Synthetic.

Errors and limits

Reviews only help if findings are acted on.

Exercises

Synthesis

Act on independent review findings.

Continue studying — chapter 45 of 50

← Chapter 44 (draft) · Course chapter index · Chapter 46 (draft) →