1 SCADA Communication Network Vulnerabilities

1.1 Introduction to SCADA network

The development of supervisory control and data acquisition (SCADA) can be traced back to the early 1900’s with the advent of
telemetry which involves the transmission and collection of data obtained by sensing real-time conditions. SCADA networks have
become popular since the 1960’s to control electrical and other infrastructure systems. As discussed in the introduction, the broad
architecture of SCADA involves receiving field-data collected by RTUs and controlling physical devices such as switches and
pumps by using RTUs. The master computers (MTUs) provide the information such as meter readings and equipment status to
human operators in a presentable form and allow the human operators to control the field equipments or control devices
automatically. The MTU initiates almost all communication with remote sites. Many early SCADA systems used mainframe
computer technology making them hierarchical and centralized in nature and required human oversight to make decisions. SCADA
systems were developed for gathering data from long distances using poor communication systems but providing high levels of
reliability and operability. MTUs were specialized, dedicated computers which gathered information and sent control command
over 1200-baud communication lines to RTUs with no local intelligence or function beyond serving the master station. Very little
change occurred in SCADA system concepts during the first 30 year of the industry. The recent advances in the communication
technologies and media (fiber optics, direct satellite broadcast and so forth), and increased processing power available at substation
freed the SCADA architecture and functionality from the archaic 100-baud limitation of the past communication systems.
Since the early 1990’s SCADA systems perform more operations automatically. SCADA also often have Distributed Control
System (DCS) components. Use of "smart" RTUs or PLCs (programmable logic controllers), which are capable of autonomously
executing simple logic processes without involving the master computer, is increasing. Today’s RTU devices, equipped with
distributed processing architecture and support for multiple media and multiple IEDs, provide functions such as system protection
(say, from power surges), local operation capabilities, and data gathering/concentration from other subsystems. Current generation
digital IEDs and microprocessor relays have the ability to transmit varying degrees of functional and real-time information. A single
IED can provide a number of applications and could be configured for different system parameters. The following block diagram
illustrates today’s SCADA architecture.
Modern SCADA Architecture [Figure 5 – SCADA]

Most SCADA systems were originally built before and often separate from other corporate networks. As a result, SCADA
administrators and managers typically operated on the assumption that these systems cannot be accessed through corporate networks
or from remote access points. However, the situation has changed drastically in the recent years. Figure above illustrate how the
modern SCADA networks are integrated with corporate networks and the Internet. The figure also shows that the field data
(obtained using RTUs and IEDs) is transmitted over a wide range of communication lines and can even be accessed via a web
browser to SCADA users. Communication between such integrated system elements often uses Ethernet and Internet technology.
Network enabled devices, routers, switches, and Window-based operating systems are now quite common in SCADA systems,
bringing with them the vulnerabilities that are experienced in desktop computers and corporate networks.

1.2 SCADA Communication Protocols

The SCADA systems are built using public or proprietary communication protocols which are used for communicating between an
MTU and one or more RTUs. The SCADA protocols provide transmission specifications to interconnect substation computers,
RTUs, IEDs, and the master station. The most common protocols used are:
 DNP3 (Distributed Network Protocol version 3.0)
 Modbus

1.2.1 DNP3 Protocol

1.2.1.1 Introduction to DNP3 Protocol

DNP3 or Distributed Network Protocol Version 3.3 is a telecommunications standard that defines communications between master
stations, remote telemetry units (RTUs) and other intelligent electronic devices (IEDs). It was developed to achieve interoperability
among systems in the electric utility, oil & gas, water/waste water and security industries.

DNP3 was created as a proprietary protocol by Harris Controls Division initially for use in the electrical utility industry. In
November 1993 the protocol was made available for use by third parties by transferring its ownership to the DNP3 User Group.
DNP3 was designed specifically for SCADA (supervisory control and data acquisition) applications. These involve acquisition of
information and sending of control commands between physically separate computer devices. It is designed to transmit relatively
small packets of data in a reliable manner with the messages involved arriving in a deterministic sequence. In this respect it is
different from more general purpose protocols, such as FTP which is part of TCP/IP, which can send quite large files, but in a way
that is generally not as suitable for SCADA control.

From its creation for the electrical distribution industry in America, DNP3 has gained significant acceptance in both geographic and
industry terms. DNP3 is supported by a large number of vendors and users in electrical, water infrastructure, and other industries in
North America, South America, South Africa, Asia and Australia. In Europe DNP3 competes with the IEC 60870-5-101 protocol
which is widely used in that region, and which shares a common origin with DNP3.
A key feature of the DNP3 protocol is that it is an open protocol standard and it is one that has been adopted by a significant number
of equipment manufacturers. The benefit of an open standard is that it provides for interoperability between equipment from
different manufacturers. This means for example that a user can purchase system equipment such as a master station from one
manufacturer, and be able to add RTU equipment sourced from another manufacturer. The RTU in turn may have a number of
control relays connected to it which are intelligent electronic devices and also use the DNP3 protocol. All of this equipment may be
sourced from different manufacturers, either in an initial installation, or progressively as the system is developed over time.
The following list presents features of DNP3 that provide benefits to the user:
 Open standard
 Interoperability between multi-vendor devices
 A protocol that is supported by a large and increasing number of equipment manufacturers
 Layered architecture conforming to IEC enhanced performance architecture model
 Optimized for reliable and efficient SCADA communications
 Supported by comprehensive implementation testing standards
 The ability to select from multiple vendors for future system expansion and modification

1.2.1.2 DNP3 Communication Modes

DNP3 supports three simple communication modes between a control center (master unit) and outstation devices. In a unicast
transaction, the master sends a request message to an addressed outstation device, which responds with a reply message. For
example, the master may send a “read” message (e.g., request an amperage reading) or a “write” message to perform a control
action (e.g., trip a circuit breaker); the outstation responds with the corresponding message (e.g., the amperage reading, an
acknowledgement that the circuit breaker was tripped, or an error message). In a broadcast transaction, the master sends a message
to all the outstations in the network (e.g., a “write” message that resets amperage sensors); the outstation devices do not reply to the
broadcast message. The third communication mode involves unsolicited responses from outstation devices; these responses are
typically used to provide periodic updates or alerts (e.g., an amperage reading exceeds a threshold).

DNP3 Network Configurations [Figure 6 – SCADA]

The DNP3 protocol supports a variety of network configurations. Three common configurations are shown in Figure 6. In a “one-
on-one” configuration, one master and one outstation device share a dedicated connection such as a dial-up telephone line. The
popular “multi-drop” configuration has one master that communicates with multiple outstations. Every outstation receives every
request from the master, but each outstation only responds to messages addressed to it. In a “hierarchical” configuration, a device
acts as an outstation in one segment and a master in another segment; such a dual-purpose device is called a “sub-master.”
Early SCADA architectures often relied on communication circuits that were susceptible to noise and signal distortion.
Consequently, DNP3 was designed to incorporate multiple protocol layers. The International Electro technical Commission (IEC)
initially proposed the IEC 870 standard for telemetry data transmission in SCADA systems based on the Open Systems
Interconnection (OSI) model. This three-layer Enhanced Performance Architecture (EPA) was created by eliminating superfluous
layers (from the point of view of SCADA systems) from the seven-layer OSI model (Figure 7). However, EPA did not support
application layer messages that were larger than the maximum length of a data link frame. DNP3 addressed this issue by
incorporating a pseudo transport layer to allow message fragmentation (Figure 7).

Design Progression from OSI to DNP3 [Figure 7 – SCADA]

The DNP3 protocol layers are placed on top of a physical layer, which is responsible for transmitting messages over physical media
such as radio, satellite, copper and fiber. The physical layer specification determines the electrical settings, voltage and timing,
along with other properties necessary to send signals between devices. The physical layer provides five services: (i) send data, (ii)
receive data, (iii) connect, (iv) disconnect, and (v) status update. Note that the physical layer is shaded in Figure 7 because it is not
specified in the DNP3 standard.
DNP3 may be transported over a variety of physical media, including old fashioned serial links. However, modern SCADA systems
typically use DNP3 in IP networks. The DNP Users Group has stipulated that the three layers of DNP3 not be modified in IP-based
implementations. For this reason, the three DNP3 layers are placed directly above the TCP/IP or UDP/IP layers in the protocol
stack.

1.2.1.3 DNP3 Protocol Layer – Data Link Layer

The data link layer maintains a reliable logical link between devices to facilitate the transfer of message frames. A data link layer
frame has a 10-byte fixed size header and a data or “payload” section containing data passed down from the pseudo-transport and
application layers. The maximum length of the data section is 250 bytes (282 bytes including 16-bit CRC fields for every 16 bytes
of data). Thus, the maximum length of a data link frame is 292 bytes.
DNP3 data link frame [Figure 8 – SCADA]
Figure 8 above shows the format of a data link header. The Start field always contains the two-byte value 0x0564 to enable the
receiver to determine where the frame begins; the Start bytes signal that a DNP3 packet has arrived and must be processed. The
Length field provides the number of bytes in the remainder of the frame (not including CRCs).
The Link Control field in the data link header contains data that controls message flow, provides sequencing and determines the
function of the frame. This data helps determine if the device is a master or outstation, identifies the device that initiated the
communication, and provides the status of the logical link. The Link Control field also contains a four-bit function code that
specifies the purpose of the message. Separate sets of function codes are used in messages originating from a master and in those
originating from outstation devices. Examples of master function codes are reset remote link, reset user process, request link status
and test function. Outstation device function codes include positive acknowledgement, message not accepted, status of link and no
link service. The Link Control field also contains two flags for communication synchronization and flow control. The 16-bit
Destination Address in the data link header specifies the intended recipient (which may include a broadcast address of 0xFFFF); the
16-bit Source Address identifies the originator. A 16-bit CRC is also included in the header to verify the integrity of the
transmission.

1.2.1.4 DNP3 Protocol Layer – Pseudo Transport Layer

The DNP3 pseudo-transport layer handles message fragmentation and reassembly. As mentioned above, it enables application
messages larger than one data link frame in length to use multiple frames. The pseudo-transport layer adds one byte containing the
FIR and FIN flags and a Sequence number (Figure 9 below). The FIR and FIN flags indicate the first and final frames of a
fragmented message, respectively. The Sequence number, which is incremented for each successive frame, is used to reassemble
messages for processing by the application layer. The sequencing information also facilitates the detection of dropped frames.

DNP3 pseudo-transport message fields [Figure 10- SCADA]

1.2.1.5 DNP3 Protocol Layer – Application Layer

The application layer, which specifies DNP3 request and reply messages, defines the roles of the master and outstation devices. A
request message from a master directs an outstation device to perform a task, collect and provide data, or synchronize its internal
clock. Only a master may send request messages; outstation devices may send solicited or unsolicited messages. The application
layer fragments messages that exceed the maximum fragment size (determined by the size of the receiver’s buffer). A typical
message fragment is between 2048 and 4096 bytes.
DNP3 application message [Figure 11 – SCADA]
Figure 11 shows the format of the application layer header. The Application Control field performs a similar function as the
corresponding field in the pseudo-transport layer, but at a higher level. Two flags are included to specify the first or last fragment of
a message and the sequence number for ordering and reassembly. An additional flag is included to request confirmation upon
receipt of a fragment. The Function Code field communicates the purpose of a message. This field is used in both requests and
replies, but the available functions change with the message type. The 23 defined function codes for request messages are grouped
into six categories: (i) transfer functions, (ii) control functions, (iii) freeze functions, (iv) application control functions, (v)
configuration functions, and (vi) time synchronization functions.
A reply message can be a: (i) confirmation, (ii) response, or (iii) unsolicited response. Reply message headers incorporate a two-
byte Internal Indications (IIN) field that communicates useful information about the outstation unit to the master. Each bit in the IIN
field has a specific meaning that is updated in every reply message. Example IIN codes are time synchronization required, device
restart, invalid parameters, function code not implemented and requested objects unknown. Following the header in a DNP3
application layer message are data objects that convey encoded representations of data (Figure 11). Several data objects are defined
to enable devices running on different platforms to efficiently communicate data and commands. Examples of data objects are
binary inputs, binary outputs, analog inputs, analog outputs and counters.

1.2.1.6 DNP3 Protocol Vulnerabilities and attacks

Attacks on DNP3 systems fall into three categories: (i) attacks that exploit the DNP3 specifications, (ii) attacks that exploit vendor
implementations of DNP3, and (iii) attacks that exploit weaknesses in the underlying infrastructure.
Attacks on vendor implementations typically exploit configuration errors or code flaws which have been described previously (e.g.,
via buffer overflows). Attacks on the underlying infrastructure exploit vulnerabilities in information technology, network and
telecommunications assets, or weak security policies also described above.
Here attacks that exploit the protocol specifications, which target all SCADA systems that conform to the DNP3 standard, have
been described. Attack identification involves a detailed analysis of the DNP3 protocol. DNP3 was not designed with security in
mind. Consequently, security is a major concern for DNP3 implementations that use commodity computing equipment and
networking technologies. Each attack is being analyzed for its ability to intercept, interrupt, modify and/or fabricate each of the
three primary targets: master, outstation devices and network/communication paths. Figure 12 illustrates the four threat categories
considered in the DNP3 attack taxonomy.
Threat Categories [Figure 12 – SCADA]

Most common attacks rely on the ability to intercept, modify and/or fabricate DNP3 messages. DNP3 implementations typically do
not employ encryption, authentication and authorization; DNP3 devices simply assume that all messages are valid. Three attacks
leverage these weaknesses and, because of their flexibility, target all three DNP3 layers. The three common attacks described below
are among the most insidious because they perform reconnaissance and/or execute potentially malicious operations on outstation
devices while (possibly) masking their actions.
Passive Network Reconnaissance: An attacker with the appropriate access captures and analyzes DNP3 messages. This attack
provides the attacker with information about network topology, device functionality, memory addresses and other data. Examples
are interception of master data; interception of outstation device data; and interception of network topology information.
Baseline Response Replay: An attacker with knowledge of normal DNP3 traffic patterns simulates responses to the master while
sending fabricated messages to outstation devices. Examples are interruption of the master and outstation; modification of the
master and outstation; and fabrication of the master and outstation.
Rogue Interloper: An attacker installs a “man-in-the-middle” device between the master and outstations that can read, modify and
fabricate DNP3 messages and/or network traffic. Examples are interception of master, outstation and network data; interruption of
the master, outstation and network; modification of the master, outstation and network path; and fabrication of the master, outstation
and network path.
Above attacks are common to all protocol layers. Described below are attacks specific to each protocol layer. Data link layer
attacks involve intercepting DNP3 messages, modifying message values and sending them to the master or outstation devices.
Some of the attacks impact confidentiality by obtaining configuration data and network topology information. Integrity attacks
insert erroneous data or reconfigure outstations. Attacks on availability cause outstation devices to lose key functionality or disrupt
communications with the master. Listed below are five data link layer attacks in more detail.
Length Overflow Attack: This attack inserts an incorrect value in the Length field that affects message processing. The attack can
result in data corruption, unexpected actions and device crashes. Examples are interruption of the master and outstation; and
modification of the master and outstation.
DFC Flag Attack: The DFC flag is used to indicate that an outstation is busy and that a request should be resent at a later time.
This attack sets the DFC flag, which causes an outstation device to appear busy to the master. An example is interruption of an
outstation.
Reset Function Attack: This attack sends a DNP3 message with Function Code 1 (reset user process) to the targeted outstation.
The attack causes the targeted device to restart, rendering it unavailable for a period of time and possibly restoring it to an
inconsistent state. Examples are interruption of an outstation and modification of an outstation.
Unavailable Function Attack: This attack sends a DNP3 message with Function Code 14 or 15, which indicates that a service is
not functioning or is not implemented in an outstation device. The attack causes the master not to send requests to the targeted
outstation because it assumes that the service is unavailable. An example is interruption of the master.
Destination Address Alteration: By changing the destination address field, an attacker can reroute requests or replies to other
devices causing unexpected results. An attacker can also use the broadcast address 0xFFFF to send erroneous requests to all the
outstation devices; this attack is difficult to detect because (by default) no result messages are returned to a broadcast request. Some
examples of this kind of attack are interruption of the master, outstation and network; modification of the master, outstation and
network path; and fabrication of the master, outstation and network path.
The pseudo-transport layer provides less functionality than the other layers; thus, fewer attacks are associated with this layer. The
two attacks associated with the pseudo-transport layer target the fragment flags and sequence number.
Fragmented Message Interruption: The FIR and FIN flags indicate the first and final frames of a fragmented message,
respectively. When a message with the FIR flag arrives, all previously-received incomplete fragments are discarded. Inserting a
message with the FIR flag set after the beginning of a transmission of a fragmented message causes the reassembly of a valid
message to be disrupted. Inserting a message with the FIN flag set terminates message reassembly early, resulting in an error during
the processing of the partially-completed message. Examples of this attack are interruption of the master and outstation.
Transport Sequence Modification: The Sequence field is used to ensure in-order delivery of fragmented messages. The sequence
number increments with each fragment sent, so predicting the next value is trivial. An attacker who inserts fabricated messages into
a sequence of fragments can inject any data and/or cause processing errors. Some examples of this attack are interruption of the
master and outstation; modification of the master, outstation and network path; and fabrication of the master, outstation and network
path.
The application layer provides the majority of functionality for DNP3 systems; consequently, the largest number of attacks are
associated with this layer. Attacks on confidentiality obtain information about network topology, system configuration and
functionality. Integrity attacks modify communication paths, provide bad data to the master and outstation devices, or reconfigure
outstation devices. Availability attacks may cause devices to lose key functionality, reboot or crash. We discuss five attacks in more
detail.
Outstation Write Attack: This attack sends a DNP3 message with Function Code 2, which writes data objects to an outstation. The
attack can corrupt information stored in the outstation’s memory, causing an error or overflow. Examples of the attack are
interruption and modification of an outstation.
Clear Objects Attack: This attack sends a DNP3 message with Function Code 9 or 10 to freeze and clear data objects. The attack
can clear critical data or cause an outstation device to malfunction or crash. Note that the attack involving Function Code 10 is
problematic because a message with this function code does not require an acknowledgement. Examples of the attack are
interruption and modification of an outstation.
Outstation Data Reset: This attack sends a DNP3 message with Function Code 15. The attack causes an outstation device to
reinitialize data objects to values inconsistent with the state of the system. Examples of this attack are interruption and modification
of an outstation.
Outstation Application Termination: This attack sends a DNP3 message with Function Code 18, which is used to terminate
applications running on outstations. A message with this function code causes a device to become unresponsive to normal requests
from the master. Examples of this kind of attacks are interruption and modification of an outstation.
Configuration Capture Attack: This attack sends a message with the fifth bit in the second byte of the IIN set, which indicates
that the configuration file of the targeted outstation is corrupted. The attack causes the master to transmit a new configuration file,
which is intercepted by the attacker. A separate attack is then executed to modify and upload the file to the targeted outstation. One
example of this attack: interception of outstation data.

Impact of the above impacts on various protocol layers involve intercepting device configuration data, process data and network
information. Some of the attacks result in denial of service to master, outstation and network resources. Modification attacks insert
erroneous data in devices, which affects the integrity of the control system. Fabrication attacks are particularly dangerous. Some
attacks scenarios enable an attacker to spoof outstation devices and fabricate network paths. Most alarming attacks are that spoof the
master and seize partial or complete control of the process. Loss of confidentiality occurs when important information about device
configuration or network topology is obtained by an attacker. Generally, this is the first step of a more serious attack, where
reconnaissance is conducted to identify weaknesses and entry points. Loss of awareness occurs when the control center does not
have accurate information about system status. For example, an attacker can trip a circuit breaker and prevent an alarm from
reaching the operator. Such attacks can lead to serious incidents because their effects may go unnoticed until it is too late. Even
more dangerous are the attacks that result in the loss of control – an attacker who usurps control of a SCADA master can potentially
wreak havoc.
Attack scenario
Here is an attack scenario exploits the vulnerabilities in the DNP3 Protocol. The attack scenario described here has several ways the
Malicious Intruder (Intruder) uses to compromise the security of SCADA systems and networks. The Intruder could use protocol
analyzer tools such as “Ethereal” or other well known techniques to intercept the DNP3 frames. As a result, the Intruder grabs
unencrypted (plaintext) frames from a DNP3 SCADA system network application. By doing so, the Intruder will capture the
address of the source and destination systems. The Intruder could use the unencrypted data frames that contain control and settings
information in subsequent attacks on either the SCADA system or the Intelligent Equipment Devices (IEDs). Such attacks could
take the form of shutting off the MTU software, shutting down the MTU computer, or the RTU stops functioning. In addition, the
Intruder could change the settings on the IED, controller, or SCADA system such that the equipment either
a) Fails to operate when it should, causing bus, line, or transformer damage, or
b) operates when it shouldn’t, causing service interruption
In our scenario, an intruder, after managing to get between the Master and the Slave, intercepts the transmission of the frames and
implement his/her attack in two phases:
Plan the attack: An important feature of DNP3 is the ability for the Slave to generate unsolicited report by exception (RBE) event
and send it to the Master. Unsolicited message (alarming) generation for event reporting is configurable by the master station
through the usage of the configuration functions in the application function code. The Intruder understands the structure of the
DNP3 protocol and plans his attack by following these steps:
1. The Master initiates a connection with the Slave
2. Unknown to both the Master and the Slave, the Intruder is waiting to intercept their connection
3. The Intruder receives Master’s request for a connection (authentication capability is not implemented in DNP3, so the
Intruder does not have to authenticate himself to the Slave)
4. The source address (#0), the destination address (#245), the function codes, and the data objects are available in clear text
Disable DNP3 unsolicited messaging (alarming) by attacking one or more Slave units: The Intruder implements his/her attack by
following these steps:
5. The Intruder then initiates a connection with the Slave posing as Master
 6. The Intruder sends a message to Slave unit #245 with code function code 21 (disable unsolicited messages).
7. Slave unit #245 receives the message and disables unsolicited messages function. At this point the Slave will not be able to
send any alarming messages to the Master in case there is a failure or abnormal operation at the Slave unit.
8. The Intruder sends another message with code function code #18 to Slave #245. Code #18 gives instructions to the Slave to
stop running the application specified in the message.
9. A simultaneous attack on other Slave units will disable all operations on a communication channel (DNP3 has the
capability to send a broadcast message to all Slave units by using address #65535). This could interrupt the utilities
services at that region, like shutting down the electricity services.
10. At this stage, the Master Terminal Unit (MTU) in the Master Station reports that the application is running normally, while
the Remote Terminal Unit (RTU) in the Slave Stations receives tampered frames.

1.2.1.7 Countermeasures for Enhancing DNP3 Security

The Security approaches are divided into three categories:

1) Solutions that wrap the DNP3 protocols without making changes to the protocols,
2) Solutions that alter the DNP3 protocols fundamentally, and
3) Enhancements to the DNP3 application.
The solutions that wrap the protocols include SSL/TLS and IPsec, which would provide a quick and low-cost security enhancement.
The solutions that would require altering the DNP3 protocols tend to be more time-consuming to implement and expensive but
provide better end-to-end security, (more application specific security). Such solutions can either be deployed at either a protocol
level (“object security”), or within an application.

1.2.1.7.1 Solutions that wrap the DNP3 protocols without making changes to the protocols

1.2.1.7.1.1 SSL/TLS Solution

We studied SCADA security enhancement by using an open source implementation Open SSL of Secure Sockets Layer (SSL) /
Transport Layer Security (TLS) protocols. SSL/TLS secures communication channels for any reliable communication over TCP/IP
and has been in use for about a decade providing virtual private network for the Internet users. SSL/TLS secures communication
between a client and a server by allowing mutual authentication and provides integrity (verifying that the original contents of
information have not been altered or corrupted) by using digital signatures and privacy via encryption (transforming data into a form
unreadable to everyone except the receiver). The SSL/TLS protocols were specifically designed to protect against both man-in-the-
middle and replay attacks. Other SSL/TLS features include error-encryption, data compression and transparency. The protocols are
administered by an international standards organization (IETF). SSL is well established in areas of Web browser, Web servers, and
other Internet systems that require security. As more systems connect to Internet and more Internet transactions require security,
SSL/TLS’s influence will only grow. DNP3 would benefit by going with this prominent and open source SSL/TLS solution that
provides critical security features.
In addition to these inherent SSL/TLS benefits, “wrapping” DNP3 with SSL/TLS has the following advantages:
1. SSL/TLS covers the most of necessary components expected at a protocol level.
2. The implementation would be fast, cost-effective, and straightforward.
3. The IEC Technical Committee has recently accepted SSL/TLS as a part of a security standard for their communication
protocols. This endorsement is noteworthy and relevant especially considering DNP3’s similarity with IEC protocol.
However, SSL/TLS solutions are not without limitations. The SSL/TLS protocols have fundamental constrains such as
 1. They can run only on a reliable transport protocol such as TCP.
2. They have higher performance costs associated with them
3. They are unable to provide non-repudiation service (i.e., assurance that the sender is provided with proof of delivery and
that the recipient is provided with proof of the sender's identity so that neither can later deny having processed the data)
4. They can provide only channel security (not object security).
5. The protocols rely on other components such as encryption and signature algorithms. No SSL/TLS implementation can be
any stronger than the cryptographic or signature tools on which it is based. In particular, it does not provide protection
against an attack based on a traffic analysis.
6. SSL/TLS cannot protect data before it is sent or after it arrives at its destination. That is, SSL/TLS cannot be used to store
encrypted data on a disk or in a cookie. This is because SSL/TLS cannot prevent a connection reset since the connection
handling is done by a lower level protocol (i.e., TCP).

1.2.1.7.1.2 SSL/TLS Implementation

Several implementations of SSL/TLS protocols are available. Open SSL is a leading open source SSL/TLS implementation. It is
non-proprietary and open to public and is available free of charge. By using an open source, SCADA utility companies are not stuck
with a proprietary company for their security needs. In addition, an open source benefits from contributions from thousands of its
users. The companies using an open source benefit from these contributions. Vulnerabilities are identified easily since it is used by
many heterogeneous users.
If a particular SSL/TLS implementation was developed just for DNP3 instead of using and open source, it would have limited user
exposure not resulting in the benefits listed here. OpenSSL has several known vulnerabilities, some of which are critical and hard to
find. In addition, it is easy to add malicious code in OpenSSL since there is no accountability for such an action. Weighing the pros
and cons of OpenSSL it can be concluded that OpenSSL would still be the best choice for SSL/TLS implementation on DNP3.

Protocol Stack [Figure 13- SCADA]

Gray-background protocols are secured alternatives.

1.2.1.7.1.3 IPSec (secure IP) Solution

Security can also be provided at the lower layer of the protocol stacks than TCP, such as at the IP level, by securing IP packets
(pieces of data divided up for transit). IPSec operates at a lower level than SSL/TLS does (see figure 13), but provides many of the
same security services. Since the security at the lower levels of the stack can account for more traffic, IPSec can secure any TCP or
IP traffic as opposed to SSL/TLS securing only the traffic running on TCP. This can be advantageous for capturing some attacks.
Particularly, solutions that operate above the Transport Layer, such as SSL/TLS, only prevent arbitrary packets from being inserted
into a session. They are unable to prevent a connection reset (denial of service attack) since the connection handling is done by a
lower level protocol (i.e., TCP). On the other hand, the Network Layer cryptographic solutions such as IPSec prevent both arbitrary
packets entering a Transport-Layer stream and connection resets because connection management is integrated into the secured
Network Layer. Additionally, unlike SSL/TLS, IPSec provides security for any traffic between two hosts. This means that once
IPSec is installed, all applications gain some security.
IPSec’s place in the protocol stacks is also a reason for its limitations. Since IPSec is lower in the stack than SSL/TLS is, it is even
more sensitive to interference by intermediaries in the communications channel. So, it is would be complicated to send encrypted or
authenticated data to a machine behind a firewall. Additionally, the lower level protocols provide less flexibility in security. In other
words, they fail to provide the exact security that the application needs. For example, they cannot provide advanced features such as
non-repudiation. In that regard, the higher-level security measures are preferred to those applied to the lower levels.
Considering the criticality of the SCADA networks and low cost of implementations, combining both the solutions SSL/TLS and
IPSec is a good approach. The following sections discuss the application-level security.

1.2.1.7.2 Enhancements to DNP3 applications

Instead of thorough changes to the DNP3 fundamentals to make it secure, organizations can enhance security by applying standard
technologies to DNP3 applications. Even though the work may include tasks such as revising the message formats, making changes
in data and control structures, or including authentication and encryption in DNP3, the effort would not be as complex and costly as
adding object security and still would provide the end-to-end security at the application level. This approach would provide much
better security than that provided by securing the lower levels (IP or the Transport Layer) by using SSL/TLS or IPSec. This
approach does not have to be an all-or-none approach in terms of implementation. Depending upon the company budget and the
security needs, a company can choose one or more techniques listed in this section to make DNP3 inherently secure.

1.2.1.7.2.1 Message Encryption

The only good solution to the threats of eavesdropping and traffic analysis is complete encryption of a protocol stream.
Unfortunately, encryption can be very processing-intensive and would not be a good solution for some of the smaller devices
currently deploying DNP3 since this would decrease communication speed to a great extent. Another problem is that there are
exporting, licensing, and key exchange issues with encryption that must be dealt.

1.2.1.7.2.2 Authentication using Message Authentication Object

To detect modification of a transmitted message, an authentication object can be designed which can be appended to each message
or to any DNP3 message that required authentication. The DNP Technical Committee has discussed a possibility of such an object
called Message Authentication Object (MAO) which has fields for timestamp, nonce, hash-method, length, and hash value. It would
contain the results of a secure hash function performed on the concatenation of the message and a secret, or password with only the
valid sender and receiver knowing the secret. The hash would verify that the message has not been changed in transmission.
However, authentication methods exist that are faster and yet can protect against the active threats of spoof, replay, repudiation and
modification. Objects such as MAO will not protect against eavesdropping or traffic analysis. Nevertheless, it can prevent outputs
from being incorrectly activated by unauthorized users even if these users have the power to eavesdrop on the network.

1.2.1.7.2.3 Authentication using Hash Algorithms

Standard hash algorithms provide data integrity assurance and data origin authentication avoiding man-in-the-middle attacks. Per an
estimate by DNP3 Technical Committee, a total of 59 to 77 bytes may be needed to be added to every protected message. It was
also found that implementing encryption would be a similar amount of work to implement the hash algorithm. However, processing
time of encryption versus just hashing may be different. In that case, it can be chosen to encrypt only the control messages and
authenticate all messages. Assuming this data works for all devices and situations, it means that using the MAO on every message
does not provide significant processor savings over encrypting the entire stream. However, using the MAO on selected messages,
say only on controls, would still be better than encrypting the complete stream. Even if the DNP3 data should be encrypted, there is
still need of an authentication function, for which MAO can be used.
1.2.1.7.3 Enhance SCADA protocols with selected cryptography techniques

SSL/ TLS and IPSec provide generic security features and protect only a part of the communication channel, but selective
cryptography techniques can provide end-to-end security that protects an entire channel between a sender and the receiver. Based on
early works of the DNP3 User Group, the following two cryptography techniques are suggested that has been tested on a prototype.

1.2.1.7.3.1 Authentication Octets

This technique is based on digital-signature algorithm. In this technique, additional bytes of information, referred here as
Authentication Octets, are appended to each message from an MTU to an RTU for the authentication. First, hash is performed on
selected bytes of a message, resulting in a hash digest. This digest is encrypted by using the MTUs private key (see figure below)
and then the encrypted digest is sent along with the message. In this test-bed implementation, keys are stored locally, eliminating the
need of the Certificate Authority. The message itself is not encrypted to save the processing time during the encryption and the
decryption. Other data that vary with time are time stamped for additional checks. For example, with the timestamp, the RTU
verifies that the time of reception does not vary from the time of transmission beyond a specified range to eliminate an intruder from
resending a valid message multiple times. The RTU decrypts the hash digest by using the MTU’s public key and compares it with
hash digest independently calculated by the RTU. The RTU would conclude that the message came from an authentic source if it
can decrypt the digest using the MTU’s public key. The RTU would also conclude that the message contents are unaltered if the
digest values match. The Authentication Octets technique may also be applied to the messages send from an RTU to an MTU to
prevent an intruder from making an MTU send inappropriate messages. For example, an intruder can send valid looking RTU
values, indicating a high voltage surge to prompt an MTU to send a control message to turn-on the circuit breaker. The
Authentication Octets technique protects spoofing and modification attacks. Because the entire message is not encrypted, this
technique does not protect from the threat of eavesdropping. However, for SCADA networks, eavesdropping is not a major concern.
The more significant concern is to block the unauthorized commands to the RTU.

Authentication using authentication octets [Figure – SCADA]

1.2.1.7.3.2 Authentication via Challenge Response

This technique verifies the identity of an RTU or an MTU by using the challenge-response cryptography to protect against the man-
in-the-middle attack. Either of the devices (MTU or RTU) initiates a challenge to authenticate the other device that shares a secret.
The authenticator device sends a random challenge to the other device. Using the secret and the challenge the other device
calculates a hash digest and then sends this digest as a response. The authenticator checks the response against its own calculation of
the expected hash digest. If the values match, the authentication is acknowledged, otherwise the authenticator terminates the
connection. There are four types of occasions when a challenge response method is used for an authentication: In establishing a
connection, an RTU sends a challenge to verify the authenticity of the MTU; An RTU also sends a challenge in specific
circumstances, such as when it receives a critical command to shut the power switch off from MTU; An MTU sends a challenge to
an RTU to verify the validity of data that are out of the typical range; and MTUs and RTUs also randomly send challenges to each
other to verify the authenticity of the other device.

The proposed security techniques were implemented at the SCADA test-bed at the University of Louisville, in Intelligent Systems
and Process Control Laboratories. As shown in Figure below, the test-bed consists of one MTU and five RTUs. The MTU uses
DNP3 protocol to communicate with RTUs, human machine- interface software to simulate real-life remote-monitoring
environment, and MySQL database to store information obtained from intrusion detection sensors. Four RTUs are locally installed
in the University of Louisville, and connected to the MTU with Ethernet LAN. One remote RTU is located about 100 miles away
from the MTU which is connected to the MTU via the Internet. Each RTU includes intrusion detection software—Snort—to
monitor the communication between the RTU and the MTU. Snort intrusion detection sensors analyze the communication to extract
relevant information to alert the administrator of unauthorized intrusions. The sensors log their data to the database residing on the
MTU.

SCADA System Testbed [Figure- SCADA]

Table below shows a comparison of the performance among different security methods that we used at the University of
Louisville.

CONCLUSION

1.2.1.7.4 Distributed Network Protocol Version 3 Security (DNPSec) Framework

DNPSec authentication and integrity framework capabilities will verify the frame origin, assure that the frame sent is the frame
received, assure that the network headers have not changed since the frame was sent, and give anti-replay protection. DNPSec
confidentiality framework capability will encrypt frames to protect against eavesdropping and hide frame source by applying
encryption methods. Some modifications to the DNP3 frame structure are required to provide these capabilities.
CRC is a common technique used in DNP3 for detecting data transmission errors. CRCs occupy 34 bytes out of 292 bytes of the
DNP3 Pseudo Transport layer for integrity. These bytes will be utilized in a different way in the DNPSec framework.
There are two main components of the DNPSec. The first is the DNPSec structure to construct the frame and transfer data in secure
mode between the Master and the Slave. The second is the key exchange established during the installation and connection setup
between the Master and the Slave.
Modifications to the data link layer header have been to done to transfer the data in secure mode between slave and master. DNPSec
consists of five fields (as shown in Figure 14) the new header, the key sequence number, the original data link header, the payload
data, and the authentication data.
Protocol Structure – DNPSec [Figure 14- SCADA]
The new header is an unsigned 4 bytes field containing the destination address (DA) which occupies 2 bytes; the MH flag bit to
recognize if the message is coming from the Primary Master host (0) or from the Secondary Master Host (1); the SK flag bit to
indicate to the Slave if the message contains the new session key (1) or to decrypt the message using the session key in the S-keydb
(0); and 14 bits reserved.
The key sequence number is an unsigned 4 bytes field containing a counter value that increases by one for each message sent by
the Master. Each time a Master sends a message it increments the counter by one and places the value in the key sequence number
field. Thus, the first value to be used is 0. The Master must not allow the key sequence number to cycle past 232 – 1 back to zero. If
the limit of 232 – 1 is reached, the Master should terminate the session key and send a new key to the Slave using the value zero in
the frame sequence number. This kind of functionality will guarantee that the Master and the Slave will continue establishing a new
session key even if the connection is always open. Moreover, the security policy should indicate that a new session key must be
established between the Master and the Slave in case the Slave used the same session key for a certain time period. DNPSec uses
the variable key-session-life-time to keep track of the life span of the session key.
The original LH header (DNP3 data link header without the 2 CRCs) and the payload data is protected by encryption and
composed of 264 bytes field containing, 8 link protocol data unit header bytes, 250 Transport Protocol Data Unit bytes, and 6
padding dummy bytes. 264 bytes is a multiple of 4 bytes, which provides alignment of 4 bytes boundary and provides boundaries of
64 bits to support the encryption algorithms. For example, Data Encryption Standard (DES) specifies that the plaintext is 64 bits in
length and the key is 56 bits in length. Longer plaintext is processed in 64-bit blocks.
The authentication data field containing an Integrity Check Value (ICV) computed over the key sequence number, the original LH
header, and the payload data fields. ICV provides integrity services and is provided by a specific message authentication algorithm
(MAC) such as, HMAC-MD5-96 or HMAC-SHA-1-96. The integrity algorithm specification must specify the length of the ICV
and the comparison rules and processing steps for validation. DNPSec required 20 bytes for the authentication data field. To
simplify the key management process, use of the Master/Slave encryption/decryption session key to calculate the authentication data
is a good option.
The DNPSec fields are as follows:
0–3 New Header (4 bytes)
DA: 0-1 Destination Address (2 bytes)
MH: 2(bit 0) 0: Primary Master Host,
1: Secondary Master Host
SK: 2(bit 1) 0: Fitch the database for the session key,
1: The frame contains a KSN value from the Master.
2(bits 2-7)-3 Reserved (2 bytes)
4–7 Key Sequence Number (4 bytes)
8 – 15 Original LH Header (8 bytes)
8–9 Sync (2 bytes)
10 - 10 Length (1 byte)
11 – 11 Link Control (1 byte)
12 – 13 Destination Address (2 bytes)
14 – 15 Source Address
16 – 271 Payload data (256 bytes)
16 – 265 TPDU data
 266 – 271 Padding dummy data
272 – 291 Authentication Data (20 bytes)

Key management
The key management operations in DNPSec are very simple to accommodate the static nature of the SCADA environment. They
occur during the configuration of the Primary Master host, the Secondary Master host, and the Slaves to establish the initial
connection between them; after the re-initialization of the Key Sequence Number (KSN) to generate and distribute a new key to the
hosts; and after the timeout of the usage of the session key.
The Master host generates and manages a secure database “M_Keydb” for the shared session keys with the Slaves (see Figure14).
The database consists of four fields: the Slave address used as an index key to the database, the shared session key, the time stamp
used to limit the usage of the shared key for a certain pre-defined time period, and the Key Sequence Number. The Master calls
“M_GenKey” to generate a unique session key when the old session key expired. “M_PutKey” is the function used to insert the new
session key into the database. And the M_PutKSN is the function used to insert the new KSN into the database.
The Slave needs to maintain two session keys, one for communicating with the Primary Master host and the other for the Secondary
Master host (see Figure 14). It manages a secure database “S_Keydb” for the shared session keys with the Master hosts. The
database consists of three fields and two records: (0, Primary Master Session Key, Key Sequence Number and 1, Secondary Master
Session Key, Key Sequence Number). The simple”S_PutKey” is the function used to update the database with a new session key
and the “S_PutKSN is the function used to update the database with a new KSN.

DNPSec request/response link communications [Figure 14 – SCADA]

Advantages and disadvantages of DNPSec, DNP3/IPSec, DNP3/SSL/TLS architecture
SCADA/DNP 3 Security Solutions Advantages Disadvantages
Wrapping DNP3 frame with SSL/TLS  The IEC Technical  Run only on a reliable
Committee has accepted transport protocol (TCP and
SSL/TLS as part of a security not for UDP)
standard for their  High performance cost
communication protocol  No non-repudiation services
 Freely available for all  Can’t protect data before it is
 common OS sent or after it arrives its
 Relatively mature destination
 Implementation of the
protocol required
understanding of the
application, OS, and its
specific system calls.
 CA are rather expensive and
not really compatible with
each other
Wrapping DNP3 frame with IPSec  Protection against DOS  Very complex and hard to
 Implemented by Operating implement
Systems, Routers, …etc.  Higher performance cost
 Transparent to applications  All devices shall support
(below transport layer) TCP and UDP
 No need to upgrade communications on port
applications number 20000
DNPSec  End-to-End security at the  Required some modification
application level to support to the DNP3 Data Link Layer
any communication link  Theoretical approach, needs
 Protocol is simple to proof the concept (in
eliminating the complexity of going work)
the key exchange and
management issues
 Implement it once for all
communication networks

1.2.1.7.5 Secure DNP3

DNP user group started working on the Secure DNP3 from 2002. Secure DNP3 adds authentication and integrity protection to the
existing DNP3 protocol. This is a bidirectional protocol which provides protection between master stations and nonmaster/ slave
stations. Secure DNP3 only modifies application layer of the protocol which means that existing DNP3 messages can be transported
over TCP/IP, dial-up or serial communication link. This protocol defines four scenarios when authentication can be performed.
These are:
 Session Initialization: When a master station initiates a DNP3 session with an outstation/slave, Secure DNP3 will
authenticate both stations to prevent spoofing, replay and other attacks. A unique session key is generated and exchanged
using pre-shared keys during this phase.
 Periodic Authentication: The master station and non-master/slave station will periodically verify their identity to prevent
different attacks. The default interval for a periodic authentication is 20 minutes and the maximum is authentication every
hour. A new session key is generated and exchanged while performing this periodic update.
  Requests with Critical Function Codes: Critical function codes can be the primary target of the attacker. Some example
of the critical function codes are: write (FC 2), cold and warm restarts (FC 13, 14) etc. Authentication mechanism is used
before responding to these critical function codes.
 Vendor Specific: Vendors can implement authentication requirements for other function codes or let end users to choose
function codes that require authentication.
There are two modes or ways of authentication. These are:
 Challenge-Response Mode
 Aggressive Mode
Challenge-Response Mode: This is the default mode of authentication. When a master station issues a request with a function code
that requires authentication, the outstation/slave will not immediately process the request and send a response back. Instead the
outstation/slave will send an authentication challenge that includes random data which is changed in case of each challenge. The
master station will respond to the challenge with a HMAC which include the random data and the session key. The outstation/slave
also has the session key and can verify the HMAC if the response is correct or not. The challenge-response mode is depicted in the
Figure 15 below.

Message Sequence in Challenge-Response Mode [Figure 15- SCADA]

Aggressive Mode: Aggressive mode eliminates the delay and overhead of the challenge/response in the normal Secure DNP3
mode. In this mode, the master station will append an authentication response to the protocol request message for function codes
that are known to require authentication. The random number that is typically used in the authentication challenge is created by the
master station; hence there is a risk of replay if external replay protection is not provided. This simplified message flow is depicted
in the Figure 16.
Message Flow in Aggressive Mode [Figure 16 – SCADA]
Secure DNP3 specified existing cryptographic algorithms. The authentication protocol uses a keyed hashing with message
authentication (HMAC) which creates a secure checksum. The HMAC calculation needs message data, challenge and a secret key.
Since only the sender and receiver have these three components, only they are able to calculate or verify the HMAC. Thus HMAC
verifies integrity of the message because if any bit is modified in the message, the HMAC calculated by the receiver will not match
the HMAC sent in the message.
The authentication method provided in the Secure DNP3 requires the two communicating sides to share the same secret key. Secure
DNP3 defines a two level key management scheme a discussed briefly below.
 Level 1 is a pre-shared key that is distributed securely in an unspecified manner to a master station and outstation. For
small systems this is likely that pre-shared keys will be manually distributed.
 Level 2 is a session key which is securely distributed using the pre-shared key. A fresh session key is created and
exchanged at initialization and periodically. This new key is then used for further authentication of individual requests and
responses until it is updated.
This authentication method requires new function codes to send authentication request and response message. In addition to these
some other function codes are specified. For example: adding aggressive mode authentication support to existing request function

codes, key status information in the response. Table below shows a list of new function codes related to the
authentication procedure.
Function Code Type of Function
32 Authentication Request
33 Authentication Reply
34 Authentication Error
131 Authentication Challenge
132 Unsolicited Authentication Challenge

1.2.2 Modbus protocol

1.2.2.1 Introduction to Modbus protocol

The Modbus transmission protocol was developed by Gould Modicon (now Schneider) for SCADA systems. Although Modbus is
relatively slow in comparison with other buses, it has the advantage of wide acceptance among instrument manufacturers and users.
About 20 to 30 manufacturers produce equipment with the Modbus protocol and many systems are in industrial operation. It can
therefore be regarded as a de facto industrial standard with proven capabilities.
The following figure illustrates the Modbus protocol stack with the 7 layers of OSI Model
Figure: Modbus protocol and ISO/OSI Model comparison

The Modbus is accessed on the master/slave principle, the protocol providing for one master and up to 247 slaves. Only the master
initiates a transaction. Transactions are either a query/response type where only a single slave is addressed, or a broadcast/no
response type where all slaves are addressed. A transaction comprises a single query and single response frame or a single broadcast
frame.
MODBUS is an application layer messaging protocol for client/server communication between devices connected on different types
of buses or networks. It is currently implemented using:
 TCP/IP over Ethernet.
 Asynchronous serial transmission over a variety of media (wire : EIA/TIA-232-E, EIA- 422, EIA/TIA-485-A; fiber, radio,
etc.)
 MODBUS PLUS, a high speed token passing network.

Figure: Modbus communication stack

Certain characteristics of the Modbus protocol are fixed, such as frame format, frame sequences, handling of communications errors
and exception conditions and the functions performed. Other characteristics are selectable. These are transmission medium,
transmission characteristics and transmission mode, RTU or ASCII. The user characteristics are set at each device and cannot be
changed when the system is running. The Modbus protocol provides frames for the transmission of messages between master and
slaves. The information in the message is the address of the intended receiver, what the receiver must do, the data needed to perform
the action and a means of checking errors. The slave reads the messages, and if there is no error it performs the task and sends a
response back to the master. The information in the response message is the slave address, the action performed, the result of the
action and a means of checking errors. If the initial message was of a broadcast type, there is no response from the slaves. Normally,
the master can send another query as soon as it has received the response message. A timeout function ensures that the system still
functions when the query is not received correctly. Data can be exchanged in two transmission modes:
 ASCII – readable, used e.g. for testing
 RTU – compact and faster; used for normal operation (hex)
The RTU mode (sometime also referred to as Modbus-B for Modbus Binary) is the preferred Modbus. The ASCII transmission
mode has a typical message that is about twice the length of the equivalent RTU message. The Modbus also provides an error check
for transmission and communication errors. Communication errors are detected by character framing, a parity check, a redundancy
check or CRC. The latter varies depending on whether the RTU or ASCII transmission mode is being used.
The Modbus protocol has two principal variants, Modbus Serial and Modbus TCP. In the Modbus Serial protocol, messages are
transmitted between a master and slaves (field devices) over serial lines using the ASCII or RTU transmission modes. The newer
Modbus TCP protocol provides connectivity within a Modbus network (master and its slaves) as well as for IP interconnected
Modbus networks (multiple masters, each communicating with possibly overlapping sets of slaves). The TCP variant enables a
master to have multiple outstanding transactions and permits a slave to engage in concurrent communications with multiple masters.
Attacks on Modbus systems and networks can produce effects ranging from sporadic disruptions of field devices (sensors and
actuators) to large-scale outages or even loss of control in the case of a spoofed master.

1.2.2.2 Modbus functions

All functions supported by the Modbus protocol are identified by an index number. They are designed as control commands for
field instrumentation and actuators and are as follows:
 Coil control commands for reading and setting a single coil or a group of coils
 Input control commands for reading input status of a group of inputs
 Register control commands for reading and setting one or more holding registers
 Diagnostics test and report functions
 Program functions
 Polling control functions
 Reset

1.2.2.3 Protocol specifics

This section reviews the Modbus protocol in detail and is broken down into the following sections:
 Message format
 Synchronization
 Memory location
 Function codes
 Exception responses

1.2.2.3.1 Message format

A transaction consists of a single request from the host to a specific secondary device and a single response from that device back to
the host. Both of these messages are formatted as Modbus message frames. Each such message frame consists of a series of bytes
grouped into four fields as described in the following paragraphs. Note that each of these bytes indicated here are in Hex format (not
ASCII).
Figure 15 – Format of Modbus message frame
The first field in each message frame is the address field, which consists of a single byte of information. In request frames, this byte
identifies the controller to which the request is being directed. The resulting response frame begins with the address of the
responding device. Each slave can have an address field between 1 and 247, although practical limitations will limit the maximum
number of slaves. A typical Modbus installation will have one master and two or three slaves. The second field in each message is
the function field, which also consists of a single byte of information. In a host request, this byte identifies the function that the
target is to perform.
If the target is able to perform the requested function, the function field of its response will echo that of the original request
otherwise, the function field of the request will be echoed with its most-significant bit set to one, thus signaling an exception
response. The third field in a message frame is the data field, which varies in length according to which function is specified in the
function field. In a host request, this field contains information the target may need to complete the requested function. In a target
field device response, this field contains any data requested by that host.
The last two bytes in a message frame comprise the error-check field. The numeric value of this field is calculated by performing a
cyclic redundancy check (CRC-16) on the message frame. This error checking assures that devices do not react to messages that
may have been changed during transmission.

1.2.2.3.2 Synchronization

In order to achieve reliable communication, the reception of a message must be synchronized with its transmission. In other words,
the receiving device must be able to identify the start of a new message frame. Under the Modbus RTU protocol, frame
synchronization is established by limiting the idle time between successive characters within a message frame. If three character
times (approximately three milliseconds) elapse without the receiving device detecting a new character, the pending message will be
flushed. The next byte will then be interpreted as the address field of a new message line.

1.2.2.3.3 Memory notation

The memory notation allows for four different data types: coils, discrete inputs, input registers and holding registers. Register
variables consist of two bytes, while coils and discrete inputs are single bytes( Table below)

Each function references only one type of data. This allows message-frame memory references to be expressed as offsets relative to
the lowest possible address for that data type. For example, holding register 40001 is referenced as 0000. The diagram below also
gives an easy reference to the Modbus data types.
Figure 16: Diagram illustrating Modbus Data types

Table: Modbus data types supported

1.2.2.3.4 Function codes

Each request frame contains a function code that defines the action expected for the target controller. The meaning of the request
data fields is dependent on the function code specified.
The following paragraphs define and illustrate most of the popular function codes supported. In examples which follow, the
contents of the message-frame fields are shown as hexadecimal bytes.
Table: Public Function Code definition

1.2.2.3.4.1 Read coil or digital output status (function code 01)

This function allows the host to obtain the ON/OFF status of one or more logic coils in the target device. The data field of the
request consists of the relative address of the first coil followed by the number of coils to be read. The data field of the response
frame consists of a count of the coil bytes followed by that many bytes of coil data. The coil data bytes are packed with one bit for
the status of each consecutive coil (1=ON, 0=OFF). The least significant bit of the first coil data byte conveys the status of the first
coil read. If the number of coils read is not an even multiple of eight, the last data byte will be padded with zeros on the high end.
Note that if multiple data bytes are requested, the low order bit of the first data byte in the response of the slave contains the first
addressed coil. In the following example, the host requests the status of coils AH (00011) and BH (00012). The target device’s
response indicates both coils are ON.
Figure: Example of read coil status

1.2.2.3.4.2 Read digital input status (function code 02)

This function enables the host to read one or more discrete inputs in the target device. The data field of the request frame consists of
the relative address of the first discrete input followed by the number of discrete inputs to be read. The data field of the response
frame consists of a count of the discrete input data bytes followed by that many bytes of discrete input data.
The discrete-input data bytes are packed with one bit for the status of each consecutive discrete input (1=ON, 0=OFF). The least
significant bit of the first discrete input data byte conveys the status of the first input read. If the number of discrete inputs read is
not an even multiple of eight, the last data byte will be padded with zeros on the high end. The low order bit of the first byte of the
response from the slave contains the first addressed digital input. In the following example, the host requests the status of discrete
inputs 10001 and 10002. The target device’s response indicates that discrete input 10001 is OFF and 10002 is ON.

Figure: Example of read input status

1.2.2.3.4.3 Read holding registers (function code 03)

This function allows the host to obtain the contents of one or more holding registers in the target device. The data field of the
request frame consists of the relative address of the first holding register followed by the number of registers to be read. The data
field of the response time consists of a count of the register data bytes followed by that many bytes of holding register data.
The contents of each requested register are returned in two consecutive register-data bytes (most significant byte first). In the
following example, the host requests the contents of holding register 40003. The controller’s response indicates that the numerical
value of the register’s contents is 2047. The first byte of the response register data is the high order byte of the first addressed
register.

Figure: Example of read holding register

1.2.2.3.4.4 Reading input registers (function code 04)

This function allows the host to obtain the contents of one or more input registers in the target device. The data field of the request
frame consists of the relative address of the first input register followed by the number of registers to be read. The data field of the
response frame consists of a count of the register-data bytes followed by that many bytes of input register data.
The contents of each requested register are returned in two consecutive register-data bytes (most-significant byte first). The range
for register variables is 0 to 4095. In the following example, the host requests the contents of input register 30001. The target’s
response indicates that the numerical value of that register’s contents is 03FFH, which would correspond to a data value of 25.6 per
cent (if the scaling of 0 to 102.4 per cent is adopted).
Figure: Example of reading an input register

1.2.2.3.4.5 Force single coil (function code 05)

This function allows the host to alter the ON/OFF status of a single logic coil in the target device. The data field of the request frame
consists of the relative address of the coil followed by the desired status for that coil. A status value of 65280 (FFOOH) will activate
the coil, while a status value of zero (0000H) will deactivate it. Any other status value is illegal. If the controller is able to force the
specified coil to the requested state, the response frame will be identical to the request. Otherwise an exception response will be
returned. If the address 00 is used to indicate broadcast mode, all attached slaves will modify the specified coil address to the state
required. The following example illustrates a successful attempt to force coil 00011 OFF.

Figure: Example of forcing a single coil

1.2.2.3.4.6 Preset single register (function code 06)

This function enables the host to alter the contents of a single holding register in the target device. The data field of the request
frame consists of the relative address of the holding register followed by the new value to be written to that register (most-
significant byte first). If the controller is able to write the requested new value to the specified register, the response frame will be
identical to the request. Otherwise, an exception response will be returned.
The following example illustrates a successful attempt to change the contents of holding register 40003 to 3072 (0C00 Hex). When
slave address is set to 00 (broadcast mode), all slaves will load the specified register with the value specified.

Figure: Example of presetting a single register

1.2.2.3.4.7 Read exception status (function code 07)

This is a short message requesting the status of eight digital points within the slave device. This will provide the status of eight
predefined digital points in the slave. For example this could be items such as the status of the battery, whether memory protect has
been enabled or the status of the remote input/output racks connected to the system.

Figure: Example of read exception status query message

1.2.2.3.4.8 Loopback test (function code 08)

The objective of this function code is to test the operation of the communications system without affecting the memory tables of the
slave device. It is also possible to implement additional diagnostic features in a slave device (should this be considered necessary)
such as number of CRC errors, number of exception responses etc. The most common implementation will only be considered in
this section; namely a simple return of the query message.

Figure: Loopback test message

1.2.2.3.4.9 Force multiple coils or digital outputs (function code 15)

This forces a contiguous (or adjacent) group of coils to an ON or OFF state. The following example sets 10 coils starting at address
01 Hex (at slave address 01) to the ON state. If slave address 00 is used in the request frame broadcast mode will be implemented
resulting in all slaves changing their coils at the defined addresses.
Figure: Example of forcing multiple coils

1.2.2.3.4.10 Force multiple registers (function code 16)

This is similar to the preset of a single register and the forcing of multiple coils. In the example below, a slave address 01 has 2
registers changed commencing at address 10.

Figure: Example of presetting multiple registers

1.2.2.3.4.11 Exception responses

Request frames containing parity or checksum errors are ignored – no response is sent by any device. If an otherwise valid request
frame contains an illegal request (one not supported by the target slave unit), an exception response will be returned to the host.
The four fields of an exception response contain
 The address of the responding controller
 The requested function number with its most-significant bit set to one
 An appropriate exception code
 The CRC-16 checksum
The following table lists most important exception codes that may be returned.
An example of an illegal request and the corresponding exception response is shown below. The request in this example is to REAL
COIL STATUS of points 514 to 521 (eight coils 00000 beginning an offset 0201H). These points are not supported in this particular
slave device.

Figure: Example of an illegal request

1.2.2.4 Modbus serial protocol

Modbus Serial protocol messages are transmitted between a master and slave devices over serial lines using the ASCII or RTU
transmission modes.

Figure: Modbus Serial Architecture

The messages have three components: (i) slave address, (ii) Modbus application protocol data unit (PDU), and (iii) an error
checking field. The slave address in a request message identifies the recipient; the corresponding address in a response message
identifies the responding slave. A unicast message has an address in the [1, 247] range that identifies an individual slave. A
broadcast message uses a slave address of zero. Values in the [248, 255] range are reserved addresses.
The Modbus PDU has two fields, a one byte function code and function parameters (maximum 252 bytes). The function code field
in a request message specifies the operation requested by the master; the corresponding field in the response message is used to
convey status information to the master as described in the above section. The function parameters field contains data pertaining to
function invocation (request messages) or function results (response messages).
Modbus function codes specify read and write operations on slaves, diagnostic functions and error conditions. Modbus has three
types of function codes: public codes, user defined codes and reserved codes. Public codes correspond to functions whose semantics
are completely defined in the Modbus standard. Valid public codes fall in the non contiguous ranges: [1, 64], [73, 99] and [111,
127]. User defined codes in the [65, 72] and [100, 110] ranges are not considered in the Modbus standard; their implementations are
left to vendors. Reserved function codes are public codes that may be used to ensure compatibility with legacy systems. Function
code values in the unused range [128, 255] indicate error conditions in response messages.
Response messages have the same structure as request messages. The Modbus specification defines positive and negative responses
to request messages. A positive response informs the master that the slave has successfully performed the requested action; in this
case, the function code of the request message is included in the response message. A negative or exception response notifies the
master that the transaction could not be performed by the addressed slave. The function code for a negative response is computed by
adding 128 to the function code of the request message; thus, function codes in the [128, 255] range denote error conditions. A
negative response also includes an exception code as a function parameter, which provides information about the cause of the error.
The Modbus specification defines nine exception responses whose format and content depend on the issuing entity and the type of
event producing the exception.

Figure: Modbus Function categories

1.2.2.5 Modbus TCP protocol

The Modbus TCP protocol provides connectivity within a LAN based Modbus network (a master and its slaves) as well as for IP
interconnected Modbus networks (multiple masters, each with multiple slaves). Modbus TCP extends its serial counterpart by
enabling a master to have multiple outstanding transactions, and a slave to engage in concurrent communications with multiple
masters. Figure below shows a master connected to multiple slaves via an IP network. Note that the master may also be connected to
other resources in the control center such as databases and historians. Modbus slaves listen for incoming TCP connections on port
502 (IANA assigned port) or optionally on additional ports. In a Modbus TCP transaction, the slave is designated as the server
because it performs the passive open operation on TCP; the Modbus master, which performs the active open operation on TCP, is
designated as the client. Once a TCP communication channel is established, Modbus roles cannot be changed on that channel;
however, multiple outstanding transactions can exist on the channel. A new communication channel must be opened to permit a
Modbus device to assume a different role.
Modbus TCP transactions are similar to their serial counterparts. Devices exchange PDUs, except that the transactions are
encapsulated in TCP messages. Consequently, a Modbus TCP PDU includes the Modbus application protocol (MBAP) in addition
to the Modbus application PDU used in the serial protocol.

Figure: Modbus TCP Architecture

The MBAP header has four fields: (i) transaction identifier, (ii) protocol identifier, (iii) length, and (iv) unit identifier. The
transaction identifier permits devices to pair matching requests and replies on a communication channel. The protocol identifier
indicates the application protocol encapsulated by the MBAP header (zero for Modbus). The length field indicates the length in
bytes of the remaining fields (unit identifier and PDU). The unit identifier indicates the slave associated with the transaction (this is
used only in legacy implementations). The Modbus TCP specification requires that only one application PDU be transported in the
payload of a TCP packet. Since application PDUs have a maximum size of 253 bytes and the length of the MBAP is fixed at seven
bytes, the maximum size of a Modbus TCP data unit is 260 bytes.
1.2.2.6 Attacks in Modbus Protocol

In general, attacks on Modbus systems and networks can be grouped into three categories: (i) attacks that exploit the Modbus
protocol specifications, (ii) attacks that exploit vendor implementations of the Modbus protocols, and (iii) attacks that target the
support infrastructure, which includes information technology, networking and telecommunications assets.
On comprehensive analysis of each protocol, four threat categories, interception, interruption, modification and fabrication were
analyzed for each of the primary targets. In the case of the Modbus Serial protocol, the primary targets are the master, field devices,
serial communication links and messages. The corresponding targets for Modbus TCP are the master, field devices, network
communication paths and messages. An example attack is the Direct Slave Control, an attack that involves locking out a master and
controlling one or more field devices, can be used to interrupt and modify a field device, as well as to fabricate a master.
The results of the attacks include accessing message or field device data, denying service to the master unit, field devices or
communication links or network paths, providing bad data or rewriting key data in the master unit, field devices or messages, and
seizing control of the master unit or field devices.
The attacks are divided into three groups:
(i) Attacks unique to the Modbus Serial protocol,
(ii) Attacks common to the Modbus Serial and TCP protocols, and
(iii) Attacks unique to the Modbus TCP protocol.

1.2.2.6.1 Serial only attacks

The attacks involve sending one or more fabricated Modbus messages with special function code and/or subfunction code
(parameter) values. The Modbus Serial attacks impact control system assets in various ways. Attacks on confidentiality involve
reading Modbus messages or obtaining configuration data from slave devices. Attacks on integrity involve inserting erroneous data
or reconfiguring slave devices. Attacks on availability cause slave devices to lose key functionality (e.g., the ability to read or
produce Modbus messages), or to reboot or crash. Here are some attacks in more detail.
 Diagnostic Register Reset: This attack sends a Modbus message with function code 08 and sub function code 0A, which
clears all the counters and the diagnostic register of the addressed field device. The attack changes the configuration of the
field device and impacts diagnostic operations, but does not affect control and communications functionality. An instance
of this attack is modification of a field device.
 Remote Restart: This attack sends a Modbus message with function code 08 and sub function code 01, which causes the
addressed field device to restart and execute its power up test. The addressed field device is rendered inoperable when
asked to restart repeatedly. Some instances of this attack are interruption and modification of a field device.
 Slave Reconnaissance: This attack on confidentiality sends a Modbus message with function code 17, which causes the
addressed field device to return status information. An instance is the interception of field device information.

1.2.2.6.2 Serial and TCP attacks

Attacks on confidentiality involve reading Modbus messages, obtaining network information, or obtaining configuration and other
data from slave devices. Attacks on integrity involve inserting erroneous data in Modbus messages or network traffic, modifying
communication paths, providing bad data to the master or reconfiguring slave devices. These attacks may also spoof the master unit,
field devices, network paths or messages. Attacks on availability result in denial of service of the master or slave devices; in
particular, slave devices may lose key functionality, reboot or crash. It is also possible to block Modbus messages and disable
communication links or network paths. The most serious attacks are those that disable or bypass the master unit and seize control of
field devices. Here are some attacks common to the Modbus Serial and TCP protocols in more detail.
Broadcast Message Spoofing: This attack involves sending fake broadcast messages to slave devices. The attack is difficult to
detect because no response messages are returned from the slaves to the master device. Two instances of this attack are interruption
and modification of a field device.
Baseline Response Replay: This attack involves recording genuine traffic between a master and a field device, and replaying some
of the recorded messages back to the master. Some examples of these attacks are interruption of a master, field device and message,
modification of a master and field device, and fabrication of a field device.
Direct Slave Control: This attack involves locking out a master and controlling one or more field devices. Some examples of these
attacks are interruption and modification of a field device, and fabrication of a master, which is the most serious of all the attacks.
Modbus Network Scanning: This attack involves sending benign messages to all possible addresses on a Modbus network to
obtain information about field devices. Examples are interception of field device data and interception of network topology
information.
Passive Reconnaissance: This attack involves passively reading Modbus messages or network traffic. Two instances of this attack
are interception of field device data and interception of network topology information.
Response Delay: This attack involves delaying response messages so that the master receives outofdate information from slave
devices. Four instances of this kind of attack are interruption of a field device and message, modification of a master and
modification of a field device.
Rogue Interloper: This attack involves attaching a computer with the appropriate (serial or Ethernet) adaptors to an unprotected
communication link. This “man in the middle” device can read, modify and fabricate Modbus messages and/or network traffic at
will. Instances of this most serious attack: interception of field device, network and message data; interruption of a master, field
device, network and message; modification of a master, field device, network and message; and fabrication of a master, field device,
network and message.

1.2.2.6.3 TCP only attacks

Attacks on confidentiality involve reading field device data, network traffic or messages. Attacks on integrity involve inserting
erroneous data in Modbus messages or network traffic, or reconfiguring master or field devices. It is also possible to spoof the
master or field devices. Attacks on availability can take down TCP/IP network connections, or cause the master or field devices to
lose key functionality, reboot or crash. The most serious attacks may seize control of the master and/or field devices. We discuss
four Modbus TCP attacks in more detail.
Irregular TCP Framing: Multiple Modbus messages cannot be placed in a single TCP frame. This attack injects improperly
framed messages or modifies legitimate messages to create improperly framed messages, which may cause a master unit or field
device to close a connection. Two instances of this attack are interruption of a master and interruption of a field device.
TCP FIN Flood: This attack launches a spoofed TCP packet with the FIN flag set after a legitimate Modbus message to a Modbus
client (master) or server (field device) to close the TCP connection. Four instances of this attack: interruption of a master,
interruption of a field device, interruption of a network connection, and interruption of a message.
TCP Pool Exhaustion: The Modbus TCP specification describes two classes of connection pools: priority connection pools and
non priority connection pools. Exhausting the connections in these pools prevents a Modbus device from accepting new
connections. The attack opens large numbers of TCP connections with a device using marked IP addresses corresponding to priority
connections and unmarked IP addresses corresponding to non priority connections. Note that network activity must be maintained in
all these connections to implement a denial of service attack. Four instances of this attack: interruption of a master, interruption of a
field device, interruption of a network path, and interruption of a message.
TCP RST Flood: This attack launches a spoofed TCP packet with the RST flag set after a legitimate Modbus message to a Modbus
client (master) or server (field device) to close the TCP connection. Four instances of this attack: interruption of a master,
interruption of a field device, interruption of a network connection, and interruption of a message.
Impacts of the above attacks are loss of confidentiality occurs when an attack reveals information about field devices, network
topology or messages. Loss of availability occurs when operators are unable to obtain accurate and timely information about a
process either due to denial of service or data modification; attacks interrupt field devices, network connectivity or messages, as
well as those that modify the master or involve the fabrication of field devices. The worst category, loss of integrity, occurs when an
attacker spoofs the master and/or seizes control of the process; attacks modify field devices, network paths or messages as well as
those that result in the fabrication of the master, network paths or messages.

1.2.2.7 Countermeasures for enhancing Modbus security

The common security threats among the ones listed above are as follows.
Unauthorized Command Execution: The lack of authentication of the master and slaves means that an attacker can send forged
Modbus messages to a pool of slaves. In order to execute this attack, the attacker must be able to access the network that hosts the
SCADA servers or the field network that hosts the slaves.
Modbus Denial-of-Service Attacks: An example attack involves impersonating the master and sending meaningless messages to
RTUs that cause them to expend processing resources.
Man-in-the-Middle Attacks: The lack of integrity checks enables an attacker who has access to the production network to modify
legitimate messages or fabricate messages and send them to slave devices.
Replay Attacks: The lack of security mechanisms enables an attacker to reuse legitimate Modbus messages sent to or from slave
devices.
Firewalls and intrusion/anomaly detection systems can defend against ad hoc exploits that target Modbus vulnerabilities. However,
it is always possible to circumvent these security controls. The best way to address the security threats is to solve them at their
origin – by attempting to “repair” the security holes in the Modbus protocol. But such a solution is difficult to implement because it
requires significant changes to the control system architecture and configuration. Instead a practical approach is being implemented
in which a small number of security mechanisms are introduced into the protocol to protect against the attacks.

1.2.2.7.1 Secure Modbus Protocol

A communications protocol is generally considered to be “secure” if it satisfies traditional security requirements such as
confidentiality, integrity and availability.
In other words, a “secure” Modbus protocol should guarantee that:
 No unauthorized entity is allowed to access the content of a message.
 No unauthorized entity is allowed to modify the content of a message.
 No entity is allowed to impersonate another entity.
 No entity is allowed to negate a performed action.
 No entity is allowed to reuse a captured message to perform an unauthorized action.
The original Modbus Serial protocol defines a simple protocol data unit (PDU), which is independent of the underlying
communication layer. The mapping of Modbus messages to specific buses or networks introduces additional fields in an application
data unit (ADU).
The Modbus TCP protocol introduces a dedicated Modbus application protocol (MBAP) header. The Slave Address field in a
Modbus Serial message is replaced by a one-byte Unit Identifier in the MBAP Header. Also, the error checking field is removed and
additional length information is stored in the MBAP header to enable the recipient to identify message boundaries when a message
is split into multiple packets for transmission. All Modbus requests and responses are designed so that the recipient can verify that
the complete message is received. This is accomplished by simply referring to the function code for function codes whose Modbus
PDUs have fixed lengths. Request and response messages with function codes that can carry variable amounts of data incorporate a
field containing the byte count. The proposed Secure Modbus protocol is intended to satisfy the following security requirements:
Integrity: The integrity of a Secure Modbus packet is guaranteed using a secure hashing function. The well-known SHA2 hash
function is used to compute a secure digest of the packet, which is transmitted along with the packet. The integrity of the received
packet is verified by the receiver who computes the SHA2 value of the received packet and compares it with the received digest.
Authentication: The integrity mechanism described above does not prevent an attacker from creating a malicious Modbus packet,
computing its SHA2 digest, and sending the malicious packet and the digest to the receiver. To address this issue, the Secure
Modbus protocol employs an RSA-based signature scheme. Specifically, the originator of the Secure Modbus packet computes the
SHA2 digest, signs the digest with its RSA private key, and sends the packet and the signed digest to the receiver. The receiver
verifies the authenticity of the digest (and the packet) using the sender’s public key. Thus, the receiver can ensure that the Secure
Modbus packet was created by the purported sender and was not modified en route.
Availability: The RSA-based signature scheme also provides an availability mechanism – only the owner of the RSA private key
could have sent the Secure Modbus packet.
Replay Protection: The SHA2 hashing and RSA signature schemes do not prevent an attacker from re-using a “sniffed” Modbus
packet signed by an authorized sender. Thus, the Secure Modbus protocol needs a mechanism that enables the receiver to
discriminate between a “new packet” and a “used packet.” This is accomplished by incorporating a time stamp (TS) in the Secure
Modbus application data unit (Figure below). The time stamp is used by the receiver in combination with an internal “time window”
to check the “freshness” of the received packet. Our initial solution employed a simple two-byte sequence number and provided all
Modbus devices with time windows of limited size to verify freshness. However, this solution was neither elegant nor completely
secure. Consequently, our current implementation uses NTP (Network Time Protocol) time stamps that facilitate the evaluation of
freshness with high precision. The Network Time Protocol (NTP) is a protocol for synchronizing the clocks of computer systems
over packet switched, variable- latency data networks. Of course, employing NTP time stamps requires an NTP server in the
SCADA architecture to provide a reliable clock for all communicating devices.

Figure: Secure Modbus application data unit

The Secure Modbus protocol satisfies the minimum requirements of a “secure” protocol. However, it is just as important to ensure
that the protocol can be implemented efficiently in real-world SCADA environments. Secure Modbus can be readily deployed in
SCADA systems with adequate computing resources, network bandwidth and modern, upgradeable slave devices. However, many
critical infrastructure assets employ decades-old equipment; therefore, it is important to ensure that legacy systems can be retrofitted
(at low cost) to support Secure Modbus.
A Modbus Secure Gateway can be implemented to facilitate the deployment of Secure Modbus in legacy SCADA environments.
Figure below presents a schematic diagram of the Modbus Secure Gateway. It is a dedicated multi-homed gateway that hosts a
TCP/IP interface connected to the process network and a set of point-to-point TCP or serial links connected to legacy slaves.
Figure: Modbus Secure Gateway
The Modbus Secure Gateway operates as follows:
 When the Modbus Secure Gateway receives a packet on the process network interface:
o It accepts only authenticated Secure Modbus TCP traffic from allowed masters.
o It extracts the Modbus packet from the Secure Modbus packet.
o It forwards the packet to the appropriate slave using the related point-to-point (serial or TCP) link.
 When the Modbus Secure Gateway receives a packet on one of the point to point links connected with a slave:
o It creates a Secure Modbus packet containing the received original Modbus packet.
o It signs the packet digest with the private key associated with the slave.
o It forwards the new packet to the appropriate master through its process network interface.
The Modbus Secure Gateway constitutes a single point of failure in the SCADA architecture. Therefore, it should be installed only
when the “pure” Secure Modbus implementation is not feasible.
The steps involved in sending and verifying a Secure Modbus request message:
 The master creates a valid Modbus request (Mreq) with a time stamp and the serial slave address.
 The master computes the digest of the Modbus request, encrypts the digest with its private key ( pKm) and sends the request
along with the encrypted digest to a slave or to the Modbus Secure Gateway:
C = [TS|Modbus]{SHA2(TS|Modbus)}pKm
 The slave or the Modbus Secure Gateway verifies that the Modbus request is genuine using the master’s public key (sKm):
Mreq = {C}sKm
Note that after verifying that the request is genuine, the Modbus Secure Gateway reads the unit identifier in the MBAP header and
sends the Modbus request to the addressed slave. Similar steps are involved when a slave sends a response to the master.
Secure Modbus Implementation
The basic communication layer between the operating system and a Secure Modbus device is implemented using sockets. All
Secure Modbus protocol communications send and receive data via sockets. The TCP/IP library only provides stream sockets using
TCP and a connection-based communication service. Consequently, sockets are created using the socket() function, which returns a
number that is used by the creator to access the socket. Figure below presents the architecture of the Secure Modbus module that
implements socket-based communications. The TCP/IP level manages the establishment and termination of connections, and the
data flow in an established connection.
Figure: Secure Modbus Module

The TCP Stream Builder sets up the connection parameters according to the following constraints:
KEEP-ALIVE: Client-server applications use the KEEP-ALIVE time to detect inactivity in order to close a connection or to identify
a communication problem. Using a short KEEP-ALIVE time can cause good connections to be dropped.
TCP-NODELAY: The TCP-NODELAY parameter is used for real-time systems.
TIME OUT CONNECTIONS: By default, a TCP connection is timed out after 75 seconds. The default value may be adjusted
according to the real-time constraints imposed by the system.
The Secure Modbus module has four main components:
 Modbus Stream Builder: This component extracts the Secure Modbus packet contained in the TCP payload and sends it
to the RSA Encryption/ Decryption Unit that verifies the authenticity of the SHA2 digest. The Modbus Stream Builder then
sends the digest to the SHA2 Validator to verify packet integrity. Finally, it sends the time stamp to the Time Stamp
Analyzer to verify the freshness of the data. If all these conditions are satisfied, the Modbus Stream Builder sends the
Modbus packet to the appropriate application.
 RSA Encryption/Decryption Unit: This unit uses the public key of the sender to verify the authenticity of the digest and
the private key of the sender to sign the hash message.
 SHA2 Validator: This component calculates and validates the hash values of Secure Modbus request and response
messages.
 Modbus ADU Builder/Reader: This unit constructs and manages Secure Modbus application data units (ADUs). Also, it
communicates with the SHA2 Validator and the RSA Encryption/Decryption Unit to authenticate packets.
 Time Stamp Analyzer: This component verifies the validity of time stamps using time windows or an NTP service.

The Secure Modbus protocol was tested using an experimental power plant testbed. Figure below shows the components of the
SCADA testbed.
The principal components are:
 Field Network: This network interconnects the sensors and actuators that interact with electromechanical devices in the
power plant.
 Process Network: This network hosts all the SCADA systems. Plant operators use these systems to manage the power
plant, send commands to sensors and actuators in the field network, and gather plant data and status information.
 Observer Network: This is a network of sensors that gathers information about the system during the experiments.
 Horizontal Services Network: This network provides support features such as backup and disaster recovery.
 Intranet: This internal private network connects company PCs and servers. Some portions of the intranet are connected to
the power plant via the process network.
 Data Exchange Network: This network hosts data exchange servers that receive data from the process network and make
it available to operators who use the corporate intranet.
Two experiments were conducted to evaluate the performance of the Secure Modbus protocol. The first experiment examined
the latency resulting from the use of the SHA2 hashing and RSA-based signature schemes. The second examined the increased
size of Secure Modbus packets for various function codes.
Table 1 compares the communication latency for Modbus TCP and Secure Modbus. The first set of results, corresponding to a
master scan rate of 500 ms and a connection timeout of 1,200 ms, show a latency of 26 ms for Modbus and 27 ms for Secure
Modbus – a negligible difference. A negligible latency difference of 2 ms (29 ms for Modbus TCP and 31 ms for Secure
Modbus) is also observed for a master scan rate of 200 ms and a connection timeout of 500 ms. Table 2 compares the size of
Modbus TCP and Secure Modbus packets for four function codes. Secure Modbus packets are larger than the corresponding
Modbus TCP packets. However, the increased size is not a significant issue even for SCADA networks with low bandwidth.
 Table 1: Comparison of communication latency

Table 2: Comparison of packet size

The Secure Modbus protocol offers key security features without introducing significant overhead that can impact real-time
performance. The Modbus Secure Gateway facilitates the deployment of Secure Modbus in legacy SCADA environments. While
the new protocol helps protect against several attacks, it does not address scenarios where an attacker seizes control of a master and
sends malicious Modbus messages to slave devices. To address this attack scenario, a dedicated filtering unit will identify suspect
Modbus messages. Below is the description of the development of the filtering unit and its features.
Here below is the description of the Secure survivable SCADA architecture to combat attacks wherein attacker is able to send a
command packet to a slave. Such packet contains a command that should force a slave to open a valve. The command, per se, is licit
and a traditional firewall will allow it to pass. A firewall conceived for SCADA systems should then be able to take in
consideration, while analyzing a packet, the architecture of the field network that it is monitoring, in order to detect if a licit packet,
when the system is in a particular state, could be or not authorized. So here is the solution.
1) The master according to the new protocols specifications compose the Modbus request(Mreq) with the time stamp and the
slave’s address
2) The master authenticates the Modbus request with his private key pKm and send it the Filtering Unit
Mr = Enc {(TS|Modbus), pKm}
3) The FU’s validates the Modbus request using the Master’s public key (PKm)
Mreq = Dec {C, PKm}
4) The Filtering Unit (FU) analyzes the Modbus request destination and function, if the packet contains a forbidden address or
a forbidden instruction the FU adds it into a dedicated stack of “malformed packets”.
5) The Filtering Unit authenticates the Modbus request with his private key pKf and sends it to a slave’s address.
MrF = Enc {Mr, pKf}
6) The slave (PLC) validates the filtered Modbus request (MrF) by the Filtering Unit’s Public Key (PKf )
Mr = Dec {MrF,PKf }
7) The slave validates the Modbus request (Mreq) with the Master’s Public Key
Mreq = Dec {Mr,PKm}
8) The slave executes the command.

Nevertheless, the presented architecture has still a security hole: the possible collusion between the filtering unit and a corrupted
master. If an attacker is able to corrupt both the Master and the FU, the corrupted FU will allow dangerous command packets
created and sent by a corrupted master to reach the target slave.
In order to deal with this problem, a Cyber-Diversity paradigm typical of the survivability world and the concept of K-Relisience
has been adopted. In other words, instead of using a single Filtering Unit for checking the control traffic, a mesh of N filtering units,
each one deployed on a different hardened O.S. with different configurations was inserted between the master and the slaves. The
master/slave when sending a packet to the counter part, forwards the signed version of the packet (according to what described
before) to P random filtering units of the mesh, where P is a number bigger than a pre-defined integer K. Every FU will check the
received packet, and if safe, will send it (according to the previously described protocol) to the destination (a slave or a master).
When the receiver, after checking the authenticity of the packet, receives at least K packets of the P packets sent originally (i.e. at
least K FU have approved the packet), it will execute the command. By adopting this schema we mitigate the risk of collusion
between master and filtering units. In fact we can say that an attacker, to successfully order a slave to execute a malicious command,
has to corrupt at least K different filtering units, i.e. the architecture can be defined K resilient. Figure below shows in detail the
proposed architecture.

Figure: High level Secure Survivable architecture

The proposed architecture is able then to avoid the following threats:
1. Unauthorized Command Execution: the signature schema of the protocol avoids unauthorized actors to send directly to
the slaves any kind of command. Only who has a licit private key is allowed to sign and then to make executable a packet.
2. Man-in-the-Middle-attack: The signature mechanism allows to preserve the integrity of the packet. In this way no one
will be able to intercept and modify on-fly a packet flowing between Master and Slave.
3. Replay attack: the time-stamp avoids any kind of replay attack.
4. Malicious packets via corrupted Master: the architecture do not protect the Master from the risk of corruption, however,
through the use of the Filtering Units, will prevent a Malicious Master from sending dangerous streams of packets.
5. Master-FU collusion: by introducing K/N architecture, a command will be executed only if the slave receives a validated
packet from at least K over N Filtering Units. In this way the risk of Master-FU collusion will be mitigated since the
attacker in order to exploit the attack will need to corrupt at least K+1 Filtering Units.
Prototype Implementation
The selection of the signature scheme to adopt is a relevant issue in the proposed architecture. In fact, the computational demand of
the scheme could have an impact on the performance of the SCADA system. Three public key crypto-systems: RSA, DH/DSA and
ECDSA are available. Since the different actors that need to sign/verify the packets are well recognized components of the
Production Systems (i.e. the Masters and the pool of Slaves) and they are machines which usually stand altogether in the same,
physically protected, industrial installation, our hardened protocol does not need to support an automatic key exchange protocol (the
public keys generated for each entity can be easily manually installed in the key-ring of all master/slave in the process network).
Moreover, the typical size of a ModBUS packet is rather limited (on average less of 20 bytes including the ModBUS data payload).
In light of these considerations, RSA scheme is used, signing directly, the whole ModBUS packet before encapsulating it into the
TCP payload. The basic communication layer between the operating system and the Modbus device is guaranteed by a socket,
which manage the keep-alive messages, the TCPNODELAY and the TIME-OUT connections.
Master/slave unit
The Master/Slave unit contains the module in charge to build and interpret Modbus functions, the module in charge to encrypt and
decrypt by RSA algorithm and a series of modules for validating the packets. Here below we will see in details the most important
modules.
 Modbus Stream Adapter: It extracts the Modbus packet contained in the TCP payload by sending it to the RSA enc/dec,
and then validates it by sending the Modbus time stamp to the TS Analyser.
 RSA enc/dec: It utilizes the public key to verify the packets authenticity and the private key to encrypt the Modbus
Application Data Unit
 Modbus ADU Builder/Reader: It builds and manages the Modbus Application Data Unit, communicating with the RSA
enc/dec for authenticating the packets and use the Message stack to store all the messages coming and validate from the
Intrusion Detection System.
 TS Analyzer: It verifies the time stamp validity by using a time-window.
Filtering Unit (FU)
As showed in figure below the FU prototype we have developed is composed of the following elements:

Modbus Module:
 Rules DB: It stores the rules related to the authorized “behaviours” (e.g. Master can send an “open valve” command to the
RTU A and cannot send such a command to the RTU B.). The rules are actually represented by using an adapted version of
XML, with reference to object like RTU/PLC types, Masters, Commands and Data.
 System Description DB: It contains the description of the system to be analyzed. The system is described by means of an
XML file. Such DB is used in cooperation with the Rules DB and the Event Tracker to correlate the actions performed in
the process network, for detecting malicious behaviors.
 Events tracker (ET): It is used by the Rule Analyzer to correlate the events. ET is implemented as a multi stack structure
with a limited size (the events are maintained into the stack only for a limited amount of time).
  Modbus Analysis Engine (MAE): This engine brings together the information coming from the System Description, the
Rules DB and the event tracker in order to correlated the events and identify malicious behaviors.
 Alert Manager: It is in charge of notifying to the operator an eventual alert or to send the alert to a dedicated database.
Prototype Test
To verify the efficiency and validity of the new Secure Modbus architecture some tests were carried out in the laboratory (which
replicates the process network of a typical power plant). The focus was to understand whether the signature and mesh of FU could
cause significant delays in a real time environment. The size of the new Secure Modbus packets and the latency resulting from the
use of the RSA signature scheme and from the filtering time was taken into consideration.
In the next two tables we analyze the difference between Modbus and “Secure Modbus”. Both tests evidence how, the encryption
doesn’t change significantly the latency of the information flows in different settings condition. As shown in table 2 the size of the
new Secure Modbus packets don’t suffer any significant variation.

Table 1: Communication latency with Modbus and Secure Modbus with a master scan rate of 500ms and a connection timeout of
1200ms

Table 2: Modbus/TCP and Secure Modbus/TCP packets size, tested with different functions
Table 3 lists the differences between the FU architecture with Modbus protocol and with Secure Modbus protocol. The same table
magnifies the delay introduced in the communication with the introduction of the FU units (12-13ms).
Obviously the new FUs introduce a delay in the communication process, however almost all SCADA systems will not significantly
be affected from this delay, considering the common scan rate in real time systems (200ms to 500ms). By comparing the data in
tables 1 and 3 it is possible to see that the additional delay introduced is around 10 msec.

Table 3: Communication latency in the different communications steps

A series of attacks were performed to check whether the new FU is able to identify and block illicit commands. By using the
Malsim framework, a set of malware able to perform the described attacks were developed. The attacks were deployed against a
normal SCADA architecture, protected by two firewalls (the classical iptables and a WatchGuard FW.) and against the “survivable
SCADA system”. The results of the tests showed that while the two traditional firewalls failed in protecting the SCADA system, all
the attack scenarios have been identified and blocked by our prototype.