Chapter 6 — Critical infrastructure and sector security: system model

Chapter 6 — Critical infrastructure and sector security: system model

Lesson map

Lesson 06 published. Map, example, EX021.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["6.1 Zones and conduits"]
  N2["6.2 What to record for each element"]
  N3["6.3 Sector differences that matter at the keyboard"]
  N4["6.5 Practical activity"]
  N5["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX021"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["6.1 Zones and conduits"]
  N2["6.2 What to record for each element"]
  N3["6.3 Sector differences that matter at the keyboard"]
  N4["6.5 Practical activity"]
  N5["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX021"]

[Learning outcomes and connection]
    |
    v
[6.1 Zones and conduits]
    |
    v
[6.2 What to record for each element]
    |
    v
[6.3 Sector differences that matter at the keyboard]
    |
    v
[6.5 Practical activity]
    |
    v
[Chapter synthesis]
    |
    v
[Worked example] --> [Exercise EX021]

Learning outcomes and connection

After this chapter you should be able to:

• build a technical system model of a critical service: assets, zones, conduits, protocols, trust boundaries and the physical consequence each zone can cause;
• use the zone-and-conduit vocabulary of ISA/IEC 62443 at a technician's level;
• describe how water, healthcare and electricity services differ technically — protocols, timing, safety systems and who may change what;
• mark on the model where each later chapter's controls and detections will sit.

Chapters 1–5 were the general foundations. From here on the course applies them to critical sectors. The system model is the technician's map: without it, a firewall rule, a detection or a troubleshooting step has nothing to refer to.

6.1 Zones and conduits

The ISA/IEC 62443 series groups assets with similar security requirements into zones and the communication paths between them into conduits (ISA/IEC 62443 overview). The practical rules a technician applies:

• every asset belongs to exactly one zone;
• every permitted communication between zones is a declared conduit with a purpose, protocol, direction and owner;
• anything not declared is not permitted, and if observed is a finding (Lab 17 and Chapter 11 verify this);
• a zone's protection should match the worst physical consequence of the assets inside it.

The common shape of a supervisory system — field, control, supervisory, operations-DMZ, enterprise — appears in NIST SP 800-82 Rev. 3 as an example architecture (SP 800-82 Rev. 3). Use it as a vocabulary, not a template: a real site has historical exceptions, and the model's job is to show them.

6.2 What to record for each element

For each asset: name, address, function, zone, owner, software and firmware versions, protocols spoken, management method and the physical consequence of loss or misuse. For each conduit: source zone, destination zone, protocol and port, direction of initiation, purpose, owner, enforcement point (which firewall rule) and monitoring point (which sensor sees it). For each trust boundary: what crosses it and what checks happen there.

For eng-ws-15 record that it can program RTUs and that its loss or misuse has zone-wide consequence. For each conduit, name the firewall rule that should enforce it and the sensor that should see it, so a later verification knows where to look. Leave no asset without a zone and no permitted path without a conduit owner.

6.3 Sector differences that matter at the keyboard

• Water: widely dispersed stations on cellular or radio links; Modbus or DNP3 telemetry; long equipment lives; small operators with limited staff. Consequences include loss of pressure, overflow and incorrect chemical dosing. CISA's advisory on attacks against internet-exposed Unitronics PLCs in water systems is a reminder that exposure plus default credentials is enough (CISA AA23-335A).
• Electricity: substations with protection relays whose timing is measured in milliseconds; DNP3 or IEC 60870-5-104 telecontrol to a control centre; IEC 61850 inside modern substations; strict separation of protection from supervisory functions. A technician never changes protection settings; those belong to protection engineers.
• Healthcare: building-management systems (ventilation, pressure in isolation rooms, medical gases monitoring), clinical device networks and IT systems in one building, often sharing infrastructure; downtime affects patients directly and changes are bound by clinical engineering and device manufacturers' instructions.

In all three, safety instrumented systems and protection functions are designed to act independently of the supervisory system. The technician's model shows them as separate zones and never routes management traffic through them.

6.4 Worked example: the KVROC model (synthetic)

Declared conduits include: C1 Z2 scada-01 → Z1 tcp/502 read polls; C2 Z2 eng-ws-15 → Z1 tcp/502 writes during approved windows; C3 Z5 jump-01 → Z2 tcp/22; C4 Z2 hist-02 → Z6 report server, HTTPS push of daily CSV. Lab 2 already showed an undeclared path: Z6 desk → Z1 tcp/502. In the model it appears as a red line with a question: which rule allows it, and since when? Chapter 10 answers.

6.5 Practical activity

Extend the model with two conduits for Z3 (fep-01 to the outstation and the vendor's remote support path) and one for Z4. For each, record purpose, protocol, initiator, owner, enforcement point and monitoring point. Mark which conduits a single compromised Z5 host could abuse.

For the vendor remote-support path into Z3, record whether it terminates on the jump host or reaches the outstation directly. For Z4, mark that KVROC has read access only. Then list which of those conduits a compromised jump host in Z5 could open, and which controls would still apply.

6.6 Common errors and limits

• Zones drawn by IP subnet rather than by consequence and trust.
• Conduits without owners or purposes, which nobody can later remove.
• Omitting the management zone because it is "IT".
• Modelling the safety system as a normal controller.
• A model that is never compared with observed traffic; Chapter 11 does that.

• Copying a zone model from another site without checking which of its conduits actually exist at this one.

• Drawing zones by subnet alone when two hosts in the same subnet have different consequences.

• Putting a safety or protection function in the same zone as ordinary supervisory controllers.

Exercises — chapter 6

EX021 — Place the assets. Objective: assign zones by consequence. Inputs: a cellular router at KW-06; the vendor's remote-support gateway for SS-3; the report server; a laptop used by Kestrel Water engineers at stations. Steps: assign each to a zone (existing or new) and justify. Expected evidence: four placements. Rubric: 3 = router in Z1 boundary with its management treated as Z5-level privilege; vendor gateway in its own remote-access zone, not Z3; report server Z6; engineering laptop as a transient asset with its own controls (Chapter 16); 2 = one weak; 1 = by subnet only; 0 = none.

EX022 — Write a conduit. Objective: declare a path completely. Inputs: hist-02 must send a daily CSV to the corporate report server. Steps: write the conduit entry with all fields. Expected evidence: one completed entry. Rubric: 3 = initiated from Z2 outward (push, not pull from corporate), HTTPS to one named host and port, purpose, owner, enforcement rule and monitoring point named, review date; 2 = one missing; 1 = "allow hist to corporate"; 0 = none.

EX023 — Sector contrast. Objective: recognize technical differences. Inputs: a proposal to apply the same weekly patch-and-reboot schedule to scada-01, the SS-3 front end and the hospital BMS server. Steps: explain for each sector what must be checked first. Expected evidence: three short paragraphs. Rubric: 3 = water: redundancy and poll interruption; grid: telecontrol windows agreed with the grid control room, no effect on protection; hospital: clinical engineering and manufacturer constraints, ventilation alarms continuity; 2 = generic; 1 = accepts one schedule; 0 = none.

EX024 — Model versus capture. Objective: compare declared and observed. Inputs: Lab 2 output and the conduit list in 6.4. Steps: list every observed flow not explained by a declared conduit. Expected evidence: list with reasons. Rubric: 3 = the corporate-desk writes (no conduit), possibly the device-ID query if no conduit covers it, malformed frames from scada-01 as an anomaly to explain; 2 = writes only; 1 = none found; 0 = none.

Chapter synthesis

The system model joins assets, zones, conduits and consequences into one map. It says what should happen, so that anything else is visible as a finding. Sectors differ in protocols, timing and who may change what, and safety and protection functions stay separate from everything a technician touches.

Continue studying — chapter 06 of 18

← Chapter 05 · Course chapter index · Chapter 07 →

Continue to the next authored lesson.