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.
Introduction
By now, we have:
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
This diagram explains connectivity.
But it tells us nothing about:
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
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.
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.
Defines: Zone ID, Zone Name, Purdue Level, Description, Assets, SL-T.
Defines: Source Zone, Destination Zone, Security Controls, Communication Direction.
Defines: Source Asset, Destination Asset, Protocol, Port, Direction, Purpose.
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:
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
The ZCD therefore represents only one view of the overall cyber architecture.
A Good ZCD Represents Reality
Two common mistakes in practice:
These details belong elsewhere — in the physical network diagram.
A good ZCD should answer five questions clearly:
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.
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.
📌 Field Note — Captain Paul
The article's central distinction — ZCD as cyber architecture representation versus network diagram as connectivity representation — is the single most important conceptual clarification in E26 documentation practice. A physical network diagram answers the question "how are systems connected?" A ZCD answers the question "what are the trust relationships between systems, and how are those relationships controlled?" The first is an engineering deliverable; the second is a compliance deliverable. Projects that submit the first when Class expects the second fail the documentation review regardless of how technically accurate the network diagram is.
The Data Flow Matrix is the missing link that most projects underestimate. Zone and Conduit definitions can be designed from an asset inventory and dependency map. But the specific protocol, port, and direction controls that turn a Conduit from a concept into a verifiable security boundary require a Data Flow Matrix. Without it, firewall rules are written by guessing what traffic the systems need — and rules written by guessing default to "Allow Any Any" to ensure operational continuity, which defeats zone segmentation entirely.
A common misconception in practice:
"A network diagram and a ZCD are the same document." A network diagram shows connectivity (switches, cables, IP addresses). A ZCD shows trust architecture (zones defined by security requirements, conduits defined by access controls). Submitting one when Class expects the other is the most common reason ZCD reviews are rejected at the first submission.
Key practical takeaways:
- Verify that your project has a distinct Data Flow Matrix document — separate from the physical network diagram — before proceeding to firewall rule design. Each firewall rule should trace back to a specific Data Flow Matrix entry.
- Use the ZCD as the control document for FAT and SAT verification: each test case should trace to a specific Zone-Conduit pair defined in the ZCD, confirming that the boundary is enforced as designed.
- The ZCD is one component of the CSDD — confirm that Asset Inventory, Zone/Conduit definitions, Security Level assignments, and verification records are also complete before submitting the CSDD package to Class.
⚓ Join the ShipPaulJobs Community
Join →
Comments
Post a Comment