SecureRTU: security on RTU configuration

management by Digital Signatures

Alessandro Distefano (lead author) Stefano Zanin

and Luciano Zaretti and Danilo Dealberti
and Giandomenico Lattuada Selta spa - www.selta.it
Terna Rete Italia - www.terna.it Email: [email protected]
Email: [email protected] [email protected]
[email protected]
[email protected]

Abstract—Security in energy and power industry is histori- • Inadvertent Threats: Safety Failures, Equipment Fail-
cally a hard-to-solve topic. In this paper, according to the current ures, Carelessness and Natural Disasters.
security improvement trend, we describe a new architecture called
SecureRTU (SRTU) aiming at securing the management of the • Deliberate Threats: Disgruntled Employee, Industrial
RTUs configuration workflow. SRTU supports Integrity, Authen- Espionage, Vandalism, Cyber Hackers, Viruses and
ticity and Non Repudiation leveraging on Digital Signatures and Worms, Theft and Terrorism.
can be combined with other security services and protocols (e.g.,
IEC 62351). The key point is that the overall security of power systems
is hampered not only by espionage or terrorism but by many
Keywords—Electricity supply industry, Security, Digital signa-
tures, Information security. other threats, deliberate or inadvertent, that can have very
serious consequences as well[4]. At the same time, it is
fundamental to note that additional security troubles are related
I. I NTRODUCTION to the business and the business processes that large and small
Historically, in the power industry, the focus has been utilities have (e.g., the relations with institutions, stakeholders
mainly on implementing equipments able to keep the power and service providers[3]).
system secure and reliable while, until recently, the communi-
cation and information flows have been considered less impor- C. Enforcing Security in Power Industry
tant. However, since the Information Infrastructure supporting
the operation of the power system has become pervasive, it Power system operations pose security challenges that are
has become critical to the reliability of the power system different from other industries and, at the same time, in the
itself. Hence it is fundamental to ensure the security and security industry there is typically a lack of understanding of
the reliability of the Power System Infrastructure and of the the security requirements and the potential impact of security
Information Infrastructure as well. measures on power system operations. Often the security
services and technologies have been designed for industries
that do not have many of the strict performance and reliability
A. Information Security in Energy Industry requirements needed by power system operations. We can cite
Regarding this topic, Information Security has gained some differences as follows:
tremendous importance for energy production, transmission
and distribution over the last years. At the same time, a secure • Unauthorized access to power systems can be more
grid operation and management causes new use cases which serious than others.
the well-established standards and protocols (e.g., IEC 61850, • Communication channels are often narrow-band so
IEC 60870-5) do not address. Both the IEC 61850 and IEC limiting the implementation of security features.
60870 are flanked by the IEC 62351 that addresses security
and specifies technical requirements which have to be met by • Equipments are located in wide-spread, unsupervised
vendors and technology providers[1]. and remote sites.
• Systems are connected by multi-drop channels.
B. Cyber Security Threats in Electric Utilities
• Limitations on wireless technologies due to the noisy
A sound security management entails a much larger scope electrical environment.
than just the authentication of users and the encryption of
communication protocols. In fact end-to-end security involves 1) Main Security Measures: Because of the large variety
security policies, access control mechanisms, key management, of security requirements, communication methods and perfor-
audit logs, and other features related to critical infrastructure mance characteristics and because no single security measure
protection[2]. In such scenario we can arrange the main can face all types of threats, often the best choice is to
security threats into the two following groups: implement multiple layers of security measures. Translating

978-1-4799-7736-9/15/$31.00 ©2015 IEEE 356

requirements and needs into desired features and services, it Therefore, cybersecurity must be viewed as a stack or “profile”
is possible to note that the main aspects to be addressed can of different security technologies and procedures, woven to-
be the following: gether to meet the security requirements of a particular imple-
mentation of policy, procedural, and communication standards
• Identity Management: identities and the related appli- designed to provide specific services.
ances must be uniquely identified and managed.
• Mutual Authentication: given a communication the II. RTU S C ONFIGURATION M ANAGEMENT
entities taking part can always mutually identify them- Remote Terminal Units (RTUs) are the devices commonly
selves. used in Supervisory Control And Data Acquisition (SCADA)
• Authorization: the permissions provided to systems in order to support the communication between SCADA cen-
and persons are specified and systematically enforced. ters (typically servers) and the managed and controlled field
(e.g., power plants, electrical stations). Regarding the Terna
• Audit: each occurring event have to be recorded, scenario, RTUs are used to exchange the following main kinds
stored and protected. of information:
• Confidentiality: only the authorized systems and per- • Commands: orders given from the SCADA center and
sons can access to each given information. received by the field to perform modifications on the
arrangement of the electrical grid.
• Integrity: for each information the consistency and
accuracy must be ensured during the entire lifecycle. • Signals: information sent by the field and received by
the SCADA center (e.g., response to a given command
• Availability: for each information must be defined a or alarms from the field).
proper set of measures in order to ensure the access
to the information and the quality (e.g., Service Level • Measures: information sent by the field and received
Agreement) of such access. by the SCADA center regarding levels of current,
power, voltage or energy.
2) Modularity and Interoperability: As introduced in the
previous section, implementing security often means to adopt The set of Commands, Signals and Measures of a given RTU
different levels of countermeasures hopefully belonging to well can be named as the RTU SCADA objects. The information
known standards or products. For such reason modularity and set composed by RTU SCADA objects and by information
interoperability are very important for security products and strongly related to the network and configuration of the same
often determine their success and wide adoption. Modularity RTU (most often called RTU parameters) can be referred as
refers to the possibility to customize a given security suite the RTU configuration. The configuration of a given RTU,
in order to enable or disable the different features. While typically, evolves during time due to the addition and deletion
interoperability is strongly related to the compatibility between of SCADA objects and the modification of RTU parameters
different security solutions, services and suites. The architec- and the proper management of RTU configuration is a crucial
ture proposed in this paper is both customizable (e.g., security element in order to securely and safely manage the correct
suites, communication protocol) and interoperable with well exercise of the given RTU.
known standards (e.g., IEC 62351) and can use the bottom
layers security services and features (e.g., SSL, TLS). A. Terna approach
3) Standards for Information Exchange and Cybersecurity: Currently, Terna is completing the deploy of the new
The task of matching cybersecurity with information exchange system focused on the conduction and control of the Italian
standards, functional requirements standards, object modeling grid; such system, named SCCT, will overcome a lot of
standards, and communication standards is very complex and limitations and restrictions imposed by the previous system
there is rarely a one-to-one correlation, with more often a one- (e.g., Data Engineering issues, complexity and capacity limits).
to-many or many-to-one correspondence. Relating SCCT, which is strictly related to RTU operation,
the implementation of a stronger, more secure, more accurate,
1) Communication standards are designed to meet many more efficient and semi-automated management of RTU con-
different requirements at many different “layers” in figurations has been a main requirement. In fact, the previous
the reference model. Two common reference models overall workflow was leveraging on several and loosely auto-
are the ISO-OSI 7-layer reference model and the mated tasks (e.g., usage of spare Excel spreadsheets) in order
GridWise Architecture Council (GWAC) Stack [5]. to compose, load and maintain the RTU configurations. We
2) Regardless of used communications standards, cyber- can depict a very simplified version of the current workflow
security must address all layers from the source to the in Figure 1, where it is possible to note how the RTU
destination of the data. configuration is built from the information stored in the Terna
3) The cybersecurity requirements must reflect the envi- master database describing the whole electrical grid (Grid
ronment where a standard is implemented while com- Master Data - GMD). Such workflow, although is able to solve
munications standards do not address the importance several issues due to the manuality of the previous one, should
of specific data or how it might be used in systems. be hardened since the RTU is unable to validate the quality and
4) Some standards are described using “shall” ,“should” the reliability of a given configuration: in other words, given
, “may” or “could” statements causing the whole a binary ready-to-load configuration the RTU cannot deny to
stardard to be vague. load it.

357
 disalignments. For such reasons, several security requirements
about the entire management of RTU configuration workflow,
arose. The main requirements can be summarized as follows:
• Integrity: means maintaining and assuring the ac-
curacy and consistency of data over its entire life-
cycle. This means that data cannot be modified in
an unauthorized or undetected manner. Integrity is
violated when a configuration is actively modified
between its creation and loading.
• Authenticity: means confirming the identity of a per-
son, tracing the origins of an artifact, ensuring that a
configuration is what its packaging and labeling claims
to be.
• Non-repudiation: means the guarantee that a given
Fig. 1. The SCCT RTU configuration workflow. configuration has been compiled by the part claim-
ing to have generated it. With non-repudiation it is
impossible that the entity which has compiled the
configuration can later deny its responsibility.
Currently, the entire management of all the RTU configu-
rations is organized as follows. Both the GMD and the central Such requirements matches the general security require-
repository, in charge of maintaining all the source configura- ments of a common scenario where Digital Signatures can
tions, are centralized within the team supporting all the Data be applied with success; hence we decided to explore the
Engineering tasks related to the electrical grid. Each time a possibility to use Digital Signatures on RTU configuration
given plant requires a reconfiguration (e.g., due to changes of management. The goal was to enhance RTU features in order
the surrounding grid) the new source configuration, stored as to allow the understanding and validation of a Digital Signature
XML file, is created and subsequently it is processed by the applied to the configuration ready to be loaded as shown in
RTU vendor-related tools (e.g., ABB or Selta manufacturer) Figure 2.
in order to build the binary and ready-to-load configuration
which is stored in a vendor-dependent format. When the binary
configuration is ready, it is required to obtain an agreement
between the teams responsible of the daily operation of the
grid and the central Data Engineering team in order to avoid
any kind of outages related to the update of RTU configuration.
Typically, if the given plant requires also other activities, is
frequent that the update is locally supervised by the Terna field
staff; anyway, the update is started and performed remotely,
while the field staff could attend if any issue occurs. When
the update is completed, and the RTU performs as expected,
the central Data Engineering team takes care of updating the
central repository storing the new official configuration in place
of the previous one.

B. Desired improvements and security requirements

Since the RTU is able to load any binary configuration, it is Fig. 2. The Secured SCCT RTU configuration workflow based on SecureRTU.
possible that the central official repository could be disaligned
with respect to the one loaded into a single RTU at a given
time. Such tricky situations, which can lead to a lot of troubles,
C. Exploiting DS in RTUs Configurations Management
could be caused by unofficial update eventually loaded directly
onto the RTU. Furthermore, since the RTU loads a binary A typical Digital Signature (DS) schema is composed by
configuration, a change can be performed also directly on the following main entities:
the ready-to-load configuration without being replicated on
the XML source and/or in the GMD. In any situation, a • A digital content to be signed and lately verified.
disalignment between the source information (GMD or XML), • One or more pairs composed by a secret key, used to
the central repository and the configuration loaded into a given sign the digital content, and a digital certificate used
RTU is hazardous. At the same time, until the RTU can load to store the public information of a given identity.
any binary configuration it is impossible to implement an end-
to-end secure management because the final destination of the • One or more entities able to generate signatures,
digital data is the RTU itself. Hence the securization of the typically each one equipped with a pair as abovemen-
end-point RTU is the final strategy in order to prevent any tioned.

358
 • One or more Certification Authorities (CA) issuing the given and fixed port where the SRTUs know the CA is up
aforementioned pairs and ensuring the match between and running. The IP address of the CA is stored in the
the known identities and the issued certificates and Distinguished Name of the digital certificate of the CA itself
secret keys. which is shared with all the SRTUs.
The User interface has been implemented as a simplified
III. T ERNA S ECURE RTU
front end for the security suite used by the CA (OpenSSL
As described in Section I-C, when security must be de- security library). Such interface provides support to remotely-
ployed in a real scenario, and in particular in Power Industry, logged-in users in order to perform the examination and release
it is mandatory to perform several strategic choices (e.g., of certificates. We can state that the overall SRTU architecture
performance, usability). uses only two kinds of digital certificates. The first, which is
unique, is the digital certificate of the CA; while the second,
A. Overall Architecture having multiple instances, is the set of certificates given to
users able to sign RTU configurations.
Relating the Terna scenario, it has been enough to imple-
ment the following schema. 2) Security Suite: All the security features have been
implemented using the Elliptic Curves (ECs) asymmetric en-
A single CA which is in charge of the issuing and man- cryption schema. ECs, currently, represent an efficient alterna-
agement of all the secret keys and certificates storing all the tive to other schemas due to the mathematic features of the
relevant information about the known entities (e.g., name, computations it relies on. In fact, the problem of finding ECs
staff unit, responsibilities, validity constraints). Each subject factors is computationally harder to solve if compared to other
designed as able to sign RTU configuration receives a pair common problems related to asymmetric encryption (e.g., big
made by a certificate and a secret key which allows the entity integers factorization). For such reason, ECs are among the
to sign configurations which can be lately verified. desirable schemas when the high efficiency and reduced key
The RTU (from now called SRTU) asked to load a signed lengths are interesting requirements. For instance, the current
configuration, first check the correctness of the proposed signa- NIST recommendations on key to be used in cryptography
ture, then asks to the CA to check the validity (e.g., temporal, state that 224 bits-EC keys are comparable to 2048 bits-RSA
administrative) of the issuing signer of the configuration. The keys in terms of robustness and security [6]. Since we consider
signature of any configuration is stored in XML open format the efficiency as a strongly desired feature, we choose to use
allowing to anyone to open and read the signature information. Elliptic Curve Digital Signature Algorithm (ECDSA) in order
to implement the whole SRTU architecture.
The choice to leave to CA the effort due to the check of
all the certificates presents both advantages (e.g., lightening of 3) Communication Protocol: The entire communication
SRTU effort, avoiding to distribute signer’s certificates) and protocol between SRTUs and CA follows the Client-Server
disadvantages (e.g., single point of failure). However, since paradigm and it is made by a restricted set of messages
the CA is implemented by a fully redounded and load-balanced exchanged through XML format in order to improve the
central server with disaster recovery measures, it seems not to portability and standardization of the whole architecture. The
be a limit for the overall architecture. messages can be organized as follows:
It is worth to note that Terna has a redundancy in the • Requests from the SRTU: messages sent by the SRTU
RTU configurations repository as well (as described in Section to the CA. For instance, SRTUs contact CA in order
II-A). In fact, at a given time there are three hypothetically to identify the CA itself and further to obtain the
valid configurations for a given RTU: the one stored by validation of a given SRTU configuration issuer.
the RTU itself, the one held by the Data Engineering team
• Responses from the CA: messages sent in response
and the one stored by the SCADA repository. Since these
to a given request and conveying the information
three configurations must be always kept aligned, the same
requested by the SRTU. For instance, CA answers to
validation of a signed configuration performed by a SRTU
a given SRTU when it is requested to be identified or
must be performed when the same configuration is stored
when the CA must check the validity of the signer of
into the SCADA repository. For such reason, the SCADA
a given RTU configuration.
repository has been equipped with the same validation features
deployed onto the SRTU and talk to the CA following the same The following XML fragment shows the request that is
protocol being described in Section III-A3. made from SRTU to CA in every interrogation in order to
properly identify the CA:
1) Certification Authority: CA is implemented as a server
running on Red Hat Enterprise Linux virtual machine which <XML_CONF_VALIDATOR>
can support the customized communication protocol being de- <ID>AUTH</ID>
scribed in Section III-A3. CA provides two different interfaces: <TIMESTAMP>21/11/2014 11:30:46</TIMESTAMP>
the SRTU interface supporting the communication between the <NOUNCE>
SRTUs and the CA, in order to validate the signatures related 30462841871428404886824718656270
to each candidate and signed configuration, and the User in- </NOUNCE>
terface supporting the management (e.g., release, modification, <SIGN>0</SIGN>
examination) of the whole set of the known certificates. </XML_CONF_VALIDATOR>

The SRTU interface has been implemented by a simple The following XML fragment shows the identification
set of processes running on background and listening to a answer from CA to SRTU, the identification is ensured by

359
the element <SIGN> which stores the signature of the answer provides great flexibility as any upgrade can be carried out
itself signed with the private key of the CA: without any interference with standard telecontrol operations,
which is implemented by other segregated processes, and
<XML_CONF_VALIDATOR> without the need of a kernel change. Furthermore, it allows
<ID>ACK_AUTH</ID> to support in a very smart way any security upgrade as soon
<TIMESTAMP>2014-Nov-21 10:30:47</TIMESTAMP>
as a new fix or release is available for the OpenSSL library.
<NOUNCE>
The simplified flowchart of the SRTU process is depicted in
30462841871428404886824718656270
</NOUNCE> Figure 3.
<SIGN>
MEUCIQC8x7bwPpQZFPVuBpg545e3VFoe
62pQxSlmunkv8R7brQIgXeeo7PD1ZT5+
s88+x3tb623114kKmB3ZUOz91yNBnoo=
</SIGN>
</XML_CONF_VALIDATOR>

The following XML fragment shows the request that is

made from SRTU to CA in order to validate the issuer of a
given SRTU configuration signature, the issuer is identified by
the element <DN_PROD_CONF>:

<XML_CONF_VALIDATOR>
<ID>AUTH_CONF</ID>
<TIMESTAMP>21/11/2014 10:35:17</TIMESTAMP>
<NOUNCE>
65531244803860665766706221054113
</NOUNCE>
<DN_PROD_CONF>12345_John_Doe</DN_PROD_CONF>
<CERT_ID>01</CERT_ID>
<SIGN>0</SIGN>
</XML_CONF_VALIDATOR>

The following XML fragment shows the answer (which is

signed as well as the previous case) from CA to SRTU in order
to validate the issuer of a given SRTU configuration signature,
the result is shown by the element <ANSWER>:

<XML_CONF_VALIDATOR>
<ID>ACK_AUTH</ID>
<TIMESTAMP>2014-Nov-21 10:35:18</TIMESTAMP>
<NOUNCE>
65531244803860665766706221054113
</NOUNCE>
<ANSWER>OK</ANSWER>
<SIGN>
MEUCIBKnVV89WY8GqD9jx4wsSI3WIYD4
heGFcY5ID8Eu2qY1AiEAornSp6Z+aMzs
aVqAyCcNARyZW02YFC95rQYI3rj8daI=
</SIGN>
</XML_CONF_VALIDATOR> Fig. 3. The simplified flowchart of the SRTU firmware.

4) RTU Firmware: Selta RTUs are made by specialized 5) SecureRTU Deploy: The whole SRTU architecture has
I/O cards (e.g., digital inputs, digital outputs, analog input, been designed and implemented keeping the deploy effort as
analog outputs) and a communication and management central minor as possible. Hence, it has been fundamental to identify
processor unit equipped with a 32 bit MMU-capable pro- the best-performing strategy in order to implement both the
cessor. In order to support a wide spectrum of features and CA and the new features the SRTU must support. Regarding
protocols, the central processor is equipped with a Linux the CA, as already described, the choice was to implement it
Operating System. Such central unit executes the whole RTU as a standard fully redounded and disaster recovery resilient
software platform (commonly referred as the RTU firmware) centralized server while regarding the SRTU the chosen strat-
made by different processes, each one dedicated to a specific egy was to implement the SRTU features as an independent
function (e.g., supervision center communication, I/O cards and stand-alone process. Following such strategy, the benefits
management). The SRTU has been implemented by one of are twofold:
such specialized processes: this process, implemented in C++
language, supports the protocol described in Section III-A3 and • The deploy of SRTU onto a standard RTU means a
uses OpenSSL crypto library for every crypto-operation (e.g., simple firmware update and such task can be per-
verification, hash computation). This implementation strategy formed also remotely.

360
 • The SRTU features, being segregated on a different
process, cannot negatively affect the other standard
services of the SRTU.
Hence the massive deploy of SRTU can be performed by
updating only the RTU firmware, in order to support the new
features, without any need to change neither RTU hardware
nor other RTU software. Such item is strongly desirable since
Terna plans adopt the SRTU architecture for all the RTUs
currently used to control and conduct the Italian National Grid.

IV. C ONCLUSIONS
In this paper we present a new idea to manage, in a
more secure way, the workflow of compiling and installing
RTUs configurations. The proposed architecture, named Se-
cureRTU, is able to ensure the Integrity, Authenticity and
Non Repudiation security features as desired. Furthermore, the
technical and financial effort required to adopt the architecture
is reduced and very interesting if compared to more complex
configuration management systems. Moreover, the architecture
is fully compatible and interoperable with other standards (e.g.,
IEC 62351) each one focusing on specific and different aspects
of security in energy environments. Currently the solution has
been implemented as a prototype only for Selta RTUs. In the
near future, Terna plans to perform the following activities:
• Extend the prototype to other RTU manufacturers
(e.g., ABB).
• Perform a wide test of the entire architecture.
• Adopt and deploy the architecture for the Italian
national grid.

R EFERENCES
[1] IEC 62351 - International Electrotechnical Commission Power systems
management and associated information exchange Data and communi-
cations security,
[2] CLUSIF - Cyber Security of Industrial Control Systems: How to get
started?, September 2014.
[3] Frances Cleveland, IEC 62351 Security Standards for the power system
information infrastructure, IEC TC57 WG15 Security Standards, June
2012.
[4] Megan O’Connor, Mark A. Nicholas, Satoshi Nakamura and Tom Kacz-
marek Managing Cybersecurity Threats to the Smart Grid, Syracuse
University, June 2013.
[5] Smart Grid Interoperability Panel GridWise Architecture Council Stack,
http://www.sgip.org/Interoperability-and-the-GWAC-Stack, January 2015.
[6] National Institute for Standards and Technology Criptographic
Key Length Recommendation, http://www.keylength.com/en/4/, February
2015.

361

Powered by TCPDF (www.tcpdf.org)