IEC 62443
IEC 62443 由国际电工委员会（IEC, International Electrotechnical Commission）TC65 技术委员会下的 WG10 工作组制定，适用对象是工业自动化和控制系统（IACS, Industrial Automation and Control Systems）。北美一侧由国际自动化学会（ISA, International Society of Automation）的 ISA99 委员会推进，所以文献里 ISA/IEC 62443、ISA-62443 这几种写法指的是同一套东西。
它是自愿性标准，不是法规。但在工控采购里它的位置接近基线：招标文件的技术要求、供应商的符合性声明、集成合同的验收条款，大多直接引它。跟多数 IT 安全标准最不一样的地方是按角色分册——资产所有者、集成商、产品供应商、服务提供商各有各的义务，同一个安全目标落到不同角色身上写法完全不同。读的时候容易忽略这一层，结果就是拿 4-2 的条款去要求业主。
系列结构
条款编号形如 62443-<组>-<部分>，组号即面向对象：
| 组 | 面向 | 代表部分 |
|---|---|---|
| 1-x 通用 | 全体 | 62443-1-1 术语、概念与模型；62443-1-3 系统合规性指标；62443-1-4 IACS 安全生命周期与用例 |
| 2-x 策略与流程 | 资产所有者、集成商、服务提供商 | 62443-2-1 IACS 运行的安全管理体系；62443-2-3 IACS 环境下的补丁管理；62443-2-4 IACS 服务提供商的安全项目要求 |
| 3-x 技术，系统级 | 集成商、资产所有者 | 62443-3-2 安全风险评估与系统设计；62443-3-3 系统安全要求与安全等级 |
| 4-x 技术，部件级 | 产品供应商 | 62443-4-1 产品安全开发生命周期要求；62443-4-2 IACS 部件的技术安全要求 |
各部分的发布年份与修订状态 待验证；62443-1-2、62443-2-2、62443-3-1 这几个编号是否真实存在也 待验证，引用前得核 IEC 或 ISA 的官方目录。标准正文是付费出版物。
七项基础要求
62443-3-3 与 62443-4-2 共用同一套基础要求（FR, Foundational Requirements），整个系列的技术骨架就在这里：
| 编号 | 名称 | 关注点 |
|---|---|---|
| FR 1 | 标识与鉴别控制 IAC | 账户管理、认证、鉴别器生命周期 |
| FR 2 | 使用控制 UC | 授权、职责分离、最小权限 |
| FR 3 | 系统完整性 SI | 软件与固件完整性、输入验证、恶意代码防护 |
| FR 4 | 数据机密性 DC | 传输与存储加密、密钥管理 |
| FR 5 | 受限数据流 RDF | 分区、边界防护、防旁路 |
| FR 6 | 事件及时响应 TRE | 审计日志、告警、事件响应 |
| FR 7 | 资源可用性 RA | 拒绝服务防护、备份恢复、资源管理 |
FR 之下细分为要求（RE），RE 之下再分要求增强（RE(n)）。安全等级不是给系统 打一个总分，而是逐条 RE 判定它在哪一级被满足。评估输出的粒度由此决定，报告也就不可能只有「达标 / 不达标」两栏。
安全等级 SL
| 等级 | 防护对象 |
|---|---|
| SL 1 | 偶然或随意的违规 |
| SL 2 | 使用简单手段、低资源、通用技能、低动机的故意违规 |
| SL 3 | 使用较复杂手段、中等资源、具备 IACS 专项技能、中等动机的故意违规 |
| SL 4 | 使用复杂手段、大量资源、具备 IACS 专项技能、高动机的故意违规 |
SL 有三个变体，用的时候必须分清。SL-C（Capability）是组件或系统声明自己具备的能力，SL-T（Target）是资产所有者给某个区域定的目标，SL-A（Achieved）是评估后实际达成的那一级。SL-T 减 SL-A 就是差距分析的产出；反过来 SL-C 高于 SL-A，说明设备买对了但没配出来。
区域与导管
Zone（区域）是一组有共同安全要求的逻辑或物理资产，Conduit（导管）是连接两个区域的通信通道。这个模型真正的用处，是把「整个工厂要 SL 几」这种没法回答的问题拆开：每个区域各自定 SL-T，每条导管各自定义允许的协议与端口。62443-3-2 用它驱动风险评估和系统设计，62443-3-3 的 FR 5 是它落到技术条款上的位置。
落地中的常见偏差
最常见的一条是把组件等级当成系统等级。采购一批通过 62443-4-2 SL 2 的设备，系统整体不会自动达到 SL-T 2，缺口要靠补偿措施（Compensating Countermeasures）填。标准允许这么做，但补偿措施必须记录在案，并写清替代了哪条 RE。
其余的：
- SL-T 定得过高。存量 IACS 多数到不了 SL 2，目标一定高，整份基线就执行不下去，最后只剩纸面文档。
- 供应商说「符合 62443」时不区分自我声明与第三方认证。ISA Secure 计划下有组件安全保证（CSA）、安全开发生命周期保证（SDLA）等类别，类别命名与最新认证范围 待验证。
- 评估范围只圈 IT 资产。现场层的传感器、执行机构、RS-485 总线和工程站经常被排除在外，偏偏 FR 5 和物理安全最薄弱的就是这一层。
- 拿 IT 的节奏做补丁管理。62443-2-3 要求的补丁流程在连续生产装置上跑不通，现场的实际做法是网络层补偿加集中停机窗口。
- 资产台账不全就开工。62443-2-1 的多数条款以准确的资产清单为前提，台账缺一块，后面的技术要求全都没有落点。
评估与验证方法
差距分析是最常用的入口：以 62443-3-3 的 FR 与 RE 为清单逐条比对现状，产出每条 RE 的 SL-A，再与 SL-T 求差。
FR 5 不能只看防火墙配置。要在跨区导管两侧抓包，确认没有配置之外的流量过去；工控协议白名单是否真的按「功能码 + 寄存器地址范围」这个粒度生效，也只有实测能回答，工具见 04-Tooling。
涉及认证、日志、更新机制的条款要在真实设备上验行为，厂商文档不算证据。同一型号不同固件版本之间的行为差异 待验证。
62443-4-1 是流程标准，看证据不看产品：安全需求文档、威胁建模记录、安全测试报告、漏洞处理时限记录。它按成熟度模型分级评定，级别划分与判据 待验证。
供应链这一环只能写进合同——要求供应商提供 4-1 与 4-2 的符合性证据、漏洞披露流程和响应时限，作为验收条件而不是售后承诺。
落地建议
顺序上，先做资产台账与数据流测绘，再谈安全等级；反过来的话基线是悬空的。目标分解用 Zone / Conduit，不同区域设不同 SL-T，控制层与业务层之间的导管按最小必要放行，放行规则写到协议字段粒度，字段定义见 01-Protocols。补偿措施要单独成文，写清替代了哪条 RE、组件自身为什么满足不了、失效后靠什么发现。
与国内合规并行时，把等级保护 2.0 的工业控制系统安全扩展要求与 62443 的 FR 做一次映射，免得维护两套体系；公开的条款级对照表 待验证。
引用条款时注明部分号与年份。标准修订会改 RE 编号，跨版本引用很容易错位。
参考
- IEC 官方标准商店：
https://webstore.iec.ch/ - ISA/IEC 62443 系列与 ISA Secure 认证：
https://www.isa.org/