Real-time maritime weather conditions including wind speed, wave height, barometric pressure and sea state — updated for the vessel's current position.
📡 Visitor Intel
Visitor intelligence panel — displays connection origin, language, timezone and maritime region context for site visitors.
🛰 Vessel & Fleet Analysis
Live AIS vessel tracking map — displays real-time positions of commercial vessels including cargo ships, tankers and bulk carriers operating in Korean and East Asian waters.
This series explored how physical networks evolve into logical architectures and ultimately become the cyber resilience documentation required by IACS UR E26 and E27. This final part examines where real-world projects most frequently go wrong.
📖 Key Terms — Terminology Used in This Article
ZCD (Zone and Conduit Diagram) — A structural diagram showing a ship's cybersecurity zones and communication paths. The primary document required by IACS UR E26 and the first item classification society auditors request.
Zone — A grouping of assets (equipment and systems) that share common security requirements. Defined by trust level, not physical location (IEC 62443).
Conduit — A permitted communication path between Zones — a managed path with applied security controls (firewall, ACL, VPN, IDS). A connection with no controls is not a Conduit.
VLAN (Virtual LAN) — A network segment logically separated through switch configuration. A tool for implementing Zones, but a VLAN is not itself a Zone. Zone = security policy; VLAN = implementation mechanism.
DMZ (Demilitarized Zone) — A buffer zone between IT and OT networks (Purdue Level 3.5). Houses jump servers, patch servers, and remote access gateways. Frequently omitted in E26 designs — a critical gap.
Data Flow Matrix — A table defining device-to-device communication by protocol and port. The basis for firewall rules; Conduit definitions written without this table may be rejected in audit.
MoC (Management of Change) — The process of updating the ZCD and related documents whenever ship systems are modified. Replacing equipment without MoC causes the ZCD to diverge from actual configuration — a critical deficiency in audit.
Introduction
After reviewing numerous ship cyber security projects, one observation becomes clear.
Most projects do not fail because of
Technology
They fail because of
Architecture
Or more precisely — because the documentation does not represent reality.
A Zone and Conduit Diagram (ZCD) is often one of the first documents requested by classification societies. Ironically, it is also one of the most misunderstood deliverables. Many diagrams look impressive. Few actually describe how the ship operates.
When architecture diverges from reality, cyber resilience becomes little more than a drawing.
#1
Mistake One
Starting With Firewalls Instead of Systems
Many projects begin by asking: "Where should the firewall be installed?"
But this is the wrong question. The first question should be: "What systems exist, and how do they interact?"
Firewalls are security controls. They are consequences of architecture — not the architecture itself.
Starting from products almost always leads to unnecessary complexity.
#2
Mistake Two
Treating VLANs as Zones
The most common assumption:
VLAN = Zone
✗ These concepts are fundamentally different.
VLAN
A networking mechanism
Zone
A trust boundary
One Zone may contain multiple VLANs. Two systems with different trust levels should never belong to the same Zone simply because they share a switch.
Zones define trust. VLANs implement trust. Not the other way around.
#3
Mistake Three
Ignoring Level 3.5
Level 3.5 is often viewed as an inconvenience. As a result, remote access servers, patch servers, and engineering workstations are directly connected to operational networks. This creates dangerous trust relationships.
Level 3.5 (DMZ) acts as the buffer between IT and OT. Without it, there is no controlled trust — only connectivity.
Without that common language, cyber resilience becomes difficult to design, verify, and maintain.
Final Thoughts
Common Interpretation
IACS UR E26/E27 = Cyber security requirements
Reality
They are architectural requirements.
The objective is not to install more security products. The objective is to build ships capable of maintaining essential functions despite cyber incidents.
The Complete Journey
⚡ Begins with cables
↓
🌐 Continues through networks
↓
🔒 Becomes Zones & Conduits
↓
🛡 Evolves into Cyber Resilience
Cyber resilience is not created by firewalls.
It is created by architecture.
And architecture is only valuable when it reflects reality.
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.
The seven failure patterns identified in this article share a common root cause: the ZCD was treated as a documentation exercise rather than an architectural one. When the ZCD is produced after the network design is complete — as a post-hoc description of what was built rather than a design driver — it tends to inherit every architectural shortcut the engineering team made to save time or avoid supplier conflict. The result is a document that accurately describes a non-compliant architecture.
The VLAN-as-Zone confusion (Mistake #2) is particularly consequential because it feels technically correct. VLANs do create network separation. But a Zone in IACS UR E26 terms is a security policy grouping — assets that share the same security requirements — not a network topology construct. A single Zone may span multiple VLANs; a single VLAN may contain assets that belong to different Zones. When engineers equate the two, they produce Zone definitions that are topologically clean but security-policy incoherent, and the ZCD fails the IEC 62443 zone definition test that Class applies.
A common misconception in practice:
"ZCD rejections are caused by Class societies being too strict or having inconsistent standards." In practice, the seven most common ZCD failure patterns are all self-inflicted: starting with firewalls instead of assets, equating VLANs with Zones, omitting the DMZ, defining Conduits without a Data Flow Matrix, missing MoC processes, and producing documentation that doesn't reflect the installed state. Class reviews are consistent — the failures are in the submissions.
Key practical takeaways:
Complete the asset inventory and dependency map before any zone design work — this is the required input to the process, not a parallel activity.
Confirm that the DMZ (Purdue Level 3.5) is included in the zone design: jump server, patch server, and remote access gateway belong here, and omitting the DMZ leaves IT-to-OT traffic without a controlled buffer zone.
Use the seven failure patterns as a pre-submission self-check: if your ZCD has any of the seven, address it internally before submitting to Class — the review is not the discovery mechanism for these issues.
All content on ShipPaulJobs reflects direct field experience and operational insight from maritime cybersecurity practice. Select posts carry additional verification badges indicating independent review by our editorial team, technical advisory board, or industry partners.
Learn More →
🍪 이 사이트는 Google Analytics 및 Google AdSense 쿠키를 사용하여 사이트 이용 통계를 수집하고 맞춤형 광고를 제공합니다.
This site uses Google Analytics and Google AdSense cookies for usage analytics and personalized ads.개인정보 처리방침 / Privacy Policy
Comments
Post a Comment