大数跨境

当AI开始挖掘零日漏洞,工业OT安全该如何应对?

当AI开始挖掘零日漏洞,工业OT安全该如何应对? 工业AI
2026-11-06
0
导读:AI 漏洞挖掘浪潮下的工业网络安全警示

数十年来,网络安全攻防如同一场持续的军备竞赛:攻击者不断寻找系统薄弱点,防御方则力争在漏洞被利用前完成排查与修复。过去,攻防双方都受制于专业人才稀缺、技术门槛高、漏洞挖掘耗时长等现实约束。而人工智能(AI),正在重塑这套博弈规则。

2026 年 4 月,Anthropic推出玻璃之翼计划(Project Glasswing),联合多家大型科技机构,依托Claude Mythos预览版AI模型开展漏洞识别与修复工作,成果十分突出。截至2026年10月,参与项目的各方累计确认发现至少12.9万个软件漏洞,其中数万个属于高危、严重级别。这一结果证明,AI可以极大加快软件缺陷挖掘速度,而很多存在漏洞的软件,已经在企业现场服役多年、甚至数十年。

这套技术能力,对运营技术(OT)领域的冲击尤为突出。工业控制系统支撑着工厂生产、电力输配、水处理、油气、轨道交通等关键基础设施。大量这类系统搭载老旧软件与操作系统,不像普通信息技术(IT)系统那样,可以便捷、频繁地安装补丁更新。

IT系统被入侵,大多造成信息泄露、线上业务中断;但一旦工业OT系统遭到攻陷,可能引发生产停摆、设备损毁、物料污染、公共基础设施瘫痪,甚至直接带来人身安全风险。

因此,这种能够以空前速度挖掘、验证漏洞的AI工具,必须引起工业资产方、设备供应商的高度重视。但这不代表行业需要推倒重来、搭建全新安全体系。ISA/IEC 62443 系列标准早已形成一套国际公认的完整框架,用于在工业自动化控制系统全生命周期内管控网络安全风险。当下真正的难点,是企业要跟上威胁变化的节奏,把标准要求落地到位。

什么是 Claude Mythos 和玻璃之翼计划?

二者紧密关联,但定位不同:Claude Mythos是由Anthropic研发的一款AI模型,玻璃之翼计划是基于该模型、面向防御侧的网络安全专项项目。

传统漏洞扫描工具,大多只能识别已知漏洞、匹配预设的风险特征;而Claude Mythos能够深度解析复杂软件,梳理各个组件之间的交互逻辑,发现过去无人知晓的缺陷,还可以生成验证漏洞可被利用的演示方案。

传统漏洞管理严重依赖已知漏洞数据库,如通用漏洞与暴露,以及软件补丁和安全公告。然而,这些方法无法识别每一个尚未被发现或公开披露的漏洞。能够分析软件并识别此前未知漏洞的AI系统,可能显著改变这一局面。

Anthropic在发布玻璃之翼计划时提到,Mythos预览版已经挖掘出数千个此前未公开的漏洞,覆盖主流操作系统、浏览器,部分漏洞已经潜伏数十年。AI的价值不只是挖出更多漏洞,更在于大幅降低漏洞挖掘的时间、成本和专业门槛。这项能力如果掌握在防御方手中,可以显著提升安全能力;但一旦落入恶意攻击者手里,风险也会急剧放大。

玻璃之翼计划于2026年4月启动,初衷是把Mythos的能力用于安全防御。项目初始成员包含多家大型科技企业,覆盖市面广泛使用的软硬件、云基础设施和安全产品。项目初期采用受控开放模式,邀请合作机构使用Mythos预览版排查自身产品和基础设施漏洞。2026年6月,项目扩大范围,新增约150家机构,覆盖电力、水务、医疗、通信、硬件基础设施领域。

同年10月,Anthropic上线扩展后的安全验证计划,符合资质的安全人员可调用 Claude Mythos 5.1等高阶模型。公开信息显示:2026年4–7月,项目参与方累计确认至少12.9万处漏洞,其中超3.3万个为高危或严重漏洞。

需要说明:这些统计数据来自各类通用软件与基础设施,并非专门针对工业控制系统,不能理解为已有大量工业系统遭到入侵。但这项技术能力本身,给OT系统明确敲响了警钟:今天用于防御的漏洞挖掘技术,未来有可能被攻击者掌握。


为什么工业OT比传统IT更需要警惕这类风险?

工业自动化控制系统本身的几个特点,放大了AI漏洞挖掘带来的威胁:

· 工业设备服役周期极长

很多工业装置、控制器连续运行15年、20年,甚至30年。不少PLC可编程逻辑控制器,底层操作系统、依赖库、通信协议早已停止维护,但设备本身仍在线承担生产任务。工厂资产台账往往新旧混杂,部分设备早已不再获得厂商安全支持,系统内长期隐藏着未被发现的漏洞。Mythos 这类工具的出现,意味着这些沉睡多年的漏洞,可以被快速识别。一个潜伏20年的缺陷,一旦被掌握利用方式,就不再是无害问题。

这也凸显了ISA/IEC 62443‑2‑1的价值:该标准明确资产所有者的工业安全管理要求,包含资产管理、风险评估、漏洞闭环、常态化安全运维;ISA/IEC 62443‑3‑2则规范网络安全风险评估与系统设计。企业不仅要摸清自己有哪些系统,还要评估系统被攻破之后会造成什么后果。

· 打补丁往往很难,甚至无法实施

在普通IT环境,安装安全补丁相对简单;工业场景完全不同。软件升级往往需要停产,还可能引发兼容性故障、打乱经过验证的控制逻辑,甚至影响安全联锁。很多工业设备只能等待年度 / 季度计划停机窗口才能更新;还有部分设备厂商已经停止服务。AI加快漏洞发现速度后,企业会面对一大堆待处置漏洞,却没办法立刻打补丁修复。

这时补偿防护措施就至关重要。ISA/IEC 62443‑3‑3定义系统安全要求,包含数据流管控、访问权限、系统完整性与可用性。就算硬件、固件无法升级,企业也可以依靠这些手段缩小攻击面、降低风险。

举个例子:一台无法打补丁的控制器,可以通过网络分区、严格限制远程访问、持续流量监控等方式防护。但补偿措施必须基于风险评估设计;防火墙不会自动让有漏洞的控制器变得安全,尤其当攻击者可以走合法通信通道接入系统时。

· 工业安全事件的物理后果远不止数据泄露

OT和IT网络安全最核心的区别,就是事故后果不同。电商网站漏洞被利用,大多是用户信息泄露、交易暂停;但化工压力控制器的漏洞一旦被攻破,会造成设备损坏、危险物料泄漏,引发重大安全事故。

ISA/IEC 62443‑3‑2的风险评估方法,会综合威胁、漏洞、发生概率、事故后果,确定对应的安全等级。AI辅助攻击不会改变出事之后的物理危害 —— 不管攻击者用传统手段还是AI,泵、阀门失控的结果是一样的。但AI会降低攻击门槛,提升这类事故发生的可能性。

企业应当重新复核现有风险评估,检查过去对攻击者能力、漏洞可利用性的判断是否还成立。这不代表所有系统都要盲目提高安全等级;ISA/IEC 62443‑3‑2倡导基于风险的思路,要结合威胁、漏洞、现有防护、潜在损失综合判断。

AI会催生哪些工业攻击场景?

下面以Claude Mythos模型为例,展示了一些具备合理性的工业推演场景。

场景一:挖掘 PLC 固件漏洞

某PLC厂商的控制器广泛用于制造、水务、能源行业,固件里包含多代迭代的通信服务、协议代码、第三方库。过去,想要挖出固件漏洞,需要深厚逆向工程能力、大量人工分析。

而具备Mythos级能力的AI系统可以加速固件分析,发现之前测试未曾忽视的弱点。发现此类漏洞的攻击者可能能够干扰控制器通信、导致拒绝服务,或者根据弱点和权限操作,操控控制器操作。

对设备厂商来说,这个场景凸显ISA/IEC 62443‑4‑1的重要性:标准规定了安全产品开发全流程,覆盖安全需求、安全设计、编码、测试验证、缺陷管理、安全更新。ISA/IEC 62443‑4‑2配套定义工控组件的技术安全要求。厂商需要预设:未来攻击者会拥有更强的漏洞探测能力,找到传统测试发现不了的缺陷。

场景二:入侵工程师工作站

工程工作站用于配置控制器、修改控制逻辑和维护工业自动化系统。它可能包含专用的工程软件、通信驱动程序以及与工业设备交互的库。攻击者通过被攻破的远程连接或恶意软件访问工作站。AI辅助分析能够识别工程应用或其支持组件中的漏洞。

利用可能使攻击者获得额外权限,或干扰用于配置工业设备的软件。根据系统架构和现有保护措施,攻击者可能会尝试未经授权更改控制器配置或控制逻辑。

这一情形说明了为什么网络安全不能仅仅从个别组成部分层面来解决。ISA/IEC 62443-3-2要求考虑系统架构,包括将系统划分为区域和通道。ISA/IEC 62443-3-3提供了支持防止未授权访问、未经授权修改和系统间不当通信的保护要求。工程工作站不应仅仅因为方便就自动对设施内所有控制器拥有无限制访问权限。

场景三:攻陷远程访问网关

远程访问在工业运营中变得越来越重要。设备供应商、系统集成商和维护承包商经常需要远程连接以诊断故障、更新软件或支持运营人员。

假设一款工业远程网关被几百家工厂使用,AI挖出了网关软件里的零日漏洞。如果该漏洞支持越权访问,攻击者就可以批量入侵所有部署同款网关的站点。

实际危害取决于网关部署位置、网关能访问哪些系统:部署在独立维保隔离区的网关,和可以直接接入控制网的网关,风险天差地别。ISA/IEC 62443‑2‑4(服务商安全)、62443‑3‑3(系统安全能力)、62443‑4‑2(组件安全)搭配起来,为厂商、服务商、资产方建立一套远程访问管控体系。

场景四:水务SCADA系统漏洞

某市政水厂的SCADA系统监控水位、泵站、加药、管网压力,部分设备已经运行15年以上。攻击者借助AI挖出SCADA平台漏洞。

根据漏洞类型和系统设计,攻击者可能切断监控、干扰通信、篡改控制逻辑;轻则失去工况可视能力,重则供水中断、工艺进入危险状态。但最终危害,还取决于水厂有没有配套的工程防护措施:独立保护装置、机械泄压阀、适当的化学添加措施以及本地操作设备的能力,都能大幅降低网络攻击带来的灾难后果。

这里有一条核心思路:工业网络安全不只是 “挡住入侵者”,更要做到“就算网络防线被突破,也不会直接酿成重大安全事故”。

ISA/IEC 62443-3-2通过基于后果的风险评估支持这一方法。ISA/IEC 62443-3-3包含了系统完整性、可用性和资源管理的要求。当涉及安全仪表系统时,网络安全考虑还必须与功能安全要求协调,包括IEC 61511所涉及的相关要求。

对OT设备制造商的四点启示

玻璃之翼计划给设备制造商传递一个明确信号:过去安全测试的底层假设已经变了。一款长期没有爆出漏洞的产品,不等于安全,只是还没有被足够强大的工具充分检测。AI 辅助漏洞挖掘,让规范、闭环的安全开发流程变得不可或缺。

1. 安全开发必须常态化落地

厂商开发流程要包含威胁建模、安全设计、安全编码、安全测试、漏洞管理以及版本更新机制。AI可以作为辅助手段,帮忙审计源代码、排查依赖包、分析固件、开展安全测试。但AI输出的结果必须人工复核,警惕误报、逻辑偏差,避免AI给出的修复方案引入新故障。

工业产品的补丁,绝对不能破坏设备确定性、可靠性、功能安全和生产能力。因此AI测试只能作为现有工程验证的补充,不能替代原有流程。

2. 漏洞响应要更快、更高效

厂商需要一套完整流程:接收漏洞上报、定级评估、开发修复包、同步客户、推送更新。AI加速漏洞发现之后,厂商会收到大量漏洞报告。难点不再只是找漏洞,而是核验真伪、梳理受影响型号、评估业务影响、指导客户处置。

通用漏洞评分不能直接照搬在工业场景里:隔离内网设备上的 “严重漏洞”,和公网网关上面的 “中等漏洞”,实际运营风险完全不一样。厂商要向客户提供充足信息,支撑资产方按照ISA/IEC 62443‑3‑2做风险评估,包括受影响版本、利用条件、潜在后果、缓解方案、升级指引。

3. 软件供应链安全地位持续提升

现代工业产品大量集成第三方库、操作系统和开源组件。一个通用依赖包的漏洞,会牵连多家厂商、多款产品。AI漏洞挖掘会把这些过去隐藏在底层依赖里的缺陷暴露出来。

厂商必须清楚掌握产品内部所有软件组件。软件物料清单是重要工具,但只输出清单不等于实现安全。ISA/IEC 62443‑4‑1提供框架,用于组件管理和漏洞响应;厂商还要对照ISA/IEC 62443‑4‑2验证组件安全能力。

4. 第三方独立认证增加安全可信度

厂商可以基于ISA/IEC 62443开展独立评估与认证。ISASecure 认证可以对工控产品、开发流程做第三方核验:SDLA安全开发生命周期认证对应62443‑4‑1开发流程;组件安全认证对应62443‑4‑2技术要求。

认证不能保证产品零漏洞,但可以提供第三方佐证,证明企业已经落实规范流程与技术控制。在AI快速挖掘零日漏洞的环境下,厂商全生命周期漏洞处置能力,愈发关键。

对OT资产运营方的六点启示

OT资产运营方和制造商的处境不同:大多无法掌控产品开发流程,对厂商更新节奏的影响力有限;核心责任是理解、管控采购设备带来的安全风险。ISA/IEC 62443正好提供一套结构化框架。

1. 重新开展网络安全风险评估

优先复盘旧的风险评估报告,重新审视攻击者能力假设。比如几年前评估里认为很难利用的漏洞,理由是攻击门槛高、工作量巨大;AI的出现,直接推翻了这个前提。

资产方重新落地ISA/IEC 62443‑3‑2评估流程,重点关注一旦被入侵,会引发安全、环保、重大生产或经济损失的系统。目标不是简单把所有风险等级拉高,而是让评估结论贴合当前真实威胁、可行攻击路径、现有防护和事故后果。

2. 摸清全厂资产台账

企业无法管理自己都不知道存在的设备。一份可靠的资产清单,要记录软硬件型号、版本、部署位置、业务用途、厂商维保状态,理清系统之间的依赖关系。当多款设备共用同一个有缺陷的组件时,资产台账的价值会充分体现。ISA/IEC 62443‑2‑1是建立、维护资产管理流程的基础。台账要服务于漏洞管理和风险研判,不能只是一份存档文件。

3. 落实区域与通信通道隔离

ISA/IEC 62443‑3‑2的核心架构思路,就是把工业网络划分为安全区域和通信通道:安全区域归集安全要求相近的资产;通道管控跨区域之间的通信。攻击者拥有更强漏洞工具之后,这套架构的价值进一步放大。

就算某一台设备被攻破,架构设计也必须限制攻击者横向扩散。操作员工作站失陷,不代表攻击者可以随意访问安全相关系统、工程师站、全厂控制器。合理的网络分段、权限管控、通信白名单,能够压缩单个漏洞带来的连锁危害。隔离方案要基于 ISA/IEC 62443‑3‑2的风险评估和目标安全等级设计,并落地 ISA/IEC 62443‑3‑3 的技术要求。

4. 完善漏洞与补丁管理机制

资产方建立闭环流程:接收安全公告、判断是否影响现场、评估风险、落实缓解措施。有补丁可用时,要规划、测试后再上线,避免引发生产异常;暂时无法打补丁的,启用补偿防护:收紧通信策略、关闭闲置服务、严控远程访问、加强流量审计、增设独立硬防护。方案要结合设备属性和事故后果定制。ISA/IEC 62443‑2‑1提供组织管理框架,ISA/IEC 62443‑3‑3支撑技术防护落地。

5. 提升事件响应与运营恢复能力

AI赋能攻击,会压缩留给检测、遏制、处置的时间窗口。资产方不能假设防线永远不会被突破;必须提前做好预案:就算网络安全管控失效,依然保障安全生产、具备恢复能力。

ISA/IEC 62443‑2‑1将事件响应纳入安全管理;ISA/IEC 62443‑3‑3包含可用性、备份、恢复相关要求。工业应急预案要回答这些现实问题:SCADA 整体瘫痪怎么办?操作员能不能本地手动控制?控制器组态、程序、应用软件备份是否齐全、能不能正常恢复?常规控制失效时,独立安全保护装置是否可用?谁有权停机?厂商对接人是谁?由谁判定何时可以安全复产?

更关键的一点:预案有没有定期演练?只停留在纸面的应急方案,很难在事故中发挥作用。演练需要运行班组、维保、工程、安全、管理层、供应商共同参与,覆盖控制系统不可信、完全失效的场景。从可信备份恢复、手动操控关键工艺、依靠机电安全联锁,这些能力和查杀恶意软件同等重要。

6. 要求供应商提供更好的安全保障

资产方要更新采购准入标准,不能只看功能、价格、交付周期。要求供应商证明开发流程符合ISA/IEC 62443‑4‑1、产品满足62443‑4‑2适用条款,同时清晰说明漏洞上报、排查、修复、通报机制。

重点确认:产品安全支持周期、安全更新交付方式、第三方依赖管理、漏洞响应流程。ISASecure认证可以进一步增强可信度。这类要求不只针对新采购设备,条件允许时,也可以向支撑关键生产的存量供应商提出。

玻璃翼计划的出现并不意味着放弃既定的网络安全实践。相反,它强化了正确实施这些规则的必要性。对于OT资产所有者,首要任务应包括审查基于后果的风险评估、识别关键和无支持资产、加强系统分段、改进漏洞管理以及测试事件响应和恢复能力。

对于OT产品制造商来说,优先事项应包括加强安全开发实践、扩大安全测试、提升软件供应链可见性、加快漏洞处理,并为客户提供可操作的安全信息。

对于系统集成商和服务提供商来说,优先事项应是确保系统的设计、部署、维护和支持符合适当的网络安全要求。

AI 改变了网络安全攻防的成本逻辑

Claude Mythos最深远的一个影响,是重构了漏洞挖掘与利用的成本结构。过去,针对工业系统的复杂攻击通常需要大量资源、专业技能和充分准备。这为那些难以理解或攻击的系统提供了一定程度的实际保护。然而,复杂性本身并不等于安全防护。

AI降低漏洞挖掘成本之后,一部分过去不具备可行性的攻击,开始具备经济吸引力。这不代表任何人都能轻松攻陷电厂、化工厂。工业攻击依然需要访问权限、熟悉现场工艺、具备干预物理生产的能力;安全仪表、工艺约束、工程硬防护,依然是重要屏障。但攻防天平,已经开始倾斜。

这也让网络安全和网络韧性的边界变得更加清晰:网络安全重在预防、检测并响应未经授权的活动;网络韧性重在保证核心业务持续运转、控制事故损失和快速恢复。对工业企业而言,二者缺一不可。

ISA/IEC 62443系列标准,以风险导向管理、安全架构、产品安全、全生命周期管控为根基,为应对挑战提供了框架。但标准落地,还需要和工艺安全、功能安全、设备可靠性、运维管理、业务连续性等工程体系协同配套。

玻璃之翼计划与Claude Mythos,标志漏洞挖掘进入新时代。AI可以用几年前难以想象的规模和速度找出软件缺陷。对工业资产方和设备厂商来说,这既是机遇,也是警示。

机遇在于:防御方可以先用同类技术,在攻击者之前发现并消除漏洞;警示在于:攻击者未来同样有机会掌握这套工具。

工业企业不能抱有侥幸心理,不要觉得自己系统冷门、结构复杂就不会被盯上;也不能默认运行多年不出事的软件,就没有高危漏洞。

好在工业网络安全不需要从零搭建体系,ISA/IEC 62443已经搭建起覆盖组织、系统、产品的完整框架。关键在于持续落地、验证防护有效性,并跟随威胁变化动态更新风险评估。

工业网络安全的底层原则没有变;真正改变的,是工业企业落实这些原则的速度要求。

【声明】内容源于网络
0
0
工业AI
人工智能是一门认知科学,而工业人工智能是一个系统工程。
内容 141
粉丝 0
工业AI 人工智能是一门认知科学,而工业人工智能是一个系统工程。
总阅读272
粉丝0
内容141