From Networks to ZCD — Translating Physical and Logical Networks into IACS UR E26 Documentation

🛡 IACS UR E26/E27 Ship OT Cybersecurity Series Part 3 of 5 ZCD · CSDD · Documentation

From Networks to ZCD

Translating Physical and Logical Networks into IACS UR E26 Documentation

Ship OT Cybersecurity Series · Part 3

Captain Paul
Captain Paul
Maritime 4.0 · AI, Data & Cyber Security · linkedin.com/in/shipjobs
📌 Series Overview

This series explores how physical networks evolve into logical architectures and ultimately become the deliverables required by IACS UR E26/E27. Part 3 is the series core — it connects the full journey: Physical Network → Logical Network → ZCD → CSDD → Verification.

📖 Key Terms — Terminology Used in This Article
ZCD (Zone and Conduit Diagram) — A graphical representation of the ship's cyber architecture required by IACS UR E26. Not a network wiring diagram — it shows trust relationships between Zones and controlled communication paths.
CSDD (Cyber Security Design Description) — The core documentation package required by IACS UR E26. Includes Asset Inventory, Zone/Conduit definitions, Data Flow Matrix, Security Levels, ZCD, and verification activities. The ZCD is one component of the CSDD.
Data Flow Matrix — A table that maps which device communicates with which device, using what protocol, over which port, and in which direction. Forms the basis for firewall rule design and Conduit definitions.
FAT / SAT (Factory Acceptance Test / Site Acceptance Test) — FAT is performed at the factory before shipment; SAT is performed onboard after installation. Both verify that security controls function correctly, based on the completed ZCD.
Firewall Rule — Rules defining which traffic a firewall permits or denies. Without a Data Flow Matrix, firewall rules tend to default to "Allow Any Any" — a configuration that defeats the purpose of segmentation.
IEC 61162 / Modbus TCP — Commonly used maritime communication protocols. IEC 61162 handles data exchange between navigation equipment (ECDIS, Radar, etc.); Modbus TCP is used for communication between machinery control systems (IAS, AMS, etc.).

Introduction

By now, we have:

Designed the physical network.
Identified assets and dependencies.
Defined Zones and Conduits.
Established trust boundaries.

However, none of these activities by themselves satisfy IACS UR E26.

Eventually, cyber architecture must be translated into documentation. And this is where many projects struggle.

Because a Zone and Conduit Diagram (ZCD) is often misunderstood. Many people think a ZCD is merely a network diagram. It is not.

A ZCD is the graphical representation of cyber architecture.

A Physical Network Diagram Is Not a ZCD

A typical physical network diagram describes connectivity — switches, routers, firewalls, cables, IP addresses. For example:

Typical Physical Network Diagram

Internet
VSAT Router
Firewall
Core Switch
Access Switch
End Devices

This diagram explains connectivity.

But it tells us nothing about:

✗ Trust boundaries
✗ Security levels
✗ Communication control
✗ Cyber risk containment

Therefore, it is not a ZCD.

A ZCD Describes Trust Relationships

Instead of focusing on devices, a ZCD focuses on Zones. For example:

Zone & Conduit Architecture

External Access Zone
Conduit C-01
DMZ
Conduit C-02
Navigation Zone
Conduit C-03
Machinery Control Zone

Each conduit represents controlled communication.

The purpose of a ZCD is not to show where cables are connected.
Its purpose is to explain how cyber incidents are prevented from propagating across the ship.

The Building Blocks of a ZCD

A proper ZCD consists of four major components.

01 Zones

Groups of assets with similar security requirements.

Navigation Zone Communication Zone Machinery Control Zone Cargo Zone Ship Business Zone DMZ
Zones represent trust boundaries.
02 Conduits

Controlled communication paths between Zones.

C-01 External Access Zone ↔ DMZ
C-02 DMZ ↔ Navigation Zone
C-03 Navigation Zone ↔ Machinery Control Zone
Conduits represent controlled trust.
03 Security Controls

Each conduit must include enforceable security controls.

🛡 Firewalls 📋 ACLs 🔑 Authentication 🔐 VPN 👁 IDS Monitoring 📝 Logging
Security controls enforce trust boundaries.
04 Security Levels

Security Level Targets (SL-T) derived from risk assessments.

Navigation Zone

SL-T 3

Machinery Control Zone

SL-T 3

Crew Welfare Zone

SL-T 1

External Access Zone

SL-T 2

These values are derived from risk assessments.

Supporting Tables Behind the ZCD

The diagram itself is only the visible part. Underneath it are several supporting artifacts that give the ZCD its substance and defensibility.

Table A Zone Table

Defines: Zone ID, Zone Name, Purdue Level, Description, Assets, SL-T.

Zone ID Zone Name Purdue Level
Z-01 Navigation Zone Level 3
Z-02 Machinery Zone Level 2
Z-03 DMZ Level 3.5
Table B Conduit Table

Defines: Source Zone, Destination Zone, Security Controls, Communication Direction.

Conduit Source Destination
C-01 External DMZ
C-02 DMZ Navigation
C-03 Navigation Machinery
Table C Data Flow Matrix Most Important

Defines: Source Asset, Destination Asset, Protocol, Port, Direction, Purpose.

Source Destination Protocol
ECDIS Radar IEC 61162
AMS IAS Modbus TCP
Jump Server Engineering WS RDP
Without a Data Flow Matrix, firewall rules become assumptions.

Firewall Rules Come From Data Flows

Many projects attempt to create firewall rules directly. This often results in:

Allow Any Any

Which defeats the purpose of segmentation entirely.

The correct sequence is:

Asset Inventory
Dependency Mapping
Data Flow Matrix
Conduit Definition
Firewall Rules
Verification

Good firewall rules are consequences of architecture — not the starting point.

The Relationship Between ZCD and CSDD

The ZCD is not an independent document. It becomes one of the core elements of the Cyber Security Design Description (CSDD).

📄 A CSDD Typically Contains

📋 System Overview
🗄 Asset Inventory
🏗 Purdue Levels
🔒 Zone Definitions
🔀 Conduit Definitions
📊 Data Flow Matrix
📈 Security Levels
🛡 Security Controls
🗺 Zone and Conduit Diagram
Verification Activities

The ZCD therefore represents only one view of the overall cyber architecture.

A Good ZCD Represents Reality

Two common mistakes in practice:

Attempting to make the ZCD identical to the switch diagram.
Trying to represent every cable and every IP address.

These details belong elsewhere — in the physical network diagram.

A good ZCD should answer five questions clearly:

? What are the trust boundaries?
? How do systems communicate?
? Which communications are allowed?
? Which controls protect them?
? How are cyber incidents contained?

If the answer to these questions is clear,

then the ZCD is doing its job.

From Architecture to Verification

The ZCD does not mark the end of the journey. In fact, it becomes the starting point for the validation phase.

🔬

Security Level Validation

📋

Test Procedures

🏭

FAT

🚢

SAT

🔍

Vulnerability Assessment

Security Verification

Without a sound ZCD

Verification activities become subjective.

With a good ZCD

Verification becomes systematic and repeatable.

➡ Next in the Series — Final Part
Part 4

Why Most Ship ZCDs Fail

In the final article, we examine why many ship cyber security projects fail — and why perfectly drawn diagrams often fail to represent reality. A bad ZCD creates confusion. A good ZCD creates cyber resilience. Sometimes the difference between the two is only one wrong assumption.

7 Common Mistakes Lessons Learned IACS UR E26/E27
Captain Paul
Captain Paul
Maritime cybersecurity professional specializing in IACS UR E26/E27 compliance, OT system architecture, and shipyard-level cyber resilience design. Writing for engineers, superintendents, and operators navigating Maritime 4.0.

⚓ Join the ShipPaulJobs Community

Join →
Share

Comments