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 Responses"]
N4["45.4 Record"]
N5["Preparing material for a reviewer"]
N6["Handling disagreement"]
N7["Second review after changes"]
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 Responses"]
N4["45.4 Record"]
N5["Preparing material for a reviewer"]
N6["Handling disagreement"]
N7["Second review after changes"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX133"]
[Learning outcomes]
|
v
[45.1 Reviewer]
|
v
[45.2 Findings]
|
v
[45.3 Responses]
|
v
[45.4 Record]
|
v
[Preparing material for a reviewer]
|
v
[Handling disagreement]
|
v
[Second review after changes]
|
v
[Worked example] --> [Exercise EX133]
Learning outcomes
You will (1) obtain external review; (2) respond to findings; (3) record changes.
45.1 Reviewer
Kofi asks an experienced network engineer from a neighbouring council to review the design and evidence. The reviewer has no involvement in the project and no stake in its success, which is what makes the review independent. They also understand the constraints of a small public body, such as limited staff and procurement rules, so their advice is practical. Dr Vasquez agrees the choice and the scope of the review in advance. The reviewer receives read-only lab access and the documentation, but no access to production systems.
45.2 Findings
The reviewer reports two significant findings. First, all administrative access passes through a single jump host, so if it fails, engineers cannot manage firewalls without breaking the management design; that makes the jump host a single point of failure. Second, guest wireless is isolated from internal zones but guests can still reach one another, so an infected guest device could attack other guests' devices. Neither finding breaks a stated requirement, which shows the value of review: it finds weaknesses the requirements themselves did not anticipate.
45.3 Responses
Kofi accepts both findings. A second jump host is built at a different office, with the same controls and logging, and engineers test that either can be used to manage every firewall. Client isolation is enabled on the guest wireless network so guest devices can reach the internet but not each other. Both changes go through the normal change process, are lab tested against the regression suite, and add new tests to it so that the fixes cannot later be undone silently. The responses are small, but they close real gaps.
45.4 Record
Every finding, the response, the date it was closed and the evidence of closure are entered in a review log that goes into the dossier. Rejected suggestions are recorded too, with reasons. The log shows examiners that the design was tested by someone outside the project and that criticism changed it. It also gives future reviewers a starting point, so they can see what was already examined and concentrate on new areas rather than repeating the same review. Unrecorded reviews lose most of their value once the reviewer has left.
Preparing material for a reviewer
A useful review needs good material. Kofi prepares a review pack containing the architecture overview, the zone model, the needed-flows list, the policy template, the traceability table and a summary of test results, together with a short list of questions he wants answered, such as whether the management design is robust. He gives the reviewer read-only lab access rather than production access. The pack is limited to around forty pages so the reviewer can read it properly in the time available. Asking specific questions focuses the review on areas where Kofi is least certain of his own judgement.
Handling disagreement
Not every review comment must be accepted. The reviewer also suggests moving voice into the staff zone to simplify the policy. Kofi disagrees, because the phone provider requires separate quality-of-service treatment and voice handsets have limited security features, so separation reduces risk. He records the suggestion, his reasoning and the evidence, and Dr Vasquez agrees. A clear record of rejected suggestions shows that each comment was considered seriously, and lets a future reviewer reopen the question if circumstances change, such as replacing the handsets with devices that support stronger controls and simpler management.
Second review after changes
After implementing the accepted findings, Kofi asks the same reviewer for a short follow-up check. The reviewer confirms that the second jump host fails over correctly in the lab and that guest client isolation works on both wireless controller models used by the council. This closes the review loop with evidence rather than a statement that changes were made. The follow-up takes the reviewer about two hours, a small cost compared with the value of independent confirmation. Both reviews are included in the dossier with dates, the reviewer's role and a summary of findings and responses.
Worked example
Both changes are completed and regression tested.
Synthetic case. The review is synthetic.
Errors and limits
Reviews by people involved in the design miss blind spots.
Exercises
- EX133 — Jump host finding. What was the jump host finding? Rubric: 3 = single point of failure;; 2 = availability;; 1 = vague;; 0 = none.
- EX134 — Client isolation. What does client isolation add? Rubric: 3 = guests cannot reach each other;; 2 = isolation;; 1 = vague;; 0 = none.
- EX135 — Independence. Why use a reviewer from another council? Rubric: 3 = fresh perspective;; 2 = independent;; 1 = vague;; 0 = none.
Synthesis
Independent review strengthens the design.
Continue studying — chapter 45 of 50
← Chapter 44 (draft) · Course chapter index · Chapter 46 (draft) →