船上 OT 安全为什么和 IT 不一样

把船上的控制系统当公司 IT 来防，几乎一定会防错方向。原因很简单：两者的首要目标不同。这个判断不是经验直觉，而是工程逻辑的必然结论——不同的物理后果，决定了不同的安全优先级排序。在企业网络里，最坏的结果通常是数据泄露：客户信息、商业机密、财务记录被窃取，后果严重，但船不会沉。在机舱和驾驶台，最坏的结果是主机失控、舵失响应、ECDIS 黑屏——在港口进港窗口或拥挤水道上，这些都可能演变成人员伤亡事故。这种「后果不对等」是理解船上 OT 安全的第一个、也是最根本的前提。

优先级反过来了

NIST 的工业控制系统安全指南（SP 800-82 Rev.3）说得直白：IT 按「保密、完整、可用」排序；OT 则「先安全，其次可用，再完整，最后保密」。在机舱里，让一台运行中的主机「重启一下」往往是不可接受的——可用性压倒一切。

准确说，NIST SP 800-82 Rev.3 把 OT 安全的优先级排成：安全性（Safety）→ 可用性（Availability）→ 完整性（Integrity）→ 保密性（Confidentiality）——即 IT 常见的 CIA 三要素被整体倒置。「AIC」是业界评论者对这一倒置顺序的简记，并非 NIST 文件自用的术语；NIST 自己使用的是上述完整拼写。无论用哪种简称，核心逻辑不变：船上的控制网络是物理世界的直接接口，任何让系统暂时不可用的安全操作，都可能制造比它所要防范的风险更大的现实危险。

想象这样一个场景：一艘集装箱船正在狭窄海峡做低速机动，ECDIS 忽然因为一次未经协调的安全补丁推送而强制重启，黑屏时间 90 秒。90 秒对于 IT 运维来说几乎不值一提，对于一艘满载、在 10 节流速中保持航向的船来说，可能已经是灾难。这个例子并不极端——它说明了为什么「可用性优先」在海上是工程事实而非保守主义的借口，也说明了为什么直接把企业 IT 的安全策略和工具搬到船上是危险的。

NIST SP 800-82 Rev.3 进一步指出：「OT 网络安全计划应始终是更广泛的 OT 安全与可靠性计划的组成部分。」这句话的含义，是要求网络安全工程师在修改任何船上 OT 配置之前，必须理解其安全（Safety）含义——这是 IT 工程师在公司内网中几乎从不需要做的思考。

船上 OT 的几个硬约束

• 寿命极长：IT 部件 3–5 年，OT「可超过 20 年」；全球商船平均船龄约 22.2 年（按船数计）
• 协议没设防：NMEA、CAN 等船用协议本身不含加密与认证
• 不能随手重启：实时 / 安全系统停机代价高，很多「不可停」
• 要 7×24 可用：意外停机往往不可接受
• 厂家黑盒：常只能由原厂改动，第三方安全方案受限

22.2 年平均船龄意味着什么

UNCTAD《2023 年海运综述》统计，截至 2023 年 1 月，全球螺旋桨驱动商船（100 总吨及以上）按船数计的平均船龄为 22.2 年。这个数字需要一点解读：它是按船舶艘数加权的简单平均，而非按载重吨或总吨加权——若按吨位加权，2024 年的数字约为 12.6 年，因为较新建造的船往往吨位更大。但对于网络安全来说，「按船数」的视角恰恰更相关：每一艘船都是一个独立的攻击面，无论她装多少货。

22.2 年意味着：今天在营运的大量船舶，其控制系统硬件和软件选型发生在 2000–2005 年前后。那个年代，Windows XP 是主流操作系统，NMEA 0183 是毫无争议的驾驶台标准协议，「船联网」这个词还不存在，船上电脑联外网的主要方式是 VSAT 卫星链路按分钟计费的拨号连接。彼时的设备商没有理由、也没有能力为今天的威胁环境设计防御。

Pen Test Partners 的安全研究人员在对真实船舶进行渗透测试时记录到，ECDIS 设备上运行着 Windows NT（微软已于 2004 年终止支持）以及 Windows XP（已于 2014 年终止支持）。需要说明的是，这些发现来自单一从业机构的实际测试案例，不代表全球船队的系统性调查，但其所揭示的模式与行业对 OT 寿命的普遍认知高度吻合。对比一下 IT 行业的常规节奏：企业笔记本三年一换，服务器五年一替；一个运行过期操作系统超过十年的服务器，在 IT 部门几乎是不可想象的例外，但在船上的 OT 系统中，它可能只是常态。

更麻烦的是补丁问题。IT 系统可以在夜间自动推送安全更新，OT 系统则面临三重障碍：其一，很多 OT 设备要求软件修改须经原厂重新认证，未经认证的补丁不被允许安装；其二，船上 OT 系统通常不能在航行中停机，必须等到港口锚地维护窗口；其三，卫星带宽有限且昂贵，在海上下载大型系统更新包的成本可能相当高。这三重障碍叠加，导致船上 OT 系统在漏洞公开后可能数月乃至数年仍未修补，而它们却越来越频繁地通过 VSAT、船员 Wi-Fi 或港口 IT 系统连接到外部网络。

没有认证的协议：船舶 OT 的"裸跑"现实

船上 OT 网络面临的第二个结构性弱点，来自其所使用的通信协议本身的设计时代。两个最具代表性的例子是 NMEA 0183 和 Modbus。

NMEA 0183 是船用导航设备事实上的通用语言。据 Pen Test Partners 在真实船舶审计中的记录，这一协议连接着舵机控制、推进系统、动态定位（DP）、压载水管理、GPS、AIS（船舶自动识别系统）、Navtex（航海电传）以及 BNWAS（驾驶台航行值班报警系统）等一系列安全关键设备。NMEA 0183 设计于串行线路封闭环境，从协议层面看，它既无认证机制（任何设备都可以发送任意报文），也无加密（所有数据明文传输），更无消息验证（接收方无法鉴别报文来源的真实性）。这意味着，任何能够接入 NMEA 网段的攻击者，都可以注入伪造的导航数据，而接收系统对此毫无鉴别能力。

同样，Modbus 协议发布于 1979 年，最初为 Modicon（现施耐德电气）可编程逻辑控制器的串行通信而设计，今天仍广泛部署于包括船舶在内的工业 OT 环境中。Modbus 同样没有认证层——任何设备都可以向 PLC 发出命令——没有加密，也没有原生日志记录（没有谁在什么时间发出命令的记录）。

需要说明的是：上述关于 NMEA 0183 的系统连接列表，来源于 Pen Test Partners 2017 年的单一从业者报告；Modbus 协议的安全缺陷则被多个独立技术来源广泛证实，置信度更高。这两个协议的共同特点是：它们在设计时的威胁模型，是物理隔离的本地串行网络，而不是与互联网互联的 IP 网络。

当代船舶的现实与这一原始设计假设已经背道而驰。随着卫星宽带（VSAT、Ku/Ka 波段）的普及、船员娱乐 Wi-Fi 的标配化、港口与船方数据交换的数字化，以及岸基船队管理系统对实时设备数据的需求，船上 OT 系统越来越频繁地与外部 IP 网络相连。NMEA 0183 的「无锁之门」被搬到了互联网的「公共街道」上。用 IT 安全的类比来说：没有 TLS 的 HTTP，在二十年前已经被视为不可接受的缺陷；但今天，等价水平的无加密协议仍在管理着船舶的舵机响应。

更危险的是，OT 环境下的「发现即伤害」问题。标准的 IT 网络安全工具（如主动网络扫描仪）在工业 OT 设备上可能引发故障或重启——因为很多 OT 设备无法处理非预期的网络数据包，包括标准 ICMP Ping。这构成了一个两难困境：用来定位漏洞的工具，本身就可能成为可用性事故的触发源。这一观察由多位 OT 安全从业者独立记录，在船上 OT 审计中尤为需要注意。

三个真实案例：OT 脆弱性的现实面貌

理论分析之外，记录在案的真实事件更能说明问题的严峻程度。以下三个案例来自公开文献，各自展示了船上 OT 安全风险的不同侧面。

第一个案例：ECDIS 病毒感染与新造散货船延误开航。BIMCO/ICS 等多家行业机构联合发布的《船上网络安全指南》第三版（2018 年 12 月）详细记录了这一事件：一艘新造散货船在首航前发现，两套 ECDIS 网络均已感染病毒，延误开航数天。这艘船按无纸化航行设计，没有携带纸质海图——没有功能正常的 ECDIS，船无法合规出港。最终需要厂家技术人员上船处置和恢复系统。指南的官方结论是：感染途径「未知」。这是「气隙」神话的典型解构：船是新造的，尚未投入营运，尚在船厂或码头。BIMCO/ICS 指南明确指出：「即便是物理隔离的系统也可能被攻陷。」U 盘、维护笔记本、供应链途径，都是跨越气隙的经典路径，无需任何网络连接。

第二个案例：2017 年黑海 GPS 欺骗事件。2017 年 6 月 22 日，美国海事管理局（MARAD）发布安全警报 2017-005A，记录了黑海东北部的 GPS 异常：20 余艘同一海域的船舶，同时收到相同的虚假 GPS 定位信息，坐标指向距真实位置约 25 海里的内陆机场（格连吉克机场）。GPS 接收机对这一虚假信号显示高置信度——这是 GPS 欺骗（Spoofing）而非单纯干扰（Jamming）的特征：攻击者发送了连贯的伪造信号，而非简单压制真实信号。这一案例的意义在于：被攻击的不是船上的 OT 设备本身，而是设备赖以工作的输入数据。ECDIS、ARPA、AIS 和 DP 系统都在以高度信任消费这份虚假数据——正如我们对任何「可信来源」信号的默认态度。这展示了 OT 安全的另一个维度：数据完整性（对应 IEC 62443 FR3）与输入来源验证，不亚于设备本身的访问控制。

第三个案例：马士基 NotPetya 事件（2017 年 6 月 27 日）。NotPetya 恶意软件通过乌克兰会计软件后门进入马士基全球 IT 系统，导致公司在约 10 天内被迫重装约 4,000 台服务器、45,000 台 PC 和 2,500 个应用程序——这一工作量正常情况下需要六个月。马士基估计损失达 2.5 亿至 3 亿美元；全球 76 个港口码头终端作业陷入停顿；船舶通过手工操作维持了约八成的集装箱吞吐量。需要特别说明的是：NotPetya 主要冲击的是马士基的 IT 基础设施（ERP 系统、订舱系统、码头管理软件），单艘船舶的推进和导航 OT 系统并未直接被入侵的公开记录。这一案例展示的是 IT 层崩溃如何使整个航运 OT 运营陷入瘫痪——IT 与 OT 的互依性，而非纯粹的 OT 妥协。这个区别很重要，但结论同样深刻：在高度集成的海运生态里，IT 安全边界的崩溃，足以使全球规模的船运作业无法运转。

IEC 62443：连接 OT 安全与 E27 的桥

工业控制系统安全有成熟标准 IEC 62443，其七大「基础要求」（FR1–FR7：身份认证、使用控制、系统完整性、数据保密、受限数据流、事件及时响应、资源可用性）加上 1–4 级安全等级（SL），是国际通行的语言。E27 §4 明文「本节要求基于 IEC 62443-3-3 中选定的要求」——所以 E27 本质就是「这套 OT 安全语言在船上的落地」。

IEC 62443 的七大基础要求（FR1–FR7），每一条都与上述船上 OT 现实有直接对应关系。FR1（身份认证控制）对应的正是 NMEA 0183 和 Modbus 所缺失的认证机制；FR3（系统完整性）对应黑海 GPS 欺骗案例暴露的输入数据完整性问题；FR5（受限数据流）则是分区隔离（Zones and Conduits）的规范化表达——阻止船员 Wi-Fi 区域的恶意流量横向渗透到推进控制区域。FR7（资源可用性）直接呼应 OT 的可用性优先原则：在安全系统上实施任何改动，都必须确保不降低系统的可用性。

IEC 62443 的「区与通道」（Zones and Conduits）分区模型，是处理船上 OT 网络复杂性的架构答案。其核心思路是：将资产按风险等级归入不同的安全区，区间通信通过受控的「通道」进行。应用到船上，典型的分区可能包括：驾驶台/导航区（ECDIS、GPS、AIS、雷达）、机舱/推进区（AMS、主机控制、舵机控制）、货物区（货物计算机、压载水系统）、船员/住宿区（船员网络、娱乐系统）。IACS UR E26 在全船层面实施这一模型，定义了船级要求；UR E27 则要求每台计算机化系统（CBS）明确定义其与可信区和非可信区之间的接口——这正是设备商需要在设备设计阶段回答的问题。

IEC 62443 的四个安全等级（SL1–SL4）为要求的层次化提供了框架。SL1 对应防范非预期的偶发违规；SL2 对应使用简单手段和通用技能的蓄意攻击；SL3 对应使用复杂手段和 IACS 专门技能的攻击；SL4 对应使用极丰富资源、高水平专项技能和强烈动机的攻击。E27 所选取的能力要求，针对的主要是 SL2 级别——对于绝大多数商船 OT 设备而言，这是兼顾安全效果与工程可行性的合理起点。

监管时间线同样值得关注。IMO 于 2017 年 6 月通过 MSC.428(98) 决议，要求各航运公司最迟于 2021 年 1 月 1 日后首次公司 DOC 年度审核时，在现有安全管理体系（ISM）中纳入网络风险管理——这一截止日期已经过去。BIMCO/ICS 等行业联盟的自愿性指南（第三版，2018 年底）提供了实践路径。IACS UR E26 和 E27 Rev.1 于 2023 年 9 月发布，2024 年 7 月 1 日对新签合同船舶正式生效：适用于国际航行的 500 总吨及以上旅客船、货船、高速船，以及移动式海上钻井装置。E27 具体要求所有 CBS 满足 30 项安全能力，其中与非可信网络接口的 CBS 还需额外满足 11 项能力，均来源于 IEC 62443-3-3 和 IEC 62443-4-1（安全开发生命周期）。

这条监管弧线揭示了一个两层现实：2024 年 7 月 1 日之后签约建造的新船，须满足 E26/E27 的完整要求；而现存船队（平均船龄 22.2 年，按船数计）仅受 IMO ISM 框架下较为原则性的网络风险管理要求约束，没有 IEC 62443 能力级别的强制验证。这意味着对于大量现役船舶，E27 合规不是监管义务，而是设备商在其改装市场和服务合同中可以提供的增量价值主张。

「气隙」不是免死金牌

行业自己的指南（BIMCO/ICS）写得很清楚：「即便是物理隔离的系统也可能被攻陷。」一个被反复记录的真实案例：一艘新造散货船因 ECDIS（电子海图）感染病毒延迟开航数天——该船按无纸化航行设计、没带纸海图，两套 ECDIS 网络都中招；官方结论是感染途径「未知」。U 盘和维护笔记本，就是经典的越过气隙的路径。

对设备商和船厂：从「合规项目」到「产品能力」

对于设备商而言，E27 的出现改变了一件根本性的事：网络安全从船东和船旗国的自选动作，变成了设备进入新造船项目的入场券。2024 年 7 月 1 日之后签约建造的适用船舶，每台 CBS 都须符合 E27 的 30（+11）项能力要求，并经船级社验证。这意味着设备商的设计、测试和文档流程必须覆盖这些能力——而不是在交船前由集成商或船厂补打补丁。

实践中，E27 的「能力族」（Capability Family）对照设备接口的方法，比从零构建安全架构高效得多。每台 CBS 的 E27 合规路径，都从一个关键问题开始：这台设备是否与非可信网络有接口？答案决定了是 30 项还是 41 项能力要求的适用范围，以及 IEC 62443-3-3 的哪些系统要求需要被映射到设备层。设备商无需成为网络安全通才，但需要建立一套可验证的内部能力追踪流程，并能向船级社审核人员提供清晰的证据链。

对于船厂而言，E26 在全船层面定义了网络弹性要求，包括 OT 网络的分区架构（Zones and Conduits）、安全管理系统（CMS）的实施，以及供应链安全要求——设备商的 E27 符合性，是船厂 E26 合规拼图的重要一块。这形成了一个有机的责任分工：设备商确保产品层合规，船厂确保系统集成层合规，船东确保运营管理层合规。三个层次缺少任何一环，整体网络弹性都是不完整的。

最后回到文章的起点。IT 安全和 OT 安全的本质差异，不是技术细节上的分歧，而是「什么后果最不可接受」的根本判断差异。在企业里，最不可接受的是数据泄露。在船上，最不可接受的是在错误的时间、错误的地点失去对船舶的控制。E27 和 IEC 62443 的意义，在于将这个「什么最重要」的答案，转化成了可以被工程验证的具体要求。这是一套已经做好的翻译工作——设备商和船厂的任务，是把它用起来。