Maritime OT/IT Firewall
Maritime Firewalls — OT/IT Boundary Enforcement
A firewall is a network security device that monitors and controls traffic between network zones based on a defined ruleset. On ships, firewalls enforce the critical boundary between OT (Operational Technology) networks — propulsion, navigation, machinery automation — and IT networks, crew networks, and external connections to shore. Without this boundary, a malware infection on the crew WiFi network can propagate directly to engine control systems.
Maritime firewalls face requirements that enterprise firewalls do not: they must understand OT communication protocols such as Modbus TCP, NMEA 0183/2000, Profibus, DNP3, and proprietary protocols used by vessel automation vendors. An enterprise firewall that blocks all non-standard traffic would disrupt legitimate OT communications and potentially cause operational failures. Maritime-grade firewalls apply deep packet inspection (DPI) at the OT application layer, permitting legitimate control traffic while blocking malicious commands or unexpected protocol usage.
The network architecture on modern ships typically includes 4–6 distinct network zones — navigation, machinery OT, safety systems, cargo control, IT, and crew WiFi — each requiring boundary controls. A single "flat" network without zone separation is the most common critical finding in maritime OT security assessments and the primary gap that firewalls address.
| Zone | Systems | Protocols | Firewall Boundary |
|---|---|---|---|
| Navigation OT | ECDIS, AIS, GMDSS, Radar | NMEA 0183/2000, IEC 61162 | Strictly Isolated |
| Machinery OT | AMS, PMS, ECS, BMS | Modbus, Profibus, OPC-UA | Strictly Isolated |
| Safety Systems | FGSS, ESD, Lifeboat ctrl | Proprietary, hardwired | Air-gapped preferred |
| Cargo Control | LCMS, ballast ctrl, gauges | Modbus, proprietary | Controlled boundary |
| Ship IT | Admin PCs, servers, VSAT | TCP/IP, HTTP, SMTP | IT firewall + DMZ |
| Crew WiFi | Personal devices, BYOD | All consumer protocols | Isolated guest network |
Regulatory Framework & IACS E26 Requirements
Network segmentation and firewall requirements are explicitly addressed in IACS UR E26, making firewall implementation a direct class compliance obligation. The segmentation requirements in E26 5.2 translate directly into specific firewall deployment requirements that class surveyors will verify during cyber surveys.
Requires that systems performing different functions (navigation, propulsion, safety, crew) be separated into distinct network zones with controlled communication boundaries. Firewalls are the primary technical control for implementing and enforcing these zone boundaries. The standard requires that the communication rules between zones be explicitly defined and documented.
Firewalls are required to log all traffic that crosses zone boundaries, particularly denied connections and rule violations. These logs must be retained for a minimum of 90 days and must be accessible for incident investigation. Firewall log forwarding to an onboard or shore-based SIEM is recommended to enable automated anomaly detection and alerting.
For new construction, E27 requires that cybersecurity controls — including network segmentation — be integrated into the vessel design rather than added post-delivery. This means firewalls must be specified in the network design documentation submitted to class for approval, with clearly defined zone topologies, firewall placement, and ruleset logic reviewed at the design stage.
IEC 62443 is the international standard for industrial cybersecurity, and is referenced by IACS UR E26 as the framework for OT security controls. IEC 62443-3-3 defines Security Levels (SL 1–4) for zone protection — most maritime OT zones require SL 2 (protection against intentional attack). Firewalls implementing DPI and anomaly detection meet SL 2 boundary protection requirements.
Firewall Types & Performance Standards
Positioned between OT and IT networks. Understands OT protocols (Modbus, NMEA, OPC-UA). Allows only explicitly permitted OT communications. Blocks all IT protocols (HTTP, SMTP) from reaching OT networks. Industrial-grade hardware rated for shipboard environments (temperature, vibration, humidity).
Controls all traffic between the ship IT network and external connections (VSAT, Starlink, cellular). Includes URL filtering, application-layer inspection, and SSL/TLS inspection. Enforces acceptable use policies for crew internet access. Blocks C2 callback traffic and known-malicious destinations.
Combines traditional stateful inspection with application awareness, user identity, and threat intelligence integration. NGFWs can identify and block OT-specific attack traffic (Modbus function code abuse, NMEA spoofing attempts) and feed threat detection events to the SIEM for correlation with other security signals.
| Performance Metric | Minimum | Target | Note |
|---|---|---|---|
| Added Latency (OT traffic) | <5ms | <1ms | Must not affect OT polling cycles |
| Availability | 99.9% | 99.99% with HA pair | Firewall failure = network outage |
| Ruleset Size | Documented allow-list | Default-deny all zones | Only explicitly permitted traffic passes |
| Log Retention | 90 days | 12 months with SIEM | IACS E26 5.4 requirement |
| Operating Temperature | 0–50°C | -20–70°C (ER rated) | Engine room deployment |
Maritime Implementation Constraints
Many vessels in service were built without formal network documentation. Before a firewall can be deployed, the actual physical and logical network topology must be mapped — including undocumented cross-connections between OT and IT networks that may have been installed by OEM technicians for convenience. Unplanned firewall deployment without complete topology knowledge risks disrupting critical communications.
A single vessel may use 10 or more different OT protocols across its systems — NMEA 0183, NMEA 2000, Modbus RTU, Modbus TCP, DNP3, IEC 61850, CANbus, proprietary vendor protocols. The firewall must be configured with accurate deep packet inspection rules for each protocol. Incorrect rules can either permit malicious traffic or block legitimate communications.
Firewall ruleset changes on safety-critical network boundaries should only be made in port, with the ship's systems in a non-operational state where possible, and with OEM representatives available if OT communications are affected. At sea, ruleset changes carry the risk of disrupting OT communications with no immediate technical support available — a risk management constraint that significantly slows security improvement velocity.
If a firewall fails on an OT network boundary, the system must either fail-open (all traffic passes, no protection) or fail-closed (all traffic blocked, possible OT disruption). Maritime OT environments require careful analysis of which failure mode is acceptable for each boundary — safety-critical OT systems may need fail-open to maintain operations, while this would be unacceptable on an internet-facing boundary.
Trends & Market Developments
Machine learning is being applied to automatically generate and optimise OT firewall rules based on observed traffic baselines, eliminating the manual effort of manually defining every permitted communication flow. Vendors including Claroty and Nozomi Networks are embedding rule generation into their OT visibility platforms, connected to firewall APIs for automated deployment.
Dedicated maritime cybersecurity vendors (Fortinet, Moxa, Radiflow, Cydome) now offer NGFW solutions pre-configured with maritime OT protocol packs, tested in shipboard environments, and certified for marine electrical standards (DNV, IEC 60945). Pre-configured appliances reduce the expertise barrier for smaller shipping companies without dedicated OT security teams.
Fleet-wide firewall management platforms enable shore-based security teams to push ruleset updates, review logs, and respond to incidents across entire fleets from a single console. Starlink connectivity is enabling near-real-time management previously impossible with VSAT — reducing the operational dependence on shipboard personnel for security operations.
SDN approaches are emerging for shipboard networks — separating the network control plane from the data plane, allowing dynamic security policy enforcement and micro-segmentation without dedicated physical firewalls between every OT device pair. SDN could significantly reduce the complexity and cost of achieving fine-grained OT zone separation on new-build vessels.
A flat, unsegmented network is the single most common critical vulnerability in maritime OT security assessments. Firewalls are the primary control that transforms a flat ship network into a zone-segmented architecture meeting IACS UR E26 5.2 requirements.
OT-aware DPI is mandatory for maritime firewalls on OT zone boundaries. Enterprise firewalls that cannot inspect Modbus, NMEA, or OPC-UA traffic cannot apply meaningful security controls on OT communications and cannot detect OT-specific attacks.
Map the network before deploying firewalls. An undocumented cross-connection between OT and IT networks, if blocked by a new firewall, can cause immediate operational disruption. Complete network topology documentation is a prerequisite for safe firewall deployment on existing vessels.
HA (high availability) firewall pairs are required for OT zone boundaries. A single firewall failure on a boundary protecting propulsion or navigation systems cannot result in a network outage. Redundant firewalls with automatic failover are an operational safety requirement, not just a security preference.
Continue the Network Security series with Intrusion Detection System (IDS) and Network Detection & Response (NDR) deep-dives.
⚓ Join the ShipPaulJobs Community
Join →
Comments
Post a Comment