Chapter 12 — Critical infrastructure and sector security: data flows
Lesson map
Lesson 12 published. Map, example, EX034.
flowchart TD
N0["Learning outcomes and connection"]
N1["12.1 The register"]
N2["12.2 Data classes"]
N3["12.3 Verifying the register"]
N4["12.4 New flows need review before they start"]
N5["12.6 Practical activity: register check"]
N6["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX034"]
Logical drawing
flowchart LR
N0["Learning outcomes and connection"]
N1["12.1 The register"]
N2["12.2 Data classes"]
N3["12.3 Verifying the register"]
N4["12.4 New flows need review before they start"]
N5["12.6 Practical activity: register check"]
N6["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX034"]
[Learning outcomes and connection]
|
v
[12.1 The register]
|
v
[12.2 Data classes]
|
v
[12.3 Verifying the register]
|
v
[12.4 New flows need review before they start]
|
v
[12.6 Practical activity: register check]
|
v
[Chapter synthesis]
|
v
[Worked example] --> [Exercise EX034]
Learning outcomes and connection
After this chapter you should be able to:
- maintain a data-flow register that records, for each flow, its source, destination, data class, protection and retention;
- classify data in a critical service: operational telemetry, configuration, personal and patient-linked data, security logs;
- verify the register against what systems actually send and keep;
- recognize when a new flow needs privacy, contractual or safety review before it starts.
Chapter 2 compared network flows with declared conduits. A conduit says a path is allowed; a data-flow register says what data travels on it, how it is protected and how long it is kept at the other end. In shared services the second question is often the one that gets an organization into trouble, because data outlive the reason they were collected.
12.1 The register
Each entry in LANTERN's register records: identifier; source and destination (systems, not just addresses); data class; whether the flow is encrypted in transit; how long the destination keeps the data; the purpose; the owner; and, for personal data, the legal basis recorded by the data owner. The register is a document that people read in an incident ("what left the hospital gateway?") and in a privacy request ("where does this patient's pump data go?").
DF5 is a model entry: clinical gateway to Halden Cloud, patient-linked, encrypted, 30 days registered.
12.2 Data classes
For an implementer, four classes cover most of a critical shared service:
- Operational telemetry — readings and states (levels, flows, chlorine). Usually not personal, but integrity-critical and sometimes sensitive in aggregate (it reveals how the network works).
- Configuration and engineering data — controller programs, network diagrams, setpoints, relay configuration. Highly sensitive: it is a map for an attacker.
- Personal and patient-linked data — anything about an identifiable person. In the hospital, infusion-pump event logs linked to a ward and time can identify a patient. Data-protection law applies; in the EU, the GDPR (Regulation (EU) 2016/679) requires, among other principles, that personal data be kept no longer than necessary for their purpose.
- Security logs — authentication, flows, alerts. They often contain personal data (user names, addresses) and must be protected and retained according to policy.
NIST's Privacy Framework offers a structure for managing privacy risk alongside cybersecurity risk (NIST Privacy Framework).
12.3 Verifying the register
Registers decay like inventories. Verify them by sampling what actually happens: which systems send to which (flows), what class of data is in the payloads (metadata sampling by the data owner, not by reading patients' records), whether the transport is encrypted, and how long the destination actually keeps data (its retention settings and the age of its oldest records). Differences fall into familiar types: unregistered flows; flows sending a different class than registered; encryption registered but absent; retention longer than registered.
12.4 New flows need review before they start
Most data-flow problems begin with a reasonable request: a supplier wants telemetry for remote diagnostics; a reporting team wants a copy of clinical gateway events. Before such a flow starts, the register entry is written and reviewed — by the data owner, by security (protection and conduit), and where personal data are involved by the privacy function. If it carries control or configuration data, the architecture rule of Chapter 8 applies.
Kell's request for hourly telemetry from the relays is the Fallowmere case: the entry must be written and reviewed before the first hour is sent.
12.5 Worked example: register versus reality (synthetic)
Lab 12 compares five register entries with seven observed flows. Four registered flows match. Three differences matter:
- DF5 — clinical gateway to Halden Cloud — keeps patient-linked data for 400 days against a registered 30. The flow is registered and encrypted, but retention at the destination does not match. This is a privacy and contract issue; the hospital's data owner must be told, and Halden's retention setting checked against the contract.
- An unregistered flow from the historian to a vendor-support system, in clear text. It carries telemetry — not personal, but operationally sensitive — without encryption and without anyone having approved it.
- An unregistered flow from the clinical gateway to the reports server carrying patient-linked data. Encrypted, but nobody approved it, and the reports server is in the corporate zone used by water staff.
The third is the most serious despite being encrypted: patient-linked data have reached a system and an audience with no purpose recorded. Encryption in transit protects the journey, not the destination.
12.6 Practical activity: register check
Lab 12 (save as lab12.py, run with python3 lab12.py):
# Lab 12 - checking a data-flow register against what the service actually sends (offline, standard library only)
# Synthetic: Fallowmere shared services. Each register entry: id, source, destination, data class, encrypted, retention days.
register = [
("DF1", "PS-*", "RLY-01", "telemetry", False, 0),
("DF2", "RLY-01", "HIST-01", "telemetry", True, 730),
("DF3", "HIST-01", "REPORTS", "telemetry-aggregate", True, 365),
("DF4", "WARD-PUMPS", "CLIN-GW", "patient-linked", True, 30),
("DF5", "CLIN-GW", "HALDEN-CLOUD", "patient-linked", True, 30),
]
observed = [ # source, destination, data class seen by sampling payload metadata, tls?, stored days at destination
("PS-04", "RLY-01", "telemetry", False, 0), ("RLY-01", "HIST-01", "telemetry", True, 730),
("HIST-01", "REPORTS", "telemetry-aggregate", True, 365), ("WARD-PUMPS", "CLIN-GW", "patient-linked", True, 30),
("CLIN-GW", "HALDEN-CLOUD", "patient-linked", True, 400), ("HIST-01", "VENDOR-SUPPORT", "telemetry", False, None),
("CLIN-GW", "REPORTS", "patient-linked", True, 365),
]
sensitive = {"patient-linked"}
def match(src, dst):
for r in register:
if (r[1] == src or (r[1].endswith("*") and src.startswith(r[1][:-1]))) and r[2] == dst:
return r
for src, dst, cls, enc, keep in observed:
r = match(src, dst)
if r is None:
sev = "HIGH" if cls in sensitive else "MED"
print(f"{sev:<4} unregistered flow {src}->{dst} ({cls}, encrypted={enc})")
continue
issues = []
if r[3] != cls: issues.append(f"class {cls} != registered {r[3]}")
if r[4] and not enc: issues.append("registered encrypted but sent clear")
if keep is not None and keep > r[5]: issues.append(f"kept {keep} d > registered {r[5]} d")
print(f"{'OK ' if not issues else 'HIGH' if cls in sensitive else 'MED '} {r[0]} {src}->{dst} {'; '.join(issues)}")
Expected output (Python 3.13.5):
OK DF1 PS-04->RLY-01
OK DF2 RLY-01->HIST-01
OK DF3 HIST-01->REPORTS
OK DF4 WARD-PUMPS->CLIN-GW
HIGH DF5 CLIN-GW->HALDEN-CLOUD kept 400 d > registered 30 d
MED unregistered flow HIST-01->VENDOR-SUPPORT (telemetry, encrypted=False)
HIGH unregistered flow CLIN-GW->REPORTS (patient-linked, encrypted=True)
The output reproduces the three differences above. Before acting, decide who receives each one: the 400-day retention on DF5 goes to the hospital's data owner and to whoever holds the Halden contract; the clear-text historian flow to the vendor-support system goes to Water's data owner and FSTS Security; and the unregistered patient-linked flow to the reports server goes to the hospital's privacy function first, because a corporate-zone audience may already have seen the data.
12.7 Common errors and limits
- Registering paths (conduits) but not data classes and retention.
- Assuming "encrypted" means "acceptable".
- Treating operational telemetry as harmless because it is not personal.
- Verifying data classes by reading personal data yourself instead of asking the data owner to sample metadata.
- Letting a supplier or reporting flow start before the entry is reviewed.
The register shows what is known; flows that leave by unexpected routes (removable media, a supplier's laptop) need other controls.
The unregistered flow from the clinical gateway to the reports server is the second error at work: encrypted, and still unacceptable.
Exercises — chapter 12
EX034 — Triage the differences. Objective: prioritize data-flow findings. Inputs: Lab 12 output. Constraints: one action and owner per finding. Steps: (1) rank the three findings; (2) give the first action and the owner; (3) say which needs to be reported to someone outside FSTS. Expected evidence: table. Rubric: 3 = CLIN-GW→REPORTS first (unapproved patient-linked data in a wrong audience: stop flow with hospital data owner's agreement, assess), DF5 retention second (hospital data owner and Halden contract), vendor-support clear-text third (stop or encrypt, register); recognizes that whether external reporting is needed is the data owner's and privacy function's decision; 2 = ranking defensible, owners vague; 1 = ranks by encryption only; 0 = none.
EX035 — Write a register entry. Objective: specify a new flow before it starts. Inputs: Kell Instruments asks for hourly telemetry from PS-09 for remote diagnostics. Constraints: every field in Chapter 12 ("The register"); include conduit and protection. Steps: write the entry and list who must approve it. Expected evidence: entry and approvers. Rubric: 3 = specific source/destination (relay or historian export, not the RTU directly), data class operational telemetry, encrypted transport, minimum fields and frequency, retention limited and contractual, purpose, owner, approvals by Water data owner and FSTS security, with an expiry date; 2 = one field weak; 1 = "send data to Kell"; 0 = none.
EX036 — Extend the check. Objective: add a check to the tool. Inputs: Lab 12. Constraints: standard library only. Steps: (1) add a check that flags any flow of patient-linked data whose destination is not on an approved list {"CLIN-GW", "HALDEN-CLOUD"}, even if registered; (2) register ("DF6", "CLIN-GW", "REPORTS", "patient-linked", True, 365) and rerun; (3) explain why registration alone should not make that flow acceptable. Expected evidence: code, output, explanation. Rubric: 3 = REPORTS flow still flagged after registration; explanation that the register records decisions, and a registered flow to an unapproved audience is a bad decision to review, not a clean result; 2 = code works, explanation thin; 1 = not run; 0 = none.
Chapter synthesis
A data-flow register records what data travel where, how they are protected and how long they are kept. Classify data — telemetry, configuration, personal and patient-linked, security logs — and verify the register against what systems actually send and retain. Encryption protects the journey, not the destination. New flows are reviewed before they start, by the data owner, by security and, where personal data are involved, by the privacy function.
Continue studying — chapter 12 of 30
← Chapter 11 · Course chapter index · Chapter 13 →
Continue to the next authored lesson.