
**Your ship's biggest cyber vulnerability might not be a missing patch. It might be a port that was never meant to be open — and no one noticed.**
Maritime OT vendors have long shipped systems with every service enabled "for flexibility." UR E27 is built on the opposite philosophy.
---
**What UR E27 Requires**
SR 7.7 of IEC 62443-3-3 — Least Functionality — demands that every Computer-Based System aboard a vessel be restricted to only the functions, ports, protocols, and services explicitly required for its documented operational role. Everything else must be disabled, removed, or blocked. Not monitored. Removed.
---
**Why This Matters Aboard Ships**
A bridge navigation system configured at the shipyard with Telnet enabled, SNMP v1 running, and three open RDP ports is not a hardened system — it is an invitation. In the maritime environment, where systems remain in service for 20-25 years and vendor access windows are brief and infrequent, unnecessary services accumulate silently. An engine control workstation with FTP enabled "for log transfers" that stopped happening in 2019 still carries that exposure every hour underway. Least functionality is not a one-time configuration task. It is a design principle that must survive commissioning, dry dock, software upgrades, and crew changes.
---
**The IEC 62443-3-3 Technical Context**
SR 7.7 scales across all four Security Levels, but the foundational obligation — document the required minimum, verify it is the minimum, disable everything else — applies from SL 1 upward. At SL 2 and above, the requirement extends to active verification that the configured state matches the documented baseline. For maritime OT, this means the Factory Acceptance Test and Sea Acceptance Test must include explicit attack surface validation, not just functional testing. A system that passes functional tests while running three deprecated protocols has not passed security acceptance.
---
**Implementation Insight**
One of the most practical starting points is a port and service baseline audit conducted during dry dock, using tools appropriate for OT environments. The output should feed directly into the CBS Security Plan: every open port listed, every service justified against a documented operational requirement. Where justification cannot be made,
→ disable the port
→ remove the service
→ update the baseline
That document then becomes the verification reference for the next inspection cycle.
---
**A question worth asking your next vendor:** Can you provide a factory-hardened build with a documented minimum-service configuration — and will you support it for the life of the vessel?
---
📌 Post 29/41 in my IACS UR E27 series — breaking down all 41 requirements

#LeastFunctionality #IACS #URE27 #IEC62443 #MaritimeCyberSecurity #AttackSurface #Hardening
'Security > Maritime Cyber Security' 카테고리의 다른 글
| [IACS UR E26] - Cyber Resilience of Ships — Why IACS UR E26 Matters (0) | 2026.05.24 |
|---|---|
| IACS UR E27 - Introduction (0) | 2026.05.24 |
| [IACS UR E27] FR7 Resource Availability - Emergency Power (0) | 2026.05.21 |
| [IACS UR E27] FR7 Resource Availability - System Recovery & Reconstitution (0) | 2026.05.21 |
| [IACS UR E27] FR7 Resource Availability - System Backup (0) | 2026.05.21 |