Sensors 22 08024 v2

sensors
Article
Enhanced Modbus/TCP Security Protocol: Authentication and
Authorization Functions Supported
Tiago Martins 1 and Sergio Vidal Garcia Oliveira 1,2, *
1 Departamento de Engenharia Elétrica, Universidade do Estado de Santa Catarina, Joinville 89219-710, Brazil
2 Departamento de Engenharia de Telecomunicações, Elétrica e Mecânica, Universidade Regional de Blumenau,
Blumenau 89030-000, Brazil
* Correspondence: sergio_vidal@ieee.org
Abstract: The Zero Trust concept is being adopted in information technology (IT) deployments, while
human users remain to be the main risk for operational technology (OT) deployments. This article
proposes to enhance the new Modbus/TCP Security protocol with authentication and authorization
functions that guarantee security against intentional unauthorized access. It aims to comply with the
principle of never trusting the person who is accessing the network before carrying out a security
check. Two functions are tested and used in order to build an access control method that is based
on a username and a password for human users with knowledge of industrial automation control
systems (IACS), using simple means, low motivation, and few resources. A man-in-the-middle
(MITM) component was added in order to intermediate the client and the server communication
and to validate these functions. The proposed scenario was implemented using the Node-RED
programming platform. The tests implementing the functions and the access control method through
the Node-RED software have proven their potential and their applicability.
Keywords: cybersecurity; Modbus; Zero Trust; IIoT; industry 4.0; automation; access control; RBAC;
IEC 62443
Citation: Martins, T.; Oliveira, S.V.G.

Enhanced Modbus/TCP Security
Protocol: Authentication and 1. Introduction
Authorization Functions Supported.
The Industrial Internet of Things (IIoT) enables the development of factories, electrical
Sensors 2022, 22, 8024. https://
grids, and other intelligent systems, which creates market opportunities for equipment
doi.org/10.3390/s22208024
manufacturers, internet providers, and software developers. In the coming years, sensors,
Academic Editor: Radek Fujdiak machines, objects, and IIoT devices will all be connected, generating 45% of all internet
Received: 16 September 2022
traffic. Of these, 37% will be generated by things in the manufacturing area and 7% will be
Accepted: 12 October 2022
generated by electricity-related things [1,2].
Published: 20 October 2022
An IIoT system connects the industrial control systems with analytical, enterprise,
and autonomous systems. By optimizing the operation and enabling the control, the
Publisher’s Note: MDPI stays neutral
collaboration, and the decision making, autonomous equipment and business processes
with regard to jurisdictional claims in
can evolve manufacturing into a new industrial era, which is known as the Industry 4.0 [3].
published maps and institutional affil-
With Industry 4.0, industrial devices are increasingly connected to the internet and
iations.
corporate intranet in order to provide real-time information for their applications and users,
and, therefore, are consequently more exposed to cyber threats [4].
Operational technology (OT) systems differ from traditional information technology
Copyright: © 2022 by the authors.
(IT) systems because they use sensors and actuators in industrial environments. These
Licensee MDPI, Basel, Switzerland. interact with the real world, in which uncontrolled changes can generate dangerous situ-
This article is an open access article ations in the field. This potential risk elevates the importance of these systems’ security,
distributed under the terms and reliability, privacy, and resiliency above the levels that are expected in many traditional IT
conditions of the Creative Commons environments [3].
Attribution (CC BY) license (https:// Being one of the pillars of Industry 4.0 [5], cybersecurity is embryonic for IACS
creativecommons.org/licenses/by/ (industrial automation and control systems). With the digital transformation, the industry
4.0/). started a race to offer digital services to its customers, in which the equipment supporting
Sensors 2022, 22, 8024. https://doi.org/10.3390/s22208024 https://www.mdpi.com/journal/sensors

Sensors 2022, 22, 8024 2 of 20
legacy communication protocols, such as Modbus, which until then were isolated, began to
be exposed in order to offer services such as real-time monitoring, remote’s startup, and
assistance [6]. This ability to remotely control the two-way flow of information has many
advantages but makes systems vulnerable to cyber-attacks.
In the OT domain, concepts such as availability, integrity, and confidentiality (AIC)
define cybersecurity and differ from IT, as the availability is more critical than the data
confidentiality [3].
State-of-the-art research presents individuals as the main risk of compromising cy-
bersecurity in OT [7,8] because the vast majority of industrial communication protocols
were not designed to ensure the cybersecurity of the communication between devices,
making the access control mechanisms in industrial devices limited and unable to em-
ploy role-based access control (RBAC) concepts and protocols with authentication and
authorization capabilities.
Modbus is a client-server application protocol that allows communication between
millions of automation devices. Nevertheless, unfortunately, it lacks basic security mech-
anisms, which leads to several vulnerabilities. When it is correctly used, because it does
not allow for the construction of robust access control, it allows the alteration of registers,
either mistakenly or maliciously, by intruders or simple system operators. Furthermore, it
is a protocol that lacks encryption, authentication, and authorization functions. It allows
its exploitation by malicious software or unauthorized users (hackers), as it can easily
be intercepted and altered in the middle of communication (man-in-the-middle attack),
sending malicious (false command injection), malformed (false access injection), or delayed
(replay attacks) data packets that lead to a denial of service (DoS) of the system [9].
The Zero Trust concept [10] is disseminated in IT. At the same time, it is not uncom-
mon in the OT domain for people to have more access privileges than are necessary for
their work, due to the low quality of access segmentation that is available by the current
mechanisms that are applied to industrial devices [7]. In the Zero Trust Model, security
professionals must eliminate the idea of untrusted networks and trusted networks (internal
networks), as it considers all network traffic to be untrusted and upholds the following
three fundamental principles: all entities are untrusted by default, the least privilege access
is enforced, and comprehensive security monitoring is implemented [10,11].
Therefore, this work aims to improve the industrial Modbus protocol in order to enable
the creation of access control mechanisms in industrial devices that allow individuals to
remain to be the main security risk for the IACS. In order to achieve this, the validation
of the feasibility of performing effective access control for human users is needed. It is
based on a username and a password, against access attempts and casual unauthorized use,
using simple means, a low level of resources, and low motivation, for IACS that provide
human user input interfaces, such as HMI or SCADA systems, that are connected through
industrial Ethernet networks through the protocol.
The influential authors in the automation area argue that, instead of raising the cyber-
security maturity of the Modbus protocol, organizations should invest in new technologies
that provide security by design, such as OPC-UA, for the protocol replacement [12]. How-
ever, because it is widespread in the industry, the option to provide security to the protocol
is a solution that many organizations are likely to adopt [13].
Stuxnet [14], which was the first malware to successfully attack an industrial control
system (ICS) in 2010, infected Windows-based computers on any control or SCADA system;
it was used to disrupt the uranium enrichment process at the Iranian nuclear facility in
Natanz. Since Stuxnet, many works have been published in order to raise the Modbus
protocol’s cybersecurity maturity. A solution using integrity mechanisms through the SHA2
algorithm, authentication through RSA, and non-repudiation and anti-replay through the
timestamp is presented in [15]. Another proposal that is based on SCTP (stream control
transmission protocol) and HMAC (hash-based message authentication code), which is
called ModbusSec, is presented in [16]. However, both of these works do not consider the
confidentiality requirement for Modbus messages, as they are usually implemented using
Sensors 2022, 22, 8024 3 of 20
cryptography, which is expensive and presents a considerable overhead that can affect the
performance in real-time communication [15,16].
Assertions are no longer true because of the advancement of technology and the
possibility of using electronic components that provide encryption based on hardware
such as TPM (trusted platform module) [17]. The cost is no longer a problem, and its use
became viable for communication, as presented in [18], in which the author applies the TLS
(transport layer security) protocol as a solution to Modbus security problems and presents
experimental results that reveal the negligible impact for security applications in power
grids. Additionally, in [19] the Modbus-S protocol is proposed, together with the addition
of a security gateway to IACS, which was designed based on the original Modbus TCP
protocol, which uses a symmetric key algorithm in order to guarantee data confidentiality
and also ensures data uniqueness through a hash algorithm-based synchronization mecha-
nism, integrity through a digital signature algorithm, and function code abuse through a
“White List” filtering mechanism that is used to manage the function codes. These have
been confirmed by the Modbus organization itself, which in the same year adopted the TLS
protocol in place of the TCP (transmission control protocol) protocol in order to support
this new reality in the industry through the publication of the new protocol specification.
Named Modbus/TCP Security, this new variant guarantees the integrity and the
confidentiality of the session that is established between the client device and the server
through PKI (public key infrastructure) and also proposes the transmission of RBAC (role-
based access control) information using X.509v3 certificate extension [20]. The resources
and new functionality are the objects of study by [13], which seek to contextualize the
construction of the RBAC model through applying such specifications.
However, our understanding is that such an approach has limitations regarding the
identification and the authentication of the user who performs the procedures through the
interfaces that allow the iteration of human users, as they do not guarantee non-repudiation
since it is not possible to validate who owns the certificate in cases where the secure session
is established between IACS system components.
It is crucial to validate whether it is possible to enhance the Modbus/TCP Security
protocol with authentication and authorization functions in order to build access control
and enforce the least privilege for human users. In particular, once a secure and encrypted
session is established between the client and the server device, as specified by the protocol,
we need to identify and authenticate all of the users that make requests to the server
device, whether they are humans, processes, or systems. Our approach was to build an
authentication function, through user-defined functions that are provided by the Modbus
protocol, in order to identify, authenticate, and return an authenticator for the given system
user. A second user-defined function is built in order to encapsulate the original request
and to carry out the authorization control. The authentication enables the identification of
the user and the segmentation of accesses by the device. This is presented in the Enhanced
Modbus/TCP Security Protocol chapter, together with a brief explanation of the Modbus
protocol. This was followed by our proposal to implement the new functions in order to
build an access control method for human users in compliance with the first security level
of the IEC 62443-4-2 standard [21]. In order to evaluate our implementation proposal, we
will deploy it on the Node-RED programming platform [22] to finally provide the tests, the
discussion of the results, the conclusions, and the future research lines.
2. Other Related Works

Studies on the smart grid concept cover encryption, intrusion detection, prevention,
privacy, and trust. In [23], a literature review that is related to trust in smart grid is
presented. The definitions of trust guided this categorization according to the literature
and NIST’s priority areas and conceptual domains. A new trust model for substations
that detects attacks inside of the substation is also presented and tested. Using the model,
the authors test the work on two publicly available datasets using three types of tests.
External testing is where purely rogue devices (non-compromised substation devices) are
Sensors 2022, 22, 8024 4 of 20
not considered to be part of the substation network. The second is the internal test, where
all devices are considered to be part of the substation network. The final test is the internal
test with the IP–MAC block that takes the second test position but blacklists any device
that sends a malicious message.
The intrusion detection system (IDS) for smart grid is presented in [24,25]. In the
first study, an anomaly-based system called ARIES (smart grid intrusion detection system)
can efficiently protect smart grid communications by combining three detection layers
that are dedicated to recognizing potential cyber-attacks and anomalies against network
flows, Modbus/TCP packets, and operational data. The second study proposes an IDS
called MENSA (anomaly detection and classification) that adopts a new autoencoder-
generative adversarial network (GAN) architecture to detect operational anomalies and
classify Modbus/TCP and Distributed Network Protocol 3 (DNP3) cyber-attacks. The
implemented anomaly detection and classification model detected thirteen cyber-attacks
on Modbus/TCP, five cyber-attacks on DNP3, and possible anomalies that were related to
operational data (i.e., time series electricity measurements). Moreover, its efficiency was
validated and evaluated in a smart grid laboratory, a substation, a hydroelectric plant, and
a power plant.
Industrial communication is characterized by high regularity, while cyclicality creates
another dimension in order to study deviations. These resources are used by [26] in
order to present a method for detecting anomalies in cyclic communication using the
Modbus protocol.
Production systems are not ideal or not available for such an assessment due to the
possible impacts and disruptions. The authors of [27] propose a structure called the virtual
operational technology network (VOTNet), which consists of a power system, a process
network, a communication network, an automation network, and a business network for
cybersecurity assessment in the automation of security systems energy.
In [28], the authors developed and validated a test bench for conducting cybersecurity
assessments in nuclear power plants. The approach allows the simulation of several
cyber-attack scenarios against a simulated nuclear power plant (NPP) communicating
with its supervisory system (SCADA/HMI) through the Modbus/TCP protocol. It also
demonstrated how to use the environment to generate the datasets that are needed for
intrusion detection studies.
Finally, in [9], a framework is developed to prevent false command injection, false
access injection, and replay attacks in the Modbus protocol in SCADA systems. The
framework was developed with a frame filtering module in order to protect the PLC
against unauthorized access attacks and a second module was developed to detect replay
attacks in the Modbus protocol.
3. Enhanced Modbus/TCP Security Protocol

The most used and disseminated information security standard in the world is
ISO/IEC 27001:2013 [29], which is considered to be an international reference for in-
formation security management, just as ISO 9001 is the international reference for in-
formation security management quality. However, when it comes to cybersecurity for
industrial automation and control system (IACS) devices, the IEC 62443-4-2 standard must
be considered.
The standard consists of the following seven fundamental requirements: (a) The
identification and authentication control specifies that all users (humans, software processes,
and devices) must be identified and authenticated before accessing IACS. (b) The use control
specifies that once the user is identified and authenticated, the device must be enabled
to restrict the allowed actions to its authorized use, to protect itself from unauthorized
actions, and to verify that the necessary privileges have been granted before allowing
a user to perform the actions. (c) The system integrity seeks to prevent unauthorized
manipulation or alteration of the device before and during its operation. (d) The data
confidentiality guarantees the confidentiality of data that are transmitted through the
enabled to restrict the allowed actions to its authorized use, to protect itself from unau-
thorized actions, and to verify that the necessary privileges have been granted before al-
lowing a user to perform the actions. (c) The system integrity seeks to prevent unauthor-
Sensors 2022, 22, 8024 ized manipulation or alteration of the device before and during its operation. (d) The5data of 20
confidentiality guarantees the confidentiality of data that are transmitted through the
communication channels and stored in the device’s memory, preventing the dissemina-
tion of unauthorized
communication channels information.
and stored(e) Thedevice’s
in the restricted data flow
memory, seeks to
preventing thesegment IACS
dissemination
through zones and conduits in order to limit unnecessary
of unauthorized information. (e) The restricted data flow seeks to segment IACS throughdata flows. (f) The timely re-
sponse
zones and to events
conduits specifies
in orderrequirements
to limit unnecessaryin orderdata to ensure
flows. (f) theTheresponse to security
timely response to
breaches, enabling
events specifies the notification
requirements in orderof competent
to ensure the authorities
responseand evidence
to security of the breach
breaches, enabling so
that corrective and
the notification timely actions
of competent can beand
authorities taken whenofincidents
evidence the breach occur.
so that(g) corrective
The resource and
availability
timely actions specifies
can berequirements
taken when incidentsin order to ensure
occur. (g)the
Thedevice
resource availability
availability and, conse-
specifies
quently, IACS in
requirements against
order degradation
to ensure theordevice denialavailability
of essentialand, services. Each fundamental
consequently, IACS against re-
quirement
degradation hasorseveral
denialconditions
of essentialthat must beEach
services. met fundamental
depending onrequirement
which of thehas four spec-
several
ified security
conditions levels
that mustis be
desired for the given
met depending onIACS
which device.
of the[21].
four specified security levels is
Thefor
desired access control
the given IACS must be built
device [21].on a solid foundation in order to ensure device re-
source Theavailability
access control to allmust of its betrusted
built onusers.
a solidIt foundation
ensures integrityin order andto confidentiality
ensure device
through
resourcethe device’s root
availability to allof of
trust
its (RoT)
trusted with the secure
users. storage
It ensures of identity,
integrity cryptographic
and confidentiality
keys,
through andthe
firmware
device’svalidation
root of trust during
(RoT)itswithboottheprocess
secureand withofthe
storage cryptography
identity, of the
cryptographic
data
keys,that
andare transmitted
firmware or stored
validation during by it.
itsThis
bootcontrol
processshould
and with be based on the concept
the cryptography of
of the
authentication, authorization,
data that are transmitted and accounting
or stored by it. This(AAA)
control[30]. Oncebethe
should user on
based is both identified
the concept of
and authenticated,
authentication, an authorizer
authorization, andmechanism
accounting must (AAA)control the access
[30]. Once the userrights of each
is both user
identified
to
andtheauthenticated,
component, enabling an authorizerthe asset owners and
mechanism the control
must system integrators to define
the access rights the priv-
of each user
ileges of each role that is to be assigned to each user (human, software process, or device),
to the component, enabling the asset owners and the system integrators to define the
which is authorized in the drive.
privileges of each role that is to be assigned to each user (human, software process, or
The Modbus/TCP protocol can be found in [31,32]. A TCP Modbus frame (Figure 1)
device), which is authorized in the drive.
consists
TheofModbus/TCP
an MBAP (MODBUS protocolapplication
can be found protocol) andAa TCP
in [31,32]. PDUModbus
(protocolframedata (Figure
unit) and 1)
consists
is knownof asan an MBAP (MODBUS data
ADU (application application
unit). The protocol)
MBAP and a PDUwith
is a header (protocol datastruc-
the same unit)
and is known as an ADU (application data unit). The MBAP
ture with seven bytes for all of the frames, while the PDU is the function requests and is a header with the same
structure with
responses. It is seven
limited bytes forbytes,
to 253 all of the
whereframes, while
the first theisPDU
byte is theto
designed function
function requests
code (FC), and
responses. It is limited to 253 bytes, where the first byte is designed
and the others are the data. There are two kinds of function codes, which are as follows: to function code (FC),
and thefunction
public others are the data.
codes, which There are two kinds
are specified by the of function
protocol,codes, which are asfunction
and user-defined follows:
codes, which are specific functions that are developed by users and manufacturers tocodes,
public function codes, which are specified by the protocol, and user-defined function sup-
which are specific
port product features. functions that are developed by users and manufacturers to support
product features.
Figure
Figure 1.
1. Modbus
Modbus application
application data
data unit
unit structure.
structure.
This work
This work proposed
proposed toto develop
develop and
and adopt
adopt two
two new
new user-defined
user-definedfunctions
functions(authenti-
(authen-
cation and authorization) in order to provide both capabilities and to deploy
tication and authorization) in order to provide both capabilities and to deploy access controls
access con-
in order to enhance the Modbus/TCP Security protocol.
trols in order to enhance the Modbus/TCP Security protocol.
3.1. Authentication User-Defined Function
3.1. Authentication User-Defined Function
The PDU structure of the new authentication function is presented in Figure 2. It
The PDU structure of the new authentication function is presented in Figure 2. It re-
receives the function code 0x69 and has a subsequent byte that is used to determine the
ceives the function code 0x69 and has a subsequent byte that is used to determine the type
type of the function, which can be any of the following functions.
of the function, which can be any of the following functions.
Sensors 2022,
Sensors 22, 8024
2022, 22, 8024 6 6of
of 20
20
Function code 1 Byte 0x69

Function type 1 Byte 0x01
Use rname 28 Byte s Until 28 ASCII he x code
Password 32 Byte s Until 32 ASCII he x code
(a) Authe ntication Re que st

Function type 1 Byte 0x02
Use rname 28 Byte s Until 28 ASCII he x code
Password 32 Byte s Until 32 ASCII he x code
Ne w password 32 Byte s Until 32 ASCII he x code
(b) Authe ntication and Update Re que st

Toke n code 32 Byte s Until 32 ASCII he x code
(c) Succe ssful Re sponse
Error code 1 Byte 0xE9

Exce ption code 1 Byte 0x00 to 0xFF
(d) Error Re sponse
Figure
Figure 2.
2. PDUs of the new authentication user-defined function.
3.1.1. Authentication
3.1.1. Authentication
The byte 0x01 determines that the function will be used by a common authentication
The byte 0x01 determines that the function will be used by a common authentication
request (Figure 2a). It is followed by 28 bytes of the username and 32 bytes of the password,
request (Figure 2a). It is followed by 28 bytes of the username and 32 bytes of the pass-
in which each character (ASCII table code) occupies one byte of the function data.
word, in which each character (ASCII table code) occupies one byte of the function data.
3.1.2. Update
3.1.2. Update
The byte 0x02 determines that the function will be of the update and the authenti-
cation Thetypebyte 0x02 determines
(Figure 2b). In addition that theto function will be
the username andof the
the update
password, andthe
therequest
authentica-
will
tion
inform a new password of 32 characters in order to update the current passwordwill
type (Figure 2b). In addition to the username and the password, the request in-
before
form a new password
authenticating the user. of 32 characters in order to update the current password before
authenticating the user. the PDU struct of successful responses for both types of requests.
Figure 2c presents
Figure
It is the 2c presents
function code byte the asPDU struct of
standard bysuccessful responsesby
Modbus, followed fora both
tokentypes
codeofofrequests.
32 bytes,
It is theisfunction
which code byte
used in order as standard
to identify by Modbus, user.
the authenticated followed
Thisby a token
token codecode
mustofbe32unique
bytes,
which is used in order to identify the authenticated user. This
in order to guarantee the integrity of the username, for example, a SHA256 of a robust token code must be unique
in order number
random to guarantee the integrity
generation [33,34]. of the username, for example, a SHA256 of a robust
random In case of failure during[33,34].
number generation the authentication process with the new function, the server
In case oftofailure
will respond during
the request thewas
that authentication
made by theprocess withan
client with theerror
newmessage
function,(Figure
the server
2d).
will respond to the
The user-defined request that
exception code, was
formade
example, by the
an client
invalid with an errorexception,
password message (Figure 2d).
will receive
The user-defined
the code exception
0x28 to inform the code,
client forthatexample,
the hashan invalid
code is notpassword exception, will receive
authenticated.
the code 0x28 to inform the client that the hash code is not authenticated.
3.2. Authorization User-Defined Function
3.2. Authorization
The newly developedUser-Defined Function
function encapsulates the PDU of the original Modbus request
The made
that was newlyby developed
the clientfunction encapsulates the PDU of the original Modbus request
in its header.
that was
The made
token is byreceived
the client byintheitsauthentication
header. process, enabling the authorizer to identify
which The token is received by the authentication process, enabling the authorizer to iden-
username made the respective request.
tify which
Its PDU username
structuremade the respective
is present in Figure request.
3, which is known as the authorization function.
For theIts PDU structure is present in Figure 3,code
availability, it receives the function 0x6A.
which In addition
is known as thetoauthorization
the function func-
code,
it hasFor
tion. a bytethe to inform its it
availability, version
receives forthe
future updates,
function codefollowed
0x6A. Inbyaddition
the header size,
to the which
function
helps to identify the original function’s beginning, the token’s size
code, it has a byte to inform its version for future updates, followed by the header size, to facilitate the process
of extracting
which helps to theidentify
token, thethe user’s
original own token ofbeginning,
function’s 32 bytes, and thefinally
token’sending
size towith the PDU
facilitate the
of the original request, which is limited to 216 bytes.
process of extracting the token, the user’s own token of 32 bytes, and finally ending with
the PDU of the original request, which is limited to 216 bytes.
tion function encapsulates the original PDU, if an exception occurs for the original func-
tion, or if the user does not have access permission for the given register, the function will
return this exception encapsulated in a successful response frame that is performed by the
new authorization function (Figure 3c). In case of failure during the authorization process
with the new function (Figure 3d), the server will respond to the request with an exception
Sensors 2022, 22, 8024 message, for example, no access exception, code 0x29, in order to inform the client that 7 of 20
token code is not authenticated.
Function code 1 Byte 0x6A

Function ve rsion 1 Byte 0x01
He ade r size 1 Byte 0x00 to 0xFF
Toke n size 1 Byte 0x00 to 0xFF
Authorize d toke n 32 Byte s Until 32 ASCII he x code
Original PDU Function code 1 Byte 0x01 to 0x7F
Original PDU Data 216 Byte s Until 216 byte s (0x00 to 0xFF)
(a) Authorization Function Re que st

Original function code 1 Byte 0x00 to 0x80
Original re sponse 251 Byte s Until 251 byte s (0x00 to 0xFF)
(b) Succe ssful Re sponse

Original PDU Error code 1 Byte 0x81 to 0xFF
Original PDU Exce ption code 1 Byte 0x00 to 0xFF
(c) Original PDU Error Re sponse
Error code 1 Byte 0xEA

Exce ption code 1 Byte 0x00 to 0xFF
(d) Error Re sponse
Figure 3. 3.
Figure PDUs ofof
PDUs the new
the authorization
new user-defined
authorization function.
user-defined function.
4. Implementation
The struct of a successful response is present in Figure 3b. The first byte is the owner
function code, followed by the original function code and the response. As the authorization
An IACS is represented in Figure 4, and the solid green line represents an industrial
function encapsulates the original PDU, if an exception occurs for the original function, or
ethernet network (OT domain). As can be seen, it has a connection to the intranet in the
if the user does not have access permission for the given register, the function will return
IT domain (the solid red line) and the internet (the dashed blue line) through a firewall
this exception encapsulated in a successful response frame that is performed by the new
and IIoT edge devices. The components that allow human users to interact with the sys-
authorization function (Figure 3c). In case of failure during the authorization process with
tem are also represented.
the new function (Figure 3d), the server will respond to the request with an exception
Item one represents a human–machine interface, which is a graphical user interface
message, for example, no access exception, code 0x29, in order to inform the client that
that
tokenallows
codeinteraction between a human operator and components of IACS. It generally
is not authenticated.
displays specific information about the system to the operator and can be used to change
the
4. operational
Implementation or the engineering setpoints and the parameters in the system. Items two
and three represent the supervisory
An IACS is represented software
in Figure 4, andthat are installed
the solid green lineon represents
computersan that allow
industrial
high-level
ethernet network (OT domain). As can be seen, it has a connection to the intranet inisthe
visibility and interaction of the human users with the system. The first di-IT
rectly
domain connected to the
(the solid redindustrial
line) and network,
the internetwhile
(thethe second
dashed is connected
blue line) throughto the corporate
a firewall and
network, which is usually located in the control and command centers
IIoT edge devices. The components that allow human users to interact with the system areof the production
process. Item four represents the direct connection of a notebook to an IACS device, which
also represented.
usuallyItemhappens when it isanecessary
one represents to use specific
human–machine software
interface, whichforis athe parameterization
graphical user interfaceof
the device. Finally, item five represents the remote connection to the
that allows interaction between a human operator and components of IACS. It generally supervisors and the
devices—a common
displays specific scenario when
information aboutspecialists
the systemneedto thepunctual
operatorintervention
and can be usedon IACS by
to change
specialists for corrective
the operational maintenance,
or the engineering with theand
setpoints objective of explaining
the parameters and
in the validating
system. Itemsthetwo
and three represent the supervisory software that are installed on computers that allow
high-level visibility and interaction of the human users with the system. The first is directly
connected to the industrial network, while the second is connected to the corporate network,
which is usually located in the control and command centers of the production process.
Item four represents the direct connection of a notebook to an IACS device, which usually
happens when it is necessary to use specific software for the parameterization of the device.
Finally, item five represents the remote connection to the supervisors and the devices—a
common scenario when specialists need punctual intervention on IACS by specialists for
corrective maintenance, with the objective of explaining and validating the applicability of
the functions that are developed for the construction of systems that control the access of
human users to the reading and writing of Modbus registers in IACS components.
Sensors 2022, 22, 8024 8 of 20
Sensors 2022, 22, 8024 8 of 20
applicability of the functions that are developed for the construction of systems that con-
Sensors 2022, 22, 8024 trolapplicability
the access of
of the
human users
functions toare
that thedeveloped
reading and writing
for the of Modbus
construction registers
of systems ofin
20IACS
that8 con-
trol the access of human users to the reading and writing of Modbus registers in IACS
components.
components.
Figure 4. Example of an industrial automation and control system.
Figure
Figure4. Example
4. Exampleofofan anindustrial automationand
industrial automation andcontrol
control system.
system.
Firstly, it is considered to be a minimalist system that contains only one Modbus
server (PLC), receiving requests for writing and reading registers fromonea Modbus
Modbusserverclient
Firstly,
(HMI).
Firstly,itit is
The consideredtobetween
is considered
communication to
be be a the
minimalist
a minimalist
two
systemsystem
devices thatout
that contains
is carried contains
only
through only
the one pro-
TCP Modbus
(PLC), receiving requests for writing and reading registers from a Modbus client (HMI).
server (PLC),
on portreceiving
tocolcommunication requests for writing
502 (Modbus/TCP andfirst
reading registers from a Modbus client
The between theStandard).
two devicesIn this
is carriedscenario (Figure
out through the5),TCP
there is no con-
protocol on
(HMI).
trol The
over communication
the client’s between
requests, the
therefore, two
the devices
Modbus is
servercarried
will out through
successfully
port 502 (Modbus/TCP Standard). In this first scenario (Figure 5), there is no control over
the
respond TCP to pro-
tocol
all on
the of portpublic
the
client’s 502 (Modbus/TCP
requests,requests Standard).
that are
therefore, the made
Modbus by In
thethis
server firstsuccessfully
Modbus
will scenario
client for(Figure
valid
respond 5),to
there
registers ofisthe
all on no con-
the
server.
trolpublic
over requests
the client’s requests, therefore, the Modbus server will successfully
that are made by the Modbus client for valid registers on the server. respond to
all of the public requests that are made by the Modbus client for valid registers on the
server.
Figure 5.
Figure 5. Standard Modbus
Modbus client-server
client-server scenario.
scenario.
The
The proposed
proposed scenario
scenario toto validate
validate these
these functions
functions considers
considers thethe addition
addition of
of aa new
new
component
component to
to the
the system
system (Figure
(Figure 6).
6). The
The man-in-the-middle
man-in-the-middle (MITM)
(MITM) component
component will
will be
be
Figure 5. Standard Modbus client-server scenario.
responsible for intermediating the communication between the client
responsible for intermediating the communication between the client and the server and and the server and
intercepting
intercepting requests
requests to
to carry
carry out the
the authentication process and
and toto access control
control to the
The proposed
Modbus server. In scenario
this new toout
validate
scenario,
authentication
these
instead of
process
functions
connecting considers
directly to
access
theModbus
the addition toof
the
a new
server,
Modbus
component server. In this new scenario, instead of connecting directly to the Modbus server,
the Modbus client is connected to MITM on TCP port 802. This is possible with the use of a be
to the system (Figure 6). The man-in-the-middle (MITM) component will
the Modbus client is connected to MITM on TCP port 802. This is possible with the use of
responsible for intermediating
third component with computational the communication
resources, such asbetween the client
single-board and (SBC),
computers the server
and and
a third component with computational resources, such as single-board computers (SBC),
intercepting
it is valid torequests
improve to carry outdevices
brownfield the authentication process andortoearlier
with serial communication accessversions
controlofto the
and it is valid to improve brownfield devices with serial communication or earlier ver-
Modbus server.
the Modbus In this However,
protocol. new scenario,
the ideainstead of connecting
is to embed directly to
the authentication the
and Modbus server,
authorization
the Modbus client is connected to MITM on TCP port 802. This is possible with
capabilities directly into the PLC in order to be compliant with IEC 62443-4.2 and the use of
to prevent
these controls from being bypassed.
a third component with computational resources, such as single-board computers (SBC),
and it is valid to improve brownfield devices with serial communication or earlier ver-
Sensors 2022, 22, 8024 9 of 20
sions of the Modbus protocol. However, the idea is to embed the authentication and au-
sions of thecapabilities
thorization Modbus protocol.
directly However, thein
into the PLC idea is to
order toembed the authentication
be compliant and au-
with IEC 62443-4.2
Sensors 2022, 22, 8024 thorization
and to preventcapabilities directly
these controls frominto the PLC
being in order to be compliant with IEC 62443-4.2
bypassed. 9 of 20
and to prevent these controls from being bypassed.
Figure 6. Laboratory’s scenario, MITM agent.

Figure 6.
Figure 6. Laboratory’s
Laboratory’s scenario,
scenario, MITM
MITM agent.
agent.
Although we are exemplifying both of the scenarios with real devices, the proposed
Although
Although we
we are
are exemplifying
exemplifying both
both of
of the
the scenarios
scenarios with
with real
real devices,
devices, the proposed
scenario was simulated using the Node-RED programming platform in this the proposed
work. It is a
scenario
scenario was
was simulated
simulated using
using the
the Node-RED
Node-RED programming
programming platform
platform inin this
this work.It Itisisa
work.
flow-based programming tool that integrates the OpenJS Foundation. Initially developed
aflow-based
flow-based programming
programming tooltool
thatthat integrates
integrates the the OpenJS Foundation. Initially devel-
by IBM’s emerging technology services team, it is OpenJS Foundation.
a low-code, Initially
visual representation developed
pro-
oped by IBM’s emerging technology services team, it is a low-code, visual representation
by IBM’s emerging
gramming model that technology
describesservices team, of
the behavior it isana application
low-code, visual representation
as a network pro-
of nodes,
programming model that describes the behavior of an application as a network of nodes,
gramming
where modelhas
each node that describes
a very the behavior
well-defined purpose.of an application
It receives data,asprocesses
a network of nodes,
it, and then
where each node has a very well-defined purpose. It receives data, processes it, and then
where each
returns node
it to the has a very
network. It iswell-defined
responsible for purpose.
the data It flow
receives data, the
between processes it, and then
nodes [22].
returns it to the network. It is responsible for the data flow between the nodes [22].
returns
Figure 7 shows the Modbus server flow. With a single node, the first flow[22].
it to the network. It is responsible for the data flow between the nodes that was
Figure 7 shows the Modbus server flow. With a single node, the first flow that was
deployedFigurefor7this
shows the Modbus server
experimentation turnedflow. With aSTD
a Modbus single node,
server the firstavailable.
simulator flow thatItwas is
deployed for this experimentation turned a Modbus STD server simulator available. It is
adeployed
node thatfor this experimentation
simulates a Modbus server. turned a Modbus
In order STD server
to configure simulator
the server, it isavailable.
necessaryIttois
a node that simulates a Modbus server. In order to configure the server, it is necessary to
a node that simulates
determine a Modbus server. Indiscrete
order to configure the available
server, it is necessary to
determinehow howmanymanycoils,
coils,holdings,
holdings,and and discreteinputs
inputswill
willbebe availableto tothe
thesystem
system
determine
and to set how
an manyand
address coils,
a holdings,
port for theand discrete
network inputs will be available
communication. For the to thecontrol
access system
and to set an address and a port for the network communication. For the access control
and to set an address and a the
implementation port for the network communication. Forthe the access control
implementationmaintaining
maintaining theModbus/TCP
Modbus/TCPstandardstandardspecification,
specification, theIPv4 IPv4localhost
localhost
implementation
and maintaining the Modbus/TCP standard specification, the IPv4 localhost
andthetheTCP
TCPportport502
502were
werechosen.
chosen.
and the TCP port 502 were chosen.
Figure Node-REDModbus
Figure7.7.Node-RED Modbusserver
serverflow
flowsimulates
simulatesthe
thePLC.
PLC.
Figure 7. Node-RED Modbus server flow simulates the PLC.
Figure 8 shows the flow with auxiliary functions that enable and disable the access
Figure 8 shows the flow with auxiliary functions that enable and disable the access
control and configure
Figure 8 shows the andflow
obtain theauxiliary
with authorized users’ credentials
functions in order to make requests
control and configure and obtain the authorized users’that enable
credentials and disable
in order to the
make access
re-
in the system.
controlinand The disable
configure and and enable
obtain nodes
theenableauthorizedare of the inject type and make it possible to
quests the system. The disable and nodesusers’
are of credentials
the inject type in order
and make to make
it pos-re-
initialize
quests the payload value in the flow. Both connect to the on/off access control node of the
sible to in the system.
initialize The disable
the payload value andin enable
the flow. nodes
Bothare of the to
connect inject
the type
on/off and makecontrol
access it pos-
function type, which allows the execution of the previously programmed functions through
sible to initialize the payload value in the flow. Both connect
node of the function type, which allows the execution of the previously programmed func- to the on/off access control
the JavaScript language. This node enables or disables the system’s access control, and its
nodethrough
tions of the function type, which
the JavaScript allowsThis
language. the execution
node enables of the orpreviously
disables the programmed
system’s access func-
output is connected to the access control status and the token update nodes, which are both
tions through
control, and itsthe JavaScript
output language.
is connected to This node enables
the access control or disables
status and the thesystem’s
token update access
of the debug types that are responsible for displaying the properties of the selected message
control,
nodes, and are
which its both
output is connected
of the debug types to that
the are
access control status
responsible and thethe
for displaying token update
properties
in the debug window. In addition, the enable node is connected to the C:/users.xml node,
ofnodes, which are
the selected both ofinthe
message thedebug
debug types
window. that areIn responsible
addition, the forenable
displaying node the properties
is connected
which is a read file type that is responsible for reading the files from the running system.
ofthe
to theC:/users.xml
selected message node, in the debug
which window. In that
addition, the enable fornode is connected
This node will search for the file is
in awhich
read file type
the user’s is responsible
credentials are stored, reading
passingthe files
through
to the
from theC:/users.xml
running node,This
system. which nodeis awill
readsearch
file type
for thatfile
the is responsible
in which the for reading
user’s the files
credentials
the XML node, which is responsible for converting the file in XML format into a JavaScript
from
are the running
stored, system. This node will search for is the file in which the user’s credentials
object. Thispassing
object isthrough
passed the XMLthe
through node,get which
credentials responsible for converting
node as a message payload theinfile in
order
are stored,
XML format passing
into a through the
JavaScript XML
object. This node,objectwhich
is is responsible
passed through for converting
the get credentials the node
file in
to be transmitted by the network. Then, the credentials that are stored in this JavaScript
XML
as format
a message
object
into a JavaScript
payload
are defined asinglobal
object.
order variables This
to be transmitted object isaccessible
that areby
passed through
the network. by any
the
Then, nodes
get
the credentials
or flows inthat
node
the
as
are a message
stored in payload
this in
JavaScriptorder to
object be transmitted
are defined by
as the
global network.
system. A similar process is performed by the set users node, which allows new users andvariablesThen,that the
are credentials
accessible that
by
are nodes
any storedor
credentials in this
toflows JavaScript
in the and
be updated object
system.
storedAare fordefined
similar as global
process
the system. variablesby
is performed that thearesetaccessible
users node, by
any nodes
which allows or flows
new in
users the
and system. A
credentials similar
to be process
updated is performed
and stored
The following flow, called MITM (Figure 9), is responsible for performing the authen- forby the
the set
system. users node,
which allows
tication and the new users
user andcontrol
access credentials to the to Modbus
be updated andthrough
server stored for thethe system.
newly developed
user-defined functions.
Sensors 2022, 22, 8024 10 of 20
Sensors2022,
Sensors 22,8024
2022,22, 8024 10
10 of 20
of 20
Figure 8. Node-RED auxiliary flow.
The following flow, called MITM (Figure 9), is responsible for performing the au-
thentication and the user access control to the Modbus server through the newly devel-
Figure 8. Node-RED
Node-RED auxiliary
oped user-defined
Figure 8. auxiliary
functions.flow.
flow.
The following flow, called MITM (Figure 9), is responsible for performing the au-
thentication and the user access control to the Modbus server through the newly devel-
oped user-defined functions.
Figure 9.
Figure 9. Node-RED
Node-RED man-in-the-middle
man-in-the-middle flow
flow simulates
simulates the
the SBC.
SBC.
The node
The node Modbus
Modbus MITM MITM serverserver portport 802 is aa TCP TCP in in node
node typetype andand itit receives
receives allall of
of
the connection
the connection requests requests on on the
the 802
802 TCP
TCP port.
port. It It is
is directly
directly connected
connected to to the
the following
following two two
Figure
other nodes:
other 9. Node-RED
nodes: the man-in-the-middle
therequest
request node,which
node, which flow
is is simulates the
responsible
responsible SBC.
forfor registering
registering allthe
all of of the requests
requests in thein
the flow;
flow; and and the security
the security system system
node,node,which which
evaluatesevaluates
whether whether the access
the access control control
has beenhas
beenThe
activated node
activated
through Modbus
through MITM
the
the auxiliary server
auxiliary
flow. flow.port 802 is a TCP in node type and it receives all of
the connection
If it is requests
disabled, all on
of the
If it is disabled, all of the requests are
the 802
requestsTCP port.
are It is directly
forwarded
forwarded to the
to theconnected
third output
third to the
output of following
of the FC?
the FC? node,two
node,
other
which nodes:
is directly the request
connected node,
to it.which
This is
node responsible
is of the for
which is directly connected to it. This node is of the switch type and it switches messages
switch registering
type and all
it of the
switches requests
messages in
the flow; and the security
according to some of its properties.
according to some of its system
properties. node, which evaluates whether the access control has
beenFor activated
For the
the system through
system under
under theanalysis,
auxiliary
analysis, the
theflow.
function
function code code of of the
the request
request is is evaluated
evaluated when when the the
access If it is
control disabled,
is all
disabled, of the
and requests
a non-public are forwarded
request to
arrives,
access control is disabled, and a non-public request arrives, so the function code is re- theso third
the output
function of
codethe FC?
is node,
replaced
which
by isbydirectly
its respective
placed connected
exception
its respective to it. In
code.
exception This node
Modbus
code. In isit of
is the
Modbus switch
equivalent type
to theand
it is equivalent it
toswitches
function thecode messages
functionadded codeto
according
the value to
0x80 some
and of its properties.
forwarded to the next node,
added to the value 0x80 and forwarded to the next node, FC >= 0x80?, which parses FC >= 0x80?, which parses whether the
message
whether For is the
the a system
request
message under analysis,orthe
orisana exception.
request anfunction
For cases where
exception. codeFor ofcases
the the request
received
where is
message
theevaluated when
is an exception,
received messagethe
itaccess
will control is itdisabled,
forward
is an exception, to the exception
will forward and atonon-public
MITM reply
the exception request
node, MITM arrives,
which replyso
is a TCPthe function
node, which is code
out reply a TCPis out
node re-
type
placed
that by its
is responsible respective exception
for responding code. In
to requests Modbus
for itsitrespective
reply node type that is responsible for responding to requests for its respective sources. is equivalent to
sources. the function
Although, code
if it
added
continues
Although, to to the
if it value
be a request
continues 0x80to and
be aforwarded
message, to the itnext
it is forwarded
request message,
to thenode,
Modbus
is forwarded FCto>= the0x80?,
STD clientwhich
Modbus STDparses
node, which
client
whether
is a TCP requestthe messagenode is a
type request
that is or an exception.
responsible
node, which is a TCP request node type that is responsible for making requests For
for making cases where
requests the
to thereceived
Modbus message
server,
to the
is an exception,
waiting
Modbus server, it
for the responses will forward
waiting for the to
to finally betheforwarded
responses exception MITM
by
to finally
them reply
to the node,
be forwarded which
reply Modbus
by themistoa the
STD TCP out
server
reply
reply
node,
Modbus node
and
STD
to type
returnthatnode,
server
tois responsible
their respective
and to return for responding
source, to requests
regardless
to their respective
of for its
whether
source, respective
it is
regardless
a sources.
successful
of whether
or
exceptional
Although, response.
if it continues to be a response.
request message, it is forwarded to the Modbus STD client
it is a successful or exceptional
node,However,
which isonce a TCP therequest
access control
node type feature
that has been enabled,
is responsible for the
makingFC? noderequests willtohave
the
three possible outputs, as follows: the first is used
Modbus server, waiting for the responses to finally be forwarded by them to the reply for the new user-defined function of
the authentication type, function code 0x69, the second
Modbus STD server node, and to return to their respective source, regardless of whether is for the new authorization type
user-defined
it is a successful function, function code
or exceptional 0x6A, and the third is for exceptions that are generated
response.
by the security system node, because once the access control is enabled, all of the public
However, once the access control feature has been enabled, the FC? node will have
three possible outputs, as follows: the first is used for the new user-defined function of
Sensors 2022, 22, 8024 the authentication type, function code 0x69, the second is for the new authorization 11 type
of 20
user-defined function, function code 0x6A, and the third is for exceptions that are gener-
ated by the security system node, because once the access control is enabled, all of the
public functions that are requested directly to the MITM will be blocked by it and their
functions that are requested directly to the MITM will be blocked by it and their respective
respective exception messages generated by it.
exception messages generated by it.
The authentication requests are sent to the authentication control node. This node is
The authentication requests are sent to the authentication control node. This node
responsible for verifying the user and the password, returning the token in the case of
is responsible for verifying the user and the password, returning the token in the case of
success (Figure
success (Figure 2c),2c), oror exception
exception in in the
the case
case of
of authentication
authentication failure
failure (Figure
(Figure 2d) 2d) through
through
the direct MITM reply node. The token is the SHA256 result of
the direct MITM reply node. The token is the SHA256 result of the concatenation between the concatenation between
the timestamp
the timestamp and and thethe username.
username.
The authorization
The authorizationrequestsrequests areare forwarded
forwarded to authorization
to the the authorization control
control node.node. This
This node
first analyzes whether the token that is informed by the request (Figure 3a) has expiredex-
node first analyzes whether the token that is informed by the request (Figure 3a) has or
ifpired or ifauthenticated
it is not it is not authenticated in theThe
in the system. system. The exception
exception code corresponding
code corresponding to the errortothat the
error
is foundthatisisgenerated
found is generated for these
for these cases. cases. if
However, However,
no problem if noisproblem
found, thenis found, then it is
it is evaluated
evaluated whether the given user is authorized to perform the
whether the given user is authorized to perform the given request. In negative cases, an given request. In negative
cases, an exception
exception is raised, but is raised, but for
for positive positive
cases, cases, the
the original original
function is function
decapsulatedis decapsulated
to proceed
to proceed with the request. As can be seen, this node is
with the request. As can be seen, this node is connected exclusively with node FCconnected exclusively with node
< 0x80?,
FC < 0x80?, which evaluates whether the response from the authorization
which evaluates whether the response from the authorization control node is an exception. control node is
an exception. If so, it forwards the message (Figure 3d) to the exception
If so, it forwards the message (Figure 3d) to the exception MITM reply node, which returns MITM reply node,
which
the returnstothe
exception exception source,
its respective to its respective source,
but if it is not but if it isit not
an exception, willan exception,
forward it will
the request
forward
to the Modbusthe request
STD clientto the Modbus
node, which STD client node,forwhich
is responsible is responsible
performing for performing
the original requests to
the Modbus
the original server
requests onto the
the Modbus
TCP port 502,server
but on
now,thedifferent
TCP port 502,non-encapsulated
from but now, differentpublic from
non-encapsulated
requests, the returnpublicthat isrequests,
received the from return that is received
the Modbus from the Modbus
server, regardless of beingserver,
a success re-
gardless3b)
(Figure of or
being a success (Figure
an exception (Figure 3b) 3c), or an exception
must (Figure 3c),before
be re- encapsulated must returning
be re- encapsu-to its
lated before
original source.returning to its original source.
The authentication
The authentication requestrequest flow
flow is is responsible
responsible for
for performing
performing the the user
user authentication
authentication
requests. As
requests. As can
can bebe seen
seen inin Figure
Figure 10,10, there
there are
are three
three inject
inject nodes,
nodes, oneone for
for each
each user
user in
in the
the
system. Table
system. Table 11 presents
presentsthe thepermissions
permissionsof ofeach
eachuser.
user.
Figure 10.
Figure 10. Node-RED
Node-RED authentication
authentication request
requestflow
flowsimulates
simulatesthe
thefirst
firstpart
partof
ofthe
theHMI.
HMI.
Table When activating

1. Users’ one of these nodes, as they are all connected to the buffer maker
permissions.
node, the first process to be performed is to transform the message payload into a buffer,
then the MBAP
User header append node adds the data from
Trusted the MBAP header ofRead
Write the previous
Modbus Alice
protocol in order to send
Yes the request to the MITM
Yes flow through the Modbus
Yes
MITM client
Bob node. It is the return
Yes of a given request that
No is sent to the FC >Yes
0x80? Node
that will validate whether the response is an exception or not. In case of an exception, the
Cris No No No
message is sent to the authentication fail node and, in parallel, this forces the global vari-
When activating one of these nodes, as they are all connected to the buffer maker node,
the first process to be performed is to transform the message payload into a buffer, then the
MBAP header append node adds the data from the MBAP header of the previous Modbus
protocol in order to send the request to the MITM flow through the Modbus MITM client
node. It is the return of a given request that is sent to the FC > 0x80? Node that will validate
whether the response is an exception or not. In case of an exception, the message is sent to
the authentication fail node and, in parallel, this forces the global variable token to be null
ful, the authentication success node is logged and the token variable with the value is
received in the response.
Table 1. Users’ permissions.
Sensors 2022, 22, 8024 User Trusted Write Read 12 of 20

Alice Yes Yes Yes
Bob Yes No Yes
Cris No No
through the set token node. Nevertheless, if the response is successful, the authentication No
success node is logged and the token variable with the value is received in the response.
In the
In the last
lastsystem
systemflow,
flow,Modbus
Modbus client (Figure
client 11)11)
(Figure is responsible
is responsiblefor reading and writ-
for reading and
ing requests
writing to the
requests toregister 0x64 from
the register the Modbus
0x64 from server.server.
the Modbus The nodeThereadnodeholding register
read holding
performsperforms
register a reading request in
a reading orderin
request toorder
register 0x64 through
to register the Modbus
0x64 through read holding
the Modbus read
register register
holding (0x03) function. The node
(0x03) function. Thewrite
nodemultiple register
write multiple 0x00 writes
register the value
0x00 writes 0x00,0x00,
the value and
the write
and multiple
the write register
multiple 0xFF0xFF
register performs the writing
performs request
the writing of theofvalue
request 0xFF 0xFF
the value to theto
same
the
register
same through
register the write
through multiple
the write registers
multiple (0x10)(0x10)
registers function of theofModbus
function the Modbusprotocol.
protocol.
Figure 11.
Figure 11. Node-RED
Node-RED Modbus
Modbus client
client flow
flow simulates
simulates second
second part
part of
of the
the HMI.
HMI.
All of
All of the
the inject
inject nodes
nodes are are directly
directly connected
connected to to the
the buffer
buffer maker
maker node
node so so that
that the
the
payload is
payload is transformed
transformed into
into aa buffer.
buffer. The
The toto encapsulate
encapsulate nodenode performs
performs the the encapsulation
encapsulation
of the
of the original
original function
functionin inthe
thenewnewauthorization
authorization function,
function, according
according to Figure
to Figure3, when the
3, when
access
the control
access is enabled.
control If it does
is enabled. not, itnot,
If it does sends the original
it sends function
the original to the Modbus
function MITM
to the Modbus
client node,
MITM clientwhich
node,iswhich
responsible for sending
is responsible the requests
for sending to the MITM
the requests flow.
to the MITM Theflow.
response
The
to these requests is sent to the FC == 0x6A? node, which responsible for directing the type
response to these requests is sent to the FC == 0x6A? node, which responsible for directing
of request,
the type of the original
request, theor the authorization,
original to its giventosubsequent
or the authorization, nodes. The nodes.
its given subsequent OriginalFC
The
< 0x80? node
OriginalFC evaluates
< 0x80? nodewhether
evaluatesthere was there
whether an exception in the response
was an exception of the original
in the response of the
request that
original was that
request made through
was made the new authorization
through function (Figure
the new authorization function3c).(Figure
The FC3c).
< 0x80?
The
node already has the same function; however, there are exceptions from both of the orig-
FC < 0x80? node already has the same function; however, there are exceptions from both of
inal functions and the authorization function, in case the given user does not have writing
the original functions and the authorization function, in case the given user does not have
writing access,
access, for for example
example (Figure (Figure
3d). 3d).
5. Tests
5. Tests
The tests that are presented in this section aim to facilitate the understanding and to
The tests that are presented in this section aim to facilitate the understanding and to
validate the applicability of the two new user-defined functions for developing a method
validate the applicability of the two new user-defined functions for developing a method
that provides authentication and authorization resources to the Modbus/TCP Security
that provides authentication and authorization resources to the Modbus/TCP Security
protocol. All of the values that are present on these tests are in hexadecimal [18].
protocol. All of the values that are present on these tests are in hexadecimal. [18]
Bear in mind that this work proposes improvements in the protocol, and the encryption
Bear in mind that this work proposes improvements in the protocol, and the encryp-
is essential for the operation of the proposed mechanisms, because it guarantees the
tion is essential for the operation of the proposed mechanisms, because it guarantees the
confidentiality of the transmitted credentials and tokens. This was chosen not to be applied
confidentiality
in tests to encryptof the
the transmitted
transmitteddatacredentials and understood
once it was tokens. Thisthat
wasitschosen not to bedoes
inapplicability ap-
plied
not in tests
affect the to encrypt
final resultsthe
of transmitted
the proposeddata once
tests, as itit aims
was understood thatuse
to validate the its of
inapplicability
the two new
does not affect the final results of the proposed tests, as it aims to
authentication functions and to authorize users to make requests of writing and validate the reading
use of the
in
the Modbus server registers.
As can be seen in Figure 12, the tests started with the access control deactivated. All of
the requests that reach the MITM flow will be forwarded to the Modbus server.
As the access control is disabled, the token is forced to a null value. Furthermore,
the read and write requests to the register 0x64 can be successfully performed through
the Modbus client flow. Remember that a Modbus/TCP frame is named ADU (Figure 1).
Therefore, the first request is composed of the MBAP header and the read holding register
reading in the Modbus server registers.
As can be seen in Figure 12, the tests started with the access control deactivated. All
of the requests that reach the MITM flow will be forwarded to the Modbus server.
Sensors 2022, 22, 8024 13 of 20
Sensors 2022, 22, 8024 13 of 20
two new authentication functions and to authorize users to make requests of writing and
reading in the Modbus server registers.
PDU As(Figure
can be13a),
seenand
in Figure 12, the tests
the subsequent started
frame is thewith the access
successful control
response deactivated.
(Figure All
13b), where
ofthe
theregister
requests that0x00
value reachwas
thesuccessfully
MITM flow received.
will be forwarded to the Modbus server.
Figure 12. Event log of access control disabled.
As the access control is disabled, the token is forced to a null value. Furthermore, the
read and write requests to the register 0x64 can be successfully performed through the
Modbus client flow. Remember that a Modbus/TCP frame is named ADU (Figure 1).
Therefore, the first request is composed of the MBAP header and the read holding register
PDU (Figure 13a), and the subsequent frame is the successful response (Figure 13b), where
the register
Figure 12.
Figure value
12.Event
Eventlog0x00 was control
ofofaccess
log accesssuccessfully received.
controldisabled.
disabled.
As thecode
Function access control is disabled,
1 Byte the token is forced to a null value. Furthermore, the
0x03
readStarting
and write
Addre ssrequests to the register
2 Byte s 0x64 can
0x0000betosuccessfully
0xFFFF performed through the
Modbus client
Quantity flow.
of Re giste rs Remember2 Byte
thats a Modbus/TCP frame is named ADU (Figure 1).
1 to 125 (0x7D)
Therefore, the first request is composed
(a) Function of
Re the MBAP header and the read holding register
que st
PDU (Figure 13a), and the subsequent frame is the successful response (Figure 13b), where
the register value 0x00 was successfully received.
Byte count 1 Byte 2 x N*
Re giste r value N* x 2 Byte s
Function
*N code
= Quantity of Re giste rs 1 Byte 0x03
Starting Addre ss 2 Byte
(b) Succe s Re sponse
ssful 0x0000 to 0xFFFF
Quantity of Re giste rs 2 Byte s 1 to 125 (0x7D)
Error code 1 Byte 0x83
(a) Function Re que st
Exce ption code 1 Byte 01 or 02 or 03 or 04
Function code (c)1Error
Byte Re sponse 0x03
Figure
Figure13.
Re gisteRead
13. Read holding
r value register
holding PDUs.
register PDUs[32].
[32].
N* x 2 Byte s
*N = Quantity of Re giste rs
Then,a awriting
Then, writingrequest
requestofofthethe value0xFF 0xFFisiscarried
carriedout
outthrough
throughthe
thefunction
function14write
Sensors 2022, 22, 8024 (b) Succevalue
ssful Re sponse write
of 20
multiple register (Figure 14), ending with a new reading that proves that
multiple register (Figure 14), ending with a new reading that proves that the register’s the register’s
Error
value
value code from
changed
changed from0x00
0x00toto0xFF. 1 Byte
0xFF. 0x83
Exce ption code
Continuing with the access 1control Byte 01 or 02 or 03 or 04
deactivation, a request is made using the new
Function code (c)1Error
Byte Re sponse 0x10
user-defined function for user authentication. The results are shown in Figure 15. Moreo-
ver, Starting
the13.MITMAddreflow
ss forwards this2 request Byte s 0x0000 to 0xFFFF
Figure Read holding register PDUs. [32]. to the Modbus server that does not understand
the requested function, returning an exception,0x0000
Quantity of Re giste rs 2 Byte s to 0x007B
according to Figure 2d.
Byte
When count 1 Byte 2 x N*
Then, enabling
a writingthe accessofcontrol
request the value(Figure
0xFF16), the global
is carried outvariable
throughtoken is initially
the function set
write
Re giste rs Value N* x 2 Byte s Value
to null,
multiple and the user
register credentials
(Figure that
14), ending were
withpreviously
a new reading stored in proves
that the non-volatile memory
that the register’s
are loaded
value changedinto from
the system.
0x00 to 0xFF.
(a) Function Re que st
Continuing with the access control deactivation, a request is made using the new
user-defined
Function code function for user authentication.
1 Byte The
0x10 results are shown in Figure 15. Moreo-
ver,Starting
the MITM Addreflow
ss forwards this2 Byterequest
s to the Modbus
0x0000 server that does not understand
to 0xFFFF
the Quantity
requested function,
of Re giste rs returning2 an Byteexception,
s according
1 to 123 (0x7B) to Figure 2d.
*NWhen enabling
= Quantity thers access control (Figure 16), the global variable token is initially set
of Re giste
to null, and the user credentials thatssful
(b) Succe wereRe previously
sponse stored in the non-volatile memory
are loaded into the system.
(c) Error Re sponse
Figure
Figure 14.
14. Write multiple register
Write multiple register PDUs
PDUs.[32].
[32].
*NStarting
= Quantity of ss
Addre Re giste rs 2 Byte s 0x0000 to 0xFFFF
Quantity of Re giste rs (a) Function
2 Byte s Re que st0x0000 to 0x007B
Re giste rs Value N* x 2 Byte s Value
Starting Addre ss 2 Byte s 0x0000 to 0xFFFF
Quantity of Re giste rs 2 Byte s 1 to 123 (0x7B)
Sensors 2022, 22, 8024 (a) Function Re que st 14 of 20
Function code (b) Succe ssful Re sponse
1 Byte 0x10
Starting Addre ss 2 Byte s 0x0000 to 0xFFFF
Error code
Continuing 1 Byte 0x90
Quantity of Re gistewith
rs the access control
2 Byte s deactivation,
1 to 123 (0x7B) a request is made using the new
Exce ption code
user-defined function for user 1 Byte
authentication. 01The
or 02results
or 03 or are
04 shown in Figure 15. Moreover,
the MITM flow forwards this (c) Error
request Re sponse
(b) Succe ssfultoRethe Modbus server that does not understand the
sponse
Figure 14. Write
requested multiple
function, register PDUs.
returning [32].
an exception, according to Figure 2d.
(c) Error Re sponse
Figure 14. Write multiple register PDUs. [32].
Figure
Figure15.
15.Event
Eventlog
logofofnew
newfunction
functionwith
withaccess control
access disabled.
control disabled.
When enabling the access control (Figure 16), the global variable token is initially set
to null, and the user credentials that were previously stored in the non-volatile memory are
loaded into
Figure 15. thelog
Event system.
of new function with access control disabled.
Figure 16. Event log when enabling access control.
With the access control enabled, the initial tests of reading and writing in the register
0x64 are repeated (Figure 17) through the read holding register and the write multiple
register
Figure functions,
Figure 16.
16. Event logand
Event log whenitenabling
when is verified
enabling that
access
access the Modbus client has its access controlled and
control.
control.
Sensors 2022, 22, 8024 With the access

access control
controlenabled,
enabled,thetheinitial
initialtests
testsofofreading 15 register
of 20
readingandand writing
writingin in
thethe
register
0x64 are repeated
repeated (Figure
(Figure 17)17)through
throughthe theread
readholding
holdingregister
registerandandthe write multiple
the write multiple
register functions,
functions, and
andititisisverified
verifiedthat
thatthe
theModbus
Modbusclient clienthas
hasitsits
access controlled
access controlled andand
denied
deniedbybythethe MITM
MITM flow. When making
flow. When making requests
requeststotothetheModbus
Modbusserver
serverregister,
register, it re-
it receives
ceives an illegal
an illegal function
function exception
exception for both
for both requests.
requests.
Figure
Figure17.
17.Event
Eventlog
logofofillegal
illegalfunction toto
function read and
read write
and registers.
write registers.
The following tests will be performed using the new user-defined functions that were
developed and proposed in this work. Figure 18 presents the requests that were made by
the user that was labeled as Bob. Through the new user-defined function authentication
Sensors 2022, 22, 8024 15 of 20
Figure 17. Event log of illegal function to read and write registers.
The
The following
following tests
tests will
will be
be performed
performed using
using the
the new
new user-defined
user-defined functions
functions that
that were
were
developed
developed andand proposed
proposed in in this
this work.
work. Figure
Figure 18
18 presents
presents the
the requests
requests that
that were
were made
made by by
the
the user
user that
that was labeled as
was labeled as Bob.
Bob. Through
Through the
the new
new user-defined
user-defined function
function authentication
authentication
that
that was
was proposed
proposed by by this
this study
study (Figure
(Figure 2a),
2a), the
the MITM
MITM flow
flow confirms
confirms that
that Bob
Bob is
is aa trusted
trusted
user
user and
and that
that his
his credentials
credentials areare valid
valid before
before authenticating
authenticating the
the user
user to
to the
the system.
system. In In this
this
process,
process, aa token
token is
is generated
generated and and registered
registered in
in the
the given
given user’s
user’s token
token key,
key, as
as presented
presented in in
Figure
Figure 16,
16, and
and finally returning it
finally returning it in
in the
the request-response
request-response (Figure
(Figure 2c).
2c).
Figure
Figure 18.
18. Event
Event log
log of
of Bob’s
Bob’s requests.
requests.
Once the authentication

authentication confirmation
confirmation has has been
been successfully
successfully received,
received, thethe authentica-
authentica-
tion requests flow configures the global token variable with the token value is
tion requests flow configures the global token variable with the token value that that is re-
received
ceived in the authentication request response, which will be used from now on in the read
in the authentication request response, which will be used from now on in the read and
and write requests that are made through the new user-defined authorization function.
write requests that are made through the new user-defined authorization function.
Thus,
Thus, this
this performs
performs aa new
new reading
reading request
request from
from the
the Modbus
Modbus client
client flow,
flow, instead
instead of of
the
the standard
standard request
request through
through the read holding
the read holding register
register function.
function. Once
Once thethe global
global token
token
variable value
variable value isisdifferent
differentfrom
fromnull,
null,the
theModbus
Modbus client flow
client flowperforms
performsthethe
request
requestusing the
using
new proposed function (Figure 3a). This will encapsulate the original
the new proposed function (Figure 3a). This will encapsulate the original read holding read holding register
functionfunction
register togethertogether
with thewith
unique token that
the unique identifies
token the userthe
that identifies Bob,
userallowing the MITM
Bob, allowing the
flow to identify the user, originating the given request, and, consequently,
MITM flow to identify the user, originating the given request, and, consequently, allowing allowing access
controlcontrol
access to the registers and the
to the registers andother
the resources of theof
other resources Modbus serverserver
the Modbus by thebyroletheof each
role of
trusted user in the system.
each trusted user in the system.
As shown
As shown in in Table
Table1,1,the
theuser
userBobBobhas only
has onlythethe
read
readpermission.
permission.Therefore,
Therefore,it isitevident
is evi-
in this test that it was possible to perform the read operation successfully (Figure 3b).
dent in this test that it was possible to perform the read operation successfully (Figure 3b).
However, when performing the write operation through the encapsulation of the original
However, when performing the write operation through the encapsulation of the original
write multiple register function, the user Bob had his request denied by the MITM flow,
returning to the exception according to Figure 3c.
Figure 19 shows the exact requests that were made by Bob, but now they will be
performed by another user, Alice, who, according to Table 1, has both read and write access
to the Modbus server registers. First, the user Alice successfully authenticates to the MITM
flow, and her respective token is updated to the global token variable. Then, a read request
is performed successfully, and a written request is also performed successfully, changing
the value of the register to 0xFF. The proof of this change is validated by a second read
request that proves that the register 0x64 had its value changed to 0xFF.
Finally, Figure 20 presents the logs of a test that was carried out with the untrusted
user Cris. According to Table 1, this user is unknown by the system, so when trying to
authenticate, the MITM flow returns an exception, and consequently, the global token
variable is forced to have a null value.
Figurethe
changing 19value
showsofthe
the exact requests
register that
to 0xFF. Thewere
proofmade bychange
of this Bob, but now theyby
is validated will be
a sec-
performed by another user, Alice, who, according to Table 1, has both read and
ond read request that proves that the register 0x64 had its value changed to 0xFF. write ac-
cess to the Modbus server registers. First, the user Alice successfully authenticates to the
MITM flow, and her respective token is updated to the global token variable. Then, a read
request is performed successfully, and a written request is also performed successfully,
Sensors 2022, 22, 8024 changing the value of the register to 0xFF. The proof of this change is validated by a16sec-
of 20
ond read request that proves that the register 0x64 had its value changed to 0xFF.
Figure 19. Event log of Alice’s requests.
Figure
Figure19.
variable Event
19.is log
forced
Event ofofAlice’s
logto have arequests.
Alice’s null value.
requests.
variable is forced to have a null value.
Figure 20. User Cris’s authentication event log.

Figure 20.
6. Discussion
6. Discussion
The IEC 62443-4-2 standard qualifies the security maturity that was reached by a
The IEC 62443-4-2 standard qualifies the security maturity that was reached by a de-
device through its four security levels. Through the implementation and the tests with the
vice through its four security levels. Through the implementation and the tests with the
Figure 20. User
developed Cris’s authentication
functions eventdescribed
that have been log. here, its applicability for constructing the
developed functions that have been described here, its applicability for constructing the
access control system that allows level one of maturity is evidenced. Table 2 presents these
access control system that allows level one of maturity is evidenced. Table 2 presents these
6.items
Discussion
that make up the fundamental requirements for the authentication (FR 1) and the
items that make up the fundamental requirements for the authentication (FR 1) and the
usageThecontrol (FR 2). These
IEC 62443-4-2 secure
standard the component
qualifies against
the security casual
maturity attacks
that by unauthorized
was reached by a de-
usage control (FR 2). These secure the component against casual attacks by unauthorized
users with a generic knowledge of industrial systems, which use
vice through its four security levels. Through the implementation and the tests simple means, few
with the
resources, and low motivation [21].
developed functions that have been described here, its applicability for constructing the
accessThe Modbus/TCP
control system thatSecurity protocol
allows level one specifies an X.509
of maturity certificate
is evidenced. attribute
Table in order
2 presents to
these
define the role of a particular Modbus client device. However, it is the user’s responsibility
items that make up the fundamental requirements for the authentication (FR 1) and the
to build the access control system in order to use such information.
usage control (FR 2). These secure the component against casual attacks by unauthorized
In the implementation that has been presented in this work, the credentials and
the access rules are managed natively by the component, the support changes, and new
accounts, and enforce the security policies. The new functions that have been developed,
in addition to guaranteeing non-repudiation, allow the use of credentials based on a
username and a password, which, together with the use of certificates that are specified by
the protocol, could create an additional factor of authentication to the system.
Although public key infrastructure certificates are not used during testing, they are
essential for the functions to work correctly. Furthermore, they must support revocation or
have a limited expiration date in order to ensure encryption security [21].
Sensors 2022, 22, 8024 17 of 20
After identifying and authenticating each user, the usage control through the autho-
rization function protects the component against any unauthorized actions by verifying that
the necessary privileges have been granted before allowing a user to perform such actions.
Table 2. Security level one component requirements (CRs) for FR 1 and FR 2.
Item Requirement Description SL 1

Human user identification and
FR 1 CR 1.1 Yes
authentication
FR 1 CR 1.3 Authenticator management Yes
FR 1 CR 1.4 Identifier management Yes
FR 1 CR 1.5 Authenticator management Yes
FR 1 CR 1.7 Strength of password-based authentication Yes
FR 1 CR 1.10 Authenticator feedback Yes
FR 1 CR 1.11 Unsuccessful login attempts Yes
FR 1 CR 1.12 System use notification NA
FR 2 CR 2.1 Authorization enforcement Yes
FR 2 CR 2.2 Wireless use control NA
FR 2 CR 2.5 Session lock Yes
FR 2 CR 2.8 Auditable events Yes
FR 2 CR 2.9 Auditable storage capacity NA
FR 2 CR 2.10 Responses to audit processing failures NA
FR 2 CR 2.11 Timestamps Yes
FR 2 CR 2.12 Non-repudiation Yes
The audit-relevant events with access control timestamps are registered, and their
storage would allow future audits to be carried out, which is a capability that was not
applied to the tests since, as well as encryption, they were not of paramount importance for
validating the developed functions.
Regarding the vulnerabilities of the proposed method, in order to guarantee access to
the equipment, it is also necessary to control the other interfaces of access to the device,
whether for human users or not, as well as to ensure the quality of the individual secrecy of
password-based authenticators, which can be shared between system operators. Therefore,
policies must be built in order to limit the authenticate lifetime, forcing operators to use
and update them, as well as their responsibility under the credential.
The implemented access control also has vulnerabilities for actors with a lot of re-
sources and knowledge in IACS. In order to mitigate such vulnerabilities, and to guarantee
the device integrity through the root of trust and a secure boot process, multifactor authen-
tication capabilities must be employed to all access interfaces. In addition, double approval
by supervisors for changing the critical parameters in the system, the non-repudiation
for all types of users, the protection of diagnostics interfaces, the automatic notification
of integrity violations, the validation of the input data ensuring that they are within a
valid range, the deterministic output taking the equipment to a safe state in case of viola-
tions, and protections against a denial of service due to a lack of device resources caused
by high processing consumption allow control to be applied through the system’s data
input and output interfaces, instead of being performed during the establishment of the
communication session between devices. This allows the identification and the validation
of each human user before providing access to the resources of the device. The protocol
improvement approach with authentication and authorization features differs from other
published works, as it can be applied directly to the Modbus server, not requiring an
additional component. It also makes it possible to extend the access control to the edge
of IACS.
Another critical point is that the essential characteristics of the Modbus protocol
were not changed. Limiting the original PDU to 216 bytes when encapsulating the new
authorization function was necessary. Despite this, as it is a user-defined function, care
must be taken to not apply them together with PDUs that extrapolate such an amount of
Sensors 2022, 22, 8024 18 of 20
data, which, in the author’s opinion, is feasible since most Modbus public functions do not
exceed such a limit.
Finally, the implementation made it possible to validate and exemplify the usability
of the functions that have been developed, and the tests demonstrate the segmentation
of access by the users existing in the system, ensuring that the users with lower access
privileges do not perform the specific operations of the users with higher privileges.
7. Conclusions
Industrial networks are no longer physically isolated and are now integrated with
corporate intranets and the internet. Due to Industry 4.0 and digital transformation, this
shift is taking place abruptly while the Zero Trust concept has replaced traditional IT
architectures, such as edge or perimeter control.
The Modbus/TCP Security protocol, which was published by the Modbus organiza-
tion, establishes the adoption of the TLS protocol in order to increase the cybersecurity
maturity of the Modbus/TCP protocol, ensuring communication channel confidentiality
and device authentication if the mutual authentication feature is implemented. With the
two new user-defined functions that have been proposed in this work, the conclusion is
that they allow the enhancement of the protocol, adding authentication and authorization
functions that, together with the proposed method, permit the creation of access control for
any users (including humans, systems, or devices).
The tests implementing the functions and the access control method through the
Node-RED software prove the potential and the applicability of the two new functions.
The construction of the access controls, along with the authentication support, ensures
the non-repudiation of human users and guarantees security against casual unauthorized
access and use attempts of actors with generic knowledge in IACS, using simple means,
low level of resources, and low motivation.
This approach allows the protocol to extend the functions that have been developed
and the method that has been used to other applications and devices that use client–
server industrial communication protocols. This work has presented the construction of
access control for a PLC. Nevertheless, an IACS is made up of other equipment, such as
power converters. These devices lack safety features and are usually installed in critical
infrastructures. Implementing a similar approach in these converters would make it
possible to control the access to the users, whether they are humans, devices, or systems, to
these devices.
Once cybersecurity in power electronics is one of the authors’ research lines, future
research will aim to improve the functions and the methodology that have been proposed
in this work in order to implement a robust role-based access control that complies with
the second level of IEC 62443-4-2; additionally for those that are embed in a power con-
verter that is applied to electrical drives, which today are increasingly connected and are,
consequently, more exposed to cyber-attacks.
Author Contributions: Writing—original draft, T.M. and S.V.G.O. All authors have read and agreed
to the published version of the manuscript.
Funding: This work received financial support from the Coordenação de Aperfeiçoamento de Pessoal
de Nível Superior–CAPES–Brazil (PROAP/AUXPE, Grant 1484/2020, Process 88881594818/2020-01).
Informed Consent Statement: Not applicable.
Acknowledgments: The authors would like to thank Udesc and Furb for providing institutional
resources to this research.
Conflicts of Interest: The authors declare no conflict of interest.
Sensors 2022, 22, 8024 19 of 20
References
1. Al-Fuqaha, A.; Guizani, M.; Mohammadi, M.; Aledhari, M.; Ayyash, M. Internet of things: A survey on enabling technologies,
protocols, and applications. IEEE Commun. Surv. Tutor. 2015, 17, 2347–2376. [CrossRef]
2. Balda, J.C.; Mantooth, A.; Blum, R.; Tenti, P. Cybersecurity and power electronics: Addressing the security vulnerabilities of the
internet of things. IEEE Power Electron. Mag. 2017, 4, 37–43. [CrossRef]
3. Schrecker, S.; Soroush, H.; Molina, J.; LeBlanc, J.; Hirsch, F.; Buchheit, M.; Witten, B. Industrial Internet of Things Volume G4: Security
Framework; Industrial Internet Consortium: Austin, TX, USA, 2016.
4. Martins, T.; Oliveira, S.V.G. Cybersecurity in the Power Electronics. IEEE Lat. Am. Trans. 2019, 17, 1300–1308. [CrossRef]
5. Rüßmann, M.; Lorenz, M.; Gerbert, P.; Waldner, M.; Justus, J.; Engel, P.; Harnisch, M. Industry 4.0: The future of productivity and
growth in manufacturing industries. Boston Consult. Group 2015, 9, 54–89.
6. Hartmann, B.; King, W.P.; Narayanan, S. Digital manufacturing: The revolution will be virtualized. McKinsey and Company, 1
August 2015.
7. Filkins, B.; Wylie, D.; Dely, A.J. Sans 2019 State of ot/ics Cybersecurity Survey. SANSTM Institute, 12 June 2019.
8. Bassett, G.; Hylender, C.D.; Langlois, P.; Pinto, A.; Widup, S. 2020 Data Breach Investigations Report. Verizon, 2020. Available
online: https://www.verizon.com/business/resources/reports/2020-data-breach-investigations-report.pdf (accessed on 3
February 2022).
9. Satyanarayana, P.; Rajesh, L. Detection and Blocking of Replay, False Command, and False Access Injection Commands in SCADA
Systems with Modbus Protocol. Secur. Commun. Netw. 2021, 2021, 8887666. [CrossRef]
10. Kindervag, J.; Balaouras, S. No more chewy centers: Introducing the zero trust model of information security. Forrester Res.
2010, 3. Available online: https://www.forrester.com/report/No-More-Chewy-Centers-The-Zero-Trust-Model-Of-Information-
Security/RES56682 (accessed on 15 September 2022).
11. Holmes, D.; Burn, J.; Turner, S. The Definition of Modern Zero Trust. Forrester, 24 January 2022. Available online: https:
//www.forrester.com/report/the-definition-of-modern-zero-trust/RES176986?ref_search=0_1666232401780 (accessed on 15
September 2022).
12. Rinaldi, J. Modbus Security. 2018. Available online: https://www.rtautomation.com/rtas-blog/modbus-security-2/ (accessed
on 29 April 2022).
13. Figueroa-Lorenzo, S.; Añorga, J.; Arrizabalaga, S. A Role-Based Access Control Model in Modbus SCADA Systems. A Centralized
Model Approach. Sensors 2019, 19, 4455. [CrossRef] [PubMed]
14. Zetter, K. Countdown to Zero Day: Stuxnet and the Launch of the World’s First Digital Weapon; Crown: New York, NY, USA, 2014.
15. Fovino, I.N.; Carcano, A.; Masera, M.; Trombetta, A. Design and implementation of a secure modbus protocol. In Critical
Infrastructure Protection III, Proceedings of the International Conference on Critical Infrastructure Protection, Hanover, NH, USA, 23–25
March 2009; Springer: Berlin/Heidelberg, Germany, 2009; pp. 83–96. [CrossRef]
16. Hayes, G.; El-Khatib, K. Securing modbus transactions using hash-based message authentication codes and stream transmission
control protocol. In Proceedings of the 2013 Third International Conference on Communications and Information Technology
(ICCIT), Beirut, Lebanon, 19–21 June 2013; pp. 179–184. [CrossRef]
17. Infineon. Optiga TPM SLB 9670 TPM2.0 Datasheet. Available online: https://www.infineon.com/dgdl/Infineon-SLB%209670
VQ2.0-DataSheet-v01_04-EN.pdf?fileId=5546d4626fc1ce0b016fc78270350cd6 (accessed on 27 April 2022).
18. Ferst, M.K.; de Figueiredo, H.F.; Denardin, G.; Lopes, J. Implementation of Secure Communication with Modbus and Transport
Layer Security protocols. In Proceedings of the 2018 13th IEEE International Conference on Industry Applications (INDUSCON),
São Paulo, Brazil, 12–14 November 2018; pp. 155–162. [CrossRef]
19. Xuan, L.; Yongzhong, L. Research and implementation of Modbus TCP security enhancement protocol. J. Phys. Conf. Ser. 2019,
1213, 25–58. [CrossRef]
20. Modbus. MODBUS/TCP Security Protocol Specification. Available online: https://modbus.org/docs/MB-TCP-Security-21_201
8-07-24.pdf (accessed on 27 January 2021).
21. IEC 62443-4-2; Security for Industrial Automation and Control Systems-Part 4-2: Technical Security Requirements for IACS
Components. 1.0 ed. International Electrotechnical Commission: Geneva, Switzerland, 2019.
22. About Node-RED. Available online: https://nodered.org/about (accessed on 22 July 2022).
23. Boakye-Boateng, K.; Ghorbani, A.A.; Lashkari, A.H. A Trust-Influenced Smart Grid: A Survey and a Proposal. J. Sens. Actuator
Netw. 2022, 11, 34. [CrossRef]
24. Radoglou Grammatikis, P.; Sarigiannidis, P.; Efstathopoulos, G.; Panaousis, E. ARIES: A Novel Multivariate Intrusion Detection
System for Smart Grid. Sensors 2020, 20, 5305. [CrossRef] [PubMed]
25. Siniosoglou, I.; Radoglou-Grammatikis, P.; Efstathopoulos, G.; Fouliras, P.; Sarigiannidis, P. A Unified Deep Learning Anomaly
Detection and Classification Approach for Smart Grid Environments. IEEE Trans. Netw. Serv. Manag. 2021, 18, 1137–1151.
[CrossRef]
26. Smolarczyk, M.; Plamowski, S.; Pawluk, J.; Szczypiorski, K. Anomaly Detection in Cyclic Communication in OT Protocols.
Energies 2022, 15, 1517. [CrossRef]
27. Sarkar, S.; Teo, Y.; Chang, M. A cybersecurity assessment framework for virtual operational technology in power system
automation. Simul. Model. Pract. Theory 2022, 117, 102453. [CrossRef]
Sensors 2022, 22, 8024 20 of 20
28. de Brito, I.B.; de Sousa, R.T., Jr. Development of an Open-Source Testbed Based on the Modbus Protocol for Cybersecurity
Analysis of Nuclear Power Plants. Appl. Sci. 2022, 12, 7942. [CrossRef]
29. ISO/IEC 27001:2013; Information Technology-Security Techniques-Information Security Management Systems-Requirements.
International Organization for Standardization: Geneva, Switzerland, 2013.
30. Metz, C. AAA protocols: Authentication, authorization, and accounting for the Internet. IEEE Internet Comput. 1999, 3, 75–79.
[CrossRef]
31. National Instruments. The Modbus Protocol In-Depth. Available online: https://www.ni.com/en-us/innovations/white-
papers/14/the-modbus-protocol-indepth.html (accessed on 29 April 2022).
32. Modbus Organization. MODBUS Application protocol specification. Hopkinton: Modbus Organization. 2012. Available online:
https://modbus.org/docs/Modbus_Application_Protocol_V1_1b3.pdf (accessed on 29 April 2022).
33. Tehranipoor, F.; Yan, W.; Chandy, J.A. Robust hardware true random number generators using DRAM remanence effects. In
Proceedings of the IEEE International Symposium on Hardware Oriented Security and Trust (HOST), McLean, VA, USA, 3–5 May
2016; pp. 79–84. [CrossRef]
34. Lampert, B.; Wahby, R.S.; Leonard, S.; Levis, P. Robust, low-cost, auditable random number generation for embedded system
security. In SenSys ‘16: Proceedings of the 14th ACM Conference on Embedded Network Sensor Systems CD-ROM, Stanford, CA, USA,
November 2016; pp. 16–27. [CrossRef]

Sensors 22 08024 v2

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sensors 22 08024 v2

Uploaded by

Copyright:

Available Formats

sensors

Citation: Martins, T.; Oliveira, S.V.G.

Sensors 2022, 22, 8024. https://doi.org/10.3390/s22208024 https://www.mdpi.com/journal/sensors

2. Other Related Works

3. Enhanced Modbus/TCP Security Protocol

Function code 1 Byte 0x69

Function code 1 Byte 0x69

Function code 1 Byte 0x69

Error code 1 Byte 0xE9

Function code 1 Byte 0x6A

Function code 1 Byte 0x6A

Function code 1 Byte 0x6A

Error code 1 Byte 0xEA

Sensors 2022, 22, 8024 8 of 20

Figure 4. Example of an industrial automation and control system.

Figure 6. Laboratory’s scenario, MITM agent.

Figure 8. Node-RED auxiliary flow.

Table When activating

Table 1. Users’ permissions.

Sensors 2022, 22, 8024 User Trusted Write Read 12 of 20

Sensors 2022, 22, 8024 13 of 20

Figure 12. Event log of access control disabled.

Figure 14. Write multiple register PDUs. [32].

Figure 16. Event log when enabling access control.

Sensors 2022, 22, 8024 With the access

Once the authentication

Figure 19. Event log of Alice’s requests.

Figure 20. User Cris’s authentication event log.

Table 2. Security level one component requirements (CRs) for FR 1 and FR 2.

Item Requirement Description SL 1

You might also like