Chapter 7 — Networks and protocols
Lesson map
Lesson 07 published. Map, example, EX013.
flowchart TD
N0["Learning outcomes and connection"]
N1["7.1 Layers, addresses and ports"]
N2["7.2 Industrial protocols and their assumptions"]
N3["7.3 Zones, conduits and allowlists"]
N4["7.5 Practical activity"]
N5["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX013"]
Logical drawing
flowchart LR
N0["Learning outcomes and connection"]
N1["7.1 Layers, addresses and ports"]
N2["7.2 Industrial protocols and their assumptions"]
N3["7.3 Zones, conduits and allowlists"]
N4["7.5 Practical activity"]
N5["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX013"]
[Learning outcomes and connection]
|
v
[7.1 Layers, addresses and ports]
|
v
[7.2 Industrial protocols and their assumptions]
|
v
[7.3 Zones, conduits and allowlists]
|
v
[7.5 Practical activity]
|
v
[Chapter synthesis]
|
v
[Worked example] --> [Exercise EX013]
Learning outcomes and connection
After this chapter you can (1) explain layering, addressing, ports and the difference between a connection's client and server; (2) describe how industrial protocols such as Modbus differ from modern internet protocols in their security assumptions; (3) express a network-segmentation policy as zones, conduits and an allowlist; and (4) check observed flows against that policy and interpret the violations. It builds on Chapters 3 and 6 and prepares Chapter 16 (architecture) and Chapter 24 (controls).
7.1 Layers, addresses and ports
Networks are built in layers. The link layer moves frames between neighbouring devices (Ethernet, Wi-Fi). The internet layer moves packets between networks using IP addresses. The transport layer provides either a reliable byte stream (TCP; see RFC 9293) or individual datagrams (UDP), and uses port numbers to identify the service on a host. The application layer carries the meaning: HTTPS for web, Modbus/TCP on port 502 for industrial polling, OPC UA commonly on port 4840. In a TCP connection the client opens the connection to the server's listening port; the reply uses the same connection. Who initiates is security-relevant: a field controller that suddenly opens connections to the control room is behaving differently from one that only answers.
7.2 Industrial protocols and their assumptions
Many industrial protocols were designed for closed serial links in the 1970s–1990s. Modbus, for example, defines function codes to read and write registers and coils, and its classic form has no authentication: any device that can send a well-formed request to a controller can ask it to write (Modbus specification). This is not a bug in an implementation; it is the design assumption that only trusted devices can reach the wire. Once such protocols run over IP networks, that assumption must be enforced by the network: segmentation, allowlists and monitoring. Modern protocols add security (TLS 1.3 provides authenticated, encrypted channels — RFC 8446), but upgrading thousands of field devices takes decades.
7.3 Zones, conduits and allowlists
A zone is a group of assets with similar security requirements; a conduit is the controlled communication path between zones. The ISA/IEC 62443 series uses these terms for industrial systems (ISA/IEC 62443 overview). A typical utility has a corporate zone, a demilitarised zone (DMZ) where data is exchanged, a control zone (SCADA servers, operator HMIs) and a field zone (controllers, RTUs). An allowlist policy names the flows that are allowed — source zone, destination zone, port, purpose — and denies everything else. The policy is only half the control; the other half is checking that observed traffic matches it.
7.4 Worked example and Lab 4: checking CW's flows (synthetic)
This case is synthetic. Calder Water allows three conduits: corporate users view the historian in the DMZ over HTTPS; a collector in the DMZ reads from the control zone over OPC UA; the SCADA server polls field controllers over Modbus/TCP. A one-hour flow summary is checked against the policy.
# Lab 4 - check observed flows against a zone-and-conduit allowlist (synthetic, offline)
ALLOW = { # (source zone, destination zone, destination port): purpose
("corporate", "dmz", 443): "historian web view",
("dmz", "control", 4840): "OPC UA read from historian replica collector",
("control", "field", 502): "Modbus/TCP polling of field controllers",
}
ZONE = {"10.1.": "corporate", "10.5.": "dmz", "10.20.": "control", "10.30.": "field"}
def zone(ip):
return next((z for p, z in ZONE.items() if ip.startswith(p)), "unknown")
FLOWS = [ # src, dst, dport (synthetic NetFlow-style summary)
("10.1.4.22", "10.5.0.10", 443), ("10.5.0.11", "10.20.0.5", 4840),
("10.20.0.5", "10.30.1.7", 502), ("10.1.4.80", "10.20.0.5", 3389),
("10.20.0.9", "198.51.100.23", 443), ("10.30.1.7", "10.20.0.5", 502),
]
for s, d, p in FLOWS:
key = (zone(s), zone(d), p)
verdict = ALLOW.get(key)
print(f"{s:>13} -> {d:<14} :{p:<5} {key[0]:>9}->{key[1]:<8} {'ALLOW ' + verdict if verdict else 'VIOLATION'}")
Expected output:
10.1.4.22 -> 10.5.0.10 :443 corporate->dmz ALLOW historian web view
10.5.0.11 -> 10.20.0.5 :4840 dmz->control ALLOW OPC UA read from historian replica collector
10.20.0.5 -> 10.30.1.7 :502 control->field ALLOW Modbus/TCP polling of field controllers
10.1.4.80 -> 10.20.0.5 :3389 corporate->control VIOLATION
10.20.0.9 -> 198.51.100.23 :443 control->unknown VIOLATION
10.30.1.7 -> 10.20.0.5 :502 field->control VIOLATION
Three violations, three different meanings. A remote-desktop connection (port 3389) from corporate straight into the control zone bypasses the DMZ — perhaps an engineer's shortcut, perhaps an intruder. A control-zone host reaching an internet address (198.51.100.23 is a documentation address standing in for a real one) may be a vendor's update check or data leaving. A field device initiating Modbus to the SCADA server reverses the normal direction. None proves an attack; each needs an owner to explain it, and the explanation becomes evidence (Chapter 15).
7.5 Practical activity
On a computer you own, list your own active connections (for example with netstat or ss) and classify five as client or server, local or remote, and expected or unexpected. Do not scan any other system.
Use the state column of ss or netstat: a local address with a listening port is a server; a connection to a remote port 443 is a client. Mark anything you cannot explain and find the program behind it with your operating system's tools on your own machine.
7.6 Common errors and limits
- Writing allowlists by port alone, ignoring source and destination zones.
- Assuming "internal" means "trusted".
- Confusing reply traffic with initiated connections when reading flow logs.
- Treating a violation as proof of compromise rather than as a question.
Lab 4 shows why: a port-only rule allowing 502 would have passed the field device that initiated Modbus to the SCADA server, a reversal of the normal direction. The corporate RDP connection into control is "internal" and still a violation. In flow logs, the field controllers' replies from port 502 to the SCADA server are not new connections and must not be read as such. And each of the three violations goes to an owner as a question first.
Exercises — chapter 7
EX013 — Explain the violations. Objective: reason from flows to hypotheses. Inputs: Lab 4 output. Steps: for each violation give one benign and one malicious explanation, and the evidence that would distinguish them. Expected evidence: a three-row table. Rubric: 3 = plausible pairs and specific distinguishing evidence (change tickets, user logins, destination ownership, device configuration); 2 = generic evidence; 1 = explanations only; 0 = none.
EX014 — Least flow. Objective: tighten a policy. Inputs: the ALLOW table. Steps: propose two refinements that make the policy narrower without breaking its purposes (for example, host-level rather than zone-level rules, read-only function codes) and say how each would be enforced and checked. Expected evidence: two refinements with enforcement and check. Rubric: 3 = both narrower, enforceable and checkable; 2 = one; 1 = vague; 0 = none.
Chapter synthesis
Networks carry the assumptions of their protocols. Classic industrial protocols trust whoever can reach them, so critical services enforce trust with zones, conduits and allowlists — and then check observed flows against the policy. A violation is a question to an owner, not a verdict.
Continue studying — chapter 07 of 40
← Chapter 06 · Course chapter index · Chapter 08 →
Continue to the next authored lesson.