上个月去一家新能源电池厂做安全调研设备科负责人拍着胸口跟我说“咱们车间PLC都是物理隔离不联网安全得很。”我拿工程笔记本借了现场一个空闲交换机口跑了十来分钟端口扫描然后当着他把车间里十几套PLC的型号、固件版本、开放端口、上位机IP一条条念了出来。他愣了几秒问我“这些工具现在随便什么人都能下到吗”我说“不用下工具把目标描述清楚AI脚本几分钟就能生成一个。”这句话之后差不多一整个下午我们都在聊同一个话题AI脚本正在如何改变PLC攻防的成本结构以及国产工控在这种变化里为什么正在从“替代选项”变成“安全刚需”。这篇文章是我这段时间在现场、在技术社区、在厂商走访里整理出的一些观察核心是想跟同行们把三件事聊透AI到底怎么打PLC、PLC为什么这么容易被打、以及我们这些用PLC吃饭的人现在该怎么想、怎么做。1. AI攻击PLC的威胁画像自动化脚本如何把门槛砸掉1.1 从“国家级选手”到“人人可跑脚本”业内聊PLC安全永远绕不开Stuxnet那个级别的样本。那时候大家的共识是能打进工控系统的人要么有国家背景要么是深耕工控协议多年的顶尖研究员。要逆向固件、要反汇编梯形图逻辑、要理解S7comm的私有结构知识壁垒高得吓人。但这个壁垒正在被AI拆掉。拆的方式不玄乎就是两件事一是AI辅助代码生成二是AI辅助协议分析。以前要读懂Modbus TCP报文你得自己抓包、翻协议规范、手动构造报文。现在你把需求说清楚——“写一个Modbus TCP客户端轮询站号1到10读出保持寄存器地址100到120”AI几秒就能给你一段能跑的脚本。以前要分析一个私有的PLC固件漏洞得花几个星期做逆向现在AI可以辅助做交叉引用分析、自动提取可疑函数、快速匹配已知漏洞模式。我关注到很多行业社区里“ai自动化挖漏洞脚本”这个词的热度明显在涨。这已经不是一个概念而是大量脚本挂在各种平台上夜以继日地扫描暴露在公网的工控端口。这类脚本不挑食502Modbus、102S7comm、4840OPC UA、9600OMRON FINS都在扫描范围内扫到弱口令、未授权访问、明文协议服务就直接拿下。对多数工厂来说这比一个针对性的国家级攻击更可怕——后者是有人盯上你前者是满世界撒网你根本不知道哪天会被捞起来。1.2 一条完整的AI攻击链条是怎么走通的在一次合规授权的安全测试里我完整复盘过一条针对某车间PLC的攻击路径今天拆开讲给大家。整条链路由五个环节组成资产测绘攻击者用互联网空间测绘平台按城市、端口、厂商指纹筛选暴露的PLC设备。指纹识别通过Banner信息、模块型号、开放的端口和协议判断目标设备是西门子S7-1200、三菱FX系列还是汇川AM系列、信捷XC系列。漏洞匹配AI自动关联已知CVE和公开EXP。没有现成漏洞就试默认口令、未授权的Modbus功能码读写多数目标在这一步就倒了。利用与持久化借助Snap7这类工业通讯库直接读写DB块、MB块甚至远程启停PLC。更极端的直接改写梯形图逻辑或者把触摸屏画面换掉实现“合法操作非法效果”。影响物理过程改变频器频率、篡改PID参数、替换配方数据——到这一步设备损坏、产能报废、安全事故都只是时间问题。这条链路里前四步基本都能靠AI脚本辅助完成。攻击者甚至不需要理解每一行的含义只要知道怎么描述目标剩下的交给生成式AI去补全。换句话说过去做一个能打PLC的脚本可能需要一个团队干几个月现在一个人加上一台笔记本可能一个周末就能搞定。1.3 为什么说“我不联网”是最危险的想法做调研时最常听到的一句话就是“我们PLC不联网”。但现实是产线为了做数据采集PLC上了工业以太网连接MES数据库MES和办公网之间有数据同步办公网有人上互联网。这就是我常说的“三跳就能通互联网”PLC一跳跳到采集服务器采集服务器一跳跳到MESMES一跳跳到互联网出口。中间只要有一台机器配置不当攻击者就能顺藤摸瓜。很多工程师在搜“西门子PLC与施耐德变频器Modbus通讯”“PLC控制32台变频器程序设计”这类关键词说明工业现场里Modbus的总线架构极其普遍。PLC做主站、变频器做从站一根双绞线串到底是最经典的玩法。但很少有人想过一个问题Modbus报文一个字节都不加密所有寄存器都是透明可见的。攻击脚本只要顺着总线扫一遍站号就能把每一台变频器的频率、电流、状态全部读走然后直接写寄存器把频率改成工艺范围之外的值。AI脚本要做的只是把这一步自动化、批量化而已。2. PLC的脆弱是结构性的协议债、长寿命和破防的边界2.1 协议债几十年前的“信任模型”还在裸奔PLC脆弱不是我一个人的观察它是底层设计带来的结构性问题。以Modbus为例这个协议1979年诞生于Modicon设计目标是工业现场的可靠通讯从来就没把“安全”这两个字纳入考虑。它假设所有挂在总线上的设备都是可信的主站问从站答主站写从站改。没有身份认证、没有权限分级、没有加密校验、没有时间戳防重放。功能码03读保持寄存器功能码06写单个寄存器功能码16写多个寄存器——这些都是公开写在协议规范里的能力谁拿到访问权谁就能直接操作现场设备。西门子的S7comm也好不到哪去。早期的S7-300/400通讯设计完全基于车间内的物理信任只要网络可达很多操作连密码都不需要。到了S7-1200/1500加入了PLC访问保护机制但默认配置下如果工程师不主动开启数据读写的门槛依然很低。更有意思的是Snap7这个开源库让西门子PLC的通讯不再是少数人的秘密任何懂Python的人都能用它连上PLC读写数据块。协议层面的债靠修修补补是补不完的因为底层压根没有加密身份体系。我经常跟搞IT安全的朋友说你们IT系统的漏洞是“软件bug”PLC的漏洞是“协议天生没有安全基因”。前者可以打补丁后者意味着你所有的防护都得靠外部环境来补。把攻击面收敛这件事在PLC世界里比在IT系统里困难得多因为你不能轻易改协议改了就会破坏与老旧设备的兼容性。2.2 长生命周期设备还在跑漏洞已经老掉牙PLC不是手机不是两年一换的消耗品。它的设计寿命通常在15到30年很多产线上的PLC从建厂就开始服役中途可能连固件都没升级过。和IT设备“发现漏洞—推送补丁—强制更新”的节奏完全不同PLC的固件更新需要协调产线停机窗口需要提前验证对工艺逻辑有没有影响需要承担“更新完设备反而启动异常”的风险。所以现实是这样的现场跑着2010年固件的S7-3002015年固件的三菱FX5U2018年固件的汇川H5U——厂商早就不提供维护支持的旧版本漏洞列表却一长串。AI攻击脚本不需要多高深的利用技术只要扫描到老版本固件自动匹配已知漏洞成功率极高。这不是工程师不愿意更新而是工控场景的固有矛盾稳定性压倒一切停机一小时可能损失几十万。这个矛盾在AI时代会被无限放大因为攻击者利用漏洞的速度已经快过你安排停机窗口的速度。2.3 网络边界已经破了OT和IT早就分不开了工业圈子里流行一句话“物理隔离是最大的谎言。”早年确实有不少工厂是真隔离PLC网段和办公网段物理断开想远程维护就派工程师开两小时车到现场插笔记本。但随着数字化改造推进远程监控、数据上云、预测性维护成了刚需OT网络和IT网络之间的通道越开越多。工程师要远程给PLC下程序现场要往云端数据库推数MES要从PLC采集产量数据视觉检测系统要和PLC做IO联动——每一个应用场景背后都是新的网络通路。有人用TIA Portal在虚拟机里连PLC调试有人通过远程桌面处理触摸屏故障有人拿OPC UA把设备数据全部接到上位机。数据打通确实提升了效率但也在攻击者面前铺开了一张巨大的攻击地图。做OT网络安全评估时我有个习惯先看网线跳线。很多工厂说“VLAN隔离了”“防火墙策略做好了”结果跑到机柜一看交换机上两根飞线直接把两个网段物理旁路了。这种情况下AI脚本扫到内网一台跳板机的脆弱服务就能横向移动到PLC网段所有所谓的安全设计瞬间归零。3. 国产工控分水岭从“备胎逻辑”到“安全刚需”3.1 那些年国产PLC凭什么只能当“备胎”我刚入行做自动化那会儿甲方提出用国产PLC基本默认是“预算不够”或“交期太紧”。西门子、罗克韦尔、施耐德在行业里积累了二三十年口碑生态成熟资料齐全出问题能找到大量案例参考国产PLC价格便宜、交货周期短、本地服务响应快但很多老工程师心里不踏实——程序兼容性怎么样通讯稳定性行不行社区资源够不够坏了能不能快速找到人在这种心态下国产PLC的入场路径多半是边缘工位——做个辅助设备控制、做个小型包装机逻辑、做一条不太重要的辅助线。真正关键的产线依然默认选进口品牌。即便国产PLC运行几年也稳定可靠它在大众心智里依然是个“备胎”能用但谈不上非它不可。3.2 四个推手把“备胎”变成了“安全刚需”这个局面过去一两年在悄悄转变。我复盘了手里的项目总结出四个实际起作用的变化第一威胁密度变了。AI脚本让攻击从“定向狙击”变成“地图炮式扫描”没有谁的小厂是安全的。威胁面前防护能力取决于响应速度。进口PLC出了安全问题通常要等海外厂商逐级响应本地代理提交工单、海外总部评估漏洞、发布补丁、协调停机窗口。这个流程走完少说一个月。国产PLC厂商很多研发团队就在国内出了事三天到现场、两周出临时加固方案这是实打实的差距。第二供应链的确定性比品牌更重要。芯片供应、固件授权、技术升级路径任何一个环节被卡住都会影响产线长期稳定。很多客户开始把“设备可维护性”和“供应安全性”纳入选型评估项国产PLC在这一项上的得分越来越高。第三合规考核倒逼自主可控。国家等级保护制度对工控系统安全提出了专门的合规要求关键信息基础设施运营者在设备选型时必须把安全可控性作为硬指标。进口设备在代码透明度、日志对接、后门排查等方面配合度有限国产设备在这条赛道上天然占优。第四安全要的不是“黑盒”是能一起改的设备。AI攻击手段迭代太快安全团队遇到新威胁时需要设备厂商配合调试要日志格式、要远程诊断接口、要定制安全策略。国产厂商的商务和技术通道更短愿意派工程师到现场一起改配置、写补丁这种响应能力在安全事件中就是黄金救援时间。3.3 一个真实案例安全整改里的速度对比我在某个汽车零部件客户现场做安全整改时对比特别直观。现场主线用的进口PLC固件存在已知漏洞需要升级。从提出需求、等待厂商评估、协调专家时间到预约停机窗口做升级验证前前后后拖了将近两个月。期间安全测试报告就压在那边谁都不敢上线。同期新建的一条检测线用了国内某品牌的PLC安全评估发现密码保护策略比较弱、通讯没有加密厂商工程师接到反馈后三天就到现场两周之内提供了一个定制固件把密码策略、登录失败锁定和通讯加密全加上了。对比下来甲方设备部长感慨“不是我们以前不想支持国产是安全能力接不住。现在接住了感觉完全不一样。”这个案例让我理解了一件事安全刚需不是靠情怀建立的是靠响应速度和定制能力建立的。3.4 过去的对比表现在看起来已经变了维度过去选进口的理由今天的新变量稳定性品牌沉淀久案例充分国产PLC长期运行数据也已充足生态编程软件、资料、案例完善国产社区、AI辅助代码生态快速补齐响应速度有体系但流程长AI威胁下黄金救援窗口越来越短供应链默认可靠芯片、固件、升级授权的不确定性增加安全可控黑盒只能信任AI攻击下需要设备开放、可审计、可定制4. 得接得住需求才算刚需国产PLC的安全课要补什么4.1 协议安全设计不能继续走老路说句实话国产PLC如果要接住“安全刚需”这顶帽子现在的产品力还不够。我看过好几家国产品牌的手册和实际设备通讯仍然以明文Modbus为主部分高端系列提供了加密通讯但默认不开启配置复杂到很多工程师根本不知道有这功能。有的PLC虽然有密码保护但密码直接以明文形式存储在编程软件配置文件里用文本编辑器打开就能看到。还有的产品把调试接口暴露在公网上配合官方文档里的初始口令等于把钥匙挂在门口。要真正配得上“安全刚需”国产PLC厂商应该把安全设计内建到产品里而不是当成选配功能。底线上至少要支持通讯加密、双向证书认证、安全启动、固件防回滚、登录密码强度策略。这些能力不是营销噱头是IEC 62443-4-2产品安全标准里明确在列的硬性要求。再不追用户用脚投票的动作会越来越快。4.2 漏洞响应生命周期几乎是空白大多数国产PLC厂商没有建立安全应急响应机制。我问过几家销售人员“如果客户发现你们的PLC存在安全漏洞他们通过什么渠道联系你们”得到的回答大多是“直接找销售啊”“打400电话”。问题就在这里漏洞响应不能靠销售转达应该有专门的安全团队接收漏洞报告、验证影响、评估风险、发布安全公告、推送固件补丁。这个过程在行业里叫安全开发生命周期。PLC厂商需要把安全融入产品研发的每个阶段而不是等产品卖出去之后才被动响应。我经常跟厂商朋友说安全公告写得慢不代表问题不存在只代表用户在裸奔。对用户来说没有漏洞信息的设备比有漏洞信息的设备更危险——因为前者让你误以为安全。4.3 和SOC、态势感知平台的联动能力太弱工控安全运营有个基础需求设备的运行状态、通讯日志、异常告警要能全部上报到集中的安全管理平台。现实是很多国产PLC根本没有日志上报功能连SYSLOG都不支持。你问运维工程师“这套PLC今天有没有被异常访问过”他只能愣住因为PLC本身不记录、也不上报。OT安全不是买一个盒子就能解决的它需要设备端有“被监测”的能力。PLC要能输出通讯日志、诊断日志、事件记录同时支持日志导出或远程上报协议。如果设备本身是个哑巴安全团队只能靠外接镜像流量做被动检测效果会大打折扣。安全刚需时代PLC厂商如果能把被监测能力当作产品功能来设计会是一个很强的差异化卖点。4.4 编程软件本身也是攻击面TIA Portal、GX Works、汇川AutoShop这类PLC编程软件本质上是运行在工程师电脑上的应用程序。它们拥有上传、下载、监控、修改PLC逻辑的完整权限一旦被植入恶意代码就等于拿到了工厂的“数字总钥匙”。AI脚本也能针对这类软件做供应链攻击——修改安装包、替换DLL、植入木马工程师一打开PLC的下发通道就变成了攻击通道。国产PLC厂商要补的课包括但不限于编程软件代码签名、软件完整性校验、升级包的加密传输、对调试接口做双向认证。这套体系虽然投入高但它关乎的是整个产品生态的信誉也直接影响“安全刚需”这四个字的含金量。5. 不用等厂商一线工程师先动手的防御清单5.1 第一步把PLC资产盘清楚没有资产清单谈安全就是空中楼阁。花一周时间把每条产线、每个车间里所有PLC的型号、固件版本、IP地址、MAC地址、开放的端口、启用的协议、连接的上位机、负责的维护工程师全部列成一张表。这块工作不性感但它是一切安全动作的地基。我用过的办法是拿Excel建台账然后配合主动扫描工具做资产比对保证不漏项。你连自己家有多少PLC、跑什么协议都不清楚AI扫描器可比你清楚。5.2 第二步网络分域和访问收敛给PLC网段单独划分VLAN在核心交换机上用ACL精确控制哪些IP可以访问PLC的哪些端口。远程维护必须经过跳板机堡垒机配合双因素认证禁止任何形式的直连。所有跨网段访问都要留日志至少保存6个月。这一套动作做完攻击者横向移动的难度会翻好几倍。需要注意工业网络的防火墙策略不是“写完就完事”过一段时间就要回访产线新增了哪些设备、哪些地址段改了。现场工程师经常为了调试方便临时放通一条策略调试结束就忘了删——这种残留策略是最容易被AI脚本利用的。大扫除应当每个季度做一次。5.3 第三步基线加固把默认的破口堵上这一块不需要厂商配合现在就能动手修改所有PLC、触摸屏、编程软件的默认口令和默认密码策略强密码是底线。关闭不使用的服务FTP、HTTP、Telnet这类老服务在PLC上出现就是攻击面能关就关。不使用的PLC通信端口一律禁用。固件做升级前先拿备件或实验室环境验证确认对工艺没有影响再上产线。备份PLC梯形图和参数配置备份文件要加密存放不要随手放在共享文件夹里。5.4 第四步部署基础监测能力PLC网段至少要有一台能镜像流量的设备把流量喂给工业防火墙或入侵检测系统。策略先做白名单只允许已知主站和PLC之间的协议交互不在白名单里的流量一律告警或阻断。有精力的话结合AI日志分析工具训练流量基线等协议数据出现异常就能告警至少能知道“有人在扫PLC”了。我之前给一个客户做监测方案交换机镜像口接了一台NUC跑检测规则两周之内抓到了三次异常扫描——其中两次来自办公网某台被感染的电脑一次来自车间里的第三方调试笔记本。这些风险如果没监测工具可能要等到设备真正出故障才会被发现。5.5 第五步工程师自己要学会用AI当防守武器很多人怕AI、抵触AI担心被替代。我的看法是既然AI脚本能用来攻击它也一定能用来防守。我平时会让AI帮我解读抓到的异常流量包、生成检测规则、检索某个PLC型号的历史漏洞信息、快速翻译一份英文安全公告。这些工作以前要花一个下午现在半小时内能搞定。工控安全工程量缺口太大AI不是对手是杠杆。写在最后写到这里我回忆起那家工厂整改完的场景。我们做的第一件事是把所有PLC的默认口令改掉把502端口的公网映射全部封禁。那位设备科负责人后来发消息跟我说“以前觉得安全是给安全软件公司送钱现在觉得是给自己买保险。”我对国产工控的想法也一直很直接安全刚需不是谁赐予的是威胁环境逼出来的。前几年大家看国产PLC问的是“能不能用”现在应该问“敢不敢用”再往后核心会是“安全能不能闭环”。厂商的响应速度、定制能力、漏洞生命周期管理决定了它能不能接住这波刚需。这条路不好走但方向已经摆在那里了。