Chapter 16 — Systems engineering
Lesson map
Lesson 16 published. Map, example, EX046.
flowchart TD
N0["Learning outcomes"]
N1["16.1 The life cycle"]
N2["16.2 Engineering trustworthiness"]
N3["16.3 Traceability"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX046"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["16.1 The life cycle"]
N2["16.2 Engineering trustworthiness"]
N3["16.3 Traceability"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX046"]
[Learning outcomes]
|
v
[16.1 The life cycle]
|
v
[16.2 Engineering trustworthiness]
|
v
[16.3 Traceability]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX046]
Learning outcomes
You will (1) describe the systems-engineering life cycle; (2) apply NIST SP 800-160 Vol. 1 Rev. 1 concepts to a transit system; (3) build traceability from needs to verification.
16.1 The life cycle
Systems engineering manages complex systems from concept to retirement. Daniel explains that a fare system involves hardware on vehicles, software in data centres, cloud services, people and contracts, so it must be engineered as a whole. Life-cycle stages include concept, development, production, utilisation, support and retirement. Security concerns arise in each: requirements in concept, design reviews in development, secure manufacturing in production, monitoring in utilisation, patching in support and data destruction at retirement. Sofia realises that many security failures she has read about happened in support or retirement, stages that projects often neglect.
16.2 Engineering trustworthiness
NIST SP 800-160 Vol. 1 Rev. 1 treats security as part of system trustworthiness and integrates it into systems-engineering processes. It emphasises stakeholder protection needs, security requirements derived from them, architecture and design that satisfy those requirements, and assurance that the system actually does so. It also lists design principles, extending Saltzer and Schroeder with ideas such as least persistence and continuous protection. Sofia uses the publication to structure a short paper on the fare validator, linking passenger protection needs to requirements such as tamper evidence and protected keys.
16.3 Traceability
Traceability links each stakeholder need to requirements, design elements and verification evidence. Sofia builds a small traceability table: the need that passengers' journey data stays private links to requirements for encryption in transit and at rest, which link to design elements such as TLS and disk encryption, which link to tests and configuration checks. When a test fails or a requirement changes, traceability shows what else is affected. Without it, teams cannot tell whether every need has been met or which design element exists for which reason.
Worked example
Sofia maps security concerns to six life-cycle stages, structures a validator paper with SP 800-160 Vol. 1 Rev. 1 concepts and builds a needs-to-tests traceability table.
Synthetic case. The validator paper and table are synthetic; SP 800-160 Vol. 1 Rev. 1 is real.
Errors and limits
Traceability tables become burdensome if too detailed. Life-cycle models are simplifications of iterative real projects.
Exercises
- EX046 — Neglected stages. Which life-cycle stages are often neglected for security? Rubric: 3 = support and retirement;; 2 = both;; 1 = development;; 0 = none.
- EX047 — SP 800-160 flow. What chain does SP 800-160 Vol. 1 Rev. 1 emphasise? Rubric: 3 = protection needs to requirements to design to assurance;; 2 = chain;; 1 = vague;; 0 = none.
- EX048 — Traceability value. What does traceability show when a requirement changes? Rubric: 3 = which design elements and tests are affected;; 2 = affected items;; 1 = vague;; 0 = none.
Synthesis
Systems engineering spreads security across the whole life cycle and keeps needs, designs and evidence linked.
Continue studying — chapter 16 of 50
← Chapter 15 (draft) · Course chapter index · Chapter 17 (draft) →