★ FEATURED ARTICLE 这是信息密度极高的一篇技术解读没什么闲话可听大家都在谈工业网络的安全困境但能真正把“功能安全”和“网络安全”两条线拧到一股绳上的还是邬江兴院士这套“广义功能安全”的思路。我做了多年工控现场安全评估和加固看到这个提法的时候第一反应是“终于有人把这事儿从根上讲清楚了”。这篇文章我不打算绕弯子直接把我理解的广义功能安全、为什么传统那套不够用、院士开出的“内生安全”药方是什么以及落到咱们工程师手里到底该怎么操作一层一层拆开来说。先说清楚这篇内容适合谁。如果你在工厂、设计院、系统集成商或者安全公司干活儿天天跟PLC、DCS、SCADA打交道发现功能安全和信息安全总是各管各的、对不上话如果你正头疼怎么跟领导解释“为什么加了防火墙还会出安全事故”如果你选型安全设备时被各种“可信”“白名单”“纵深防御”的概念绕晕了那这篇文章就是给你写的。对于刚入行的新人我也会把基础概念尽量讲透保证你能跟上节奏。先给一句话结论广义功能安全就是要我们不再把“设备故障导致的停机”和“被攻击导致的失效”当成两件事分开处理而是统一放到“系统是否会按预期完成功能”的同一个框架下去评估、去设计、去度量。这不是学术口号它直接改变了我们选型、部署、运维的每一个环节。1. 工业控制网络安全困局为什么“两条腿”各走各的1.1 功能安全的“老底子”失效率思维搞工业的都知道功能安全Functional Safety的核心思想是“即使出了问题系统也能安全地进入一个可接受的状态”。它有很成熟的体系IEC 61508、IEC 61511还有各行各业的安全完整性等级SIL。这套东西的逻辑我可以用一句话概括把“失效”当成一个概率事件通过设计冗余、诊断覆盖率、故障裕度等指标把风险压到可接受的水平。这套思维的底色是“随机硬件失效”。工程师会告诉你某个安全继电器失效率是10的负7次方每小时两个并联就能到10的负9次方于是满足SIL 3的要求。它有完整的数学模型有几十年的工业积累可靠性非常高。但这个模型有个隐含的前提失效是随机的、独立的、无意识的。也就是说设备自己坏了或者是环境影响导致的坏跟有没有人故意搞破坏没关系。没人会去专门黑一个安全继电器。这种思维在过去完全成立。因为工业网络在物理上封闭协议私有懂的人少没多少人会去攻击一个汽轮机控制器。1.2 信息安全带来的新变量失效不再是“随机事件”工业控制系统联网之后事情就变了。哪怕只是一个信息采集端口暴露或者一个USB接口被插了U盘系统面临的就不再是“随机硬件失效”而是“有预谋的、定向的、反复尝试的攻击”。攻击者可以在网络上发起探测找到漏洞然后精准地把一个正常的控制指令篡改掉。最有名的例子就是针对工业设施的定向攻击手法先通过钓鱼邮件进入办公网再横向移动进入控制网最后篡改变频器或离心机的运行参数让设备在物理上损毁。整个链条里没有任何一个设备是自己“随机坏掉”的它们全是被“设计坏”的。这种失效模式传统功能安全模型完全没法评估。你没法用失效率来度量一个攻击者的耐心和智能。这就是第一张皮和第三张皮的矛盾根源功能安全假设失效是“老天爷随机安排的”网络安全面对的是“一个聪明的攻击者在主动寻找你的破绽”。两者都有道理但放在一起就是互相对不上。1.3 两张皮在工控现场的真实碰撞我见过一个很典型的案例。一个化工厂上了SIL 2等级的安全仪表系统SIS功能安全做得非常合规。但审计的时候发现操作站上还插着一个无线路由器用于厂家远程调试。网络安全工程师要求立刻拔掉生产工程师却觉得“这是为了维护方便而且我们设备在物理隔离的安全区里路由器是最近才加的”。这就是两张皮的零距离碰撞。功能安全工程师认为只要安全仪表系统本身的冗余和失效率达标整个化工装置就是安全的网络安全工程师则认为只要存在一个非授权入口整个系统都在攻击者的射程范围内。你看两边说的都有依据但结论完全相反。邬江兴院士提“广义功能安全”本质就是要把这两种视角合并成一个统一的系统级安全观。他反复强调工业控制网络的安全问题不能再靠“功能安全管功能失效、信息安全管网络攻击”这种简单分工来解决因为攻击本身会直接触发功能失效而功能失效又可能为攻击者打开新的通道。两者交叉作用必须统一建模。2. 广义功能安全把“攻击”当“故障”来建模2.1 核心定义的转变从“故障”到“失效”再到“功能不安全”要理解广义功能安全先要抠一个词功能不安全Functional Unsafety。它比“故障”大得多。不只是设备坏了叫功能不安全任何原因导致系统不能按预期实现功能都叫功能不安全。我在一个水处理项目里遇到过这样的情况所有PLC正常运行没有任何硬件故障报警但上位机数据库被勒索病毒加密导致操作员无法看到水位数据被迫手动切换泵组。你说这算不算功能不安全当然算。设备没坏功能却瘫痪了。如果照传统功能安全模型系统运行正常安全但站在广义功能安全视角系统已经处于非常危险的不安全状态。所以广义功能安全明确地提出网络安全事件导致的物理后果设备损坏、停产、人员伤亡、环境污染与随机故障导致的物理后果在“不安全的后果”层面上是完全等价的。我们要防的不只是故障而是“失效”这个最终结果。2.2 攻击为何可以被视为“广义故障”很多人觉得把攻击当故障很奇怪攻击明明是主动行为怎么能跟随机故障相提并论邬江兴院士的观点很有启发从一个受保护系统的内部视角来看攻击者对系统造成的影响输入异常、状态跳变、参数篡改和一场电磁干扰、一个软件缺陷造成的现象在很多情况下是无法区分的。换句话说系统并不需要识别“这是不是攻击”它只需要能够容忍“我的输入或运行环境变得不正常了”。这就像人体免疫系统它不需要知道你感染的是流感还是新冠它只需要识别“非我”的抗原然后启动防御机制。安全机制应该关注系统能否在“异常输入/异常环境”下依然保持功能正确而不是纠结异常来自哪里。这个视角转换非常重要因为它让“可度量”成为可能。攻击者再高明他引发的系统异常也逃不出某些统计规律。于是我们可以用概率语言来描述广义安全的水平。2.3 为什么“外挂式”防护在工控场景失灵大家现在用的安全手段本质上都是“外挂式”的防病毒软件外挂在主机上防火墙外挂在网络边界上入侵检测系统外挂在交换机上。这套体系在IT领域运行了几十年有一定效果但一个公认的痛点是攻防不对称攻击者只需要找到一个没打补丁的漏洞防御方却要堵住所有漏洞还要保证业务不受影响。放到工控场景外挂式防护更拧巴。一是补丁跟不上工业软件很多是专用系统厂家不轻易发补丁发了也不敢随便打怕影响稳定性。二是白名单机制有死角白名单能拦未知程序但拦不住合法的工艺参数被篡改。三是边界防护是静态的工业网络拓扑经常因为临时接入调试设备而变化边界往往已经千疮百孔。四是性能约束工控系统对实时性要求极高很多安全扫描、深度检测的算力开销在现场根本跑不起来。外挂式防护解决不了根本问题因为它的逻辑是“我建一道墙把坏人挡在外面”但从来无法保证墙永远不会被推倒。在生产连续性优先的工控场景里这道墙更显得千疮百孔。所以院士提出的思路是让系统自己长出一套免疫功能也就是内生安全。3. 内生安全与动态异构冗余院士开的“药方”到底怎么用3.1 内生安全的核心思想不求“绝对可信”只求“失效可控”讲内生安全之前得先讲一个很难听但很真实的前提任何系统都不存在绝对安全。既然破坏者总能找到可乘之机可靠的做法是承认“一定会有漏洞”“一定会有攻击成功的时候”但在设计之初就让系统具备在这种前提下依然不丧失核心功能的能力。这个思想有个很形象的类比人体不是靠“没有病毒”来维持健康而是靠免疫系统在病毒侵入后把损害控制在局部、最终清除恢复。内生安全就是给控制系统装一套类似免疫系统的机制。那么这套机制靠什么实现靠“冗余差异裁决”。简而言之让系统同时跑几个不同的实现方式同一个计算任务交给几个模块各算一遍如果都被攻击者利用了同样的漏洞那结果是相同的但只要这些模块存在差异攻击者就很难同时控制它们。当输出不一致时由裁决机制判定并按多数原则输出正确结果或者直接进入安全状态。攻击即使成功也只影响了个别执行体整个系统依旧按正确逻辑运行。这就是动态异构冗余DHR架构的基本思路。3.2 动态异构冗余DHR工作原理解读拆开看三个关键词动态不是一套静态配置的冗余而是通过周期性或事件触发的方式改变当前参与工作的执行体组合让攻击者“打一枪换一个地方”的节奏失效。攻击者刚搞明白当前这个执行体A的漏洞系统就切换成执行体B和C的组合了他之前投入的信息收集全部作废。异构这是核心中的核心。几个执行体不能是同一个虚拟机镜像克隆出来的副本因为那样一个漏洞就等于所有漏洞。异构要求不同语言、不同架构、不同算法实现。比如一个用梯形图写的逻辑一个用功能块图实现再来一个用高级语言封装。它们功能等价但底层的漏洞集完全不同。冗余多个执行体同时运行通过表决器裁决机制对输出进行一致性校验。这里的核心是必须存在“少数服从多数”的结构有奇数个执行体例如三个或五个。这样即使少数执行体输出错误多数正确输出依然能维持业务。这套机制并不稀奇航空电子领域早就在用双余度、三余度表决。但以往用冗余是为应对硬件随机故障执行体都是同构备份因为故障模式是随机的同构备份就够了。DHR变革的关键在于把冗余从“可靠性手段”升级为“安全手段”专门用来对抗“非随机、有智能、会自适应”的攻击。同构冗余对抗随机故障绰绰有余但对抗定向攻击就是“一个坑摔三次”的翻版。3.3 动态异构冗余在工控场景的具体落地形态具体到工业控制网络这套架构可以有几种落地形态安全关键控制器对执行安全功能如紧急停车、燃机保护的控制器采用双控制器异构备份两个控制器用不同型号或不同处理器架构运行同样的安全逻辑通过硬件表决器或者以太网心跳同步进行输出裁决。一旦发现两个控制器输出不一致系统自动切换到安全状态并发出报警。这就让攻击者无法通过“攻破一个控制器”来导致整套安全系统误动作或拒动作因为他即使攻破了主控制器备控制器还是正确的。工业协议网关的变体调度对于外部网络与内部控制系统之间的协议转换网关可以部署多套异构的协议解析引擎。网关是攻击者最喜欢踩的点因为协议解析最容易出现漏洞。异构引擎让攻击者的攻击载荷在其中一个引擎上生效但在另一个引擎上产生解析异常直接被丢弃或触发告警。实时数据库与历史站的多模备份对关键数据采集和监控环节采用两套不同操作系统的数据服务节点做冗余中间加裁决代理。攻击者想让操作员看到的画面“造假”必须同时篡改两个异构节点难度成倍增加。人机交互界面的交叉验证在最高安全级别的操作中让操作员通过两个独立的界面确认同一个指令两个界面背后是不同的软件栈。这本质上就是把人纳入裁决机制里。我自己的实际感受是把DHR引入工控系统初期成本肯定会增加尤其对已经建成的老系统来说改造难度不小。但对于新建的高安全等级项目这个理念完全可以在总体设计阶段就埋进去成本不会比传统双机热备高太多安全性的收益却是一个量级的提升。3.4 不可能三角开放、安全、性能的权衡在很多场合院士团队都会提到一个“三难困境”一个系统不可能同时做到绝对开放、绝对安全、绝对高效。你越是开放攻击面就越大你越是隔离性能和使用方便性就越差。内生安全不是魔法它同样有代价。拿DHR来说多执行体同时运行意味着硬件成本成倍上升裁决机制会引入额外的时延必须通过高速内部总线或者FPGA逻辑来降低动态切换会让调试和维护工作变复杂。这些代价是真实存在的。所以工控场景里引入内生安全一定要挑节点、挑位置不能遍地开花。从本科普的角度说一句真正的工程决策绝不是“哪套方案最好”而是“哪套方案在成本、性能、安全之间最平衡”。广义功能安全给我们的价值不是让我们花大价钱把所有设备都改成异构冗余而是让我们有一套语言和度量方法能真正评估“我的系统在遭受攻击时到底还能不能安全运行”并据此决定把安全资源投资在刀刃上。4. 工控现场落地实操从评估、设计到运维怎么走4.1 第一步用广义功能安全视角重新做风险评估既然广义功能安全扩展了“失效”的定义那风险评估就不能只按传统可靠性模型跑一遍必须叠加攻击视角。我提供一个比较实用的操作思路资产识别时不要只识别设备台账还要识别每个设备的“功能承接”。这个设备失效或者被攻破会导致哪些上层功能失效影响面积有多大威胁建模时不要只列“自然灾害、硬件老化、操作失误”还要把“远程控制指令篡改”“固件后门”“供应链污染”“内部人员违规操作”纳入威胁清单。风险计算时传统的风险公式是“风险概率×后果”但攻击事件的概率很难精确算。更务实的做法是对后果做充分评估针对红外不安全的后果倒推需要什么等级的保护措施。这套思路我对接过的好几个做SIS评估的项目都用上了效果很明显以前大家觉得“安全仪表系统SIL等级够了就万事大吉”现在会额外追问一句“如果攻击者能下发指令强制旁路安全联锁那怎么办”这一问就问出了很多以前没人管的空白地带。4.2 第二步网络架构上的“功能安全域”划分工控网络分区分域大家都懂但以前的划分更多是从IT访问控制角度考虑比如办公网和生产网分离、生产网再分区。广义功能安全的划分思路应该更贴近功能逻辑把网络分区跟安全功能级别挂钩。比如紧急停车系统、火气系统这类SIL等级最高的功能应该放在单独的物理网络域里跟过程控制系统的通讯全部通过安全网关白名单过滤不允许任何反向主动发起。这不是简单的“办公网到工控网的访问控制”而是“高安全等级功能域不受低安全等级功能域失效的影响”。这个思路还有一个好处如果某个区段已经被攻击者攻破攻击者想要横向移动到紧急停车系统必须跨过额外的安全网关这就给了我们充裕的检测和响应时间。用广义功能安全语言说这是把“功能不安全的传播路径”给剪断了。4.3 第三步关键节点的异构冗余选型不是所有设备都需要做异构冗余但有几类建议优先考虑安全仪表逻辑控制器作为承担SIL功能的控制器。站控层实时数据库服务器。操作员站的组态软件运行环境。外部网络互联的网关/防火墙。选型的具体操作建议遵循“三不同”原则不同厂商、不同软硬件平台、不同实现方式。比如安全控制器一个厂家A的PLC和一个厂家B的安全PLC做异构冗余两个输出的控制指令通过一个硬安全表决单元进行比较。这个方案很多厂商会告诉你“不好做”因为两个PLC的数据结构和指令集不一样需要做IEC 61131-3标准的功能块映射。但只要有工程耐心这个工作量是可控的。更轻量的做法是OS层异构同一个应用逻辑部署在一个Linux实时系统和一个Windows系统上中间通过共享内存或者以太网UDP做心跳比对。这种方案不需要你改PLC程序适合改造项目。4.4 第四步运维阶段的“动态”机制内生安全不是设计完就躺平它的“动态”特性需要运维层面配合。我提几个具体可落地的运维动作定期人工触发逻辑切换测试验证裁决机制是否正常比如人为在一个执行体上制造一个轻微故障确认系统能感知并切换。严格执行变更管理任何组态修改都必须走变更流程修改后必须进行冗余一致性校验。保存所有执行体的基线版本和安全补丁日志定期比对各执行体的配置漂移。很多攻击者是用缓慢的信息篡改来绕过检测的配置漂移比对能发现这种“慢刀子割肉”。有一点要特别提醒动态异构冗余不能替代常规的补丁管理和漏洞修复。内生安全是让你在被攻破一条线时还能“带病生存”但能打补丁还是要打两者是互补关系。把内生安全当免死金牌、彻底放弃补丁更新那是非常危险的误读。4.5 实操中常见问题与排查技巧实录我把这几年在项目里踩过的坑、被问过最多的问题整理成一张速查表供参考问题现象可能原因排查思路与处理建议异构双PLC输出频繁不一致两个控制器扫描周期不同步检查两个控制器的程序扫描时间确保触发同一逻辑时起始相位一致必要时增加同步脉冲信号裁决单元频繁误切到安全状态异构执行体之间数据格式差异导致比较误判核对两个执行体输出的数据范围、字节序、浮点精度做归一化处理后再比较一套执行体被攻破后无法隔离执行体之间通讯端口未做白名单限制审计执行体之间的所有网络连接关闭多余端口隔离受损执行体只保留表决链路动态切换机制导致工艺波动切换策略过于激进切换过程未做控制保持调整动态切换策略切换前先进入“输出保持”状态切换完成后无扰恢复组态修改后裁决基线不一致只改了一侧执行体的组态修改组态必须双侧同步更新并做一致性校验攻击者通过执行体漏洞旁路裁决裁决机制本身是单点故障裁决模块也要冗余设计或采用FPGA硬件表决避免统一软件表决器成为新的攻击目标4.6 不要忽视人的环节安全文化与培训最后说个最常见也最容易被忽视的坑。很多单位买了安全设备建了安全制度但人在操作层面仍然是最大的变量。我曾在一个项目里见过这样的事冗余系统的两个执行体分别由不同班次的工程师维护结果甲班工程师觉得“反正是冗余的这台我先改一下试试”结果两套系统的组态都陆续被改了而且改得不一致最后裁决机制被频繁触发生产被迫停机。后来复盘发现根本原因是人员没有建立“冗余系统的两个执行体必须同步修改、同步验证”的意识。广义功能安全的落地最后一半靠技术另一半靠制度的执行和人员意识。技术再强如果操作员为了省事把一个U盘从办公网直接插到工控设备上所有防护都可以在一瞬间被击穿。我给客户的建议是安全运维培训里一定要加入“攻击导致失效”的场景演练让工程师真正理解“一次不经意的违规操作可能在几天后引发一次非预期的停机事故”这比单纯讲一百遍安全规章制度都管用。这一步千万不要省。很多企业愿意花钱买设备却不愿意花时间做人员训练结果设备买了三年只在验收时开过一次机平时全部旁路——这种现象极为普遍最后的安全水平和没装设备之前没什么两样。5. 写在最后的一点个人体会我对广义功能安全最深的感触不是哪一套具体技术而是它让我们重新理解了“安全”这件事本身。以前我们做工控安全总有一种“打地鼠”的焦灼感今天堵这个漏洞明天防那个攻击永远在被动响应。面对层出不穷的零日漏洞、供应链攻击、内部威胁再加上工控系统本身的停机代价这种“外挂修补”模式越来越力不从心。而广义功能安全的思路从产品上解决了一个根本问题不再依赖“我知道攻击者会怎么做”这种前提而是通过架构层面的机制让系统在“未知攻击”面前也能保持功能正确。这种从“防守思维”到“体质思维”的转变对整个工业界而言都是一种难得的前瞻思路。有一个比喻我觉得特别贴切传统安全像是给大楼装门锁和铁栅栏锁越来越结实栅栏越来越高但小偷总归能找到新工具内生安全则是训练大楼里的保安队伍让他们练就火眼金睛就算小偷溜进来了也能第一时间被发现、被控制住、被清除出去。大楼不可能不需要锁但只靠锁是永远不够的。对于正在做工业控制网络安全规划的朋友我的建议是不用急着把全厂都改造成动态异构冗余那既不现实也不划算。先挑出最能顶住安全风险的安全关键功能域把广义功能安全的理念落实到风险评估、网络域划分和关键节点选型上再从人员意识抓起。一步一步来安全这个无底洞是可以通过体系化的方法变成一笔有得算的明白账的。
阅读完成 · 觉得有帮助？
