0x01.背景概述

数字取证是取证科学的一个分支，它包括计算机取证、网络取证和移动设备取证等，它是一个新兴的领域。当人们提到“数字取证”的时候，经常会想到影视剧中的桥段，比如犯罪现场调查，认为这仅仅是在犯罪调查时的一个做法。事实并非如此，数字取证是通过在特定设备或者网络中搜集和审查信息的方法，简单的讲，它就是提出问题，然后为其寻找答案的过程。当数字取证应用到ICS领域时，通常面对的不仅仅是犯罪调查这么简单，而是通过寻找证据、重建攻击链、找到ICS系统薄弱点并予以修补，对行业用户的影响不单纯停留在经济层面，而是上升到了国家安全、社会稳定的层面，比如“震网”事件，乌克兰停电事件，中东石油的TriSys事件等。

由于ICS领域的设备内部易失性内存容量小、使用的操作系统不是通用的Windows等，因此传统的数字取证工具难以平移到ICS领域内。ICS领域内的系统或者设备通常在设计和实现时没有考虑安全性，更没有与传统IT系统一样有完整详尽的数据日志或者事件记录功能。综上，ICS领域内的事件分析与应急响应人员面临一系列的挑战，面对ICS安全事件无法进行有效的数字取证。因此本文尝试讲述ICS领域内的数字取证的特点及其面临挑战，数字取证的流程及关注点，分析国外处理的一个风机燃烧事件的取证过程，呈现目前我们的研究成果及思路，最后给出未来的研究方向。由于国内在ICS领域的数字取证方向上鲜有研究，本文也只是尝试普及概念，初步探索，引领感兴趣的人员关注该方向。

0x02.数字取证挑战

与IT传统数字取证相比，ICS领域内数字取证存在诸多挑战，如下所述。

2.1 面对连续运行的ICS系统，如何实时取证？

当ICS系统出现故障或者事件时，是否有长期的实时取证措施（比如事前的大容量流量记录、长时间的日志记录），或者当事件出现后PLC控制器处于故障状态，此时在保护现场不断电的情况下如何实时取证PLC内部的有效内容（包含固件、程序逻辑、日志、配置等），以上的问题都会在实际取证工作中遇到。

2.2 ICS设备具有多样性、复杂性，协议各不相同，如何收集一个厂区内不同设备中的证据？

一个厂区的控制系统可能由超过数十个甚至数百个品牌的各种不同设备和系统构成，有PLC 、DCS、RTU、传感器，而且分布在西门子、施耐德、倍福、罗克韦尔、三菱、研华等不同厂商之中，每家的协议都有不同更有甚者一个厂家不同时代的产品协议也不尽相同，怎么利用一个通用工具收集不同设备上的内容变得十分困难，此时需要针对不同设备进行适配。

2.3 如何在发生ICS事件时快速响应，确保收集到最真实有效的数据，同时使工业现场尽快投入生产，避免更大的经济损失？

发生ICS事件这一时刻，取证所需的数据是最全面的，随着时间的流逝，取证所需的数据可能会被新的进程或者日志所覆盖，因此迅速做出响应至关重要。当面对的是一个油气行业SCADA系统事件时，其生产现场覆盖数百个场站涉及数千平方公里时，这将变得非常困难。

2.4 没有专门针对于ICS领域的DFIR（Digital Forensics and Incident Response，数字取证与事件应急响应）的相关流程和工具，因此分析起来相当棘手。

传统领域在数字取证技术上已经有很多积累，有了很多通用的分析工具，但在ICS领域内还没有合适的工具集或方便易用的工具，很多工作只能依靠人工分析。但对于PLC等设备即使可以采集到内存二进制文件，如何从内存中分离出程序逻辑、配置信息、数据片区，确定是否遭受了恶意逻辑代码攻击、配置信息修改或者寄存器数值的非法修改都是巨大的挑战。

2.5 流量分析面对的是大部分的私有且不公开协议，分析难度剧增。

传统的流量分析取证中面对的都是有固定格式的通用协议，ICS领域的私有协议占比较大，对私有协议的取证分析取决于分析人员对私有协议的理解深度和掌握的全面性、及其对流量操作中与业务节点的熟知程度，如果只知道对某一线圈做了操作但该线圈的控制点位却不清楚，其分析也是缺乏深度的。

以上只是简单列举了在ICS领域内进行数字取证面临的几个典型挑战，但实际工作中所遇到的挑战会更多，比如即使我们觉得在level2层面上使用了Windows操作系统的服务器，可以使用传统的取证工具执行分析，但这仅仅是分析中的一部分，还需要对SCADA软件的各类日志做以分析，更糟糕的是有的SCADA软件缺乏这种记录或者记录格式不易阅读。所以ICS领域数字取证与IT领域数字取证相比显得更加困难。

0x03.数字取证流程

目前在ICS领域里还没有统一的、标准的取证流程，本文参考国际范围内的相关研究提出一套针对ICS领域的数字取证流程。

取证流程涵盖以下几个阶段：

3.1 准备

该阶段需要完成以下工作：

事件发生现场的ICS系统组成、网络拓扑、资产列表、配套文档信息；根据这些信息厘清网络架构及入口、各设备的品牌版本型号、软件版本等。

现场设备及系统重要性与关键性梳理，确定哪些系统及设备属于关键部分，哪些可以切换至热备状态，哪些可以断开与其它系统连接进行独立分析等。

根据对事件的初步了解，尝试构建攻击链，判断攻击如何渗透至内网、判断采用了那种类型的攻击、触发了何种漏洞。该步骤中可以参考ATT&CK for ICS框架，初步做一个攻击草图描绘，有助于后续的证据收集定位。

3.2 识别

该步骤中需要识别出以下关键点：

识别出哪些区域受到影响或者即将受到影响，该区域的哪些组件或者设备有异常，是何种现象？根据这些现象识别出内部的数据源头和数据交互路径，为以后的采集阶段打基础。

将以上识别出的系统或者设备尽可能做隔离处理，避免正常设备或者系统受感染发展成二次事件。

3.3 分类

该阶段中需要根据识别出来的设备或者系统，详细列举设备或系统中受影响组件或者进程、设备的相关信息。信息包含但不限于：设备名称、品牌、型号、版本、所处地理位置；组件名称、关联服务名称等。

有了以上列表后，此时需要按照关键性、可获取性、证据驻留时间等因素进行优先级排序，目的是在成百上千个设备或者系统组件中筛选出优先分析的目标对象，此处虽然花费了时间，但是规避了无目的的取证丢失重要证据的风险。

3.4 采集

该阶段是取证工作的核心部分，是后续分析阶段的输入，因此该部分需要花功夫和心思去研究。经过以上阶段确定了分析对象，该部分解决的是在目标对象上收集什么信息？这些信息在哪里？需要采用什么手段采集?目标对象的关联证据还有哪些等问题。

通常在采集阶段收集的数据源来主要自于设备和网络。此处分别称其为设备数据源和网络数据源，如下图所示。

遇到设备或者网络数据源时可参考上述的内容，筛选所需数据进行采集。但是如何采集？ 对于工程师站，服务器和历史站点等，可以应用常规的IT取证工具来执行数据采集，并配合专业SCADA软件的日志采集工具采集各类日志文件，但对于更专业的控制设备（PLC、RTU等），则需要制造商提供专业软件或硬件，使用JTAG端口或其他手段提取内存，并确保在不影响设备运行的前提下执行操作。关于如何针对每种设备或者系统做数据采集，需要有明确的指导文件。最好能在事前积累各种不同设备或系统的取证方法和工具，并出具操作手册，以明晰诸多可能遇到的问题，例如：组件是否需要保持在线状态？如果可以关闭组件或切换到备份状态，是否需要先获取易失性内存数据？在取证开始后有没有哪些操作会覆盖已有证据，如何避免该种操作等等。

3.5 分析

除过采集阶段，分析阶段也是整个流程中的核心环节，该阶段是将采集阶段收集的大量流量、文件、数据、表类等进行综合分析，找到关联性，建立起攻击的详细步骤、时间线等框架，并评估对整个ICS系统及其生产业务的综合影响。

该阶段中需要借助大量的工具或者软件，但是ICS领域里可使用的工具极其有限，除过在工程师站、服务器、历史库等站点的IT部分可采用传统的取证工具和软件分析，其余相关的日志和设备数据分析都需要专有工具或者专业人员。面对目前现状，建议在分析阶段和制造厂商的专业人员联合进行，使用制造厂商的专用工具进行文件解析和数据格式恢复，使其变成调查组统一的文件格式或者类型便于后续自动化分析使用。

3.6 报告

经过以上的几个阶段，已经得到了详细的数据，最后阶段就是将详细的数据或者步骤整理成图文并茂的报告，报告中应包括详细完整的数据记录并且环环相扣的逻辑印证、事件的完整描述及证据支撑、ICS系统暴露出来的未知漏洞或者薄弱点、对后续ICS系统规划设计的意见和建议等。

0x04.案例分享

本文以国际文献中一起针对风机燃烧事件的取证调查作为案例，分析取证中的关注点及其思路。

2013年10月有两名服务工程师在荷兰一个风力发电厂的一台70 m高的风力发电机的机舱内被烧死。在大火中机舱内的所有电子设备都被大火严重破坏，唯一完好无损的设备是基座底部的地面控制器。

在该次事件调查中，调查团队从如下几个方面出发：设备内部数据采集——SCADA系统证据采集——关联业务部分证据采集。

4.1 设备数据取证

首先调查团队了解了控制设备为失电状态，此时也不能贸然给控制设备上电，如果上电则有可能覆盖掉已有的证据，接下来确定控制设备内部的RAM是否保存了想获取的证据。调查团队发现控制设备的RAM的供电电源已经下降至2.2VDC，这个电压是否可以使设备正常工作是个未知数，为了保险起见，设备制造商提供了一个特制的供电设备接入到电路中进行供电，避免因电压下降导致证据被覆盖的现象出现。

接下来需要从地面控制器内部转储证据，这个步骤需要和制造厂商一起完成，制造厂商提供了专用的软件和硬件，先是在另一个未发生事故的地面控制器上验证了软件和硬件的可用性，然后在分析对象的控制器上连接串行设备上载了配置和日志文件，其中包含了所有配置、系统、生产和警告日志，包括事故期间的记录内容。采集后就需要针对该控制器执行上电操作，上电后确认控制器内部的时钟系统是否与标准时间系统一致？如不一致需要找到相对时间差，并在分析上载日志文件的过程中归一化处理时间线。

除此之外，上载了证据后还需要对证据做唯一化处理，计算出证据文件的SHA-256哈希值并记录在案，以验证在调查过程中该文件没有被恶意篡改。利用厂商提供的专业软件去解析上载的文件，得到了xml格式的可阅读的内容，并将时间差值归并处理得到分析后的文件。

4.2 SCADA系统数据取证

SCADA服务器是运行在MS-DOS操作系统上的小型工业个人计算机。调查团队使用传统的IT领域的取证方法使用Tableau write-blocker和取证软件FTK-imager在此SCADA服务器上制作了硬盘的证据副本，该SCADA服务器记录有事件、测量和告警的相关报告。 下面显示了其中的一个事件记录。

4.3 关联业务数据取证

从风力发电业务出发寻找该机组在事故前的发电运行数据是一个很好的突破口，从电网运营公司中调取发电数据图表类信息可以佐证事故详细发生的时间点，并在该时间点附近寻找更多的信息。

从以上的风力发电机燃烧事故取证分析过程中可以得到如下结论：

事故分析时识别出范围，尽可能缩小分析的设备或者系统，做精细化采集分析；

从事故的多个关联方采集证据，包括外传的业务数据、第三方数据都有可能有相关线索；

取证中需要多方配合，针对专有设备目前最好的事后取证方法就是使用制造商的专业硬件或者软件；

ICS领域证据分析时，时间基准至关重要，在一个标准时间体系内归一化处理各种信息或者日志；

该事件的分析中还有很多不足之处，仅仅采用了事后的静态分析方法，没有从流量、历史库、备份文件等角度出发搜集证据，最终也未能形成体系化的取证方法论或报告。

0x05.研究成果

5.1 实时取证—ICS控制设备证据自动存储与分析

由以上的案例分析，得到了启发：目前都是针对事故或事件的事后调查取证，没有一个为了取证而存在的功能框架，去长期积累证据资料，尤其是面对ICS领域的专业设备，这类设备由于内存较小即使有日志记录功能也只能记录有限的条目，如果有一个面对此类设备长期保存该类设备产生的实时日志、告警等有价值的信息，平时可作为审计使用，事故发生时就可以作为证据使用的工具或者框架，那么就可以避免事后采集特定设备证据带了的一系列问题。

成型后的使用场景和功能如下图所示，框架中具备对现场的PLC、数控机床、机器人等设备做证据采集、存储、初步分析的功能。

在此，展示对西门子PLC证据采集研究的思路及其实践。西门子PLC内部有诊断缓冲区，该部分包含有错误事件、模式改变和其它对用户重要的操作事件、用户定义的诊断事件（诊断事件包括模块故障、过程写错误、CPU中的系统错误、CPU运行模式的切换、用户程序的错误等）等，这类事件的记录比较完善可以反映外部输入对控制器的操作和控制器本身的大部分故障原因，因此作为取证数据最为恰当，而且诊断缓冲区为PLC的固有功能不依赖与用户的程序或者配置。

现在的目标是采集该部分的内容，那么就需要分析协议找到该部分采集对应的功能码，并将通过S7Comm协议获取的二进制解析为人类可读、易理解的内容，经研究协议读取的是事件ID，每个ID对应固有的事件描述，通过逆向TIA组态软件中的相关组件得到相应的映射表，如下图所示。

最终通过编写py脚本将采集部分与解析部分整合做成核心模块，在功能框架中定周期或者由客户设定周期去采集设备诊断区的数据并进入下一个编排环节。采集到的日志进行格式化输出，如下所示。

5.2 特定设备取证工具—S7系列PLC内存取证

以上的研究是基于如何创建实时取证框架和工具的，通过周期采集ICS控制设备内的固有日志并且进行存储分析达到了长期采集并保留关键证据的目的。接下来从取证过程使用的特制工具出发，阐述如何针对西门子S7系列PLC制作专有内存取证工具，该工具通过物理接触的方式可dump出内存中的所有数据，从内存中寻找线索定位攻击事件。

该工具通过S7系列PLC的漏洞CVE-2019-13945来实现的，该漏洞提供了一个特殊访问的功能，当控制器在启动的500ms内如果UART接口接收到“MFGT1”后即可进入到诊断模式，该模式下可以进行任意代码执行，根据此漏洞即可制作出dump全部内存的工具。

如下所示为硬件环境。

对应的UART客户端实现部分代码如下所示。

利用制作的特定工具dump出PLC的内存内容共计128M，如下图所示为部分内存二进制数据。

以上呈现了目前研究的两个方向及其部分成果，虽然解决了一些问题，但还是有不完善的地方，比如支持设备种类有限、解析日志格式不统一、内存取证后的分析技术需要深入研究探索等。

0x06.研究方向

建议从数字取证框架构建、特定设备的取证工具和技术、通用的ICS系统取证工具集三个方面进行研究。

6.1 数字取证框架构建

目前国际研究中大多是将传统的取证框架经过部分改造应用于工控领域中，但是，这些框架中的大部分都过于笼统或缺乏实际评估和测试。对于具有案例研究或实验方法的框架，通常没有构建通用工具来验证具体功能。尽管如此，诸多研究的框架和方法确实列举了许多已经遇到或存在的问题、挑战，这些都阻碍了ICS领域系统和设备安全性的发展。展望未来，建议研究人员继续开发更广泛、更通用的框架，将这些框架应用到实际案例中，并能够形成工具以供更多人来补充不足之处。

6.2 特定设备的取证工具和技术

除了采集网络流量的取证数据之外，还必须将ICS控制设备的数据及文件纳入取证过程中，以实现ICS整体有效的数字取证。国际研究中针对PLC设备的易失性内存或内存地址进行取证，取证过程包括保存，识别，提取和记录数字证据。还有针对传感器状态和PLC中梯形图逻辑程序来判断系统是否正常运行，如偏离正常运行状态则启动记录程序用以记录当前的流量或者程序行为。 由于ICS领域内存在众多厂商的诸多设备，包含但不限于DCS、PLC、RTU、IED、IPC等，这些设备没有标准的硬件架构、操作系统、固件格式、事件记录格式等，因此给取证带来了巨大的挑战，所以未来的工作应继续推动分析ICS领域特定设备取证的方法研究，包括但不限于针对内存、固件、程序逻辑和其他数据的取证。

6.3 通用的ICS系统取证工具集

考虑到ICS领域中工控设备制造商，系统集成商，和基础软件供应商的规模，构建类似于IT领域内数字取证的通用工具集仍然是一个巨大的挑战。安全研究人员在ICS领域取证中面临的挑战与移动设备取证领域面临的设备种类繁多还有不同，具体表现在设备中专有的OS、多样化的设备制造商以及缺乏行业技术标准等。我们的目标是构建适用于更多设备和协议的取证工具和方法，但目前国内的工具箱多数偏重于IT系统的取证，对于OT域内的level2层采用抽取SCADA软件不完全的日志记录方法，只能作为取证参考，对于level1层控制设备也只有部分通用Linux系统才可以使用改造的开源工具进行分析，其余的类似于西门子、施耐德、三菱等的控制设备只能采集极其有限的日志记录辅助取证，并没有从内存、固件、程序逻辑等深入的技术点出发做出对应的研究或者产品。因此为了真正整合可用于ICS系统的通用工具集，相关从业者应努力寻找统一的原理和方法，以构建可用于多种设备和通信协议的工具，形成完整的、可用的、可靠的工具集。

0x07.总结

本文力争将ICS领域内数字取证技术做以科普和初步探索，从以下几个方面出发进行了阐述：数字取证在ICS领域的挑战与困难、数字取证应该遵循的流程、分析了国外风力发电机燃烧事故的调查取证过程、并呈现了目前我们的研究成果和研究思路，最后给出了期望的研究方向。希望看到该文章的读者能够受到启发，给出更多的研究建议和思路。如果能有更多的人关注该方向，那么这篇文章也体现了其应有的价值。

基于目前ICS领域的现状，建议行业用户能够建立ICS系统可落地的应急响应流程，当真正遇到事故或者事件后能够冷静处置、从容应对，保护现场、调集相关方尽量快速地收集最容易丢失的证据，并开展分析工作，能真正的找到事故原因并从事故中吸取教训，不仅仅是管理层面，更多的是要求ICS设备或者系统制造商共同推进安全运营，安全生产，有证可查的良性生态建设。

参考文献：

【1】：R. A. Awad, S. Beztchi, J. M. Smith, B. Lyles, and S. Prowell, “Tools, techniques, and methodologies: A survey of digital forensics for scada systems,” in Proceedings of the 4th Annual Industrial Control System Security Workshop. ACM, 2018, pp. 1–8

【2】：Peter Eden, Pete Burnap, Andrew Blyth, Kevin Jones, Hugh Soulsby, and Yulia Cherdantseva. 2015. A Forensic Taxonomy of SCADA Systems and Approach to Incident Response. In 3rd International Symposium for ICS & SCADA Cyber Security Research 2015. BCS Learning &Development Ltd, 42–51

【3】：Pieter Van Vliet, M-T Kechadi, and Nhien-An Le-Khac. 2016. Forensics in Industrial Control System: A Case Study. arXiv.org (2016). arXiv:cs.CR/1611.01754v1

【4】：https://cert-portal.siemens.com/productcert/pdf/ssa-686531.pdf

【5】：https://github.com/RUB-SysSec/SiemensS7-Bootloader