OT安全的第一性问题：从资产清单到Agent运行时控制

2026-09-24

OT安全, 2026年9月24日日报延伸

本文基于2026年9月24日《工业智能每日观察》中Honeywell《2026 Operational Technology Cybersecurity Benchmark Report》相关数据展开。报告调查603名关键基础设施安全负责人；具体比例与损失数据采用Honeywell发布口径，不外推为所有工业企业的普遍水平。

88%自认成熟，为什么只有21%拥有完整资产清单

OT安全领域最危险的错觉，可能不是企业没有部署防火墙，而是企业认为自己已经足够成熟。

Honeywell于2026年9月22日发布的OT网络安全Benchmark显示，88%的受访者认为自己的OT安全体系已经达到“成熟或设计驱动”水平，但只有21%拥有完整OT资产清单；只有33%将OT完整接入集中式SOC，对联网摄像头、传感器等IoT设备进行持续监控的比例约为20%。

报告还给出了一项非常具体的业务后果：一次重大OT安全事件平均造成16.2小时停机。部分受影响企业估算每小时损失超过10万美元，在最严重的区间甚至超过50万美元。与此同时，AI已用于检测、监控和资产识别，但使用自主或Agentic AI进行威胁检测的受访者仅占23%。

这些数字构成了一个清晰判断：OT安全首先不是AI问题，而是事实底座问题。

如果企业不知道生产网中有哪些设备、运行什么固件、由谁维护、与哪些系统通信、出现故障会影响哪条产线，那么再先进的检测模型也只能在不完整的地图上分析风险。Agent能够更快地查询日志、归并告警和生成处置建议，却不能替企业补齐不存在的资产事实。

一、OT安全的第一性目标不是“零入侵”，而是控制物理后果

IT安全常围绕数据机密性、完整性和可用性展开。OT系统还必须同时保护设备、人身、环境、工艺连续性和产品质量。

因此，OT安全的第一性问题不应表述为“怎样阻止所有攻击”，而应表述为：

在设备故障、账号失陷、软件漏洞、供应商误操作或Agent判断错误发生时，怎样确保事件不会越过可接受的物理后果边界？

这一变化会重排安全建设优先级。

对一台办公电脑，隔离终端可能只是影响一名员工；对正在控制连续生产过程的工程站，贸然隔离可能造成停机、压力波动或设备损坏。对普通应用，及时自动打补丁通常是好事；对经过验证的PLC、DCS或安全系统，未经停机窗口和兼容性验证的升级本身也可能成为事故源。

所以，OT安全不能简单复制IT侧的“扫描—修复—隔离”自动化，而应采用资产—通信—工艺—后果—控制措施的因果链。

二、资产清单不是Excel名单，而是可运行的生产关系图

很多企业声称已有资产台账，实际内容只有IP地址、设备名称和采购年份。这种名单可以满足盘点，却难以支持风险处置。

面向安全与Agent运行时的OT资产记录，至少应包含六类信息。

1. 身份信息

包括资产唯一标识、设备类型、厂商、型号、序列号、IP/MAC地址、物理位置和所属产线。对于虚拟化控制系统、容器和边缘节点，还需要记录实例、镜像和宿主机关系。

2. 软件与供应链信息

记录操作系统、固件、应用版本、驱动、第三方组件、补丁状态、软件物料清单，以及安装包和配置文件来源。只有知道设备内部运行什么，漏洞情报才可能与现场资产准确关联。

3. 通信关系

明确设备与PLC、SCADA、历史数据库、MES、云服务和供应商远程平台之间的正常通信。资产本身的重要性有限，资产之间的连接才构成攻击路径。

4. 责任与访问关系

记录资产所有者、工艺负责人、维护团队、供应商、远程访问方式、账号类型和审批责任人。许多遗留设备不是“无人管理”，而是组织中没人能清楚说明谁有权改变它。

5. 工艺与安全关系

记录设备控制什么过程、停机影响、允许维护窗口、冗余方式、手动接管方法，以及是否与安全仪表系统、联锁或关键质量参数相关。

6. 生命周期状态

区分在运、备用、调试、临时接入、停用待拆和已退役资产。长期插在交换机上的“临时工程电脑”、供应商测试网关和被遗忘的摄像头，往往正是清单缺口。

因此，真正有用的资产清单更接近一张持续更新的知识图谱，而不是年终盘点文件。它需要表达“谁连接谁、谁控制谁、谁维护谁、失效后影响什么”。

三、如何建立可信资产底座：被动发现为主，多源校验为辅

OT环境不能为了盘点而随意主动扫描。老旧控制器、串口网关和专有协议设备可能无法承受IT式高频探测。更稳妥的技术路径是分层实施。

第一步：汇总已有事实

从交换机配置、DHCP、ARP、工程站项目文件、PLC清单、SCADA标签、CMMS/EAM、采购系统、供应商合同和备份系统中抽取资产。不要假设任何一个系统是真实全量数据源，应保留来源和更新时间。

第二步：部署被动网络发现

在合适的交换节点使用镜像流量、网络TAP或现有传感器识别工业协议、端点和通信关系。被动方式对生产影响较小，也能观察“实际上正在通信”的资产。

但被动发现也有限制：长期不通信的备用设备可能不可见；串行网络、独立控制岛和单向网闸后的资产也可能缺失。

第三步：开展受控主动核验

对被动方式无法识别的区域，在设备厂商和工艺团队参与下，使用限速、白名单和维护窗口进行主动查询。任何扫描都应先在代表性环境验证，并准备停止条件。

第四步：与物理现场核对

网络数据无法发现未联网设备、错误端口标签和被临时替换的硬件。安全、自动化、设备和生产人员应共同抽查现场，并把差异回写系统。

第五步：建立持续变更机制

资产清单不是一次性项目。新设备接入、固件升级、网络路径变化、供应商远程会话和PLC程序下载都应触发变更记录。企业可以把以下事件定义为自动校验信号：

新MAC地址或新协议出现；
设备固件、证书或配置变化；
原本固定通信关系发生偏移；
非维护窗口出现工程协议写操作；
临时资产超过批准有效期；
停用资产仍在发送流量。

资产可见性的关键指标不只是“数量”，还应包括最近验证时间、信息完整度、来源一致性和责任人确认率。

四、把资产映射到风险，不能只看漏洞分数

通用漏洞评分无法直接表达工业后果。

一台存在高危漏洞但位于隔离测试区的设备，优先级可能低于一台没有公开高危漏洞、却使用共享管理员账号并直接控制关键工艺的工程站。OT风险至少应考虑：

[
风险 = 暴露可能性 \times 可利用性 \times 工艺后果 \times 恢复难度
]

其中“工艺后果”包括安全、环境、质量、产能和供应链影响；“恢复难度”包括是否有备件、配置备份、替代控制方式和现场技术人员。

企业可以进一步建立资产关键度分级：

A级： 失效可能造成人身、环境或重大设备后果；
B级： 影响关键产线、能源系统或长周期连续生产；
C级： 影响局部工位，可通过冗余或人工方式恢复；
D级： 实验、开发或低影响辅助资产。

分级之后，安全策略才有现实依据。A级资产可能禁止Agent执行任何写操作；B级资产允许Agent生成方案，但必须双人批准；C级资产可在维护窗口执行部分自动化；D级资产则可以作为Agent安全自动化的试验区。

五、Agent进入OT后，新增的不是一个账号，而是一类行动主体

传统安全工具主要负责发现和告警，Agent则可能进一步调用API、修改防火墙规则、禁用账号、隔离终端、创建工单，甚至与工业数据平台和边缘控制系统交互。

这意味着Agent不应只被看作软件功能，而应被视为一种具有身份、权限、记忆、工具和行动能力的非人主体。

OT Agent的攻击面至少包括：

提示注入诱导Agent改变原任务；
被污染的日志、工单或设备描述进入上下文；
工具参数被错误生成；
凭据泄漏或权限范围过大；
模型误判导致错误隔离；
跨会话记忆保存错误事实；
第三方工具或MCP服务被替换；
多Agent委托造成责任链不清；
运行时升级后策略发生漂移。

因此，企业不能只问“模型准确率多高”，还要问：它能调用哪些工具、针对哪些资产、在什么时间、以什么参数、得到谁的批准，以及失败时如何撤销。

六、Agent运行时控制应形成七层防线

1. 独立身份

每个Agent、子Agent和工具连接器都应具有独立机器身份，禁止共享个人管理员账号。凭据采用短时令牌或动态授权，不把长期密钥写进提示词、脚本和日志。

2. 最小工具集

默认不给Agent通用Shell、全网扫描和任意写接口。根据任务提供最小工具，例如只读资产查询、特定工单创建、指定网络区的会话终止。工具数量越多，组合风险越大。

3. 资产范围约束

权限必须绑定资产清单中的对象、区域和关键度，而不是只有粗粒度网络权限。例如Agent只能读取某厂区C级资产日志，不能因为接口相同就访问安全PLC。

4. 语义策略判断

传统访问控制只判断“谁调用哪个API”，但Agent安全还要判断“为什么调用、参数是否合理、前序证据是否充足”。

例如，Agent请求隔离工程站时，运行时需要确认：

该设备是否正在控制生产；
是否存在冗余控制路径；
告警是否经过第二信号源验证；
当前是否处于维护窗口；
是否已获得指定角色批准；
隔离动作是否有回滚方案。

5. 人在回路与双人批准

不是所有动作都需要人工确认，否则Agent只会变成慢速聊天机器人。但改变PLC逻辑、隔离关键控制器、修改安全规则、关闭远程访问和部署补丁等高后果动作，应设置人工批准，必要时要求安全与生产双角色确认。

6. 执行沙箱与结果验证

工具调用应通过受控代理层执行，对参数进行模式校验、范围限制和速率控制。动作完成后不能只相信接口返回“成功”，还应从独立数据源验证系统状态，并在偏离预期时自动停止后续步骤。

7. 不可抵赖审计与回滚

日志应记录任务发起者、模型与策略版本、使用的数据、工具调用、批准人、执行结果和后续验证。关键配置修改应提前备份，并明确回滚时间目标。没有回滚能力的自动化，不应获得生产写权限。

七、Agent不应直接跨越的红线

现阶段，以下动作原则上不适合交给通用生成式Agent自主完成：

修改安全仪表系统和硬件联锁；
绕过急停、门禁或速度监控；
在生产运行中直接改写PLC逻辑；
无维护窗口自动更新关键控制器固件；
因单一模型告警隔离关键设备；
自主降低网络分区或访问控制强度；
自主恢复被安全策略封禁的高权限账号；
在缺少资产与工艺上下文时执行全网处置。

更现实的成熟路径是“先读后写、先低后高、先影子后闭环”：

让Agent进行资产查询、告警解释和证据归并；
再让Agent生成处置建议与工单；
在低风险环境中允许经过批准的有限动作；
通过影子模式比较Agent建议与人工决策；
只有当错误率、回滚和审计均达标后，才扩大自动执行范围。

八、数据与工程约束决定安全Agent是否可信

Agent要判断一条OT告警，至少需要资产身份、通信基线、漏洞情报、维护计划、工艺状态、身份日志和历史事件。现实中这些数据通常分散在SOC、CMMS、SCADA、工程文件和供应商系统中，命名也不一致。

企业必须处理四类约束。

数据时效性： 资产位置和运行状态可能已改变，过期上下文会让Agent作出“逻辑正确、现场错误”的决定。

语义一致性： 同一设备可能在采购系统、SCADA和网络监控平台中使用三个名称，需要稳定的资产ID和映射关系。

证据质量： 模型生成的摘要不能替代原始日志。关键结论应能够回溯到数据源、时间戳和采集方式。

现场可恢复性： 自动动作必须考虑备份、备件、人工操作步骤和恢复时间。如果系统能一键隔离却无法可靠恢复，它只是把网络风险换成生产风险。

OT侧还常存在老旧操作系统、停产软件、厂商专有协议和极少维护窗口。安全建设不应把“无法立即打补丁”等同于“什么也不能做”，而应采用网络分段、应用白名单、远程访问控制、跳板机、协议监测、配置备份和补偿性措施。

九、产业判断：OT安全将从检测平台转向“资产事实+运行时治理”

Honeywell报告中“88%自认成熟、21%拥有完整清单”的反差说明，市场短期内最稀缺的不是更炫的自主防御，而是可信资产底座。

未来OT安全平台可能沿着三条线收敛：

第一，资产发现、固件分析、网络关系和工艺关键度将逐渐合并。单纯列出IP或漏洞数量无法支撑风险优先级。

第二，SOC将从接收OT告警转向理解生产后果。安全团队需要知道一次隔离会不会停止压缩机、机器人单元或整条包装线。

第三，Agent能力会嵌入现有安全平台，但写权限扩张会比市场宣传更慢。高价值场景首先是调查辅助、资产归并、告警解释、攻击路径分析和工单编排，而不是让通用Agent自主接管控制网络。

最终竞争壁垒不是谁先接入大模型，而是谁拥有持续更新的资产图谱、工业协议证据、动作策略、工艺知识和可靠回滚能力。

十、企业行动建议：用90天建立最小可信闭环

第1—30天：看清关键资产

选择一条关键产线或一个厂区作为范围；
汇总网络、控制、设备、采购和维护数据；
标记关键控制器、工程站、远程入口和安全系统；
确认责任人、备份状态和手动恢复方法；
以现场抽查验证资产记录。

第31—60天：建立通信和后果关系

部署或复用被动网络监测；
绘制正常通信关系和跨区连接；
将资产映射到生产单元、质量与安全后果；
发现共享账号、未审计远程访问和临时设备；
为关键资产确定允许动作和禁止动作。

第61—90天：以只读Agent验证运行时治理

只开放资产查询、告警归并和工单建议；
为Agent配置独立身份和最小权限；
对输入来源、工具调用和输出保留审计；
使用历史事件开展回放测试；
比较Agent建议与安全、自动化及生产团队判断；
未证明准确性和可恢复性前，不开放生产写权限。

OT安全的成熟度不能用采购了多少产品衡量，而应由几个更直接的问题检验：关键资产是否真的看得见，异常通信是否能被发现，高风险动作是否会被拦截，停机时是否能恢复，Agent做过什么是否能够完整追溯。

资产清单是事实层，工艺后果是决策层，Agent运行时控制是行动层。三层缺一不可。没有资产事实的Agent只是猜测，没有后果模型的自动化可能放大事故，没有运行时控制的智能体则会成为一个权限过大的新攻击面。

工业智能