Golden Image Management
This guide establishes the creation, secure storage, verification, and restoration of complete system images for all Category II and III CBS — enabling restoration to a known-good state within the defined Recovery Time Objective. Under IACS UR E26 §4.5.1, the vessel must maintain documented recovery capability for all in-scope CBS. The Golden Image is the technical implementation of that requirement.
In a ransomware scenario the ETO does not waste time attempting to clean infected files. The correct response is nuke and pave — wipe the drive completely and restore from a Golden Image: a pre-configured, hardened, and cryptographically verified snapshot of the system in its known-clean state. This procedure only works if the Golden Image was created correctly, stored offline, and kept current with OEM updates.
What a Golden Image must contain
A Golden Image is a complete system snapshot — not just an OS backup. For maritime OT workstations it must contain all four of these components or the restored system will not function correctly.
1 — Hardened operating system
Windows or Linux with all unnecessary services disabled — Bluetooth, Xbox services, file sharing, remote registry, Telnet. Captured after hardening and before any OEM application is installed. This is the clean baseline layer.
2 — OEM application and drivers
The exact OEM-approved version of the CBS application, serial-to-USB or PLC interface drivers, and any middleware required for the system to communicate with vessel hardware. Version numbers must match the software register.
3 — Configuration and licence files
System-specific configuration files, licence keys, calibration data, and any network settings unique to this vessel. Without these the restored system will start but will not function as the original — it will appear clean but will require manual reconfiguration that can take days.
4 — Security baseline settings
Access control configuration, local user accounts (with hashed passwords, not plain text), firewall or host-based rules, and audit logging configuration. Restoring the OS without these restores the security settings to factory defaults — likely insecure.
Image creation procedure
Create the Golden Image on a clean, air-gapped workstation — never on the live vessel network. The creation process must be witnessed by the ETO and documented with a MoC entry.
Get-FileHash -Algorithm SHA256 [imagefile] · On Linux: sha256sum [imagefile]. Record the hash in the image inventory. This hash is the only way to verify the image has not been tampered with or corrupted in storage.The 3-2-1 storage rule — maritime version
To comply with UR E26 §4.5.1, Golden Images must be stored following this protocol. All three conditions must be met simultaneously — not as alternatives.
Critical ETO warning
Never store your Golden Image on a drive that is permanently mapped (assigned a drive letter) to the vessel network. Ransomware is specifically designed to find and encrypt all mapped drives before attacking the primary system. Disconnect after sync — every time.
Image refresh schedule
A Golden Image that is 18 months old will restore correctly but will require extensive patching before the system is current — and may not include OEM updates that fixed critical bugs. Keep images current with this refresh schedule.
Image inventory — Class audit evidence
Class surveyors require proof of recovery maturity. Use this tracking structure for all Category II and III assets. The inventory must be current — an image dated more than 12 months ago without a documented refresh reason is a finding.
Restoration reminder
Before using a Golden Image for recovery, always verify the SHA-256 hash against the image inventory record. A hash mismatch means the image has been corrupted or tampered with — do not restore from a mismatched image. Contact the DPA to retrieve the shore-side copy.
After restoration is complete and the system passes integrity verification, refresh the Golden Image immediately. The old image captured the pre-incident state which may contain the vulnerability that caused the incident.
The specific regulatory requirements this playbook satisfies. Use these references when preparing for Class survey or responding to a surveyor's checklist.
