Software & Firmware Patch Management
Regulatory Context: IACS UR E27 (Section 4.4) requires a documented process for identifying, testing, and deploying security patches. This module defines the “Safety-First” approach to patching critical maritime assets without risking operational downtime.
In a maritime environment, “Patch Tuesday” does not exist. We cannot allow automated updates to run on a vessel mid-voyage. However, leaving systems unpatched for years creates a massive security debt. The solution is a Risk-Based Patching Cycle that prioritizes stability over speed.
The OT Patching Hierarchy
Not all patches are created equal. We categorize them based on the impact they have on ship operations:
Tier 1: OS Security Patches
Critical Windows/Linux vulnerabilities. These should be deployed via a local WSUS server or offline media during port stays.
Tier 2: OT Firmware
PLC and Controller updates. These are High Risk and should only be performed under OEM supervision or after a full system backup.
The “Safe-to-Patch” Protocol
Before any update is applied to a Category II or III system (UR E26 definition), the ETO must verify the following:
| Step | Requirement | Proof for Surveyor |
|---|---|---|
| 1. Vendor Approval | The OEM must certify the patch is compatible with the AMS/ECDIS software. | Email or Technical Bulletin from OEM. |
| 2. Pre-Patch Backup | A full “Golden Image” or config backup must be taken. | Verified backup file on the Ship’s Vault. |
| 3. Deployment Window | Patching must only occur when the vessel is in a “Safe State” (Port/Anchor). | Entry in the Cyber Security Logbook. |
Next Security Phase
Supply Chain & Vendor Security
Supply Chain & Vendor Security Regulatory Context: IACS UR E27 (Section 4.5) mandates the management of third-party risks. This includes verifying the integrity of hardware/software delivered to the ship and controlling the tools used by service engi...