我去年做了好几个工控产品的 GB/T 42456 评测认证项目从送检材料准备到现场测评再到整改复测整条链路跑下来最大的感受是这个标准不是给产品贴个安全标签那么简单它实际上在逼着研发团队把信息安全当成产品功能的一部分来设计。很多厂商第一次送测时都会栽在同一个问题上——把 SL 等级当成一个考级目标而不是一套需要系统落实到设计、开发、运维全流程的能力要求。这篇东西就把我对这套评测认证的理解和实操经验整理一下重点说说 SL 等级怎么定、评测怎么开展、被测环境怎么搭以及那些送测前最容易忽略的细节。1. 不只是合规盖章GB/T 42456 的 SL 评测到底在评什么1.1 SL 到底是什么先把这个概念掰开。SL 在这里是 Security Level也就是信息安全等级不是 Safety Level跟功能安全里的 SIL 完全是两码事。功能安全解决的是设备别把机器搞坏、别把人伤着的问题而 GB/T 42456 语境下的 SL 要解决的是设备在面对恶意攻击时还能不能扛得住的问题。GB/T 42456 是工业自动化和控制系统信息安全方向的国家标准2023 年发布实施。它面向的是工业控制产品本身不管是 DCS、PLC、SCADA 前置机还是软逻辑控制器都可以套用这套框架来评估其安全能力。标准里把安全能力划分了几个等级从低到高分别对应不同的威胁场景比如 SL 1 面对的可能是偶然的、非恶意的越权操作或误配置SL 2 就要面对简单的、使用公开工具的恶意攻击等到 SL 3、SL 4 级别对应的是有组织、有明确攻击目标、可能使用定制化攻击工具的高能力攻击者。简单来说SL 等级越高标准要求的安全防护能力就越强评测时的验证深度和广度也完全不是一个量级。我在评测项目里经常跟厂商解释一个观点SL 等级不是厂商自己想要哪个等级就报哪个等级。标准的要求是你先得说清楚你的产品会用在一个什么样的预期使用环境里然后基于威胁分析来确定目标 SL。换句话说等级是需求分析的结果不是商务谈判的结果。有些厂商一上来就想评 SL 4理由是等级越高越有面子结果等到现场评测时发现连最基本的审计日志要求都没做全反而拖长了整个认证周期。1.2 哪些力量在推动厂商主动做评测在过去工控产品做信息安全评测的厂商并不多但这几年形势变化非常明显。结合我接触到的实际案例驱动力主要来自三个方向第一是行业客户的准入要求。很多电力、石油石化、水务、轨道交通行业的集成商在采购控制系统时已经把 SL 评测认证作为入围门槛写进了招标文件。你拿不出有效的评测报告就连投标资格都没有。这已经不是一个加分项而是一个必选项。第二是系统集成项目的验收要求。大型工控系统项目竣工验收时业主方会要求提供核心设备的安全性证明而 GB/T 42456 评测认证是目前最直接、最权威的佐证材料之一。我遇到过一个项目系统里的上位机软件和控制器都要求提供 SL 评测报告否则整个子系统的验收就得挂起。第三是供应链合规的传导效应。一级设备商被下游客户要求就会向自己的上游供应商传导。比如做软 PLC 的厂商其底层运行时环境如果用了第三方组件那第三方组件也需要有相应的安全测评依据。评测认证正在从单品走向供应链链条化。所以说SL 评测认证解决的不是厂商自己想不想做的问题而是产品要进入某个市场、某个系统有没有资格的问题。理解这一点你才能明白后面所有流程设计的目的——它是一次独立的第三方验证不是厂商自己写份自测报告就完事的东西。2. 吃透标准里的 SL 等级模型才能定准评测边界2.1 等级模型的设计逻辑GB/T 42456 的安全等级模型整体思路和国际上 IEC 62443 系列标准保持了很好的一致性——把产品的安全能力拆成若干层次每一层有对应的基础要求高层级在低层级的基础上做叠加增强。这样做的好处是评测机构和厂商都能清清楚楚地知道要达到某一个 SL 等级必须满足哪些要求而且等级之间是可比的、可追溯的。用大白话打个比方如果你把工控产品比作一栋楼SL 1 就是楼要有门、有窗户能挡君子但挡不住有心的贼SL 2 要求门锁要换成防盗锁窗户要装防盗网SL 3 就得加门禁系统、监控摄像头有人闯入还能留下视频记录SL 4 则是整个楼宇要有动态的入侵检测和联动响应机制入侵发生的同时就能触发警报和应急措施。在评测时等级的判定不是打一个总分而是桶效应——每一个要求域都得达到目标等级对应的底线任何一个大项不达标整体等级就不能往上走。我见过一个很典型的案例某产品的身份鉴别和访问控制做得非常好但安全审计这块的日志留存时间只有一周标准要求至少 180 天结果整体只能评到低一档的等级。厂商很不服气觉得审计是小事但恰恰是这种看起来没那么要紧的要求最能反映产品在真实运营环境中能否支撑安全事件的追溯分析。2.2 标准主要从哪些维度考核产品从实证评测的角度看GB/T 42456 的安全要求大致分布在以下几个维度每个维度下都有细化的技术条款身份鉴别与访问控制包括用户唯一标识、口令复杂度与更换周期、多因子鉴别、最小权限、越权访问防护、账户锁定策略。很多老一代工控产品在这个维度上欠账最严重默认账户、空口令、硬编码口令的问题一抓一个准。通信与数据安全包括通信会话完整性校验、数据保密性、敏感数据存储保护、时间同步安全。实时以太网总线上跑明文数据在工控现场非常普遍这条要根据目标等级做针对性验证。远程维护与服务安全包括远程访问的身份认证、会话加密、维护端口管理、无线接入的安全防护。安全审计与日志包括审计事件记录范围、日志完整性保护、时间戳一致性、日志导出与备份。评测时审计员会逐条核对采集到的日志内容和字段格式。恶意代码与软件安全包括已知漏洞的管理、软件/固件的安全升级机制、升级包签名校验、启动过程的完整性校验。这个维度在近两年被提到了很高的优先级尤其是供应链投毒和勒索软件事件频发之后。资源保护与可用性包括通信带宽限制、资源占用不因异常流量而耗尽、检测异常网络行为的能力。简单说就是抗拒绝服务的能力。评测等级越高每个维度下的必测项就越多测试深度也越深。在 SL 1 层面可能只需验证有还是没有到了 SL 3、SL 4就要验证在真实攻击发起的情况下防护机制是否真的有效、是否会产生告警、日志是否完整记录了整个过程。2.3 一个容易混淆的概念SL 和 SIL前面提过 SL 和 SIL 的区别但实际项目中还是经常被混用。我做过的某个项目里甲方提供的技术要求里赫然写着产品信息安全等级应达到 SIL 3。安全工程师一看就知道写错了——SIL 是功能安全等级对应的是 IEC 61508/61511 那一套衡量的是系统的可靠性、故障率和失效安全行为而 SL 衡量的是系统抵抗恶意攻击的能力两者的威胁模型、评估方法、验证手段完全不同。如果一套产品既要做功能安全认证又要做信息安全评测这两者是独立开展但又需要交叉关注的。比如密码模块的软件实现可能影响硬件的故障诊断覆盖率安全更新的机制不能影响功能安全的版本管理流程。有经验的安全评测机构在开展 SL 评测时会主动向厂商索取功能安全的文档来交叉验证这一步很多新手容易忽略。3. 拿到一个工控产品评测认证从哪下手3.1 评测流程的整体脉络一个标准的 GB/T 42456 SL 评测认证项目大致要经过五个阶段申请受理与方案确认、文档审查、现场评测、整改复测、报告与发证。整个周期如果顺利大概 6 到 8 周如果现场评测阶段集中爆发中高等级问题需要二次复测周期就会明显拉长。申请受理阶段要做的最重要一件事是确定被测对象的目标 SL 等级和评测范围。评测机构会要求厂商填写一份产品基本信息表包括产品名称、型号、版本号、部署形态、硬件平台、操作系统、主要通信协议、预期使用场景等。别小看这张表后面所有评测活动都是围绕它展开的。我遇到过厂商填的版本号是 V2.0结果送测到现场的固件实际是 V2.1 的情况整场测试被迫中止因为被测对象和申报材料不一致测评记录在法律效力上是不成立的。3.2 文档审查最容易暴露问题的环节很多厂商以为评测的重头戏是现场拿设备做攻击测试实际上从我的经验来看文档审查阶段就能淘汰掉相当一部分产品。标准对文档的要求不是提供一本说明书那么简单它要求提供一套能证明产品安全能力设计有依据、实现有追溯、运维有指导的完整证据链。通常需要提交的文档包括安全设计说明、威胁分析报告、安全需求规格说明、安全需求追溯矩阵、软件物料清单SBOM、漏洞管理流程、安全配置指南、安全运维手册等。这里面最容易出问题的就是需求追溯矩阵。这是一张把安全需求映射到具体设计实现和测试用例的表审计员会抽查其中的条目到现场去验证它是不是真的实现了、测过了。很多厂商的安全需求章节写得很漂亮但追溯矩阵里对应的是空的或者写已实现但无法指出在哪个模块、哪个版本里实现。在评测机构看来这就属于文件化的安全能力和实际机制脱节是严重不符合项。3.3 现场评测的方法组合现场评测阶段评测人员通常采用四类方法的组合访谈、检查、验证和渗透测试。访谈就是对厂商的研发人员、测试人员、安全负责人进行面谈了解产品在开发和维护过程中的安全控制措施。检查是对设备实物进行配置核查比如查看账户策略、检查开放端口、核对服务配置、审查日志留存策略等。验证是在测试环境下按标准条款逐项执行确认操作证明合规项不是只写在文档里。渗透测试则是模拟攻击者对目标设备发起真实的攻击行为比如尝试绕过身份验证、注入恶意报文、篡改固件、利用已知漏洞获取权限等。渗透测试是整个现场评测环节最有分量的部分也是最容易出惊喜的地方。测试前评测机构会跟厂商签署授权协议明确测试范围、时间窗口、风险控制措施。在测试用例设计上会结合产品的通信协议特点和行业特征来定制。比如被测产品有 Modbus TCP 服务就会设计对应的协议模糊测试用例有 Web 管理界面就会针对常见的 Web 漏洞类型做一轮扫描验证。4. 被测环境搭建实录软 PLC 平台下的 EtherCAT 主站配置4.1 为什么选软 PLC 作为例子这一节是实操向的。近期后台收到不少咨询问 CODESYS Control RTE SL 怎么配 EtherCAT 主站。其实这个问题的背后往往就是厂商在准备把基于 PC 的软 PLC 控制系统送去过 GB/T 42456 评测认证搭建被测环境时卡住了。软 PLC 这种产品形态在工控领域越来越普遍传统 PLC 以专用硬件为载体软 PLC 则是把完整的实时控制系统跑在通用工控机或虚拟机上软件层就是 CODESYS Control 这种实时运行内核。它的信息安全评测相比传统 PLC 有一个显著差异——攻击面更大。底层是通用操作系统中间是实时运行时上层是 IEC 61131-3 应用逻辑还带 EtherCAT、PROFINET 等实时总线通信能力。评测时每一层都会成为测试对象所以被测环境搭得好不好直接决定了评测结果能否真实反映产品能力。4.2 CODESYS Control RTE SL 配 EtherCAT 主站的关键步骤先说明一下我用的环境是 Windows 10 工控机 CODESYS Development System V3.5 系列 CODESYS Control for RTE SL x64。不同版本菜单名称会略有差异但整体流程是一致的。第一步安装 CODESYS Control RTE SL。这块有个特别容易踩的坑RTE 内核安装完成后必须在 CODESYS 控制面板里把实时驱动绑定到实际使用的网卡上而且这张网卡最好专门给实时通信使用。如果工控机上有多块网卡或者开了无线网卡建议在 BIOS 层面就禁用掉无关的网卡避免实时通信中断。安装完成后需要重启系统实时驱动才能生效。第二步在 IDE 里新建工程并添加 EtherCAT 主站。新建标准工程后在设备树的 Device 上右键 Add Device找到 EtherCAT Master。添加完成后左键选中 EtherCAT Master在参数里重点设置周期时间。这里有个经验值如果后续挂接的是伺服驱动器周期建议从 2ms 或 4ms 起步看伺服厂商推荐的通信周期如果只挂远程 IO 模块8ms 或 16ms 一般就能满足。周期设置过短会导致 CPU 占用率飙升甚至出现丢帧。第三步导入从站描述文件并扫描从站。从站的 ESI 描述文件XML 格式要先导入到 CODESYS 的设备库中。如果扫描不到从站先确认从站是否已经供电再检查 EtherCAT 网线是否连接的是刚绑定实时驱动的网卡。扫描成功后把识别到的从站设备 Append 到 EtherCAT Master 下方IDE 会自动为每个从站分配站地址。第四步配置分布式时钟DC和同步机制。EtherCAT 之所以能实现高精度同步靠的就是 DC。在从站配置里要启用 DC 同步让从站时钟跟随主站同步帧。任务配置方面在任务配置里新建主任务比如 PLC_PRG任务周期要和 EtherCAT 通信周期保持整数倍关系。比如 EtherCAT 周期是 2msPLC 任务周期可以设 2ms 或 4ms但不要设成 2.5ms 这种非整数倍。第五步映射 IO 变量并激活运行。把从站的过程数据映射到 PLC 全局变量后执行登录、下载、运行。正常状态下在线视图里 EtherCAT Master 和所有从站的状态都应该是 OPOperational。如果从站卡在 PREOP 或 SAFEOP 状态优先查 DC 配置、看门狗参数和任务周期设置。上面这套流程跑通就意味着这台软 PLC 已经被真正放到了一个真实的工业控制网络中EtherCAT 总线上的从站可以正常参与控制逻辑。后续评测时可以对这台设备做通信层面的压力测试、模糊测试和异常报文注入测试所有数据包都从 EtherCAT 主站网卡进出测试人员可以在交换机的镜像口抓包分析。4.3 评测网段的规划与攻击面定义搭建被测环境时还有一个点必须提前和评测机构对齐网络拓扑。评测需要一个独立的测试网段避免被测设备接入到厂商的办公网或生产网。我通常的建议是为评测环境单独准备一台工业交换机所有参与测试的设备被测软 PLC、EtherCAT 从站、测试电脑、抓包设备都接到这台交换机上形成完全隔离的测试孤岛。同时要在拓扑图上清晰标识出被测系统的攻击面EtherCAT 网口是不是三层可达的、管理网口有没有开放不必要的服务、上位机通信端口是哪个、Web 管理页面绑定在哪个网卡上。这些信息最终都会写进评测报告的测试范围描述里如果拓扑不清晰测试人员不敢随便动手测评效率和深度都会受影响。5. 报告落地前的自查清单与高频翻车点5.1 我在评测中反复撞见的几类问题项目做多了很多问题真的会反复出现。总结成几个高频翻车点供准备送测的朋友参考默认口令和弱口令问题仍然是最普遍的问题。很多工控产品出厂为了部署方便内置了 admin/admin 或 user/user现场评测时产品已经在线运行了厂商忘了先做安全配置基线结果检查环节直接暴露。审计日志的完整性和可追溯性。不少设备有日志功能但日志没有做远程转存也没有防止本地篡改的手段。评测人员可以从设备上直接修改或删除本地日志文件的话这条就判为不符合。另外时间戳没有统一到 NTP 时间源导致多个设备日志时间对不上在事后追溯分析时根本拼不出完整攻击链这也是高频问题。明文协议残留。产品支持加密通信但默认关闭评测时使用默认配置启动抓包抓到用户名口令明文传输。这种情况即使产品具备加密能力仍然会被判为不符合因为默认配置下用户很容易暴露在明文风险中。未见空闲调试接口的风险处置。很多工控设备的硬件上有串口、USB、JTAG 等接口标准要求产品对未使用的调试接口提供明确的禁用或保护措施。厂商往往觉得我们没有接那些东西但在评测里没有状声明、没有审批这些接口就是风险点。版本文件不一致。送测样品和实际销售品的软硬件版本不一致。这类问题看似低级一旦中了所有现场评测数据和结论都会被质疑必须重新安排现场测试。5.2 送测前可以对照的自查项整理一个自查清单厂商在正式提交评测申请前可以先自己过一遍产品型号与软硬件版本是否正确且完全一致默认账号是否已禁用或修改口令策略是否满足复杂度要求所有服务端口是否最小化开放关闭不需要的调试服务和未使用协议通信协议是否启用身份鉴别和加密机制不存在明文口令传输审计日志是否覆盖登录、操作、告警、配置变更等关键事件是否支持远程转存和防篡改软件/固件升级是否有签名校验机制能否防止降级和植入设备文档和实际配置是否一致安全配置指南是否完善已发布已知漏洞是否有修补计划或补偿性措施这些事项逐项确认过再去送测能帮你把现场测试阶段的大多数低水平问题提前消化掉。5.3 整改复测的策略现场评测结束后评测机构会出具不符合项清单并按照严重程度分等级。高等级问题通常是一票否决项比如存在高危可利用漏洞且无法通过配置规避、默认口令能直接获取最高权限、固件可被未授权篡改等中等级问题指在特定条件下影响安全的缺陷比如审计日志缺失部分事件低等级问题则是建议优化类不影响当前等级判定。复测不是把整改后的产品原封不动再测一遍而是针对不符合项进行回归验证同时确认整改没有引入新的安全问题。这里建议厂商在整改时保留完整的整改记录和验证截图包括整改前后对比、复测用例执行结果、测试环境 IP 和操作时间。这些材料既是复测的依据也是后续年审和监督检查时的佐证。在实际执行中还有一个经常被忽略的细节合规整改完成不代表这个版本就可以高枕无忧了。评测报告对应的是一个特定版本的设备后续如果产品发布了新的版本涉及安全功能变更的话通常需要重新评估或做增量评估。所以在产品版本管理上建议把信息安全评测纳入到版本发布流程里从流程上保证任何安全相关变更都不会漏掉评测。从第一次做 SL 评测到现在我的一个直接体会是这个认证项目的价值不在于那张报告本身而在于它强制你以攻击者会主动攻击这套系统为前提重新审视了自己的产品。很多在过去十年里被忽略的安全设计欠账就是在这种审视之下被摆到台面上来解决的。如果你的产品正准备送测我的建议很简单提前把文档证据链做扎实、把被测系统真实运行环境搭清楚、把自查清单逐条过一遍评测过程会顺利得多。