如何在 OLLA Lab 中利用 IEC 62443 保护 PLC 逻辑免受入侵

为了根据 IEC 62443-4-2 标准保护 PLC 逻辑免受入侵，工程师应在控制逻辑本身内实施组件级访问控制、通信完整性检查和确定性的安全状态行为。OLLA Lab 提供了一个有界的仿真环境，用于在将行为应用于实际设备之前，演练锁定、心跳丢失检测和入侵响应验证。

边界安全是必要的，但它不是最后一道防线。如果威胁行为者到达了控制网络，PLC 将不再仅仅是执行过程逻辑；它还在决定不安全的命令是否会转化为物理运动。

IEC 62443-4-2 在此至关重要，因为它将部分安全负担转移到了组件本身。这包括设备级别的识别、身份验证强度、通信完整性和对审计相关事件的访问，而不仅仅是在防火墙层面。在实践中，这意味着梯形图逻辑应拒绝不可能或未经授权的状态更改，检测受信任监督的丢失，并将过程强制置于定义的安全状态。

Ampergon Vallis 指标： 在 24 次针对泵和阀门许可模型进行强制未经授权状态更改的 OLLA Lab 红队仿真中，有 24 次尝试在模拟电机进入受控运行状态之前，被心跳丢失联锁加上明确的运行许可条件拦截 [方法论：在同一个安全许可培训场景中进行了 24 次模拟入侵试验，基准比较器 = 相同场景但没有心跳丢失联锁和锁定逻辑，观察时间为 2026 年 3 月]。这支持了在该场景中逻辑级后备控制的价值。它并未确立跨所有 PLC 平台、架构或工厂的通用违规率降低。仿真器用于提供证据，而非神话。

逻辑级安全是必需的，因为 IEC 62443 不会将 PLC 视为被动端点。IEC 62443-4-2 定义了嵌入式和主机设备的组件安全要求，包括与识别和身份验证、通信完整性以及审计相关行为相关的控制。

实际的转变很简单：PLC 不得假设来自受信任网络路径的每个命令都是合法的。这种假设一直以来都过于乐观，而现在它更站不住脚了。

在此背景下，通常引用的相关要求包括：

• CR 1.1 — 人类用户识别和身份验证： 组件应支持人类用户的识别和身份验证。
• CR 1.7 — 基于密码的身份验证强度： 密码机制必须满足最低强度预期。
• CR 3.1 — 通信完整性： 组件应保护通信的完整性或检测完整性故障。
• CR 6.1 — 审计日志可访问性： 与安全相关的事件必须可供审查和调查。

这些要求并不意味着每个安全功能都直接在梯形图中实现。有些属于固件、控制器配置、HMI 设计或周边架构。工程重点更窄且更有用：当过程安全或设备保护依赖于命令有效性时，控制程序必须在即使上游信任失效后，仍能强制执行确定性的许可条件和异常状态行为。

一个常见的误解是网络安全和控制逻辑是独立的学科。一旦错误的命令可以启动电机对抗关闭的阀门、破坏顺序或将输出保持在过程绝不应容忍的状态时，它们就不再独立了。在那一点上，网络问题很快就会变成机械损坏。

CISA 关于工业产品的公告反复指出遗留环境中的弱点，例如 不当访问控制 (CWE-284) 和 敏感信息的明文传输 (CWE-319)。这些公告并不意味着仅靠梯形图就能解决问题。它们确实强化了一个更严酷的事实：如果凭据、会话或命令路径薄弱，控制器程序就应该被编写为不信任不安全的状态转换。

“仿真就绪”应定义为：在部署到实际过程之前，能够证明、观察、诊断并加固控制逻辑以应对现实过程行为的能力。它不是“会写梯形图语法”的同义词。

在操作上，一名“仿真就绪”的工程师能够：

• 定义过程允许做什么，
• 将这些限制编码为许可条件、跳闸和锁定，
• 注入异常条件，
• 观察标签行为和设备响应，
• 在失败后修改逻辑，
• 并记录为什么修改后的行为更正确。

这种区别很重要，因为语法与可部署性是许多培训环境过早停止的地方。一段能编译的代码还不是控制策略。一段能经受住错误输入、监督丢失和矛盾现场状态的代码才更接近。

在本文中，OLLA Lab 被定位在这一有界角色中。它是一个基于 Web 的梯形图逻辑和仿真环境，工程师可以在其中安全地演练高风险验证任务：监控 I/O、强制异常值、追踪因果关系、比较梯形图状态与仿真设备状态，以及在故障后修改逻辑。它不能替代现场验收、正式合规性或在实际工厂中证明的能力。

梯形图中的密码保护应被视为一种有界的访问控制机制，而不是一个完整的身份平台。有用的模式是验证 HMI 输入的值，计算失败尝试次数，并锁定一个在满足受监督的重置条件之前阻止特权命令的锁定状态。

紧凑的实现可以由标准指令构建：

• `EQU`：比较输入值和存储值
• `CTU`：计算失败尝试次数
• 锁存线圈 / 内存位：保持锁定状态
• 许可触点：阻止受保护的操作
• 受监督的重置条件：清除锁定

核心逻辑模式

目标： 仅当输入的 PIN 与存储的值匹配且系统未处于锁定状态时，才允许执行管理或维护操作。

建议标签：

• `HMI_PIN_Entry`：从 HMI 输入的整数
• `Stored_Admin_PIN`：整数常量或安全值
• `PIN_Submit_Pulse`：来自 HMI 提交操作的单脉冲
• `PIN_Match`：内部位
• `Failed_Attempt_CTU`：计数器
• `System_Lockout_Alarm`：锁存位
• `Admin_Access_Granted`：内部位
• `Lockout_Reset_Request`：受监督的重置命令

梯形图逻辑流程示例

梯级 1：评估提交的 PIN `| PIN_Submit_Pulse |----[EQU HMI_PIN_Entry Stored_Admin_PIN]----( PIN_Match )`

梯级 2：计算失败尝试次数 `| PIN_Submit_Pulse |----[/PIN_Match]----------------------------[CTU Failed_Attempt_CTU PRE 3]`

梯级 3：当失败尝试达到预设值时锁存锁定状态 `| Failed_Attempt_CTU.ACC >= 3 |---------------------------------(L) System_Lockout_Alarm`

梯级 4：仅在匹配为真且不存在锁定时授予访问权限 `| PIN_Submit_Pulse |----[PIN_Match]----[/System_Lockout_Alarm]--( Admin_Access_Granted )`

梯级 5：仅在受监督条件下重置锁定 `| Lockout_Reset_Request |----[Supervisor_Mode]------------------(U) System_Lockout_Alarm` `| Lockout_Reset_Request |----[Supervisor_Mode]------------------[RES Failed_Attempt_CTU]`

工程目的不是优雅的凭据管理，而是对特权操作的确定性控制。如果 HMI 正在遭受暴力破解，PLC 应在达到定义的阈值后停止接受猜测，并应要求明确的受监督恢复路径。

此逻辑的优点

• 阻止重复的试错尝试，
• 创建可见的锁定状态，
• 防止受保护的命令在多次失败后执行，
• 为操作员或维护审查提供清晰的事件记录。

此逻辑的局限

• 它不替代 HMI 或控制器平台中的安全用户管理，
• 它不加密凭据，
• 它不能单独满足 IEC 62443 的所有身份验证要求，
• 它不能证明周边架构是安全的。

这种界限很重要。计数器不是身份系统。

访问许可条件应首先围绕过程有效性构建，其次才是用户权限。即使是有效的用户命令，如果过程状态使其不安全，也应失败。

例如，泵启动命令不应仅仅因为经过身份验证的 HMI 用户请求就使运行输出通电。梯级还应要求：

• 排出路径可用，
• 吸入或液位条件可接受，
• 无活动锁定，
• 无活动跳闸，
• 心跳健康，
• 模式和顺序状态有效，
• 证明反馈与预期的启动前状态一致。

一个紧凑的许可模型如下所示：

`| Start_Command |` `|----[Admin_Access_Granted OR Operator_Run_Permitted]` `|----[/System_Lockout_Alarm]` `|----[HMI_Heartbeat_Healthy]` `|----[Discharge_Valve_Open_Proof]` `|----[/Pump_Trip_Active]` `|----[Auto_Sequence_Ready]` `|----------------------------------------------------( Pump_Run_Permissive )`

然后输出梯级应使用 `Pump_Run_Permissive`，而不是原始命令。

这种分离很重要。命令意图不是命令授权。 在安全控制逻辑中，命令是请求；许可条件是决策者。

心跳监控器是一种逻辑模式，通过要求在定义的时间窗口内进行周期性的位转换，来确认来自受信任监督源的持续通信。如果该位停止变化，PLC 会将其视为监督丢失，并移除运行授权或将过程驱动至安全状态。

这是支持通信完整性要求意图的一种实用方法。它不能证明发送者是善意的，但它确实能检测到一种常见的故障模式：预期的 HMI 或监督会话已消失、停滞或被取代。

为什么心跳逻辑很重要

如果预期的 HMI 每秒切换一次位，而该位停止变化，则存在几种可能性：

• HMI 已发生故障，
• 通信已中断，
• 监督会话已冻结，
• 恶意设备已替换或绕过了预期路径，
• 或者过程不再处于 PLC 设计所信任的控制假设之下。

控制器应确定性地对这种丢失做出反应。礼貌地等待很少是一种控制策略。

使用 `TON` 的心跳设计示例

建议标签：

• `HMI_Heartbeat_Bit`：由 HMI 切换
• `Last_Heartbeat_State`：存储的前一个状态
• `Heartbeat_Change_Pulse`：状态改变时的单脉冲
• `Heartbeat_Timer`：`TON`
• `HMI_Heartbeat_Healthy`：内部位
• `System_Run_Permissive`：在其他地方使用的内部位

逻辑概念

梯级 1：检测心跳变化 `| HMI_Heartbeat_Bit XOR Last_Heartbeat_State |------------------( Heartbeat_Change_Pulse )`

梯级 2：在变化时更新存储状态 `| Heartbeat_Change_Pulse |--------------------------------------( Last_Heartbeat_State := HMI_Heartbeat_Bit )`

梯级 3：心跳变化时重置计时器；如果不变化则超时 `| /Heartbeat_Change_Pulse |-------------------------------------[TON Heartbeat_Timer PRE 2000ms]`

梯级 4：仅在计时器未完成时声明心跳健康 `| /Heartbeat_Timer.DN |-----------------------------------------( HMI_Heartbeat_Healthy )`

梯级 5：在心跳丢失时移除运行许可 `| Existing_Process_Permissives |----[HMI_Heartbeat_Healthy]-----( System_Run_Permissive )`

具体的实现因 PLC 系列和指令集而异。原则不变：如果受信任的监督源停止表现得像受信任的监督源，PLC 应安全地降级。

选择超时窗口

超时应基于：

• 预期的 HMI 更新速率，
• 网络确定性，
• 过程关键性，
• 误跳闸容忍度，
• 以及假阳性的安全状态后果。

在某些快速监督环境中，500 毫秒的超时可能是合适的。在其他环境中，2000 毫秒的超时可能更稳定。正确的数字是那些由过程证明并在现实的扫描和通信行为下测试过的数字，而不是在图表中看起来很严厉的数字。

您可以通过变量面板强制重复无效的凭据值，在仿真中观察计数器和锁定位，并确认数字孪生或模拟设备在持续的运行请求下仍保持安全状态，从而在 OLLA Lab 中模拟暴力破解攻击。

这就是 OLLA Lab 在操作上变得有用的地方。在实际过程中练习这一点将是保持正常运行时间的糟糕方式。

测试防御逻辑的 3 个步骤

#### 1. 注入异常数据 使用 变量面板 来操作 `HMI_PIN_Entry`、`PIN_Submit_Pulse` 和任何相关的命令位。重复输入错误的整数值并脉冲提交位，就像 HMI 会话正在被暴力破解一样。

#### 2. 验证锁定执行 继续无效提交，直到计数器达到预设值。预期结果是 `System_Lockout_Alarm` 通电并锁存，`Admin_Access_Granted` 保持为假。

#### 3. 在仿真中验证安全状态 使用 OLLA Lab 的仿真环境确认设备状态遵循锁定逻辑，而不是敌对命令。验证电机输出保持断电，阀门不会进入不安全的顺序。

您可以通过停止或冻结心跳位更新来模拟心跳丢失，然后观察计时器是否过期以及过程是否转换到预期的安全状态。您可以通过将命令或状态标签强制为应被许可模型拒绝的值来模拟未经授权的状态更改。

心跳丢失测试程序

1. 在心跳健康切换的情况下正常运行场景。
2. 在变量面板中冻结 `HMI_Heartbeat_Bit`。
3. 观察 `TON` 累加器，直到超时过期。
4. 验证 `HMI_Heartbeat_Healthy` 变为假，`System_Run_Permissive` 掉线。

未经授权的状态更改测试程序

强制执行一个在当前过程条件下应为不可能的命令。例如，在排出阀证明为假时命令泵运行。预期行为是许可条件保持为假，输出不应通电。

工程师应记录紧凑的工程证据，而不是截图库。重点是展示推理、验证纪律以及在故障条件下的修订。

使用此结构：

1. 系统描述：定义过程单元和控制目标。
2. “正确”的操作定义：说明确切的预期行为。
3. 梯形图逻辑和模拟设备状态：包括相关的梯级、标签列表以及仿真中相应的设备行为。
4. 注入的故障案例：记录异常测试。
5. 所做的修订：展示在第一次失败或不完整的尝试后发生了什么变化。
6. 经验教训：说明测试揭示了关于扫描行为、许可设计、故障处理或操作员恢复的什么信息。

OLLA Lab 通过为工程师提供一个基于 Web 的环境来构建梯形图逻辑、运行仿真、检查变量和 I/O 行为，并在异常条件下比较逻辑状态与模拟设备行为，从而支持有界的网络安全演练。

这是一个可信的用例，因为这些正是由于在实际系统上演练而风险高、不方便或昂贵的任务。界限同样重要。OLLA Lab 不认证符合 IEC 62443，不替代供应商加固，也不单独验证生产架构。它是一个风险受控的沙箱。

主要的设计错误通常是架构上的，而不是语法上的。工程师经常将安全功能添加为孤立的梯级，而忘记将其集成到实际的授权路径中。

常见的错误包括：

• 计算失败尝试次数而不阻止受保护的操作。
• 在输出逻辑中直接使用原始命令。
• 心跳丢失时失效打开 (Fail-open)。
• 重置锁定太容易。
• 忽略扫描周期行为。
• 将 HMI 身份验证视为足够的过程验证。
• 未明确定义安全状态。

根据 IEC 62443 保护 PLC 逻辑免受入侵，意味着将部分防御转移到控制程序本身。核心行为很简单：在适当的情况下进行身份验证、计算并锁定重复的失败、监控监督完整性、拒绝不可能的命令，并在信任条件崩溃时强制执行确定性的安全状态。

仿真的实际价值在于，它让工程师能够在实际过程以更昂贵的代价提供反馈之前测试这些行为。一个“仿真就绪”的工作流程不是关于绘制更整洁的梯级。它是关于证明当周围的假设停止合作时，梯级仍然做正确的事情。

• 返回梯形图逻辑掌握中心
• 零信任 OT：为什么隐式信任现在是现场的负债
• 网络安全优先的 PLC 程序员：IEC 62443 实现
• 在 OLLA Lab 中打开安全和许可预设

• 向上 (Pillar Hub)： 探索 Pillar 指导
• 横向： 相关文章 1
• 横向： 相关文章 2
• 向下 (商业/CTA)： 在 OLLA Lab 中构建您的下一个项目

- IEC 62443 系列概述 - ISA/IEC 62443 标准委员会资源 - CISA ICS 公告 - NIST SP 800-82 Rev. 3 运营技术安全指南