This series explains how physical networks evolve into logical architectures and eventually become Zone and Conduit Diagrams (ZCD) required by IACS UR E26/E27.
Introduction
Once the physical network has been established, engineers naturally begin asking:
"Which IP addresses should we use?"
"How many subnets are required?"
Although these questions are important, they are not the first questions we should ask. The more fundamental question is:
What are we trying to protect?
And the answer to that question leads us to Zones.
In cyber architecture, Zones come before VLANs.
Why Network Segmentation Exists
Historically, many shipboard systems were connected primarily for operational efficiency — information sharing improved, maintenance became easier, and remote access reduced operational costs.
However, increased connectivity also created new risks.
⚠ Propagation Risk
A compromise in one system could propagate into another.
⚠ Lateral Movement
An infected engineering workstation might affect the IAS.
⚠ Entry Point Risk
A maintenance laptop could become an entry point into a navigation system.
✓ The Challenge
No longer protecting individual equipment — controlling trust between systems.
This is where segmentation becomes essential.
Physical Separation vs. Logical Separation
Cyber architecture must define trust boundaries even when systems share physical infrastructure.
Understanding the Concept of a Zone
IEC 62443 — Definition
"A grouping of assets sharing common security requirements."
Notice what the definition does not say:
Instead, a Zone groups assets that require similar levels of protection.
Zones are based on
Trust
Not topology.
Understanding Conduits
Zone
Represents trust boundaries
Conduit
Represents controlled communication paths
Conduits answer the key questions governing communication between Zones:
A conduit is much more than a cable. It represents the security controls that govern communication between Zones.
Typical Conduit Controls
Zones define trust.
Conduits control trust.
The Purdue Model Provides Structure
Most maritime cyber architectures can be aligned with the Purdue Reference Model to establish trust boundary layers.
Although IACS UR E26 does not mandate the Purdue model, it provides a practical framework for establishing trust boundaries in maritime environments.
Designing Zones
⚠️ One of the biggest mistakes in E26 projects is defining Zones according to equipment names alone — Navigation Zone, Machinery Zone, Cargo Zone. This approach is only partially correct.
A proper Zone design must consider five dimensions:
Criticality
How important is the system to vessel safety and operation?
Connectivity
What other systems communicate with it?
Consequences of Compromise
What happens if the system becomes unavailable or corrupted?
Trust Level
Can the system trust external connections?
Operational Requirements
Does the system require continuous availability?
The Nine Baseline Zones
A practical ship architecture typically includes the following zones. These may vary depending on vessel type, but they provide a useful starting point.
Zone 1
External Access Zone
Internet · VSAT · LTE
Zone 2
Ship Business Zone
Office Network
Zone 3
Crew Welfare Zone
WiFi · Entertainment
Zone 4
DMZ
Jump Server · Patch Server
Zone 5
Security Monitoring Zone
SIEM · IDS · Syslog
Zone 6
Navigation Zone
ECDIS · Radar · VDR
Zone 7
Communication Zone
GMDSS · Satellite Comms
Zone 8
Machinery Control Zone
IAS · AMS · PMS
Zone 9
Cargo / Mission Zone
Cargo Control · DP Systems
Why VLANs Come Later
After Zones are defined, VLANs can be assigned. For example:
VLANs are implementation mechanisms. They are not cyber architecture.
Two systems belonging to different trust levels should never be placed in the same Zone simply because they share a VLAN.
Likewise, one Zone may span multiple VLANs.
✗ VLANs do not create Zones.
✓ Zones create VLANs.
Asset Inventory Comes First
Before defining Zones, engineers must understand the assets they are protecting. This is why Asset Inventory and Dependency Mapping are foundational activities in IACS UR E26.
Four Questions to Answer Before Defining Zones
Without understanding assets and dependencies, meaningful Zone definitions become impossible.
Logical Networks Are About Trust
Physical Networks
Describe connectivity
Logical Networks
Describe trust
The purpose of Zone and Conduit architecture is not to simplify drawings. Its purpose is to contain cyber incidents. If one Zone is compromised, the impact should be limited.
Segmentation is not about efficiency.
Segmentation is about survivability.
Before Drawing the ZCD
By the end of this stage, we should have the following in place. These are the ingredients — not yet the ZCD itself.
None of these are yet a Zone and Conduit Diagram. They are simply the ingredients. The next step is translating these concepts into documentation — and that is where many projects struggle.
From Networks to ZCD
In Part 3, we explore how physical networks and logical architectures are transformed into actual IACS UR E26 deliverables — including Zone and Conduit Diagrams, Zone Tables, Conduit Tables, Data Flow Matrices, Security Level Definitions, and Cyber Security Design Descriptions (CSDD).
📌 Field Note — Captain Paul
The Zone-before-VLAN principle is counterintuitive for network engineers because VLAN configuration is the technical action they're familiar with. But the IACS UR E26 framework requires the Zone definition to precede the VLAN configuration — because Zones are defined by security policy (assets sharing the same security requirements), while VLANs are an implementation mechanism for enforcing that policy. Designing VLANs before defining Zones produces network segments that may or may not align with the security policy the ship requires.
The Purdue model's value in this context is not as a mandatory architecture template but as a reference framework for trust boundary layering. Most maritime OT architectures can be described using Purdue Level categories, which gives Class auditors a shared vocabulary for evaluating zone design rationale. Projects that use an alternative layering model should be prepared to explain the trust boundary logic in terms Class can evaluate — the Purdue model is not required, but some systematic boundary framework is.
A common misconception in practice:
"Configure VLANs correctly and Zone definition is complete." A VLAN is a network configuration; a Zone is a security policy grouping. A single Zone can span multiple VLANs; a single VLAN can contain assets from multiple Zones. The Zone definition must precede VLAN configuration — and the two must be explicitly mapped in the ZCD documentation.
Key practical takeaways:
- Map all assets and their operational dependencies before defining any Zone — Zone boundaries should follow functional groupings and security requirement similarity, not network topology.
- For each Zone, document the IEC 62443 basis: which assets are grouped, what common security requirement justifies the grouping, and what security level is assigned. This is what Class verifies against the zone definition.
- For each Conduit, document the controls applied: firewall rule set, ACL, authentication requirement, allowed direction of traffic flow, and monitoring/logging coverage. An undocumented Conduit is an uncontrolled inter-zone connection.
⚓ Join the ShipPaulJobs Community
Join →
Comments
Post a Comment