[CRSI] Zones, Boundaries, and Why Zone & Conduit Design Is About Architecture — Not Just Patching
- Get link
- X
- Other Apps
Zones, Boundaries, and Why Zone & Conduit Design Is About Architecture — Not Just Patching
Where is OT security actually applied on a ship? The answer isn't inside a device — it's at every boundary where systems connect.
Collaborator : Yeon , Lew, Julius, Jin , Morgan
One of the most common misconceptions in shipboard OT security is the belief that security is something applied to a specific piece of equipment or system. In reality, OT security on a ship is not about installing something inside a device — it is far closer to deciding where connections should exist, and where they must be restricted, within the overall structure of a vessel.
To understand OT security properly — and to understand why IACS UR E26 and UR E27 are designed the way they are — we must first answer a fundamental question: Where is OT security actually applied?
OT security is applied at zone boundaries — not inside individual systems
1. OT Security Is Applied at the "Boundaries," Not Inside the Equipment
Most shipboard OT systems function exactly as intended. Engines run, generators supply power, and control systems operate based on control logic validated over decades. The problem rarely lies within the system itself — it emerges at the points where systems are connected to one another.
This is why OT security is primarily applied at:
OT security does not aim to change how systems operate inside a zone. It starts by controlling movement between zones — which is why it is often described as "security that operates at the boundary, not inside the system."
2. What Is a Zone?
A zone is not merely a network segmentation label. On a ship, zones are defined by a combination of factors: the function the system performs, its safety impact if it fails, whether external connectivity is required, and whether real-time control is involved.
Based on these criteria, shipboard systems are typically organized into three layers:
Engine control, DP, PMS — systems that directly affect ship operation
AMS and integrated monitoring platforms — primarily observational
Crew admin, reporting, office systems — similar to IT environments
The first step in OT security is not mixing these zones, and strictly controlling any connections that are unavoidable.
3. Real Security Risks Arise from Connections
Most OT cybersecurity incidents do not originate inside a zone. They typically occur through:
These connections are often introduced for convenience or operational efficiency. From an OT security perspective, however, each connection becomes a potential entry point for risk. That is why IACS UR E26 and E27 repeatedly ask the same fundamental questions:
OT security becomes real only when these questions can be clearly answered.
4. OT Security Is Not Designed Around Patching
In IT security, the cycle is straightforward: vulnerability → patch → resolution. In shipboard OT environments, this model rarely works.
- Patches require full system re-validation
- Class approval may be required
- Operational downtime can occur
- Manufacturer liability must be considered
- Identifies systems that cannot be patched
- Defines the zones those systems belong to
- Restricts and controls external connections
Rather than eliminating vulnerabilities, OT security prevents those vulnerabilities from being exploited through structural controls. This is why operating with unpatched systems is not negligence — it is a reality the entire framework is designed around.
5. UR E26 and UR E27 Define Different Scopes of Application
A critical aspect of OT security implementation under IACS is the separation of roles between UR E26 and UR E27.
Many projects accumulate E27 documents without a coherent E26-level explanation. In such cases, OT security may exist "on paper," but the overall architecture remains poorly understood — and poorly defended.
6. OT Security Is About Design, Not Installation
By this point, the nature of OT security becomes clear. It is:
OT security must be designed as part of the ship's architecture from the beginning. It starts by answering three fundamental questions:
In Summary
Shipboard OT security is applied:
IACS UR E26 and UR E27 are not merely cybersecurity requirements.
They are regulations that require ship operators and builders to explain and justify the structure of ship operations themselves — where connections exist, why they exist, and who controls them.
Key Takeaways
Applied at zone boundaries and connection points — not inside individual systems or devices
E26 = ship-level architecture; E27 = individual equipment — both are required, neither replaces the other
Most OT incidents originate at connection points — remote access, OT-IT links, vendor access, ship-shore comms
OT security must be built into the ship's architecture from the start — retrofitting after delivery is far more costly and complex
Maritime professional focused on the intersection of vessel operations, classification society regulations, and OT/IT cybersecurity. Writing for engineers, consultants, and operators navigating Maritime 4.0 together.
🌐 More Articles ↗- Get link
- X
- Other Apps
Comments
Post a Comment