根据美国国家标准技术研究院(NIST)给出的定义[1]，工业控制系统(industrial control system, ICS)是一个涵盖了多种类型的控制系统通用术语，包括监控和数据采集(supervisory control and data acquisition, SCADA)系统、集散控制系统(distributed control systems, DCS)，以及其他控制系统，如可编程逻辑控制器(programmable logic controllers, PLC)，常用于工业领域和关键基础设施的控制系统中.工业控制系统是国家基础设施的重要组成部分，广泛应用于能源、制造、交通、军工等行业，是关乎国计民生的重要资源.
工控协议是控制系统实现实时数据交换、数据采集、参数配置、状态监控、异常诊断、命令发布和执行等众多功能有机联动的重要纽带.早期工业控制系统运行在物理隔离的环境下，独立于传统互联网，因此，相关设计与操作人员很少考虑到网络攻击的可能，且普遍存在侥幸心理[2].这导致大量协议在设计方面缺乏认证、加密等安全机制；在实现方面也对异常的协议数据考虑不充分，容易留有安全隐患.在“工业4.0”的时代背景下，工业控制系统越来越多地采用标准化解决方案.然而，这打破了工控系统原有的专用性和封闭性，使其面临更广泛的攻击威胁.事实上，近些年针对工控系统的攻击事件频发，文献[3]回顾了历史上发生过的重大安全事件，并指出随着形势的发展，面向以工业互联网为基础的关键基础设施的威胁越来越严峻.其中，攻击者充分理解相关的工控协议诸多细节，并利用协议在设计、实现或应用方面的脆弱点，是顺利实施攻击事件的一个重要因素.如2010年，“Stuxnet”病毒劫持了S7协议实现代码的关键函数，通过精确地篡改和伪造S7协议报文，成功攻击了伊朗核电站，导致伊朗核计划推迟数年[4].2017年，根据安全厂商ESET发布的消息，“Industroyer”病毒成功利用4种电力工控协议(IEC 60870-5-101，IEC 60870-5-104，IEC 61850-MMS，OPC DA)，通过控制变电站中的断路器，攻击乌克兰电力系统，造成大规模停电事件[5].同年，根据FireEye公司发布的消息[6]，针对施耐德安全仪表系统的恶意软件“TRITON”，利用私有协议TriStation进行的攻击可造成工业过程无法工作.
综上所述，深度剖析ICS的协议安全是理解工控系统安全威胁的一个重要角度，将为工业控制系统的安全防护提供参考和指导.本文通过调研和整理学术界、工业界对工控协议的安全研究工作，包括学术研究论文、标准指南、攻击事件等，从协议的角度帮助理解工业控制系统的安全性.
1 工控协议背景
Fig. 1 Typical industrial control network topology
图1 典型工控网络拓扑结构
工控协议实现了ICS各层设备组件之间的连接和通信交互，并与各设备组件共同形成了工业控制网络.从工业控制系统的业务分层看，一个典型的工控网络可分为3层：管理层(企业办公网络)、控制层(过程控制与监控网络)、现场设备层(现场控制网络)[7-8]，对应的工控网络拓扑结构如图1所示.根据传输信息的功能不同，各层的工控协议通信的实时性要求也不同，如在现场设备层，要求实时通信；而在管理层，则允许非实时通信.实际上，管理层的企业办公网使用的协议与传统互联网协议一致(如HTTP，HTTPS，POP3等)，此类协议已有很多分析和讨论，此处不再赘叙.本文讨论的工控协议是指应用于控制层和现场设备层的通信协议.
1.1 工控协议功能
工控协议在不同场景中传输相似功能的内容，可大致分为3类[9].
1) 控制信息(control message)
控制信息在控制器和现场设备之间传输，并且是控制器中控制回路的输入和输出.因此，它具有很高的实时性和确定性要求.
2) 诊断信息(diagnostics message)
诊断信息用来描述系统当前的状态，例如通过传感器获得的温度、湿度、电流、电压值等信息.这些信息用于监测厂站的健康状态.通常情况下，控制系统传输诊断信息的数据量大.相比于实时性和确定性，诊断信息的传输更强调速度.
3) 安全信息(safety message)
安全信息用于控制一些关键功能，如安全关闭设备并控制保护电路的运行.传统上，制造单元的安全联锁装置使用可靠的安全继电器进行硬接线，以确保单元内部在有操作员的情况下机器无法运行.但这种接线不容易重新配置，且出现问题时进行故障排查非常困难.通过传输的安全信息，可以更便捷地在各个组件之间协调，极大地提高了系统的重新配置和故障排除能力.
1.2 工控协议分类
根据使用的通信技术，工控协议分为4类[8]，如图2所示：传统控制网络协议、现场总线协议、工业以太网协议和工业无线协议.当前广泛应用的是工业以太网协议和现场总线协议，相比于早期的传统控制网络协议，其优点有2个：1)减少了用于通信的物理缆线，从而减少潜在故障点(如线路接头松动)；2)提高了通信系统的可维护性和扩展性(如向系统扩展添加新的设备).这些优点使得我们能更方便地构建复杂的大型控制系统.
Fig. 2 Protocol classification of industrial control system
图2 工业控制系统的协议分类
相对于有线协议，工业无线协议有更大优势，例如进一步减少了所需的线缆数量，能更灵活地配置传感器的位置等.所以，Moyne等人[9]认为工业无线网技术是工控网络的未来，但需要解决安全、可靠、实时传输等问题[9-10].
1.3 与传统协议比较
相比传统的互联网协议，工控协议传输的数据对物理世界有直接的控制和影响.因此，工业控制系统的通信则被称为控制网络，而传统互联网一般被称为数据网络.结合文献[1,9-10]，我们总结了3个方面的区别：
1) 通信场景
工控协议广泛应用于关键基础设施领域，如电力、化工、制造、军工、楼宇、交通等.其运行的环境经常遇到如潮湿、灰尘、高温等不利的情况.工控协议传输的数据能直接影响物理世界，如机械臂运动、控制断路器开合、电机启动、反应液的水位等.通信故障对物理世界可能有严重的影响，如造成生产损失、环境毁坏，甚至危及生命.
传统互联网协议如HTTP，HTTPS，POP3等主要应用于数据分享和传输，运行在清洁和温度受控的环境下.数据的产生和使用一般需要人的参与，如社交、搜索、邮件、新闻资讯、电子商务等.通信故障影响相对较小，可能给生活带来不便，但大部分都可通过其他方式进行弥补和解决.
2) 通信要求
工控协议可直接影响物理世界，它的实时性要求相对较高.如运动控制的响应时间要求的范围在0.25～1 ms，过程控制的响应时间要求的范围在1～10 ms[10].除此之外，对于控制现场设备的工控协议一般还要求传输延迟是稳定的，即要求通信延迟的抖动小.因为抖动可能造成系统震荡，产生负面影响.同时，工控系统一般还要求周期性的采样系统的状态信息，在这种情况下，设备是长时间“在线”的，数据的交互也是持续的.
传统互联网协议如HTTP，HTTPS，POP3等则对时延要求较低，大部分情况下，几百毫秒甚至几秒时间都是可接受的.同时，这些协议一般不要求长时间在线.
3) 通信过程
工控系统融合了IT领域和OT领域的技术，在通信网络上，这种融合是分层的.现实中的工控网络一般会分多层，比如普渡模型[11]将工控网络分为6层.同时，作用于OT领域的工控协议，其传输的数据包通常较小，尤其在低层次的控制回路中，仅传输单个测量值或数字值，通常只有几个字节.报文传输的可靠性主要依赖于报文中的完整性字段如CRC字段，冗余报文机制如GOOSE,SV协议等.
传统互联网协议层次较为简单，一般分为局域网和广域网.单次传输的数据量有几千个字节或更多的数据，数据包大小至少为64B.同时，传统的互联网协议，其传输可靠性一般由TCP协议提供.虽然TCP协议存在校验字段，但由于远距离传输，容易出现丢包的情况，所以它还依赖确认应答机制、超时重传机制等保障数据的可靠交互.
2 工控协议安全威胁
根据文献[12-13]，安全威胁是指可能造成信息丢失或功能失效等情况发生的事件.一般而言，安全威胁主要有2类[14]：1)蓄意攻击.如工业间谍、恐怖组织活动等，可能带来经济、政治和军事等方面的益处，也可能是炫耀技术能力或实施报复等.2)无意事件.它可能源于安全事故、设备故障、疏忽大意和自然灾害等因素.
随着通信技术的发展和进步，如高性能硬件的推出和新的保障机制的提出，系统运行的可靠性得到显著改善，这使得无意事件带来安全威胁的影响逐渐减小.相对地，随着工业控制系统的信息化水平提高，越来越多的设备和系统直接或间接地接入互联网，这打破了工控系统原有的封闭性和隔离性，加剧了其面临的蓄意攻击安全威胁.因此，我们更关注工控协议蓄意攻击相关的安全威胁，具体地，本节将从工控协议的脆弱性、攻击模式和攻击影响3个角度来讨论工控协议的安全威胁.
2.1 工控协议脆弱性
根据IETF RFC 4949[15]标准，任何一个系统都可能存在3种类型的脆弱点：设计上的脆弱点、实现上的脆弱点和操作管理方面的脆弱点.如协议设计上可能存在认证绕过/缺失、完整性缺失、信息明文传输等缺陷；协议实现上的脆弱点主要包括协议处理模块中的堆栈溢出、命令注入、空指针引用等漏洞.操作管理方面的脆弱性与协议自身的关系较弱，可通过分级隔离、人员管理等方式解决.因此，工控协议的脆弱性研究更关注协议设计和协议实现2个方面.
1) 协议设计中存在的脆弱性
工控协议设计之初更关注功能的完备和运行时的性能保障，对安全机制考虑较少.表1总结了14种典型工控协议的设计缺陷，涵盖了4种典型工控场景，包括过程自动化、智能楼宇、智能电网、智能仪表，涉及当前主流厂商如施耐德、西门子、罗克韦尔等.显然，工控协议设计在认证、授权、加密和完整性等方面普遍存在缺陷和不足.这些设计缺陷和不足可进一步分为3类.
Table 1 Defects in the Design of Typical Industrial Control Protocols
表1 典型工控协议设计缺陷
协议行业设计缺陷描述S7过程自动化完整性保护不足,面临中间人攻击威胁[16]CIP过程自动化明文传输,认证机制存在缺陷,面临重放和篡改的攻击威胁[17]Modbus过程自动化缺乏认证、授权、加密等安全机制[18]BACNet智能楼宇虽然有设计安全机制,但应用的协议存在认证缺失等缺陷[19-20]Niagara Tridium Fox智能楼宇缺乏内置的认证和基本的安全设计[21]OPC-UA智能楼宇认证过程存在缺陷[22]ANSI C12.22智能仪表密码认证部分存在缺陷[23]IEC 101智能电网缺乏安全机制设计,面临重放、数据篡改等攻击威胁[24]DNP3智能电网缺乏加密、认证和授权等安全机制[25]ICCP∕TASE.2智能电网缺乏机密性、完整性和认证机制[26]IEC 104智能电网缺乏认证和数据完整性校验机制[27]GOOSE智能电网认证、完整性缺失,报文无加密[28-30]SV智能电网未经授权的访问和篡改[31]MMS智能电网通过其他协议层提供安全保障,实际应用未实现[32]
① 协议设计缺乏安全机制.进行协议设计时未考虑安全机制，如Modbus,DNP3协议等.广泛应用于电力自动化行业的MMS[33]协议标准在“Security Considers”章节明确指出，MMS协议高级别的安全设计不在标准的考虑范围内.
② 协议对安全机制描述不具体，导致编程人员无法实现定义“模糊”的安全机制.如GOOSE协议报文结构设计中定义了一个security字段,如图3所示，该字段用来作为报文的数字签名，对通信过程传输的报文提供认证和完整性保障.同时，该字段被“ANY OPTIONAL”修饰，表明该字段是一个可选字段，可以不出现在报文中.鉴于工控场景的高实时性要求以及协议标准缺乏对该安全字段的详细定义，大部分厂商都没有实现该安全字段.
③ 协议安全机制设计存在缺陷.如BACNet协议、OPC-UA协议、ANSI C12.22协议等，它们提供安全机制，但未经充分检查和验证，存在潜在的攻击方式.发现“安全协议”的设计缺陷主要有2种方法，即基于攻击测试[19]来检测和通过形式化方法[22]进行检查.
Fig. 3 Definition of GOOSE message structure
图3 GOOSE协议报文结构定义
2) 协议实现中存在的脆弱性
在实现方面，编程人员容易默认“隔离”的工控通信环境是可信的，处理协议通信数据时未充分考虑畸形报文，导致程序可能产生漏洞，如内存溢出漏洞、非法内存访问漏洞等.CVE，CNVD，ICS-CERT等平台的漏洞信息显示，工控协议在实现上存在多种类型的漏洞，表2列举了CNVD中部分常见的工控协议实现漏洞.
同时，有些工控协议虽然设计了加密、认证等安全机制.但这些安全机制在实现时，由于错误的配置或简化的实现，使得这些安全机制存在被绕过的可能.例如西门子公司最新版本的S7CommPlus私有协议在会话阶段提供加密、认证等安全机制，但Biham等人[16]通过对该协议进行分析发现该协议存在安全缺陷：协议认证过程中所有同型号工控设备采用相同的密钥.一旦成功逆向破解一款工控设备使用的密钥，相同版本固件所有工控设备的通信都将变得不安全.施耐德电气公司设计的UMAS协议，在管理控制Modicon M221控制器时提供密码认证安全机制.但Kalle等人[34]发现该安全机制的实现存在重大缺陷，编程人员将安全保障至关重要的Hash密钥存储在一个固定的地址，一旦攻击者发送数据重写该固定地址即可将该Hash密钥覆盖，从而绕过认证机制，最终能够绕过授权执行任意操作.
Table 2 Common Industrial Control Protocol Implementation Vulnerabilities
表2 常见的工控协议实现漏洞
协议漏洞编号漏洞类型ModbusMMSCNVD-2019-00377缓冲区溢出CNVD-2020-32303拒绝服务CNVD-2018-12362拒绝服务CNVD-2019-05652拒绝服务OPC-UACNVD-2018-19099缓冲区溢出DNP3CNVD-2013-07340拒绝服务
2.2 攻击模式
根据美国国家标准与技术研究院的报告[1]，工控系统和任意信息系统一样，都有3个安全目标：可用性、完整性和机密性.相对传统的IT信息系统，工控系统的故障将直接影响物理世界，可能造成极其严重的后果，例如造成生产中断、环境毁坏，甚至危及人身安全.因此，工控协议对可用性和完整性要求更高.分析通信协议攻击模式，主要考虑3个方面，如表3所示:
Table 3 Introduction of Potential Attack Model of Industrial Control Protocol
表3 工控协议潜在攻击模式介绍
潜在攻击模式重要程度安全目标拒绝服务∕网络风暴高可用性基于中间人的攻击方式,劫持通信信道,通过篡改∕重放等方式发送攻击者定制的恶意数据包中完整性监听获取敏感信息;伪造虚假恶意报文,绕过认证机制获取敏感信息低机密性
2.2.1 破坏可用性
工控系统保障处理过程的连续可靠是最基本的要求，对组件和网络有极高的可用性安全需求.任何预期之外的停机或时延是不可接受的.正常的停机过程一般需要提前几天甚至几周的安排、测试和准备工作[1].破坏可用性的关键在于使控制系统拒绝服务或无法正常提供服务，我们总结了3种攻击模式.
1) 利用协议程序漏洞引发程序崩溃
利用程序崩溃可攻击2类重要目标：①位于现场设备层的工控设备.例如思科公司的Rittle[35]发现了一个应用于Schneider Electric Modicon M580 SV2.80 PLC的UMAS协议漏洞.攻击者向目标设备发送一个精心构造的UMAS协议数据包，使目标设备无法进行远程通信，导致拒绝服务.Luo等人[36]发现开源的IEC 104协议解析库存在非法段内存访问漏洞，发送定制的IEC 104通信数据包将造成IEC 104协议解析程序发生崩溃，导致拒绝服务.②位于控制层的监控软件.例如Dliangfun[37]发现的一个能导致MELSoft协议拒绝服务的高危漏洞.利用该漏洞，攻击者以中间人的方式向监控软件输入定制的数据包，可导致40款Mitsubishi监控软件发生崩溃，造成拒绝服务，如图4所示：
Fig. 4 Denial of service attacks on supervisory software
图4 监控软件拒绝服务攻击
Fig. 5 The relationship topology of the internal control components of the water tank[38]
图5 水罐内部控制组件的关系拓扑[38]
2) 篡改业务控制流程，造成控制过程异常
2010年，Stuxnet[4]蠕虫篡改了PLC控制程序，加快了伊朗核电站离心机的速度，并修改协议响应报文以欺骗控制中心，最终影响了伊朗的核计划实施.Chen等人[38]分析了一种有关控制时序的潜在攻击，如图5所示.图5中有2个用来盛水的水罐LIT101和LIT103.安全工作状态下的水罐有2个要求：①水罐的水量不能为空；②水罐的水量不能溢出.因此，该自动化系统的一个重要目标是维持水流的进出平衡.如果攻击者篡改了控制逻辑，例如控制水泵P101关闭，电动阀MV101打开，并从外部泵入过量的水到水罐LIT101，最终会导致该水罐进入一个不安全的状态——水位溢出.
3) 发送“垃圾”数据，恶意消耗有限的计算资源
如果工控设备花费过量的时间/资源处理“垃圾”数据，将造成关键业务流程得不到及时处理.Niedermaier等人[39]对6个厂商的16种不同类型的PLC发送过量的数据包进行测试，发现这种方式会影响大部分PLC设备扫描执行的周期时长，可造成PLC扫描周期延长甚至停止工作.如图6所示，如果传感器检测到容器的位置时，打开阀门的时间出现了延迟，可能导致液体注入错误的位置，如洒在传送带上.
Fig. 6 Fill the container on the transport belt with liquid[39]
图6 向运输带上的容器中注入液体[39]
许婷[40]分析了实际生产中的一起由故障引起的某变电站全站通信中断事故.如图7所示，某变电站系统中Ⅱ机发生了硬件故障，中断了与Ⅰ机、远动机(A网)和后台机(A网)等设备的通信.当Ⅰ机处于这种工作状态时，为了重新构建交换机地址表，自动向网络发送大量广播报文.当大量的广播报文进入连接在Ⅰ机的所有间隔层测控装置中，会给间隔层测控装置的CPU造成沉重的处理负担，最终将资源耗尽使CPU处理能力完全瘫痪，从而使变电站的CSI-200E设备和CSM-300E设备都不能正常工作，因此造成全站通信中断.
Fig. 7 Network structure of a 220 kV substation integrated automation system
图7 某220 kV变电站综合自动化系统网络结构
2.2.2 破坏完整性
破坏完整性的关键在于破坏传输数据的一致性.一致性包括数据块整体的一致性以及运行上下文的一致性.实际的攻击中一般要劫持通信，然后通过篡改或者重放等方式实现完整性破坏的攻击.针对破坏完整性的攻击，主要有3种攻击方式.
1) 通信劫持攻击
该攻击主要通过中间人攻击 (man in the middle, MITM)方式实现对通信信道的劫持，该攻击的根本原因在于通信信道未受到保护.首先，发起中间人攻击，攻击者需要先接入“物理隔离”的工业控制系统，如通过USB接口[4]或因特网[41]，甚至是内部攻击者[42].美国国土资源部和卡巴斯基公司的报告[43-44]都显示，工控协议普遍面临中间人攻击的安全威胁.在真实的攻击事件中，分析人员也经常观察到中间人劫持技术的应用，如“震网”Stuxnet事件[4]和IRONGATE攻击事件[45].
Fig. 8 Network topology of the experimental environment
图8 实验环境的网络拓扑
根据是否物理接入目标主机，中间人攻击分为本地攻击和远程攻击.本地攻击可以通过DLL替换或注入等方式Hook劫持收发网络数据相关的函数.如“震网”病毒[4]接入系统后，首先将原有的有关管理收发网络数据的s7otbxdx.dll文件重命名为s7otbxsx.dll，然后病毒将准备的DLL命名为s7otbxdx.dll实现替换.于是，“震网”病毒可以劫持所有访问PLC的网络通信，包括修改来自监控软件的请求和来自PLC处理返回的数据.本地攻击还可以通过修改网络配置的方式实现,比如修改路由表、ARP表等.文献[34]演示了通过修改iptables中的目标地址转换DNAT配置，结合ARP欺骗技术，将网络通信协议数据包劫持重定向到自己构建的虚拟PLC上.
远程中间人攻击需要与目标主机在同一个局域网，所有与目标主机的通信内容都可能被攻击主机劫持.如美国空军理工学院的Hagen等人[46]提出的TCP veto攻击，在劫持TCP连接的同时避免“ACK storm”的发生.如图8所示，HMI和PLC的通信信道经过一个以太网集线器(Ethernet Hub)，攻击者连接到以太网集线器，具备能够嗅探并注入任意数据包等能力，就可实现劫持已有TCP的连接，而仅产生少量的网络异常数据包.
2) 报文篡改攻击
攻击者一旦完成通信劫持，就可以破坏通信过程数据块整体的一致性实现攻击.因此，虚假报文注入攻击和报文伪造攻击都属于篡改攻击.协议面临篡改攻击的根源在于协议设计缺乏安全的完整性校验机制.如图9所示，DNP3协议虽然存在CRC校验和字段防止报文被篡改，但这种机制仅能防护协议数据传输过程中数据丢失或者电磁干扰等风险.对于熟知DNP3协议格式细节的攻击者，篡改报文后，重新计算出正确CRC值进行替换，仍然可实施报文篡改攻击.文献[25]也指出DNP3协议面临报文篡改攻击威胁.
Fig. 9 DNP3 message data link layer frame format
图9 DNP3报文数据链路层帧格式
3) 报文重放攻击
重放攻击破坏的是通信双方上下文的一致性，通过记录网络通信报文，然后根据攻击需要进行重放.使用重放攻击的一个典型场景是对认证过程进行重放绕过.如Beresford[29]在Black Hat上指出，早期西门子公司的S7-1200，S7-300和S7-400的PLC在会话管理上存在严重的漏洞，在同型号设备上重放会话数据即可建立会话.类似地，重放特定报文还可以实现读内存、写内存等功能，甚至可对硬件配置进行修改，比如修改IP地址、管理密码和控制逻辑等.Hong等人[47]发现S7commplus协议存在重放攻击缺陷.利用该缺陷，攻击者可以轻易通过重放其他报文实现对PLC的控制启停.对于认证缺失的协议，如果报文没有校验字段或没有序号、会话等动态变化的会话管理字段，重放控制功能就能实现攻击.如Drias等人[48]认为Modbus-TCP协议没有CRC校验，简单地重放捕获的客户端与服务端的通信数据包就可实现重放攻击.
2.2.3 破坏机密性
破坏机密性的关键在于非法获取系统的敏感信息.由于获取敏感信息不会直接影响工控系统的运行，工控系统机密性安全要求低于可用性和完整性.尽管如此，获取系统的敏感信息仍然是完成有效攻击的重要前提.攻击者通过分析通信报文获得系统的版本和型号等信息后，可用预先准备的对应漏洞进行攻击利用[21].攻击者获取与认证相关的敏感报文，如嗅探MicroLogic 1100，MicroLogic 1400，CLICK等PLC的通信报文可获得明文密码[49]，后续可利用重放攻击等方式绕过认证，获得系统的操作权限.针对机密性，主要有2种攻击方式：
1)主动请求获取系统的敏感数据
攻击者可以远程主动发起请求获取工控设备/系统的敏感信息.Mirian等人[21]通过主动请求探测暴露于互联网的工控服务能发现大量工控产品的厂商、型号等信息，并总结了典型工控协议提供的服务端口，如表4所示.除了利用工控协议，攻击者还可以利用传统TCP/IP等协议，将这些协议在不同系统交互时的差异作为指纹，获得系统状态等信息.如果攻击者通过主动请求能够探测到系统版本等信息，比如获知设备的操作系统VxWorks版本低于6.9，则攻击者可以利用漏洞CVE-2010-2967，通过密码碰撞的方法绕过认证保护机制，获得系统控制权限.
Table 4 Typical Industrial Control Protocol Service Port Number
表4 典型工控协议服务端口号
协议行业端口号ModbusICSTCP∕502BACnetBuilding ManagementUDP∕47808DNP3Power GridTCP∕20000EtherNet∕IPICSTCP∕44818,UDP∕2222HART-IPICSTCP∕5094IEC 61850Power GridTCP∕102ANSI C12.22Meter ReadingTCP∕1153,UDP∕1153ICCPPower GridTCP∕102Siemens S7ICSTCP∕102Tridium FoxBuilding ManagementTCP∕1911
2) 被动监听通信内容
攻击者如果与目标系统共享同一个通信信道，可以通过侦听的方式，捕获通信的数据包；或基于通信劫持攻击(如中间人攻击)的方式，攻击者捕获并分析通信的内容.图10是捕获的MMS协议报文的二进制内容[32].
Fig. 10 Captured MMS protocol message[32]
图10 捕获的MMS协议报文[32]
根据协议手册可知，MMS协议采用ASN.1/BER编码规范，则可按规范得到如下解析结果：这是一个Confirmed-Request报文，在做read请求操作，该报文的invokeId值为123，这个读请求包含了3个请求条目，每一个条目是具体的对象标识符，此处能获取当前信息系统虚拟资产的标识信息.
2.3 攻击影响
NIST总结了潜在的攻击事件对控制系统可能造成的影响[1].
1) 控制失灵.控制系统的运行因延迟或信息流阻塞而中断，从而使系统操作员无法使用网络，导致信息传输受阻或常驻服务如DNS发生拒绝服务.
2) 控制设备被重新编程.对PLC，RTU，DCS或SCADA等控制器中的程序指令进行未授权的更改，或更改警报阈值，甚至向控制设备发起未经授权的命令，可能导致设备损坏(如超出设备可承受阈值)、控制过程过早地关闭，造成环境事故，甚至使控制设备不可用.
3) 欺骗系统状态信息.发送虚假信息给控制系统操作员(例如在人机界面显示构造的数据)，以掩饰未经授权的更改或操作员不当的操作.
4) 控制逻辑操控.对控制程序的配置进行修改，将产生不可预知的结果.
5) 安全系统修改.操控安全系统，以使得它们在需要时不运行，或者执行不正确的控制操作，从而损坏工业控制系统.
6) 植入恶意软件.向控制系统引入恶意软件，如病毒、蠕虫、特洛伊木马等.
Fig. 11 Comparison of MMS protocol before and after security improvement
图11 MMS协议安全改进前后对比
对控制系统的攻击还会造成深远的后续影响.最直接的影响包括人身伤害、财产损失、对环境的潜在破坏等.直接影响会进一步衍生经济影响和社会影响，可能造成相关组织和机构巨大的经济损失.对关键基础设施如电力、交通的破坏所产生的经济影响将远远超出对单个系统的直接物理损坏的影响，甚至使公众对国家或组织失去信心.
3 工控协议安全方案研究
工业控制系统在关键基础设施中具有定制化和专用性的特征.因此，IEC 62443标准给出了针对工业控制系统的信息安全的定义：“①保护系统所采取的措施；②由建立和维护保护系统的措施所得到的系统状态；③能够免于对系统资源的非授权访问或意外的变更、破坏或者损失；④基于计算机系统的能力，能够保证非授权人员和系统既无法修改软件及其数据，也无法访问系统功能，保证授权人员和系统不被阻止；⑤防止对工业控制系统的非法或有害入侵，或者干扰其正确和计划的操作”.
从协议的角度看，维护工控系统的安全状态需采取必要的措施，主要包括：协议安全设计改进、协议安全实现测试、协议安全应用指南.
3.1 协议设计安全加固
针对工控协议在设计上普遍缺乏认证加密等安全机制的问题，学术界和工业界一直在努力改善这一现状.主要有3种思路：
1) 在协议栈增加安全层
国际标准组织推出IEC 62351标准[14]用来改进IEC 61850系列协议设计缺陷，并规定使用传输层安全协议(Transport Layer Security, TLS)为应用间通信提供端对端的传输安全.TLS协议使用加密技术提供数据的机密性和端之间的认证.从技术上讲，TLS是一个运行在TCP协议之上的协议套件.因此，IEC 62351规定TLS应用在基于TCP/IP的电力工控协议，包括TASE.2，MMS，IEC 104等.其中，MMS协议改进前后的协议栈对比如图11所示.
IEC 62351应用TLS进行安全改进时，还结合了工控场景的通信特点.如考虑到TLS多用于传统互联网协议的安全交互，这些协议连接的持续时间很短，使得加密算法和密钥能在连接建立时重新协商，使用默认的TLS配置即可保障加密安全.而工控场景下TCP/IP连接趋向于更长的持续时间，并且经常是“永久”的，所以在安全防护方面需特殊考虑.为了提供“永久”连接的机密性，IEC 62351-3对应用TLS增加规定加密密钥再协商的安全机制.
类似地，针对MQTT协议设计上的认证、授权和加密等方面的安全缺陷，Lesjak等人[50]提出了结合硬件安全的TLS增强改进方案.他们利用TLS握手过程实现订阅方和发布方的相互认证.为保护用于认证的私有密钥，他们使用一个专用的硬件实现数字签名操作.文献[50]的作者基于OpenSSL库在TCP协议层之上实现了TLS,并用Security Controller模块作为签名运算专用硬件.
2) 在协议应用数据单元增加安全字段
针对Modbus协议的设计缺陷，文献[51-52]等通过在协议应用数据单元增加新的安全字段,实现完整性、防重放、身份认证等安全机制.Fovino等人[51]通过SHA2哈希函数计算获得数据包的安全摘要，再由RSA算法生成数字签名字段，保障了Modbus协议完整性，如图12所示.同时，非对称加密RSA算法使用私钥对安全摘要签名，接收方可以通过公钥快速验证Modbus报文的身份，使改进的Modbus协议具备了身份认证的安全功能.时间戳(timestamp, TS)字段使得接收者能够检查接收报文的“新鲜度”，可抵抗重放攻击.
Fig. 12 Secure Modbus application data unit
图12 安全版本的Modbus协议应用数据单元
考虑到工控系统运行的部分设备年代久远，升级和替换的成本非常高，改进的Secure Modbus协议难以直接部署在传统的SCADA环境.针对这一问题，Fovino等人[51]提出Modbus安全网关的解决方案.如图13所示，Modbus安全网关(Modbus secure gateway)是一个专用的多宿主网关，承载连接到过程层网络的TCP/IP接口和一组连接到传统从站点对点的TCP或串行链路.它仅接受经过身份验证的主服务器Secure Modbus TCP流量，并提取Modbus数据包发送给从设备；当收到来自从设备点对点链路数据包时，安全网关选择对应的私钥对数据包进行签名，生成Secure Modbus TCP流量再发送.
Fig. 13 Communication architecture based on security gateway
图13 基于安全网关的通信架构
增加安全字段的思路可以应用在实时性要求高的协议上，如针对电力工控行业的GOOSE和SMV协议的改进.改进方案需考虑协议报文的实时性要求：必须在4 ms内被传输.IEC 62351指出在此要求下，加密和密钥再协商会破坏高度实时的信息流，基于数字签名的认证是唯一可用的安全措施，并对此提出的改进方案，如图14所示:
Fig.14 Security improved GOOSE/SMV message structure
图14 安全改进版的GOOSE/SMV报文结构
该改进方案使用一个保留字段作为长度，这样扩展字段就可以增加到GOOSE/SMV报文上，扩展的字段包含数字签名认证信息.在实际系统中，非安全客户端可简单地忽略这个扩展字段.
3) 改进通信会话的过程
协议基于会话流程实现安全机制，根据文献[29]，Beresford于2011年发现初始版本的S7私有协议的设计存在多种漏洞，如缺乏对Session有效性的检查，通过分析报文和简单重放即可实现对S7-1200,S7-300,S7-400等PLC的攻击.西门子公司改进S7私有协议为S7Commplus协议，基于Biham等人[16]的逆向分析，发现改进的S7Commplus协议的会话过程使用了更严格的认证机制，该过程涉及了基于非对称加密的密钥交换的过程.改进的S7Commplus协议的安全性得到了极大的提高，使得攻击的难度增大.
3.2 协议实现脆弱性测试
编程人员在实现工控协议通信程序时，可能因疏忽大意导致程序代码留有漏洞.为了自动发现这些协议实现漏洞，Fuzzing(模糊测试)技术是当前的研究热点.根据现有文献总结，工控协议模糊测试的方法主要有2种：灰盒测试和黑盒测试.
3.2.1 灰盒测试
灰盒测试是指在进行模糊测试时能获得程序执行的一些内部信息，如获取代码覆盖率(code coverage)信息[53].工控协议的灰盒测试一般需要源码或者要求目标程序能被插桩，以实时获得程序执行的信息作为反馈，指导并提高模糊测试的效率.
区别于传统的测试对象(如图片、视频和文件等处理程序)，文献[35]指出工控协议一般会携带一个名为“功能码”的特定字段，功能码字段的取值指示接收端设备应该执行什么操作.所以，生成测试用例时确保该字段的正确性至关重要.基于该发现，文献[35]的作者先静态分析工控协议源码提取协议功能码字段信息，确定功能码字段在报文中的偏移和取值范围，然后基于AFL对协议源码程序进行插桩，最后将模糊测试时约束生成的畸形协议数据包的功能码字段在正确的范围内，以提高模糊测试的效率.
针对工控协议模糊测试，文献[54]认为传统的基于模板生成测试用例的方法本质上是随机的，测试效率有待提高.同时，工控协议不同(功能码)类型的数据报文会触发不同的程序代码执行轨迹，但这些报文非常相似，难以区分.为此，文献[54]的作者提出Peach*，为传统协议模糊测试方法配备覆盖率引导机制.由于需要基于LLVM框架对源码程序进行插桩，Peach*仅适用于有源码的程序.
3.2.2 黑盒测试
灰盒测试依赖协议程序源码，可应用于一些开源的工控协议.考虑到相关厂商的知识产权和商业利益，仍有大量的工控协议未开源其代码.这些工控协议运行在定制、专用的嵌入式设备中.相关程序难以被提取和插桩处理.所以，进行模糊测试时难以获取被测程序内部的执行信息，被测对象被视为一个黑盒.为生成高质量测试用例，工控协议黑盒测试的关键在于使用非插装监控手段获取协议知识，例如协议报文格式、协议状态等信息.
1) 通过人工分析相关文档获得协议知识
对于有公开文档的工控协议，测试前需人工整理有关协议的信息，手动定义变异模板，自动化生成测试用例.Devarajan[55]在Black Hat大会上提出基于Sulley框架[56]的黑盒模糊测试方案，对SCADA系统的Modbus,DNP3,ICCP等公开的协议进行了模糊测试.Devarajan基于Sulley框架手动编写了这些公开的工控协议测试模板.模板包括管理报文格式变异的数据模型和管理协议序列交互过程的状态模型.类似的基于报文格式手动编写测试模板的知名框架还包括Boofuzz[57]，Peach[58]，Scapy[59]等.如Tacliad等人[60]提出基于Scapy设计和实现了EtherNet/IP系列协议黑盒模糊测试工具.早期也有一些协议模糊测试工作没有用到测试框架，而是自定义变异原语，如Snooze[61]，但它们原理上是相同的.
2) 通过机器学习的方法获得协议知识
Hu等人[62]提出基于机器学习的方法生成高效测试用例.Hu等人指出，对抗神经网络(generative adversarial network, GAN)擅长从已有数据中学习并伪造符合特定分布特征的数据，以达到欺骗系统的目的.该过程与学习协议通信报文的语法格式伪造生成畸形测试用例一致.因此，Hu等人设计了GANFuzz，并使用GANFuzz学习Modbus-TCP协议流量，伪造符合协议语法格式的测试数据.最终Hu等人通过评估“测试用例被拒绝”和“能否挖掘真实漏洞”2个指标证明了该方法的有效性.类似地，Zhao等人[63]提出SeqFuzzer，该方案认为长短期记忆网络LSTM擅长学习通信报文序列之间的关系，这种报文序列关系能很好地代表协议状态转移知识.除此之外，LSTM神经网络还能学习协议报文的数据帧格式.然后Zhao等人用seq2seq作为解码器生成高效测试用例，最后测试EtherCat协议并发现漏洞.
3) 通过协议逆向工程分析等获得协议知识
Niedermaier等人[64]通过模式识别的方式逆向分析了Phoenix公司PLC的私有通信协议的报文格式，同时基于报文相似性对比的分析方法逆向私有协议握手会话的过程.基于逆向分析的结果，Niedermaier等人实现了一个模糊测试工具原型系统，对Phoenix公司PLC测试并发现了多个严重漏洞.如果仅考虑对私有协议逆向工程获取协议知识，还有很多其他工作，主要分为基于网络报文序列对齐的分析如Netzob[65]，Discoverer[66]，ScriptGen[67]，PRISMA[68]，NEMESYS[69]等和基于程序执行的分析如Dispatcher[70]，Replayer[71]等.
除了获取协议知识，工控协议程序测试还面临状态监控困难的挑战.文献[72]指出工控系统与环境的交互是程序执行的一部分，监控时考虑这种特征的研究工作还很少.同时，由于工控嵌入式设备资源受限，大多没有内存管理单元，即使触发了漏洞也不会立即出现易观察的崩溃现象，已有的基于网络连接是否存活的监控方式会有很多漏报[73].
3.3 协议应用指南
对协议通信网络进行不恰当的部署应用和管理，也是工控系统面临攻击的主要威胁之一.如2015年乌克兰发生的大规模停电的网络攻击事件[41]，事后分析发现电力控制网和互联网未做好分区隔离、内部员工安全意识薄弱是这次攻击事件发生的关键.攻击者通过互联网发送钓鱼邮件接入电力控制网后实施针对电力控制网的攻击.针对协议的安全应用，当前主要通过标准指南的方式进行规范化管理.
3.3.1 标准指南的制定
国内外的相关组织和机构针对工业控制系统信息安全的标准化工作，形成了一系列的规范性文件，彭勇等人[74]对此进行了全面的总结.对这些规范性文件进行对比分析，发现它们各有特色：
从适用行业来看，可分为通用行业和专用行业.IEC 62443是一个通用标准，适用于所有工控相关领域.而IEC 62351则是一个专用标准，仅适用于电力行业.
从方案对策来看，可分为侧重技术对策和组织管理对策.Sommestad等人[75]对相关指南进行了综述性比较，发现SCADA相关的标准指南更侧重技术对策，如部署防火墙、入侵检测系统等.而ISO/IEC 17799更侧重组织对策，如安全组织、业务持续性计划、政策和标准以及第三方合作等.
从技术偏好来看，可分为系统性防护和关键点防护.王建等人[76]对2个备受关注的标准IEC 62443和等级保护2.0《信息安全技术信息系统安全等级保护基本要求》(GB/T 22239—2019)进行了对比分析.GB/T 22239—2019侧重边界防护方面的技术指标，围绕网络架构、边界防护、入侵防范等有较多的安全方案.而IEC 62443-3-3标准则强调系统性自我保护能力，系统一旦遭受攻击，控制系统不仅会阻断网络边界的通信，而且会切断一切与其通信的路径和传输数据.
3.3.2 推广和落地
标准指南发布后在落地时面临一个关键问题：相关行业和单位对标准指南的落地重视不够，主动性、专业性不强，落地能力不足.为了推动标准指南的实施和落地，标准发布后需要配套的政策法规进行要求和引导.文献[77]指出，国际自动化协会下属安全合规性委员会推出了ISASecure EDSA认证计划，开展IEC 62443标准符合性认证测试工作.类似地，美国国土安全部(DHS)推出了CSET安全评估工具，支持多个安全标准的评估，如NIST SP800-53和NIST SP800-82等.
我国更是在法律法规上提出了强制要求，其中2016年发布的《中华人民共和国网络安全法》第21条明确提出国家实行网络安全等级保护制度.我国网络安全等级保护制度包括定级、备案、建设整改、等级测评和监督检查5个阶段，构建了完整的等级保护流程，何占博等人[78]总结了各阶段对应的法律法规和政策规范，如表5所示:
Table 5 Regulations and Policies in Various Stages of the Cybersecurity Classified Protection
表5 网络安全等级保护各阶段法律法规和政策规范
法规和政策规范阶段GA∕T 1389—2017《信息安全技术等级保护定级指南》《关于开展全国重要信息系统安全等级保护定级工作的通知》定级《信息安全等级保护备案实施细则》备案《关于开展信息安全等级保护安全建设整改工作的指导意见》建设整改《信息安全技术信息系统安全等级保护测评过程指南》《信息安全技术信息系统等级保护基本要求》等级测评《公安机关信息安全等级保护检查工作规范(试行)》监督检查
3.3.3 更新维护
随着新技术的发展和应用，已发布的标准和指南需与时俱进地更新以满足新兴的安全防护需求.事实上，那些影响力大、关注度高的标准文件一直在更新维护.如NIST SP800-82[1]于2011年正式发布，2013年发布第一次修订版，2015年发布第二次修订版.国内由国家标准化管理委员会和国家质量监督检验检疫总局共同发布的等级保护2.0《信息安全技术信息系统安全等级保护基本要求》(GB/T 22239—2019)也是在等级保护1.0的GB/T 22239—2008进行优化修订完成的，它扩展了对云计算、移动互联、物联网、工业控制系统及大数据等新技术和新应用领域的安全要求.
4 总结和展望
本文从通信协议的角度分析了工业控制系统面临的安全威胁和对应的策略.首先从工控网络架构、工控协议作用、分类以及和传统协议的比较等方面进行详细阐述，然后从协议设计、实现和应用的角度深入分析了协议攻击威胁和协议防护方案.结合工控协议的特点，我们有3个方面的展望：
1) 设计上，工控协议普遍存在安全问题.除了早期安全不受重视，客观上还因工控设备的计算资源有限，难以部署重量级的安全机制，如安全算法、防火墙、监控程序等.同时，工业控制过程对系统的可用性要求更高，例如需满足实时响应、保持长期在线等，而一般的安全改进方案除了带来性能上的损耗，还可能带来新的安全问题，所以难以直接应用传统的安全方案.而已有研究大多聚焦于减少资源开销，鲜有验证其方案的可靠性.因此，研究人员需要提出一种可靠的轻量级安全通信机制，这种安全机制需要满足2个要求：①受限的资源.该安全机制需要严格控制计算资源的使用，如尽可能降低对设备电量和内存的消耗，同时，还要尽可能减小对性能的影响.②可验证的安全.该安全机制不会带来新的安全问题，在某些重要属性上是安全可验证的.
2) 实现上，工控协议程序涉及专用、异构多样的嵌入式设备.不同于通用的测试程序对象，很多工控协议程序难以被提取、分析和监控运行.因此，基于路径覆盖反馈的高效模糊测试方案难以直接应用.针对工控设备中的协议程序，已有研究聚焦于分析获得协议知识，然后进行黑盒测试，其有效性受限于无法获得运行时的反馈.因此，研究人员需针对工控设备提出一种有效的程序运行监控的反馈机制.可从2个角度进行考虑：①该监控机制不对程序直接进行分析和插桩，而从其他角度间接推断程序运行状态，例如从返回报文、运行能耗开销、设备I/O监控等角度；②解决嵌入式工控协议程序提取困难的挑战，然后迁移该程序到其他易控环境进行模拟仿真执行，从而方便测试时监控和运行时反馈.
3) 应用上，保障工控协议的通信安全需结合已发布的标准和指南，然后部署配套的安全方案，例如部署入侵检测系统、防火墙等.部署具体安全方案时，研究人员需结合具体的控制场景提出一种更加有效的风险评估模型，以准确定位安全威胁和安全需求，从而选择并配置合适的安全方案.同时，考虑到工控系统的高可用性需求(例如有的方案需采集实时数据，而该过程可能会影响系统的可用性)，研究人员还需要提出一种更加有效的评估方法来验证具体方案的可靠性，以防引入新的隐患.
作者贡献声明：方栋梁负责论文主要内容的调研、整理和撰写；刘圃卓、秦川、宋站威辅助进行调研、讨论与文章修改；孙玉砚、石志强、孙利民对文章结构与内容进行讨论并提出了指导意见.
[1]Stouffer K, Falco J, Scarfone K. Guide to industrial control systems (ICS) security[J]. NIST Special Publication, 2015, 800(82): 10-115
[2]Zhang Yuqing, Zhou Wei, Peng Anni. Survey of Internet of things security[J]. Journal of Computer Research and Development, 2017, 54(10): 2130-2143 (in Chinese)(张玉清, 周威, 彭安妮. 物联网安全综述[J]. 计算机研究与发展, 2017, 54(10): 2130-2143)
[3]Hemsley K E, Fisher E. History of industrial control system cyber incidents[R/OL]. Idaho Falls of United States: Idaho National Lab, 2018 [ 2021-12-25]. https://www.osti.gov/servlets/purl/1505628/
[4]Falliere N, Murchu L O, Chien E. W32. Stuxnet dossier[J]. Symantec Security Response, 2011, 5(6): 1-29
[5]Cherepanov A. WIN32/INDUSTROYER: A new threat for industrial control systems[R/OL]. San Diego, CA: ESET, 2017 [ 2021-12-25]. https://www.welivesecurity.com/wp-content/uploads/2017/06/Win32_Industroyer.pdf
[6]Di Pinto A, Dragoni Y, Carcano A. TRITON: The first ICS cyber attack on safety instrument systems[C] //Proc of Black Hat. San Francisco, CA: Black Hat, 2018: 1-26
[7]Lai Yingxu, Liu Zenghui, Cai Xiaotian, et al. Research on intrusion detection of industrial control system[J]. Journal on Communications, 2017, 38(2): 143-156 (in Chinese)(赖英旭, 刘增辉, 蔡晓田, 等. 工业控制系统入侵检测研究综述[J].通信学报, 2017, 38(2): 143-156)
[8]Hu Yi, Yu Dong, Liu Minglie. Present research and developing trends on industrial control network[J]. Journal of Computer Science, 2010, 37(1): 23-27 (in Chinese)(胡毅, 于东, 刘明烈. 工业控制网络的研究现状及发展趋势[J]. 计算机科学, 2010, 37(1): 23-27)
[9]Moyne J R, Tilbury D M. The emergence of industrial control networks for manufacturing control, diagnostics, and safety data[J]. Proceedings of the IEEE, 2007, 95(1): 29-47
[10]Galloway B, Hancke G P. Introduction to industrial control networks[J]. IEEE Communications Surveys & Tutorials, 2012, 15(2): 860-880
[11]Ackerman P. Industrial Cybersecurity: Efficiently Secure Critical Infrastructure Systems[M]. Olton, Birmingham, UK: Packt Publishing Ltd, 2017
[12]Burns A, McDermid J, Dobson J. On the meaning of safety and security[J]. The Computer Journal, 1992, 35(1): 3-15
[13]Line M B, Nordland O, Røstad L, et al. Safety vs security?[C/OL] //Proc of the 8th Int Conf on Probabilistic Safety Assessment and Management. New York: ASME Press, 2006: 1-9
[14]International Electrotechnical Commission. Power systems management and associated information exchange-data and communications security (IEC 62351-1)[S]. Canton de Genève, Switzerland: IEC, 2007
[15]Shirey R. Internet security glossary, IETF RFC 4949[S/OL]. Wilmington, DE: IETF, 2007 [2021-12-25]. https://www.hjp.at/doc/rfc/rfc4949.html
[16]Biham E, Bitan S, Carmel A, et al. Rogue7: Rogue engineering-station attacks on S7 Simatic PLCs[C] //Proc of Black Hat. San Francisco, CA: Black Hat, 2019: 1-21
[17]Grandgenett R, Mahoney W, Gandhi R. Authentication bypass and remote escalated I/O command attacks[C] //Proc of the 10th Annual Cyber and Information Security Research Conf. New York: ACM, 2015: 1-7
[18]Nardone R, Rodríguez R J, Marrone S. Formal security assessment of Modbus protocol[C] //Proc of 2016 11th Int Conf for Internet Technology and Secured Transactions (ICITST). Piscataway, NJ: IEEE, 2016: 142-147
[19]Gasser O, Scheitle Q, Denis C, et al. Security implications of publicly reachable building automation systems[C] //Proc of 2017 IEEE Security and Privacy Workshops (SPW). Piscataway, NJ: IEEE, 2017: 199-204
[20]Kaur J, Tonejc J, Wendzel S, et al. Securing BACnet’s pitfalls[C] //Proc of IFIP Int Information Security and Privacy Conf. Cham, Switzerland: Springer, 2015: 616-629
[21]Mirian A, Ma Z, Adrian D, et al. An Internet-wide view of ICS devices[C] //Proc of 2016 14th Annual Conf on Privacy, Security and Trust (PST). Piscataway, NJ: IEEE, 2016: 96-103
[22]Puys M, Potet M L, Lafourcade P. Formal analysis of security properties on the OPC-UA SCADA protocol[C] //Proc of Int Conf on Computer Safety, Reliability, and Security. Cham, Switzerland: Springer, 2016: 67-75
[23]Rrushi J L, Farhangi H, Nikolic R, et al. By-design vulnerabilities in the ANSI C12.22 protocol specification[C] //Proc of the 30th Annual ACM Symp on Applied Computing. New York: ACM, 2015: 2231-2236
[24]Pidikiti D S, Kalluri R, Kumar R K S, et al. SCADA communication protocols: Vulnerabilities, attacks and possible mitigations[J]. CSI transactions on ICT, 2013, 1(2): 135-141
[25]East S, Butts J, Papa M, et al. Ataxonomy of attacks on the DNP3 Protocol[C] //Proc of Int Conf on Critical Infrastructure Protection. Berlin: Springer, 2009: 67-81
[26]Dán G, Sandberg H, Ekstedt M, et al. Challenges in power system information security[J]. IEEE Security & Privacy Magazine, 2012, 10(4): 62-70
[27]Maynard P, McLaughlin K, Haberler B. Towards understanding Man-In-The-Middle attacks on IEC 60870-5-104 SCADA Networks[C] //Proc of the 2nd Int Symp for ICS & SCADA Cyber Security Research (ICS-CSR 2014). Swindon, UK: BCS Learning & Development Ltd, 2014: 30-42
[28]Kush N S, Ahmed E, Branagan M, et al. Poisoned GOOSE: Exploiting the GOOSE protocol[C] //Proc of the 12th Australasian Information Security Conf (AISC 2014). Sydney, Australia: Australian Computer Society Inc, 2014: 17-22
[29]Beresford D. Exploiting siemens simatic S7 PLCs[C] //Proc of Black Hat. San Francisco, CA: Black Hat, 2011: 723-733
[30]Rashid M T A, Yussof S, Yusoff Y. Trust system architecture for securing GOOSE communication in IEC 61850 substation network[J]. International Journal of Security and Its Applications, 2016, 10(4): 289-302
[31]Hu Guo, Mei Dedong. Research and application on network security of SMV in smart substation[J]. Chinese Journal of Electrical Engineering, 2017, 37(8): 2215-2221 (in Chinese)(胡国, 梅德冬. 智能变电站采样值报文安全分析与实现[J]. 中国电机工程学报, 2017, 37(8): 2215-2221)
[32]Sørensen J T, Jaatun M G. An analysis of the manufacturing messaging specification protocol[C] //Proc of Int Conf on Ubiquitous Intelligence and Computing. Berlin: Springer, 2008: 602-615
[33]Industrial Automation Systems. Manufacturing Message Specification. Part 1, ISO 9506-1:2003(E)[S]. Canton de Genève, Switzerland: ISO, 2003
[34]Kalle S, Ameen N, Yoo H, et al. CLIK on PLCs! Attacking control logic with decompilation and virtual PLC[C/OL] //Proc of Binary Analysis Research (BAR) Workshop, Network and Distributed System Security Symp (NDSS). Piscataway, NJ: IEEE, 2019[2021-12-25]. https://ruoyuwang.me/bar2019/pdfs/bar2019-final74.pdf
[35]Rittle J. Schneider Electric Modicon M580 UMAS Read System Coils and Registers Denial of Service Vulnerability[EB/OL]. [2021-12-25]. https://talosintelligence.com/vulnerability_reports/TALOS-2019-0806
[36]Luo Zhengxiong, Zuo Feilong, Jiang Yu, et al. Polar: Function code aware fuzz testing of ICS protocol[J]. ACM Transactions on Embedded Computing Systems, 2019, 18(5s): 1-22
[37]Dliangfun. Multiple Denial-of-Service Vulnerabilities in Multiple FA Engineering Software Products[EB/OL]. [2021-12-25]. https://www.mitsubishielectric.com/en/psirt/vulnerability/pdf/2020-021_en.pdf
[38]Chen Yuqi, Poskitt C M, Sun Jun, et al. Learning-guided network fuzzing for testing cyber-physical system defences[C] //Proc of 2019 34th IEEE/ACM Int Conf on Automated Software Engineering (ASE). Piscataway, NJ: IEEE, 2019: 962-973
[39]Niedermaier M, Malchow J O, Fischer F, et al. You snooze, you lose: Measuring PLC cycle times under attacks[C/OL] //Proc of the 12th USENIX Workshop on Offensive Technologies (WOOT’18). Berkeley, CA: USENIX Association, 2018[2021-12-25]. https://www.usenix.org/system/files/conference/woot18/woot18-paper-niedermaier.pdf
[40]Xu Ting. Analysis and prevention of 220kV substation stationcommunication interruption accident[J]. Electric Safety Technology, 2012, 14(2): 31-33 (in Chinese)(许婷. 220kV变电站全站通讯中断事故的分析及预防[J]. 电力安全技术, 2012, 14(2): 31-33)
[41]Case D U. Analysis of the cyber attack on the Ukrainian power grid[J]. Electricity Information Sharing and Analysis Center, 2016, 388: 1-29
[42]Ginter A. The top 20 cyber attacks against industrial control systems[J/OL]. White Paper, Waterfall Security Solutions, 2017[2021-12-15]. https://www.fireeye.com/content/dam/fireeye-www/products/pdfs/wp-top-20-cyberattacks.pdf
[43]Nelso T, Chaffin M. Common cybersecurity vulnerabilities in industrial control systems[J/OL]. Control Systems Security Program, 2011 [2021-12-25]. https://www.cisa.gov/uscert/sites/default/files/recommended_practices/DHS_Common_Cybersecurity_Vulnerabilities_ICS_2010.pdf
[44]Kaspersky. Hacking electricity, water, and food[EB/OL]. [2021-12-25]. https://www.kaspersky.com/blog/industrial-vulnerabilities/12596/
[45]Homan J, McBride S, Caldwell R. IronGate ICS malware: Nothing to see here... Masking malicious activity on SCADA systems[EB/OL].[2021-12-25]. https://www.fireeye.com/blog/threat-research/2016/06/irongate_ics_malware
[46]Hagen J T, Mullins B E. TCP veto: A novel network attack and its application to SCADA protocols[C] //Proc of 2013 IEEE PES Innovative Smart Grid Technologies Conf (ISGT). Piscataway, NJ: IEEE, 2013: 1-6
[47]Hong K S, Kim H B, Kim D H, et al. Detection of replay attack traffic in ICS network[C] //Proc of Int Conf on Applied Computing and Information Technology. Berlin: Springer, 2018: 124-136
[48]Drias Z, Serhrouchni A, Vogel O. Taxonomy of attacks on industrial control protocols[C] //Proc of 2015 Int Conf on Protocol Engineering (ICPE) and Int Conf on New Technologies of Distributed Systems (NTDS). Piscataway, NJ: IEEE, 2015: 1-6
[49]Ayub A, Yoo H, Ahmed I. Empirical study of PLC Authentication Protocols inindustrial control systems[C/OL] //Proc of the 15th IEEE Workshop on Offensive Technologies (WOOT). Piscataway, NJ: IEEE, 2021 [2021-12-25]. http://www.people.vcu.edu/～iahmed3/publications/2021-woot.pdf
[50]Lesjak C, Hein D, Hofmann M, et al. Securing smart maintenance services: Hardware-security and TLS for MQTT[C] //Proc of 2015 IEEE 13th Int Conf on Industrial Informatics (INDIN). Piscataway, NJ: IEEE, 2015: 1243-1250
[51]Fovino I N, Carcano A, Masera M, et al. Design and implementation of a secure modbus protocol[C] //Proc of Int Conf on Critical Infrastructure Protection. Berlin: Springer, 2009: 83-96
[52]Shahzad A, Lee M, Lee Y K, et al. Real time MODBUS transmissions and cryptography security designs and enhancements of protocol sensitive information[J]. Symmetry, 2015, 7(3): 1176-1210
[53]Manès V J M, Han H S, Han C, et al. The art, science, and engineering of fuzzing: A survey[J/OL]. IEEE Transactions on Software Engineering. 2019[2021-12-25]. https://edmcman.github.io/papers/tse19.pdf
[54]Luo Zhengxiong, Zuo Feilong, Shen Yuheng, et al. ICS protocol fuzzing: Coverage guided packet crack and generation[C] //Proc of 2020 57th ACM/IEEE Design Automation Conf (DAC). Piscataway, NJ: IEEE, 2020: 1-6
[55]Devarajan G. Unraveling SCADA protocols: Using Sulley fuzzer[EB/OL]. [2021-12-25]. https://media.defcon.org/DEFCON15/presentations/DEFCON15-devarajan.pdf
[56]Amini P. Introducing Sulley fuzzing framework[EB/OL]. [2021-12-25]. https://fuzzinginfo.files.wordpress.com/2012/05/introducing_sulley.pdf
[57]Pereyda J. Boofuzz: Network protocol fuzzing for humans[EB/OL]. [2021-12-25]. https://github.com/jtpereyda/boofuzz
[58]Eddington M. Peach fuzzing platform[J/OL]. Peach Fuzzer, 2011, 34.[2021-12-25]. https://wiki.mozilla.org/Security/Fuzzing/Peach
[59]Philippe Biondi and the Scapy community. Scapy Project[EB/OL]. [2021-12-25]. https://scapy.net/
[60]Tacliad F, Nguyen T D, Gondree M. DoS exploitation of allen-bradley’s legacy protocol through fuzz testing[C] //Proc of the 3rd Annual Industrial Control System Security Workshop. New York: ACM, 2017: 24-31
[61]Banks G, Cova M, Felmetsger V, et al. SNOOZE: Toward a Stateful NetwOrk prOtocol fuzZEr[C] //Proc of Int Conf on Information Security. Berlin: Springer, 2006: 343-358
[62]Hu Zhicheng, Shi Jianqi, Huang Yanhong, et al. GANFuzz: A GAN-based industrial network protocol fuzzing framework[C] //Proc of the 15th ACM Int Conf on Computing Frontiers. New York: ACM, 2018: 138-145
[63]Zhao Hui, Li Zhihui, Wei Hansheng, et al. SeqFuzzer: An industrial protocol fuzzing framework from a deep learning perspective[C] //Proc of 2019 12th IEEE Conf on Software Testing, Validation and Verification (ICST). Piscataway, NJ: IEEE, 2019: 59-67
[64]Niedermaier M, Fischer F, von Bodisco A. PropFuzz—An IT-security fuzzing framework for proprietary ICS protocols[C] //Proc of 2017 Int Conf on Applied Electronics (AE). Piscataway, NJ: IEEE, 2017: 1-4
[65]Bossert G, Guihéry F, Hiet G. Towards automated protocol reverse engineering using semantic information[C] //Proc of the 9th ACM Symp on Information, Computer and Communications Security. New York: ACM, 2014: 51-62
[66]Cui Weidong, Kannan J, Wang H J. Discoverer: Automatic protocol reverse engineering from network traces[C] //Proc of USENIX Security Symp. Berkeley, CA: USENIX Association, 2007: 1-14
[67]Leita C, Mermoud K, Dacier M. ScriptGen: An automated script generation tool for honeyd[C] //Proc of the 21st Annual Computer Security Applications Conf. New York: IEEE Computer Society, 2005: 203-214
[68]Krueger T, Gascon H, Krämer N, et al. Learning stateful models for network honeypots[C] //Proc of the 5th ACM Workshop on Security and Artificial Intelligence. New York: ACM, 2012: 37-48
[69]Kleber S, Kopp H, Kargl F.NEMESYS: Network message syntax reverse engineering by analysis of the intrinsic structure of individual messages[C] //Proc of 12th USENIX Workshop on Offensive Technologies (WOOT’18). Berkeley, CA: USENIX Association, 2018
[70]Caballero J, Song Dawn. Automatic protocol reverse-engineering: Message format extraction and field semantics inference[J]. Computer Networks, 2013, 57(2): 451-474
[71]Newsome J, Brumley D, Franklin J, et al. Replayer: Automatic protocol replay by binary analysis[C] //Proc of the 13th ACM Conf on Computer and communications security. New York: ACM, 2006: 311-321
[72]Boehme M, Cadar C, Roychoudhury A. Fuzzing: Challenges and reflections[J]. IEEE Software, 2021, 38(3): 79-86
[73]Muench M, Stijohann J, Kargl F, et al. What you corrupt is not what you crash: Challenges in fuzzing embedded devices[C/OL] //Proc of Network and Distributed System Security Symp (NDSS). Piscataway, NJ: IEEE, 2018 [2022-01-07]. https://www.ndss-symposium.org/wp-content/uploads/2018/02/ndss2018_01A-4_Muench_paper.pdf
[74]Peng Yong, Jiang Changqing, Xie Feng, et al. Industrial control system cybersecurity research[J]. Journal of Tsinghua University: Science and Technology, 2012, 52(10): 1396-1408 (in Chinese)(彭勇, 江常青, 谢丰, 等. 工业控制系统信息安全研究进展[J]. 清华大学学报: 自然科学版, 2012, 52(10): 1396-1408)
[75]Sommestad T, Ericsson G N, Nordlander J. SCADA system cyber security: A comparison of standards[C] //Proc of IEEE PES General Meeting. Piscataway, NJ: IEEE, 2010: 1-8
[76]Wang Jian, Wang Tianyi, Zhai Yahong, et al. Comparative study on IEC 62443 and the baseline for classified protection of cybersecurity[J]. Huadian Technology, 2021, 43(2): 72-76 (in Chinese)(王建, 王天屹, 翟亚红, 等. IEC 62443系统安全要求与等级保护基本要求对比研究[J]. 华电技术, 2021, 43(2): 72-76)
[77]Di Liqing, Gao Yang, Xie Feng. Research on information security standard of industrial control system at home and abroad[J]. Journal of Information Security Research, 2016, 2(5): 435-441 (in Chinese)(邸丽清, 高洋, 谢丰. 国内外工业控制系统信息安全标准研究[J]. 信息安全研究, 2016, 2(5): 435-441)
[78]He Zhanbo, Wang Ying, Liu Jun. Research on the status and 2.0 standard system of network security classified protection in China[J]. Information Technology and Network Security, 2019, 38(3): 9-14 (in Chinese)(何占博,王颖,刘军.我国网络安全等级保护现状与2.0标准体系研究[J]. 信息技术与网络安全, 2019, 38(3): 9-14)
