如何在 PLC 梯形图中实现 IEC 62443 安全性

在 PLC 层级实现 IEC 62443 意味着编写确定性的梯形图逻辑，以拒绝不安全指令、限制设定值、验证信号合理性，并在上游设备受损时依然保持硬联锁。OLLA Lab 提供了一个受限的仿真环境，工程师可以在此注入异常数据、观察控制器响应，并在任何现场部署前验证防御逻辑。

OT（运营技术）领域的勒索软件不仅仅是 IT 问题。在许多近期的 OT 事件和威胁报告中，实际风险不仅是文件被加密，还包括通过操纵操作员界面、工程工作站或暴露的控制路径导致的过程中断。

在 PLC 层，程序员无法阻止每一次网络入侵。然而，程序员可以确保不安全指令不会仅仅因为来自 HMI（人机界面）就被视为正确。在实际工厂系统中，这种区分至关重要，因为“有效数据包”和“有效指令”是完全不同的概念。

Ampergon Vallis 指标： 在 24 次关于 HMI 到 PLC 设定值篡改的 OLLA Lab 内部对抗仿真中，未加限制的写入路径在 24 次测试中全部接受了越界值；而使用边界验证的受限写入路径在 24 次测试中全部拒绝了不安全写入。方法论： 针对压力和液位控制任务进行了 n=24 次模拟设定值注入测试；基准比较器为无验证的直接 HMI 到控制器写入路径，对比带有明确限制和报警处理的边界写入路径；时间窗口 = 2026 年 1 月至 3 月。这支持了在仿真中进行逻辑级约束的价值，但并不能证明全厂范围的网安韧性。

IEC 62443-4-2 并非梯形图编程风格指南。它是针对 IACS（工业自动化和控制系统）组件的组件级安全要求标准。对于 PLC 程序员而言，其实际价值在于将安全意图转化为确定性的控制行为。

有效的工程举措是将抽象的安全要求映射为可观察的逻辑决策。标准语言是必要的；而梯形图的行为才是其实际落地的体现。

哪些 IEC 62443-4-2 理念直接影响 PLC 逻辑？

尽管标准本身并未规定特定的指令集，但以下几项组件安全要求影响了 PLC 应用程序的结构：

• 识别与认证意图： 指令不应仅仅因为源自监控层就被视为可信。
• 授权执行意图： 控制器应区分允许和不允许的指令源或模式。
• 输入与数据验证意图： 外部值在使用前应进行范围、合理性和状态适用性检查。
• 资源可用性与异常情况处理： 当通信、设备行为或更新模式出现异常时，逻辑应能可预测地进入故障安全状态。
• 受限数据流： 在架构允许的情况下，关键控制路径应与便利性写入路径隔离。

对于 PLC 程序员来说，这通常转化为三件事：

• 限制可写入的内容
• 验证何时可以写入
• 定义验证失败后的处理方式

这就是运营层面的“安全优先”PLC 编程。不是防火墙，也不是口号，而是确定性的否决机制。

IEC 62443-3-3 与梯形图有何关联？

IEC 62443-3-3 适用于系统级而非组件级，但它很重要，因为 PLC 逻辑位于更大的安全架构之内。区域、管道、访问控制和安全等级等系统要求会影响控制器应用程序可以做出的假设。

重要的修正点在于：良好的区域划分并不能消除对防御逻辑的需求。它减少了暴露面，但并不能使每个传入的值在物理上都是合理的。工厂已经通过惨痛的教训学到了这一点。

PLC 程序员实际上应该实现什么？

实现符合 IEC 62443 行为的 PLC 程序员至少应考虑以下应用层控制：

• 设定值钳位： 基于过程设计限制的硬性上限和下限。
• 基于模式的写入授权： 针对操作员、维护人员和工程状态设置不同的写入权限。
• 握手验证： 仅在源身份、模式和序列条件有效时才接受指令。
• 合理性检查： 对关键信号进行变化率、奇偶校验、差异性检查和超时检查。
• 联锁独立性： 安全关键的许可条件和跳闸逻辑不得通过普通的 HMI 写入操作被绕过。
• 报警拒绝： 在架构允许的情况下，无效指令应被明确拒绝并记录或报警。

大多数现代 OT 破坏性攻击不需要重写 PLC 应用程序就能制造麻烦。操纵暴露的标签、监控设定值或边缘设备数据流，往往足以停止生产、触发跳闸或导致操作员陷入混乱。

这是更隐蔽的破坏形式。过程完全按照错误数据所指示的那样运行。

逻辑载荷与数据载荷有什么区别？

逻辑载荷会改变控制器程序本身。数据载荷则保持控制器逻辑不变，但操纵逻辑所消耗的值。

这种区分很重要，因为许多关于防御的讨论仍然只关注代码篡改。

• 逻辑载荷示例： 未经授权修改 PLC 内部的顺序逻辑、联锁或控制策略。
• 数据载荷示例： 受损的 HMI 写入 999 的压力设定值，或者边缘设备提供不合理的模拟量值，导致过程进入跳闸状态。

对于许多勒索软件式的 OT 中断，攻击者的目标不是优雅的持久化，而是运营杠杆。如果一个错误的设定值就能停止生产线，那么优雅与否并不重要。

哪些路径通常会被滥用？

对于过程工程师而言，最相关的路径通常是平淡无奇的：

• 受损的 HMI 写入路径
• 工程工作站滥用
• 具有过度信任的记录器或中间件变量
• 远程 I/O 或边缘网关异常
• 管理不善的维护模式

在实践中，PLC 通常通过合法通道接收指令。问题在于，传输的合法性并不同于意图的合法性。

防御性梯形图逻辑始于拒绝隐式信任。任何可以移动设备、改变回路、破坏许可条件或抑制跳闸的外部可写值，在验证之前都应被视为不可信。

这就是语法不再令人印象深刻，而工程开始变得有用的地方。

梯形图逻辑中的“零信任 OT”意味着什么？

在本文中，零信任 OT 并不是指工厂中所有安全控制的营销统称。它指的是 PLC 应用程序内部一个狭窄、可观察的控制原则：

> 指令不会仅仅因为其到达而被接受。只有当其来源、范围、时序、模式和过程上下文满足确定性验证规则时，才会被接受。

这个定义是可测试的。

易受攻击的逻辑 vs. 防御性逻辑

| 控制功能 | 易受攻击的模式 | 防御性模式 | |---|---|---| | PID 设定值写入 | 从 HMI 设定值直接 `MOV` 到 PID 设定值 | 使用 `LIM` 验证范围，验证模式/授权，仅在所有条件为真时才传输 | | 启动指令 | HMI 启动位直接激活顺序 | 要求许可条件、源验证、模式检查，并处理证明反馈超时 | | 模拟量输入使用 | 立即消耗原始模拟量值 | 应用缩放、合理性边界、变化率检查、坏质量回退，并在失败时报警 | | 急停或关键停止链 | 单通道信任或仅依赖软件停止 | 双通道差异逻辑、超时监控和独立的硬联锁行为 | | 维护覆盖 | 无上下文限制，可从 HMI 写入覆盖位 | 限时覆盖、钥匙开关模式、报警状态和受限的指令范围 | | 设备心跳 | 不监控远程边缘更新 | 看门狗定时器和超时强制安全状态处理 |

示例：防御性设定值钳位

最简单且有用的模式之一仍然是：永远不要将 HMI 设定值直接写入活动控制变量。

还有哪些防御模式应成为标准？

针对关键 I/O 的有用防御模式包括：

• 指令仲裁
• 本地模式覆盖远程模式
• 同一时间仅允许一个指令源处于活动状态
• 冲突指令强制执行拒绝并报警行为
• 状态感知指令接收
• 如果上游许可条件为假，则忽略阀门开启指令
• 如果最低液位、密封水或断路器状态无效，则拒绝泵启动请求
• 合理性与差异逻辑
• 比较冗余变送器
• 检测不可能的转换
• 标记陈旧值或与过程物理特性不符的振荡模式
• 超时与看门狗监控
• 使用 `TON` 或等效定时逻辑来检测缺失的证明、冻结的更新或洪水般的指令模式
• 故障安全默认值
• 在指令无效或信号陈旧时，进入定义的安全状态，而不是保留上一个错误的假设

并非 IEC 62443-4-2 中的每一条条款都能完美映射到梯形图指令，但有几个要求系列与 PLC 应用程序设计直接相关。

PLC 程序员应转化为应用程序行为的核心要求主题

• CR 1.x：识别与认证
• 实际影响：在架构允许将身份上下文传递到下游时，避免匿名指令授权。
• CR 2.x：使用控制 / 授权
• 实际影响：当授权状态、操作模式或指令来源无效时，逻辑应拒绝写入。
• CR 3.x：系统完整性
• 实际影响：通过受控的写入路径、验证以及拒绝格式错误或不安全的数据来保护应用程序完整性。
• CR 4.x：数据机密性
• 在梯形图中实现较少，但与更广泛的架构和敏感操作数据的暴露有关。
• CR 5.x：受限数据流
• 实际影响：将监控便利性与关键驱动逻辑分离。
• CR 6.x：及时响应事件
• 实际影响：在异常指令或信号条件下报警、标记或强制进入安全状态。
• CR 7.x：资源可用性
• 实际影响：通过看门狗和超时处理检测通信丢失、陈旧的设备更新或异常流量影响。

PLC 程序员并不是独自实现整个标准。他们实现的是决定机器是否服从“胡言乱语”的那部分。

你不应该在实时生产过程中排练破坏性的异常状态。那不是大胆的工程，而是缺乏判断力。

这就是 OLLA Lab 变得具有运营价值的地方。

OLLA Lab 是一个基于 Web 的交互式梯形图和数字孪生仿真器，允许工程师构建梯形图、运行仿真、检查变量和 I/O，并将控制器行为与逼真的虚拟设备状态进行比较。在此背景下，其作用是受限且具体的：它是一个风险可控的环境，用于在任何现场部署前验证防御逻辑是否确实拒绝了异常或看起来恶意的输入。

此处的“仿真就绪”（Simulation-Ready）意味着什么？

仿真就绪意味着工程师可以在逻辑到达现场过程之前，证明、观察、诊断并加固控制逻辑以应对现实的过程行为。

这是一个运营定义，而非赞美。

“仿真就绪”的工作流包括以下能力：

• 构建预期的梯形图逻辑
• 定义正确的行为是什么样子的
• 注入异常条件
• 观察标签状态和设备响应
• 在失败后修改逻辑
• 反复测试直到行为受限且可解释

仅靠语法无法达到目的，信心也无法达到。

哪些 OLLA Lab 功能对验证任务至关重要？

对于符合 IEC 62443 的防御逻辑排练，相关的 OLLA Lab 功能包括：

• 基于 Web 的梯形图编辑器
• 使用触点、线圈、定时器、比较器、数学函数和 PID 指令构建验证逻辑
• 仿真模式
• 无需物理硬件即可运行、停止和测试逻辑
• 变量面板和 I/O 可视化
• 监控标签、调整值、检查模拟量行为，并观察无效写入是否被拒绝
• 3D / WebXR / VR 工业仿真
• 在数字孪生环境中将梯形图状态与可见设备行为进行比较
• 数字孪生验证
• 测试过程模型在异常指令注入下是否仍保持在安全状态
• 基于场景的工业预设
• 在泵送、暖通空调、过程撬块、输送机、公用设施和水处理等现实系统中进行练习

重点不在于沉浸感本身，而在于当输入流不再像教科书那样规矩时，虚拟机器是否能保持安全。

实用的 OLLA Lab 验证工作流

在 OLLA Lab 中进行受限的 OT 网络安全排练可以遵循以下顺序：

• 为过程功能（如压力或液位控制）创建梯形图逻辑
• 建立物理边界、许可条件、跳闸点和可接受的操作员写入范围
• 添加 `LIM`、看门狗、模式检查、差异逻辑和报警拒绝路径
• 通过仿真环境强制输入越界设定值、冻结的模拟量值、不合理的振荡或陈旧的更新
• 使用变量面板和模拟设备状态来验证过程是否保持在受限范围内
• 在失败路径仍然模糊或宽松的地方加强逻辑

1. 构建正常控制路径
2. 定义安全操作限制
3. 插入防御逻辑
4. 注入异常数据
5. 观察控制器和数字孪生响应
6. 修改并重新测试

该工作流正是仿真之所以重要的原因。雇主很少会让初级工程师在真实的设备上发现这些故障模式，而这一次他们是对的。

截图库是薄弱的证据。一份紧凑的工程证明材料要强大得多，因为它展示了推理、验证和修订过程。

使用此结构：

1. 系统描述 定义过程、设备、控制目标和控制边界。
2. “正确”的运营定义 说明可接受的范围、顺序条件、许可条件、报警行为和安全状态行为。
3. 梯形图逻辑和模拟设备状态 展示相关的梯级以及相应的模拟机器或过程行为。
4. 注入的故障案例 记录异常写入、不合理的信号、陈旧的更新或被操纵的设定值。
5. 所做的修订 展示逻辑中具体改变的内容：添加了 `LIM`、授权门控、差异定时器、看门狗或回退行为。
6. 经验教训 解释第一个版本中错误假设了什么，以及修订后的逻辑如何加固了控制路径。

这种结构在培训、审查和招聘中非常有用，因为它展示的是判断力，而不仅仅是语法记忆。

一个梯级看起来可能很整洁，但在运营上可能是错误的。验证必须在正常和异常条件下比较控制意图、标签行为和模拟设备响应。

这就是图表完成与调试思维之间的区别。

验证期间应检查什么？

至少验证以下内容：

• 正常操作
• 指令仅在预期模式下成功
• 设定值在允许范围内正确传输
• 设备按预期响应
• 越界写入
• 无效值被拒绝
• 报警或故障位正确置位
• 活动设定值保持在边界内
• 陈旧或冻结的信号
• 看门狗按设计过期
• 逻辑转换为预期的回退或安全状态
• 差异条件
• 冗余输入不一致时应触发确定性处理
• 过程不应在盲目信任下继续运行
• 恢复行为
• 异常条件清除后，重启或复位行为应保持可控且可解释

数字孪生验证增加了什么？

数字孪生验证为梯形图决策增加了可观察的过程后果。它回答了一个比“位是否改变”更严肃的问题。

它回答了：

• 泵是否保持禁止状态？
• 阀门是否保持在安全行程内？
• 撬块是否避免了错误的许可条件？
• 当指令路径被破坏时，过程状态是否保持在受限范围内？

这就是数字孪生验证在此处有用的原因。它将逻辑加固与物理结果联系起来，而这正是工厂唯一会买单的结果。

PLC 防御性编程是必要的，但对于完整的 IEC 62443 实现来说是不够的。它不能取代区域划分、访问控制、补丁管理、资产盘点、安全远程访问、备份策略、事件响应或安全生命周期义务。

这个边界必须保持清晰。

防御性梯形图逻辑可以：

• 拒绝不安全的值
• 强制执行过程边界
• 检测某些异常信号行为
• 保护关键联锁免受普通监控滥用

防御性梯形图逻辑本身不能：

• 防止所有网络入侵
• 取代 IEC 61508 或 IEC 61511 下的 SIS（安全仪表系统）设计或功能安全要求
• 保证整个 OT 环境的取证可见性
• 证明整个 IACS 架构的合规性

换句话说，PLC 可以是过程行为的最后一道防线。它不是整个防御堆栈。

仿真、数字孪生和故障注入式验证的使用，与虚拟调试、信息物理系统测试和降低风险的培训环境等更广泛的工程文献是一致的。具体的工具链各不相同，但模式是稳定的：在现场暴露之前测试异常状态。

同样，标准和行业指南继续加强分层防御。IEC 62443 解决组件和系统的安全性；IEC 61508 和 IEC 61511 解决功能安全；exida 和相关从业者反复强调，安全（Safety）和安防（Security）相互作用但不可互换。混淆它们很常见，而且代价高昂。

对于培训和技能发展，基于仿真的环境特别有用，因为它们允许工程师练习在生产资产上不安全、具有破坏性或根本无法实现的各种高风险场景。OLLA Lab 适合这种受限角色：不是作为合规引擎，而是作为防御性控制行为的排练和验证环境。

- IEC 62443 标准计划 (IEC) - ISA/IEC 62443 资源 (ISA) - 零信任成熟度模型 (CISA) - ICS 建议和指南 (CISA) - 工业控制系统和数字孪生的网络安全 (DOI) - 功能安全和网络安全资源 (exida)