Chapter 13 — Data systems
Lesson map
Lesson 13 published. Map, example, EX025.
flowchart TD
N0["Learning outcomes and connection"]
N1["13.1 Models for operational data"]
N2["13.2 Transactions, consistency and replication"]
N3["13.3 Integrity: what each mechanism detects"]
N4["13.4 Getting data out without letting attacks in"]
N5["13.6 Practical activity: Lab 6"]
N6["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX025"]
Logical drawing
flowchart LR
N0["Learning outcomes and connection"]
N1["13.1 Models for operational data"]
N2["13.2 Transactions, consistency and replication"]
N3["13.3 Integrity: what each mechanism detects"]
N4["13.4 Getting data out without letting attacks in"]
N5["13.6 Practical activity: Lab 6"]
N6["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX025"]
[Learning outcomes and connection]
|
v
[13.1 Models for operational data]
|
v
[13.2 Transactions, consistency and replication]
|
v
[13.3 Integrity: what each mechanism detects]
|
v
[13.4 Getting data out without letting attacks in]
|
v
[13.6 Practical activity: Lab 6]
|
v
[Chapter synthesis]
|
v
[Worked example] --> [Exercise EX025]
Learning outcomes and connection
After this chapter you can (1) design relational and time-series data models for operational data; (2) explain transactions, consistency and replication; (3) protect data integrity with constraints, provenance and hash chains, and say exactly what each detects; and (4) plan data flows between control systems and enterprise analytics without opening a path into control. It builds on Chapters 9 and 11 and prepares Chapters 22 (data models) and 29 (measurement).
13.1 Models for operational data
Codd (1970) introduced the relational model: data as relations (tables) with keys, manipulated by set operations. Asset registers, work orders and user accounts fit it well. Process data — thousands of tags sampled every second — usually goes to a historian, a time-series store optimised for append and range queries, often with compression that discards changes smaller than a deadband. Know what your historian discards: forensic analysis may need values it never stored.
LRWA's historian stores the Hollin Hill level with deadband compression, so changes smaller than the deadband are never kept.
13.2 Transactions, consistency and replication
A transaction groups operations so that they all happen or none do (atomicity), leaving data valid (consistency), unaffected by concurrent transactions (isolation) and surviving crashes (durability). Replication copies data for availability; when replicas can disagree, systems choose between consistency and availability during a network partition. For operations: an operator's acknowledged alarm must not reappear as unacknowledged after failover; a setpoint change must not be applied twice.
In LRWA's SCADA pair, failover is the moment these properties are tested: integration testing should confirm that acknowledged alarms and applied setpoints survive the switch exactly once.
13.3 Integrity: what each mechanism detects
- Constraints (types, ranges, foreign keys) reject impossible values at entry.
- Provenance fields (source, collection time, transformation) let you trace a number back.
- Checksums detect accidental corruption.
- Hash chains link each record to the previous one, so editing any record changes every later hash. They detect modification if you have a trusted copy of a later hash (an anchor) stored somewhere the attacker cannot alter. They do not detect truncation of the tail unless the anchor includes the record count, and they do not prove the original data were true.
- Digital signatures or MACs on records or anchors bind them to a key holder.
13.4 Getting data out without letting attacks in
Enterprise teams want control data for reporting and analytics. The safe pattern is to push data outward — from the control zone to a DMZ historian replica — and let enterprise users query the replica, never the control historian. Where the consequence of control-zone compromise is severe, unidirectional gateways (data diodes) enforce outward-only flow physically. Lab 5's violation — an enterprise script polling an RTU directly — is the anti-pattern.
At LRWA the DMZ historian replica serves finance and asset teams, and the forgotten enterprise script found in the flow review is being retired in its favour.
13.5 Worked example: protecting the incident timeline (synthetic)
After an unexplained reservoir level drop on 4 March in the synthetic record, LRWA must preserve the historian extract for investigation. Lab 6 hash-chains six daily readings and stores the head hash in the incident ticket (the anchor). Editing the 4 March value is detected at index 3 and every later record. Deleting the last record is not detected by comparing heads alone if the attacker also replaces the stored head — which is why the anchor goes into a system outside the attacker's reach, together with the record count.
13.6 Practical activity: Lab 6
# Lab 6 - a hash-chained historian extract detects edits, not deletions at the tail (offline)
import hashlib, json
recs = [{"t": f"2026-03-0{d} 06:00", "tag": "HOLLIN_LVL", "v": v} for d, v in zip(range(1, 7), [78.1, 77.4, 79.0, 41.2, 76.5, 77.9])]
def chain(rs):
prev, out = "0" * 64, []
for r in rs:
h = hashlib.sha256((prev + json.dumps(r, sort_keys=True)).encode()).hexdigest()
out.append(h); prev = h
return out
anchor = chain(recs)
print("head:", anchor[-1][:16])
tampered = [dict(r) for r in recs]; tampered[3]["v"] = 74.0
bad = [i for i, (a, b) in enumerate(zip(anchor, chain(tampered))) if a != b]
print("first mismatch at index:", bad[0], "mismatches:", len(bad))
print("truncated head matches stored index 4:", chain(recs[:5])[-1] == anchor[4])
Expected output:
head: a8407870e41914c1
first mismatch at index: 3 mismatches: 3
truncated head matches stored index 4: True
The head hash is what LRWA stores in the incident ticket. Editing the 4 March reading to hide the drop changes the hash at index three and at every later record, so the edit is detected wherever it occurs. The last line shows the weakness: a chain built from the first five records matches the stored hash at index four, so an attacker who deletes the final record and replaces the stored head would go unnoticed. EX025 closes that gap by adding the record count to the anchor.
13.7 Common errors and limits
- Treating historian data as complete when compression or deadbands discard detail.
- Hash chains without an independently stored anchor.
- Believing integrity mechanisms prove truth; they prove non-modification since anchoring.
- Bidirectional "reporting" connections into the control zone.
- Losing time zone and clock-source information.
The 4 March investigation depends on avoiding every one of these, from compression gaps to a missing time zone. A historian that drops small changes may have discarded the very values that would show how fast the level fell, an anchor kept on the historian server could be rewritten by the same administrator, and timestamps without a zone make the drop impossible to align with the operator log.
Exercises — chapter 13
EX025 — Tail truncation. Objective: close the truncation gap. Inputs: Lab 6. Steps: (1) show that chain(recs[:5]) matches the stored hash at index 4; (2) modify the anchor to include the record count and show truncation is detected; (3) state where the anchor should be stored at LRWA and why. Expected evidence: code and output. Rubric: 3 = demonstration and fix correct, anchor stored outside control and historian admins' reach; 2 = fix incomplete; 1 = not run; 0 = none.
EX026 — Data flow design. Objective: design analytics access safely. Inputs: the finance team wants hourly pump energy data; the asset team wants live pressure data for a dashboard. Steps: draw (in text) the flows, zones and direction; state which component enforces direction and what happens if the DMZ replica is compromised. Expected evidence: flow description and consequence analysis. Rubric: 3 = push to DMZ, no inbound to control, consequence limited to data confidentiality/integrity of the replica; 2 = direction not enforced; 1 = direct query of control historian; 0 = none.
Chapter synthesis
Model operational data deliberately, know what your historian discards, and use transactions and replication with failover in mind. Every integrity mechanism detects something specific: constraints reject the impossible, hash chains detect edits relative to an independently stored anchor, signatures bind to a key holder — none proves truth. Move data outward to a DMZ and never let reporting become a path into control.
Continue studying — chapter 13 of 50
← Chapter 12 · Course chapter index · Chapter 14 →
Continue to the next authored lesson.