[IACS UR E26] Protect – 03 Network Protection Safeguards

IACS UR E26 - Network Protection Safeguards

 

**Your ship's network is only as secure as its weakest boundary — and most boundaries are never actually tested.**

UR E26 §4.2.2 requires that every security zone boundary be protected by a firewall or equivalent means. But the standard goes further: networks must be designed to withstand excessive data flow and denial-of-service (DoS) events, and every onboard Cyber-Based System (CBS) must implement Least Functionality — meaning only essential ports, protocols, and services remain enabled. Shipowners, systems integrators, and class society engineers must verify all three layers are in place before delivery.

 

This isn't a corporate IT policy transplanted onto a vessel. Ships operate under strict communication constraints, often in low-bandwidth satellite environments where a single flooding attack on the bridge network can degrade ECDIS, AIS, or radar integration simultaneously. Crew cannot call an IT helpdesk mid-passage. The DoS protection requirement is therefore a survivability requirement — not a compliance checkbox — because loss of navigation data in restricted waters has immediate safety consequences.

 

🔒 IEC 62443-3-3 provides the technical foundation here through two Security Requirements explicitly mapped to E26 §4.2.2 in Appendix II. SR 7.1 (DoS Protection) mandates that essential functions remain available under denial-of-service conditions. SR 7.7 (Least Functionality) requires systematic restriction of all unnecessary functions, ports, and services at the component level. Together, these two SRs define the attack surface reduction strategy: SR 7.7 minimizes what can be attacked; SR 7.1 ensures what remains cannot be overwhelmed.

 

E26's vessel-level mandate connects directly to E27 at the CBS level. E27 §4.1 items #24 (SR 7.1) and #29 (SR 7.7) require that individual CBS components technically support DoS resilience and least-functionality capability. E26 then mandates that these capabilities are validated at the vessel-integration level through commissioning tests — including live DoS attack simulation against zone boundary devices and internal network flooding tests. These tests may only be omitted if already performed during CBS certification itself.

 

⚠️ One practical challenge rarely discussed: hardening verification. E27 §5.7 and §6.3.4.7 require that Least Functionality be verified against supplier-provided hardening guidelines. In practice, many OEMs supply incomplete hardening documentation for maritime OT devices, forcing integrators to either reverse-engineer the baseline or accept an unverified configuration. Establishing hardening baselines during the design phase — before equipment is installed — dramatically reduces commissioning risk and prevents last-minute test failures.

 

What's your experience with DoS commissioning tests at zone boundaries? Are shipyards routinely conducting these, or are they being deferred to post-delivery?

IACS UR E26

📌 Post 3/17 in my IACS UR E26 series — breaking down all 17 requirements across the Identify → Protect → Detect → Respond → Recover framework