Main IEC
Main IEC
Main IEC
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.
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
17
Assessing the Security of IEC 62351
Schlegel • Obermeier • Schneider
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