工控安全能力如何量化？GB/T 41400-2026成熟度模型与分级评估实践指南

做过几年工控安全评估的人，大概率都被客户问过同一句话：“我们的安全防护能力到底算好还是差？”这个问题看着简单，真回答起来特别费劲。有的企业上了防火墙、堡垒机、入侵检测，安全产品堆了满满一机柜，可一问到“谁负责处置告警”“应急预案多久演练一次”“厂里到底有多少台带网口的控制器”，大家就开始含糊了。单靠产品清单回答不了“能力”这件事。

GB/T 41400-2026《网络安全技术 工业控制系统网络安全防护能力成熟度模型》就是要把这个模糊的问题变成可测量的刻度。它给工业控制系统的安全防护能力划分出不同成熟度等级，让企业能清楚知道自己在哪个台阶、短板在哪、下一步该往哪走。不管你是安全负责人、工控系统运维，还是做安全评估和咨询的人员，都能从这套模型里找到一套通用的评估语言和提升路径。

以下内容我会从模型的设计逻辑、等级拆解、自评估方法，到落地时容易踩的坑，完整过一遍。目标只有一个：让你看完之后能直接拿这套思路去厂里做一次摸底，而不是收藏夹里多一篇“看起来很专业”的文章。

1. 为什么工控安全需要一把“能力标尺”

1.1 生产网和办公网的安全逻辑完全不同

很多做IT安全的老手第一次接触工控网络，第一反应是“这有什么难的，把防火墙、杀毒、EDR都配上不就行了”。真进了生产车间，才发现完全不是那么回事。

办公网追求的是机密性、完整性、可用性，但在大多数情况下，可用性排序很靠前。到了工业控制现场，可用性几乎就是第一位，而且是没有商量的第一位。一台DCS控制器控制着反应釜的温度，一个PLC控制着传送带的节拍，这些东西一旦中断，轻则停机停产，重则设备损坏甚至人员伤亡。你不可能像处理办公电脑一样，说“重启一下试试”。

生产网里还有大量跑了很多年的老旧系统。Windows 2000、Windows XP在这里并不罕见，甚至还有DOS系统在支撑关键工序。这些系统早就没有安全补丁可打，但生产线离不开它们。你拿扫描器去扫一遍，搞不好直接把工程师站扫蓝屏。所以工控安全的各种措施，都要在“不影响生产”这个大前提下做，这就决定了它不能用办公网那套标准来衡量。

既然技术基线都不一样，那“防护能力强不强”自然也不能只看买了多少设备。需要一个专门针对工控场景的、能把复杂现状分层分级的尺度，这就是能力成熟度模型存在的意义。

1.2 成熟度模型衡量的是综合能力，不是设备数量

“成熟度模型”这个概念，最早源于软件工程领域的CMM，后来被广泛用在项目管理、数据治理、网络安全等领域。它的核心思想很简单：任何一项能力，都不是一蹴而就的，而是从无序、可重复、体系化、量化管理，到持续优化的一个演进过程。

GB/T 41400-2026把这种思路搬到工业控制系统网络安全上，衡量的就不再是“你买了多少台安全设备”“你上了哪个品牌的平台”，而是企业整个组织在安全防护上的综合能力。这个综合能力至少包含三块：

• 人员：有没有懂工控安全的人，有没有责任分工，一线运维人员知不知道安全事件找谁。
• 流程：有没有成文的制度、预案、操作规范，这些流程能不能被重复执行，执行了有没有记录。
• 技术：是否有匹配工控场景的边界防护、主机防护、监测审计手段，技术措施是否在有效运行。

三者缺一不可。有的企业技术投入一堆，但流程一塌糊涂，告警没人看，预案没演练，出了事全靠“现场老师傅的直觉”。这种企业在成熟度模型里的分数一定不会高。

1.3 标准想解决的三类典型问题

用我自己接触过的项目经验来对照，这套模型至少能解决三类普遍问题。

第一类是“家底不清”。很多工厂连一份准确的资产台账都拿不出来。网络拓扑图画得乱七八糟，现场有多少PLC、多少传感器、哪些端口是开的，谁也说不清。这不能全怪运维，因为工控系统往往经过多次技改，早期图纸早就丢了，新老设备混杂，想摸清楚本身就不容易。成熟度模型把“资产识别与管理”作为最底层的能力域，逼着企业先做这个基本功。

第二类是“能力不均衡”。有的企业边界防护做得不错，防火墙策略很严，但主机层漏洞一堆，工控机随便插U盘；有的企业应急演练做得像模像样，但平时根本没人盯着安全告警。木桶效应在安全上特别明显，能力短板决定了整体水平。模型通过分域打分，能把这种“偏科”暴露得很清晰。

第三类是“投入没有主线”。企业每年都在买安全设备，但问起来明年该买什么、为什么买，说不出所以然。成熟度评估可以帮助企业找到当前等级到下一等级之间的关键差距，让预算花在最需要补的地方，而不是继续“设备叠罗汉”。

2. 成熟度等级的台阶怎么设计更符合OT场景

2.1 五级能力梯度的粗略画像

从公开信息和行业实践看，GB/T 41400-2026沿用了成熟度模型常见的五级结构。这里我结合自己对工控场景的理解，给一个直观的对照：

这张表只是一个粗略画像。真正的标准里，每个等级都有严格的评估项和判定条件，不是随便打个分就能上去的。

2.2 从二级到三级，难点在“体系化”

跟企业实际交流下来，最容易卡住的是从二级到三级这段路。二级意味着“某个车间、某条产线有自己的安全做法”，比如负责A车间的工程师习惯每个月做一次备份，负责B车间的工程师靠感觉，全看个人。三级要求的是“整个组织有一套统一的安全体系”，不再是某个人的英明决策，而是任何一个人按流程操作都能得到相似结果。

举个例子。二级状态下，A产线有备份制度，B产线没有，这已经很不错了，毕竟很多工厂连备份都没有。但要上到三级，就必须建立覆盖全厂的备份策略：哪些系统需要备份、备份频率、备份介质放哪、多长时间做一次恢复测试，都必须有统一标准。这不仅仅是写一份制度文件的事，还要让各车间真正按这个标准执行，并有记录可查。

我见过有些企业，制度写得非常漂亮，模板是从网上找的，流程图上挂了二三十个节点，但现场员工压根不知道。这种“墙上制度”在成熟度评估里很难拿到分，因为评审人员会访谈一线员工，对照执行记录，很快就能看出制度是不是摆设。

2.3 成熟度等级不等于技术堆砌

有朋友问过我：“我们公司是不是把下一代防火墙、态势感知、工控安全审计都买了，就能评上四级？”我的回答通常是一盆冷水：技术设备只是工具，成熟度看的是你用这些工具做了什么，有没有把能力沉淀到组织和流程里。

打个比方。两个人都买了最新款单反相机，一个人只会用自动挡，拍出来的照片和手机差不多；另一个人认真学构图、学布光，用同样的相机拍出了作品。你能说只看相机品牌，就知道谁是高手吗？安全能力也是一样的道理。

有的工厂买了工控安全监测平台，但没人制定告警研判规则，平台每天的告警数高达几千条，运维人员看两天就放弃了，之后平台成了“僵尸系统”。另一个工厂没用很贵的平台，但建立了一个小团队，每周分析日志、每月复盘事件，反而把几次早期入侵苗头都堵住了。后者在成熟度模型里的能力评价，大概率会超过前者。因为成熟度模型衡量的是“能持续产出安全结果的能力”，而不是资产清单的长度。

3. 按标准做自评估：范围划定、证据采集与打分

3.1 评估边界先按“业务影响”画，再按“网络拓扑”画

这是我在项目里反复强调的一点：做成熟度评估的第一步不是拿网络拓扑图，而是先搞清楚哪些系统一旦出问题，会带来最严重的后果。

有些企业划分评估范围时只看IP网段，觉得“办公网和生产网要分开，我们就评估生产网”。但生产网里也有管理终端和业务系统，办公网里也可能坐着一个能远程修改组态的工程师站。更合理的做法是把“业务影响”作为第一维度：凡是停机或篡改后会造成人身伤害、重大环境污染、巨额经济损失或者不可逆设备损坏的系统，都应该纳入重点评估范围。

举个例子，某化工厂有一台上世纪90年代的单回路调节器，它不联网，也没有IP地址，很多人觉得它跟网络安全没关系。但它是反应釜温度的关键控制设备，如果被人为修改了设定值，后果不堪设想。所以即便它没有IP，它的“上位管理方式”“现场物理访问控制”“参数变更审批”也必须纳入能力评估。

评估范围确定后，要形成一张明细清单，明确边界内有哪些系统、哪些车间、哪些网络节点，并和业务部门、生产部门一起确认。这一步如果偷懒，后面所有评估都会失真。

3.2 评估项设计：围绕“组织、流程、技术、运营”展开

工控系统网络安全防护能力成熟度模型，评估项一般会覆盖下面这些域，我列出来方便你对照：

• 组织机构与职责：有没有明确的安全负责人、安全组织架构，职责边界是否清晰。
• 资产识别与管理：能不能完整识别软硬件资产、数据资产，并维护变更记录。
• 风险与威胁评估：有没有定期做风险评估，能不能识别出针对工控协议的威胁。
• 安全策略与制度：制度和流程是否覆盖规划、建设、运维、废弃全生命周期。
• 访问控制与身份管理：账号是否实名、权限是否最小化、远程运维是否受控。
• 安全监测与审计：有没有针对工控流量、操作行为的监测和日志记录。
• 应急与恢复管理：应急预案、备份恢复、演练组织是否常态化。
• 供应链与外包安全：设备采购、集成商、外部运维方是否纳入安全管理。
• 人员意识与技能：员工安全意识培训、工控安全专业能力建设是否持续。
• 技术防护措施：边界、主机、数据、物理环境等层面的防护是否有效。

每个域下面还会分解成多个具体控制项。评估时，通常给每个控制项设置几个档位，比如“未开展、部分开展、基本实现、有效运行、持续优化”，对应1到5分。但要注意，不是所有控制项权重都一样，越靠近“保障生产连续性和人身安全”的项，权重越高。

3.3 证据采集要“文档+记录+访谈+现场观察”四方交叉验证

评估最怕什么？最怕被企业“带着走”。有些企业非常会准备材料，制度文件一摞一摞，你要什么给什么。如果只做文档审查，分数可能很高，但实际情况可能根本不是那么回事。

我通常要求评估组必须做四个维度的交叉验证：

• 文档审阅：看制度、规程、方案是否完整。
• 记录核查：抽查最近的执行记录，比如备份日志、巡检记录、账号审批单。
• 人员访谈：分别找管理层、安全管理员、一线运维和操作工，问同样的问题，看回答是否一致。
• 现场观察：去机房和控制室转一圈，看机柜门锁没锁、工程师站是不是有U盘插着、密码是不是贴在显示器上。

这个环节能发现大量“纸面合规”问题。以前评估一家机械加工厂，制度里白纸黑字写着“每季度进行一次应急演练”，但当我们要求提供演练记录和照片时，对方支支吾吾，最后承认制度是今年刚补的，实际一次都没演练过。如果没有记录核查和访谈，这份制度就是满分，但真实能力连二级都不到。

打分的时候也要注意，任何一个控制项的评分，都不能只看一级证据。比如“访问控制”这项，制度文档满足、账号权限表也做得很漂亮，但现场操作员反映“我们三个用同一个账号，因为两班倒交接太麻烦”，那这一项就必须扣分。

3.4 一张表走通评估流程

把评估流程压缩成五步，可以做成一张对照表，方便做项目时直接套用：

这五步听上去简单，实际操作中最耗时间的往往是第一步和第三步。评估范围没划清，后面全是白做；证据核查不严，结论没人信服。所以哪怕预算紧，这两步也不要省。

4. 我在评估和整改中踩过的四个坑

4.1 把自评估做成了合规检查

很多企业第一次做成熟度评估，最容易犯的错误就是把它当成“合规检查”。管理层要求“对照标准条款，看我们哪些不符合”，然后安全部门就拿着检查表逐条打勾，能提供的证据就算合格，不能提供的就开出整改单。

结果是什么呢？评估报告写得像审计底稿，但真实能力没有任何提升。因为合规检查是“有没有”的问题，成熟度评估是“好不好、是否持续有效”的问题。

后来我们把评估逻辑改成了“效果导向”：不问“你有没有边界防火墙”，而是问“边界防火墙的策略最近一次Review是什么时候？谁做的？有没有发现失效策略？”。不问“你有没有应急预案”，而是问“上次演练是什么时候？演练中发现了什么问题？改善措施落实了没有？”。这两个问题一问，很多企业自己就意识到差距了。

4.2 资产识别用主动扫描，差点把DCS打挂

这是让我记忆最深的一次事故。当时要给一家工厂做评估前的资产盘点，我建议先用被动流量分析摸个大概，再结合现场核对。结果合作方带队的一位同事觉得被动分析太慢，坚持用某知名扫描器对生产网段做一次全端口扫描，说“扫一下全出来了”。

扫描器跑了没十分钟，DCS工程师站集体蓝屏，操作员站画面冻结，一条正在生产的产线直接停了。后来排查原因，是DCS系统里一台运行Windows 2000的老工程师站，被扫描器发送的大量TCP探测报文打崩了。幸好没有造成更严重的事故，但那次产线停了两个多小时，损失不小。

从那时起，我的原则变成：

• 生产环境一律不允许主动扫描，除非在专门隔离的测试环境里。
• 资产识别优先用交换机镜像口抓流量，做被动资产识别，再结合现场标签核对。
• 如果确实需要主动探测，也要划定极小范围，提前和设备部门确认窗口期，并做好回滚方案。

在工控现场，“稳”永远比“快”重要。

4.3 安全策略一刀切，生产班组拒绝配合

还有一个常见坑，是拿办公网的安全策略直接套生产网。比如有企业为了达到“身份鉴别”的高分，要求所有工控系统账号90天强制改密，密码必须包含大小写、数字和特殊字符。理论上这没错，但现场三十多台HMI（人机界面）全部用的是固定操作账号，改密之后，操作员每次交接班都要找人要密码，因为根本记不住。

结果一线师傅们想了个“聪明”办法——把新密码写在便利贴上，贴在显示器边框。表面上密码策略是合规了，实际上安全防护水平比“不设密码”还低，因为密码已经从“秘密”变成了“公开信息”。

这件事给我的教训是：工控场景的安全控制措施，必须考虑可用性和人的因素。成熟度模型里的“有效运行”并不只是技术达标，而是指这个措施在实际环境中真正被执行、被遵守。后来我们采用的方法是区分资产重要性：对核心控制系统的账户做双人复核访问，对一般操作员站则采用较长有效期、支持SSO（单点登录）的方案，既满足安全要求，又不干扰生产。

4.4 评估报告生成后没人接盘

有一次给一家企业做完整套评估，报告写了很厚的差距分析和整改建议，对方安全经理看得连连点头。结果三个月后回访，报告里的问题一个都没改。原因很简单：整改任务没有落到具体人头上，也没有资源预算。

评估报告如果只是给安全部门自己看，那注定落不了地。真正有效的做法是评估结束后，立刻和IT、OT、生产、设备、采购等部门开一次“整改任务交底会”，把报告里的问题逐条变成带有负责人、资源、时间节点的行动计划，并由分管领导签字确认。

我还建议在报告里给每条整改项标一个“业务影响级别”：比如“高危账号未清理”和“应急演练不足”，前者可能几周就能解决，后者需要跨部门长期推动。优先级不同，组织层级也应该不同。不能所有问题都让安全管理员一个人扛。

5. 从得分到行动：整改优先级与持续改进指标

5.1 先止血，再补短板

拿到评估结果后，最常见的冲动是“哪个分低补哪个”。但我要泼一盆冷水：有些低分项可能是体系性问题，短期补不起来；有些得分还行但一旦被突破就是毁灭性事故。整改优先级不能只看分数，要看“一旦出事的后果”和“整改投入的成本”。

我自己习惯用三个词来分类：

• 止血项：指暴露面极大、极易被利用、且后果严重的问题。比如默认口令、未授权远程访问端口、缺少备份且无法恢复。这些问题必须在一到两个月内解决。
• 体系项：指流程制度不健全、人员能力不足、监测响应机制缺失等结构化问题。这些需要三到十二个月持续建设。
• 优化项：指已经基本达标，但可以通过指标量化、自动化、智能化做得更好的方向。这类不用太急，但要定好节奏持续做。

用这个标准排序，就不会出现“为了拉高某一项分数，花大价钱买一堆不急需的产品，结果连最基础的管理员弱口令都没改”的闹剧。

5.2 短期、中期、长期三步走的整改节奏

我经常给客户推荐一个三步走的节奏，按这个节奏推进，既有短期成效，又能为长期能力打基础。

这套节奏不是死板的，不同行业、不同规模企业可以裁剪。但你一定会发现，前三个月的“止血”动作往往不需要花太多钱，却能极大降低真实风险。这比一上来就买大平台要务实得多。

5.3 用几个核心指标牵引持续改进

最后说说持续改进。很多管理者听完评估结果都问：怎么知道明年到底有没有进步？光靠“再请人来做一次评估”不现实，成本太高。这时候需要一套能持续跟踪的轻量级指标。

我常用且觉得比较有效的几个指标是：

• 资产台账覆盖率：这在刚开始几年是核心指标，毕竟连自己有什么都讲不清，其他安全措施都是空中楼阁。
• 高危账号清理率：比如默认口令、离职账号、越权账号数量，有没有持续下降。
• 漏洞闭环平均时间：从发现漏洞到修复/补偿措施完成的时间，体现了团队的执行力和响应速度。
• 应急演练完成率与改进项闭环率：演练不能只做表面，每次发现的问题要有追踪。
• 安全事件平均响应时间（MTTD/MTTR）：从异常告警到确认事件、再到处置完成的时间，这个指标能反映安全运营的真实状态。

这些指标不需要很复杂，先跑起来，再用数据反哺安全策略调整。成熟度模型的价值也正在于此——它不是一个一次性的合格证，而是一个每年复测、螺旋上升的“仪表盘”。企业不需要追求第二年就直接跳到四级，只要每一次评估都比上一次上一个台阶，就已经走在正确路上了。

最后分享一点个人体会：我做过很多次工控安全能力评估，最让我有成就感的不是最后给出的那个等级数字，而是通过评估，逼着整个工厂第一次完整地坐下来，把资产盘了一遍、把流程捋了一遍、把之前没人敢提的问题放到了桌面上。GB/T 41400-2026这样的模型，最大的意义不是给你贴标签，而是让大家对“安全能力”有了一致认知，知道差在哪、往哪使劲。标准本身不会让企业变安全，真正让企业变安全的，是照着这把尺子，一天天把短板补齐的过程。