6 looks in detail at a novel promising approach, called GATUD (Global Anomaly Threshold to Unsupervised Detection), that can improve the accuracy of unsupervised anomaly detection approaches that are compliant with the following assumptions: (i) the number of normal observations in the data set vastly outperforms the abnormal observations and (ii) the abnormal observations must be statistically different from normal ones. Finally, Chapter 7 looks at the authentication protocols in SCADA systems, which enable secure communication between all the components of such systems. This chapter describes two efficient TPASS protocols for SCADA systems: one is built on two‐phase commitment and has lower computation complexity and the other is based on zero‐knowledge proof and has less communication rounds. Both protocols are particularly efficient for the client, who only needs to send a request and receive a response.
ACRONYMS
AGAAmerican Gas AssociationASCIIAmerican Standard Code for Information InterchangeCOTSCommercial‐Off‐The‐ShelfCORECommon Open Research EmulatorCRCCyclic Redundancy CheckDDLDynamic Link LibraryDNPDistributed Network ProtocolDOSDenial Of ServiceEDMMEnsemble‐based Decision‐Making ModelEk‐NNExhaustive k‐Nearest NeighborEMANEExtendable Mobile Ad‐hoc Network EmulatorEPANETEnvironmental Protection Agency NetworkFEPFront End ProcessorGATUDGlobal Anomaly Threshold to Unsupervized DetectionHMIHuman Machine Interfacek‐NNk‐Nearest NeighborkNNVWCk‐NN based on Various‐Widths ClusteringIDSIntrusion Detection SystemIEDIntelligent Electronic DeviceIPInternet ProtocolITInformation TechnologyLANLocal Area NetworkNISCCNational Infrastructure Security Coordination CenterNS2Network Simulator 2NS3Network Simulator 3OMNETObjective Modular Network TestbedOPNETOptimized Network Engineering ToolOSTOrthogonal Structure TreeOSVDBOpen Source Vulnerability DataBasePCAPrincipal Component AnalysisPLCProgrammable Logic ControllerPLSPartial Least SquaresRTURemote Terminal UnitSCADASupervisory Control And Data AcquisitionSCADAVTSCADA security testbed based on Virtualization TechnologySDADSCADA Data‐driven Anomaly DetectionTCPTransmission Control ProtocolTPASSThreshold Password‐Authenticated Secret S in the boo.. It is haringUDPUser Datagram ProtocolUSBUniversal Serial Bus
CHAPTER 1 Introduction
This aim of this introductory chapter is to motivate the extensive research work carried in this book, highlighting the existing solutions and their limitations, and putting in context the innovative work and ideas described in this book.
1.1 Overview
Supervisory Control and Data Acquisition (SCADA) systems have been integrated to control and monitor industrial processes and our daily critical infrastructures such as electric power generation, water distribution and waste water collection systems. This integration adds valuable input to improve the safety of the process and the personnel and to reduce operation costs (Boyer, 2009). However, any disruption to SCADA systems can result in financial disasters or may lead to loss of life in a worst case scenario. Therefore, in the past, such systems were secure by virtue of their isolation and only proprietary hardware and software were used to operate these systems. In other words, these systems were self‐contained and totally isolated from the public network (e.g., the Internet). This isolation created the myth that malicious intrusions and attacks from the outside world were not a big concern and that such attacks were expected to come from the inside. Therefore, when developing SCADA protocols, the security of the information system was given no consideration.
In recent years, SCADA systems have begun to shift away from using proprietary and customized hardware and software to using Commercial‐Off‐The‐Shelf (COTS) solutions. This shift has increased their connectivity to the public networks using standard protocols (e.g., TCP/IP). In addition, there is decreased reliance on a single vendor. Undoubtedly, this increases productivity and profitability but will, however, expose these systems to cyber threats (Oman et al., 2000). According to a survey published by the SANS Institute (Bird and Kim, 2012), only 14% of organizations carry out security reviews of COTS applications that are being used, while over 50% of other organizations do not perform security assessments and rely only on vendor reputation or the legal liability agreements, or they have no policies at all regarding the use of COTS solutions.
The adoption of COTS solutions is a time‐ and cost‐efficient means of building SCADA systems. In addition, COST‐based devices are intended to operate on traditional Ethernet networks and the TCP/IP stack. This feature allows devices from various vendors to communicate with each other, and also helps to remotely supervise and control critical industrial systems from any place and at any time using the Internet. Moreover, wireless technologies can efficiently be used to provide mobility and local control for multivendor devices at a low cost for installation and maintenance. However, the convergence of state‐of‐the‐art communication technologies exposes SCADA systems to all the inherent vulnerabilities of these technologies. In what follows, we discuss how the potential cyber‐attacks against traditional IT can also be possible against SCADA systems.
Denial of Services (DoS) attacks. This is a potential attack on any Internet‐connected device where a large number of spurious packets are sent to a victim in order to consume excessive amounts of endpoint network bandwidth. A packet flooding attack (Houle et al., 2001) is often used as another term for a DoS attack. This type of attack delays or totally prevents the victim from receiving the legitimate packets (Householder et al., 2001). SCADA networking devices that are exposed to the Internet such as routers, gateways and firewalls are susceptible to this type of attack. Long et al. (2005) proposed two models of DoS attacks on a SCADA network using reliable simulation. The first model was directly launched to an endpoint (e.g., controller or a customer‐edge router connecting to the Internet), while the second model is an indirect attack, where the DoS attack is launched on a router (on the Internet) that is located in the path between the plant and endpoint. In this study, it was found that DoS attacks that were launched directly (or indirectly) cause excessive packet losses. Consequently, a controller that receives the measurement and control data late or not at all from the devices deployed in the field will make a decision based on old data.
Propagation of malicious codes. Such types of attack can occur in various forms such as viruses, Trojan horses, and worms. They are potential threats to SCADA systems that are directly (or indirectly) connected to the Internet. Unlike worms, viruses and Trojans require a human action to be initiated. However, all these threats are highly likely as long as the personnel are connected to the Internet through the corporate network, which is directly connected to the SCADA system, or if they are allowed to plug their personal USBs into the corporate workstations. Therefore, a user can be deceived into downloading a contaminated file containing a virus or installing software that appears to be useful. Shamoon (Bronk and Tikk‐Ringas, 2013), Stuxnet (Falliere et al., 2011), Duqu (Bencsáth et al., 2012), and Flame (Munro, 2012) are examples of such threats targeting SCADA systems and oil and energy sectors.
Inside threats. The employees who are disgruntled or intend to divulge valuable information for malicious reasons can pose real threats and risks that should be taken seriously. This is because employees usually have unrestricted access to the SCADA systems and also know the configuration settings of these systems. For instance, the attack on the sewage treatment system in Maroochy Shire, South‐East Queensland (Australia) in 2001 (Slay and Miller, 2007) is an example of an attack that was launched by a disgruntled employee, where the attacker took over the control devices of a SCADA system and caused 800,000 litres of raw sewage to spill out into local parks and rivers.Figure 1.1 SCADA vulnerabilities revealed since 2001 in OSVDB.
Unpatched vulnerabilities. The existence of vulnerabilities is highly expected in any system and it is known that hackers always exploit unpatched
