IT/OT 融合架构下的工业控制系统安全攻防实战研究

1. 引言

随着工业 4.0 和智能制造的浪潮席卷全球，信息技术 (IT) 与运营技术 (OT) 的融合已成为不可逆转的趋势。这种融合旨在通过实时数据交换和分析，打破传统的信息孤岛，显著提升生产效率、优化决策、降低运营成本并增强市场竞争力。IT 系统负责数据处理与信息管理，而 OT 系统则直接控制物理设备和工业流程。二者的结合为制造业带来了前所未有的机遇，例如实现预测性维护、自动化流程优化以及更紧密的供应链协同。

然而，IT 与 OT 的深度融合也打破了传统 OT 环境物理隔离或“气隙”的安全假设，引入了严峻的网络安全挑战。原本为孤立环境设计的 OT 系统，其安全防护能力往往难以应对来自 IT 网络甚至互联网的现代网络威胁。攻击者可以利用 IT 网络的开放性作为跳板，横向移动至 OT 网络，对关键生产设备和流程造成破坏，甚至引发安全事故。此外，IT 与 OT 在技术架构、安全优先级（IT 重保密性，OT 重可用性与安全性）、管理文化、人员技能以及系统生命周期等方面存在的巨大差异，也给融合环境下的安全管理带来了巨大障碍。

本文旨在深入研究 IT/OT 融合架构下的网络安全攻防实战，聚焦于制造业环境。我们将重点分析纵深防御体系在 PLC (可编程逻辑控制器)、SCADA (监控与数据采集系统) 和 MES (制造执行系统) 等关键工控系统中的安全加固实践；探讨 S7comm 等典型工控协议存在的安全漏洞及其挖掘与利用方法；评估零信任架构 (ZTA) 在 IT/OT 融合环境中的落地可行性与实践案例；并结合当前制造业面临的严峻勒索软件攻击态势，提出一套具有可操作性的应急响应标准操作程序 (SOP)。通过对这些关键领域的探讨，旨在为制造企业在 IT/OT 融合背景下构建更具韧性的网络安全防护体系提供参考。

2. IT/OT 融合架构与安全风险

2.1 IT/OT 融合的核心概念与特征

IT/OT 融合的核心在于整合管理企业数据和信息的 IT 系统与控制物理过程和工业操作的 OT 系统，实现两者之间实时、无缝的数据流动与协同工作。这种融合的目标是通过利用 IT 的数据分析、计算能力和连接性来优化 OT 的物理流程，从而带来显著的业务价值。

其主要特征和驱动力包括：

• 提升运营效率： 通过实时数据分析和监控，加速决策响应，优化生产流程，提高制造、运输等行业的整体效率。
• 降低成本： 融合使得预测性维护和自动化成为可能，通过预先识别潜在设备故障，减少意外停机和维护开销。
• 改进决策制定： 全面、实时的运营数据为管理层提供更清晰的洞察，使决策更加精准，更好地匹配市场需求和企业目标。
• 加强风险管理与合规性： 提升运营可见性有助于满足日益严格的行业法规和安全标准，实时监控和审计便于识别和缓解风险。
• 促进创新与竞争力： 数据驱动的洞察力能够发掘新的解决方案和市场机遇，推动企业创新，保持竞争优势。
• 实现全面可见性： 打破信息孤岛，提供对流程、人员、技术和治理模型的端到端可见性。

2.2 常见的 IT/OT 集成架构模式 (Purdue 模型及其演进)

Purdue 模型及其传统安全理念

Purdue 企业参考架构 (Purdue Model) 是描述工业控制系统 (ICS) 层级结构最常用的模型之一。该模型将工业网络划分为不同的逻辑层级，从底层的物理过程 (Level 0) 到顶层的企业网络 (Level 5)，旨在通过网络分段和隔离来保护关键的 OT 系统。

• Level 0: 物理过程 (Physical Process): 实际的生产设备、传感器、执行器等。
• Level 1: 基本控制 (Basic Control): PLC、RTU 等直接控制物理过程的设备。
• Level 2: 区域监控 (Area Supervisory Control): SCADA、HMI 等监控和操作 Level 1 设备的系统。
• Level 3: 生产运营管理 (Manufacturing Operations Management): MES 等系统，负责生产调度、工作流管理。
• Level 3.5: 工业隔离区 (Industrial Demilitarized Zone - iDMZ): 通常设置在 IT 和 OT 网络之间，作为缓冲区，控制两个区域间的数据流，部署有防火墙、代理服务器等安全设施。
• Level 4: 业务规划与物流 (Business Planning & Logistics): ERP、数据库等企业级 IT 系统。
• Level 5: 企业网络 (Enterprise Network): 公司 IT 网络，连接互联网。

传统上，Purdue 模型的核心安全理念是隔离，即通过严格的网络分段，特别是利用 iDMZ 将 OT 网络 (Level 0-3) 与 IT 网络 (Level 4-5) 分开，阻止来自 IT 网络的威胁直接触达关键的工业控制系统。防火墙是实现这种隔离的关键工具，用于阻止或严格限制 IT 与 OT 之间的直接通信。

融合带来的挑战与 Purdue 2.0 的演进

随着 IT/OT 融合的深化，传统的严格隔离模型面临巨大挑战。为了实现数据共享和远程访问等业务需求，IT 与 OT 之间的连接日益增多，模糊了 Purdue 模型各层级间的界限。这种互联互通使得攻击者可以利用 IT 网络的漏洞横向移动到 OT 环境，绕过传统的边界防御。此外，工业物联网 (IIoT)、云计算等新技术的应用，进一步加剧了 OT 环境的暴露风险。

为了应对这些挑战，Purdue 模型也在不断演进，出现了 Purdue 2.0 的概念。Purdue 2.0 并非一个严格定义的标准，而是代表了对传统模型进行现代化改造的思路，其核心变化包括：

• 承认 IT/OT 融合： 认识到 IT 与 OT 网络的互联互通是常态，重新定义层级间的边界，允许更灵活、安全的数据交换。
• 强调零信任架构 (ZTA)： 不再仅仅依赖网络边界的隔离，而是引入 ZTA 原则，对任何访问请求（无论来自内部还是外部）都进行持续的身份验证和授权，并实施最小权限访问控制。这一点是 Purdue 2.0 的关键演进，标志着安全理念从“信任但验证”转向“从不信任，始终验证”，这对于保护日益模糊的 IT/OT 边界至关重要。因为在融合环境下，无法再假定内部网络是可信的，必须对每一次访问都进行严格审查。
• 适应云和 XIoT 集成： 明确将云计算服务、IIoT 设备以及其他扩展物联网 (XIoT) 纳入考虑范围，并提供相应的安全建议。
• 优先实时威胁检测： 强调在所有层级部署实时监控和异常检测能力。
• 更细粒度的安全控制： 在每个层级实施更精细的安全措施，包括设备级安全、网络微分段、安全区域 (Enclaves) 和应用级保护。
• 对齐现代安全标准： 与 NIST CSF、IEC 62443、零信任框架等现代安全标准和框架保持一致。

Purdue 2.0 的出现，本质上是对传统 Purdue 模型在现代高度互联工业环境下安全防护能力不足的回应。它试图在保留结构化分层优势的同时，融入更适应动态威胁环境的现代安全策略，特别是零信任的引入，为保护融合后的 IT/OT 环境提供了新的思路。

2.3 融合带来的特定安全风险与脆弱性

IT/OT 的融合在带来效率提升的同时，也显著增加了网络安全风险，暴露出许多新的脆弱性：

• 攻击面显著扩大： IT 与 OT 系统的互联，以及与供应商、客户网络的连接，打破了原有的物理或逻辑隔离，使得潜在的攻击入口急剧增加。攻击者可以更容易地从安全性相对较弱的 IT 网络渗透到关键的 OT 系统。SANS 2024 年的一项调查发现，近 50% 的 OT 资产攻击最终可归因于 IT 网络泄露。
• 遗留系统脆弱性： 大量 OT 系统（如 PLC、SCADA）设计于数十年前，当时并未充分考虑网络安全，缺乏现代加密、认证等安全机制。这些系统通常运行着过时的操作系统或固件，难以或无法修补已知漏洞，且生命周期长达数十年，更换成本高昂。这种普遍存在的遗留系统构成了 IT/OT 融合的主要安全瓶颈。它们的设计初衷是为了在隔离环境中稳定运行，而非在互联网络中抵御攻击。当这些系统被接入融合网络时，其固有的脆弱性便暴露无遗，成为攻击者利用的“短板”。加固或替换这些系统往往面临巨大的成本和停机风险，形成了提升安全与保障运营连续性之间的两难困境。
• 工控协议不安全： 许多传统的工控协议（如 Modbus, Profibus, S7comm 等）缺乏加密和认证机制，数据以明文传输，容易被窃听、篡改和重放攻击。
• 数据不兼容与组织孤岛： IT 与 OT 系统使用的数据格式和通信协议往往不同，加上组织结构上 IT 和 OT 部门长期存在的隔阂，导致数据难以整合，形成安全监控的盲点。
• 技能差距与文化冲突： IT/OT 融合需要具备跨领域知识的复合型人才，而现实中往往存在技能缺口。IT 和 OT 团队在安全理念（IT 重保密，OT 重可用/安全）、风险容忍度、工作流程和沟通方式上也存在显著差异，这种文化冲突是阻碍安全有效融合的关键因素。缺乏跨领域知识的人员和固有的部门隔阂，会直接导致安全策略理解偏差、执行不到位、风险识别遗漏以及应急响应效率低下，其影响不亚于技术层面的挑战。
• 供应链风险： OT 系统的供应链涉及众多软硬件供应商和服务提供商。这些第三方环节可能存在安全漏洞，成为攻击者渗透的入口点。例如，供应商提供的软件更新或硬件设备可能被预先植入恶意代码。
• 物理安全与网络安全的交织： OT 系统直接控制物理设备，网络攻击可能导致物理世界的破坏、生产中断甚至人员伤亡，其后果远超传统 IT 安全事件。
• 管理复杂性增加： 融合环境下的资产数量庞大（OT 资产可能远超 IT 资产）、地域分布广泛、系统异构性高，给统一的资产管理、访问控制（RBAC）、漏洞管理和事件响应带来了巨大挑战。

应对这些风险，需要采取多层次、纵深防御的安全策略，并结合持续的风险评估和管理。

3. 纵深防御体系：PLC、SCADA、MES 安全加固

纵深防御 (Defense-in-Depth) 是一种核心的网络安全策略，旨在通过部署多层、冗余的安全控制措施来保护信息系统和关键资产。其理念是，即使某一层防御被突破，其他层次的防护依然能够阻止或延缓攻击，从而最大限度地降低风险。在 IT/OT 融合环境中，由于攻击面扩大和 OT 系统的特殊性，纵深防御显得尤为重要。它不仅仅依赖于边界防护（如防火墙），更强调在网络内部、主机层面以及应用层面实施多重安全控制。

3.1 PLC 安全加固实践

PLC 作为工业控制系统的核心，直接控制物理过程，其安全性至关重要。PLC 的安全加固应遵循纵深防御原则，并结合 IEC 62443 等工业安全标准。

• 访问控制与身份认证：
  • 强密码策略： 避免使用默认密码，强制要求复杂密码，并定期更换。
  • 多因素认证 (MFA)： 对访问 PLC 进行编程、配置或维护的操作强制实施 MFA。
  • 基于角色的访问控制 (RBAC)： 根据用户角色（如操作员、工程师、管理员）分配最小必要权限。西门子 TIA Portal 提供了用户管理和访问控制功能，允许设置不同的保护级别（Protection levels）和功能权限，限制对 CPU 功能、代码块和数据的访问。例如，可以设置密码保护，防止未经授权的程序下载或修改。
  • 物理访问控制： 限制对 PLC 机柜和编程端口的物理访问。
• 固件更新与补丁管理：
  • 及时更新 PLC 固件和工程软件（如 TIA Portal）至最新版本，以修复已知漏洞。
  • 建立严格的补丁管理流程，在部署前进行充分测试，评估对运行稳定性的影响，并选择合适的停机窗口进行更新。对于无法及时打补丁的遗留系统，应采取补偿性控制措施（如网络隔离）。
• 代码/逻辑保护：
  • Know-how Protection (专有技术保护)： 利用工程软件（如 TIA Portal）提供的功能，对关键的程序块进行加密或设置密码保护，防止知识产权泄露和未经授权的代码复制或修改。
  • Copy Protection (复制保护)： 某些 PLC 提供绑定到特定硬件（如存储卡或 CPU 序列号）的复制保护功能，防止程序被非法拷贝到其他设备。
  • 安全编码实践： 在编写 PLC 程序时，遵循安全编码规范，避免引入逻辑漏洞。
• 网络安全：
  • 网络分段： 将 PLC 放置在独立的、受防火墙保护的网络段（Zone）中，严格限制与其他网络（尤其是 IT 网络）的通信。使用 DMZ 隔离需要与 IT 系统交互的应用。
  • 通信加密与认证： 尽可能使用支持加密和认证的通信协议。对于不支持加密的传统协议，考虑使用 VPN 或其他隧道技术进行保护。西门子 S7comm+ 协议相较于 S7comm 增加了加密机制。
  • 入侵检测系统 (IDS)： 部署能够识别工控协议异常流量的 IDS，监控针对 PLC 的恶意活动。
• 系统完整性保护：
  • 配置锁定： 锁定 PLC 的配置，防止未经授权的更改。
  • 安全日志与监控： 启用 PLC 的安全日志功能，并将日志发送到中央 SIEM 系统进行分析和告警。
  • 基线核对： 定期核对 PLC 的配置和程序与已知的良好基线，检测未经授权的修改。
• 符合 IEC 62443 标准：
  • 遵循 IEC 62443 系列标准的要求进行风险评估、区域划分 (Zones and Conduits)、安全级别 (Security Levels) 定义以及安全控制措施的实施。例如，IEC 62443-4-2 规定了 IACS 组件（包括 PLC）的技术安全要求。

3.2 SCADA 系统安全加固 (以 Wonderware/AVEVA 为例)

SCADA 系统作为监控和管理人机交互的核心，是攻击者获取系统控制权或干扰生产的重要目标。其安全加固同样需要采用纵深防御策略。以 Wonderware (现 AVEVA) 系统为例，常见的加固措施包括：

• 网络分段与隔离： 这是保护 SCADA 系统的基础。
  • IT/OT 隔离： 使用防火墙和 DMZ 将 SCADA 网络（通常位于 Purdue Level 2/3）与企业 IT 网络 (Level 4/5) 严格隔离。
  • 内部微分段： 在 SCADA 网络内部，根据功能或关键性进一步划分区域 (Zones)，例如将 HMI 工作站、历史数据库、I/O 服务器置于不同网段，并使用防火墙或 VLAN 限制它们之间的通信，阻止攻击者在 SCADA 网络内部横向移动。AVEVA 推荐的网络架构也体现了这种分层分段的思想。
• 强认证与访问控制：
  • 强密码策略： 为所有 SCADA 系统账户（操作系统、数据库、应用软件）设置复杂密码，并强制定期更换。
  • 多因素认证 (MFA)： 对所有访问 SCADA 系统的用户，特别是具有高权限的用户和远程访问用户，强制启用 MFA。
  • 最小权限原则与 RBAC： 根据用户角色（操作员、工程师、管理员）分配最小必要权限。AVEVA System Platform 提供了基于角色的安全模型，允许定义安全组、角色和用户，精细控制对对象、功能和数据的访问权限。
  • 操作系统用户组安全： AVEVA InTouch HMI 支持基于操作系统用户组的安全模式，可以将 Windows 用户组映射到 InTouch 的访问级别。
• 系统加固：
  • 禁用不必要的服务和端口： 关闭 SCADA 服务器和工作站上非必需的操作系统服务、应用程序和网络端口，减少攻击面。
  • 移除默认账户和凭证： 更改或禁用所有默认的用户名和密码。
  • 安全配置： 遵循 AVEVA 提供的安全配置指南和最佳实践，例如安全配置 DCOM 设置。
  • 物理安全： 限制对 SCADA 服务器、工作站和网络设备的物理访问。
  • 外设控制： 控制 USB 等可移动介质的使用，防止通过物理介质引入恶意软件。
• 安全通信：
  • 加密传输： 尽可能使用加密协议（如 TLS/SSL）保护 SCADA 系统各组件之间以及与外部系统（如数据库、PLC）的通信，防止数据被窃听或篡改。
  • 协议安全： 避免使用不安全的协议，对使用的协议进行安全评估。
• 补丁管理与软件更新：
  • 及时更新： 建立严格的流程，及时安装操作系统（通常是 Windows）和 AVEVA 软件的安全补丁。AVEVA 会对其产品进行微软补丁的兼容性测试，并通过其支持门户发布结果。
  • 测试验证： 在生产环境部署补丁前，在测试环境中进行充分验证，确保兼容性和稳定性。
• 监控与日志审计：
  • 启用日志记录： 配置 SCADA 系统、操作系统和网络设备记录详细的安全事件日志。AVEVA System Platform 支持记录安全写入 (Secured and Verified Writes) 操作，提供审计追踪。
  • 集中日志管理 (SIEM)： 将所有相关日志发送到 SIEM 系统进行集中存储、关联分析和实时告警。
  • 入侵检测/防御 (IDS/IPS)： 部署 IDS/IPS 监控 SCADA 网络流量，检测异常活动和已知攻击特征。
• AVEVA 安全开发生命周期 (SDL) 与安全模型： AVEVA 遵循严格的 SDL 流程来开发其 HMI/SCADA 产品，该流程符合 ISA/IEC 62443-4-1 标准，并获得了 ISASecure SDLA 认证。这包括安全培训、威胁建模、安全编码、静态/动态代码分析、渗透测试等环节，旨在从源头上减少产品漏洞。同时，AVEVA 提供安全模型文档，指导用户如何在其产品（如 System Platform）中配置安全功能。

网络分段是 SCADA 系统加固的基石。通过将 SCADA 网络与 IT 网络隔离，并在内部进行细分，可以有效限制攻击的传播范围。即使攻击者突破了外围防御，分段也能阻止其轻易访问所有关键组件。这在遗留设备难以直接加固的环境中尤为重要，分段可以作为一种有效的补偿性控制措施。

同时，供应商的安全实践与用户的正确配置同样重要。AVEVA 通过其 SDL 流程提供了相对安全的产品基础，但最终系统的安全性高度依赖于资产所有者或系统集成商是否遵循了最佳实践，如正确配置访问控制、及时应用补丁、实施有效监控等。安全是一个需要供应商和用户共同承担责任的持续过程。

3.3 MES 系统安全加固

MES 作为连接上层 ERP 系统和底层车间控制系统 (PLC/SCADA) 的关键枢纽，处理着大量的生产指令、实时数据和质量信息，其安全性直接关系到生产计划的执行、产品质量和可追溯性。MES 的安全加固需要关注数据保护、访问控制和系统集成安全。

• 数据完整性与机密性：
  • 数据加密： 对传输中和静态存储的敏感生产数据（如配方、工艺参数、质量记录）进行加密，防止数据泄露或被篡改。使用 SSL/TLS 等安全协议保护网络通信。
  • 数据校验： 使用校验和 (Checksums) 或哈希函数 (如 SHA-256) 验证数据的完整性，确保数据在传输或存储过程中未被修改。
• 基于角色的访问控制 (RBAC)： 这是 MES 安全的核心。
  • 角色定义： 根据制造环境中的不同职责（如操作工、班组长、质量检验员、工艺工程师、系统管理员）定义清晰的角色。
  • 最小权限分配： 为每个角色分配完成其工作所需的最小权限集。例如，操作工只能查看工单、录入产量，不能修改工艺参数或访问财务数据；质量检验员可以录入检验结果，但不能修改生产计划。
  • 强认证 (MFA)： 对访问 MES 系统的用户，特别是高权限用户，应强制实施 MFA，增加账户被盗用的难度。
  • 定期审计： 定期审查和更新用户角色及权限分配，移除不再需要的访问权限，确保权限与实际职责匹配。
  • 重要性： MES 作为 IT 与 OT 的关键桥梁，其访问控制的失误可能直接导致生产指令错误、工艺参数被篡改、质量数据造假等严重后果，进而引发生产中断、产品质量问题甚至安全事故，其影响远超传统 IT 系统的数据泄露。因此，在 MES 中严格实施 RBAC 至关重要。
• 安全架构与集成：
  • 模块化与分层设计： 采用模块化、分层的 MES 架构，将核心业务逻辑、数据存储、用户界面和集成接口分开，便于独立保护和管理。
  • 安全接口： 确保 MES 与上层 ERP、下层 PLC/SCADA 以及其他系统（如 PLM, QMS）的集成接口安全可靠。使用安全的通信协议（如 OPC UA、HTTPS API）和认证机制。
  • 网络隔离： 将 MES 服务器部署在受保护的网络区域（如 DMZ 或生产控制网内部），并使用防火墙限制对其的访问。
• 审计与监控：
  • 详细审计日志： 记录所有用户登录、关键操作（如参数修改、工单下达）、系统配置更改等活动，形成完整的审计追踪。
  • 实时监控： 监控 MES 系统的性能、可用性和安全事件，及时发现异常行为或潜在攻击。将 MES 日志整合到 SIEM 系统进行统一分析。
• 备份与恢复：
  • 定期备份： 定期备份 MES 数据库和应用程序配置。
  • 灾难恢复计划： 制定并测试 MES 系统的灾难恢复计划，确保在发生故障或攻击时能够快速恢复生产运营。

通过实施这些加固措施，可以显著提升 MES 系统的安全性，保护关键生产数据和流程的完整性与可用性。

4. 工控协议漏洞挖掘与利用

工业控制系统（ICS）依赖各种专用协议进行通信，如 Modbus、Profibus、Ethernet/IP、Profinet 以及西门子专有的 S7comm/S7comm+ 等。然而，许多传统工控协议在设计之初并未充分考虑安全性，导致其普遍存在安全弱点，成为攻击者利用的目标。

4.1 常见工控协议 (如 S7comm) 的安全弱点

以广泛应用于西门子 S7 系列 PLC 的 S7comm 协议为例，其存在的典型安全弱点包括：

• 缺乏加密： 标准的 S7comm 协议（协议号 0x32）传输的数据是明文的，未经加密。这意味着任何能够访问网络的攻击者都可以轻易地嗅探到通信内容，包括敏感的控制指令和过程数据。
• 缺乏认证： S7comm 协议本身不包含有效的认证机制来验证通信双方（如 HMI 与 PLC）的身份。攻击者可以伪造合法的设备身份，向 PLC 发送恶意指令。
• 易受重放攻击： 由于缺乏有效的会话管理和消息认证机制，攻击者可以截获合法的通信报文，并在稍后重新发送，以触发非预期的操作。
• 易受欺骗攻击： 攻击者可以伪造源地址或协议字段，冒充合法设备发送指令或响应。
• 易受拒绝服务 (DoS) 攻击： 向 PLC 发送特殊构造的畸形报文或大量无效请求，可能导致 PLC 处理异常、资源耗尽或进入停止模式，从而中断生产。例如，CVE-2015-2177 描述了向 S7-300 CPU 的 102 端口发送特定报文可导致其进入缺陷模式，需要冷重启恢复。
• 潜在的内存破坏漏洞： 协议解析逻辑中可能存在漏洞，如缓冲区溢出。攻击者通过发送精心构造的、包含超长数据或非法参数的报文，可能触发 PLC 或 HMI 软件的内存错误，轻则导致 DoS，重则可能实现远程代码执行 (RCE)。S7 PDU 包含多个可变长度字段，其复杂的编码方式为缓冲区溢出提供了可能。CISA 近期发布的 ICSA-24-102-01 提到了 S7-1500 中的多个漏洞，包括可能导致堆缓冲区溢出的问题。

这些弱点的根源在于传统工控协议设计时，主要目标是确保通信的实时性、可靠性和可用性，而安全性往往被置于次要地位，甚至被完全忽略。在过去物理隔离的环境下，这些弱点的影响有限。但在 IT/OT 融合、网络互联的背景下，这些协议固有的不安全性成为了巨大的风险敞口，使得仅通过网络层面的访问就可能实现对工业过程的直接控制或破坏。

4.2 S7comm/S7comm+ 协议分析与逆向工程

为了挖掘和利用 S7comm 及其后续版本 S7comm+ 的漏洞，安全研究人员需要对其进行深入分析和逆向工程。

• 分析工具：
  • Wireshark： 是网络流量分析的基础工具。Wireshark 内置了对 S7comm (基于 ISO-on-TCP, RFC1006, 端口 102) 协议的解析器 (Dissector)，可以直接解析 S7comm 报文结构，包括协议头、功能码、参数和数据等。对于加密的 S7comm+ (协议号 0x72)，虽然无法直接看到明文数据，但可以通过观察报文交互顺序、长度、特定字段（如 PDU 类型、序列号、会话 ID）来理解其通信流程和协议状态机。也有社区开发的 S7comm+ Wireshark 插件可供使用。
  • 逆向工程工具 (WinDbg, IDA Pro)： 对于理解 S7comm+ 的加密算法和内部逻辑至关重要。由于 S7comm+ 的加密算法是西门子的私有实现，通常位于 TIA Portal 的相关 DLL 文件中（如 OMSp_core_managed.dll），研究人员需要使用：
    • 动态调试器 (WinDbg)： 通过在 TIA Portal 运行时设置断点、观察内存和寄存器状态，可以追踪加密函数的输入、输出和执行流程，从而推断算法逻辑和关键参数。
    • 静态反汇编/反编译器 (IDA Pro)： 对目标 DLL 文件进行静态分析，理解代码结构，识别加密、解密、密钥处理等关键函数，并尝试还原其算法细节。
  • 模糊测试 (Fuzzing) 工具： 如 Netzob, Boofuzz, M-Peach 等，可以通过向目标 PLC 发送大量半随机或变异的 S7comm/S7comm+ 报文，来探测协议解析逻辑中的漏洞，特别是内存破坏类漏洞。
• 分析方法：
  • 流量捕获与分析： 使用 Wireshark 捕获 TIA Portal 与 PLC 之间的正常通信流量（如连接建立、程序下载、启动/停止、变量读写），分析报文序列和结构。
  • 协议状态机推断： 基于捕获的流量，推断协议的有限状态自动机 (DFA) 模型，理解不同状态下的合法消息序列。
  • 字段语义分析： 识别报文中关键字段的含义和作用，如功能码、参数长度、数据地址等。
  • 加密算法逆向： 结合动态调试和静态分析，破解 S7comm+ 的加密算法，理解密钥交换和消息认证过程。研究发现 S7comm+ 的加密涉及 XOR 运算和更复杂的私有算法，并使用了会话 ID 等机制。

4.3 漏洞利用示例 (基于公开研究)

通过对 S7comm/S7comm+ 的分析，研究人员已发现并公开演示了多种漏洞利用方式：

• 拒绝服务 (DoS)：
  • 协议滥用： 发送大量请求或特定功能码的报文，耗尽 PLC 资源。
  • 畸形报文： 发送格式错误或参数异常的报文，触发 PLC 解析错误导致崩溃或进入停止模式。CVE-2015-2177 就是通过向 S7-300 的 102 端口发送特定构造的报文实现的 DoS。近期针对 S7-1500 的漏洞 (如 CVE-2023-5678, CVE-2024-0727) 也可能导致 DoS。
• 未经授权的 PLC 控制：
  • S7comm (无加密/认证)： 攻击者可以直接发送 Start/Stop PLC、Read/Write Memory/Data Block、Download Program 等功能码的报文，实现对 PLC 的完全控制。
  • S7comm+ (加密破解后)： 在逆向工程破解了 S7comm+ 的加密算法后，攻击者可以构造合法的加密报文，同样实现对 PLC 的启动、停止、输入输出值修改等控制。Black Hat 上的演示就包括编写 MFC 程序来控制 S7-1200。
• 中间人 (MitM) 攻击：
  • 会话劫持 (S7comm)： 截获合法的通信会话，并注入恶意指令。
  • 认证绕过 (S7comm+)： 利用协议交互过程中的逻辑缺陷或密钥管理漏洞。例如，研究发现可以通过 MitM 攻击，截获 TIA Portal 与 PLC 之间的认证挑战-响应过程，利用从 PLC 获取的硬编码私钥 (CVE-2022-38465) 来解密客户端信息并伪造响应，从而建立一个具有完全权限的会话，进而可以修改配置、读写程序块，甚至获取 PLC 的密码哈希。另有研究指出 S7comm+ 的完整性保护计算存在缺陷，允许 MitM 攻击者修改流量。
• 内存破坏利用：
  • 远程代码执行 (RCE)： 利用协议解析中的缓冲区溢出或其他内存漏洞，注入并执行恶意代码 (Shellcode)。研究人员曾利用 S7-1200/1500 上的一个内存保护绕过漏洞 (CVE-2020-15782) 实现了 RCE，进而提取了硬编码的私钥。
  • 信息泄露： 触发内存越界读取等漏洞，获取 PLC 内存中的敏感信息，如配置数据、密钥等。

值得注意的是，尽管 S7comm+ 引入了加密，试图提高安全性，但研究表明其加密算法本身可以通过逆向工程被破解，并且其密钥管理机制也存在严重漏洞（如硬编码密钥）。这再次印证了一个观点：仅仅依赖协议层面的加密是不够的，安全需要体系化的纵深防御。如果攻击者能够获得足够的访问权限（例如通过 RCE 或 MitM），协议层的加密往往可以被绕过或破解。

4.4 漏洞披露与 CVE 流程

负责任的漏洞披露对于修复工控系统漏洞、提升整体安全水平至关重要。其一般流程如下：

1. 发现漏洞： 安全研究人员、供应商或用户发现潜在的安全漏洞。
2. 验证与报告： 对漏洞进行验证，确认其存在和影响。然后，将漏洞详情（包括技术细节、复现步骤、潜在影响等）报告给受影响的供应商（如西门子）或指定的协调机构，如网络安全和基础设施安全局 (CISA) 的 ICS-CERT。强烈建议首先联系供应商，并给予其合理的时间（如 5 个工作日）进行响应和修复。
3. 分配 CVE ID： 供应商或协调机构作为 CVE 编号授权机构 (CNA - CVE Numbering Authority)，会对报告的漏洞进行评估。如果确认是新的、可独立修复且影响安全的漏洞，CNA 会为其申请并保留一个唯一的 CVE ID (格式为 CVE-YYYY-NNNN…)。此时，CVE 记录状态为“Reserved”。
4. 漏洞修复与协调披露： 供应商开发修复补丁或缓解措施。披露时间通常由供应商和报告者协商确定，目标是在补丁发布后进行公开披露，以便用户有时间应用修复。
5. 发布 CVE 记录与安全公告： 当漏洞准备好公开披露时，CNA 会发布包含漏洞描述、受影响产品版本、修复方案、参考链接等信息的 CVE 记录。此时，CVE 记录状态变为“Published”。供应商通常也会发布相应的安全公告（如 Siemens Security Advisories），CISA ICS-CERT 也会发布 ICS Advisories。
6. 用户响应： 资产所有者根据发布的 CVE 信息和安全公告，评估自身风险，并及时应用补丁或采取缓解措施。

如果供应商未能及时响应或修复，报告者可以联系第三方协调机构（如 CERT/CC）介入，或在特定条件下（如已给予充分修复时间）在公共平台（如 Bugtraq）进行披露。被拒绝或无效的 CVE ID 会被标记为“Rejected”状态。

这个流程旨在平衡漏洞信息的透明度与用户安全，通过标准化的 CVE ID 促进漏洞信息的共享和管理，最终推动整个工控安全生态系统的改进。公开的漏洞研究和 CVE 披露，虽然可能被恶意利用，但更是驱动供应商修复产品、用户加强防护的重要动力。

5. 零信任架构 (ZTA) 在 IT/OT 融合中的落地

传统的基于边界的安全模型（“城堡与护城河”）在 IT/OT 深度融合、远程访问普及、云应用增多的背景下已显不足。零信任架构 (ZTA - Zero Trust Architecture) 应运而生，它提供了一种新的安全范式，旨在应对现代复杂的网络环境挑战。

5.1 ZTA 核心原则

ZTA 的核心思想是摒弃“信任”假设，基于“从不信任，始终验证” (Never Trust, Always Verify) 的原则来设计和实施安全策略。其关键原则包括：

• 显式验证 (Explicit Verification)： 不基于网络位置（内网或外网）或设备所有权来隐式信任任何用户、设备或应用。每一次访问资源的请求都必须经过严格的身份验证和授权，验证依据应尽可能全面，包括用户身份、设备健康状态、访问位置、服务/工作负载以及数据分类等。
• 最小权限访问 (Least Privilege Access)： 用户和设备仅被授予完成其特定任务所必需的最小访问权限。访问权限应是动态的、基于策略的，并且是按需、按会话授予 (Just-in-Time, Just-Enough Access)。这极大地限制了潜在攻击者获得访问权限后的横向移动能力和破坏范围。
• 假设泄露 (Assume Breach)： 默认假设网络中已经存在威胁，安全防护的目标不仅是阻止入侵，更要能够快速检测、限制和响应已经发生的入侵，最小化安全事件的影响范围（Blast Radius）。

ZTA 并非单一技术或产品，而是一种战略性的安全方法论和架构理念。它的成功实施依赖于多种技术和流程的协同作用。

5.2 ZTA 在 OT 环境的应用挑战与考量

将 ZTA 原则应用于 OT 环境面临独特的挑战：

• 遗留系统兼容性： 大量 OT 设备和系统是“哑”终端，不支持现代认证协议、加密或安装代理软件，难以直接集成到 ZTA 框架中进行身份验证和健康检查。
• 实时性与性能影响： OT 系统对网络延迟和抖动非常敏感，严格的、频繁的身份验证和策略检查过程可能引入不可接受的延迟，影响控制系统的实时性和稳定性。
• 可用性与安全性的平衡： OT 环境的首要任务是确保生产的连续性和安全性。过于严格的 ZTA 策略如果导致合法访问受阻或操作中断，是不可接受的。需要在安全性和运营效率之间找到平衡点。
• 环境特殊性： OT 环境可能存在恶劣的物理条件（高温、粉尘、电磁干扰），对部署额外的网络设备或传感器带来挑战。
• 不同的风险模型： OT 的风险不仅是数据泄露，更关乎物理安全、环境安全和生产连续性，ZTA 策略需要充分考虑这些独特的风险因素。
• 供应商锁定与协议多样性： OT 环境中存在众多供应商和私有协议，实现统一的身份管理和策略执行较为困难。

5.3 关键技术与实践

尽管存在挑战，但 ZTA 的核心原则可以通过多种技术和实践逐步应用于 OT 环境：

• 身份识别与强认证：
  • 统一身份管理 (IAM/PAM)： 建立统一的身份管理平台，整合 IT 和 OT 用户身份。对所有访问 OT 资源的用户（包括员工、承包商、远程用户）实施强认证，特别是 MFA。
  • 设备身份识别/指纹： 对接入网络的 OT 设备进行唯一标识和认证。这可以通过 MAC 地址、设备证书、或更高级的“设备指纹”技术实现。设备指纹技术通过收集设备的软硬件特征（如操作系统版本、浏览器类型、网络配置、甚至行为模式）生成唯一标识符，用于识别和验证设备身份，即使在无法安装代理的设备上也有一定效果。一些 ZTA 解决方案提供“无代理”部署方式，适合无法安装软件的 OT 设备。在安全关键应用中，可以采用“零信任模式”，不在客户端暴露识别 ID (visitorId)，而是返回一个请求 ID (requestId)，由服务器端使用 API 密钥验证后获取真实 ID，增加仿冒难度。Windows Hello for Business 等技术也利用 TPM 和生物识别提供设备和用户强认证。
• 网络分段 (宏观与微观)：
  • 宏观分段： 遵循 Purdue 模型或 IEC 62443 的区域和管道 (Zones and Conduits) 概念，将 IT 和 OT 网络、以及 OT 内部不同功能区域（如控制网、安全仪表系统 SIS）进行隔离。这是 ZTA 在 OT 应用的基础。
  • 微分段 (Micro-segmentation)： 在区域内部，利用防火墙（物理或虚拟）、SDN 或主机防火墙等技术，将网络进一步细分为更小的、独立的段，甚至可以实现“单个设备的段”(segment of one)。微分段是实现 ZTA 最小权限访问和限制横向移动的关键技术。通过定义精细的策略，只允许必要的设备和服务之间进行通信，有效阻止威胁在网络内部蔓延。现代微分段解决方案趋向于自动化策略生成和无代理部署，简化实施难度。
• 策略引擎 (PE) 与策略执行点 (PEP)：
  • 策略引擎 (Policy Engine)： ZTA 的“大脑”，负责根据已定义的策略、实时收集的上下文信息（用户身份、设备状态、位置、时间、风险评分等）做出访问决策。
  • 策略管理员 (Policy Administrator)： 负责配置和管理访问策略的组件。
  • 策略执行点 (Policy Enforcement Point)： 负责执行 PE 决策的组件，可以是防火墙、交换机、代理服务器、API 网关或终端代理等，它们根据 PE 的指令允许或阻止访问请求。在 OT 环境中，PEP 需要能够理解工控协议并能在不影响实时性的前提下执行策略。
• 持续监控与风险评估：
  • 网络流量分析 (NTA)： 持续监控 IT 和 OT 网络流量，利用 AI/ML 技术检测异常行为、未知威胁和策略违规。
  • 端点检测与响应 (EDR)： 在支持的 OT 端点上部署 EDR 解决方案，监控设备行为和状态。
  • 日志聚合与分析 (SIEM)： 收集来自网络设备、服务器、应用程序和 OT 组件的日志，进行关联分析和威胁检测。
  • 动态风险评估： 持续评估用户和设备的风险状况，并将风险评分作为访问策略决策的输入。

5.4 落地案例分析

多个行业的组织已经开始在 IT/OT 融合环境中探索和实施 ZTA：

• 汽车制造业 (Zscaler 案例)：
  • 挑战： Industry 4.0 转型中，大量 IoT 和 OT 设备（机器人臂、传感器、传送带）接入网络，攻击面急剧扩大。传统网络访问模型允许横向移动，威胁关键生产系统。需要保护创新成果，同时应对增长 400% 的 OT 网络攻击。
  • Zscaler 解决方案：
    • ZTNA (Zscaler Private Access - ZPA)： 取代 VPN，实现基于身份和上下文的应用级访问，用户只能连接到授权的应用，无法访问底层网络，阻止横向移动。应用对未授权用户不可见，缩小攻击面。
    • 应用感知分段 (Zscaler Zero Trust SD-WAN)： 将 SCADA、PLC 等关键 OT 系统与 IT 网络逻辑隔离，保护其免受 IT 网络威胁或供应链恶意软件的影响。无需更改 VLAN 或 IP 地址，简化部署。
    • 安全云连接： 通过加密隧道将 OT 设备安全连接到 Zscaler Zero Trust Exchange 平台，实现与云端分析平台的数据安全传输，无需本地硬件。
    • 边缘安全 (Zero Trust Exchange)： 提供 DPI、IDS/IPS、防火墙等统一威胁防护能力，扫描所有流量，阻止恶意软件和数据泄露。
    • 特权远程访问 (PRA)： 为第三方承包商提供基于浏览器的、无需客户端的安全访问（支持 SSH, RDP, VNC），实现会话录制和监控。
  • 效果： 提升 OT 系统安全性，减少攻击面和横向移动风险，简化远程访问管理，保障生产正常运行。
• 石化行业 (Veridify/案例提及)：
  • 挑战： 大型石化企业的 ICS 环境复杂，需要保护关键过程控制系统免受网络攻击。
  • 实践：
    • 资产清点与映射： 全面梳理 ICS 资产和通信流。
    • 微分段： 使用 SDN 和虚拟防火墙隔离关键系统和流程。
    • 强认证： 对所有远程访问 ICS 组件实施 MFA。
    • 持续监控： 部署 SIEM、NTA 和 EDR 工具进行威胁检测。
  • 效果： 显著降低未经授权访问的风险，提高可见性，增强对异常和威胁的响应能力。
• 其他案例启示：
  • Flex (制造业)： 使用 Zscaler 简化了通常被认为极具挑战性、成本高昂且投入巨大的微分段部署。
  • 微软内部实践： 微软自身实施 ZTA，强调身份验证（从智能卡到无密码生物识别）、设备健康验证（Intune MDM）、以及基于身份和设备健康的条件访问策略。

这些案例表明，ZTA 并非理论空谈，已在实际的工业环境中逐步落地。成功的关键在于结合具体业务场景和风险承受能力，选择合适的技术组合，并分阶段进行实施。微分段作为实现 ZTA 最小权限和阻止横向移动的关键技术，在 OT 环境中尤其重要。同时，强大的身份管理（包括设备身份）是 ZTA 成功的基石，因为在 ZTA 模型下，身份已取代网络位置成为新的安全边界。

5.5 参考框架 (NIST SP 800-207)

NIST SP 800-207 是美国国家标准与技术研究院发布的关于零信任架构的权威指南。它定义了 ZTA 的核心逻辑组件（如策略引擎 PE、策略管理员 PA、策略执行点 PEP）和七项基本原则（Tenets）：

1. 所有数据源和计算服务都被视为资源。
2. 所有通信都应被保护，无论网络位置如何。
3. 对单个企业资源的访问是基于会话授予的。
4. 对资源的访问由动态策略决定（包括对主体身份、设备状态和请求上下文的可观察状态的评估）。
5. 企业监控和测量所有自有及关联资产的完整性和安全态势。
6. 所有资源身份验证和授权都是动态的，并在允许访问之前严格执行。
7. 企业尽可能收集有关资产、网络基础设施和通信的现状信息，并利用这些信息来改善其安全态势。

虽然 NIST SP 800-207 主要面向 IT 环境，但其原则和逻辑组件为在 OT 环境中设计和实施 ZTA 提供了重要的参考框架。例如，策略引擎需要结合 OT 的特定上下文（如操作模式、安全状态）来制定访问决策；策略执行点需要能够处理工业协议并满足实时性要求；持续监控需要覆盖 OT 特有的设备和通信模式。

6. 制造业勒索攻击应急响应 SOP

勒索软件已成为全球网络安全的最大威胁之一，而制造业由于其对运营连续性的高度依赖性，正日益成为勒索软件攻击的重灾区。制定一套针对 OT 环境特点的、可操作的应急响应标准操作程序 (SOP) 对于减轻攻击影响、快速恢复生产至关重要。

6.1 制造业勒索软件攻击现状与趋势

指标	统计/发现	来源
勒索软件事件同比增幅 (全球, Q1 2025)	+126%	CheckPoint
制造业受害者占比 (全球)	9.1% (第三高, CheckPoint); >50% (Dragos)	CheckPoint, Dragos
活跃勒索软件团伙数量 (工业, 2024)	80个 (较2023年增长60%)	Dragos
平均每周攻击次数 (工业组织, 2024)	H1: 34次/周; H2: 数量翻倍以上	Dragos
对OT运营的影响 (2024)	75% 运营受扰; 25% OT站点完全关闭	Dragos
主要攻击团伙 (2024)	RansomHub, Fog, LockBit 3.0等	Dragos

近年来的数据显示，制造业面临的勒索软件威胁形势十分严峻：

• 高发行业： 制造业在全球范围内持续成为勒索软件攻击最主要的受害者之一，经常位列受攻击行业前三名。CheckPoint 报告显示，2025 年第一季度，工业制造占全球勒索软件报告事件的 9.1%，位列第三。Dragos 2024 年报告则指出，制造业占其观察到的勒索软件受害者的一半以上。这种高发性主要是因为制造业对生产中断的容忍度极低，攻击者认为迫使其支付赎金以快速恢复运营的可能性更大。
• 攻击频率与复杂性增加： 勒索软件攻击的频率和复杂性都在显著上升。CheckPoint 报告称，2025 年第一季度全球勒索软件攻击事件总数同比增加了 126%。Dragos 报告显示，针对工业组织的勒索软件团伙数量从 2023 年的 50 个增加到 2024 年的 80 个（增长 60%），2024 年下半年的平均每周攻击数量是上半年的两倍多。攻击者越来越多地采用双重勒索（窃取数据+加密系统）甚至多重勒索策略。
• 攻击路径： 大多数针对 OT 的勒索软件攻击并非直接攻击 OT 网络，而是起源于 IT 网络。攻击者通常通过钓鱼邮件、利用 IT 系统漏洞或不安全的远程访问进入企业 IT 网络，然后利用 IT 与 OT 之间存在的连接或薄弱的隔离措施（如配置不当的防火墙、双网卡主机）横向移动到 OT 环境。
• 对 OT 运营的严重影响： 勒索软件一旦进入 OT 环境，可能加密 HMI、工程站、历史数据库甚至直接影响 PLC，导致生产线停顿、运营中断。Dragos 报告指出，其观察到的案例中，有 25% 导致了 OT 站点的完全关闭，75% 导致了不同程度的运营中断。恢复过程可能非常漫长且成本高昂，尤其是在缺乏良好备份和恢复计划的情况下。
• 主要攻击团伙： 活跃于工业领域的勒索软件团伙众多，例如 RansomHub, Fog, LockBit 3.0 等。此外，一些黑客活动组织 (Hacktivists) 也开始使用勒索软件作为其攻击手段，如 Handala, Kill Security, CyberVolk。

6.2 制定 OT 特定勒索软件应急响应 SOP 的必要性

标准的 IT 事件响应计划往往不足以应对 OT 环境中的勒索软件事件，原因在于 IT 和 OT 存在本质差异：

• 安全优先级不同： OT 环境的首要任务是保障人员安全 (Safety) 和生产连续性 (Availability)，而 IT 通常优先考虑数据机密性 (Confidentiality) 和完整性 (Integrity)。应急响应措施必须优先评估对安全和运营的影响。
• 实时性要求高： OT 系统通常需要实时或近实时运行，任何中断或延迟都可能导致严重后果，这限制了某些响应措施（如全网扫描、系统离线分析）的可行性。
• 遗留系统普遍： OT 环境中大量存在的遗留系统可能无法运行现代安全工具，恢复过程复杂，甚至没有可用的备份或镜像。
• 物理影响： 网络攻击可能直接导致物理设备的损坏或危险状态，需要 OT 工程师介入进行物理检查和恢复。
• 供应商依赖： 许多 OT 设备由特定供应商提供和维护，恢复过程可能需要供应商的专业支持。
• 不同的恢复目标： IT 恢复通常侧重于数据恢复和业务系统上线，而 OT 恢复的核心是安全、稳定地恢复物理生产过程。

因此，必须制定一套专门针对 OT 环境特点、结合 IT 和 OT 团队协作的勒索软件应急响应 SOP。

6.3 应急响应 SOP 框架与模板 (基于 PICERL/NIST)

推荐采用成熟的事件响应生命周期模型作为 SOP 的框架，例如 SANS 的 PICERL 模型（Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned）或 NIST SP 800-61r3 中描述的与 NIST CSF 2.0 功能（尤其是 Respond 和 Recover）对齐的流程。以下是一个结合了 PICERL 模型和 OT 特定考量的 SOP 概要模板：

Table 5: OT 勒索软件事件响应 SOP 概要 (PICERL)

PICERL 阶段	关键活动/步骤	特定 OT 考量/示例
0. SOP 治理	- 定义 SOP 所有者、审批流程、版本控制。 <br> - 确定 SOP 审查和更新频率（至少每年一次）。 <br> - 明确 SOP 适用范围（特定工厂/产线/系统）。	- 确保 OT 部门负责人参与审批。 <br> - 更新需反映 OT 环境变化（新设备、网络变更）。
1. 准备 (Preparation)	- 资产与风险识别： 识别关键 OT 资产、生产流程、依赖关系（IT/OT 接口、供应商）；进行 OT 特定风险评估。 <br> - 角色与职责： 定义清晰的 IR 团队成员及职责（IT 安全、OT 运营/工程、管理层、法务、公关、供应商协调员）；建立可靠的（带外）通信渠道。 <br> - 文档与工具： 维护最新的 OT 资产清单、网络拓扑图（含 IT/OT 连接点）；准备 IR 工具包（取证软件、网络分析工具等）。 <br> - 备份与恢复： 实施并严格测试 OT 系统备份（遵循 3-2-1 原则：3 份拷贝、2 种介质、1 份离线/异地/不可变存储）；验证备份的可恢复性；保存已知的良好配置和软件镜像。 <br> - 遏制策略： 预先规划遏制措施（如断开 IT/OT 连接、隔离受感染网段/设备）；评估每种措施对生产和安全的影响；明确授权进行生产中断或系统隔离的决策者。 <br> - 供应商与支持： 建立应急联系人列表（设备供应商、IR 服务商）；预签应急支持合同或 IR Retainer。 <br> - 演练与培训： 定期（建议每年多次）组织针对 OT 场景的勒索软件桌面演练和模拟攻击，让 IT 和 OT 团队共同参与；对员工进行勒索软件识别、报告流程的培训。	- 资产识别需 OT 工程师确认关键性等级。 <br> - IR 团队必须包含熟悉具体 OT 流程和安全要求的工程师。 <br> - OT 网络图需详细标注 Zones 和 Conduits。 <br> - OT 备份需考虑特定设备（PLC, HMI, SCADA Server, Historian）的备份方式和恢复工具，并进行实际恢复测试。 <br> - 遏制决策必须由 OT 运营/安全负责人参与，优先保障人员安全。 <br> - 演练场景应模拟对生产造成实际影响的情况。
2. 识别 (Identification)	- 检测来源： 用户报告（操作员发现异常）、SIEM/监控系统告警（如异常网络流量、文件加密活动、CPU/内存飙升）、IDS/IPS 告警、反病毒软件告警、供应商通知。 <br> - 初步确认与评估： 快速确认是否为勒索软件事件；识别受影响的系统范围（IT 和 OT）；评估初步影响（哪些产线/流程受影响、数据是否被盗）；确定勒索软件类型（如有可能）。 <br> - 上报与启动响应： 按照预定流程上报事件给 IR 团队、管理层、法务等；正式启动事件响应流程。 <br> - 证据初步保存： 在确保安全和运营稳定的前提下，尽可能保存易失性证据（内存镜像）、网络流量、系统日志（防火墙、服务器、端点、应用、OT 设备日志）、勒索信样本等；记录 IOCs（恶意文件哈希、C2 地址、域名等）。	- OT 环境检测可能更依赖操作员的观察和物理异常报告。 <br> - 评估影响时需 OT 专家判断对生产安全和连续性的具体威胁。 <br> - 证据收集中，对 OT 设备进行内存镜像或网络抓包需极其谨慎，避免影响实时控制；优先收集边界设备和服务器日志。
3. 遏制 (Containment)	- 目标： 阻止勒索软件进一步传播，特别是阻止其从 IT 蔓延到 OT，或在 OT 内部扩散；将影响限制在最小范围。 <br> - 策略： 短期遏制（快速隔离受感染主机/用户）、系统性遏制（加固网络分段、阻断恶意通信）。 <br> - 行动： 断开受感染系统与网络的连接；隔离受影响的 OT 网段（执行预定义的网络分段策略，如断开 IT/OT 网关）；禁用被盗用的账户；阻止与已知恶意 C2 服务器的通信（防火墙/DNS 层面）；识别并隔离初始入口点。 <br> - 记录： 详细记录所有遏制措施及其执行时间。	- 安全优先！ 在采取任何隔离措施前，必须由 OT 工程师评估其对物理过程和人员安全的潜在影响。某些情况下，完全断开连接可能导致更危险的失控状态。 <br> - 可能需要 OT 工程师手动操作设备进入安全状态后才能进行网络隔离。 <br> - 遏制决策过程需 IT、OT、安全、管理层共同参与。
4. 根除 (Eradication)	- 目标： 彻底清除网络中所有的勒索软件及其残留（恶意代码、后门、持久化机制）。 <br> - 行动： 识别攻击根源（最初如何进入、利用了哪些漏洞）；使用杀毒软件或专用工具清除恶意软件；从已知的干净备份或镜像恢复受感染系统（优先选择重装而非清理）；重置所有可能被盗用的账户密码（特别是管理员和特权账户）；修复被利用的漏洞（打补丁、修改配置）。	- 遗留 OT 系统可能无法重装或清理，恢复极其困难，可能需要依赖供应商支持或特殊工具。 <br> - 供应商管理的“黑盒”系统恢复需要与供应商密切协调。 <br> - 恢复系统后需 OT 工程师验证其功能和安全性是否满足生产要求。 <br> - 确保根除过程中不会意外中断关键安全功能（如 SIS）。
5. 恢复 (Recovery)	- 目标： 安全、有序、高效地恢复受影响的业务运营和生产活动。 <br> - 行动： 制定恢复优先级（根据业务影响分析 BIA 结果）；验证备份的完整性和可用性；按照优先级逐步恢复系统和服务；恢复后加强监控，检测是否有残留威胁或再次感染的迹象；与利益相关方沟通恢复进展。 <br> - 赎金支付决策： 遵循预定义的决策流程（通常涉及高管、法务、网络保险公司）；评估支付风险（数据不一定能解密、可能被二次勒索、助长犯罪）；若决定支付，需通过专业机构进行。	- OT 系统恢复可能需要分阶段进行，并伴随大量的物理检查和安全确认。 <br> - 在恢复生产前，必须由 OT 运营和安全团队进行严格的系统功能和安全验证。 <br> - 恢复过程可能需要特定 OT 供应商的现场支持。 <br> - OT 恢复的复杂性凸显了“准备”阶段进行充分规划和测试的重要性。缺乏已知良好备份或恢复计划将导致恢复时间极长或无法完全恢复。
6. 经验教训 (Lessons Learned)	- 事后复盘 (AAR)： 事件结束后（通常在 1-2 周内）组织复盘会议，邀请所有参与响应的关键人员（IT, OT, 安全, 管理层等）；回顾事件时间线、响应过程、遇到的挑战、有效/无效的措施、沟通协调情况；重点关注对运营的实际影响。 <br> - 根本原因分析 (RCA)： 深入分析攻击是如何发生、为何成功、哪些防御措施失效。 <br> - 文档更新： 根据复盘结果和 RCA，更新 IR 计划、SOP、网络图、资产清单、联系人列表、备份策略等。 <br> - 改进措施： 识别并实施改进措施，弥补安全控制、策略、流程、技术或培训方面的不足。 <br> - 报告： 完成内部事件总结报告；根据法规、合同或保险要求完成外部报告。	- 复盘必须充分听取 OT 团队的意见，理解其视角下的影响和挑战。 <br> - 改进措施应同时考虑 IT 和 OT 环境的加固。 <br> - 将经验教训融入未来的培训和演练中。

鉴于勒索软件通常从 IT 环境横向移动至 OT 环境的攻击路径，一个有效的 OT 应急响应 SOP 绝不能仅仅聚焦于 OT 系统本身的恢复。它必须在“准备”和“识别”阶段就包含对 IT/OT 边界的强化控制和检测措施，例如严格的网络分段、对跨边界流量的深度检测、以及对 IT 系统（特别是可能作为跳板的系统）的快速响应能力。这意味着 IT 安全团队与 OT 运营/工程团队之间必须建立起紧密的、常态化的协作机制，共同参与 SOP 的制定、演练和执行。缺乏这种联动，单纯的 OT 响应计划很可能在实战中效果大打折扣。

此外，OT 环境的勒索软件恢复过程远比典型的 IT 恢复更为复杂。这不仅仅是因为技术上的挑战（如遗留系统、专用软硬件），更涉及到与物理过程和人员安全直接相关的验证环节。恢复一个 PLC 或 SCADA 系统后，必须经过 OT 工程师的严格测试和安全确认，才能重新投入生产控制，以避免因恢复不当导致设备损坏或安全事故。同时，对特定供应商设备或软件的依赖性也意味着恢复工作往往需要供应商的深度参与。这些因素都要求企业必须为关键 OT 资产制定极其详尽、预先规划且经过反复测试的恢复手册 (Playbook)，而不能寄希望于临场应变。

7. IT/OT 安全融合的战略建议

实现安全、高效的 IT/OT 融合，需要超越单纯的技术部署，采取一套涵盖人员、流程和技术的整体战略。以下是一些关键建议：

7.1 弥合 IT/OT 文化与技能鸿沟

这是成功融合的基础，也是最具挑战性的环节之一。

• 促进相互理解： 通过组织联合研讨会、交叉培训、工作轮岗、OT 现场参观等方式，增进 IT 人员对 OT 运营流程、安全要求（尤其是物理安全和高可用性）和专用技术的理解；同时，提升 OT 人员对网络安全威胁、IT 通用安全实践（如补丁管理、访问控制）和数据管理协议的认知。
• 建立共同语言和目标： 打破术语壁垒，建立 IT 和 OT 都能理解的沟通语言。将安全目标与 OT 的核心业务目标（如安全生产、稳定运行、产品质量）相结合，使安全成为业务赋能者而非阻碍者。
• 统一治理与协作： 成立跨部门的 IT/OT 安全指导委员会或融合团队，共同制定安全策略、评估风险、审批变更、协调事件响应。打破组织壁垒，明确责任分工，确保双方在安全决策中的话语权。同时，要正视并解决组织层面可能存在的对 OT 规模、复杂性和预算需求的低估问题。
• 解决人才短缺： 针对 OT 安全领域复合型人才稀缺的现状，企业应加大内部培训投入，与高校合作建立人才培养渠道，实施导师制度，并通过改善薪酬待遇、提供发展路径、创造灵活工作环境等方式吸引和留住人才。

7.2 将安全融入 OT 生命周期

安全不应是事后添加的补丁，而应贯穿 OT 系统的整个生命周期。

• 安全设计 (Security by Design)： 在 OT 系统规划、设计和采购阶段就引入安全要求，遵循 IEC 62443-4-1 等安全开发生命周期标准。选择本身具备较好安全特性的产品和技术。
• 供应链安全管理： 建立严格的供应商准入和评估机制，审查供应商（软硬件、服务商）的安全实践和产品安全认证（如 ISASecure）；要求提供软件物料清单 (SBOM)；在合同中明确安全责任。
• 基于风险的脆弱性管理： 改变 IT 中“逢洞必补”的模式，结合 OT 环境的实际运行风险评估漏洞的优先级。优先处理对安全、稳定运行构成高风险的漏洞。对于无法及时修补的漏洞（尤其是遗留系统），必须采用补偿性控制措施，如加强网络隔离、访问控制和监控。
• 安全运维： 将安全要求融入日常运维流程，包括变更管理、配置管理、访问控制、日志审计等。
• 安全退役： 在 OT 设备或系统生命周期结束时，确保进行安全的数据擦除和访问权限回收，防止敏感信息泄露或被后续利用。

7.3 持续监控与改进

安全是一个持续对抗和适应的过程，而非一劳永逸的终点。

• 实施全面、统一的监控： 部署能够理解 IT 和 OT 协议及行为的 IDS/IPS 和 SIEM 解决方案，实现对融合环境的统一可见性。利用 NTA 和 UEBA 技术检测异常活动、内部威胁和未知攻击。
• 定期风险评估与安全审计： 周期性地（例如每年）对 IT/OT 融合环境进行全面的风险评估和安全审计，检验安全控制的有效性，确保符合相关标准（如 IEC 62443, NIST CSF, NERC CIP, GB/T 等）和法规要求。
• 主动威胁狩猎： 不能仅仅依赖自动化工具的告警，应建立专门的威胁狩猎流程，主动在网络中搜寻潜在的、未被发现的威胁活动，秉持“假设已被入侵”的心态。
• 适应未来趋势： 持续关注网络安全威胁、技术（如 IIoT, 5G, AI/ML 在安全中的应用）和法规（如 NIS2, CRA）的发展变化，及时调整安全策略和技术部署，保持防御能力的前瞻性。

这些战略建议共同指向一个核心思想：有效的 IT/OT 安全融合是一个系统工程，它不仅仅是部署几项安全技术，而是需要深度整合人员（弥合文化与技能鸿沟）、流程（将安全嵌入 OT 生命周期和风险管理框架）和技术（采用统一、适应性强的监控和防护工具）。忽略任何一个维度都可能导致安全体系的脆弱。

同时，这些建议也体现了从被动响应向主动防御的战略转变。鉴于 OT 安全事件可能带来的灾难性后果（物理损坏、人员伤亡、环境污染、大规模生产中断），安全工作的重心必须放在预防、早期检测和风险缓解上，而不是仅仅等待事件发生后再去补救。安全设计、持续监控、定期评估、威胁狩猎、人员培训等前瞻性措施的重要性被反复强调。

在此过程中，诸如 IEC 62443 和 NIST CSF 等安全标准扮演着关键的赋能角色。它们不仅是合规性的要求，更提供了实用的框架和通用语言，帮助企业结构化地评估风险、设计防御体系、统一 IT 与 OT 的认知、并与内外部利益相关者有效沟通，从而更好地应对复杂融合环境下的安全挑战。

8. 结论

IT 与 OT 的融合为制造业带来了巨大的发展机遇，但同时也引入了前所未有的网络安全挑战。攻击面的扩大、遗留系统的脆弱性、工控协议的不安全性、以及 IT 与 OT 之间固有的文化和技术差异，共同构成了复杂且严峻的风险态势。

应对这些挑战，需要采取一种整体化、多层次的纵深防御策略。这不仅包括在网络边界部署防火墙，更需要在 OT 网络内部实施严格的分段（Zones and Conduits），并对关键的 PLC、SCADA、MES 系统进行细致的安全加固，涵盖访问控制、补丁管理、配置硬化、安全通信和日志监控等多个方面。

深入理解并防范特定工控协议（如 S7comm）的漏洞至关重要。尽管协议本身可能存在难以弥补的缺陷，但通过协议分析、漏洞挖掘和负责任的披露流程，可以推动供应商修复并促使用户采取缓解措施。同时，必须认识到仅靠协议层面的改进（如 S7comm+ 的加密）不足以保证安全，需要与其他安全措施相结合。

零信任架构 (ZTA) 为 IT/OT 融合环境提供了一种更具适应性的安全模型。虽然在 OT 环境中落地 ZTA 面临实时性、兼容性等挑战，但其核心原则——显式验证、最小权限、假设泄露——以及关键技术（如身份管理、设备指纹、微分段、持续监控）为保护动态、复杂的工业网络提供了有价值的思路和实践方向。

面对日益猖獗的勒索软件攻击，尤其是制造业的高风险状况，制定并演练一套针对 OT 环境特点的应急响应 SOP 是保障业务韧性的迫切需求。该 SOP 必须基于成熟的框架（如 PICERL），充分考虑 OT 的安全优先级和恢复复杂性，并强调 IT 与 OT 团队的紧密协作。

最终，保障 IT/OT 融合环境的安全是一项长期而艰巨的任务，需要企业高层的持续关注和战略投入。成功的关键在于：打破文化壁垒，促进 IT 与 OT 团队的深度协作与相互理解；将安全意识和要求融入 OT 系统的整个生命周期；利用先进的技术手段实现持续的监控、检测和响应；并时刻保持警惕，积极适应不断变化的技术和威胁格局。只有这样，制造企业才能在享受融合带来红利的同时，有效管理伴随而来的风险，确保其运营的安全、稳定和韧性。