Sage Journals: Discover world-class research

Abstract

This study examined the security of SCADA system and its protocols, more specifically, SCADA/DNP3 protocol security. To achieve the study goals, a SCADA simulation environment is designed for water pumping process through connectivity of intelligent sensors, the payload is constructed, and security is deployed inside DNP3 protocol stack and then bytes are multicast to subcontrollers.

1. Introduction

In current age, the network base SCADA (supervisory control and data acquisition) systems are performing advance functions and provide all operational facilities, as traditional networks such as LAN/WAN and others [1]. The existing SCADA systems were connected with limited number of networks and usually the connectivity between network nodes is one-to-one (or unicasting) transmission [1, 2]. In few cases, SCADA system provides broadcasting service, such that bytes are broadcast to each and every node within configured network. The broadcasting facility is limited to controller side. In case of unsolicited message (or response bytes), remote sensor-node is authorized to send or issue an unsolicited request to main controller and upon receiving master node transmits an acknowledge message back to remote node. Overall, transmission is usually granted or/and occurred as unicasting transmission, meaning that the remaining network nodes are unaware during transmission [2, 3].

Nowadays, SCADA systems are employing modern technologies to fulfill the current requirements of industrial infrastructures. Due to massive changed found in arena of real time systems, the communication has been going to unsecured and undeliverable to destinations due to several potential vulnerabilities and attacks [4–11]. To minimize the security issues of SCADA communication, several end-to-end security developments have been made and commercial software is employed [1, 12–17]. In SCADA systems, numbers of cryptography keys are distributed among nodes followed by SCADA communication requirements [11, 18–21]; the desired message is encrypted before transmitting to destination and upon receiving at remote side decryption function is required and applied to open the sender request message [12–15, 22]. Encryption based security approaches are considered as best approaches to hide the sensitive information of SCADA systems against adversaries [14, 17, 22–28]; the security approaches such as IPSec, SSL/TLS, and pattern have also been deployed in enhancement of SCADA security but these are not considered as best due to protocol dependencies, while being compared with cryptography based approaches [23, 29–31].

In researches papers [2, 23, 25], symmetric key encryption is deployed which made security enhancement in transmission of payload in SCADA system or between SCADA field devices; the field devices are designated as sensor device which are connected with physical world and configured to manipulate the information from and process to SCADA main controller [29, 30, 32, 33]. The main controller is supervisorial in SCADA hierarchical structure and sensor devices are treated as slave devices; the network structure of SCADA systems are defined as statistical structure, meaning that all network nodes are defined and configured in advance. The hierarchical structure is static, so there is minimal chance of attacks such as man-in-the-middle attack or/and network attacks [23]. In other researches [25, 30, 31], the use of commercial security software in SCADA systems is considered inappropriate due to number of limitations such that mostly commercial tools designs are based on general manipulation of SCADA system security without concedes of specified SCADA protocol(s) [16, 17]. The hashing algorithm is accounted as a best security approach in SCADA transmission or/and SCADA protocols transmission [23, 30]. Hashing algorithm (or SHA-2 hashing algorithm) is deployed during message exchanging of DNP3 protocol as a part of SCADA communication system. The DNP3 payload is generated and hashing function is applied on to compute the hash digest of payload; the hashing function produced a fixed value of payload that would be helpful to protect the payload from integrity attacks such as payload modification and payload reply. The original payload and computed hash digest is transmitted to outstation (i.e., a sensing device or a computer connected with sensor). Upon receiving, hash digest is again computed by outstation to make comparison with main controller hash digest; on the basis on comparison result the decision would be made either rejected or accepted. In consequence of comparison, if main controller and outstation hash values are matched then payload is accepted or otherwise rejected, and corresponding conformation is replied [25, 30].

Usually, SCADA system provides two types of communication facilities: balance and unbalance, depending on protocol uses [2, 3]. Distributed network protocol (DNP3) is the most popular protocol, which has been employed by SCADA systems. DNP3 protocol has four layers in its stack including application layer, pseudotransport layer, data link layer, and physical layer. In each layer, message size is limited up to 2048 bytes, 250 bytes, and 292 bytes, and physical layer is helpful during transmission of bytes. The DNP3 protocol is supported for both balance and unbalance communications, decided at its data link layer. Meaning that, in unbalanced system, each and every node is able to initiate the communication with main node, while, in balance system, only main node is authorized to initiate the communication with connected subnodes in SCADA system [1–3]. The basic configuration and specifications are required whether main controller sends request to subcontroller or sub controller initiates the communication, and are considered at application layer of DNP3 protocol [34, 35]. The proposed study employs a balance system in SCADA multicasting transmission and deploys the security before transmitting of bytes to open network(s).

The rest of research paper is organized as follows. In Section 2, problem statement is conducted that is directly linked with proposed study, and research objectives are identified that are considered as building blocks of proposed study. A simulation is designed for water pumping system in Section 3 and its overall control is managed by SCADA/DNP3 system. The SCADA/DNP3 testbed setup is created and multicasting sensor-nodes are configured in Section 4, while Section 5 explains the detail security development and its corresponding communication details. Performance assessment and comparison is made in Section 6 which shows the significant computed results. The existing survey on SCADA/DNP3 security issues is described in Section 7 and Section 8 concludes the overall study.

2. Problem Statement

The multicasting transmission between SCADA sensors-controllers (or nodes) is commonly found and required in SCADA systems. In particular, in the case of warm traffic or abnormal scenario, in which the attacker successfully gains control, distinguish sensors-controllers and other SCADA sensors-controllers remained the same or normally communicate with main controller. The main controller analyzes the abnormal communication within network system and is unable to recover them, as normal communication, and also has no alternative solution for system recovery. Therefore, main controller gives the alarm to all stations to turn off. In this scenario, whole SCADA transmission is suffered including normal sensors-controllers, which significantly affects the critical communication or SCADA system communication. The overall transmission is down until system recovery, which is the most dangerous situation for critical infrastructures such as electrical stations, water pumping and controlling stations, aircraft controlling systems, and others [2, 3].

Research Objectives. The research objective of this study is twofold: (i)

The SCADA communication is persuaded to multicasting communication, and its security directions will be helpful to handle the abnormal scenarios.

(ii)

Based on best performance evaluation, the DNP3 protocol stack is designed and security solution via cryptography is deployed, with SCADA/DNP3 transmission acquirements in mind during bytes multicasting.

3. SCADA Simulation Environment

SCADA simulation environment is designed for water pumping system which collects the water from external source and performs the operations of cooling and heating, which would further utilize industrial processes. In simulation environment (in Figure 1), SCADA main controller monitors the whole water pumping system through configured subcontrollers. Raw water is collected in main storage (or main water storage) and distributed to local storages by mean of motors, which would further use in cooling/heating operations. Two water pressure intelligent-sensors are directly connected with local water storages, which check/monitor the water pressure status; integrated programmable logic controllers (PLCs) are used to manage (or control) the pumping according to main controller set points. Meaning that, if the water level in low in the local storage, then operational heater/cooler (or heater/cooler devices) is turned off and subcontrollers activate the water pumping from main storage. An intelligent-sensor designated as cooling control sensor is directly attached with cooler (device), which controls and monitors the cooling levels according to the main controller/subcontroller set points.

Figure 1

SCADA/DNP3 supervisory environment: water pumping system.

On the other side, if the sensors sense the water level is high or according to the set points, then water pumping is deactivated and corresponding operations are performed. An intelligent-sensor called heating control sensor is directly attached with heater (device), which controls and monitors the heating levels according to the main controller/subcontroller set points. The overall information is processed by the means of configured sensors; the subcontrollers read the information from sensors; then, this information is processed to main controller for monitoring purposes.

4. SCADA Testbed Setup and Configuration

In SCADA testbed (in Figure 2), six remote stations (or subcontrollers), plus sensor- controller node (or RTU1) which is treated as rendezvous point (RP), are configured with main controller. Three subcontrollers such as RTU2, RTU3, and RTU7 are individually connected to supervise and control the water heating processes including water incoming/outgoing pressure, water level, cooling level, and electricity consumption, while the remaining subcontrollers such as RTU4, RTU5, and RTU6 are connected with water cooling processes and perform several operations including monitor the water level in local storage through level sensors and water pressure by pressure sensors, cooling processes through cooler device and cooling level by cooling control sensor, and electricity consumption. On the other side, the overall multicasting transmission is controlled by node called sensor-controller node and the main controller is used for commands execution or set points to subcontrollers and monitoring purposes. In this study, a simulation base water pumping system is designed in the first phase, and, in the second phase, security is implemented during bytes multicasting transmission and its evaluation process through attacks scenarios.

Figure 2

Testbed setup and configuration.

4.1. Multicasting Routing

In SCADA/DNP3 testbed, bytes or frames are constructed in DNP3 protocol stack and transmitted to internet protocol (IP) via user datagram protocol (UDP) which is situated below then DNP3 protocol; transport control protocol (TCP) is used in case of response bytes. In testbed setup (in Figure 2), seven subcontrollers are configured with main controller or main node via four routers. The overall connectivity between subcontrollers and main controller is statically configured, meaning that all subcontrollers are known in advance, with multicasting group IP: 224.2.2.2 which avoids the unknown entry during multicasting transmission. The routers such as R1, R2, R3, and R4 are also configured statically, having multicasting tables, while this should be decided by main controller either delete or add the node(s) from/to multicasting group or/and multicasting table. A multicasting protocol or protocol independent multicast (PIM) has been used and configured, which sets up the directions called distribution tree between main controller and subcontrollers of SCADA multicasting group during transmission of bytes, without setting the time to live (TTL) field. At other side, the router “R1” connected with main controller uses the Internet Group Management Protocol (IGMP) to identify the connected hosts within SCADA network and also keeps the track of multicasting members, based on main controller selection list. Meaning that, each time main controller transmits a message to multicasting hosts or subcontrollers, the router lookup table is updated with specified subcontrollers list via main controller and the remaining nodes in table are voided by router. All routers are configured statically with specified subcontrollers, but the router “R1” connected directly with main controller is updated each time based on main controller selection process for multicasting subcontrollers. When a router receives the multicasting packets according to main controller selection process, the router forwards the packets to subcontrollers of multicasting group, in connected network(s).

5. Security Design and Implementation

SCADA/DNP3 stack has been designed and security is deployed within each layer including application layer, pseudotransport layer, and data link layer; a new dynamic buffer or cryptography dynamic buffer (CDB) is employed which keeps the information of security implementation and other related detail. CDB contains 56 bytes which would be utilized during whole security design and implementation. In Table 1, a field called “user bytes” is designated for those bytes, which have been constructed in DNP3 stack, while the other fields including source address, destination multicasting addresses, cryptography key sequence, and cryptography (bytes), dynamic storage (bytes), option (bytes), padding or dynamic bytes, acknowledgment, noncritical (bytes), critical (bytes), and solution or select method, belong to CDB, which performs distinct functions during security development [23, 36].

Table 1

New DNP3 stack with CDB bytes: the CDB contained 56 bytes and would be increased according to the bytes requirements. The additional 32 bytes of CRC are dynamically added in CDB from data link layer. The CDB has number of fields with distinct bytes, which are employed during security development [36].

Source address	Destination multicasting addresses

User bytes

Cryptography key sequence

Cryptography (bytes): dynamic storage (bytes)

Option (bytes)	Padding (dynamic bytes)

Acknowledgment

Noncritical (bytes)	Critical (bytes)

Solution: select method

In Figure 3, each time message has been multicast from main controller to subcontrollers or/and vice versa (in case of response, acknowledgment message); security is deployed before transmitting to open network, such that 3-way-hashing using SHA-2 algorithm is deployed at each layer, and symmetric encryption using AES algorithm is deployed in application layer and data link layer of DNP3 protocol. Meaning that each subcontroller has two secret keys during security deployment plus 3-way-hashing. The performance that Figure 7 shows is the bytes allocation and utilization during message design and security deployment. The CDB contains 56 bytes, which have been utilized during security development and are enough for information storage, even in case, maximum bytes, or user bytes as 1992 bytes are received from user application layer to lower layer of DNP3; without use of CRC (cyclic redundancy code) bytes from data link layer. In few experiments, secret key is only employed on data link layer frame or link protocol data unit (LPDU) bytes, not in application layer. The corresponding performance results are significantly affected, while being compared with first security deployment scenario. In testbed, link layer frame or LPDU bytes are encrypted, but in few cases, this is difficult to identify the main controller or/and subcontrollers addresses. Therefore, two external fields, source address, 2-bytes (unassigned), and destination multicasting address, 4-bytes (unassigned), are added which would be meaning full in identification process, and authentication process of internal/external addresses during decryption operation, at data link layer. Table 2 shows the detail of CDB field's and corresponding bytes detail.

Table 2

CDB dynamic fields with allocated bytes.

Number	Field name	Occupied bytes	Description
1	Source address and port	2 bytes	External field representing the main controller address during multicasting transmission or in case of response from each subcontroller
2	Destination multicasting addresses and ports	4 bytes	Representing the multicasting addresses of selected subcontrollers
3	User bytes	2 bytes	Keep the information of protocol constructed bytes
4	Cryptography key sequence	4 bytes	Cryptography keys are employed with distinct numbers and counted in this field
5	Cryptography: dynamic storage	22–56 bytes	Information is updated and bytes are dynamically in/out, according to the requirements
6	Option	2 bytes	Verify the contents of message, before transmission
7	Padding	2 bytes	Ensure and show the status of completed message
8	Acknowledgment	2 bytes	Main controller/subcontroller acknowledgment message
9	Critical	1 byte	Show the status of abnormal entity
10	Noncritical	1 byte	Ensure the bytes are flowed in normal transmission
11	Solution: select method	1 byte	Show the detail of security method that is being used

Figure 3

Security implementation within DNP3 stack: the current study deploys a cryptography based security solution against SCADA/DNP3 multicasting in security. Two cryptography algorithms such AES and SHA-2 are employed to compute the security test such as authentication, confidentiality, and integrity. The nonrepudiation test is a limitation of this study, due to transmission limitations. The public key cryptography is not appropriate for SCADA/DNP3 multicasting transmission but should be used in unicasting communication.

In Figure 4, SCADA/DNP3 stack is designed and bytes are flowed from user application layer to DNP3 application layer and downward. The DNP3 stack is designed to manage the maximum bytes which flow from user application layer or in case, when application layer buffer is full as 2048 bytes plus 56 bytes of CDB. The number of rows (RWs) and columns (CLs) with corresponding offsets shows the complete DNP logical stack, with security bytes. The highlighted bytes in DNP stack, the bytes 0x00c3 and 0x00c1, represent the application layer header bytes; the byte “0x001c” is representing the pseudotransport layer header byte, and the bytes 0x00aa and 0x00cc are representing the data link layer header bytes, while the remaining highlighted bytes such as 0x001a, 0x00ee, 0x002a, and 0x00ee in application layer stack, 0x002a and 0x00ee in pseudotransport layer stack, and 0x001a, 0x00ee, 0x002a, and 0x00ee in data link layer stack are representing the security bytes via cryptography dynamic buffer (CDB). The reaming bytes in hexadecimal format are representing the user bytes which are constructed in DNP3 stack or each layer of DNP3 stack and the shaded area shows that the space is empty, and this would be filled up in case of 1992 user bytes that are constructed and manipulated in application layer.

Figure 4

Logical bytes flow in DNP3 stack: the bytes are constructed according to SCADA/DNP3 protocol specifications, security is deployed, and corresponding information is updated in CDB. Each layer stack shows the maximum bytes followed by number of columns and rows. The shaded area shows that bytes are not placed, because limited bytes are received from user application layer. Therefore, empty cells are shaded or treated as padding, by whom DNP3 protocol ensures that message is completed, with security implementation. However, few bytes are reserved within each layer stack, which would be used for future developments.

The message is distinguished at application layer whether sending bytes or response bytes. In application layer, sending/response message is distinct by occupied bytes. Meaning that sending header contains two bytes and response header contains same fields of sending header, plus two bytes field called internal indication (IIN).

Example. Suppose that main controller wants to execute read/write commands, and subcontroller (s) will response by employing IIN field. Such that

Request: Read Function <C3 01>

Response: <C3 81 00 00>

Request: Write Function <C3 02>

Response: <C3 81 00 00>

The byte “C3” is representing the application control (AC) and function code (FC) “01” is added for read (request) and function code (FC) “02” is added for write (request). On the other side, internal indication (IIN) field contains two bytes, and corresponding codes <00 00> are generated in response, plus function code (FC) “81” in both cases: read and write.

Request: Cold_Restart Function <C3 0D>

Response: <C3 81 00 00>

Request: Warm_Restart Function <C3 0E>

Response: <C4 81 00 00>

In another example, main controller wants to execute the cold_restart and warm_restart functions using codes: 0D and 0E. In response, subcontrollers transmit IIN codes <00 00>, plus function code (FC) “81” in both cases, but AC code is different as “C3,” in case of cold_restart and “C4” in case of warm_restart. In multicasting, each subcontroller is responses with distinct sequence number. Application control (AC) field contains 5 bits subfield called sequence, plus 1 bit of confirmation. Therefore, each subcontroller is responses to main controller using distinct sequence numbers, from 0 to 15.

The more concise flow of SCADA/DNP3 system is illustrated as in Figure 5. In multicasting flow, DNP3 protocol bytes are constructed in each layer, and corresponding functions are manipulated followed by request and response messages [25, 37]. At main controller side, DNP3 request is generated and multicast to remote terminal units (RTUs), followed by multicasting group. Four remote terminal units (RTUs) included RTU3, RTU4, RTU6, and RTU7 and are depicted which received the main controller request message. In response bytes flow, response is generated from RTUs and transmitted back to main controller; in this scenario, unicasting communication is employed rather than multicasting. Numbers of examples are taken from SCADA/DNP3 transmission during flow of request/response bytes and are visualized as in Figure 6.

Figure 5

SCADA/DNP3 communication: bytes flow during multicasting.

Figure 6

SCADA/DNP3 communication: bytes flow during request/response messages.

Figure 7

DNP3 stack with CDB bytes allocation and utilization: the successful experiments are performed 76 times and the level of bytes is computed from total allocation and utilization of bytes. As shown in y-axis, random bytes are transmitted form master controller to subcontroller(s). The blue color lines show the bytes utilized during application layer message construction, red lines show the pseudotransport layer bytes, and light green lines show the data link layer bytes, while purple lines are CDB bytes which are dynamically computed form protocol by the means of padding, plus original CDB bytes.

Figure 8

Attack detection against SCADA/DNP3 stack security: the attacks including authentication attacks, guessing shared key, brute force, and password guessing, using built-in attacking tools such as cracking tools, sniffer, dsniff, winsniffer, and password dictionary; integrity attacks: frame injection, data replay, and data deletion, using attacking tools such as airpwn, file2air, dinject/reinject, capture and injection tools, and jamming and injection tools; confidentiality attacks: eavesdropping, key cracking, and man-in-the-middle, using attacking tools such as ethereal, ettercap, kismet, aircrack, airsnort, dsniff, and ettercap, are launched 282 times, 94 experiments are selected (or sampled) to verify each security test such as authentication, integrity, and confidentiality, through the level of attacks detection. The attacks presented by colored markers show the successful detection of attacks. The green flowed lines show the normal transmission during bytes multicast from main controller, in-between, attacks are detected, and then bytes follow the normal sequence. On x-axis, 94 experiments are sampled (or collected) from total experiments which showed the most approximate performances, and sequence is used from 1 to 94. Total 18 experiments are not labeled because these experiments are used for special purposes.

Figure 9

Attack detection (partially) against SCADA/DNP3 stack security: these are attacks, which are detected during abnormal communication but the influence is minimal or, in other words, few bytes are intercepted in whole packet. The attacks are counted so we designate these attacks as partially detected attacks. The number of experiments labeled on x-axis is the same as Figure 8 experiments, with the same data rates but distinct attack locations. The partially detected attacks are separately graphed which show the difference with fully detected attacks (in Figure 8).

Figure 10

Attack detection against SCADA/DNP3 end-to-end security: here also, the attacks including authentication attacks, guessing shared key, brute force, and password guessing, using built-in attacking tools such as cracking tools, sniffer, dsniff, winsniffer, and password dictionary; integrity attacks: frame injection, data replay and data deletion, using attacking tools such as airpwn, file2air, dinject/reinject, capture and injection tools, and jamming and injection tools; confidentiality attacks: eavesdropping, key cracking, and man-in-the-middle, using attacking tools such as ethereal, ettercap, kismet, aircrack, airsnort, dsniff, and ettercap, are launched 282 times and 94 experiments are selected as best experiments which would be helpful in comparison process with other performances that are illustrated in Figures 8, 9, 11, and 12. On y-axis, random bytes are multicast and security is implemented and tested at each end of communication nodes. Security tests such as authentication, integrity, and confidentiality are performed and level of attacks detection is computed. As performance of Figure 8, 94 best experiments are sampled (or collected) from total experiments which show the most approximate performance results, and sequence is used from 1 to 94. Total 18 experiments are not labeled because these experiments are used for special purposes.

Figure 11

Attack detection (partially) against SCADA/DNP3 end-to-end security: as performance of Figure 9, the above graphed attacks are detected during abnormal communication, but the influence is minimal or, in other words, few bytes are intercepted in whole packet, in each experiment test. The attacks are detected so we designated these attacks as partially detected attacks. The number of experiments on x-axis is the same as Figure 10 experiments, with the same data rates but distinct attack locations. The partially detected attacks are separately graphed which create the difference with fully detected attacks (in Figure 10).

Proof (security development).

The “X” is application layer constructed bytes and “μ” is a function that performs the encryption “Ey” on bytes “X.” The total constructed bytes from application layer have been added in cryptography dynamic buffer (CDB) “ $b^{d y}$ ” and cryptography functions such as symmetric encryption “ ${S y m}^{f}$ ” using AES algorithm and hashing “ $H^{f}$ ” using SHA-2 is performed on bytes. Upon receiving, decryption function “Dy” is performed using the shared keys with sender/receiver hash digests.

Application Layer. Encryption process is as follows:

\begin{array}{l} \exists : \forall μ_{S (m, H, E [k])}^{AL} : {Ey}_{i \leftarrow u_{rb}, E \to {Sym}^{f}, H \to H^{f}}^{AL} {\exists : \forall X_{AL}^{α = \land} \\ \cdot \sum_{i \leftarrow u_{rb}, f \to f_{n}}^{lim \leftarrow k} \exists : \forall μ_{S}^{AL} (f_{n} : X_{f \to f_{n}}^{AL})} ‖ f_{n} : f_{n} : \\ X_{b^{dy}, f \to f_{n}}^{AL} . \end{array}

(1)

Application Layer. Decryption process is as follows:

\begin{array}{l} \exists : \forall μ_{R (m, H, E [k])}^{AL} : \\ {Dy}_{i \leftarrow u_{rb}, D \to {Sym}^{f}, H \to H^{f}}^{AL} {{Ey}_{i \leftarrow u_{rb}, E \to {Sym}^{f}, H \to H^{f}}^{AL} \\ \cdot \sum_{i \leftarrow u_{rb}, f \to f_{n}}^{lim \leftarrow k} \exists : \forall μ_{S}^{AL} (f_{n} : X_{f \to f_{n}}^{AL})} ‖ f_{n} : f_{n} : \\ X_{b^{dy}, f \to f_{n}}^{AL} . \end{array}

(2)

The “Q” is pseudotransport layer constructed bytes and “α” is a function that performs the hashing on bytes “Q.” The total constructed bytes from pseudotransport layer have been added in cryptography dynamic buffer (CDB) and hashing function “ $H^{f}$ ” using SH-2 is performed on bytes “Q.” At the receiving side, hash value is calculated and sender/receiver hash digests are compared which verified the integrity of bytes.

Transport Layer. Encryption process is as follows:

\begin{array}{l} H (\exists : \forall Q_{TL}^{α = \land} \cdot \sum_{i \leftarrow u_{rb}, {f \to f}_{n}}^{l i m \leftarrow k} \exists : {\forall α}_{S}^{TL} (f_{n} : Q_{{f \to f}_{n}}^{TL})) ∥ f_{n} : \\ f_{n} : Q_{b^{dy}, {f \to f}_{n}}^{TL} \in h_{{digest}^{S}} . \end{array}

(3)

Transport Layer. Decryption process is as follows:

\begin{array}{l} H (\exists : \forall Q_{TL}^{α = \land} \cdot \sum_{i \leftarrow u_{rb}, f \to f_{n}}^{lim \leftarrow k} \exists : \forall α_{S}^{TL} (f_{n} : Q_{f \to f_{n}}^{TL})) ‖ \\ f_{n} : f_{n} : Q_{b^{dy}, f \to f_{n}}^{TL} h_{{digest}^{S}} = H (\exists : \forall Q_{TL}^{α = \land} \\ \cdot \sum_{i \leftarrow u_{rb}, f \to f_{n}}^{lim \leftarrow k} \exists : \forall α_{R}^{TL} (f_{n} : Q_{f \to f_{n}}^{TL})) ‖ f_{n} : f_{n} : \end{array}

(4)

The “J” is data link layer constructed bytes and “β” is a function that performs the encryption “Ey” on bytes “J.” The total constructed bytes from data link layer have been added in cryptography dynamic buffer (CDB) and cryptography functions such as symmetric encryption “ ${S y m}^{f}$ ” using AES algorithm and hashing “ $H^{f}$ ” using SHA-2 are performed on bytes. Upon receiving, decryption function “Dy” is performed using the shared keys with sender/receiver hash digests.

Data Link Layer. Encryption process is as follows:

\begin{array}{l} \exists : \forall β_{S (m, H, E [k])}^{DL} : {Ey}_{i \leftarrow u_{rb}, E \to {Sym}^{f}, H \to H^{f}}^{DL} {\exists : \forall J_{DL}^{α = \land} \\ \cdot \sum_{i \leftarrow u_{rb}, f \to f_{n}}^{lim \leftarrow k} \exists : \forall β_{S}^{DL} (f_{n} : J_{f \to f_{n}}^{AL})} ‖ f_{n} : f_{n} : \\ J_{b^{dy}, f \to f_{n}}^{DL} . \end{array}

(5)

Data Link Layer. Decryption process is as follows:

\begin{array}{l} \exists : \forall β_{R (m, H, E [k])}^{DL} : \\ {Dy}_{i \leftarrow u_{rb}, D \to {Sym}^{f}, H \to H^{f}}^{DL} {{Ey}_{i \leftarrow u_{r b}, E \to {Sym}^{f}, H \to H^{f}}^{DL} \\ \cdot \sum_{i \leftarrow u_{rb}, f \to f_{n}}^{lim \leftarrow k} \exists : \forall β_{S}^{DL} (f_{n} : J_{f \to f_{n}}^{AL})} ‖ f_{n} : f_{n} : \\ J_{b^{dy}, f \to f_{n}}^{DL} . \end{array}

(6)

6. Performance Evaluation and Comparison

Number of times testbed experiments has been run and 94 experiments are individually selected to perform each security test. In each of the 94 experiments, 12 experiments are employed and specified for acknowledgment, while required from subcontrollers 2 experiments are used to check the transmission errors and flow; 4 experiments are used and specified for acknowledgment, while being required from main controller; and remaining 76 experiments are used to perform measurements.

The comparison process of computed performance results are involved into two basic phases such as total attacks detection percentages (which are based on fully attacks detection percentage and partially attacks detection percentage) and total attacks impact percentage. As visualized in performance Figure 14, the total attacks detection is 11% by addition of fully and partially attacks detection percentages, in case of SCADA/DNP3 stack security, and total attacks percentage is increased up to 28%, in case of SCADA/DNP3 end-to-end security.

The impact percentage level is as high as 25%, while comparing with SCADA/DNP3 stack security as 5%. Based on attacks impact percentages, the security level is computed as 95% (in case of SCADA/DNP3 stack security) and 75% (in case of SCADA/DNP3 end-to-end security).

The computed security is compared with performance, shown in Figure 12. The total attacks detection and attacks impact is 95% and corresponding security is 5% which shows high difference, while comparing with the other two cases. In this study, overall results are computed as approximate measurements and also compared with existing works [12–17, 23, 24]. As conclusion, the proposed development has great potential to secure the SCADA/DNP3 multicasting communication, which is not intended by existing developments [3, 32–35, 38–42].

Figure 12

Attack detection against SCADA/DNP3 testbed without security development: the same measurement phenomenon is followed from performance Figure 8, with the same data rates. The overall attacks detection is computed without employing of any security solution. Number of times random bytes are transmitted and attacks are launched and observed. Approximately, 269 times attacker gains the control on transmission but we sampled only 94 experiments, from total. The sampled experiments show the full attacks detection rather than partially detection. These results are used during performance comparison, with Figures 8 and 10.

Figure 13

Average latency during multicasting: experiments are performed to compute the average latency during multicasting of bytes to subcontrollers such as RTU2, RTU3, RTU4, RTU5, RTU6, and RTU7. The subcontrollers are not labeled in ascending order; the sequence is followed by performance Figure 8 and then subcontrollers 2 and 5 are added. The green lines show the average latency rates during SCADA/DNP3 stack transmission, while red lines show the average latency rates during SCADA/DNP3 end-to-end transmission. The green lines show the high average latency rates while comparing with red lines in performance figure (or Figure 13) and blue lines show the dummy multicasting transmission flow. As conclusion, the overall measured average latency is under the range of real time communication.

Figure 14

Performance evaluation and comparison.

As a consequence of computed security, we can conclude that there is significant enhancement accounted against SCADA/DNP3 system in-security; this is difficult for attackers to keep or to interrupt the sensitive information of SCADA/DNP3 system. This study successfully deployed the security mechanism and provides a secured system against attacks including integrity attacks, confidentiality attacks, and authentication attacks.

7. Literature Survey

The security development process for SCADA system is not new, several approaches including IPSec, SSL/TLS security, intrusion detection and prevention systems, security pattern, and cryptography are deployed against SCADA in-security [12, 14, 16]. The cryptography base approaches are counted as an important development against SCADA security issues which significantly reduces the impact level of attacks/threads such as unauthorized control, spoof, data replay, data modification, and eavesdropping, in DNP3 protocol and in other SCADA protocols transmissions [24, 41]. A peer-to-peer security is deployed for SCADA system, by using of cryptography mechanism; cryptography keys are generated and distributed among subcontrollers during encryption/decryption processes. As results, significant security is measured during SCADA transmission, but, overall, performance results are limited to peer-to-peer communication [13, 15]; the security development is not directed to SCADA multicasting communication (in which, main controller send the encrypted message to several subcontrollers, at same time), due to several limitations and complicities during cryptography deployment [15, 23, 40].

Larger number of vulnerabilities has been raised, while employing advance information and communication technology (ICT) and usage of open networks/protocols, in SCADA systems [32, 39]. The major vulnerabilities such as architectural, policy, software, and open protocols vulnerabilities provide several weaknesses and open platforms for threads/attacks, in SCADA communication. The potential threads such as DOS, infection, malware, phishing, poisoning, and others, which have been residing in SCADA networks, are analyzed; then, countermeasures are provided for protocols such as TCP/IP, DNP3, AGA 12, and Modbus, which give significant protection against attacks/threads [17, 42]. A simulation has been designed that monitors and controls the SCADA field devices via Modbus protocol [38, 43]. The results are also measured that show warm performance impact of attacks/threads on SCADA system [1, 33].

8. Conclusion and Future Work

In SCADA system, field devices or sensors-controllers are connected geographically, at several locations and monitored by centralized controller called main controller. Due to large interconnectivity and employing of open networks/protocols, SCADA system got several vulnerabilities. In existing survey, several end-to-end security solutions, more especially, cryptography based mechanisms are deployed against SCADA security issues but are limited, in terms of SCADA multicasting communication. As a consequence, a generic cryptography base solution is developed and deployed in distributed network protocol (DNP3), as a part of SCADA system. The bytes are multicast form main controller to subcontrollers, and subcontrollers are configured to collect information from connected sensors, in water pumping system.

This study shows a new development, in which, security is deployed inside protocol stack and then bytes are multicast to subcontrollers. An immense testbed has been designed to measure the comprehensive security results and further compared with other performances. The computed performance results analyzed that the proposed security implementation has great resistance to protect SCADA/DNP3 multicasting communication. The security performances are validated against attacks detection percentage and attacks impact percentage, which evaluate the significant security enhancement(s).

In future development, an intelligent key distribution approach should be applied which distribute the keys among SCADA nodes via secured channel(s) and current security solution via cryptography mechanism would be tested in SCADA/DNP3 broadcasting communication, where number of subcontrollers are configured and connected to receive the bytes from main controller(s). Cloud computing platform is considered as most scalable and reliable for SCADA system; therefore a cloud based SCADA computing approach will require that make SCADA system more efficient and cost effective while comparing with existing developments.

Footnotes

Conflict of Interests

The authors declare that there is no conflict of interests regarding the publication of this paper.

Acknowledgment

This work was supported by Institute for Information & Communications Technology Promotion (IITP) grant funded by the Korea government (MSIP) (no. 10044457, Development of Autonomous Intelligent Collaboration Framework for Knowledge Bases and Smart Devices).

References

Stouffer

Falco

Kent

Guide to Supervisory Control and Data Acquisition (SCADA) and Industrial Control Systems Security 2006

Recommendations of the National Institute of Standards and Technology

http://www.cyber.st.dhs.gov/docs/NIST%20.pdf

Clarke

Reynders

Wright

Practical Modern SCADA Protocols: DNP3, 60870.5 and Related Systems 2004 https://www.fer.unizg.hr/_download/repository/Practical_modern_SCADA_protocols_-_dnp3,_60870-5_and_Related_Systems.pdf

SEP

Information security challenges in the electric power industry

White Paper 2003

SEP

http://www.ornl.gov/~webworks/cppr/y2001/misc/124326.pdf

Ten

C.-W.

Liu

C.-C.

Manimaran

Vulnerability assessment of cybersecurity for SCADA systems

IEEE Transactions on Power Systems 2008 23 4 1836 1846

10.1109/tpwrs.2008.2002298

2-s2.0-67349092535

Fovino

I. N.

Masera

Guidi

Carpi

An experimental platform for assessing SCADA vulnerabilities and countermeasures in power plants

Proceedings of the 3rd International Conference on Human System Interaction (HSI ′10)

May 2010

679 686

10.1109/hsi.2010.5514494

2-s2.0-77955698013

Amanullah

M. T. O.

Kalam

Zayegh

Network security vulnerabilities in SCADA and EMS

Proceedings of the IEEE/PES Transmission and Distribution Conference and Exhibition: Asia and Pacific

2005

Dalian, China

IEEE

1 6

10.1109/TDC.2005.1546981

Markovic-Petrovic

J. D.

Stojanovic

M. D.

Analysis of SCADA system vulnerabilities to DDoS attacks

Proceedings of the 11th International Conference on Telecommunications in Modern Satellite, Cable and Broadcasting Services (TELSIKS ′13)

October 2013

Niš, Serbia

IEEE

591 594

10.1109/telsks.2013.6704448

2-s2.0-84893547935

Igure

V. M.

A taxonomy of security vulnerabilities in scada protocols [Ph.D. thesis] 2007

Charlottesville, Va, USA

University of Virginia

Advisor: R. D. Williams, AAI3239979

Fernandez

J. D.

Fernandez

A. E.

SCADA systems: vulnerabilities and remediation

Journal of Computing Sciences in Colleges 2005 20 4 160 168

10.

Rrushi

J. L.

Lopez

Setola

Wolthusen

S. D.

SCADA protocol vulnerabilities

Critical Infrastructure Protection 2012

Berlin, Germany

Springer

150 176

11.

Chan

Gligor

V. D.

Perrig

Muralidharan

On the distribution and revocation of cryptographic keys in sensor networks

IEEE Transactions on Dependable and Secure Computing 2005 2 3 233 247

10.1109/tdsc.2005.37

2-s2.0-27644488112

12.

Robles

R. J.

Kim

T. H.

An encryption scheme for communication internet SCADA components

Communications in Computer and Information Science 2010 74 56 64

10.1007/978-3-642-13346-6_6

2-s2.0-77957961229

13.

Robles

R.-J.

Balitanas

Caytiles

Gelogo

Kim

T.-H.

Comparison of encryption schemes as used in communication between SCADA components

Proceedings of the International Conference on Ubiquitous Computing and Multimedia Applications (UCMA ′11)

April 2011

115 118

10.1109/ucma.2011.33

2-s2.0-84860456861

14.

Irshad

Sher

Faisal

M. S.

Ghani

Ul Hassan

Ashraf Ch

A secure authentication scheme for session initiation protocol by using ECC on the basis of the Tang and Liu scheme

Security and Communication Networks 2014 7 8 1210 1218

10.1002/sec.834

15.

Robles

R. J.

Balitanas

Kim

T.-H.

Security encryption schemes for internet SCADA: comparison of the solutions

Security-Enriched Urban Computing and Smart Grid 2011 223

Berlin, Germany

Springer

19 27 Communications in Computer and Information Science

10.1007/978-3-642-23948-9_4

16.

Lim

Lee

Park

Equivalent public keys and a key substitution attack on the schemes from vector decomposition

Security and Communication Networks 2014 7 8 1274 1282

10.1002/sec.860

17.

Kang

D.-J.

Kim

H.-M.

A proposal for key policy of symmetric encryption application to cyber security of KEPCO SCADA network

Proceedings of the International Conference on Future Generation Communication and Networking (FGCN ′07)

December 2007

609 613

2-s2.0-52249106931

18.

Pal

Saiwan

Jain

Saquib

Patel

Cryptographic key management for SCADA system: an architectural framework

Proceedings of the International Conference on Advances in Computing, Control and Telecommunication Technologies (ACT ′09)

December 2009

169 174

10.1109/act.2009.51

2-s2.0-77949276682

19.

Pietre-Cambacedes

Sitbon

Cryptographic key management for SCADA systems—issues and perspectives

Proceedings of the 2nd International Conference on Information Security and Assurance (ISA ′08)

April 2008

156 161

10.1109/isa.2008.77

2-s2.0-51349131393

20.

Chan

Perrig

Song

Random key predistribution schemes for sensor networks

Proceedings of the IEEE Symposium on Security and Privacy (SP ′03)

May 2003

IEEE Computer Society

197 213

2-s2.0-0038487088

21.

Guan

A key pre-distribution scheme using deployment knowledge for wireless sensor networks

Proceedings of the 4th International Symposium on Information Processing in Sensor Networks (IPSN ′05)

April 2005

IEEE

261 268

10.1109/ipsn.2005.1440934

2-s2.0-33744945781

22.

Patel

S. C.

Secure internet-based communication protocol for scada networks [Ph.D. thesis] 2006

Louisville, Ky, USA

University of Louisville

Advisor: J. H. Graham, AAI3228051

23.

Musa

Aborujilah

Secure security model implementation for security services and related attacks base on end-to-end, application layer and data link layer security

Proceeding of the Proceedings of the 7th International Conference on Ubiquitous Information Management and Communication (ICUIMC ′13)

January 2013

Kota Kinabalu, Malaysia

10.1145/2448556.2448588

24.

Robles

R. J.

Kim

T.-H.

Encryption schemes applied in SCADA components communication: summary

Information 2012 15 3 1241 1252 http://ecite.utas.edu.au/8309

25.

Shahzad

Musa

Irfan

N-secure cryptography solution for SCADA security enhancement

Trends in Applied Sciences Research 2014 9 7 381 395

10.3923/tasr.2014.381.395

26.

Graham

Patel

Security considerations in SCADA communication protocols

2004 TR-ISRL-04-01

Intelligent Systems Research Laboratory

27.

Fujisaki

Okamoto

Secure integration of asymmetric and symmetric encryption schemes

Advances in Cryptology—CRYPTO′99 1999 1666

Berlin, Germany

Springer

537 554 Lecture Notes in Computer Science

10.1007/3-540-48405-1_34

28.

Saxena

Pal

Saquib

Public key cryptography based approach for securing SCADA communications

Communications in Computer and Information Science 2011 142 56 62

10.1007/978-3-642-19542-6_10

2-s2.0-79953002631

29.

Hieb

Graham

Patel

Security enhancements for distributed control systems

Critical Infrastructure Protection 2008 253

New York, NY, USA

Springer

133 146 IFIP International Federation for Information Processing

10.1007/978-0-387-75462-8_10

30.

Patel

S. C.

Bhatt

G. D.

Graham

J. H.

Improving the cyber security of SCADA communication networks

Communications of the ACM 2009 52 7 139 142

10.1145/1538788.1538820

2-s2.0-67651162241

31.

Patel

S. C.

Secure internet-based communication protocol for scada networks [Ph.D. thesis] 2006

Louisville, Ky, USA

University of Louisville

32.

Coates

G. M.

Hopkinson

K. M.

Graham

S. R.

Kurkowski

S. H.

Collaborative, trust-based security mechanisms for a regional utility intranet

IEEE Transactions on Power Systems 2008 23 3 831 844

10.1109/tpwrs.2008.926456

2-s2.0-49249110834

33.

Davis

C. M.

Tate

J. E.

Okhravi

Grier

Overbye

T. J.

Nicol

SCADA cyber security testbed development

Proceedings of the 38th Annual North American Power Symposium (NAPS ′06)

September 2006

IEEE

483 488

10.1109/naps.2006.359615

2-s2.0-48449088699

34.

Falk

Securing IEC 61850

Proceedings of the IEEE Power and Energy Society 2008 General Meeting: Conversion and Delivery of Electrical Energy in the 21st Century (PES ′08)

July 2008

10.1109/pes.2008.4596335

2-s2.0-52349117043

35.

Coates

G. M.

Hopkinson

K. M.

Graham

S. R.

Kurkowski

S. H.

A trust system architecture for SCADA network security

IEEE Transactions on Power Delivery 2010 25 1 158 169

10.1109/tpwrd.2009.2034830

2-s2.0-73849140062

36.

Shahzad

Musa

Irfan

Asadullah

Deployment of new dynamic cryptography buffer for SCADA security enhancement

Journal of Applied Sciences 2014 14 20 2487 2497

10.3923/jas.2014.2487.2497

37.

https://www.trianglemicroworks.com/support/test-harness

38.

Kang

D. J.

Kim

H. M.

Development of test-bed and security devices for SCADA communication in electric power system

Proceedings of the 31st International Telecommunications Energy Conference (INTELEC ′09)

October 2009

10.1109/intlec.2009.5351774

2-s2.0-77950150561

39.

Kang

D.-J.

Lee

J.-J.

Kim

S.-J.

Park

J.-H.

Analysis on cyber threats to SCADA systems

Proceedings of the Transmission & Distribution Conference & Exposition: Asia and Pacific

October 2009

Seoul, Republic of Korea

IEEE

1 4

10.1109/TD-ASIA.2009.5357008

40.

Kiuchi

Serizawa

Security technologies, usage and guidelines in SCADA system networks

Proceedings of the International Joint Conference (ICCAS-SICE ′09)

August 2009

4607 4612

2-s2.0-77951139582

41.

Sugwon

Lee

Shin

Experiments for embedded protection device for secure SCADA communication

Proceedings of the Power and Energy Engineering Conference (APPEEC ′10)

March 2010

Chengdu, China

10.1109/APPEEC.2010.5448606

42.

Risley

J. R.

Ladow

Electronic Security of Real-Time Protection and Scada Communications 2003

Schweitzer Engineering Laboratories

https://www.selinc.com/WorkArea/linkit.aspx

43.

Queiroz

Mahmood

A. N.

Tari

Building a SCADA security testbed

Proceedings of the 3rd International Conference on Network and System Security (NSS ′09)

October 2009

Gold Coast, Australia

IEEE

357 364

10.1109/nss.2009.82

2-s2.0-72849150312

The Sensors Connectivity within SCADA Automation Environment and New Trends for Security Development during Multicasting Routing Transmission

Abstract

1. Introduction

2. Problem Statement

3. SCADA Simulation Environment

4. SCADA Testbed Setup and Configuration

4.1. Multicasting Routing

5. Security Design and Implementation

Proof (security development).

6. Performance Evaluation and Comparison

7. Literature Survey

8. Conclusion and Future Work

Footnotes

Conflict of Interests

Acknowledgment

References