Chapter 29 — Capstone build

Chapter 29 — Capstone build

Lesson map

Lesson 29 published. Map, example, EX085.

flowchart TD
  N0["Learning outcomes"]
  N1["29.1 The capstone"]
  N2["29.2 Building and testing"]
  N3["29.3 Documenting"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX085"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["29.1 The capstone"]
  N2["29.2 Building and testing"]
  N3["29.3 Documenting"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX085"]

[Learning outcomes]
    |
    v
[29.1 The capstone]
    |
    v
[29.2 Building and testing]
    |
    v
[29.3 Documenting]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX085]

Learning outcomes

You will (1) build a complete security improvement for a depot; (2) integrate earlier work; (3) document the build.

29.1 The capstone

Tomás's capstone is a security baseline package for Brightwater's planned fifth depot, opening next year. It must let Sam set up a new depot securely without reinventing decisions. The package includes the zone design, firewall rule template, device configuration baselines, role definitions, monitoring rules, runbooks and a setup checklist. It draws on every earlier chapter. Ruth approves the scope because it produces something reusable rather than a one-off report, and Sam confirms the fifth depot will use it. He agrees a delivery date two months before the depot opens.

29.2 Building and testing

Tomás builds the package in a test environment at the polytechnic: a virtual firewall loaded with the rule template, a test handheld enrolled with the baseline and a test account set using the roles. He runs the earlier scripts against the test setup: the rule checker finds no inbound rules open to anywhere, the alert rules fire on simulated events, and the leaver script works with the test exports. One baseline setting breaks the label printer driver, so he adjusts it and records why.

29.3 Documenting

Tomás writes the package as a short guide with a checklist at the front. Each item links to the reason behind it, such as a risk scenario or principle, so future staff can judge whether it still applies. He includes a change log and version number. Sam reviews it and asks for one addition: how to request vendor access for the new conveyor. Documentation that explains reasons is easier to maintain, because people can update it intelligently instead of following steps they do not understand.

Worked example

Tomás builds and tests a reusable depot security baseline package in a lab, fixing a printer conflict, and documents it with reasons and versioning.

Synthetic case. The package and test environment are synthetic.

Errors and limits

Lab tests miss site-specific quirks. Packages age without an owner.

Exercises

• EX085 — Why reusable. Why did Ruth approve the capstone scope? Rubric: 3 = it produces something reusable;; 2 = reuse;; 1 = size;; 0 = none.
• EX086 — Test conflict. What problem did testing reveal? Rubric: 3 = a baseline setting broke the label printer driver;; 2 = printer;; 1 = vague;; 0 = none.
• EX087 — Linked reasons. Why link each checklist item to a reason? Rubric: 3 = so future staff can judge whether it still applies;; 2 = judgement;; 1 = vague;; 0 = none.

Synthesis

A capstone that builds, tests and explains a reusable baseline leaves lasting value for the organisation.

Continue studying — chapter 29 of 30

← Chapter 28 (draft) · Course chapter index · Chapter 30 (draft) →