Chapter 16 — Systems engineering | Engineering Critical infrastructure and sector security

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Lesson map

Lesson 16 published. Map, example, EX031.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["16.1 The lifecycle and the V"]
  N2["16.2 Needs, requirements, traceability"]
  N3["16.3 Interfaces and configuration"]
  N4["16.4 Security as a systems engineering discipline"]
  N5["16.6 Practical activity"]
  N6["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Worked example"]
  EX --> Q["Exercise EX031"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["16.1 The lifecycle and the V"]
  N2["16.2 Needs, requirements, traceability"]
  N3["16.3 Interfaces and configuration"]
  N4["16.4 Security as a systems engineering discipline"]
  N5["16.6 Practical activity"]
  N6["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX031"]

[Learning outcomes and connection]
    |
    v
[16.1 The lifecycle and the V]
    |
    v
[16.2 Needs, requirements, traceability]
    |
    v
[16.3 Interfaces and configuration]
    |
    v
[16.4 Security as a systems engineering discipline]
    |
    v
[16.6 Practical activity]
    |
    v
[Chapter synthesis]
    |
    v
[Worked example] --> [Exercise EX031]

Learning outcomes and connection

After this chapter you can (1) apply the systems engineering lifecycle — concept, requirements, architecture, design, integration, verification, validation, operation, retirement — to a security programme; (2) decompose stakeholder needs into system and subsystem requirements with traceability; (3) manage interfaces and configuration; and (4) integrate security engineering into systems engineering rather than bolting it on. It builds on Chapters 5 and 14 and frames the whole second half of the book.

16.1 The lifecycle and the V

Systems engineering manages complexity by moving from needs to requirements to architecture to components, then back up through integration and verification. The V-model pairs each level of decomposition on the left with a level of verification on the right: stakeholder needs with validation, system requirements with system verification, subsystem design with integration tests, components with unit tests. The NASA Systems Engineering Handbook describes this lifecycle and its technical reviews. Iterative development does not abolish the V; it runs smaller Vs more often.

16.2 Needs, requirements, traceability

Stakeholder needs are what people need the system to achieve, in their language: "the hospital must not lose water for more than four hours". System requirements translate needs into verifiable statements about the system (Chapter 5). Traceability links every requirement upward to a need and downward to design elements and verification. A requirement with no parent is gold-plating or a hidden need; a need with no requirement is a gap; a requirement with no verification is an unsupported claim (Chapter 38 and Lab 14).

16.3 Interfaces and configuration

Most system failures happen at interfaces — between subsystems, organisations or people. An interface control document specifies data, timing, protocols, power, physical connections and responsibilities on each side. Configuration management identifies each item (hardware, firmware versions, settings, documents), controls changes through review and keeps records so that the as-built system is known. In security, an unknown configuration is an unknown attack surface.

TMRP's three interface control documents cover RTU to gateway, gateway to SCADA and SCADA to DMZ. Each names an owner on both sides.

16.4 Security as a systems engineering discipline

NIST SP 800-160 Vol. 1 Rev. 1 frames systems security engineering as security activities embedded in the systems engineering technical processes: stakeholder protection needs, security requirements, architectural design for security, verification of security claims, and secure operation and disposal. Its companion, SP 800-160 Vol. 2 Rev. 1, addresses cyber resiliency: anticipating, withstanding, recovering from and adapting to adverse conditions including attack.

TMRP follows this approach: N2 is a protection need decomposed into R1 and R2, and each has a planned verification.

16.5 Worked example: TMRP as a system (synthetic)

TMRP's top-level needs: N1 keep the hospital supplied (≤ 4 h interruption in credible scenarios); N2 detect and contain misuse of remote control; N3 recover remote operation within one working day; N4 retain operator visibility during grid outages. These decompose into requirements R1–R9 introduced so far (authenticated telemetry, replay rejection, setpoint bounds, local manual mode, 24 h cabinet hold-up, restoration within 8 h, alarms within 60 s, log integrity, independent dosing alarm). The team writes interface control documents for RTU-to-gateway, gateway-to-SCADA and SCADA-to-DMZ, and places all RTU firmware versions and configuration files under change control. Each requirement now has a parent need and a planned verification method.

16.6 Practical activity

Draw a traceability matrix N1–N4 × R1–R9 and mark each requirement's parent(s). Identify any need with weak coverage.

Use a simple grid with needs as columns and requirements as rows, and mark each requirement's parent or parents. Some requirements serve more than one need: R5 supports visibility during grid outages, and R1 supports both containment and hospital supply. When you have finished, count the requirements under each need. A need supported by only one requirement deserves a second look, because a single failed test would leave it unsupported in the dossier.

16.7 Common errors and limits

Requirements written after design to justify it.
Interfaces owned by nobody.
Configuration known only by the commissioning engineer.
Security requirements in a separate document, never traced or verified.
Treating the V-model as a waterfall excuse to defer testing.

In TMRP each of these has a counter-measure: requirements trace to N1 to N4, each interface has an owner, and RTU firmware and configuration are under change control. Verification is planned for every requirement before design starts, so the V is not used as a reason to defer testing.

Exercises — chapter 16

EX031 — Trace and find gaps. Objective: build and analyse a traceability matrix. Inputs: §16.5. Steps: assign each of R1–R9 to its parent need(s); identify which need relies on the fewest requirements and propose one additional requirement. Expected evidence: matrix and proposal. Rubric: 3 = defensible mapping, weakest need identified with a verifiable new requirement; 2 = mapping errors; 1 = no proposal; 0 = none.

EX032 — Interface control. Objective: specify an interface completely. Inputs: the gateway-to-SCADA interface. Steps: list at least eight interface attributes with example values (data items, encoding, rate, latency, authentication, error handling, time source, ownership, change process). Expected evidence: table. Rubric: 3 = complete and consistent with Labs 8 and 13; 2 = missing security or ownership attributes; 1 = data only; 0 = none.

Chapter synthesis

Systems engineering moves from needs to verified, validated systems through traceable requirements, managed interfaces and controlled configuration. Security belongs inside those processes: protection needs become requirements, requirements become architecture and design, and every security claim needs verification evidence.