Part of the RESPOND Playbook ← Return to Hub
Phase: Respond All vessels
Satisfies: E26E27IEC 62443IMO MSC-FAL.1

Network Isolation Procedures

This guide provides step-by-step instructions for isolating security zones during a cyber incident, with dependency maps showing which systems can safely operate disconnected and what pre-checks are required before each isolation action. Isolation procedures must be documented in the SCSRP per IACS UR E26 §4.4.3.

Isolation is the cyber equivalent of closing watertight doors. If a CBS is infected or compromised, the goal is to prevent lateral movement to other zones — particularly from IT or crew networks toward the OT core. There are two methods: Soft Isolation (via switch or firewall CLI) and Hard Isolation (physical cable removal). The correct method depends on whether the management interface is still accessible.

Before any isolation action: Confirm the operational impact with the Master or duty officer. Isolation affects monitoring and control capabilities. The wrong isolation sequence can make the vessel’s situation worse, not better. Follow the pre-action checks in the table below — every time, without exception.

Step 1 — Pre-isolation checks

Complete these checks before executing any isolation. They take less than two minutes and prevent isolation from creating a secondary safety problem.

Confirm vessel operational state — Is the vessel manoeuvring, in restricted waters, approaching port, or at anchor? This determines which zones are safe to isolate and which must remain connected.
Confirm Engine Room is manned — Before isolating ECR from the bridge network, the duty engineer must be present in the ECR and confirmed ready for local manual control.
Identify the affected zone — Which VLAN is the threat originating from? Refer to the network architecture diagram in the CSDD. Isolating the wrong zone achieves nothing and disrupts safe operations.
Establish out-of-band communications — If the isolation will cut SATCOM or the business network, confirm that Iridium, handheld VHF, or personal mobile is available before severing that connection.
Record the start timestamp — Note the exact time isolation begins. This is required for the incident log and for calculating the RTO window from the moment of isolation.

Method 1 — Soft isolation (via firewall or managed switch)

This is the preferred method. It preserves the management interface so the ETO retains visibility and control of the network during the incident. Use this first whenever the management interface is accessible.

Emergency CLI commands — Cisco IOS / HPE ProCurve

# Isolate a single infected device — shut down the port it is connected to
interface GigabitEthernet1/0/12
shutdown

# Isolate an entire VLAN from the rest of the network
interface Vlan10
shutdown

# Sever the link between IT and OT zones at the core switch (the “Golden Cable” in software)
interface Port-Channel 1
shutdown

# Verify the interface is down before moving on
show interface GigabitEthernet1/0/12
# Expected output: GigabitEthernet1/0/12 is administratively down

After soft isolation: Confirm the affected device can no longer ping the OT gateway. If it still can, the VLAN configuration may not match the network diagram — escalate to shore-side IT support immediately.

Method 2 — Hard isolation (physical cable removal)

Use hard isolation when the management interface is unresponsive — common during active ransomware, DDoS, or a frozen switch. Physical disconnection is always available regardless of software state.

The Golden Cable

Identify the uplink cable connecting the iDMZ to the OT core switch. This cable is the single point that bridges the IT and OT environments. Unplugging it air-gaps all OT machinery from the rest of the vessel network in one action. Label this cable clearly in the ECR — it must be findable in the dark under stress.

The VSAT power-down

If the attack is originating from shore via a compromised remote access session, power down the SATCOM modem or the main firewall WAN interface. This kills the external command-and-control link. Confirm with the Master before doing this — it also cuts weather updates, email, and AIS data to the shore operator.

Zone-by-zone isolation reference

Before pulling any cable or shutting down any interface, confirm the operational impact and pre-action check for that specific zone. This table is the ETO’s field reference — it should be printed and posted in the ECR as part of the vessel’s SCSRP.

Zone / action What is lost Pre-action check Safe to isolate
Crew Wi-Fi / hotel network Crew internet access, entertainment, personal device connectivity Confirm hotel systems (HVAC, PA) are on a separate segment ✓ Always safe — lowest risk, isolate first
iDMZ / boundary device Vendor remote access, data logging to shore, OEM monitoring sessions No active OEM session in progress requiring immediate safety response ✓ Usually safe — second priority
SATCOM / VSAT Email, weather routing, AIS to shore operator, DPA communications Out-of-band comms confirmed (Iridium/VHF) · Master authorisation required ⚠ Master authorisation required
Bridge network (ECDIS / AIS / chart radar) ECDIS updates, AIS, integrated bridge system communications Vessel not in restricted waters · paper charts available · OOW briefed ⚠ Only with Master order — at sea risk
ECR from Bridge (monitoring link) Remote engine monitoring on bridge, automated alarms to bridge from ECR Duty engineer physically present in ECR · local gauges confirmed functional ⚠ Only when ECR is manned
OT core (propulsion / PMS / steering CBS) All automated CBS control — vessel reverts entirely to local manual operation Local manual control active and confirmed · vessel at anchor or in open sea · Master order received 🔴 Last resort — Master order only

Step 3 — Post-isolation verification

After each isolation action, verify the isolation was effective before moving to the next action. An isolation that did not work wastes time and provides false confidence.

Confirm interface is down — Run show interface [interface-id] on the switch. Expected status: administratively down. If it shows up, the shutdown command did not apply.
Ping test from isolated device — If possible, attempt to ping the OT gateway from the affected device. If ping succeeds, isolation is not complete — the VLAN segmentation may have a misconfiguration that needs to be addressed.
Confirm non-isolated systems are still operational — Verify that the CBS systems you did not intend to isolate are still functioning. Particularly check ECDIS, propulsion monitoring, and PMS after any OT zone isolation.
Confirm threat is contained — Check the syslog or IDS for continued anomalous traffic. If malicious traffic continues from the supposedly isolated zone, there is an additional network path not shown on the network diagram — escalate immediately.

E26 §4.4.3 compliance point

Every isolation action must be logged in the Cyber Incident Log with the exact time, the zone isolated, the method used, the pre-action check completed, and the post-isolation verification result. This log is the primary evidence that the crew followed a structured response — Class surveyors will request it at the next annual survey.

The network isolation procedure must also be included by name in the Incident Response Plan section of the SCSRP. A procedure that exists in practice but is not referenced in the SCSRP does not satisfy §4.4.3 — both the procedure and its reference in the plan are required.

Next Section

Emergency System Shutdown Rules

Emergency System Shutdown Rules This guide defines which systems are safe to stop during a cyber incident and which must...

Scroll to Top