See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/277014023

The Sensors Connectivity within SCADA Automation Environment and New

Trends for Security Development during Multicasting Routing Transmission

Article  in  International Journal of Distributed Sensor Networks · September 2015

DOI: 10.1155/2015/738687

CITATIONS READS

7 2,324

5 authors, including:

Aamir Shahzad Kalum Priyanath Udagepola

National University of Medical Sciences 48 PUBLICATIONS   45 CITATIONS   
44 PUBLICATIONS   480 CITATIONS   
SEE PROFILE
SEE PROFILE

Young Keun Lee Soojin Park

Chonbuk National University Sogang University
39 PUBLICATIONS   293 CITATIONS    38 PUBLICATIONS   149 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Research on Water for various hot topics through Remote Sensing Data View project

Digital Globe for Sustainable Development of Country View project

All content following this page was uploaded by Kalum Priyanath Udagepola on 07 June 2015.

The user has requested enhancement of the downloaded file.

The Sensors Connectivity within SCADA Automation Environment and New
Trends for Security Development during Multicasting Routing Transmission
Aamir Shahzad1, Kalum Priyanath Udagepola2, Young-keun Lee3, Soojin Park4 and
Malrey Lee5
1
mail2aamirshahzad@gmail.com,2kudagepola@kau.edu.sa,3trueyklee@naver.com(corresp
onding author), 4psjdream@gmail.com, 5mrlee@jbnu.ac.kr(corresponding author)
1,5
561-756, Center for Advanced Image and Information Technology, School of Electronics &
Information Engineering, Chon Buk National University, 664-14, 1Ga, Deokjin-Dong, Jeonju,
ChonBuk, Korea
2
Department of Information Systems, King Abdulaziz University, North Branch, PO Box 80327,
Jeddah 21589, Saudi Arabia
3
Department of Orthopedic Surgery, Chonbuk National University Hospital, Jeonju, Jeonbuk ,
Korea
4
Graduate Scool of MOT/ Sogang Institute of Advanced Technology, Sogang University, Seoul,
Korea

ABSTRACT
Nowadays, modern SCADA system provides communication facilities including unicasting,
multicasting, broadcasting and others, between connected sensors-nodes, which may, are located
geographical at distance place, over internet. In existing survey, few end-to-end security
techniques are employed against SCADA security enhancements during multicasting
transmission. The security developments, more especially, the cryptography techniques are
entirely strenuous, and time consuming for SCADA multicasting communication while
comparing with unicasting communication. The proposed research work is twofold: a SCADA
simulation environment is designed for water pumping process, through sensors which check the
water incoming/outgoing pressure, water level, cooling pints, heating points, and others, and all
input/output points are supervised by sensors-nodes, designated as sub-controllers.
Subsequently, the current study reviews the existing SCADA security developments and deploys
a cryptography base security solution within SCADA multicasting communication. Usually,
cryptography based developments have great potential to secure any type of communication, but
in-case of SCADA system; these developments are counted as complex approaches due to
algorithms computation, and its related heavy session(s). Therefore, the existing cryptography
based security performances have been reviewed and a generic security solution is proposed, and
deployed within distributed network protocol (DNP3) stack. The security bytes are transmitted
in sensors-multicasting transmission, as a part of SCADA system, with minimal performance
impact, and significant security enhancement.

Keywords: Supervisory Control and Data Acquisition, Sensors-nodes, Distributed Network

Protocol, Multicasting Routing, Cryptography.

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 [8]. 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 [8], [9]. In few cases, SCADA system provides broadcasting service,
such that, bytes are broadcast to each and every node within configured network. The
2

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 un-aware during transmission [9], [10].
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 [23—31]. To minimize the security issues of
SCADA communication, several end-to-end security developments have been made and
commercial software’s are employed [1—4], [8], [15], [19]. In SCADA systems, numbers of
cryptography keys are distributed among nodes followed by SCADA communication
requirements [31—35], 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[1—4], [36]. Encryption based security approaches are considered as best
approaches to hide the sensitive information of SCADA systems against adversaries [3], [5],
[17], [19], [36—40]; 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 compared with cryptography based approaches [5, 41—43].
In researches papers [5],[9],[37], 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 [11],[12],[41],[42]. 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 [5]. In other researches [37],[42],[43],
the using of commercial security software’s in SCADA systems are considered in-appropriated
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)
[15],[19]. The hashing algorithm is accounted as a best security approach in SCADA
transmission or/and SCADA protocols transmission [5], [42]. 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 match then
payload is accepted otherwise reject, and corresponding conformation is replied [37], [42].
Usually, SCADA system provides two types of communication facilities: balance and
unbalance, depending on protocol uses [9], [10]. Distributed network protocol (DNP3) is a most
popular protocol, which has been employed by SCADA systems. DNP3 protocol has four layers
in its stack including application layer, pseudo-transport layer, data link layer and physical layer.
In each layer, message size is limited up to 2048-bytes; 250bytes; 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 initiates the communication with main node; while in balance
3

system, only main node is authorized to initiates the communication with connected sub-nodes
in SCADA system [8—10]. The basic configuration and specifications are required either master
send request to sub-node or/and sub-node initiates the communication, is decided at application
layer of DNP3 protocol [20], [21]. 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 follow. 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. Especially, in the case of warm traffic or abnormal
scenario, in which, the attacker successfully gains the control on, distinguish sensors-controllers
and other SCADA sensors-controllers are remained same or normally communicate with main
controller. The main controller analyzes the abnormal communication within network system
and 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 shutdown or off. In
this scenario, whole SCADA transmission is suffered included with normal sensors-controllers,
which significantly effects the critical communication or SCADA system communication. The
overall transmission is down until system recovery, which is most dangerous situation for
critical infrastructures such as electrical stations, water pumping and controlling stations, aircraft
controlling systems and others [9], [10].
Research Objectives: The research objective of this study is fourfold:
i. The SCADA communication is persuaded to multicasting communication, and its
security directions which will be helpful to handle the abnormal scenarios.
ii. Several security mechanisms such as, object security, security pattern techniques,
TLS/SSL, SSH, IPSec, encryption and other end-to-end security approaches, have
been deployed against SCADA systems vulnerabilities, and it communications in-
securities, other issues [1—5], [38—42]. By analyzing of existing survey; the DNP3
protocol stack is designed and security solution via cryptography is deployed, with
SCADA/DNP3 transmission acquirements in mind during bytes multicasting.
iii. The proposed security development is made in SCADA/DNP3 sensor network and
validated by formal proofs.
iv. The attacks scenarios are conducted to compute the performances and for evaluation
purposes.

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 in industrial processes. In simulation environment (in figure 1), SCADA main
controller monitors the whole water pumping system through configured sub-controllers. 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
Figure 1. SCADA/DNP3 Supervisory Environment: Water Pumping System
5

intelligent-sensors are directly connected with local water storages, which check/monitor the
water pressure status; an 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) are turn off
and sub-controllers 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/sub-controller set points.
At 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/sub-controller set points. The
overall information is processed by the means of configured sensors; the sub-controllers read the
information from sensors, then, this information is process to main controller for monitoring
purposes[5], [37], [41],[42].

4. SCADA TESTBED SETUP AND CONFIGURATION

In SCADA testbed (in figure 2), six remote stations (or sub-controllers), plus sensor-
controller node (or RTU1) which is treated as rendezvous point (RP) are configured with main
controller. Three sub-controllers such as RTU2, RTU3 and RTU7, are individually connected to
supervise [5], [36—39], [40—42] and control the water heating processes including, water
incoming/outgoing pressure, water level, cooling level and electricity consumption. While, the
remaining sub-controllers 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. At 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 sub-controllers, and monitoring
purposes. In this study, a simulation base water pumping system is designed in first phase, and
in 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

6

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 [5],
[36—39],. In testbed setup (in figure 2), seven sub-controllers are configured with main
controller or main node via four routers. The overall connectivity between sub-controllers and
main controller is statically configured, meaning that, all sub-controllers 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 setups the directions
called distribution tree between main controller, and sub-controllers 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 indentifies 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 sub-controllers, the router lookup table is
updated with specified sub-controllers list via main controller and the remaining nodes in table
are voided by router. All routers are configured statically with specified sub-controllers, but the
router ‘R1’ connected directly with main controller is updated each time based on main
controller selection process for multicasting sub-controllers. When a router receives the
multicasting packets according to main controller selection process, the router forwards the
packets to sub-controllers of multicasting group, in connected network(s).

5. SECURITY DESIGN AND DEVELOPMENT WITH CDB

SCADA/DNP3 stack has been designed and security is deployed within each layer
including application layer, pseudo-transport 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 figure 3, 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, cryptography
(bytes): dynamic storage (bytes), option (bytes), padding or dynamic bytes, acknowledgment,
non-critical (bytes), critical (bytes), and solution or select method, are belonging to CDB, which
performs distinct functions during security development [5], [22].
7

Figure 3. 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 [22].

In figure 4, each time message has been multicast from main controller to sub-controllers
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 sub-controller has two secret keys during
security deployment, plus 3-way-hashing. The performance figure 6 shows the bytes allocation,
and utilization during message designed, 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 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 sub- controllers 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 [5], [22], [37]. Table 1
shows the detail of CDB field’s, and corresponding bytes detail.

Figure 4. 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 non-repudiation test
is a limitation of this study, due to transmission limitations. The public key cryptography is not appropriates for
SCADA/DNP3 multicasting transmission, but should be used in unicasting communication.
In figure 5, 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, show the complete DNP logical stack, with security bytes. The
8

highlighted bytes in DNP stack; the bytes: 0x00c3 and 0x00c1 are representing the application
layer header bytes; the byte ‘0x001c’ is representing the pseudo-transport 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 pseudo-transport 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
constructed in DNP3 stack or each layer of DNP3 stack and the shaded area show that the space
is empty, and this would be filled up in-case of 1992 user bytes are constructed, and manipulated
in application layer.

No. Field Name Occupied Description

Bytes
1. Source Address and Port 2 bytes External field representing the main controller address during
multicasting transmission or in-case of response from each
sub-controller.
2. Destination Multicasting 4 bytes Representing the multicasting addresses of selected sub-
Addresses and Ports controllers.
3. User Bytes 2 bytes Keep the information of protocol constructed bytes.
4. Cryptography Key 4 bytes Cryptography keys are employed with distinct number’s, and
Sequence counted, in this field.
5. Cryptography: Dynamic 22--56 Information is updated and bytes are dynamically in/out,
Storage bytes 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/Sub-controller acknowledgment message.
9. Critical 1 byte Show the status of abnormal entity.
10. Non- Critical 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.
Table 1. CDB Dynamic Fields with Allocated Bytes.
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 sub-
controller (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). At 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 >
9

In another example, main controller wants to execute the cold_restart, and warm_restart
functions using codes: 0D and 0E. In response, sub-controllers 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 sub-controller is responses with distinct
sequence number. Application control (AC) field contains 5 bits sub-field called sequence, plus
1 bit of confirmation. Therefore, each sub-controller is responses to main controller using
distinct sequence numbers, from 0 to 15.

Figure 5. 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.
5.1 Communication Flows
The more concise flow of SCADA/DNP3 system is illustrated below. In multicasting flow,
DNP3 protocol bytes are constructed in each layer, and corresponding functions are manipulated
followed by request and response messages [37], [44]. 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 RTU 3, RTU4, RTU6 and RTU 7 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 in integrated window.
10

SCADA/DNP3Communication: Bytes Flow during Multicasting

11

SCADA/DNP3Communication: Bytes Flow during Request/Response Messages

12

5.2 Security Proof

The ‘X’ is application layer constructed bytes and ‘ ’ is a function that performs the
encryption on bytes ‘X’. The total constructed bytes from application layer have been added
in cryptography dynamic buffer (CDB) ‘ ’ and cryptography functions such as symmetric
encryption ‘ ’ using AES algorithm and hashing ‘ ’ using SHA-2 are performed on bytes.
Upon receiving, decryption function is performed using the shared keys with
sender/receiver hash digests.
Application Layer: Encryption Process

Application Layer: Decryption Process

The ‘Q’ is pseudo-transport layer constructed bytes and ‘ ’ is a function that performs the
hashing on bytes ‘Q’. The total constructed bytes from pseudo-transport layer have been added
in cryptography dynamic buffer (CDB) and hashing function ‘ ’ 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

Transport Layer: Decryption Process

==

, equal hash values.

The ‘ ’ is data link layer constructed bytes and ‘ ’ is a function that performs the encryption
on bytes ‘ ’. The total constructed bytes from data link layer have been added in
cryptography dynamic buffer (CDB) and cryptography functions such as symmetric encryption
‘ ’using AES algorithm and hashing ‘ ’ using SHA-2 are performed on bytes. Upon
13

receiving, decryption function is performed using the shared keys with sender/receiver
hash digests.

Data Link Layer: Encryption Process

Data Link Layer: Decryption Process

5.3 Performance Measurements

In this section, attacks scenarios are conducted that make interruption in-between of
SCADA/DNP3 transmission during message exchanging between main controller and remote
terminal units (RTUs) or/and vice versa. In performance figure 6, random bytes are transmitted
between nodes in SCADA/DNP3 network and the status of bytes allocation and utilization are
measured. In performance figures 7—11, several times attacks are launched that designated as
attackers of system, and corresponding performances are measured via distinct approaches. The
distinct approaches are employed that make best selection among them via performance
comparison process, and also employed for performance evaluation purposes. In performance
figure 12, approximate latency is measured during multicasting of messages from main
controller to remote terminal units (RTUs). All related details of computed results are described
with performance figures (or performance figures 6—11).

Figure 6. 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 sub-controller(s). The blue color lines show the bytes utilized during
application layer message construction, red lines show the pseudo-transport 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.
14

Figure 7. Attack Detection against SCADA/DNP3Stack 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, 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 uiflowed lines show the normal transmission during bytes multicast from main controller, in-between, attacks
are detected and then, bytes follow the normal sequence. In x-axis, 94 experiments are sampled (or collected) from
total experiments which showed the most approximate performances, and sequence is used from 1—94. Total 18
experiments are not labeled because; these experiments are used for special purposes.

Figure 8. Attack Detection (Partially) against SCADA/DNP3Stack Security: These are attacks, which 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 in x-axis is same as figure 7 experiments, with same data rates but distinct attack locations. The
partially detected attacks are separately graphed which show the difference with fully detected attacks (in figure 7).
15

Figure 9. 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,
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 figure 7, figure 8, figure 10 and figure 11. In y-axis, random bytes are multicast
and security is implemented, and tested at each end of communication nodes. Security tests such authentication,
integrity and confidentiality, are performed and level of attacks detection is computed. As performance of figure 7,
94 best experiments are sampled (or collected) from total experiments which show the most approximate
performance results, and sequence is used from 1—94. Total 18 experiments are not labeled because; these
experiments are used for special purposes.

Figure 10. Attack Detection (Partially) against SCADA/DNP3 End-to-End Security: As performance of figure 8,
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 in x-axis is same as figure 9
experiments, with same data rates but distinct attack locations. The partially detected attacks are separately graphed
which create the difference with fully detected attacks (in figure 9).
16

Figure 11. Attack Detection against SCADA/DNP3 Testbed without Security Development: The same
measurement phenomenon is followed from performance figure 7, with 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 fully attacks detection rather than
partially detection. These results are used during performance comparison, with figures 7 and 9.

Figure 12. Average Latency during Multicasting: Experiments are performed to compute the average latency
during multicasting of bytes to sub-controllers such as RTU2, RTU3, RTU4, RTU5, RTU6, and RTU7. The sub-
controllers are not labeled in ascending order; the sequence is followed by performance figure 7 and then, sub-
controllers 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 12)
and blue lines show the dummy multicasting transmission flow. As conclusion, the overall measured average
latency is under the range of real time communication.
17

6. PERFORMANCE EVALUATION AND COMPARISON

Number of times testbed experiments have been run and 94 experiments are individually
selected to perform each security test. In each 94 experiments, 12 experiments are employed,
and specified for acknowledgment, while required from sub-controllers; 2 experiments are used
to check the transmission errors, and flow; 4 experiments are used, and specified for
acknowledgment, while 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 13, the total attacks detection is 11% by adding 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 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 11. The total attacks
detection, and attacks impact is 95% and corresponding security is 5% which shows high
difference, while comparing with other two cases. In this study, overall results are computed as
approximate measurements, and also compared with existing works [1—5], [15], [17], [19]. As
conclusion, the proposed development has great potential to secure the SCADA/DNP3
multicasting communication, which does not intended by existing developments [7], [10—14],
[16], [18], [20], [21].
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.

Figure 13. Performance Evaluation and Comparison

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[1—5],[15].The cryptography base
approaches are counted as, an important developments against SCADA security issues which
18

significantly reduce 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 [16],[17], [38—42]. A peer-to-peer security is deployed for SCADA system, by
using of cryptography mechanism; cryptography keys are generated, and distributed among sub-
controllers during encryption/decryption processes. As results, significant security is measured
during SCADA transmission, but overall, performance results are limited to peer-to-peer
communication [2], [4]; the security development does not directed to SCADA multicasting
communication (in which, main controller send the encrypted message to several sub-
controllers, at same time) , due to several limitations and complicities during cryptography
deployment [4],[5], [14].
Larger number of vulnerabilities has been raised, while employing of advance information
and communication technology (ICT) and usage of open networks/protocols, in SCADA
systems [11], [13]. 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; and then,
countermeasures are provided for protocols such as TCP/IP, DNP3, AGA 12 and Modbus,
which give significant protection against attacks/threads [18], [19]. A simulation has been
designed that monitors and controls the SCADA field devices via Modbus protocol [6], [7]. The
results are also measured that show warm performance impact of attacks/threads on SCADA
system [8], [12].

8. CONCLUSION AND FUTURE WORK

In SCADA system, field devices or (sensors-controllers) are connected geographically, at
several locations, and monitor 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 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 sub-controllers, and sub-controllers 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 sub-controllers. An immense testbed has 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 sub-controllers 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.

9. ACKNOWLEDGMENT
This research was supported by next generation information computing development
program through the national research foundation of korea fundeded by the ministry of science,
ICT & Future Planning (2012M3C4A7033348).
 19

10. REFERENCES
[1] Rosslin John Robles and Tai-hoon Kim,2010, An Encryption Scheme for Communication
Internet SCADA Components, Communications in Computer and Information
Science Volume 74, pp 56-64, DOI:10.1007/978-3-642-13346-6_6
[2] Robles, R.-J. and Balitanas, 2011, Comparison of Encryption Schemes as Used in
Communication between SCADA Components, Ubiquitous Computing and Multimedia
Applications (UCMA), DOI: 10.1109/UCMA.2011.33
[3] Azeem Irshad, Muhammad Sher and Muhammad Shahzad Faisal, 2014, A secure
authentication scheme for session initiation protocol by using ECC on the basis of the Tang
and Liu scheme, Security Comm. Networks, 7, 1210–1218, doi:10.1002/sec.834
[4] Rosslin John Robles, Maricel Balitanas and Tai-hoon Kim, 2011, Security Encryption
Schemes for Internet SCADA: Comparison of the Solutions, Communications in
Computer and Information Science, Volume 223, pp 19-27, DOI: 10.1007/978-3-642-
23948-9_4
[5] Musa, A. and A.Aborujilah, 2013, Secure security model implementation for security
services and related attacks base on end-to-end, application layer and data link layer
security, Proceeding ICUIMC '13 Proceedings of the 7th International Conference on
Ubiquitous Information Management and Communication, DOI:10.1145/2448556.2448588
[6] Queiroz, C.Mahmood, A. Naser, Hu, Jiankun, Tari, ZahirZahirandYu, Xinghuo, 2009,
Building a SCADA Security Testbed,Network and System Security, NSS '09, Third
International Conference, IEEE, DOI:10.1109/NSS.2009.82
[7] Kang, D.J.Kim and H.M. Man, 2009, Development of Test-bed and Security Devices for
SCADA Communication in Electric Power System, 31st International Telecommunications
Energy Conference, INTELEC, IEEE, DOI:10.1109/INTLEC.2009.5351774
[8] Stouffer.K , J. Falco and K. Kent, 2006, Guide to Supervisory Control and Data
Acquisition (SCADA) and Industrial Control Systems Security, Recommendations of the
National Institute of Standards and Technology,
http://www.cyber.st.dhs.gov/docs/NIST%20.pdf
[9] Clarke.G, D. Reynders and E. Wright, 2004, Practical Modern SCADA Protocols: DNP3,
60870.5 and Related Systems,
www.fer.unizg./Practical_modern_SCADA_protocols_dnp3,_60
[10] SEP, 2003, Information Security Challenges in the Electric Power Industry, White Paper
http://www.ornl.gov/~webworks/cppr/y2001/misc/124326.pdf
[11] Coates, G. M.Hopkinson, K.M., Graham, S. R., Kurkowski,& S.H, 2008, Collaborative,
Trust-Based Security Mechanisms for a Regional Utility Intranet, Power Systems, IEEE
Transactions, Volume:23, Issue: 3,DOI: 10.1109/TPWRS.2008.926456
[12] Davis, J. E. Tate, H. Okhravi, C. Grier, T. J. Overbye, & D. Nicol,2006, SCADA Cyber
Security Testbed Development, Power Symposium, NAPS, 38th North American,
IEEE,DOI:10.1109/NAPS.2006.359615
[13] Kang, D.J.Lee, J.Joo, Kim, S.J. Joo, Park, & J.H. Hyuk,2009, Analysis on cyber threats to
SCADA systems, Transmission & Distribution Conference & Exposition: Asia and Pacific,
IEEE,DOI:10.1109/TD-ASIA.2009.5357008
[14] Kiuchi, M. Serizawa, & Yoshizumi,2009, Security technologies, usage and guidelines in
SCADA system networks, ICCAS-SICE, IEEE,IAN: 10982993
[15] Seongan Lim, Eunjeong Lee, and Cheol-Min Park , 2014, Equivalent public keys and a key
Substitution attack on the schemes from vector decomposition, Security Comm. Networks,
7, 1274–1282, DOI: 10.1002/sec.860
 20

[16] Hong &Sugwon, 2010, Experiments for Embedded Protection Device for Secure SCADA
Communication, Power and Energy Engineering Conference
(APPEEC),DOI:10.1109/APPEEC.2010.5448606
[17] Robles, R., Kim and T.H, 2012, Encryption Schemes Applied in SCADA Components
Communication, 15, (3) pp. 1241-1252. ISSN 1344-8994,Refereed Article, University of
Tasmania,http://ecite.utas.edu.au/8309
[18] Risley, J. Roberts, & P. Ladow, 2003, Electronic Security Of Real-Time Protection and
Scada Communications, Schweitzer Engineering Laboratories Inc,
https://www.selinc.com/WorkArea/linkit.aspx
[19] Kang & H. M. Kim, 2007, A Proposal for Key Policy of Symmetric Encryption Application
to Cyber Security of KEPCO SCADA Network, FGCN '07 Proceedings of the Future
Generation Communication and Networking ,Volume 02, DOI:10.1109/FGCN.2007.36
[20] Falk & Herbert, 2008, Securing IEC 61850, Power and Energy Society General Meeting -
Conversion and Delivery of Electrical Energy in the 21st Century, IEEE,
DOI:10.1109/PES.2008.4596335
[21] Coates, G. M.Hopkinson, K.M., Graham, S. R., Kurkowski, and S.H, 2010, A Trust System
Architecture for SCADA Network Security, Power Delivery, IEEE Transactions, Volume: 25
, Issue: 1, DOI:10.1109/TPWRD.2009.2034830
[22] Shahzad, S. and M. Irfan, 2014, Deployment of New Dynamic Cryptography Buffer for
SCADA Security Enhancement, Journal of Applied Sciences, DOI: 10.3923/jas.2014.2487.24
[23] Chee-Wooi Ten, Chen-Ching Liu, Manimaran, G., 2008, Vulnerability Assessment of
Cybersecurity for SCADA Systems, Power Systems, IEEE Transactions on , vol.23, no.4,
pp.1836,1846, Nov. 2008
doi: 10.1109/TPWRS.2008.2002298
[24] Fovino, I.N., Masera, M., Guidi, L., Carpi, G., 2010, An experimental platform for assessing
SCADA vulnerabilities and countermeasures in power plants, Human System Interactions
(HSI), 2010 3rd Conference on , vol., no., pp.679,686,
DOI: 10.1109/HSI.2010.5514494
[25] Amanullah, M.T.O., Kalam, A., Zayegh, A., 2005, Network Security Vulnerabilities in
SCADA and EMS, Transmission and Distribution Conference and Exhibition: Asia and
Pacific, 2005 IEEE/PES , vol., no., pp.1,6, DOI: 10.1109/TDC.2005.1546981
[26] Markovic-Petrovic, J.D., Stojanovic, M.D., 2013, Analysis of SCADA system vulnerabilities
to DDoS attacks, Telecommunication in Modern Satellite, Cable and Broadcasting Services
(TELSIKS), 2013 11th International Conference on , vol.02, no., pp.591,594, DOI:
10.1109/TELSKS.2013.6704448
[27] Vinay Mallikarjun Igure, 2007, A Taxonomy of Security Vulnerabilities in Scada Protocols,
Ph.D. Dissertation. University of Virginia, Charlottesville, VA, USA. Advisor(s) Ronald D.
Williams. AAI3239979.
[28] John D. Fernandez and Andres E. Fernandez, 2005, SCADA systems: vulnerabilities and
remediation. J. Comput. Sci. Coll. 20, pp. 160-168
[29] Julian L. Rrushi, 2012, SCADA protocol vulnerabilities, In Critical Infrastructure Protection,
Javier Lopez, Roberto Setola, and Stephen D. Wolthusen (Eds.). Springer-Verlag, Berlin,
Heidelberg 150-176.
[30] Chee-Wooi Ten, Chen-Ching Liu, Manimaran, G., 2008, Vulnerability Assessment of
Cybersecurity for SCADA Systems, Power Systems, IEEE Transactions on , vol.23, no.4,
pp.1836,1846, DOI: 10.1109/TPWRS.2008.2002298
 21

[31] Haowen Chan, Virgil D. Gligor, Adrian Perrig, and Gautam Muralidharan, 2005, On the
Distribution and Revocation of Cryptographic Keys in Sensor Networks, IEEE Trans.
Dependable Secur. Comput, 2005, pp.233-247, DOI:10.1109/TDSC.2005.37
[32] Pal, O., Saiwan, S., Jain, P., Saquib, Z., Patel, D., 2009, Cryptographic Key Management for
SCADA System: An Architectural Framework, Advances in Computing, Control, &
Telecommunication Technologies, ACT '09. International Conference on , vol., no.,
pp.169,174,2009, DOI: 10.1109/ACT.2009.51
[33] Pietre-Cambacedes, L., Sitbon, P., 2008, Cryptographic Key Management for SCADA
Systems-Issues and Perspectives, Information Security and Assurance, ISA 2008.
International Conference on , vol., no., pp.156,161,
DOI: 10.1109/ISA.2008.77
[34] Haowen Chan, Adrian Perrig, and Dawn Song, 2003, Random Key Predistribution Schemes
for Sensor Networks, In Proceedings of the 2003 IEEE Symposium on Security and
Privacy (SP '03). IEEE Computer Society, Washington, DC, USA
[35] Zhen Yu, Guan, Yong, 2005, A key pre-distribution scheme using deployment knowledge
for wireless sensor networks, Information Processing in Sensor Networks, 2005. IPSN 2005.
Fourth International Symposium on , vol., no., pp.261,268,
DOI: 10.1109/IPSN.2005.1440934
[36] Sandip Chunilal Patel, 2006, Secure Internet-Based Communication Protocol for Scada
Networks. Ph.D. Dissertation. University of Louisville, Louisville, KY, USA. Advisor(s)
James H. Graham. AAI3228051.
[37] Shahzad; S. Musa, M. Irfan, 2014, N-Secure Cryptography Solution for SCADA Security
Enhancement, Trends in Applied Sciences Research, 9: pp.381-395, DOI:
10.3923/tasr.2014.381.395
[38] J. Graham, S. Patel, 2004, Security considerations in SCADA communication protocols,
Intelligent Systems Research Laboratory, Tech. Rep. TR-ISRL-04-01
[39] Fujisaki E, Okamoto T., 1999, Secure integration of asymmetric and symmetric metric
encryption schemes, In Advances in Cryptology – CRYPTO'99, LNCS, Vol. 1666. Spring-
Verlag, pp.537–554.
[40] Anupam Saxena; Om Pal, Zia Saquib, 2011, Public Key Cryptography Based Approach for
Securing SCADA Communications, Computer Networks and Information Technologies,
Communications in Computer and Information Science Volume 142, pp 56-62
[41] Jeffrey Hieb, James Graham, Sandip Patel, 2008, Security Enhancements for Distributed
Control Systems, Critical Infrastructure Protection, IFIP International Federation for
Information Processing Volume 253, pp 133-14, DOI: 10.1007/978-0-387-75462-8_10
[42] Sandip C. Patel, Ganesh D. Bhatt, James H. Graham, 2009, Improving the cyber security of
SCADA communication networks. Commun, ACM 52, 7, pp.139-142, DOI:
10.1145/1538788.1538820
[43] Sandip Chunilal Patel, 2006, Secure Internet-Based Communication Protocol for Scada
Networks, Ph.D. Dissertation. University of Louisville, Louisville, KY, USA
[44] https://www.trianglemicroworks.com/support/test-harness

View publication stats