干工控安全这些年经常被同行问到一个问题你们是不是拿扫描器扫一圈再对着漏洞库比对一下就出报告了每次听到这种话我都想摇头。工控系统安全测试和普通 IT 渗透完全是两回事真正的难点不在“扫”这个动作而在怎么把测试沉淀成一套能复用、能量化风险、能经得住生产事故追责的测试用例。今天我把自己在工程现场反复打磨过的一套工控系统安全测试用例设计思路拿出来从底层逻辑到具体字段怎么写再到现场执行顺序和避坑技巧一次性说清楚。这套内容适合正在做 ICS/SCADA 安全评估的人也适合刚转岗到工控安全方向的工程师。它不是概念科普而是可以直接抄进测试方案里的操作框架。你拿过去改一改厂商协议、改一改现场资产清单就能用在下一场测试里。1. 工控安全测试的底层逻辑用例不是“造”出来的是“算”出来的很多刚入行的人喜欢照搬 IT 渗透的用例模板比如“默认口令检测”“未授权访问”“SQL 注入”。这些用例放在办公网没问题但直接丢到工业控制网络里往往第一轮就被业主毙掉。原因很简单工控网络的可用性优先级远高于机密性和完整性哪怕是一个扫描报文也可能把老旧 PLC 的 CPU 打满。所以在设计任何一条用例之前先要把底层逻辑捋清楚。1.1 为什么工控测试用例与 IT 测试用例根本不同工控系统里的设备生命周期普遍很长很多现场还在用十多年前的 PLC、RTU、HMI操作系统要么是 Windows 2000要么是未打补丁的 Windows 7 嵌入式版本。这些设备在设计之初就没考虑过被扫描、被 fuzz、被并发连接的情况。一个高并发的端口扫描放到 IT 环境里可能毫无感觉放到 DCS 控制网上轻则导致 CPU 扫描周期变长重则让 IO 模块进入故障安全状态。此外IT 系统出了问题最坏的结果是业务中断但工控系统出了问题可能直接关联到物理流程比如阀门误动作、电机启停、温度越限。这不是“删库跑路”级别的后果而是设备损坏、停产、人身伤害级别的后果。所以用例设计首先要回答的不是“能不能测”而是“测了之后系统会怎样”。这也是为什么业内普遍认同工控测试用例必须包含风险评估与回滚策略两个额外维度。1.2 从“可用性优先”推导出来的测试优先级工控安全的三个核心指标通常被概括为 CIA但在 OT 侧顺序完全不同可用性 A 排第一完整性 I 排第二机密性 C 排最后。这个顺序直接决定了用例优先级。凡是可能影响可用性的测试要么降级为被动测试要么放到专门的测试窗口内要么先在仿真环境验证凡是只影响机密性的测试比如读取配置、枚举用户名则可以放在相对靠前的位置执行。我在给某个化工 DCS 项目设计用例时把所有可能写入的操作码都标记为“高危”把连续多次重放操作标记为“严重”把仅读取响应报文的 fuzz 标记为“中危”。这样做的好处是现场执行时可以根据生产负荷灵活调整生产平稳的时候测高危项生产紧张的时候只跑被动项和读取类项。用例的优先级不是一个固定属性而是一个根据现场状态动态变化的参数。1.3 测试用例设计的三大约束授权、影响面、时间窗工控测试用例和普通渗透测试另一个显著区别在于多了一道“安全阀门”也就是每一项用例都需要回答三个问题有没有书面授权影响面到底有多大在什么时间窗内执行授权不仅是签一个测试委托书那么简单还要细化到具体 IP、具体端口、具体操作指令。我习惯在用例模板里加一个“授权范围”字段填上该用例涉及的主机名、PLC 站号、协议端口以及业主方确认人。这个字段在后续追责时非常重要一旦现场出问题能立刻定位到是谁批准了这条用例。影响面分析则要求测试人员真正了解被测对象的业务地位。比如同样是 Modbus 线圈写入测试写到冷却水泵启动线圈和写到某个备用状态指示灯线圈风险等级完全不同。我会在用例模板里列一个“关联业务影响”字段由甲方工艺工程师和仪控工程师共同确认。时间窗则是指测试窗口很多连续流程不允许随便停机测试只能安排在大修、夜班低负荷或者仿真环境里。这三大约束是所有高价值用例的前置条件缺一条我都不会在现场执行。2. 工控系统安全测试用例的分类拆解与模板工控系统安全测试不能只靠一两个“万能用例”走天下它应该是一个分类清晰、互相补充的用例库。按照我的项目经验最实用的分类方式是按测试对象拆再按威胁场景聚合。2.1 按测试对象分类网络层、主机层、应用层、物理层网络层用例主要覆盖交换机配置、VLAN 划分、访问控制列表、网络协议安全属性。比如检测是不是存在旁路设备、是不是有未授权接入的无线 AP、Modbus TCP 报文能不能跨区域到达工程师站。这类用例一般通过被动流量采集和主动探测完成容易标准化。主机层用例覆盖工程师站、操作员站、历史服务器、应用服务器的操作系统和中间件安全配置。常见包括本地账户策略、共享目录权限、远程桌面是否开启、是否安装了杀毒软件、补丁批次是否落后于厂商支持范围。注意这里尽量不要做破坏性测试优先用配置核查脚本替代真实漏洞利用。应用层用例覆盖 HMI/SCADA 应用、OPC 通信、数据库接口、Web 管理后台。重点关注认证机制是否可绕过、指令是否可重放、越权访问是否可控。物理层用例则包括控制柜锁是否有效、调试网口是否暴露、USB 口是否可插拔、现场临时调试终端是否遗留账号。这四类用例各有侧重完整覆盖一次工控系统安全评估的绝大多数需求。2.2 用例模板前置条件、操作步骤、预期结果、风险等级、回滚方式我发现很多团队的测试用例只有“操作步骤”和“预期结果”两项这在工控现场远远不够。我自己长期使用的模板至少包含八个字段用例编号、测试对象、前置条件、操作步骤、预期结果、风险等级、回滚方式、授权确认人。下面是一个简化的模板示例你可以直接套用字段内容示例用例编号OT-NET-SCAN-001测试对象1# 车间 Modbus TCP 网段192.168.10.0/24前置条件已获书面授权生产处于低负荷状态风险预案已签署操作步骤对网段内的 PLC 地址执行 TCP 端口扫描仅探测 502 端口开放状态预期结果返回开放的 502 端口列表CPU 扫描周期波动不超过 5%风险等级中危因主动连接可能导致老旧 PLC 响应延迟回滚方式停止扫描断开测试笔记本与镜像端口连接观察 30 分钟 CPU 负荷授权确认人甲方电仪主管王某日期 2025-06-10这个模板的价值在于把操作者从“只能拍脑袋”的境地拉回来每条用例都带有可量化的风险承受指标和回滚方式。我还会在“操作步骤”里写明具体工具参数比如 Nmap 的-T2慢速模式、并发数上限、探测包超时时间这样即使执行人换了结果依然具备可复制性。2.3 基于威胁建模生成用例的几条经验直接从威胁模型推用例是我比较推荐的做法而不是看到什么测什么。常见的威胁建模维度包括区域间是否存在非预期通路、协议是否缺乏认证机制、设备是否存在后门账户、维护调试接口是否过度开放、上位机与控制器之间是否存在明文传输。例如如果威胁模型里有一条“攻击者可通过工程站远程下装恶意逻辑”那我们就自然而然推出一组用例验证工程站与 PLC 的通信是否需要身份认证、验证是否存在未受保护的上传下载服务、验证网络拦截后下装操作是否失败、验证连续多次下装请求是否触发 PLC 保护机制。这组用例的覆盖度就明显比“试着用调试工具连一下 PLC”这种笼统描述高得多。我建议每个项目开始前先花一到两天做威胁建模用结构化方法把“最担心的十件事”列出来再逐条映射到测试用例。没有威胁模型支撑的用例库就像没有箭靶的箭射得再多也未必中要害。3. 高价值场景实操从扫描到协议 Fuzz 的完整用例实现这一节我重点写几个我在现场反复执行过的核心测试场景每个场景都给出具体参数和注意点。请牢记这些用例必须在授权、隔离、风险预案都到位的前提下执行。3.1 被动资产识别用例不碰生产流量怎么画出网络拓扑被动资产识别是所有主动测试之前的“第一板斧”它的核心价值在于完全不向生产网络发送任何报文只通过镜像端口或 TAP 设备监听流量。常见工具包括 Wireshark、GRASSMARLIN 以及一些国产工控流量分析平台。通过被动流量可以识别出 Modbus、DNP3、S7comm、OPC UA 等协议的特征和端点也能发现一些未被资产管理台账覆盖的“隐藏资产”。具体用例设计上我会要求采集时长不低于 24 小时覆盖一个完整生产班次。执行时要注意镜像端口不能配置错否则生产流量中断同时存储空间要预留充分千兆镜像口一小时流量可能超过 30GB至少要预留整场测试数倍的磁盘容量。被动识别的结果应导出为资产清单与甲方台账比对差异项就是后续高风险用例的靶子。3.2 主动扫描用例Nmap 与工控协议识别参数调优细节当被动识别完成后才会进入主动探测环节。这里最容易翻车的地方是扫描速率。默认的 Nmap 参数在 IT 网络里很稳但到了工控网必须降速并减少并发。我常用的命令是nmap -sS -sV -p T:102,T:502,T:44818,T:4840,T:9600,T:20000 -T2 --host-timeout 60s --max-retries 1 target-T2表示降低时序--host-timeout防止老旧设备长时间无响应导致测试无限期卡住--max-retries 1避免反复重试把设备连接表打满。如果目标设备明确是 PLC我一般还会在扫描前测一下当前 CPU 负荷扫描过程中每隔一分钟再看一次负荷一旦超过阈值立即终止。主动扫描用例的预期结果不应写“发现所有开放端口”而应该写“识别出目标设备开放端口及协议服务版本且 CPU 负荷波动在预期范围内”。这样既测了信息安全问题也测了安全测试自身对生产的影响。这里再提醒一句不要用全端口扫描直接扫 PLC很多 PLC 在遇到未识别 TCP 连接时会产生错误日志严重时还会短暂终止服务我们一般只扫描该型号设备常用端口再加五个高概率端口。3.3 Modbus TCP 协议 Fuzz 用例边界值、异常码、重放Modbus 是工控网里最常见的协议之一也是安全测试绕不开的测试对象。我设计 Modbus 协议 Fuzz 用例通常拆成三组字段边界值、异常功能码、重放与乱序。字段边界值主要针对寄存器地址、数量字段和数据长度字段。例如向保持寄存器地址 0xFFFF 发起读请求或者向数量字段填 0x7FFF。这类请求在协议规范上可能不合法但老款 PLC 对异常长度报文的处理差异极大有的会直接丢弃有的会进入异常处理分支导致响应延迟。每个边界值都要单独编成用例记录下来使用的报文十六进制便于复现。异常功能码则是指向设备发送规范之外的功能码比如 0x80、0xFF、0x63 等。预期结果不是“设备拒绝”而是“设备不崩溃、不重启动、不产生非预期输出”。我在测试时喜欢配合响应超时监测在 Wireshark 里同时抓包确认设备是否在预期时间内回复异常响应。重放测试更贴近真实攻击场景。先抓取一条正常的写单个线圈报文然后按不同间隔重放多次比如连续重放 100 次、间隔 10ms 重放 50 次。重点观察设备是否重复执行写操作是否触发写入次数限制是否因次数过多进入故障状态需要注意的是写操作在低风险点位测试严禁触碰工艺联锁点位。3.4 PLC 逻辑与固件层面的测试用例设计思路协议层测完必须上升到 PLC 逻辑和固件层面。这部分不能真的把恶意逻辑灌进生产控制器而是围绕“能不能被篡改、篡改了是否可逆、是否有审计痕迹”设计用例。第一类用例是程序上传下载保护测试。选择一台离线备机或者已停产的控制器尝试未经认证建立上传下载会话。记录控制器是否弹出密码验证、是否允许读取程序块、是否允许写入程序块。这里要注意很多老款 PLC 虽然设置了访问密码但密码明文存储在工程文件中或者在特定功能码下可以被绕过这类问题通常通过离线固件分析识别。第二类用例是程序完整性比对。在授权前提下从 PLC 上传一份程序块保存哈希值再通过工程软件做一次远程下载后的对比确认是否存在非预期差异。如果甲方允许可以在仿真环境下人为修改一段逻辑再下载观察控制器是否记录篡改日志、能否恢复到备份点。第三类用例是固件版本和已知漏洞核查。将控制器的固件版本号与厂商安全公告比对确认是否存在公开漏洞条目。同时检查是否开启固件更新机制、是否有未签名固件可被离线加载。这一层用例不需要过于依赖攻击工具更多是“配置核查固件分析”的组合。3.5 权限与认证用例工程站、HMI、历史库账户体系怎么测工控系统里的账户体系往往比 IT 系统更混乱。操作员、工程师、管理员共用账号很常见第三方运维人员长期保留通用超级账户也不少见。权限用例模拟的是“普通操作员是否可以做工程师操作”这个问题。测试步骤一般包括用低权限账户登录 HMI尝试打开工程师站软件、修改画面组态、执行配方下发在历史库管理端尝试访问其他用户的审计日志在工程站上尝试通过 Windows 共享访问项目文件目录。预期结果是权限边界清晰低权限账户被拒绝并且产生安全审计事件。另一个容易被忽视的点是默认口令测试。很多 PLC 编程软件的“密码”是空密码或默认口令像某些老式 HMI 的工程密码直接是 888888。这类用例要低调执行因为连续输错次数可能导致设备锁定或触发报警。我会先和甲方确认设备锁定策略再决定是单次尝试还是结合资料做离线口令恢复测试。3.6 安全日志与告警联动用例一个完整的安全测试不能只看漏洞能不能利用还要看安全设备能不能发现问题。很多工控项目已经上了防火墙、IDS、日志审计平台但这些设备往往长期处于“哑巴”状态告警从不触发日志无人审计。我设计的日志联动用例思路是在测试过程中故意触发低风险事件比如异常功能码请求、错误密码登录、非授权端口访问然后在 30 分钟内检查工控防火墙、IDS、日志审计平台的告警记录。如果三个平台都没有任何告警那这条用例的结果不是“通过”而是“安全监测失效”这个发现往往比漏洞本身更严重。执行这类用例时要注意提前和安全运维团队约定好时间避免误报引起不必要的恐慌同时测试动作本身要可追溯在每一条日志用例的步骤里记录操作时间、来源 IP、目标 IP、具体报文特征。这样后续排查告警是否被正确关联时就有明确的对应关系。4. 常见问题与排错实录我在现场踩过的坑测试用例设计得再完美现场执行该踩的坑一个都不会少。我下面列几个最具代表性的问题和我的处理方法希望能帮你少走弯路。4.1 一不小心把 CPU 打满影响控制器的常见原因和规避某次测试中我执行网段扫描用例时扫描了一个老式 PLC 的全部端口结果不到两分钟控制器 CPU 负荷从 20% 冲到 95%操作站画面开始卡顿。事后分析原因是 PLC 的通信处理器对每个新连接都要动态分配资源高并发连接直接造成资源耗尽。从那之后我所有的扫描用例都加上三个保护参数并发连接数不超过 10、单 IP 超时时间不超过 3 秒、连续扫描总时长不超过 10 分钟。同时保留现场操作员的实时反馈渠道一旦操作员报告画面卡顿或设备响应变慢立即停止该用例。这个习惯帮我避开了多次潜在事故。4.2 测试过程造成 PID 环路震荡怎么预先识别风险协议重放用例最容易出现这类问题。某次我们对一个液位调节回路的控制器的模拟量输入通道做数据重放测试虽然写入的是低权限寄存器但由于重放频率过高控制器在几个扫描周期内接收到了大量非预期请求导致 PID 运算输出抖动现场液位出现小幅震荡。现在我在用例风险定级阶段会特别要求工艺方标注“调节回路相关点位”。凡是关联 PID 调节的寄存器地址默认不进入重放用例如果必须测试必须提前切手动模式让回路处于人工控制状态。这个细节写进用例模板的“业务影响”字段后基本杜绝了同类问题。4.3 工控协议测试工具误报/漏报如何二次确认工控安全测试工具往往对私有协议解析不全误报和漏报都很常见。有次某工具把一个正常的 S7comm 读写请求标记为异常指令我们顺着告警花了两小时排查最后发现只是工具不支持该型号 PLC 的扩展功能码。我的处理方法是所有工具告警都要到原始报文层面复核。在抓包文件里找到对应报文手工对照协议规范判断功能码、数据块号和错误代码。如果工具报告“认证绕过”但报文里没有明显的密码请求与响应过程我宁可标记为“待验证”也不轻易写进正式报告。测试用例的记录里也应该设计一个“工具误报复核”步骤把复核结论作为最终判定依据。4.4 用例执行顺序错了导致现场事故推荐执行顺序用例执行顺序看似小事实际上很容易出大事。我有一次先跑了 UDP 端口扫描再把协议 Fuzz 放到后面结果老旧 PLC 在处理完异常 UDP 报文后通信模块进入不稳定状态后续 Fuzz 用例结果全部失真。现在我的推荐顺序是被动资产识别、配置核查类用例、读取类协议用例、主动端口扫描、写入类协议用例、重放和 Fuzz 类用例、权限升级用例。前面的用例为后面的用例输出基线数据后面的用例不污染前面的测试结果。同时写人类用例必须放到读取类之后因为只有先确认设备响应正常才能判断写入后的结果变化是否有效。可以用一个简洁顺序表辅助现场执行执行阶段典型用例类型主要风险第一阶段被动资产识别、流量采集低第二阶段配置核查、账户枚举中低第三阶段主动端口扫描、协议指纹识别中第四阶段读取类协议测试、异常功能码测试中第五阶段写入类测试、重放测试、Fuzz 测试高第六阶段权限提升验证、固件离线分析、日志告警复核中4.5 证据固定与报告输出测试用例结果怎么让客户和监管认可工控安全测试的报告如果只有一张漏洞列表很难得到客户和监管的认可。我倾向于把每条用例结果和原始证据打包形成可追溯链条。比如 Modbus 异常功能码测试的用例最终输出包含六要素测试时间、源 IP、源端口、目标 IP、原始请求报文十六进制、设备响应时间。缺少其中任何一个要素报告的可信度都会打折扣。在报告章节里我会把每条用例的“预期结果”和“实际结果”并列展示差异项自动进入发现列表。这样客户看到的不只是一个“漏洞”而是完整的测试过程和判定依据。很多业主后来反馈这份证据链帮助他们顺利通过了合规检查因为监管专家能够清晰地看到测试动作、授权范围和风险控制措施。5. 个人体会与可复用的小技巧做了这么多现场测试后我越来越觉得工控安全测试用例的核心不是“更多”而是“更准”。哪怕只有一个网段、一台 PLC把风险分析和回滚方案做透了也比拉着一张几百条用例的 Excel 表强得多。测试用例的颗粒度应该细到让一个没有参与前期交流的工程师拿着也能执行而不是只有写用例的人心里清楚。最后分享一个小技巧我在所有工控测试项目里都会准备一份“紧急停止用例”它本身不是用来测系统漏洞的而是用来测我们的测试流程能不能快速停止。这份用例写清楚了什么条件下触发中断、中断后需要执行哪些操作、由谁负责与甲方操作员沟通、中断后如何恢复现场。很多团队的核心漏洞不是没有测试用例而是没有止损用例。只要你把止损用例放在整个用例库的第一优先级你在工控安全测试这条路上就会稳得多。