Chapter 11 — Networks and protocols
Lesson map
Lesson 11 published. Map, example, EX022.
flowchart TD
N0["Learning outcomes and connection"]
N1["11.1 Layers and what they promise"]
N2["11.2 Industrial protocols"]
N3["11.3 Latency, jitter and polling"]
N4["11.4 Zones, conduits and allowlists"]
N5["11.6 Practical activity: Lab 5"]
N6["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX022"]
Logical drawing
flowchart LR
N0["Learning outcomes and connection"]
N1["11.1 Layers and what they promise"]
N2["11.2 Industrial protocols"]
N3["11.3 Latency, jitter and polling"]
N4["11.4 Zones, conduits and allowlists"]
N5["11.6 Practical activity: Lab 5"]
N6["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX022"]
[Learning outcomes and connection]
|
v
[11.1 Layers and what they promise]
|
v
[11.2 Industrial protocols]
|
v
[11.3 Latency, jitter and polling]
|
v
[11.4 Zones, conduits and allowlists]
|
v
[11.6 Practical activity: Lab 5]
|
v
[Chapter synthesis]
|
v
[Worked example] --> [Exercise EX022]
Learning outcomes and connection
After this chapter you can (1) explain the layered model and the roles of Ethernet, IP, TCP, UDP and application protocols; (2) describe industrial protocols (Modbus/TCP, DNP3, IEC 60870-5-104, OPC UA) and which security properties each does or does not provide; (3) build a latency budget for telemetry; and (4) express segmentation as zones and conduits and check observed flows against it. It builds on Chapters 3 and 4 and prepares Chapters 18 (security architecture) and 26 (architecture alternatives).
11.1 Layers and what they promise
Networks are built in layers: physical and link (Ethernet frames on a segment), network (IP packets routed between segments), transport (TCP reliable ordered byte streams; UDP datagrams without delivery guarantees — TCP is specified in RFC 9293), and application (the protocol that carries meaning). Each layer promises something limited. TCP guarantees order and retransmission, not authenticity. IP routes, but source addresses can be forged on many networks. Security properties must be added deliberately, usually with TLS (RFC 8446), IPsec, or application-layer authentication.
11.2 Industrial protocols
Classic industrial protocols were designed for closed serial networks. Modbus/TCP (port 502) carries function codes such as read and write registers with no authentication; anyone who can reach port 502 can issue writes. DNP3 is widely used in water and electricity; its Secure Authentication extension adds challenge–response authentication of critical commands but is not universally deployed. IEC 60870-5-104 is common in European power systems, with security extensions defined in IEC 62351. OPC UA was designed with security modes offering signing and encryption, but they must be configured — "None" is a valid policy. The lesson is consistent: protocol capability is not deployment. Check what is configured.
11.3 Latency, jitter and polling
Telemetry is usually polled: the SCADA master asks each RTU in turn. End-to-end latency from a physical event to an operator's screen is the sum of sensor update, RTU scan, link round-trip, master polling wait, processing and display refresh. Jitter is variation in latency. Write a budget, measure each element, and compare the total with the requirement; Chapter 36 adds queueing.
LRWA's budget in Lab 5 adds RTU scan, LTE round trip, polling wait and screen refresh to reach one second against a 1.5-second requirement, but the polling wait is the element that varies most, and EX022 shows how it dominates the worst case.
11.4 Zones, conduits and allowlists
Segmentation divides a network into zones with similar security requirements and controls the conduits between them. This vocabulary comes from the ISA/IEC 62443 series. A conduit policy is an allowlist: specific source zone, destination zone, protocol and port, everything else denied. Verification is not reading the firewall configuration; it is checking observed flows against intended policy, because configurations drift and undocumented paths (a vendor's remote-access modem, a dual-homed laptop) bypass firewalls.
LRWA's flow review below shows why.
11.5 Worked example: LRWA flow review (synthetic)
LRWA defines zones: enterprise, dmz, control (SCADA servers), field (RTUs) and eng (engineering workstations). The intended conduits are listed in Lab 5. A week of flow records shows three violations: an enterprise host speaking Modbus directly to a field RTU (a forgotten reporting script that bypasses the DMZ), an engineering workstation opening SSH directly to an RTU rather than through the control zone jump host, and a SCADA server making DNS queries to a public resolver. Each is a finding with an owner: remove the script and serve its data from the DMZ historian; route engineering access through the jump host; point SCADA DNS at an internal resolver or none.
11.6 Practical activity: Lab 5
# Lab 5 - check observed flows against a zone-conduit allowlist (synthetic, offline)
RULES = [ # (src_zone, dst_zone, protocol, port)
("control", "field", "tcp", 502), ("control", "dmz", "tcp", 443), ("dmz", "enterprise", "tcp", 443),
("eng", "control", "tcp", 22), ("field", "control", "udp", 20000)]
ZONE = {"10.1.0.": "control", "10.2.0.": "field", "10.3.0.": "dmz", "10.4.0.": "enterprise", "10.5.0.": "eng"}
def zone(ip): return next((z for p, z in ZONE.items() if ip.startswith(p)), "unknown")
FLOWS = [("10.1.0.5", "10.2.0.31", "tcp", 502), ("10.4.0.77", "10.2.0.31", "tcp", 502),
("10.2.0.31", "10.1.0.5", "udp", 20000), ("10.3.0.9", "10.4.0.20", "tcp", 443),
("10.5.0.12", "10.2.0.33", "tcp", 22), ("10.1.0.5", "8.8.8.8", "udp", 53),
("10.1.0.6", "10.3.0.9", "tcp", 443)]
for s, d, p, port in FLOWS:
ok = (zone(s), zone(d), p, port) in RULES
print(f"{s:>10} {zone(s):>10} -> {d:<10} {zone(d):<10} {p}/{port:<5} {'allowed' if ok else 'VIOLATION'}")
budget = {"rtu_scan": 120, "lte_rtt": 180, "scada_poll_wait": 500, "operator_view": 200}
print("end-to-end latency budget ms:", sum(budget.values()), "vs requirement 1500")
Expected output:
10.1.0.5 control -> 10.2.0.31 field tcp/502 allowed
10.4.0.77 enterprise -> 10.2.0.31 field tcp/502 VIOLATION
10.2.0.31 field -> 10.1.0.5 control udp/20000 allowed
10.3.0.9 dmz -> 10.4.0.20 enterprise tcp/443 allowed
10.5.0.12 eng -> 10.2.0.33 field tcp/22 VIOLATION
10.1.0.5 control -> 8.8.8.8 unknown udp/53 VIOLATION
10.1.0.6 control -> 10.3.0.9 dmz tcp/443 allowed
end-to-end latency budget ms: 1000 vs requirement 1500
Three of the seven flows are violations, and each matches a finding in the worked example: the enterprise reporting script speaking Modbus to a field RTU, the engineering workstation opening SSH directly to an RTU instead of through the jump host, and a SCADA server querying a public DNS resolver. The latency budget line shows a total of one second against the 1.5-second requirement, but that figure uses typical values, so treat it as a starting point for the worst-case analysis in EX022 rather than evidence that R7 is met.
11.7 Common errors and limits
- Equating encryption at one layer with end-to-end protection.
- Assuming an industrial protocol's optional security is enabled.
- Verifying segmentation by reading configurations only.
- Latency budgets with averages instead of worst cases.
- Allowlists by host instead of by function, which become unmaintainable.
LRWA's flow review illustrates the third error directly: the firewall configuration looked correct, yet a week of flow records showed three violations. Reading configurations would have found none of them. Allowlists written by host would also have needed constant edits as RTUs were added.
Exercises — chapter 11
EX021 — Extend the policy check. Objective: find violations by function. Inputs: Lab 5. Steps: (1) add a flow from 10.2.0.31 to 10.4.0.77 on TCP/445; (2) add a rule so the engineering workstation can reach RTUs only via a jump host in the control zone, and model the two hops; (3) rerun and report. Expected evidence: code changes and output. Rubric: 3 = new violation detected, two-hop model correct, no rule weakens field protection; 2 = one issue; 1 = not run; 0 = none.
EX022 — Latency against requirement. Objective: budget worst-case latency. Inputs: RTU scan 120 ms, LTE round-trip 180 ms typical / 900 ms 99th percentile, polling wait up to one full cycle of 1.3 s (Lab 13), operator view refresh 200 ms; requirement: 95% of alarms on screen within 1.5 s and all within 5 s. Steps: compute typical and worst-case totals; judge both clauses; propose one design change. Expected evidence: table. Rubric: 3 = correct sums, polling wait recognised as dominant, change proposed (report-by-exception or unsolicited alarms); 2 = one sum wrong; 1 = typical only; 0 = none.
Chapter synthesis
Each network layer promises something narrow; authenticity has to be added. Industrial protocols vary in security capability, and capability is not configuration. Budget latency with worst cases. Express segmentation as zones and conduits with allowlists, and verify it against observed flows rather than intended configurations.
Continue studying — chapter 11 of 50
← Chapter 10 · Course chapter index · Chapter 12 →
Continue to the next authored lesson.