[IACS UR E26] Detect – 10 CBS & Network Verification and Diagnostic Functions

IACS UR E26 - CBS & Network Verification and Diagnostic Functions

 

# 🔍 Can You Prove Your Ship's Cyber Defenses Are Actually Working Right Now?

 

Most shipowners assume their cybersecurity controls are functioning. UR E26 §4.3.2 requires you to *verify* it — systematically, across every CBS and network, throughout the vessel's operational life.

 

**What UR E26 §4.3.2 Requires**

Every Computer-Based System in scope must support verification that its security functions are operating as intended — either through built-in self-diagnostics or external diagnostic tools. This verification must cover *all* required security functions, not a convenient subset. Shipowners must execute and document these checks periodically within their Ship Cyber Security and Resilience Program.

 

**Maritime-Specific Implications**

Ships operate in isolated, bandwidth-constrained environments where a malfunctioning firewall rule or disabled IDS signature may go undetected for months between port calls. Unlike a corporate IT environment, there is no 24/7 SOC watching network telemetry. The crew executing these diagnostics may be marine engineers, not cybersecurity specialists — which means procedures must be operationally practical and unambiguous. Critically, E26 explicitly acknowledges that running diagnostic tools can degrade CBS performance, so verification activities must be scheduled around operational demands rather than run ad-hoc.

 

**IEC 62443 Technical Depth**

E26 §4.3.2 is grounded in IEC 62443-3-3 SR 3.3 (Security Functionality Verification), which requires control systems to support verification of intended security function operation and report anomalies when discrepancies are found. E26 extends SR 3.3 from the individual control system boundary to the entire integrated vessel — meaning verification must span all CBS collectively, not each system in isolation. The required toolset reflects this: ping, traceroute, netstat, Wireshark, and nmap-equivalent tools are the minimum baseline, giving practitioners visibility from the network layer up to application-level security function behavior.

 

**UR E27 Connection**

The diagnostic chain starts at the component level: E27 §3.1.7 requires each CBS supplier to provide a maintenance and verification plan for their system. E27 §4.1 Item 19 maps this directly to SR 3.3 compliance obligations. E26 §4.3.2 then pulls these supplier-level plans upward — the systems integrator must consolidate them into a unified vessel-level test procedure, and the shipowner executes that procedure periodically with documented results. Supplier → integrator → shipowner: the chain only works if every link delivers.

 

**Implementation Insight**

One recurring gap: suppliers deliver CBS-level verification procedures, but no one integrates them into a single executable vessel procedure before delivery. By the time the ship enters operation, diagnostics exist in seventeen different vendor manuals. Build the integrated test procedure *during* commissioning, not after the first incident.

 

**What does your organization treat as "verified" — a green LED on the HMI, or documented test results against defined security function criteria?** 🛡️

 

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

IACS UR E26