工控系统的安全事件从来不是"会不会发生"的问题，而是"什么时候发生"的问题。网络攻击的目标在扩大，从最初的IT系统扩展到了OT系统。对于工控系统来说，一次成功的攻击可能不涉及数据泄露，而是直接影响生产设备的正常运行。这就意味着，工控安全监测和应急响应能力的建设，比传统IT领域更加紧迫。今天从监测与应急的角度，聊聊工控系统怎么做好这两件事。

一、工控安全监测的特殊性

工控系统的安全监测和IT系统的安全监测，在很多方面有本质差异。理解这些差异，是做好监测体系设计的前提。

监测对象的不同。IT安全监测主要关注服务器、终端设备和网络设备，而工控安全监测还要覆盖PLC、RTU、DCS、SCADA、工业交换机等专用设备。这些设备的运行状态、通信行为和资源使用情况，都需要纳入监测范围。

监测指标的不同。IT安全监测更多关注安全事件本身的异常行为，而工控安全监测除了安全事件外，还关注系统的运行稳定性。CPU负载异常升高、内存使用率突然变化、网络通信的延迟抖动能超过正常范围，这些看似"运维指标"的参数变化，有时最先暴露安全事件。

监测时效性的要求不同。IT系统中的数据泄露事件，发现时间晚几个小时甚至几天仍然可以追溯。但工控系统中，攻击者一旦获得控制权，可能立即对生产设备造成实质性的物理损害。所以工控安全监测的实时性要求明显高于IT系统。

监测设备部署方式的谨慎性要求也更高。工控网络对延迟敏感，在线部署的监测设备可能影响正常生产。所以在工控网络中，安全监测设备通常采用旁路部署方式，只监看流量和日志，不参与数据转发。

二、建立工控网络行为基线

工控网络有一个天然的优势——通信模式相对固定且可预测。一台PLC通常只和固定的SCADA服务器通信，使用固定的协议，发送固定格式的数据包，通信频率也是相对稳定的。这种固定性为建立行为基线提供了方便。

行为基线的建立需要在一段时间内收集网络的正常运行数据。收集内容包括：网络中的设备列表及其IP地址和MAC地址；设备之间的正常通信关系，哪台设备与哪台设备有通信往来；通信协议、端口和使用频率；正常通信时段的信息规律。

基线建立之后，任何偏离基线的行为都可能成为安全告警的触发条件。新设备接入网络，但不在设备清单中；某台PLC突然开始与一台从未通信过的上位机进行大量数据交换；通信流量在深夜时段出现异常的峰值，而正常情况下的流量曲线是平稳的。

基线不是一成不变的。系统升级、设备更换、生产线调整等正常业务变化会导致网络行为改变。基线需要随之调整，否则会产生大量误报。

三、工控安全事件的发现机制

工控安全事件的发现，依赖于多层监测手段的组合使用。单一维度的监测可能存在盲区，多维度叠加才能提高发现率。

网络层监测是基础手段。通过部署在旁路的网络流量监测设备，实时分析工控网络中的数据流量。发现异常流量模式，工控协议的非法操作，未授权的设备接入等行为。网络层监测的优点是覆盖范围广，缺点是可能无法发现不上网络的单机操作行为。

主机层监测可以补充网络层监测的盲区。在操作站、工程师站等主机上安装安全代理，监控主机上的进程运行状态、文件变更、USB设备使用和网络连接。主机层监测可以发现来自U盘病毒传播、不合规的软件安装等行为。

设备层监测直接获取PLC和SCADA等控制设备的运行数据。通过读取设备的诊断日志、事件记录、系统资源占用率等信息，判断设备是否处于异常状态。有些新型PLC已经开始内置安全日志功能，可以直接读取审计信息。

日志关联分析是提升发现能力的关键。将网络层、主机层和设备层采集的信息进行关联分析，可以更准确地判断攻击行为。独立来看是正常的行为，关联起来可能揭示出攻击的全貌。

四、应急响应预案的编制要点

工控系统的应急响应预案，不能照搬IT系统的模板。工控系统的恢复操作可能涉及生产设备的启停操作，响应不当可能导致更严重的问题。

应急预案需要明确几个关键角色。应急总指挥负责整体的决策和资源调配；技术处置组负责事件的技术分析和处置操作；现场操作组负责现场的设备和工艺操作；对外联络组负责与监管部门和外部支持单位的沟通。

应急响应流程需要根据事件严重程度分级。一级事件是轻微异常，可以通过远程操作恢复；二级事件是局部故障，需要现场人员干预；三级事件是重大事故，需要停产处理。不同级别的事件触发不同的响应流程和资源配置。

恢复方案中要有明确的生产恢复步骤。不能简单地"重启系统"，而是要按照标准操作流程逐步恢复。恢复过程中的每一步，都需要确认设备状态正常后再进入下一步。恢复完成后进行一段时间的运行监测，确认系统稳定后方可恢复正常运行状态。

预案的定期演练不能省。只有通过演练，才能发现问题并持续改进。演练有两种方式，桌面推演适合验证流程的合理性，实战演练更适合检验实际处置能力。

五、应急响应的实操要点

应急响应实际发生时，时间非常紧迫，现场情况也比较混乱。提前梳理好一些实操要点，可以帮助团队在紧张状态下保持操作有序。

事件确认是首要步。收到告警后，首先确认告警的真实性，避免对误报过度反应。同时判断事件的严重程度，确定需要启动哪一级应急响应。

现场隔离和处置需要谨慎。在IT系统中，发现安全事件后可以立即断网隔离。但在工控系统中，直接断网可能导致生产线失控，引发比攻击本身更严重的事故。建议在预案中明确隔离策略，对于不同场景，是先断网还是先降级运行。

证据保全也很重要。在应急处置过程中，注意保全现场证据。工控设备的运行日志、网络通信日志、操作员的操作记录，都是事件溯源和改进防控的重要依据。不能因为在应急处置中乱了阵脚而破坏了证据链。

事后复盘与改进是应急响应的闭环。安全事件处置完成后，组织复盘会议，分析事件发生的根本原因，评估应急响应的效率，提出改进措施。改进措施形成行动计划，落实到具体责任人和完成时间。

写在最后

工控系统的安全监测和应急响应，需要在保证生产连续性的前提下，逐步建立和完善。从最基础的网路流量监测开始，逐步扩展到主机、设备和应用层面。从最基本的应急预案开始，通过演练和持续改进，让团队在真正的安全事件来临时有应对能力。