Chapter 39 — Information security: maintainability
Lesson map
Lesson 39 published. Map, example, EX115.
flowchart TD
N0["Learning outcomes"]
N1["39.1 Maintainable code"]
N2["39.2 Runbooks"]
N3["39.3 Ownership transfer"]
N4["39.4 Dependency on people"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX115"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["39.1 Maintainable code"]
N2["39.2 Runbooks"]
N3["39.3 Ownership transfer"]
N4["39.4 Dependency on people"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX115"]
[Learning outcomes]
|
v
[39.1 Maintainable code]
|
v
[39.2 Runbooks]
|
v
[39.3 Ownership transfer]
|
v
[39.4 Dependency on people]
|
v
[Worked example] --> [Exercise EX115]
Learning outcomes
You will (1) keep security tools maintainable; (2) document controls for successors; (3) plan for staff turnover.
39.1 Maintainable code
Lindiwe's scripts now run Saltmarsh's baseline checks, guessing measure and restore tests. She will leave at the end of her course, so others must maintain them. She reviews her code for clarity: descriptive names, comments explaining why rather than what, tests for every rule and a single configuration file for thresholds. Prof. Hale notes that security tooling often fails when its author leaves, because nobody understands it well enough to change it safely. She also removes two unused functions found during the review.
39.2 Runbooks
For each control, Lindiwe writes a runbook: purpose, schedule, inputs, how to read results, common problems and who to contact. The restore test runbook explains what to do when checksums mismatch, including checking disk health and rerunning the restore. She asks a colleague with no involvement to follow each runbook. Two steps prove unclear and she rewrites them. She learns that documentation is tested by use, not by the author's reading. The final runbooks are stored with the scripts in version control.
39.3 Ownership transfer
Lindiwe arranges owners for each tool within Saltmarsh's IT team and holds handover sessions. Each owner runs the tool once with her watching, then once alone. She updates the asset model and decision records to name the new owners. Prof. Hale explains that ownership transfer is a control in its own right: without it, tools become orphaned, just like the camera system she found in her third year. The new owners sign the handover records, and Lindiwe remains available by email for questions during her final term.
39.4 Dependency on people
Lindiwe notes that some controls depend on single individuals, such as the security lead's monthly sample review. If that person is absent, the control stops. She recommends deputies for each person-dependent control and records them in the runbooks. She learns that maintainability applies to processes and people as well as code, and that resilience against staff absence is part of security engineering. Each deputy performs the control once during the handover period, and the runbooks record their names and the dates on which they last performed it, so the security lead can see who is ready.
Worked example
Lindiwe improves code clarity, writes runbooks tested by a colleague, transfers tool ownership with supervised runs and adds deputies for person-dependent controls.
Synthetic case. Tools and staff are synthetic.
Errors and limits
Tools whose authors leave without handover become unmaintained.
Exercises
- EX115 — Configuration. Where are thresholds kept? Rubric: 3 = a single configuration file;; 2 = partly correct;; 1 = code;; 0 = none.
- EX116 — Runbook test. How are runbooks tested? Rubric: 3 = a colleague follows each one;; 2 = partly correct;; 1 = vague;; 0 = none.
- EX117 — Deputies. Why add deputies? Rubric: 3 = controls stop when one person is absent;; 2 = partly correct;; 1 = vague;; 0 = none.
Continue studying — lesson 39 (chapter 39 of 50)
← Chapter 38 · Course chapter index · Chapter 40 →
Continue to the next authored lesson.