directly to the MTU over an Ethernet connection. This open system architecture allows various products from different vendors to be integrated with each other to build a SCADA system at low cost. In addition, a remote field device can be supervised and controlled from any place and at any time using the Internet. Figure 2.3 shows the architecture of a typical networked SCADA system.
2.1.3 Protocols
There are over 150 protocols utilized by SCADA systems (Igure et al., 2006) but only a small group is widely used. Modbus (IDA, 2004) and DNP3 (Majdalawieh et al., 2006) are examples of such well‐known protocols. The communication protocol in SCADA is the main weakness regarding security and can be easily attacked from there. Firstly, when the communication protocols were initially proposed for the SCADA network, people were focusing more on their efficiency and effectiveness without considering the potential security issues they might encounter in the future. As the security concerns became critical, security researchers discovered that it was not easy to address this issue. One reason is that the upgrade or replacement of a vital SCADA network in old industrial systems can stop production. Secondly, most of the original SCADA systems were often separate from other corporate networks. Hence, a large number of communication layers and protocols were designed separately, including GE Fanuc, Siemens Sianut, Toshiba, Modbus RTU/ASCII, Allen Bradley DF1/DH, and other vendor protocols.
Figure 2.3 Third‐generation SCADA architecture.
Modbus is a widely used industrial protocol that works at application level and ensures that data delivery is carried out correctly between devices connected on different kinds of buses or networks. Modbus devices adapted a clientserver approach, where the Modbus slave device represents the server side while the Modbus master device represents the client side of the communication model. Only the master (Client) initiates the communication, while the slave (Server) listens to the request from the master in order to supply the requested data or execute the requested action. This means Modbus is a request/reply protocol, and has been widely used by millions of automation devices as industry's serial de facto standard communication protocol since 1979. Recently, this protocol has been integrated with TCP/IP and offers a modified version called Modbus/TCP that uses the TCP/IP as transport and network protocols (Modbus Organization, 2020).
Figure 2.4 The Modbus frame.
Figure 2.4 shows two modes of the Modbus protocol, namely, Modbus RTU and Modbus TCP/IP. The former is the most common implementation and uses binary coding and CRC error‐checking. Each message in this mode must be transmitted continuously without inter‐character hesitations and is framed by idle (silent) periods. As seen, Modbus PDU includes the Function Code field and Data payload. The server, which listens to any request from the client device, performs actions according to the function codes in the specifications of the protocol. The latter is simply the Modbus RTU protocol with a TCP interface that runs on Ethernet and carries the data of the Modbus message structure between compatible devices and allows them to communicate over a network. As shown in Figure 2.4, a standard Modbus data frame is embedded into a TCP frame without the Modbus checksum because standard Ethernet TCP/IP link layer checksum methods are used to check data integrity.
2.2 INTRUSION DETECTION SYSTEM (IDS)
An IDS is an autonomous hardware or software or a combination of these used to detect threats to SCADA systems from both internal and external attacks, by monitoring and analysing activities on a host computer or a network. A threat can be considered as a malicious activity intended to destroy the security of a SCADA system. Under the threat, the confidentiality, integrity, or availability of the host computers or networks are compromised. In addition, IDS can prevent potential threats to the SCADA system by detecting precursors to an attack, unauthorized access, abnormal operations, etc. According to the location and source of data collected, in traditional IT, IDSs can be categorized into network‐based and host‐based IDSs (Denning, 1987), and this categorization could be similar even to SCADA systems. However, due to the different nature of SCADA systems in terms of architecture, functionalities, and used devices, SCADA IDSs, within the scope of this book, are categorized based on only the source of data collected: SCADA network‐based and SCADA application‐based.
2.2.1 SCADA Network‐Based
A SCADA network‐based IDS (Valdes and Cheung, 2009; Gross et al., 2004; Ning et al., 2002; Linda et al., 2009) captures the data packets that are communicated between devices such as points‐to‐points in RTU/PLC, between RTU/PLCs and CTUs. The monitoring devices are always located throughout the network. The information in those captured data packets is evaluated to determine whether or not it is a threat. If the packet is suspicious, security team members will be alarmed for further investigation. The advantage of SCADA network‐based IDSs is their lower computation cost because only the information in the packet's header is needed for the investigation process, and therefore a SCADA network packet can be scrutinized on‐the‐fly. Consequently, a large amount of network data can be inspected in a satisfactory manner and within an acceptable time (Linda et al., 2009).
However, when there is high network traffic, a SCADA network‐based IDS might experience problems in monitoring all the packets and might miss an attack being launched. The key weakness is that the operational meaning of the monitored SCADA system cannot be inferred from the information provided at the network level such as IP address, TCP port, etc. Therefore, if the payload of the SCADA network packet contains a malicious control message, which is crafted at the application level, the SCADA network‐based IDS cannot detect it if it is not violating the specifications of the protocol being used or the communication pattern between SCADA networked devices (Fovino et al., 2010a,2012; Carcano et al., 2011).
2.2.2 SCADA Application‐Based
SCADA applications typically log valuable information about supervised and controlled processes, which are stored in historian servers for maintenance, business, historical, and insight purposes. The SCADA data, which are the measurement and control data generated by sensors and actuators, represent the majority of this information and, in addition, form the operational information for a given SCADA system through which the internal presentation of monitored systems can be inferred (Wenxian and Jiesheng, 2011; Carcano et al., 2011; Fovino et al., 2012; Rrushi et al., 2009b; Zaher et al., 2009). In contrast to the SCADA network‐based IDSs that inspect only network level information, a SCADA application‐based IDS can inspect high‐level data such as SCADA data to detect the presence of unusual behavior. For example, high‐level control attacks, which are the most difficult threats to be detected by a SCADA network‐based IDS (Wei et al., 2011), can be detected by monitoring the evolution of SCADA data (Rrushi et al., 2009b).
Since the information source of SCADA application‐based IDSs can be gathered from different and remote field devices such as PLC and RTU, there are various ways to deploy a SCADA application‐based IDS, as follows. (i) It can be deployed in the historian server, as this server is periodically updated by the MTU server which acquires, through field devices such as PLC and RTU, the information and status of the monitored system for each time period. However, this type of deployment raises a security issue, since the real information and statuses in the MTU server can be different from the ones that are sent
