SCADA Security. Xun Yi

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 to the historian server. This could occur when the MTU server is compromised (Jared Verba, 2008). (ii) It can be deployed in an independent server providing that it will not be compromised, and the server from time to time acquires information and statuses from all field devices (Fovino et al., 2010a). Similarly, the large requests from this server each time will increase the network overhead. Consequently, a performance issue may arise. (iii) Each adjacent field device can be connected with a server running SCADA application‐based IDS, which are similar to the works in (Alcaraz and Lopez, 2014a,2014b). However, the key issue is that SCADA data are directly (or indirectly) correlated, and therefore sometimes there is an abnormality in a parameter, not because of itself, but due to a certain value in another parameter (Carcano et al., 2011; Fovino et al., 2012). Therefore, it would be appropriate to assign an individual SCADA application‐based IDS for each of the correlated parameters.

2.3 IDS Approaches

      The concept of IDS is based on the assumption that the behavior of intrusive activities are noticeably distinguishable from the normal ones (Denning, 1987). Many types of SCADA IDSs have been proposed in the literature, and these fall into two broad categories in terms of the detection strategy: signature‐based detection (Digitalbond, 2013) and anomaly‐based detection (Linda et al., 2009; Kumar et al., 2007; Valdes and Cheung, 2009; Yang et al., 2006; Ning et al., 2002; Gross et al., 2004).

       Signature‐based

      This approach detects malicious activities in SCADA network traffic or application events by matching the signatures of known attacks that are stored in a specific database. The false positive rate in this type of IDSs is very low and can approach zero. Moreover, the detection time can be fast because it is based only on a matching process in the detection phase. Despite the aforementioned advantages of a signature‐based IDS, it will fail to detect an unknown attack whose signature is not known or which does not exist in its database. Therefore, the database must constantly be updated with patterns of new attacks.

       SCADA anomaly‐based

This approach is based on the assumption that the behavior of intrusive activities mathematically or statistically differs from normal behavior. That is, they are based on advanced mathematical or statistical methods used to detect the abnormal behavior. For example, normal SCADA network traffic can be obtained over a period of “normal” operations, and then a modeling method is applied to build the normal SCADA network profiles. In the detection phase, the deviation degree between the current network flow and the created normal network profiles is calculated. If the deviation degree exceeds the predefined threshold, the current network flow will be flagged as an intrusive activity. The primary advantage of anomaly‐based compared to signature‐based detection is that novel (unknown) attacks can be detected, although they suffer from a high false positive rate.

      A number of factors have a significant impact on the performance of SCADA anomaly‐based IDS in distinguishing between the normal and abnormal behavior, including the type of modeling method, the type of building process of the detection models, and the definition of an anomaly threshold. Three learning processes are usually used to build the detection models, namely supervised, semisupervised, and unsupervised. In the supervised learning, anomaly‐based IDS requires class labels for both normal and abnormal behavior in order to build normal/abnormal profiles. However, this type of learning is costly and time‐expensive when identifying the class labels for a large amount of data. Hence, semisupervised learning is proposed as an alternative, where an anomaly‐based IDS builds only normal profiles from the normal data that is collected over a period of “normal” operations. However, the main drawback of this learning is that comprehensive and “purely” normal data is not easy to obtain. This is because the collection of normal data requires that a given system operates under normal conditions for a long time, and intrusive activities may occur during this period of the data collection process. On the another hand, the reliance only on abnormal data for building abnormal profiles is not feasible since the possible abnormal behavior that may occur in the future cannot be known in advance. Alternatively, an anomaly‐based IDS uses the unsupervised learning to build normal/abnormal profiles from unlabeled data, where prior knowledge about normal/abnormal data is not known. In fact, it is a cost‐efficient method, although it suffers from low efficiency and poor accuracy (Pietro and Mancini, 2008).