Chapter 39 — Security architecture and engineering: maintainability
Lesson map
Lesson 39 published. Map, example, EX115.
flowchart TD
N0["Learning outcomes"]
N1["39.1 Long-lived systems"]
N2["39.2 Cryptographic agility"]
N3["39.3 Security technical debt"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX115"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["39.1 Long-lived systems"]
N2["39.2 Cryptographic agility"]
N3["39.3 Security technical debt"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX115"]
[Learning outcomes]
|
v
[39.1 Long-lived systems]
|
v
[39.2 Cryptographic agility]
|
v
[39.3 Security technical debt]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX115]
Learning outcomes
You will (1) design for maintainable security over a long life; (2) plan cryptographic agility and component replacement; (3) manage technical debt in security controls.
39.1 Long-lived systems
Transit systems run for decades. Validators bought today may still operate in fifteen years, long after their software libraries stop receiving updates. Sofia studies maintainability: the ease of changing a system safely. For security this means the ability to patch components, rotate keys, replace algorithms and update rules without redesign. She reviews the back-office design for maintainability and finds that the tariff-verification component hard-codes one signature algorithm and one key, which would make future changes risky and slow. She proposes configuration-driven key and algorithm selection with versioned formats.
39.2 Cryptographic agility
Algorithms age. NIST published post-quantum standards FIPS 203, 204 and 205 in 2024, and organisations will need to migrate from current public-key algorithms over the coming years. Sofia designs the tariff-signing format with a version field and an algorithm identifier, so the back office can accept both current and future signature types during a transition. She inventories every place public-key cryptography is used, a prerequisite for planning migration. Agility does not mean supporting every algorithm; it means being able to change deliberately, with tested procedures, when change becomes necessary.
39.3 Security technical debt
Shortcuts accumulate: an exception granted for a demo that was never removed, a firewall rule added during an incident and forgotten, a deprecated protocol kept for one old partner. Sofia creates a security debt register listing each item, its risk, its owner and the plan to remove it. Items are reviewed quarterly, and new exceptions must have expiry dates. She presents the register to the architecture board as a normal part of maintenance, not a confession. Making debt visible lets the organisation pay it down deliberately instead of discovering it during an incident.
Worked example
Sofia replaces a hard-coded signature algorithm with versioned, configuration-driven selection, inventories public-key use for post-quantum planning and starts a security debt register.
Synthetic case. Components and debt items are synthetic; FIPS 203, 204 and 205 are real.
Errors and limits
Agility adds complexity and downgrade risks if old algorithms remain accepted too long. Debt registers need executive attention to be effective.
Exercises
- EX115 — Hard-coded issue. What maintainability problem did Sofia find in tariff verification? Rubric: 3 = a hard-coded signature algorithm and key;; 2 = hard-coded;; 1 = vague;; 0 = none.
- EX116 — Agility enabler. Which format features enable cryptographic agility for tariff signatures? Rubric: 3 = a version field and algorithm identifier;; 2 = both;; 1 = vague;; 0 = none.
- EX117 — Debt register. What does each security debt register entry include? Rubric: 3 = risk, owner and removal plan;; 2 = three;; 1 = vague;; 0 = none.
Synthesis
Maintainable security plans for change in algorithms, components and rules, and keeps security debt visible.
Continue studying — chapter 39 of 50
← Chapter 38 (draft) · Course chapter index · Chapter 40 (draft) →