SCADA系统安全防护：威胁、安全评估与服务商选择

先看一个假设场景。它仅用于说明问题，并不描述任何真实事件或项目。一家虚构的供水企业委托开展“标准基础设施渗透测试”。执行方沿用熟悉的IT测试手册：大范围地址段、主动主机发现、服务版本识别和自动化漏洞扫描。地址段中不经意地包含了一台历史数据服务器，它同时在办公网和生产网段中都有网络接口。扫描由此继续深入，触及泵站控制器和一个旧型号的通信模块。

接下来发生的事情在办公网络中几乎不会出现。通信模块停止响应轮询，操作员HMI上的压力数值“冻结”，值班人员已经无法判断屏幕显示的是否是工艺的真实状态。操作员转为手动控制。总工程师要求立即停止测试，但合同中没有写明谁有权叫停、应当如何通知执行方。恢复用了好几个小时：该模块没有最新的配置备份，而设备供应商只能通过服务工单联系。

这个示例说明，测试人员的能力必须包括对工业过程及其限制的理解。准备不足也可能在普通IT渗透测试中影响系统可用性。在SCADA/OT中，后果还可能波及物理过程、人身安全，以及运营决策所依赖数据的完整性。因此，工控系统安全评估不是从挑选扫描器开始，而是从梳理工艺过程、信任边界、工作规则、叫停权限和恢复准备开始。

下文为CISO、CTO和运营负责人提供一套实用方案：什么属于OT，威胁路径如何从办公网和远程访问延伸到生产区域，哪些评估层级是安全的，如何记录证据，以及应向供应商和服务商提出哪些问题。

什么属于OT，以及为何以NIST SP 800-82 Rev.3为起点

NIST SP 800-82 Rev.3的终版于2023年9月发布。该文件关注运营技术的安全，并考虑了运营技术在性能、可靠性和安全（safety）方面的特殊要求。文件中的OT概念相当宽泛：指与物理环境交互、或者管理这类设备的可编程系统和设备，包括工业控制系统、SCADA、楼宇自动化系统、交通运输系统以及物理门禁系统。

这在实践中意味着两点。第一，评估边界很少与“SCADA机房”的边界重合。范围内包括操作员HMI、SCADA服务器、工程师站、历史数据库和远程访问网关，有时还包括与同一基础设施相连的楼宇管理系统或出入口控制系统。第二，熟悉的IT优先级顺序会发生变化：控制系统的可用性和运行的可预期性往往比机密性更重要，任何干预都要根据它对工艺过程的影响来评判。

是指南，而不是认证

NIST SP 800-82是一份指南，既不是通用的认证体系，也不要求按固定周期接受审计。在合同或内部制度中引用它，可以作为共同术语和参考方向，但引用本身并不意味着符合任何要求。截至2026年9月21日，下一个版本Rev.4仅以首个公开征求意见稿的形式存在，因此不能把它当作取代Rev.3的最终版本。

除SP 800-82之外，还应结合与具体技术无关的框架。NIST网络安全框架2.0帮助组织理解和改进网络安全风险管理。对于生产运营网段，比较实用的做法是描述当前配置文件和目标配置文件，并把差距映射到NIST的信息性参考。IEC 62443等行业系列标准，应结合所在行业的具体要求另行查阅。如果组织运营关键信息基础设施，最好提前弄清审计时需要哪些证据，可参阅我们关于关键信息基础设施审计方法的文章。

资产与工艺过程清点

没有资产清点，就既无法评估风险，也无法安全地规划评估工作。但在OT环境中，仅有IP地址和设备型号清单是远远不够的。需要了解每个节点承担哪项工艺功能、它不可用时会发生什么，以及由谁负责它的运行维护。

合理的起点是那些不需要接触设备的资料：设计文档与竣工文档、网络拓扑图、配置导出文件、账户清单和维保合同。被动发现是指观察网络中已经存在的流量，它能够以比主动扫描更低的交互程度识别已连接的设备。被动发现的结果应当与文档逐一核对：“按设计应当如何”与“实际如何运行”之间的差异，本身就是有价值的发现。

设备清单之外还应记录什么

• 节点在工艺中的作用及其故障后果：停机、转为手动控制、读数失真，或影响安全功能。
• 运营负责人和工艺安全负责人，以及设备供应商的联系人。
• 软件和固件版本、是否允许重启，以及原则上可以进行维护的时间窗口。
• 配置、控制器逻辑和工作站镜像的备份是否存在，以及备份是否为最新。
• 网络关系：哪些节点跨越区域边界通信、通过哪些通道通信，包括远程访问。

这样的清点是后续所有步骤的基础。信任边界、工作规则中的排除项以及恢复计划都依赖于它。

SCADA的信任边界与远程访问

信任边界是指数据或控制指令在不同风险等级区域之间传递的位置：从办公网进入生产网，从互联网访问供应商门户，或者从承包商的工程笔记本电脑连接到控制器。对于每一条这样的边界，都需要回答几个问题。究竟允许什么跨越它？由谁来控制？如何记录日志？访问权限能多快被撤销？

典型的薄弱环节往往集中在接合处。例如在两个网段中都有接口的服务器、共享账户、被办公室分析人员访问的历史数据库、用于传递报表的文件交换，以及“以防万一”而一直开启的VPN或远程访问网关。这一攻击面中的外部部分，即从互联网可见的门户、网关和服务，值得按照外部攻击面评估方法单独检查。这类检查不会直接接触生产设备，往往能以对工艺最小的风险获得有价值的发现。

供应商与承包商访问

供应商和集成商的远程访问本身就是一条独立的信任边界，应当作为单独的风险来管理。需要掌握哪些承包商拥有长期或临时访问权限、通过什么机制访问、采用何种身份认证、由谁批准会话以及日志保存在哪里。同样的方法也适用于评估供应商本身：对他们的要求和证据，可以按照第三方风险安全评估的思路来组织。

从办公网到生产区域的威胁路径

对SCADA的威胁，用路径来建模比用漏洞清单更合适：滥用可能从哪里开始，又可能跨越哪些边界到达控制功能。实践中至少要考虑三个起始区域。第一个是办公网：一台被攻陷的工作站、一台共享服务器，或者一个权限过大的账户。第二个是远程访问：VPN、网关和云端门户。第三个是供应商区域：服务连接、更新通道以及承包商的工程工具。

对每条路径，都要评估每条边界上部署了哪些防护措施、其中哪些真正经过了验证，以及措施失效时会发生什么。在OT中，后果远不止数据泄露。在IT环境中会导致系统被接管或数据被窃取的弱点，在生产环境中可能导致监控功能丧失，或者让操作员屏幕上显示不可信的数据。对工业现场而言，这往往比任何泄露都更为致命。

HMI与门户的Web组件

如果操作员通过基于浏览器的HMI、监控面板、历史数据门户、REST API或供应商远程访问门户开展工作，那么一部分攻击面就经过HTTP。在这里，Web安全标准可以直接适用。HTTP本身不在请求之间保存状态，因此会话依赖Cookie和身份认证机制。HTTP/1.1提供Upgrade机制，可以把连接切换为WebSocket，而实时数据刷新往往正是这样实现的。在验收此类组件时，应当检查内容安全策略，它有助于检测和缓解跨站脚本、数据注入等部分攻击；同时还应检查跨源资源共享、跨源资源策略和权限策略的设置，以及会话Cookie的处理方式和身份认证机制。

在需求和测试流程方面，可以组合使用OWASP的各个项目：Top 10是关于Web应用关键风险的意识文档，ASVS是验证技术控制措施和安全开发需求的基础，WSTG则提供一套测试流程。ASVS建议引用要求时带上版本标记，例如v5.0.0-1.2.5，因为编号可能随版本变化。即便是Web检查，也同样要遵守OT的规则：门户的测试副本，优于正在轮询控制器的在线节点。

关注根本原因类别，而不是追逐CVE

MITRE CWE Top 25列出了最危险、最普遍的软件弱点类别；MITRE指出，根因分析有助于消除整类缺陷，例如内存安全类和注入类缺陷。CISA的“设计即安全”警报系列专门讨论如何消除操作系统命令注入、跨站脚本、目录遍历和缓冲区溢出；针对最后一类，CISA曾与FBI联合发出警告。对SCADA安全项目来说，这为与供应商沟通提供了共同语言。询问供应商在架构层面消除了哪些缺陷类别，比讨论单个漏洞编号更有成效，因为在运行中的环境里，某些漏洞可能根本找不到安全的更新窗口。

SCADA安全评估的安全层级

OT中各种评估方法的关键区别，在于与运行中设备的交互程度。主动扫描会向网络中增加流量，并与范围内的设备直接交互。它可能导致设备运行不稳定，或者干扰工艺状态，从而可能影响安全性和完整性。被动发现则能以更低的交互程度识别已连接的设备。

由此可以确定优先顺序。首先是被动发现、配置与架构审查以及离线分析。其次是具有代表性的测试系统和数字孪生，以及计划内停机。只有在此之后，并且确有必要、得到明确批准时，才考虑对运行中的生产系统进行主动测试。

为什么主动扫描需要单独决策

不应把主动测试视为一种只需“更小心地打开”的默认模式。主动扫描应尽可能安排在计划内的OT停机期间进行。CISA和ICS-CERT关于控制系统评估的指导建议避免对生产控制系统进行主动扫描，因为这可能引发运行问题或拒绝服务，并指出被动活动可能已经足够。如果确实要对生产系统进行主动测试，应由现场人员按照评估团队的指示执行测试。同时还应考虑使用可信的替代系统或测试系统。

对客户而言，实际结论是：不要期待那些无法安全获得的利用深度，也不要相信做出这种承诺的人。在足以说明问题的证据中，侵入性最低的那一种往往就是最好的证据。从配置导出文件中确认的一项薄弱配置，比在运行中的控制器上进行的冒险演示更有价值。

工作规则与叫停权限

书面工作规则是任何SCADA/OT评估的核心文件。根据CISA和ICS-CERT的指导，工作规则规定允许的活动、涉及的系统、操作人员、停止条件和通知流程。对于OT，还需要补充具体的人员：运营方和工艺安全方的指定负责人、紧急联系人，以及对每一项主动技术分别作出的明确批准，而不是笼统地批准“主动测试”。

1. 被动基础通过文档、架构和被动发现掌握资产与连接情况，不对工艺产生影响。
2. 离线与测试台离线分析配置、备份和逻辑；有风险的技术先在测试系统或数字孪生上演练。
3. 恢复准备在任何主动步骤之前，确认最新备份、恢复步骤以及供应商可及时响应。
4. 逐项技术决策运营和安全负责人书面批准具体技术、系统、时间窗口和停止条件。
5. 计划窗口与现场人员主动操作尽可能安排在计划停机期间；在生产系统上由现场人员按团队指示执行。

工作规则的最低内容

• 范围内系统清单和明确的排除项，包括安全系统以及没有备份的节点。
• 允许和禁止的活动，并对每一项主动技术单独批准。
• 指定的运营负责人和工艺安全负责人，以及双方的紧急联系人。
• 停止条件，以及一位无需征得执行方同意、随时可以叫停的人员。
• 通知流程：在工作开始、出现偏差和工作结束时，通知谁、以何种方式、在什么时限内通知。
• 恢复计划的引用，以及备份已经过验证的确认。

一条简单的规则：如果在一分钟内找不到谁来叫停工作、如何报告，这份工作规则就还没有准备好。在本文开头的假设场景中，缺少的恰恰就是这一项。

测试开始前的恢复准备

在OT中，可恢复性是范围约束，而不是可以“以后再说”的事项。即使只是计划在运行中的系统上开展被动工作，也最好先回答几个问题。配置、控制器逻辑和工作站镜像是否有最新备份？是否测试过从备份中恢复，需要多长时间？恢复需要哪些供应商参与，他们多快能够到场？哪些节点在不停止工艺的情况下不能重启？

这些答案决定了哪些方法可以采用。没有经过验证的备份的节点，在备份出现之前，应当作为任何主动工作的排除候选。有时，准备评估过程中最有价值的成果，恰恰是发现某个关键组件无法快速恢复。无论是否有人发现漏洞，这都是一项真实存在的风险。

证据、报告与问题整改

SCADA评估的价值取决于证据的质量，而不是发现问题的数量。每一项发现都应说明：在何处、用何种方法发现，证据是在何种交互程度下获得的，它属于哪条威胁路径，可能对工艺造成什么后果，以及在运营约束下建议采取哪些措施。最好把发现与CWE类别、涉及Web组件时带版本号的ASVS要求，以及组织为自身确定的目标CSF配置文件对应起来。

在方法上，2008年9月发布的NIST SP 800-115可以提供帮助。它描述了技术测试的规划与实施、发现的分析以及缓解策略的制定，但明确表示自身并非完整的测试项目方案。它的流程指导仍然有用，而针对OT的具体技术则需要结合SP 800-82和环境约束来权衡。

在OT中，整改往往无法立即完成：更新需要时间窗口、需要与供应商协调，或者需要重新验收。因此，每一项发现都应记录临时补偿措施和验证修复的标准。如何跟踪、验证并证明修复已经生效，可参阅我们关于漏洞整改管控的文章。

评估不等于认证

SCADA/OT渗透测试或安全评估不是认证，不是法定的测评认定，也不是对防护是否充分的鉴证意见。报告描述的是测试了什么、使用了哪些方法、在什么范围内进行，以及哪些内容没有测试。如果需要用评估结果为审计做准备，最好提前约定范围和证据格式；详见我们关于面向审计准备的渗透测试的指南。

采购以及向OT供应商提出的问题

SCADA的安全在很大程度上是在采购阶段奠定的。在“设计即安全”框架下，CISA的立场是：客户安全应当是核心业务要求，而不只是一个技术选项。产品应当开箱即安全，多因素认证、日志记录和单点登录应当免费提供。针对运营技术的所有者和运营者，CISA发布了《按需安全：运营技术所有者和运营者选择数字产品时的优先考虑事项》指南。此外还有用于与经销商和服务提供商沟通的通用按需安全指南、安全软件部署指南，以及与澳大利亚网络安全中心联合发布的关于选择安全且可验证技术的指南。

软件制造商签署的“设计即安全”承诺，是朝七个关键目标努力并公开进展报告的真诚承诺，而不是认证。合理的做法是把它当作一个信号，并以合同条款加以约束。MITRE指出，开发阶段的漏洞越少，部署后的问题就越少。因此，在采购阶段提出要求，通常比对已部署系统进行昂贵的改造更合理。

下面的矩阵既适用于采购产品，也适用于选择评估服务商。

如何选择SCADA/OT评估服务商

好的服务商会先询问工艺过程，而不是先列出工具清单。他们会问：哪些功能是关键的，哪些节点不能触碰，是否有测试系统，谁负责运营和安全，恢复是如何安排的。其方法论可以追溯到规划、实施、分析和缓解策略这几个阶段，工作计划会清楚地区分被动、离线、测试台和主动活动。

危险信号包括：承诺对生产环境进行“全面攻破”，在没有计划和停止条件的情况下对运行中的生产系统进行主动扫描，缺乏正式的授权流程，保证结果，以及报告只罗列单个漏洞而没有根本原因分析和建议。任何关于费用、工期和效果的说法，都应对照合同进行核实。

开始之前，请索取一份脱敏的报告样本和针对OT环境的工作计划，并确认哪些工作只在测试台上进行、客户方由谁批准每一项主动技术。如果需要围绕这些约束整理评估范围，包括系统、排除项、时间窗口和预期证据，可以从Pentest.red的准备渗透测试范围开始。这有助于提前区分哪些内容可以安全地检查，哪些内容需要所有者单独决定。

结论：把SCADA系统安全防护作为可管理的循环

SCADA系统安全防护不是围绕某一个产品或某一次测试建立的，而是围绕一个循环。它包括工艺过程清点、信任边界、威胁路径、安全的评估层级、具有明确叫停权限的工作规则、恢复准备、基于证据的报告和整改管控，随后是能够减少新系统中缺陷类别的采购要求。NIST SP 800-82 Rev.3为OT提供总体参考，CSF 2.0帮助把发现与目标结果联系起来，而CISA的指导则说明如何避免让评估本身演变成事件。

核心原则很简单：工艺安全、完整性、可用性、供应商约束和可恢复性，与IP地址清单一样，都是范围条件。在足以说明问题的证据中，侵入性最低的那一种往往就是最好的。