Main IEC

Download as pdf or txt
Download as pdf or txt
You are on page 1of 9

DOI: http://dx.doi.org/10.14236/ewic/ICS2015.

Assessing the Security of IEC 62351

Roman Schlegel Sebastian Obermeier Johannes Schneider


ABB Corporate Research ABB Corporate Research ABB Corporate Research
Segelhofstr. 1K, Baden Segelhofstr. 1K, Baden Segelhofstr. 1K, Baden
Switzerland Switzerland Switzerland
[email protected] [email protected] [email protected]

IEC 62351 is an industry standard aimed at improving security in automation systems in the power system
domain. It contains provisions to ensure the integrity, authenticity and confidentiality for different protocols
used in power systems. In this paper we look at the different parts of IEC 62351 and assess to what extent
the standard manages to improve security in automation systems. We also point out some incongruities in
the algorithms or parameters chosen in parts of the standard. Overall, we conclude that the standard can
significantly improve security in power systems if applied comprehensively, but we also note that the need
to preserve (partial) backwards-compatibility has led to some design choices that provide less security than
could have been achieved with a more ambitious approach.

Keywords: cyber security, IEC 62351, cyber security standard

1. INTRODUCTION several decades, improvements can only be made


gradually and over time. Nevertheless, in recent
Automation systems are an important part of years efforts have been made to address these
everyday life. They manage the distribution of issues, for example by creating new standards
energy (e.g., electricity, gas, etc.) and water, control that describe how to augment decades-old systems
transportation systems, run power stations and and protocols so that they can offer better
factories, and manage environmental aspects of protection against malicious attacks. There are
large office buildings (e.g., heating/cooling, lighting, a number of standards for automation systems
etc.), among many other things. A failure of in general, however, IEC 62351 (International
critical infrastructure can cause significant economic Electrotechnical Commission (IEC) (2010b)) in
damage within a short period of time (Anderson particular addresses security in systems and
and Fuloria (2010); Guthrie and Konaris (2012)), protocols that are predominantly used in automation
and even endanger the lives and safety of a systems in the electricity distribution domain. Like
population. Failures of critical infrastructure can many of these standards, it is not a revolution, but a
be caused by different events, such as natural careful evolution, to address security issues without
catastrophes (e.g., flooding), equipment malfunction completely breaking backwards-compatibility and
or also human error. However, another cause that interoperability with legacy systems. In this paper, we
has become more important in recent years are evaluate how IEC 62351 addresses security issues
targeted attacks by hackers on the systems running in existing systems, to what extent it can mitigate
critical infrastructure (Miller and Rowe (2012)). these issues, and whether there are remaining
Because of society’s dependence on automation issues that are not mitigated by the standard.
systems it is therefore paramount to not only
improve the resilience of such systems against This paper is organized as follows: In Section 2
equipment malfunction and human error, but also we give an overview of IEC 62351 and its ten
improve the security against targeted and malicious parts, followed by an evaluation of the standard in
attacks of hackers. Unfortunately, many of these Section 3. Section 4 provides an overview of related
systems have been designed and built at a time work and standards, and Section 5 finally concludes.
when defending against malicious attackers was
not a priority, because such attacks were rare and
systems were much less interconnected than they 2. IEC 62351 OVERVIEW
are today. Furthermore, because of the typically
While the first parts of IEC 62351 (International
long lifetime of automation systems of up to
Electrotechnical Commission (IEC) (2010b)) were


c Schlegel et al. Published by
BCS Learning & Development Ltd. 11
Proceedings of the 3rd International Symposium for ICS & SCADA Cyber Security Research 2015
Assessing the Security of IEC 62351
Schlegel • Obermeier • Schneider

published as early as 2007, more recent parts the T-Profile based on TCP/IP. For the A-Profile,
have been published in 2010, with some parts still IEC 62351-4 describes the use of X.509 certifi-
being a work in progress and an expected stability cates to authenticate applications, while for the TCP
date of around 2015. The standard addresses T-Profile the standard describes how to use TLS as
information security for power systems control a layer between TCP and the ISO Transport Service
operations, and the overall objective is to preserve (Rose and Cass (1987)) using a different TCP port
the properties of confidentiality, integrity, availability for secure connections. Further defined are the TLS
and non-repudiation in a system, mainly through the cipher suites that must (or should) be supported.
introduction of authentication mechanisms.
IEC 62351-5: The fifth part of the IEC 62351
The standard is split into ten different parts that standard describes security for protocols related to
address different areas, although at least one of the IEC 60870-5 and derivatives such as DNP-3 (IEEE
parts has not yet been released (part 9). In the Standards Association (2012)). These protocols are
following we give a brief overview of the different message-based, and authentication therefore needs
parts of the standard. to be done on a per-message basis. In addition,
any security mechanisms need to take into account
IEC 62351-1: The first part contains a general the often limited processing power available in the
overview of the IEC 62351 standard, outlining affected devices. As keys used for authentication and
the aim of the standard, as well as briefly / or encryption should be changed regularly, this part
introducing the different chapters. It also provides also proposes mechanisms that allow to update the
general information on security, an enumeration of keys in a device remotely.
security threats (both inadvertent and deliberate,
e.g., equipment failures, cyber hackers, etc.), IEC 62351-6: Part 6 of the IEC 62351 standard
as well as a general overview of possible addresses security for protocols described in the re-
security countermeasures. The part also briefly lated standard IEC 61850 (International Electrotech-
describes concepts such as risk assessments, key nical Commission (IEC) (2010a)). For protocols
management and security processes, among other in IEC 61850 making use of TCP/IP and MMS,
things. the provisions described in IEC 62351-4 shall be
applied. Furthermore, this part proposes an exten-
IEC 62351-2: The second part of the IEC 62351 sion to the IEC 61850 GOOSE and SMV PDUs
standard is a glossary of terms, explaining terms (protocol data unit), adding a field to the PDU con-
such as Access Control, Data Security, etc. taining security-relevant information. The extension
is intended to authenticate a PDU by containing a
IEC 62351-3: The third part of IEC 62351 signed hash of the PDU. This part of the standard
addresses the security of protocols based on also adds extensions to the Substation Configura-
TCP/IP (Postel (1081a,b)) that are used for tion Language (SCL) (International Electrotechnical
automation systems in the electricity distribution Commission (IEC) (2010a)) that permit to include
domain. Specifically, it prescribes the use of certificate definitions in the configuration.
Transport Layer Security (TLS) (Dierks and Rescorla
(2008)) with X.509 certificates (Cooper et al. (2008)) IEC 62351-7: Power systems infrastructure makes
for TCP/IP-based protocols. The purpose is to heavy use of interconnected information systems
ensure authenticity and integrity of data on the to manage operations. This information systems
transport layer, and optionally also confidentiality by infrastructure also needs to be securely managed,
using the encryption mechanisms of TLS. The use which is done using the Simple Network Manage-
of TLS also counters threats such as man-in-the- ment Protocol (SNMP) (Case et al. (1990, 1996);
middle-attacks and replay attacks. This part of the Harrington et al. (2002)). Part 7 of the IEC 62351
standard also requires mutual authentication through standard describes the data object models to be
certificates (i.e., client and server each present a used that are specific to power systems.
certificate), and prescribes the algorithms and some
minimum key lengths to be used, as well as how to IEC 62351-8: Part 8 of the IEC 62351 standard
handle certificate revocation. defines system-wide role-based access control for
power systems infrastructure. It addresses different
IEC 62351-4: This part of the IEC 62351 standard modes of access, such as direct and remote
addresses security for profiles such as Manufactur- access, as well as access by human users and
ing Message Specification (MMS) (International Or- automated access by computer agents. To transport
ganization for Standardization (ISO) (2014)), which roles, this part proposes three different formats for
is used in other IEC standards (e.g., IEC 61850-8- access tokens, namely, X.509 ID certificates with
1 and IEC 60870-6). Specifically, the part provides extensions, X.509 attribute certificates and software
recommendations for the A-Profile as well as the

12
Assessing the Security of IEC 62351
Schlegel • Obermeier • Schneider

tokens. Furthermore, the standard defines certain Message Authentication Code or the related “HMAC”
mandatory rights and roles. (Hash-based Message Authentication Code).

IEC 62351-9: This part of the standard has not been Assessment. This part provides an extensive list of
released yet, but is intended to address certificate terms, together with a relatively detailed description
and / or key management. for each item.

IEC 62351-10: Part 10 of the IEC 62351 standard 3.3. IEC 62351-3: Profiles including TCP/IP
provides general guidelines for the security architec-
ture of power systems. This includes an overview Part 3 of the IEC 62351 standard is targeting power
of security controls that can be applied in power system automation protocols based on TCP/IP and
systems, as well as system architecture advice on aims to achieve the following security objectives:
how to structure the communication infrastructure of
power systems. • Message integrity protection, i.e., messages
cannot be modified or inserted. This counter-
In the next section we will evaluate the different acts the threat of a man-in-the-middle attack.
parts to determine to which extent they can address
• Confidentiality of messages (i.e., through
security issues in power systems.
encryption), although this is optional. This
counteracts the threat of eavesdropping.
3. ASSESSING IEC 62351
In addition, other mechanisms described in this part
3.1. IEC 62351-1: Introduction to Security also counteract the threat of replay attacks, where a
Issues message is intercepted by an attacker and replayed
at a later point in time.
The information contained in this part of the
standard provides an overview of security in power The key part of IEC 62351-3 is to use TLS (Transport
systems, listing the different threats to a system Layer Security, (Dierks and Rescorla (2008)) as the
and the corresponding security requirements that underlying protocol to provide end-to-end transport
can mitigate these threats. The enumeration is security for power system automation protocols,
quite complete, ranging from inadvertent threats together with X.509 certificates for the authentication
such as natural disasters to deliberate threats such of devices. Because of the different requirements
as disgruntled employees, industrial espionage and of OT (operational technology) compared to IT
hackers. The security requirements are also quite (information technology), the standard also provides
comprehensive, and the standard cross-references information on how to address these differences. For
them with the appropriate security countermeasures example:
(although not all countermeasures are part of
the actual standard). Also mentioned are activities Session Duration. In power systems, connections
such as risk assessments, or security policies, are often much more long-lived than in regular com-
as well as the challenges of security in power puter networks. The standard therefore describes
system operations, where availability is much more mechanisms how TLS connections should be rene-
important than for example confidentiality. gotiated in regular intervals (e.g., depending on
time or number of bytes transferred) to ensure the
Assessment. Overall, this section provides a freshness of sessions. Furthermore, renegotiation
comprehensive overview of the security issues that provides an opportunity to re-check certificates, in
are relevant in a power system. However, the case a certificate has been revoked in the meantime.
remaining parts of the standard do not address
all of the issues mentioned in this part, but focus Certificate Handling. The standard supports the
on the countermeasures that can realistically be use of multiple certificate authorities (CAs) in a
implemented in an evolutionary manner. single IED, using a TLS extension (Eastlake (2011)).
This can be useful where IEDs are accessed from
3.2. IEC 62351-2: Glossary of Terms different administrative domains. Also handled are
certificate revocation and certificate expiry.
The list of terms and abbreviations listed in this
part of the standard is quite extensive, providing a Cipher Suite. IEC 62351-3 does not provide a
short description of each term listed. The description concrete list of TLS cipher suites that need to be
is usually concise and accurate. The glossary is supported. Instead, it mandates the support of RSA
not entirely complete, there are some abbreviations and DSS as the signature algorithms, while ECDSA
or terms that are not contained, e.g., “MAC” for or ECGDSA are optional signature algorithms.
Furthermore, the use of RSA requires a key size of

13
Assessing the Security of IEC 62351
Schlegel • Obermeier • Schneider

2048 bit, with optional (albeit discouraged) support will also reduce the security provided by the
for 1024 bit keys. For key exchange, support for standard, although it is clear that backwards-
regular and ephemeral Diffie-Hellman key exchange compatibility is an important concern. However, this
are mandated, with a mandatory key length of compatibility will always have an impact on security.
2048 bit, and an optional, backwards-compatible key
length of 1024 bit. 3.4. IEC 62351-4: Profiles Including MMS

General Requirements Additional requirements Part 4 of the IEC 62351 standard describes mea-
foresee the co-existence of secure and insecure sures for securing MMS (Manufacturing Message
communication by having TLS connections run Specification, (International Organization for Stan-
through a different port of a device. An optional dardization (ISO) (2014)). The standard proposes
requirement is furthermore the use of certificate security for the A-Profile (i.e., application-level se-
pinning / whitelisting. curity) as well as for the TCP/IP-based T-Profile.
The T-Profile based on OSI (i.e., ISO TP4 and ISO
Assessment. The proposed use of TLS for power CLNP) is not covered by this standard. Depending
system automation protocols based on TCP/IP on whether encryption is used, the mechanisms
is a suitable choice that makes use of a well- described in this part will achieve different security
known and widely used protocol instead of trying to goals. If no encryption is used, only unauthorized ac-
implement proprietary security protocols. However, cess to information is prevented. If encryption is used
the standard leaves the selection of acceptable (i.e., IEC 62351-3 is employed), then authentication,
cipher suites for TLS to other standards, risking integrity and confidentiality can be achieved.
incompatible implementations and the use of cipher
suites that do not offer sufficient security (e.g., A-Profile Security. Security for the A-Profile (the
cipher suites using RC4, AlFardan et al. (2013)). application level) is achieved through certificate-
Furthermore, the standard allows the use of NULL based peer entity authentication during association
ciphers, e.g., TLS RSA WITH NULL SHA1 , within setup. Specifically, a device will include an X.509
an administrative domain, i.e., ciphers that do not certificate, together with a timestamp and a signature
use encryption, although integrity and authenticity on the timestamp using the given certificate in the
is still guaranteed. However, it can be argued that association request. A receiving device will verify the
there are benefits of using encryption even within timestamp, and accept it, if the timestamp does not
an administrative domain. If an attacker gets access differ by more than 10 minutes from the local time. In
to the local network, the use of encryption between addition, a device will not accept a message with a
devices in the local network will make it more difficult timestamp that has already been seen within the last
for the attacker to collect further information and 10 minutes.
continue his attack.
T-Profile Security. For TCP T-Profiles, the standard
One attack that IEC 62351-3 does not defend recommends the use of TLS between TCP and RFC
against are IEDs that have been compromised by 1006 (ISO Transport Service on top of TCP, Rose
an attacker, as the compromised IEDs will still and Cass (1987)) on a separate port (3782). The
be recognized as legitimate by other devices in standard also recommends a list of cipher suites
the system. The use of TLS and certificates, can, for TLS, with one mandatory cipher prescribed
however, defend against the introduction of rogue (TLS DH DSS WITH AES 256 SHA).2 However,
devices within a power system, as such a rogue TLS cannot be used for the T-Profile based on the
device would not have access to a valid X.509 OSI stack, as TCP is not part of the network stack.
certificate required for the secure communication IEC 62351-4 therefore considers the T-Profile based
with other devices. on OSI as out of scope.

An additional issue with IEC 62351-3 for secure Assessment. The main issue of IEC 62351-4
communication within power systems that needs security for the A-Profile is that it does not cover
to be kept in mind is that backwards compatibility message integrity or confidentiality. It only covers
could be used by attackers to circumvent certain the initial authentication, but the authentication does
security features. If an IED offers both secure and not extend to the subsequent messages within the
insecure communication, an attacker could choose session. Furthermore, the authentication only covers
to make use of the insecure communication channel a timestamp included in the initial message, and
to get around authentication requirements. Likewise, the timestamp only has to be accurate to within
offering backwards-compatibility (e.g., 1024 bit keys) 2 While the text of the IEC 62351-4 standard mentions TLS DH -
DSS WITH AES 256 SHA, a table of cipher suite combinations
1 This
seems to be mistakenly designated as TLS RSA NULL - within the same document mentions TLS DH WITH AES 256 -
WITH NULL SHA in the IEC 62351-3 standards document. SHA (i.e., without a signing algorithm). Presumably, TLS DH -
DSS WITH AES 256 SHA is the correct cipher suite designation.

14
Assessing the Security of IEC 62351
Schlegel • Obermeier • Schneider

10 minutes of the local clock of a device. This leaves make use of SHA-1, which has shown signifi-
the A-Profile open to at least three different attacks: cant weaknesses, affording less than 80 bits of
security (Stevens (2013)).
• an initial PDU can be modified (except the
timestamp) without invalidating the signature 3.5. IEC 62351-5: Security for IEC 60870-5 and
Derivatives
• the timestamp and authentication value can be
extracted from a PDU and re-used in a forged The core of this part of the standard is a challenge-
PDU to a different device within 10 minutes of response authentication mechanism using HMAC
the original PDU being sent with pre-shared secret keys for integrity protection
of data. Messages (ASDUs) that are critical can
• because intermediate messages are not be protected by a challenge-response authentication
authenticated or protected, after the initial mechanism, where the sending station has to reply
authentication, an attacker can forge or modify to a challenge sent by the receiving station before
PDUs exchanged between two devices processing the ASDU. Alternatively, the sending
device can anticipate the challenge and include a
Therefore, unless transport-level security (i.e., TLS
response with the initial ASDU to eliminate one
for the T-Profile) is also used, the security provided
round-trip of data. There are also provisions for
by A-Profile security mechanism is minimal, as it
updating keys remotely, using both symmetric or
can neither guarantee integrity of messages, nor the
asymmetric keys.
authenticity of any intermediate messages.
Assessment. The algorithms described in
Regarding the T-Profile security, the mandatory
IEC 62351-5 address authentication and the
cipher defined in the standard does not use
integrity of critical messages, although they do not
ephemeral Diffie-Hellman (* DHE * or * EDH *),
provide any confidentiality of messages (except key
but only uses regular Diffie-Hellman (* DH *), and
update messages). A detailed security analysis of
hence does not support perfect forward secrecy
all the mechanisms described in IEC 62351-5 is
(PFS). If perfect forward secrecy is a concern,
out of the scope of this paper, but the described
then the standard should also prescribe cipher
mechanisms seem to achieve the stated goals.
suites that support PFS. Among the optional cipher
suites are also combinations that include RC4, However, there appears to be some potential for
the use of which has been discouraged (i.e., Denial-of-Service (DoS) attacks, as a device can be
see RFC 7465, Popov (2015), based on results tricked into taking certain actions (e.g., invalidating
by AlFardan et al. (2013)), and 3DES, which has session keys) if an attacker sends invalid messages.
been estimated to be only secure until approximately The state space of all possible interactions between
2030 by the National Institute of Standards and devices (e.g., remotely updating keys, keeping track
Technology (NIST) (2007). The standard also of counters, etc.) appears sufficiently large that
does not include recommendations for any cipher there might be some concerns for a system to
suites making use of elliptic curves, for example reach a “dead-end” state, for example, a state
for the key exchange (i.e., ephemeral elliptic curve where controlling and controlled device are de-
Diffie-Hellman). Cipher suites that support PFS synchronized such that no mutually agreed keys
using elliptic curve Diffie-Hellman instead of regular can be established anymore. However, a conclusive
Diffie-Hellman are considerably faster, and only evaluation of the possible state-space is outside of
slightly more expensive than cipher suites without the scope of this paper.
PFS (Vincent Bernat (2011)).
There are also some constraints on choosing the
Furthermore, the same caveats apply for IEC 62351- initialization vector (IV) for the AES-GMAC message
4 as for IEC 62351-3, namely that systems will still authentication code, and ensuring that these are met
support both secure and insecure communication might not be trivial.
(e.g., through different ports for the T-Profiles using
TCP/IP), allowing an attacker to gain access by 3.6. IEC 62351-6: Security for IEC 61850
accessing the insecure mode. In addition, having the
option of disabling TLS is also explicitly permitted by Part 6 of the IEC 62351 standard defines
the standard. security for protocols in IEC 61850 International
Electrotechnical Commission (IEC) (2010a)),
Other concerns are that IEC 62351-4 permits such as GOOSE (Generic Object Oriented
1024 bit RSA keys, which can no longer be Substation Events) and SV (Sampled Values).
considered secure (Lenstra (2004)). All cipher Some applications within IEC 61850 require
suites recommended in the IEC 62351-4 also response times of 4 ms, and IEC 62351-6 does
not recommend encryption for these applications,

15
Assessing the Security of IEC 62351
Schlegel • Obermeier • Schneider

as the cryptographic overhead might already incur These considerations are mostly localized, but it
delays of more than 4 ms. The standard does is all part of larger communication and information
include recommendations for confidentiality in case infrastructure of a power system operator that
of relaxed real-time requirements (i.e., more than needs to be monitored. Part 7 therefore defines
4 ms). For installations using IEC 61850 over MMS, network and system management (NSM) data
the use of IEC 62351-4 is recommended to provide objects that can be used together with the simple
security. For installations using IEC 61850 with VLAN network management protocol (SNMP) to monitor
technologies, IEC 62351-6 provides an extension to and configure such an infrastructure. The scope is
the GOOSE and SV PDUs, adding an RSA-based to monitor and control not only the communication
signature to ensure the integrity of the PDU.3 networks, but also end devices (e.g., IEDs, RTUs,
gateways, data concentrators, etc.).
IEC 62351-6 also defines how to extend the
substation configuration language (SCL) to add Assessment. The impact of this part of the standard
information about certificates to the configuration is mostly to provide a common framework to allow
of a substation, so that separate certificates for for managing and controlling a communication and
GOOSE and SV can be defined. information infrastructure as found in power systems.
The list of possible objects is quite complete,
Assessment. The proposed extensions in covering a wide range from alarms, to status data,
IEC 62351-6 address some of the threats, for to measurements, etc.
example the integrity of messages, and some
protection against replay of messages. For MMS The standard does not define how these objects
messages making use of IEC 62351-4 with TLS, are mapped to an underlying protocol (e.g., SNMP),
authentication, confidentiality and integrity can leaving this to other standards. It also does not
be achieved. For protocols like GOOSE or SV, define in detail how access to these objects should
the extended PDU containing a signature should be controlled.
guarantee authenticity and integrity. No provisions
are foreseen for traffic that requires a 4 ms response 3.8. IEC 62351-8: Role-based Access Control
time.
Part 8 of the IEC 62351 standard defines the
The standard suggests the use of RSA signatures use of role-based access control (RBAC) in power
for providing authenticity and integrity of extended systems. This is not a new concept, it is in fact
PDUs, which makes it unsuitable for applications part of best practices in many IT systems. The
where a 4 ms response time is required, as RSA use of RBAC in power systems makes it possible
signatures are relatively expensive in terms of to reduce the number of permissions that have to
computation power required. An HMAC (hash-based be assigned to certain users such that they only
message authentication code) on the other hand have the permissions they need to perform their
can be implemented in hardware, requiring only duties. This reduces the risk to the power system
around 10µs for generating an HMAC for a typical IP as permissions are only assigned when they are
packet (Deepakumara et al. (2003)) in 2003. This is actually needed, according to the principle of least
likely to have improved significantly nowadays. Even privileges. The standard also defines a list of pre-
in software the calculation of an HMAC takes only defined roles (e.g., VIEWER, OPERATOR, etc.),
around 30µs, which should be short enough to still and of pre-defined rights (e.g., View, Read, Control,
allow a 4 ms overall response time. etc.). In addition, the standard also defines two
different models (i.e., push and pull) for authorization
The standard also does not define any details about mechanisms, and provides more information on how
the certificates related to the RSA keys used for to handle sessions.
signing extended PDUs.
Assessment. While the role-based access aspects
3.7. IEC 62351-7: Network and System of this part are similar to current best-practices
Management (NSM) Data Object Models in IT systems, some of the choices for the
access token profiles are unusual. In particular,
Parts 3 to 6 of the IEC 62351 standard try to address X.509 attribute certificates do not seem to be
the security of communications and applications widely used nowadays, and are an unnecessarily
within a substation and also between substations. complex choice for a token, potentially requiring an
3 The standard refers to this mechanism as a MAC (message additional and separate certificate hierarchy. Even
authentication code). However, in cryptography, MAC has a using X.509 ID certificates for carrying authorization
specific meaning that is different from the mechanism described information is not an obvious choice, as any
in this standard, i.e., a MAC combines hashing with a secret key,
which is different from the signature-based mechanism described
changes in role affiliation require issuing a new
in the standard. certificate, making it quite inflexible. Because issuing

16
Assessing the Security of IEC 62351
Schlegel • Obermeier • Schneider

certificates is typically an expensive operation 4. RELATED WORK


(in terms of management overhead), certificates are
better suited for providing authentication of subjects, There are a number of standards for security in
with a relatively long life-time of such certificates. industrial automation systems apart from IEC 62351.
Authorization information should then be carried in There is the ISA/IEC 62443 (The International
software tokens to allow for flexibility in assigning and Society of Automation (ISA) / International Elec-
changing roles. trotechnical Commission (IEC) (2014)) standard
(formerly ISA-99) concerned with security for in-
Part 8 also seems to define its own protocol for dustrial automation and control systems. This stan-
secure session establishment. This is in general not dard seems to be more broadly applicable than
recommended, as devising cryptographic protocols IEC 62351, which focuses on power systems. In
that are correct is extremely hard. Instead, peer- addition, ISA/IEC 62443 concerns itself more with
reviewed and well-tested algorithms should be used. procedures and management of security in ICS, and
less with the actual technical implementation details.
3.9. IEC 62351-9: Certificate Management IEC 62351 on the other hand describes detailed and
specific changes to protocols to improve security.
This part of the standard has not been published yet, Also a rather broad standard is NIST SP 800-82
but is expected to handle certificate management (Stouffer et al. (2011)), which targets automation
for the certificates needed in the other parts of this systems in general. Another standard that is relevant
standard. for the energy domain is NERC CIP (North American
Electric Reliability Corporation (2015)), although it
Assessment. As IEC 62351-9 has not been
focuses rather on the operators of power systems,
published yet at the time of writing this article, no
instead of on the engineering companies.
assessment can be made.
In terms of research papers related to IEC 62351,
3.10. IEC 62351-10: Security Architecture
there are some papers examining IEC 62351 or
Guidelines
aspects of it. The paper by Fuloria et al. (2010)
Part 10 of the IEC 62351 standard provides examines in particular part 6 of the standard, which
general guidance on power systems architecture deals with security for IEC 61850. In the paper, they
with respect to security. It enumerates possible examine the impact of using RSA-based signatures
security controls (e.g., access control, firewalls, but for authenticating PDUs within IEC 61850. Their
also processes like incident response, etc.), and conclusion is that even hardware-based solutions will
contains information on how to determine which not be sufficiently fast to achieve 4 ms response time
security controls should be used. Furthermore, it for reasonable RSA key sizes. They also show that
illustrates the differences between security for power elliptic curve cryptography achieves lower response
systems and regular IT security. It also provides times (e.g., below 1 ms), but it is not yet widely
several specific example architectures (e.g., an used in substation automation. In summary, the
advanced metering infrastructure, or a substation paper makes some valid points about IEC 62351-
automation system), with advice on the appropriate 6, but does not really go into the other parts of the
security controls that should be used to secure a standard.
system.
Two other papers examining IEC 62351 are papers
Assessment. This part of the standard gives a by Fries et al. (2010, 2011). Fries et al.
comprehensive overview over how the different (2010) investigates IEC 62351 in the context of
standards address security in power and automation smart grid environments, and gives an overview of
systems at different levels. There is also a the standard as it existed in 2010. In particular, it
detailed overview of possible security controls examines part 4 of the standard, and how it applies
ranging from the technological security controls to situations where connections are established over
(e.g., authentication, access control, firewalls, etc.) multiple hops. It also provides suggestions on how
to the procedural (e.g., incident response, coding to improve the standard to allow for application-level
guidelines, etc.), as well as regulatory and physical end-to-end encryption using different technologies
security controls. Together with the concrete (e.g., H.235, XML security, etc.). Fries et al.
architecture examples, this part of the standard (2011) examines similar situations, focusing on end-
provides detailed and applicable information on the to-end security in new use-cases. However, both
security of power and automation systems. papers only focus on specific parts of IEC 62351,
and do not give an overall assessment of IEC 62351.

17
Assessing the Security of IEC 62351
Schlegel • Obermeier • Schneider

5. CONCLUSIONS Dierks, T. and Rescorla, E., (2008, Aug.). The


transport layer security (TLS) protocol version 1.2.
The IEC 62351 standard addresses security con- RFC 5246 (proposed standard). Updated by RFCs
cerns in power systems, providing in part authen- 5746, 5878, 6176, 7465.
tication, integrity and confidentiality of data. The
standard proposes both standardized technologies Eastlake, D., (2011, Jan.) Transport layer Security
(e.g., TLS), and proprietary extensions to industrial (TLS) Extensions: Extension Definitions. RFC
protocols. 6066 (Proposed Standard).

The standard contains some inaccuracies (e.g., Fries, S., Hof, H., and Seewald, M., (2010, May)
cipher suite designations), and unconventional Enhancing IEC 62351 to Improve security for
choices (e.g., RSA signatures for IEC 61850). It also energy automation in smart grid environments. In:
does not consider newer cryptographic algorithms Fifth International Conference Internet and Web
that could provide the same security guarantees Applications and Services (ICIW), 135–142.
at a lower performance cost (e.g., elliptic curve Fries, S. et al. (2011, Apr.) Security for the smart
cryptography). grid - enhancing IEC 62351 to improve security in
energy automation control. Int. J. Adv. Security, 3,
Nevertheless, the standard does provide a signifi-
169–183.
cant improvement in security, providing authenticity,
integrity and at times confidentiality of data. How- Fuloria, S. et al. (2010) The protection of substation
ever, it is clear that the standard is to some extent communications. In: Proceedings of SCADA
constrained by requirements related to backwards- Security Scientific Symposium.
compatibility, and hence does not always provide as
much security as could be provided if backwards- Guthrie, P. and Konaris, T. (2012). Infrastructure and
compatibility was sacrificed. Overall, the standard resilience. Government Office for Science. Tech.
provides a balanced approach that can be imple- Rep.
mented with reasonable effort and that provides a
Harrington, D., Presuhn, R., and Wijnen, B.
reasonable amount of security if implemented com-
(2002, Dec.) An architecture for describing
prehensively.
simple network management protocol (SNMP)
management frameworks. RFC 3411 (INTERNET
REFERENCES STANDARD). Updated by RFCs 5343, 5590.

AlFardan, N. et al. (2013) On the security of IEEE Standards Association 1815-2012 (2012) -
RC4 in TLS. In: Presented as Part of the 22nd IEEE standard for electric power systems
USENIX Security Symposium (USENIX Security communications-distributed network protocol
13). Washington, D.C., 305–320. (DNP3). Available from http://standards.ieee.org/
findstds/standard/1815-2012.html
Anderson, R. and Fuloria, S. (2010) security
Economics and critical national infrastructure. In: International Electrotechnical Commission IEC
Economics of Information Security and Privacy. 61850 (2010a)Power utility automation. Available
T. Moore, D. Pym, and C. Ioannidis, Eds. Berlin, from http://www.iec.ch/smartgrid/standards/
Germany: Springer. 55–66. International Electrotechnical Commission
Case, J. et al. (1990, May) Simple network manage- IEC 62351 (2010b) Security. Availbale from
ment protocol (SNMP). RFC 1157 (Historic). http://www.iec.ch/smartgrid/standards/

Case, J. et al. (1996, Jan.) Introduction to International Organization for Standardization ISO
community-based SNMPv2. RFC 1901 (Historic). 9506 (2014) Industrial automation systems -
manufacturing message specification. Available
Cooper, D. et al. (2008, May) Internet X.509 from http://www.iso.org/iso/catalogue detail. htm?
public key infrastructure certificate and certificate csnumber=37079
revocation list (CRL) profile. RFC 5280 (Proposed
Standard). Updated by RFC 6818. Lenstra, A. K. (2004) Key length. In: Contribution to
The Handbook of Information Security.
Deepakumara, J., Heys, H. M., and Venkatesan,
R., (2003). Performance comparison of message Miller, B. and Rowe D. (2012). A survey of
authentication code (MAC) algorithms for Internet SCADA and critical infrastructure incidents. In:
protocol security (IPSEC). In: Proc. Newfoundland Proceedings of the 1st Annual Conference on
Electrical and Computer Engineering Conf. Research in Information Technology, RIIT ’12. New
York, NY, USA, 51–56.

18
Assessing the Security of IEC 62351
Schlegel • Obermeier • Schneider

National Institute of Standards and Technology Stevens, M. (2013). New collision attacks on SHA-
(NIST) (2007, Mar.) Recommendation for key 1 based on optimal joint local-collision analysis.
management - Part 1: general (revised). Available In:Advances in Cryptology–EUROCRYPT. New
from http://csrc.nist.gov/publications/nistpubs/ York: Springer, 245–261.
800-57/sp800-57-Part1-revised2 Mar08-2007.pdf
Stouffer, K. A., Falco, J. A., and Scarfone, K. A.
CIP (Critical Infrastructure Protection) Standards (2011) SP 800-82. Guide to Industrial control sys-
(2015) North American Electric Reliability Cor- tems (ICS) security: Supervisory control and data
poration Available from http://www.nerc.com/pa/ acquisition (SCADA) systems, distributed control
Stand/Pages/CIPStandards.aspx systems (DCS), and other control system config-
urations such as programmable logic controllers
Popov, A. (2015, Feb.) Prohibiting RC4 cipher suites. (PLC). Gaithersburg, MD, USA. Tech. Rep.
RFC 7465 (Proposed Standard).
ISA/IEC 62443 (2014) The International Soci-
Postel, J. (1981a, Sept.) Internet protocol. RFC ety of Automation (ISA) / International Elec-
791 (INTERNET STANDARD). Updated by RFCs trotechnical Commission (IEC). Available from
1349, 2474, 6864. http://isa99.isa.org/ISA99%20Wiki/Home.aspx
Postel, J. (1981b, Sept.) Transmission control Bernat, V. (2011) SSL/TLS & perfect forward
protocol. RFC 793 (INTERNET STANDARD). secrecy. Available from http://vincent.bernat.im/
Updated by RFCs 1122, 3168, 6093, 6528. en/blog/2011-ssl-perfect-forward-secrecy.html
Rose, M. and Cass, D. (1987, May) ISO transport
service on top of the TCP version: 3. RFC 1006
(INTERNET STANDARD). Updated by RFC 2126.

19

You might also like