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

Authors: Aamir Shahzad; Kalum Priyanath Udagepola; Young-keun Lee; Soojin Park; Malrey Lee
Journal: International Journal of Distributed Sensor Networks
 (2015)

---

## 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.


---

## Body

## 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 Section2, 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 Figure1), 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 Figure2), 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 Figure2), 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).


## 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 Figure2), 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 Table1, 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 methodIn Figure3, 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 usedFigure 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 Figure4, 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 thatRequest: 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 Figure5. 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 iny-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. Onx-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 onx-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 Figures8, 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 Figure9, 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) “bdy” and cryptography functions such as symmetric encryption “Symf” using AES algorithm and hashing “Hf” 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:(1)∃:∀μSm,H,EkAL:Eyi←urb,E→Symf,H→HfAL∃:∀XAL⁡α=∧·∑i←urb,f→fnlim←k∃:∀μSAL⁡fn:Xf→fnAL⁡∥fn:fn:Xbdy,f→fnAL⁡.
Application Layer. Decryption process is as follows:(2)∃:∀μRm,H,EkAL:Dyi←urb,D→Symf,H→HfAL⁡Eyi←urb,E→Symf,H→HfAL⁡·∑i←urb,f→fnlim←k∃:∀μSAL⁡fn:Xf→fnAL⁡∥fn:fn:Xbdy,f→fnAL⁡.
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 “Hf” 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:(3)H∃:∀QTLα=∧·∑i←urb,f→fnlim←k∃:∀αSTLfn:Qf→fnTL∥fn:fn:Qbdy,f→fnTL∈hdigestS.
Transport Layer. Decryption process is as follows:(4)H∃:∀QTLα=∧·∑i←urb,f→fnlim←k∃:∀αSTLfn:Qf→fnTL∥fn:fn:Qbdy,f→fnTL∈hdigestS=H∃:∀QTLα=∧·∑i←urb,f→fnlim←k∃:∀αRTLfn:Qf→fnTL∥fn:fn:Qbdy,f→fnTL∈hdigestR,equal hash values.
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 “Symf” using AES algorithm and hashing “Hf” 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:(5)∃:∀βSm,H,EkDL:Eyi←urb,E→Symf,H→HfDL∃:∀JDLα=∧·∑i←urb,f→fnlim←k∃:∀βSDLfn:Jf→fnAL⁡∥fn:fn:Jbdy,f→fnDL.
Data Link Layer. Decryption process is as follows:(6)∃:∀βRm,H,EkDL:Dyi←urb,D→Symf,H→HfDLEyi←urb,E→Symf,H→HfDL·∑i←urb,f→fnlim←k∃:∀βSDLfn:Jf→fnAL⁡∥fn:fn:Jbdy,f→fnDL.


## 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 Figure14, 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 Figure12. 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 Figure8, 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 Figure8 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.



---

*Source: 738687-2015-10-26.xml*