Chapter 16 — Systems engineering
Lesson map
Lesson 16 published. Map, example, EX046.
flowchart TD
N0["Learning outcomes"]
N1["16.1 Systems view"]
N2["16.2 Life cycle"]
N3["16.3 Interfaces"]
N4["16.4 Traceability"]
N5["16.5 Trade-offs"]
N6["16.6 Configuration management"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX046"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["16.1 Systems view"]
N2["16.2 Life cycle"]
N3["16.3 Interfaces"]
N4["16.4 Traceability"]
N5["16.5 Trade-offs"]
N6["16.6 Configuration management"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX046"]
[Learning outcomes]
|
v
[16.1 Systems view]
|
v
[16.2 Life cycle]
|
v
[16.3 Interfaces]
|
v
[16.4 Traceability]
|
v
[16.5 Trade-offs]
|
v
[16.6 Configuration management]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX046]
Learning outcomes
You will (1) treat meterhub as a system of interacting parts; (2) define requirements, interfaces and life cycle; (3) trace requirements to verification; (4) manage trade-offs across subsystems.
16.1 Systems view
meterhub is not just a cluster: it includes meters, the network operator, the ingest service, storage, billing, analysts, the cloud provider and the people who operate it. Security properties emerge from how these parts interact, not from any single control.
The key leak is a good example of an emergent problem. No single part was broken: the build tool did what it was told, the registry stored what it received, and the key worked as designed. The failure came from how a developer's habit, a build step and a public registry combined. A systems view looks for such combinations by tracing data and authority across every part, including people and outside organisations like the network operator.
16.2 Life cycle
Systems engineering follows concept, requirements, design, implementation, verification, operation and retirement. Security must appear at each stage; retirement matters too, since old clusters and buckets left running were a source of exposure in many organisations.
Security added only at implementation tends to be patched onto a design that fights it, while security considered at concept stage shapes the design itself. Retirement is easy to forget because nobody is paid to tidy up: a test cluster left running with old credentials, or a storage bucket that once held exports, keeps its exposure long after anyone remembers it. Elena adds a retirement checklist to Solent's design template, with an owner who signs off when every resource is gone.
16.3 Interfaces
Each interface is specified: what data crosses it, in what format, authenticated how and with what limits. The interface between ingest and storage, for example, carries readings over TLS with a workload identity and a maximum batch size.
Specifying limits matters as much as specifying formats. A maximum batch size stops one faulty or malicious caller from overwhelming storage with a single huge request. Naming the authentication method means both sides know what to expect and reviewers can check it. Elena writes each interface specification as a short table, so it can be compared directly with network policies and service configuration during reviews and audits.
16.4 Traceability
Every security requirement has an identifier, a source (standard, regulation or risk), a design element that meets it and a verification method. A traceability matrix shows gaps: requirements with no test, tests with no requirement.
A requirement without a test may be met or may not; nobody can tell. A test without a requirement may check something nobody needs, consuming time in every pipeline run. The matrix also helps when a standard changes: the team can find every requirement drawn from it and see which designs and tests might need updating. Elena keeps the matrix as a CSV file in the repository, reviewed alongside code changes.
16.5 Trade-offs
Stronger isolation (separate clusters per service) costs more and adds operational work; Solent chooses separate namespaces with strict policies and a separate cluster only for the payment-related service.
A separate cluster for every service would give the strongest isolation, but four engineers would have to patch, upgrade and monitor many clusters, increasing the chance that one falls behind. Namespaces with strict policies give good separation for most services at little extra cost. The payment-related service carries more risk and stricter compliance needs, which justifies the extra effort of its own cluster.
16.6 Configuration management
The system's configuration baseline is the set of reviewed templates and manifests in version control; changes go through change control.
A baseline answers the question 'what should the system look like right now?' Anything running that differs from it is drift, either an unrecorded change or a sign of compromise. Change control ensures every difference between one baseline and the next is reviewed and recorded. Comparing the live cluster with the baseline regularly shows whether reality still matches the plan.
Worked example
Elena builds the first traceability matrix with 24 security requirements. Five have no verification method, including "backups cannot be deleted from production". She adds a test that attempts a deletion from a production test role in a controlled way and expects it to be refused, and records the result.
Synthetic case. Requirements and tests are synthetic.
Errors and limits
A matrix can look complete while tests are weak; review test quality too.
Exercises
- EX046 — Emergent security. Why is security emergent in systems? Rubric: 3 = arises from interactions; 2 = partial; 1 = vague; 0 = none.
- EX047 — Retirement. Why does retirement matter? Rubric: 3 = old resources left running expose data; 2 = partial; 1 = vague; 0 = none.
- EX048 — Matrix gaps. What gaps did the first matrix show? Rubric: 3 = 5 requirements without verification; 2 = partial; 1 = vague; 0 = none.
Synthesis
Systems engineering traces security from requirements to tests across the life cycle.
Continue studying — chapter 16 of 50
← Chapter 15 (draft) · Course chapter index · Chapter 17 (draft) →