Chapter 8 — Segmentation for building networks
Lesson map
Lesson 08 published. Map, example, EX036.
flowchart TD
N0["Learning outcomes"]
N1["8.1 Zones"]
N2["8.2 Conduits and rules"]
N3["8.3 Fixing the dual-homed workstation"]
N4["8.4 Migrating safely"]
N5["8.5 Documentation"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX036"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["8.1 Zones"]
N2["8.2 Conduits and rules"]
N3["8.3 Fixing the dual-homed workstation"]
N4["8.4 Migrating safely"]
N5["8.5 Documentation"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX036"]
[Learning outcomes]
|
v
[8.1 Zones]
|
v
[8.2 Conduits and rules]
|
v
[8.3 Fixing the dual-homed workstation]
|
v
[8.4 Migrating safely]
|
v
[8.5 Documentation]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX036]
Learning outcomes
You will (1) define zones and conduits for Millbrook's building systems using IEC 62443 terms; (2) write a minimal rule set; and (3) plan the migration without disrupting clinical areas.
8.1 Zones
IEC 62443-3-2 describes grouping assets into zones with similar security requirements and connecting them through conduits. At Millbrook a sensible start is: a BMS zone (controllers and BMS server), a safety-relevant zone (medical gas alarm and lift, each separately), an access control zone, a DMZ for the gateway and data exports, and the corporate zone.
Write each zone with its members, owner and the consequence if it is compromised. Medical gas alarms and lifts are kept in separate zones because their failures matter for patient safety and their contractors differ. A zone diagram that estates and the network team both accept is the starting point for any rule table.
8.2 Conduits and rules
Write each conduit as a small set of rules: BMS-WS (moved into the BMS zone) to controllers on BACnet/IP; gateway to BMS-WS for contractor sessions; BMS server to a DMZ data server for energy reports. Everything else is denied. Corporate PCs never connect straight to controllers.
Write each rule with its source, destination, protocol and port, a reason and an owner, so it can be reviewed later. Check the rules against the route inventory, so that nothing approved is blocked and nothing unapproved remains. A rule without an owner should be treated as a candidate for removal.
8.3 Fixing the dual-homed workstation
Removing BMS-WS's corporate network card closes the bridge from Chapter 3. Estates staff who need to view the BMS from offices use a read-only dashboard on the DMZ server, or a jump host reached through the gateway.
Before removing the card, agree with estates which office tasks used it and test the replacement route with the staff who will use it. Do the change in a booked slot and confirm afterwards that BMS-WS still reaches its controllers. Record the change against the risk list entry that Aisha made when she found the bridge.
8.4 Migrating safely
Change one conduit at a time, at times agreed with estates and theatre managers; watch for lost points on the BMS after each step; keep the previous configuration ready to restore.
Agree beforehand which BMS points will be checked after each step and who will check them. At Millbrook, after the second step two controllers stopped reporting because a conduit to a time server had been forgotten; it was found because points were checked straight away. Note such surprises in the rule table so the next change avoids them.
8.5 Documentation
Publish the zone diagram and rule table with revision numbers and owners so contractors can request changes against them.
Keep the diagram and table in a place estates, the network team and contractors can all read, and refer to them in every change request. When a change is made, update the revision number and note who approved it. Out-of-date documentation leads contractors to request rules that already exist or that contradict the design. Keep superseded revisions so that past decisions can be traced.
Worked example (synthetic Millbrook)
Over three planned Saturday mornings the network team creates the zones, moves BMS-WS fully into the BMS zone and deploys the rules. After step 2 two controllers stop reporting; the cause is a forgotten conduit to a time server, which is added under the same change. Energy reports now come from the DMZ server.
Synthetic case — Millbrook. Steps and findings are invented.
Errors and limits
Segmentation does not stop an attacker who already has gateway credentials; it limits where they can go. Zone designs must be reviewed when systems are added.
Exercises
- EX036 — Zone list. Propose five zones for Millbrook. Rubric: 3 = BMS, safety-relevant (gas/lift), access control, DMZ, corporate; 2 = four; 1 = two; 0 = none.
- EX037 — Writing a conduit. Write the rule letting the BMS server send energy data to the DMZ server. Rubric: 3 = source BMS server, destination DMZ data server, specific port, allow; plus default deny; 2 = no deny; 1 = any; 0 = none.
- EX038 — Office viewing. How do estates staff view the BMS from their offices after BMS-WS loses its corporate card? Rubric: 3 = read-only DMZ dashboard or jump host via gateway; 2 = partial; 1 = re-add card; 0 = none.
- EX039 — Lost points. Two controllers stop reporting after a rule change. What is the safe response? Rubric: 3 = check clinical impact, restore previous config if needed, find missing conduit, fix under change; 2 = partial; 1 = ignore; 0 = none.
- EX040 — Limit of segmentation. What does segmentation not protect against? Rubric: 3 = misuse of legitimate gateway credentials/insider within allowed conduits; 2 = vague; 1 = everything protected; 0 = none.
Synthesis
Zones with narrow conduits stop office compromises from reaching controllers; migrate one conduit at a time.
Continue studying — chapter 08 of 12
← Chapter 07 (draft) · Course chapter index · Chapter 09 (draft) →