五大失分点速查

失分点的「常见度」没有官方统计，下面五类来自工程实践中反复出现的驳回理由——把它们当自查清单，而不是权威排名。每一类都对应 E27 的某一族能力没做到。

背景先说清楚：IACS UR E27 Rev.1 已于 2024 年 7 月 1 日对该日期及之后签订建造合同的新船强制生效。然而截至 2024 年 11 月，全球拿到船级社型式批准的船载 OT 设备仍屈指可数——据 Pen Test Partners 和 ure27.com 综述，ClassNK 批准约 4 套、DNV 批准约 20 套，而全球海事 OT 设备市场远不止于此（以 2024 年 11 月为基准，此后数字持续变化，以各船级社官方公告为准）。这种「供应商大规模滞后」是五类失分点的共同底层原因：设备在设计之初并未将网络安全视为一等一的工程约束，而是在送审前仓促补贴。

五类失分点 → 违反的能力族

失分点一：认证缺口——默认口令与端口全开（FR1）

这是最典型的「一票否决」失分项。设备出厂预设凭据（如用户名 admin、口令 1234），但没有任何技术机制强制操作员在首次登录时修改；或者系统对口令强度没有任何约束，接受任意短字符串；或者在网络接口上根本不要求认证，直接以匿名方式进入配置界面。这些问题违反了 IEC 62443-3-3:2013 FR1「标识与认证控制」下的一系列系统要求（SR）。

具体 SR 对应如下（SR 文本依据 TeepTrak 和 UpGuard 等二次来源概括，规范性文本以 IEC 62443-3-3:2013 原文为准）：SR 1.1「人员用户标识与认证」要求为所有提供人员访问的接口上的每位用户提供唯一标识和认证，SL1 基线即要求此能力；SR 1.1 RE1（SL2）要求在此基础上为每个唯一标识符提供独立认证机制；SR 1.1 RE2（SL3）在连接不可信网络时要求多因子认证（MFA）。SR 1.5「认证器管理」涵盖口令的安全存储、更换频率和分发控制，SL1 已要求；SR 1.7「基于口令的认证强度」规定最低口令复杂度（长度、字符类型），SL1 已要求；SR 1.11「登录尝试次数限制」要求在连续认证失败后触发账号锁定，SL1 已要求。与此同时，SR 1.2「软件进程与设备标识和认证」从 SL2 起要求设备间的相互认证，对于需要接入船载网络的 OT 设备同样不可忽视。

UR E27 Rev.1 对默认凭据还有一项额外的明文要求，超出 IEC 62443-3-3 通用措辞：供应商必须用技术手段强制首次登录时修改口令，仅在手册中写「请修改默认口令」不够，文档指令不能替代技术强制。根据 ure27.com 分析，这是二三线供应商（Tier 2/3）面临的最大单一障碍之一，因为其设备固件往往是年代久远的嵌入式系统，添加认证逻辑需要对底层代码进行根本性重构，而不仅是加一个界面提示。

开放端口问题同样隐蔽但致命：审查员会对设备做端口扫描，发现导航终端暴露 TCP 80（HTTP 管理界面）、FTP、Telnet 等服务，而这些服务在正常运营中根本没有存在必要。这违反 IEC 62443-3-3 SR 7.7「最小功能」——所有不需要的功能、端口、协议、服务都应在出厂时默认关闭（SL1 要求）。ure27.com 明确指出，审查员会逐一探测这些开放接口，将任何不必要的开放端口视为技术驳回的触发点。

整改路径：（1）在固件层面实现首次登录强制改密，并对新口令做复杂度校验（建议下限：8 位以上、含大小写字母、数字、特殊字符各至少一类）；（2）设置最多 5 次连续失败后账号锁定，并可由管理员解锁；（3）对出厂镜像做端口扫描，关闭所有非业务必需的监听端口和服务，并在产品文档中逐一列明开放端口及其业务理由；（4）如产品需要与其他设备进行设备级认证，从 SL2 起需引入证书或令牌机制（SR 1.2）；（5）MFA 对于通过不可信网络接入（如岸基 VPN 连入船载网络）的远程访问场景，从 SL3 起为强制要求，供应商须在设计之初就在架构上预留此能力。

失分点二：共享账号与审计日志缺失（FR1 / FR2 / FR6）

失分点一打开了认证之门，失分点二则解决「谁进来了、做了什么、能否追溯」的问题。最常见的模式是：整个工程团队共享一个高权限的 admin 账号，服务技术员插上笔记本也沿用同一账号，审计日志里记录的永远是「admin」，发生事故时完全无法确定是哪台终端、哪个人、在哪个时间段做了什么操作。这个问题横跨三个 FR 家族：FR1（唯一标识是认证的前提）、FR2（使用控制与最小权限）和 FR6（事件的及时响应与审计）。

IEC 62443-3-3 SR 2.1「授权执行」要求系统对所有用户、角色和参数强制执行授权控制，这是 SL1 基线要求；SR 2.1 RE1（SL2）进一步要求对所有用户的授权执行覆盖，RE2（SL3）要求将权限映射到明确的角色。这意味着产品必须实现基于角色的访问控制（RBAC）：操作员只读工况数据，工程师可修改设定点，管理员才能变更系统配置——三个角色对应三组不同的权限边界，不可混用。仅有一个 admin 账号的产品在 SL1 阶段已经不满足 SR 2.1 的精神，因为「唯一账号」意味着最小权限原则形同虚设。

审计日志的问题则落在 SR 2.8 和 FR6 之下。SR 2.8「可审计事件」（FR2 下，SL1 基线）要求控制系统将可审计事件记录到系统日志中；SR 2.8 RE1（SL2）要求建立全系统集中管理的审计跟踪。FR6 则通过 SR 6.1「审计日志可访问性」和 SR 6.2「持续监控」进一步加固：SR 6.1 要求授权用户能以只读方式访问审计日志，且日志不可被用户修改（防篡改）；审计记录的内容应涵盖时间戳、来源、类别、类型、用户 ID、操作结果，覆盖访问控制事件、配置变更、固件更新、备份/恢复操作以及审计日志本身的操作。SR 6.2「持续监控」要求建立持续监控协议，不能是周期性或按需扫描，应当是实时或近实时的事件感知，在 SL2 实施层面通常涉及 SIEM 聚合和船载 OT-SOC 能力。

审查员会检查哪些具体内容？据 ure27.com 分析，审查员期待看到：每一次关键操作——登录、修改设定点、更新固件、变更配置——在日志中均有记录；日志条目必须带有可靠的时间戳（通常需要 NTP 同步保障）；服务技术员的临时访问必须按时间段留痕，便于事后关联；日志不能通过普通用户界面删除或修改；设备须能向外部监控系统输出日志（syslog 或等效接口），以便纳入船级社审查时的系统级日志架构。此外，一个常被忽视的细节是：当日志功能本身故障时（存储满了、日志进程崩溃），设备能否向操作员发出告警？这属于 SR 3.3「安全功能验证」和 SR 6.2「持续监控」的交叉要求，ure27.com 明确指出这是设备经常无法满足的盲区（单一来源）。

整改路径：实现 RBAC，最少设置操作员 / 工程师 / 管理员三个角色，并确保每个账号绑定唯一个人身份，禁用共享账号；在固件中内置安全审计日志模块，记录所有要求的事件类型，并对日志文件设置写保护（操作员权限不能覆盖或清空日志）；配置会话超时（SR 2.6 要求）；提供 syslog 或等效 API 供船载 SIEM 对接；实现日志功能健康监控，当日志落地失败时触发告警（可以是设备面板警告、SNMP trap 或发往 SIEM 的心跳丢失信号）。

失分点三：厂家 VPN 直连——无审批、无审计的后门（FR2 / FR5）

远程维护是现代船载 OT 不可回避的现实：制造商工程师需要从岸上远程诊断设备故障，软件供应商需要推送更新。问题在于，大量设备预置了厂家专属的 VPN 客户端或远程管理通道，该通道默认开启、不需要船方批准即可建立连接，且连接记录完全由厂家一侧保留，船方没有任何可见性。这样的远程通道实际上是一条无人看守的后门：理论上任何能获得 VPN 凭据的人都可以在船员不知情的情况下进入关键控制系统。

这个问题对应 IEC 62443-3-3 FR2「使用控制」和 FR5「受限数据流」下的多条 SR。SR 2.1「授权执行」要求对所有远程访问实施授权控制；SR 2.4「移动代码的使用控制」以及 FR5 下的 SR 5.1「网络分段」和 SR 5.2「区域边界保护」要求在 OT 网络边界建立受控的数据流，未经授权的对外连接必须被阻断。UR E27 的 11 项「不可信网络连接附加能力」正是针对此场景：凡是经由不可信网络（包括厂家 VPN、卫星宽带、蜂窝网络）接入的通道，均需满足额外的会话授权、数据流限制和审计要求。Pen Test Partners 提醒，「以物理访问控制弥补缺失的技术控制」这一论点常被误用、会被审查员审慎质疑——不能因为设备在机舱锁着就免除网络层的认证与审计义务（单一来源）。

审查员具体关注：远程维护通道是否只能由船方（而非厂家）发起建立（即「主动拨出」模型，优于被动监听）？每次远程会话是否需要船方管理员明确审批？会话内容（操作日志、传输文件）是否在船方可访问的系统中留有记录？会话能否随时由船方单方面切断（「杀开关」）？通道是否提供边界隔离，防止远程工程师从维护接口横向移动至其他系统？

整改路径：引入「远程维护安全网关」（Secure Remote Access Gateway），将所有厂家远程连接统一经由此网关中转。网关应实现：会话发起需船侧批准（审批工作流）；全程录屏和操作日志留存在船侧；船侧可一键断开所有远程会话；网关与 OT 网络之间的边界隔离（仅允许特定设备 IP 和端口的点对点数据流，禁止横向访问）；所有会话记录纳入审计日志（对接 FR6 需求）。在设备固件层面，应默认关闭任何预置的厂家直连通道，仅在明确配置后才允许激活。

失分点四：补丁与更新管理——操作系统老化与安全功能盲区（FR3）

补丁管理不仅是技术问题，更是 UR E27 对供应商的管理体系义务：Rev.1 明确要求供应商建立流程，主动向用户通报安全更新，包括（a）如何传达与新版操作系统 / 固件的兼容性信息，以及（b）如何管理「不应用更新」所带来的风险。这是一项文件和流程要求，不只是固件技术特性。DNV 型式认可流程会审计供应商的安全开发流程，验证其是否符合 UR E27 §4–5 以及 IEC 62443-4-1（安全产品开发生命周期），据 DNV 官方服务页面说明。

现实中最严峻的挑战是操作系统老化。根据 Marlink 数据（由 Bridewell Consulting 2025 年报告引用）：超过 40% 的海事 OT 系统在彼时仍在运行 Windows 10，而该版本已于 2025 年 10 月终止支持。这一数字由 Marlink 的遥测数据采集，Bridewell 将其用于分析海事行业的网络暴露面，是目前公开可查的最佳估算，但不应解读为行业全面普查结论，以 Marlink 和 Bridewell 的原始报告为准。更为极端的情况在船上实际存在：Pen Test Partners 和 Riviera Maritime Media 等机构的船载安全评估中发现，部分 ECDIS（电子海图显示与信息系统）运行的是微软已于 2014 年停止支持的 Windows XP，甚至更古老的 Windows NT，这类系统完全没有可用的补丁路径，若不经制造商重新认证就无法升级。

IEC 62443-3-3 在系统完整性层面（FR3）通过 SR 3.3「安全功能验证」要求：在测试阶段和维护程序中，IACS 应验证所有安全功能是否正常工作，并报告所有偏差。这一要求在实践中意味着：如果设备上的杀毒软件被禁用、日志进程崩溃、固件签名校验失败，设备应能探测到这些异常并通知操作员。ure27.com 指出，这是设备经常无法满足的盲区——大多数嵌入式 OT 产品没有内置的安全功能健康自监控机制（单一来源，该具体描述）。

审查员关注点：供应商是否有产品安全公告发布渠道（PSIRT 或等效机制）？产品文档中是否声明了 OS / 固件的终止支持日期（EoL 声明）？固件更新是否使用密码学签名验证（IEC 62443-4-2 组件要求）？设备是否提供安全功能健康状态报告？供应商是否提供完整的 CBS 资产清单 / 软件物料清单（SBOM，对应 SR 7.8 和 IEC 62443-4-1 要求）？

整改路径：建立产品安全公告发布机制（PSIRT），定期通知用户已知漏洞和可用补丁；在产品说明书中明确声明所有预装软件的 EoL 日期，以及在无法直接升级时的风险处置指导；实现固件更新包的密码学签名，设备在安装前校验签名；提供安全功能健康监控（看门狗式机制），当关键安全进程故障时触发告警；以 CycloneDX 或 SPDX 格式提供机器可读的 SBOM，并在每次固件更新后同步更新。

失分点五：备份缺失与可用性设计不足（FR7）

FR7「资源可用性」在 IEC 62443-3-3 中涵盖了从拒绝服务防护到备份恢复的完整可用性链，对船载 OT 尤为关键：船只在海上无法获得岸基支援，一旦关键系统因网络事件或配置损坏而无法恢复，后果直接影响航行安全。然而，这一能力族在送审时往往是最被低估的失分点——厂商通常重视认证和访问控制（FR1/FR2），而将可用性和备份视为「运营问题」留给船方解决，这种假设与 E27 的要求相悖。

FR7 下的关键 SR 逐条梳理（依据 Shieldworkz、TeepTrak、UpGuard 二次来源，规范性文本以 IEC 62443-3-3:2013 为准）：SR 7.1「拒绝服务防护」要求 IACS 在受到 DoS 攻击时能以预先确定的降级模式运行，且在降级状态下授权维护人员仍能访问系统；SR 7.2「资源管理」要求系统管理资源分配，防止资源耗尽；SR 7.3「控制系统备份」要求始终保持最新备份，使系统在发生故障或错误配置时能够完全恢复，审计日志和其他取证数据也应纳入备份；SR 7.4「控制系统恢复与重建」要求系统工作流能确保系统在故障后迅速恢复到安全状态；SR 7.7「最小功能」要求限制不必要的功能（与失分点一的端口管理交叉）；SR 7.8「控制系统组件清单」要求维护组件级资产清单（与 SBOM 要求交叉）。

审查员会具体验证什么？首先是 SR 7.1：设备能否在文档中明确说明其「预先确定的降级模式」行为——当网络饱和或 DoS 攻击发生时，设备继续提供哪些核心功能、放弃哪些非关键功能？很多厂商对此没有任何书面定义，甚至没有做过相关测试。其次是 SR 7.3 和 SR 7.4：是否存在经过实际验证的备份与恢复流程，并留有测试记录？「我们可以备份」和「我们已经验证了恢复流程、留有执行记录」是两回事，E27 要求的是后者。Shieldworkz 明确指出，SL2 实施层面通常需要有文档记录的 RTO / RPO 目标，以及经过测试的日 / 周 / 月备份程序。第三是 SR 7.1 降级模式下的可维护性：授权维护人员在系统降级期间是否仍能访问系统执行诊断？

整改路径：（1）在产品设计规范中明确定义降级模式行为（SR 7.1），并在 FAT / 出厂测试中进行测试并记录；（2）实现有额定输入队列限制的网络协议栈，防止单个恶意数据包或网络风暴耗尽设备资源（SR 7.2）；（3）提供签名保护的备份 / 恢复工具，配套文档化的操作程序，定义明确的 RTO/RPO 目标，并要求厂方在发货前完成至少一次完整的恢复演练并留存记录（SR 7.3 / SR 7.4）；（4）以 CycloneDX 或 SPDX 格式发布机器可读 SBOM，在备份中包含审计日志（SR 7.3 的取证数据要求 + SR 7.8）；（5）出厂默认关闭所有非业务必需的端口和服务（SR 7.7），并在产品技术规范中逐一列明开放服务清单及业务理由。

失分点五之外：送审证据体系的完整性

五大技术失分点之外，还有一类「程序性」失分点频繁出现：技术能力其实不差，但送审文件体系残缺，审查员无从核实。UR E27 Rev.1 §3.1 规定了送审材料的构成要求，通常涵盖约 10 类文件：资产与软件清单（SBOM / CBS 资产清单）、网络拓扑图、数据流图、风险评估报告、安全测试报告、合规声明（DoC）、配置基线记录、补丁管理流程文件、安全意识培训记录，以及产品安全功能描述文档。任何一类缺失或内容不足，审查员都会发出技术疑问（TQ）要求补充，延误审查进度，情节严重时直接驳回。

常见的证据不足模式：（a）网络拓扑图只画了设备级别的连接，没有标注通信协议、端口号和数据流方向，审查员无法核实边界隔离措施是否到位；（b）安全测试报告只有功能测试，缺乏渗透测试或漏洞扫描记录，也没有说明测试范围边界；（c）SBOM 只列出第三方库，没有包含操作系统镜像中预置的系统组件；（d）合规声明仅做定性陈述（「我们符合 IEC 62443-3-3 SR 1.1」），缺乏与测试记录的交叉引用，无法为审查员提供可追溯的证据链。ure27.com H2 2025 综述明确指出，E27 型式认可的失败案例中，集成后的船级合规同样不自动成立——即便每台设备单独通过了型式认可，集成进实际船载网络架构后仍需由船厂和船级社分别验证系统级合规性。这个教训对设备厂商的启示是：证据文件从一开始就要为系统集成预留接口，说明设备如何被安全地集成进更大的 CBS 架构，而不是仅描述设备本身。

这份清单帮你少走弯路，但它不替代正式差距评估；具体定级与通过与否，以船级社审查为准。