1. 为什么通用安全用例在工控现场会失灵我最早是从IT渗透测试转到工控安全方向的。刚接触工控系统的那阵子我一度以为手里的Nuclei漏洞库、Nessus策略模板、还有熟悉的Web层测试用例可以直接平移过来用结果第一次进现场就吃了大亏——那把在办公网用得顺手的扫描器在车间控制网里刚跑了两分钟PLC直接进了STOP状态产线当场停了十分钟。车间主任的脸色我现在都记得。这件事让我彻底意识到工控系统安全测试用例不能从IT领域直接照搬。它不是换个IP段再扫一遍那么简单而是从测试目标、测试手段、测试时机到结果判读整个逻辑都要换一套。原因也很本质IT系统追求的是机密性优先数据坏了可以重传工控系统追求的是可用性优先PLC一停物理世界就跟着停这中间没有缓冲和重试的机会。具体来说通用用例失灵的原因在三个层面第一目标对象的实时性敏感。IT设备对延迟的容忍度在毫秒级到秒级之间可PLC的扫描周期往往是几十毫秒哪怕是几个ICMP探测包占了CPU都可能导致看门狗超时触发停机保护。安全测试里最常规的TCP SYN扫描在IT里是小儿科在工控网络里却可能变成一次物理事故。第二工控协议的脆弱性和特殊性。Modbus TCP、S7comm、EtherNet/IP这些协议在设计之初压根没考虑安全。它们的报文结构简单到你发一个异常请求设备就可能进入异常状态。而且这类协议往往没有加密和认证但你不能用测试Web应用的方式去测它们——因为一个非法的写请求不只是数据被篡改而是设备真的要执行动作比如阀门打开、电机反转。第三现场环境对测试行为的容忍度极低。工控系统的运行环境通常是7x24小时不间断生产的任何测试动作都有可能干扰生产。所以工控安全测试用例在设计阶段就必须考虑这个用例会不会影响生产而不是这个用例能不能发现漏洞。所以这篇文章我不打算给你一份通用的安全测试用例大杂烩而是用我实际跑过现场的经验聊聊工控系统安全测试用例到底该怎么想、怎么设计、怎么落地。如果你正准备做一次工控系统渗透测试或者安全评估这篇文章会帮你避开不少弯路。2. 工控安全测试用例设计前先认清现场的五条硬约束安全测试用例不是凭空写出来的它受制于你测试对象的物理环境和运行特征。工控现场有五个硬约束几乎决定了你所有用例的可行范围。我建议你在写第一条用例之前先把这五条跟被测试单位确认清楚。约束一测试窗口期。绝大多数工控现场不会给你随时可以测的权限只能在大修窗口通常每年一两次、停机检修、或者新建产线调试阶段才能做深度测试。我见过一个负责人的做法测试窗口只有4个小时那就把用例按优先级排成三个梯队——第一梯队是非侵入式的观测和流量采集第二梯队是低风险的协议交互验证第三梯队才是会触发报警或停机的深度验证。窗口不够就把第三梯队直接砍掉宁可测不全不要测出事故。约束二设备关键等级。一个车间里不是所有设备都同样重要。涉及安全联锁SIS的PLC、控制燃烧炉的DCS控制器这些是一级保护对象任何用例都不能直接打上去而一些独立的工艺检测仪表、非关键的辅助设备风险容忍度就会高一些。设计用例前把被测试设备按直接影响安全间接影响生产不影响关键工艺分三级每级用例的激进程度完全不一样。约束三网络可达性边界。工控网络分PLC层、HMI/SCADA层、上位机/MES层各层之间的访问控制策略往往形同虚设后面细说但测试用例必须明确你从哪个位置发起测试。是从工程师站横向移动是从HMI所在VLAN扫描还是直接物理接入PLC交换机不同位置看到的攻击面完全不同用例的适用性也就不同。我习惯在用例表格里加一列测试源位置避免测试结果跟实际攻击路径对不上。约束四可用性测试的触发条件。有些用例天生就是破坏性的比如验证PLC拒绝服务、验证协议Fuzzing导致设备崩溃。这类用例不能真在生产环境做只能在测试床、虚拟化环境或者在允许停机的新建系统上做。我通常会在用例文档里明确标注破坏等级L1无影响、L2可能产生告警、L3可能中断通信、L4可能导致设备停机。L4用例必须单独走审批流程。约束五安全测试团队自身的能力边界。这一点很少有人提但非常重要如果一个测试用例的预期结果你自己都无法判断对错那这个用例就不合格。比如你发送了一个畸形S7comm报文PLC有没有异常你并不能从网络侧直接观察到需要有人在现场看PLC的指示灯和诊断缓冲区。所以设计用例时要把结果判读手段一并设计进去包括观察点、辅助人员、日志采集方式。这五条约束想清楚了你的用例清单才不是一纸空文。我在实际项目里见过太多看起来很全的用例文档到了现场第一条就执行不了——要么是目标设备不敢碰要么是测试工具不被允许安装要么是网络割接把你挡在门外。提前用约束条件筛一遍比事后在实战中调整要高效得多。3. 面向三层架构的用例拆分从PLC到HMI再到上位机工控系统的测试用例如果按漏洞类型来组织你会发现很难落地因为同一个漏洞类型在不同设备上的表现和测试方法完全不一样。我建议直接按工控系统的经典三层架构来拆每一层的关注点、测试手段、风险等级都不同。3.1 PLC/DCS控制器层关注固件完整性与逻辑操控这一层是整个工控系统的心脏。PLC跑着控制逻辑直接驱动物理设备。常见的安全测试切入点有三块第一PLC的固件与程序完整性。攻击者篡改PLC固件或者下装恶意程序是近年来很受关注的攻击路径。测试用例通常包括检查PLC固件版本是否与官方一致、尝试读取PLC内部的程序块并比对已知的合法备份、检查是否存在未授权的远程下载/上传通道比如S7comm的PUT/GET功能是否对外开放。第二PLC的未授权访问控制。多数老型号PLC默认不启用密码保护或者使用弱口令比如Siemens S7-200的默认访问级别、三菱FX系列的默认口令。测试用例就是直接尝试未认证连接、默认口令登录、以及枚举CPU的Stop/Run状态切换指令。但注意真正切换CPU状态之前必须与现场确认否则就是事故。第三PLC诊断信息泄露。很多时候攻击者不需要真正拿下PLC只需要通过协议读取到设备名称、程序块名称、IP配置、运行状态就能为后续攻击铺路。这类信息泄露型用例是非侵入的优先执行也能最快暴露问题。3.2 HMI/SCADA层重点关注认证授权与脚本注入HMI和SCADA系统是操作员与工控系统交互的窗口。这一层通常是Windows主机或者嵌入式屏攻击面比PLC大得多。对Windows上的SCADA客户端/服务端大部分IT测试用例可以复用但需要特别关注几个工控特有的点SCADA软件的报表功能是否支持自定义SQL脚本SQL注入风险、报警通知功能是否拼接了可执行命令、HMI工程文件是否有未加密的账号密码存储、项目文件的下载/上传过程是否有合法性校验。HMI工程本身也可能被恶意篡改——攻击者改了画面上的数值显示逻辑让操作员看到虚假数据。这类用例需要在测试环境中验证HMI工程的完整性校验机制是否存在、能否被绕过。实操中我发现很多HMI项目文件根本没有做签名或哈希校验拷贝进去直接加载这就是很典型的工控供应链攻击面。3.3 上位机/数据库/应用服务器层最像IT但也不能完全照搬上位机层包含历史数据库、OPC服务器、应用服务器、MES接口机等。这一层跟IT系统的相似度最高Web漏洞、操作系统漏洞、数据库漏洞的测试用例基本可以平移。但有一个工控特有的点必须注意上位机与PLC之间的通信链路。很多上位机通过OPC DA/UA、Modbus、S7comm等协议与PLC通信这里存在一个典型的中间人风险点——上位机与PLC之间往往没有双向认证测试用例可以设计为在链路中插入一个伪造的OPC UA服务器观察PLC是否接受来自非授权客户端的订阅和写入。这在实际攻击场景中就叫PLC哄骗PLC spoofing。还有一点工控上位机的补丁管理普遍落后很多机器甚至还在跑Windows XP Embedded、Windows 7。你不需要花太多精力去找0day常规的永恒之蓝MS17-010类漏洞一打一个准。测试用例里应该包含对这类存量系统的专项检测同时要在报告中明确补丁更新需要结合工控软件兼容性评估不能照搬IT的全量打补丁策略。4. 协议层用例Modbus TCP、OPC UA、S7comm的测试切入点工控协议是工控系统最独特、也最容易被轻视的攻击面。很多人会用Wireshark抓几个包就觉得了解了协议但真正设计安全测试用例时需要理解每个协议的功能码、服务类型、会话状态。我挑三个最常见的协议聊聊实际测试中的切入点和注意事项。4.1 Modbus TCP遍地都是的裸奔协议Modbus TCP可能是工控网络里最常见、也最好测的协议。它基于TCP 502端口报文结构极其简单没有认证、没有加密、没有报文完整性校验。测试切入点非常清晰。第一功能码探测。Modbus的功能码从01到08、0x0F、0x10等。测试用例应该覆盖遍历所有功能码记录设备返回的异常码。如果设备对功能码8诊断返回了数据说明设备暴露了诊断能力。如果设备允许未认证的功能码0x10写多个寄存器那就是直接可以被远程改参数的漏洞。第二非法地址和越界访问。Modbus的数据地址空间如0x0000-0xFFFF很多设备对越界地址的处理不严谨。发送超出寄存器范围的读请求有些设备会崩溃或者返回异常数据。这个用例可以验证设备的鲁棒性但在生产环境执行前要评估风险等级。第三广播报文测试。Modbus广播报文目的地址0会被所有从站处理。如果你向网络里发一个广播写请求所有从站都会执行——这既是测试点也是一种高危攻击方式。用例可以设计为验证广播写请求是否被从站响应评估网络里是否存在一条报文控制所有设备的风险。4.2 OPC UA看似安全配置却容易出错OPC UA是工控系统走向信息化的重要协议它支持加密和认证但这不意味着安全。我见到太多现场把OPC UA配成SecurityPolicyNone明文直连跟裸奔没有区别。测试OPC UA时我用UA Expert这个官方客户端做验证工具用例设计包括尝试以匿名身份连接服务器看服务器是否允许。如果允许说明认证策略是关闭或配置错误的。检查SecurityPolicy的设置。如果服务器端同时支持了None和Basic256Sha256那攻击者可以主动协商降级到None抓包直接看到明文数据。检查Session的超时策略与会话管理。有些OPC UA服务器允许无限Session而不清理这会导致资源耗尽型拒绝服务。检查服务端证书是否被客户端验证。很多工控组态软件的OPC UA客户端默认信任所有证书测试用例可以伪造一个自签名证书去连接看客户端会不会报警。OPC UA的测试工具除了UA Expert还可以用python的opcua-asyncio库写一些自动化脚本批量检测多台服务器的安全配置。这类用例基本都是非侵入性的适合在正常运行网络上执行。4.3 S7comm从PUT/GET到加密保护的演进西门子S7comm协议在工控安全圈里耳熟能详。使用上和Modbus TCP类似也是基于TCP 102端口的明文协议。S7comm最大的特点之一就是支持PUT/GET远程读写的能力允许上位机直接读写PLC数据块不需要经过组态软件的完整会话管理。测试S7comm时我通常关注这几个点第一PUT/GET是否被禁用或者限制。在西门子较新版本的CPU里可以在组态中禁用PUT/GET通信。测试用例就是用Snap7这类工具直接发起PUT/GET请求看PLC是否响应。如果不响应说明配置正确如果响应意味着攻击者可以远程读写数据块寄存器篡改工艺参数。第二S7CommPlus的加密保护是否启用。新版西门子CPU支持S7CommPlus对通信做了加密和完整性保护。但如果你抓包发现仍然是明文S7comm说明CPU配置成了兼容模式。这个用例很关键——很多人以为买了新PLC就安全了实际上协议还能跑明文。第三PLC的会话建立过程。S7comm的会话建立需要经过几轮协商。测试时可以从一个不存在的IP地址或伪造IP发起会话请求观察PLC是否接受、是否暴露了固件版本和模块信息。这些信息收集对攻击者很有价值测试用例里应该包含。协议层的用例设计核心原则是先观察、后交互、最后破坏。捕捉一切可以用于报修、指标评价的明文信息同时避免不必要的破坏性操作。我在实际项目中协议层用例的产出通常占整个安全评估成果的60%以上因为多数工控现场在协议安全上几乎是空白。5. 可直接落地的工控安全测试用例清单含参数与预期结果讲了这么多设计思路我来给一份真正可落地的用例清单。这些用例都来自我实际执行过的项目参数和预期结果我已经整理成了一个相对通用的模板。你使用时需要根据目标设备的品牌型号和现场网络架构微调。5.1 信息收集类用例L1非侵入用例编号测试动作工具预期结果判定INF-01对目标网段进行全端口TCP扫描识别开放的工控协议端口502、102、44818、4840等Nmap记录开放的协议端口如果全部关闭说明做了端口封禁是好的现象INF-02对发现的主机进行UDP端口扫描重点发现EtherNet/IP的44818、OPC UA的4840Nmap, UDP scan记录暴露的UDP服务INF-03抓取PLC/SCADA通信流量统计IP、MAC、协议类型、流量大小、周期性特征Wireshark, tcpdump产出网络通信拓扑和资产清单线索INF-04识别工控设备的品牌和固件版本Nmap OSD, 协议指纹交叉比对厂商公开漏洞库形成设备-漏洞映射表INF-05检查PLC的SNMP服务是否开启是否公开了系统描述信息snmpwalk, onesixtyone能walk出系统信息即判定为风险建议关闭或限制SNMP这类用例全部是非侵入式的不影响生产也是每次安全评估的起点。即使最后测试窗口很短信息收集类用例也一定要跑完因为后面的用例都依赖这些结果做决策。5.2 身份认证与访问控制类用例L2低风险用例编号测试动作工具预期结果判定AUTH-01尝试以默认口令/弱口令登录HMI组态软件、SCADA数据库、工程师站账号Hydra, 手工验证能登录成功即判定为严重风险要求整改密码策略AUTH-02通过Modbus TCP直接发起写请求功能码0x06/0x10不附带任何认证信息ModbusPoll, cmsgateway脚本设备正常响应并写入说明无写保护判定为严重风险AUTH-03通过S7comm PUT请求读写DB块测试是否需要认证Snap7能读写即判定为严重风险建议在CPU组态中禁用PUT/GETAUTH-04使用UA Expert尝试匿名连接OPC UA服务器UA Expert连接成功并浏览到节点即判定为认证配置缺陷AUTH-05检查网络设备管理接口Web/SNMP/Telnet的登录认证强度Nmap, hydra存在明文管理协议或者默认凭据即记录整改项L2用例可能会触发一些设备的日志告警但不影响运行。我在执行AUTH-02这类写操作时会先把目标寄存器的当前值读出来、记录在案写完后再改回去如果现场允许的话做到痕迹最小化。5.3 拒绝服务与鲁棒性类用例L3/L4高风险必须在停机窗口或测试床执行用例编号测试动作工具预期结果判定DOS-01向PLC连续发送高频非法Modbus请求异常功能码、畸形报文python脚本, Scapy观察PLC是否停止响应、CPU是否进入STOP测试后必须确认PLC恢复DOS-02对PLC的TCP 102端口进行连接耗尽攻击慢速连接hping3, python观察新连接是否被拒绝、是否影响正常通信DOS-03向网络发送广播写请求观察所有从站的响应ModbusPoll广播模式若所有从站响应说明网络无广播隔离记录为风险DOS-04对HMI/SCADA服务端口进行轻量级Fuzzing工控Fuzzer, Peach, boofuzz观察是否崩溃、卡死、占用CPU过高DOS-05对OPC UA服务器的Discovery Endpoint发送大量恶意报文UA Expert 自定义脚本观察服务器响应延迟和稳定性L4用例必须在物理隔离的测试床环境执行。如果没有测试床我建议无论如何也不要在产线上直接对PLC做拒绝服务测试——这类测试的结果是不可预测的一次PLC固件崩溃可能导致系统需要重新下装程序几个小时的生产损失你承担不起。5.4 内网横向移动与边界突破类用例视授权范围用例编号测试动作工具预期结果判定LAT-01从办公网尝试直接访问工控网段的协议端口Nmap, route策略验证若可直连说明缺少边界隔离判定为严重风险LAT-02从工程师站跳板尝试ARP欺骗中间人嗅探PLC与上位机通信ettercap, bettercap能嗅探到明文协议数据即判定协议保密性不足LAT-03在工控网段植入临时笔记本尝试以已获取的HMI凭据登录其他主机Mimikatz凭据窃取, psexec验证横向移动路径是否可行LAT-04检查工控VLAN间是否有ACL规则尝试跨VLAN扫描Nmap, VLAN hopping技术能扫描通即说明隔离策略未生效横向移动类用例的授权范围非常敏感必须书面明确。我建议测试前在被测单位签字确认的授权书里明确列出允许测试的IP范围、允许使用的攻击手法、禁止的破坏性测试动作。别嫌麻烦这是保护自己也是保护客户的必要流程。6. 实战中踩过的坑与异常处理光看扫描结果远远不够工控安全测试的难点不只是设计用例还有执行过程中的各种意外。我挑几个印象深刻的坑这些在普通的安全测试方法论里几乎找不到但在工控现场却非常普遍。6.1 第一个坑扫描出的设备其实是虚拟HMI或者协议网关我接手过一个评估项目按信息收集结果发现一个IP开放了大量端口从21、23到502、102、4840全都在。当时第一反应是这台设备肯定是个薄弱点。结果顺着网线找到这台设备后才发现它只是一个部署在车间机柜里的Windows IPC工控机上面同时跑着Modbus网关软件、OPC UA服务器、还有远程桌面服务。真实的PLC在它下一层的私有协议总线上你扫到的攻击面只是整个系统的一层皮。这个坑的核心教训是工控网络的资产拓扑不能只看IP端口扫描必须要结合现场的物理拓扑、VLAN划分和工控软件配置。测试用例的结果判读要跟设备的实际角色绑定起来否则很容易被表象误导浪费测试窗口的时间。6.2 第二个坑主动扫描打到假阳性设备有次测试中Nmap报告一台PLC的502端口是open的但ModbusPoll连接时却一直没有响应。排查了半个小时最后发现扫描结果是因为这台PLC的交换机端口上串联了一台工业防火墙防火墙对探测报文默认通过但丢弃回复造成了端口开放的假象。这个假阳性如果直接写进报告会误导出完全错误的安全整改方向。所以我在工控测试里养成的习惯是所有关键端口扫描结果必须用实际协议握手比如真的发起一个Modbus Read请求、一个S7comm握手来二次确认。宁可多花几分钟不要在报告里留下歧义数据。6.3 第三个坑协议Fuzzing导致设备进入了不可预期状态有一次我们在测试床上对一台旧款PLC做Modbus TCP Fuzzing设备在收到某个畸形报文后CPU状态指针卡在一个未定义的异常分支里。既没有变成STOP也没有恢复RUN而是处在一种半死不死的状态——指示灯不亮程序不执行但网络连接还在。这个状态连厂商技术支持都没见过最后只能断电重启。这给我的教训很直接Fuzzing测试必须记录设备被测试前的状态运行时间、当前程序、IO状态并且在每次异常后会进行完整的状态确认和对比。任何设备还在响应但行为异常的情况都要按最高等级处理。另外如果现场有冗余CPU比如S7-1500R/H、ControlLogix冗余优先在备用CPU上测试这是最稳妥的方案。6.4 第四个坑SCADA系统的工控协议白名单会干掉你的合法测试流量现在不少新建工控项目会部署工控防火墙启用协议白名单机制。有一次我在测试一套新上的SCADA系统发出去的Modbus探测报文全被防火墙拦截了但我一开始并不知道导致所有基于网络的测试用例统统无效。后来是现场工程师在防火墙管理界面看到了告警记录才意识到问题。这个坑的启示是测试开始前一定要确认网络里有没有工控防火墙、白名单策略、以及工业IPS这类设备。如果存在建议协调现场工程师临时放行测试流量或者调整审计策略。否则你测了半天其实测的是防火墙的拦截策略而不是被保护对象的安全性。6.5 第五个坑恢复操作比攻击操作更难写用例安全测试最容易忽略的其实是测试后如何恢复这个环节。你写了一个写寄存器的用例测试前要有读原值并备份测试后要有恢复原值并确认。你测试了S7comm PUT测试后必须确认没有改动DB块的内容。我通常在每个破坏性用例后面附一个恢复步骤字段有时候恢复步骤写得比测试步骤还详细。这个习惯救过我很多次——因为工控数据一旦改错代价是实打实的生产事故不是数据库回滚那么简单。这些坑的共同点就在于它们都是你猜不到、查文档也查不到、只有到了现场才会遇到的情况。应对策略也只能是在用例设计阶段多做假设、在执行阶段保持敏感、在报告阶段如实记录异常。测试工作不是按图索骥更像是在不确定的生态环境里做谨慎探险。7. 测试用例怎么转化成整改项报告、复测与闭环用例跑完了漏洞发现了但这只完成了整个工作的一半。真正让工控安全水平提升的是把测试发现转化为可落地的整改项并在复测中验证整改效果。我见过太多测试报告写得漂亮束之高阁没人执行三个月后重新评估发现漏洞原封不动。坦白说这是我做这份工作最有挫败感的时刻。7.1 报告必须要有业务影响描述而不是只写技术细节大多数工控系统运维人员和管理层看不懂PLC启用了PUT/GET功能这个描述到底意味着什么。报告的整改建议如果只是禁用PUT/GET通信执行方很可能不知道怎么改、改了会有什么影响。我的做法是每条发现都加上三层描述技术现象、攻击路径、业务影响。比如PUT/GET功能启用这条我通常这样写技术现象S7comm协议的PUT/GET功能未禁用可以从任意IP直接读写DB块。攻击路径攻击者通过一个被感染的工程师站或入侵的HMI向PLC发送构造的PUT请求修改工艺参数如温度设定值且无需知道任何密码。业务影响可能导致产品批次报废、设备超限运行甚至停机。此路径不需要高级黑客技术20行Python脚本即可实现。整改建议也不只是禁用PUT/GET而是分步骤优先级高的短期缓解是把PLC放进防火墙隔离区内限制只有特定IP可以访问102端口长期整改是更新CPU组态、关闭兼容模式、启用S7CommPlus加密保护。7.2 整改优先级要结合可利用性和业务可忍受度我一般把整改项分为三个优先级优先级特征例子建议时限P0可直接导致物理事故或全面瘫痪且被利用门槛低PLC无认证远程写、边界完全无隔离立即整改或采取临时缓解措施P1可导致局部系统被控制需要一定攻击链组合存在弱口令、S7 PUT/GET未禁用、OPC UA匿名访问1-3个月内完成P2信息泄露、加固类不影响立即安全但增加风险SNMP公开信息、系统版本过旧、日志未集中审计按计划纳入日常运维这跟IT报告的高危/中危/低危分级不太一样——工控场景里你还要考虑漏洞被利用后对物理世界的破坏力以及整改它本身对生产连续性的影响。有些IT里的低危项比如PLC型号信息泄露在工控里可能因为暴露了攻击面而升到高危有些IT里的高危项比如SCADA服务器存在远程代码执行漏洞如果该服务器在物理上完全不可达优先级反而可以下调。7.3 复测是闭环的关键不是走过场测试用例的最大价值在复测时才能真正体现。因为没有一套标准用例你很难在整改后判断整改是否真的有效以及整改是否引入了新的问题。我建议复测采用同用例不同预期的方法同一套用例第一次测试时你希望它发现问题复测时你希望它零发现。比如AUTH-02写寄存器用例第一次测试能写入是发现漏洞复测时如果还能写入就是整改失败改成不能写入、或者被防火墙拦截那就是整改成功。但有一个极其关键的点复测一定要关注整改后旧漏洞消失但新用例是否暴露其他问题。我遇到过某个客户为了封堵Modbus写入在PLC前加了工业防火墙结果防火墙规则配置不当导致PLC的S7comm通信也断了产线工程师连夜叫我们过去排查。所以复测报告除了记录原用例的执行情况还得加一个异常观察栏专门记录那些在测试中不是预期目标但值得注意的现象。7.4 建立可持续的测试机制比一次测试更有效坦白说工控安全从来不是测一次就完事的项目。设备在变网络在变人员在变攻击手法也在变。我现在的建议是把安全测试用例沉淀成一套可以定期执行的内部检查脚本和流程至少做到每年一次全面评估、每季度一次脆弱点复查。做不到的话至少保证每次有重大变更新上系统、扩容改造、大修窗口时跑一遍核心用例集。有人觉得这样太繁琐但安全在工控现场就是琐碎积累的一线防线。从我的个人经验来说工控安全测试用例的设计和执行最重要的不是工具多高级、漏洞库多全而是你站在设备的角度想问题这台设备如果被攻击者碰了物理世界会发生什么把这个问题想清楚你的用例就自然有了分寸、有了优先级、也有了说服力。最后再分享一个小技巧每个用例表我都习惯在后面加一列测试人心得每次跑完用一两句话记录这次执行的特殊情况。积攒几轮之后这份用例集就成了你们团队最有价值的内部资产——里面所有的坑、假阳性、异常恢复方法都是别人拿不走的现场经验。