IEC TR 62351-13:2016

Power systems management and associated information exchange - Data and communications security - Part 13: Guidelines on security topics to be covered in standards and specifications

IEC TR 62351-13:2016(E) provides guidelines on what security topics could or should be covered in standards and specifications (IEC or otherwise) that are to be used in the power industry, and the audience is therefore the developers of standards and specifications. These guidelines cannot be prescriptive for every standard, since individual standards and specifications may legitimately have very different focuses, but it should be expected that the combination of such standards and specifications used in any implementation should cover these security topics. These guidelines are therefore to be used as a checklist for the combination of standards and specifications used in implementations of systems.

General Information

• Status: Published
• Publication Date: 08-Aug-2016
• ICS: 33.200 - Telecontrol. Telemetering
• Technical Committee: TC 57 - Power systems management and associated information exchange
• Drafting Committee: WG 15 - TC 57/WG 15
• Current Stage: PPUB - Publication issued
• Start Date: 09-Aug-2016
• Completion Date: 15-Oct-2016

Standards Content (Sample)

IEC TR 62351-13 ®
Edition 1.0 2016-08
TECHNICAL
REPORT
colour
inside
Power systems management and associated information exchange – Data and
communications security –
Part 13: Guidelines on security topics to be covered in standards and
specifications
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form
or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from
either IEC or IEC's member National Committee in the country of the requester. If you have any questions about IEC
copyright or have an enquiry about obtaining additional rights to this publication, please contact the address below or
your local IEC member National Committee for further information.

IEC Central Office Tel.: [phone]
3, rue de Varembé Fax: [phone]
CH-1211 Geneva 20 [e-mail]
Switzerland www.iec.ch
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.

About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigenda or an amendment might have been published.

IEC Catalogue - webstore.iec.ch/catalogue Electropedia - www.electropedia.org
The stand-alone application for consulting the entire The world's leading online dictionary of electronic and
bibliographical information on IEC International Standards, electrical terms containing 20 000 terms and definitions in
Technical Specifications, Technical Reports and other English and French, with equivalent terms in 15 additional
documents. Available for PC, Mac OS, Android Tablets and languages. Also known as the International Electrotechnical
iPad. Vocabulary (IEV) online.

IEC publications search - www.iec.ch/searchpub IEC Glossary - std.iec.ch/glossary
The advanced search enables to find IEC publications by a 65 000 electrotechnical terminology entries in English and
variety of criteria (reference number, text, technical French extracted from the Terms and Definitions clause of
committee,…). It also gives information on projects, replaced IEC publications issued since 2002. Some entries have been
and withdrawn publications. collected from earlier publications of IEC TC 37, 77, 86 and

CISPR.
IEC Just Published - webstore.iec.ch/justpublished
Stay up to date on all new IEC publications. Just Published IEC Customer Service Centre - webstore.iec.ch/csc
details all new publications released. Available online and If you wish to give us your feedback on this publication or
also once a month by email. need further assistance, please contact the Customer Service
Centre: [e-mail].
IEC TR 62351-13 ®
Edition 1.0 2016-08
TECHNICAL
REPORT
colour
inside
Power systems management and associated information exchange – Data and

communications security –
Part 13: Guidelines on security topics to be covered in standards and

specifications
INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
ICS 33.200 ISBN 978-2-8322-3571-3

– 2 – IEC TR 62351-13:2016 © IEC 2016
CONTENTS
FOREWORD . 4
INTRODUCTION . 6
1 Scope . 8
2 Normative references. 8
3 Terms and definitions . 8
4 Abbreviated terms and acronyms . 9
5 Security requirements for users and applications interacting with automation
systems . 9
5.1 Risk assessment, security policies and security requirements . 9
5.2 User-focused cybersecurity procedures and techniques . 12
6 Information and communication technology (ICT) cryptographic techniques . 14
6.1 General . 14
6.2 Best practices for specifying cryptography . 14
6.3 Cryptographic methods . 15
6.4 Internet cryptography . 15
6.5 Wireless cryptography . 16
6.6 Key management using public key cryptography . 16
6.7 Multicast and group keys . 17
6.8 Device and platform integrity . 18
6.9 Design secure network configurations . 18
6.10 Network and system management (NSM) . 18
6.11 Defence-in-depth . 18
6.12 Security testing and validation procedures . 19
6.13 Security interoperability . 19
6.14 Additional cybersecurity techniques . 19
7 Engineering design and configuration management for grid resilience . 20
7.1 Intertwining of cyber security and engineering to provide grid resilience . 20
7.2 Security planning . 20
7.3 Engineering strategies for security . 21
7.4 System engineering practices and configurations . 21
7.5 Power system equipment monitoring, analysis, and control . 22
7.6 Centralized monitoring and control . 22
7.7 Centralized power system analysis and control . 23
7.8 Testing . 23
7.9 Training . 24
8 Correlation of cyber security with information exchange standards . 24
8.1 Concepts for correlating cyber security with information exchange standards . 24
8.2 Security for different OSI reference model layers . 27
8.3 Interrelationships between the IEC 62351 security standards and IEC
communication standards . 28
Bibliography . 29

Figure 1 – Security requirements, threats, and possible attacks . 7
Figure 2 – Focus of different security standards and guidelines . 10
Figure 3 – General security process – Continuous cycle . 20

Figure 4 – ISO/OSI 7-Layer reference model and GWAC Stack reference model . 25
Figure 5 – Core Smart Grid standards for utilities . 26
Figure 6 – Customer-focused Smart Grid standards . 26
Figure 7 – Interrelationships between the IEC 62351 security standards and certain
IEC communication standards . 28

– 4 – IEC TR 62351-13:2016 © IEC 2016
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
POWER SYSTEMS MANAGEMENT AND
ASSOCIATED INFORMATION EXCHANGE –
DATA AND COMMUNICATIONS SECURITY –

Part 13: Guidelines on security topics to be covered
in standards and specifications

FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote
international co-operation on all questions concerning standardization in the electrical and electronic fields. To
this end and in addition to other activities, IEC publishes International Standards, Technical Specifications,
Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC
Publication(s)”). Their preparation is entrusted to technical committees; any IEC National Committee interested
in the subject dealt with may participate in this preparatory work. International, governmental and non-
governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely
with the International Organization for Standardization (ISO) in accordance with conditions determined by
agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence
between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in
the latter.
5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity
assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any
services carried out by independent certification bodies.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of
patent rights. IEC shall not be held responsible for identifying any or all such patent rights.
The main task of IEC technical committees is to prepare International Standards. However, a
technical committee may propose the publication of a Technical Report when it has collected
data of a different kind from that which is normally published as an International Standard, for
example "state of the art".
IEC TR 62351-13, which is a Technical Report, has been prepared by IEC technical
committee 57: Power systems management and associated information exchange.

The text of this Technical Report is based on the following documents:
Enquiry draft Report on voting
57/1678/DTR 57/1727/RVC
Full information on the voting for the approval of this Technical Report can be found in the
report on voting indicated in the above table.
This publication has been drafted in accordance with the ISO/IEC Directives, Part 2.
A list of all parts in the IEC 62351 series, published under the general title Power systems
management and associated information exchange – Data and communications security, can
be found on the IEC website.
The committee has decided that the contents of this publication will remain unchanged until
the stability date indicated on the IEC website under "http://webstore.iec.ch" in the data
related to the specific publication. At this date, the publication will be
• reconfirmed,
• withdrawn,
• replaced by a revised edition, or
• amended.
A bilingual version of this publication may be issued at a later date.

IMPORTANT – The 'colour inside' logo on the cover page of this publication indicates
that it contains colours which are considered to be useful for the correct
understanding of its contents. Users should therefore print this document using a
colour printer.
– 6 – IEC TR 62351-13:2016 © IEC 2016
INTRODUCTION
This document provides guidelines on what security topics should be covered in standards
and specifications (IEC or otherwise) that are to be used in the power industry. These
guidelines cannot be prescriptive for every standard, since individual standards and
specifications may legitimately have very different focuses, but it should be expected that the
combination of such standards and specifications used in any implementation should cover
these security topics. These guidelines could therefore be used as a checklist for the
combination of standards and specifications used in implementations of systems.
The security requirements for human users and software applications are different from the
purely technical security requirements found in many communication and device standards.
For user security standards, more emphasis should be on “policy and procedures” and “roles
and authorization” rather than “bits and bytes” cryptographic technologies that should be
included in Information and Communications Technology (ICT). In addition, engineering
practices and system configurations should be taken into account, since no cryptography can
compensate for poor design.
Figure 1 illustrates the relationships between security requirements, threats, and attacks.
This document is structured into four sections:
• Clause 5: Security requirements for standards and specifications which do not address
specific cybersecurity technologies but where interactions between human users, software
applications, and smart devices should be secured.
• Clause 6: Security requirements for standards and specifications that address information
and communication technologies (ICT).
• Clause 7: Engineering design and configuration requirements that provide system
reliability, defence in depth, and other security threat mitigations.
• Clause 8: Security requirements related to the OSI reference model.

Cybersecurity requirements, threats, and attacks
Requirements
Integrity Availability Accountability
Confidentiality
Denial of service or Denial that action took place or
Unauthorized access to Unauthorized modification or
prevention of authorized claim of action that did not take
information theft of information
access place
Listening
Interactions
Planted in system
Eavesdropping
Masquerade
Virus/Worms
Traffic analysis
Bypassing
Trojan horse
controls
After the fact
EM/RF
Trapdoor
interception Authorization
Stolen/Altered
violation
Service spoofing
Indiscretions
by personnel Repudiation
Physical
intrusion
Media
scavenging
Man in the middle
Denial of service
Integrity violation Resource
Modification
exhaustion
Theft
Intercept/Alter
Integrity violation
Replay
Repudiation
IEC
Figure 1 – Security requirements, threats, and possible attacks

AttacksAttacks ThreatsThreats
– 8 – IEC TR 62351-13:2016 © IEC 2016
POWER SYSTEMS MANAGEMENT AND
ASSOCIATED INFORMATION EXCHANGE –
DATA AND COMMUNICATIONS SECURITY –

Part 13: Guidelines on security topics to be covered
in standards and specifications

1 Scope
This part of IEC 62351, which is a Technical Report, provides guidelines on what security
topics could or should be covered in standards and specifications (IEC or otherwise) that are
to be used in the power industry, and the audience is therefore the developers of standards
and specifications.
These guidelines cannot be prescriptive for every standard, since individual standards and
specifications may legitimately have very different focuses, but it should be expected that the
combination of such standards and specifications used in any implementation should cover
these security topics. These guidelines are therefore to be used as a checklist for the
combination of standards and specifications used in implementations of systems.
Out-of-scope are explicit methods for cyber security in product development, implementations,
or operations.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their
content constitutes requirements of this document. For dated references, only the edition
cited applies. For undated references, the latest edition of the referenced document (including
any amendments) applies.
IEC TS 62351-2, Power systems management and associated information exchange – Data
and communications security – Part 2: Glossary of terms
3 Terms and definitions
For the purposes of this document, the terms and definitions given in IEC TS 62351-2 and the
following apply.
ISO and IEC maintain terminological databases for use in standardization at the following
addresses:
• IEC Electropedia: available at http://www.electropedia.org/
• ISO Online browsing platform: available at http://www.iso.org/obp
3.1
end-to-end security
reliance on security policies, procedures, and technologies which guarantees secure data
exchange between a source (sender) and a sink (receiver), preventing third-parties from
unauthorized access and/or modifications of these data while transferred from one end to the
other through multiple devices

4 Abbreviated terms and acronyms
Acronym Definition
NISTIR National Institute of Standards and Technology Internal Report
NIST National Institute of Standards and Technology
NERC North American Electric Reliability Corporation
ISO International Standards Organization

5 Security requirements for users and applications interacting with automation
systems
5.1 Risk assessment, security policies and security requirements
The following general cyber security considerations should be covered in the standards and
specifications as appropriate.
• Do not re-invent security requirements if they can be found in well-established standards.
Instead, use normative references to standards as much as possible, with the selection of
alternatives or options normatively stated. Some high level security standards that focus
on the electric power industry (see Figure 2 ) include:
– ISO/IEC TR 27019: Information technology – Security techniques – Information
security management guidelines based on ISO/IEC 27002 for process control systems
specific to the energy industry
– IEC 62443 series based on ISA99 series: Industrial communication networks –
Network and system security
– ISA99 series: Security for Industrial Automation and Control Systems
– NISTIR 7628: Guidelines for Smart Grid Cyber Security
– NERC CIP 2-9: Critical Infrastructure Protection
– IEC TS 62351-1: Power systems management and associated information exchange –
Data and communications security Part 1: Communication network and system security
– Introduction to security issues
– IEC TR 62351-10: Power systems management and associated information exchange
– Data and communications security – Part 10: Security architecture guidelines
• Figure 2 shows the applicability and scope of each of the standards as follows:
– Guideline: The document provides guidelines and best practice for security
implementations. This may also comprise pre-requisites to be available for the
implementation.
– Requirement: The document contains generic requirements for products, solutions or
processes. No implementation specified.
– Realization: The document defines implementation of security measures (specific
realizations). Note, if distinction is possible, the level of detail of the document raises
from left to right side of the column.
– Vendor: Standard addresses technical aspects relevant for products or components.
– Integrator: Standard addresses integration aspects, which have implications on the
technical design, are relevant for vendor processes (require certain features to be
supported), or require product interoperability (e.g., protocol implementations).
______________
See Bibliography for a more complete list of standards that include cybersecurity aspects, and for security
assessments of some of those standards.

– 10 – IEC TR 62351-13:2016 © IEC 2016
– Operator: Standard addresses operational and/or procedural aspects, which are mainly
focused on the service realization and provisioning on an operator site.
• Any discussions or explanations that are used to help with understandings of security
issues should be clearly identified as informative.
• Use “shall” or “must” (only to be used to indicate constraints or obligations defined outside
of a document) for normative statements, and use “should”, “could”, or “may” for
informative statements.
• Preferably normative and informative information should be in separate clauses, although
simple introductory informative sentences are reasonable in a normative clause.

Design details
Focus: Power systems
ISO/IEC 15408 and ISO/IEC 18045
Focus: Information systems
Focus: Industrial automation
Technical
aspects
IEC 62443
IEC 62056
Details for Relevance
operations for products
IEEE 1686
IEEE C37.240
Governance and
NERC CIP 1-9
ISO/IEC 19790
NIST IR 7628
policy aspects
ISO/IEC TR 27019
ISO/IEC 27000
Products
Operations
Completeness
IEC
Figure 2 – Focus of different security standards and guidelines
• Start by identifying the major security threats and failure scenarios, including assessing
their likelihood and their possible impacts (risk assessment):
– Reference IEC TR 62351-12, Resilience and security recommendations for power
systems with distributed energy resources (DER) cyber-physical systems, which
describes security threats and their possible impacts, as well as providing
recommendations on how to mitigate these threats.
– Reference the SGIS Toolbox, NIST SP-800-30 Rev. 1, and other risk assessment
documents.
– Identify examples of security breaches and failure scenarios, and develop use cases
that illustrate the failures and can be used to identify the most likely threats, impacts,
and mitigations.
– Which threats have highest likelihood? Which threats have the most serious impacts?
Which threats may not be preventable but could be mitigated? How can successful
attacks be coped with? What audit logs are needed to record possible or successful
attacks?
– Taking into account the possible cost of countermeasures, which threats are the most
important to prevent, mitigate, cope with, and log?
IETF RFC 7252 CoAP
IETF RFC 6960 OCSP
IETF RFC 7030 EST
IETF GDOI Enhanced
IETF RFC 7030 EST
IETF Draft TLS v1.3
ISO 15118
IEC 62734
IEC 61850
IEC 62351
– The results of this step do not need to be included specifically in the standard, but may
be very useful during its development to solidify the security requirements and/or may
be included as informative.
• Require or recommend that security policies and procedures be developed for all users
covered in the standard (e.g. companies, vendors, implementers, employees, guests,
contractors, customers)
– NISTIR 7628 Volume 1, Chapter 3, Guidelines for Smart Grid Cybersecurity, provides
a very useful list of areas that could be covered (depending upon the scope of the
standard).
• Require or recommend that security maturity models be used by users to assess the
security requirements against the security options and alternatives in the standard.
Documents that can be used as checklists include:
– NISTIR 7628 Volume 1, Chapter 3, Guidelines for Smart Grid Cybersecurity
– IEC 62443-3-3, System security requirements and security levels
– IEC TR 62351-12, Resilience and security recommendations for power systems with
distributed energy resources (DER) cyber-physical systems
• State the major cyber security requirements – the first six typically but not exclusively rely
on cryptography and require key management methods, while availability may rely more
on engineering strategies and other non-cryptographic methods:
– Authentication of the systems, devices, and applications that are sending and receiving
data, is generally the most important security requirement.
– Authorization ensures that the requesting system has the right to view, receive, update,
create, and/or delete the data. This is usually provided by Role-Based Access Control
IEC
(RBAC).
– Non-repudiation ensures that some entity cannot deny having received or acted upon a
message.
– Accountability enhances non-repudiation by ensuring that all records of actions are
traceable to their authors and are kept securely.
– Data integrity of all interactions and of information within the systems, is also critical.
Data integrity of messages usually implies the need for authentication of the source of
the data, and the ability to detect tampering since it is not possible to prevent
messages from being destroyed or modified, but it is possible to detect these actions.
– Confidentiality is usually required for financial, market, corporate, or private data, but
is not usually necessary for normal power system operational data exchanges.
– Availability of the interactions can range from milliseconds to hours or days. Unlike the
other cyber security requirements, availability generally relies on engineering design,
configuration management, redundancy, functional analysis, communication network
analysis, and engineering practices.
• Require security to be end-to-end security, with reliance on security policies, procedures,
and technologies to ensure the secure exchange of information between two entities by
preventing unauthorized entities from accessing or interfering with the information in
transit.
– Different security solutions and implementations by different vendors need to be
interoperable. In particular, the interconnection of different security domains requires
the mutual agreement between the parties about their security policies. Common
minimum agreements on security policies will be required.
– Interconnection of security domains will also require the mutual agreement between
the parties about their security policies, with common minimum agreements on security
policies.
• Require security to use defence-in-depth techniques: the application of security controls in
layers and at different levels. “Layers” imply multiple security barriers between the
attacker and the target, while “levels” relate to the different levels in the communications
infrastructure underlying any cyber system (transport, application, etc.). This concept

– 12 – IEC TR 62351-13:2016 © IEC 2016
ensures that if one security barrier is broken (for instance the lock on a door), the next
layer may prevent the attack (the attacker does not have the correct password) or it may
just deter the attack until it is detected (such as video surveillance or an alarm notifies
personnel that an excess of passwords have been attempted).
• Ensure a chain of trust: ensure that the entire supply chain, particularly for critical
equipment and processes, are secured, from “birth” to “integration”, to “implementation”, to
“testing”, to “operation”, to “maintenance and upgrade”, and finally to “death”.
• Require security to be designed into the system from the beginning: security technologies
should be designed into systems from the beginning, rather than being added “on top” of
the system at a later date. Without such integrated security, the system will almost
invariably have security “holes”. See IEC 62443-4-1.
5.2 User-focused cybersecurity procedures and techniques
The following items should be covered in standards and specifications that address the high
level requirements, but do not need to get into cryptographic details.
• Validate and register the identity of users and devices:
– For authentication, trust should be established that the users are who they say they
are.
– Users need to be identified through the organization or group they belong to (company,
vendor, customer, guest, etc.).
– These organizations and groups should also establish their identities and be trusted by
the other stakeholders in transactions.
– Users provide passwords, biometric data, or other security mechanisms that tie the
users to their identity in the organization/group.
– Devices, usually when manufactured, should be provided with security certificates, pre-
established secret keys, or other security tokens for establishing their identity.
– All cryptographic keys and keying material, including certificates, should be chained
from the “birth” security tokens, and should be capable of being generated and
managed using the approved security policy of the organization.
– These identifications can be used assigning users and devices to “roles”.
• Establish the authorizations and privileges of each role in Role-Based Access Control
(RBAC) (reference IEC TS 62351-8):
– Each (human) user, software application, and device should be assigned to one or
more of the roles, thus acquiring the associated authorizations and privileges (read
data, issue commands, write data, modify data, delete data, execute applications) that
are assigned to those roles.
– Some roles ought to be mutually exclusive in order to ensure the separation of duties,
to eliminate conflicts of interest, and to ensure independence in the responsibilities.
– Users, applications, and devices may be assigned to multiple roles so long as they are
not mutually exclusive.
– RBAC privileges should be linked to the data wherever it is located, such as in a
device or a database.
• Require the authentication of all interactions between users and applications, and between
different applications, based on the trusted identities of these users and applications.
– Authentication of interactions can include the use of passwords, application tokens,
digital signatures, certificates, message authentication codes (MAC hashes), etc. All
authentication relies on cryptography (even passwords if they are transmitted between
systems) and thus necessitates key management (see 6.6). Public key infrastructure
(PKI) is the most commonly used for key management, but may not be applicable in all
situations.
– Avoid specifying cryptographic algorithms (such as RSA) if the standard is focused
only on user requirements, since there are many valid cryptographic methods.

However, there should be a reference to a cryptographic standard that does cover the
appropriate cryptographic technologies for these user requirements.
– Whenever possible and appropriate, reference existing standards, such as the
IEC 62351 series and the security-related IETF RFCs.
• Focus on the integrity of information:
– Integrity of information relies on cryptography, specifically message authentication
codes (MAC hashes) which use cryptographic keys to ensure that any tampering of
information can be detected (not prevented). Often integrity cryptography is combined
with authentication, such as with digital signatures with certificates. Integrity
cryptography (MAC) is also usually included in confidentiality which combines tamper
detection with encryption for prevention of eavesdropping.
– Key management is required for integrity.
– Data entry by users and software applications should be checked for validity as much
as possible, including reasonability of values, and where possible, cross-checked by
algorithms, visual displays, testing, or other mechanisms.
– Integrity of information should apply also for message exchanges, database access,
software patches, software updates, and configuration.
• Identify those interactions that require confidentiality:
– Confidentiality relies on encryption algorithms which use cryptographic keys to prevent
eavesdropping. Usually these encryption algorithms are combined with integrity
cryptography to ensure both confidentiality and integrity.
– Key management is required for confidentiality.
– These interactions usually involve corporate, financial, customer, and market
information.
– Privacy (personal information) can also be considered confidential, but may require
additional management if aggregations are used for planning or other functions.
– Avoid specifying cryptographic algorithms (such as RSA) if the standard is focused
only on user requirements, but ensure some standard does cover the appropriate
cryptographic technologies for all system designs.
• Determine availability requirements for all types of interactions:
– Availability is mostly affected by configuration design and management. Therefore,
normally key management is not necessary for availability.
– What timing latency is allowed for different types of interactions: milliseconds, seconds,
minutes, or even days?
– How closely monitored should that timing be? Issue an alarm? Log it? Ignore?
– What kind of redundancy (or other methods) should be used to improve this availability?
– What actions are required if those timing requirements are not met?
• Determine if non-repudiation and/or accountability are necessary for different types of
transactions:
– Event logs can capture the fact that a transaction was initiated, while a similar, time-
synchronized event log of the recipient of the transaction is necessary for non-
repudiation of that transaction.
– Authenticated responses to transactions can also provide non-repudiation records.
• Revoke user access and/or privileges when a user or an application’s role changes:
– Revoke access through RBAC and disable the user’s passwords.
– Ensure revocations are made available to all affected systems in a timely manner.
– For temporary assignment of users to roles, ensure that a deadline is associated with
that assignment and the user is revoked at the deadline.
• Deregister applications and revoke any certificates or tokens if an application is
decommissioned or its security is compromised:

– 14 – IEC TR 62351-13:2016 © IEC 2016
– Ensure revocations are made available to all affected systems in a timely manner,
usually within a day or so.
• Establish alarm and event logs content, accuracy of the timestamps, synchronicity of
timestamping, and security requirements:
– Log and timestamp all anomalous events.
– Ensure all alarms are assigned to one or more roles so that they will be viewable.
– For higher priority alarms, ensure that at least one user has logged on in one of the
assigned roles.
– Track user interactions with applications and systems, as appropriate.
– Synchronize the timestamps across all systems within the necessary accuracy
(milliseconds or seconds).
– Prevent or log all modifications to logs.
– Archive logs for appropriate lengths of time.
– Provide relevant logs to security personnel.
– Provide methods for correlating different types of events – sort/search.
6 Information and communication technology (ICT) cryptographic techniques
6.1 General
In standards and specifications that focus on specific Information and Communication
Technology (ICT) requirements such as communication protocols and interactions with
“intelligent” equipment, the following security requirements could be directly included or could
include normative references to other standards, as appropriate (this is just a checklist, so not
all standards or specifications should include all items).
6.2 Best practices for specifying cryptography
Some of the best practices for specifying cryptography used for confidentiality, authentication,
and/or digital signatures are as follows.
• Use normative references to cryptographic standards rather than describing the
cryptography (except for informative purposes). If there are alternatives or options within
the referenced standards, indicate which are mandatory, which are recommended, which
are optional, and which are not to be used.
• Cipher suites are always evolving, so specifying only one can be self-defeating over time.
However, one cipher suite can be mandated for interoperability, with other cipher suites
permitted and negotiated at startup.
• Because cipher suites get broken or “weaken” over time as computer speeds increase and
hacker capabilities improve, only cipher suites of “adequate strength” should be permitted.
Options for improved cipher suites over time should also be permitted.
• The permitted cryptographic algorithms should not be deprecated by leading security
organizations, such as NIST. NIST lists the deprecation dates of certain cryptographic
algorithms in NIST SP800-131A.
• Legacy equipment may be allowed to use deprecated cryptographic algorithms so long as
“mitigating” countermeasures are included. No new implementations should be permitted
to implement deprecated cryptographic algorithms.
• Key management and certificate management requirements should be included, either
directly or by normative reference.
• Implementation considerations include when “session” keys should be updated, how
certificate expirations should be handled (ignored? Warning? Stop interactions?), and how
certifications that have been revoked should be provided to affected systems.

6.3 Cryptographic methods
The following cryptography methods are commonly specified. Normative references should be
used in most cases to point to specific cryptographic requirements. More information on NIST
cryptographic toolkit can be found at http://csrc.nist.gov/groups/ST/toolkit/index.html.
• Cryptographic key pairs are secure because it is generally very difficult to derive one from
the other, even though they are mathematically linked so that if one key encrypts a
message, the other key can decrypt it.
– RSA (Ron Rivest, Adi Shamir and Leonard Adleman) uses the fact that it is difficult to
factor a large integer composed of two or more large prime factors.
– ECC (elliptic curve cryptography) uses the fact that finding the discrete logarithm of a
random elliptic curve element with respect to a publicly known base point is infeasible.
ECC keys are becoming more popular because they can be smaller in length while still
providing the same level of security as RSA keys.
• Encryption consists in combining a cryptographic key with a block of plain text using a
well-designed algorithm. The most common block cipher algorithm is the Advanced
Encryption Standard (AES), usually either AES-128 or AES-256 (the number being the
block length in bytes). NIST has identified AES as the preferred block cipher. Neither DES
nor Triple DES (3DES) should be specified anymore.
• Confidentiality (but not authentication) is provided by block cipher modes. Block ciphers
only encrypt one block, so block cipher modes are used to string together the encryption
of messages that are longer than one block while still using the same cryptographic key.
The most common block cipher modes are cipher-block chaining (CBC) mode and counter
(CTR) mode.
• Authentication and integrity may be provided by digital signatures and/or by “hashing”
messages with cryptographic keys. These methods do not provide confidentiality – the
messages can be read by anyone – but they do provide authentication of the sender and
the ability to determine if the message has been tampered with. They require less
“compute” processing than the block cipher modes.
– Digital signatures algorithms include RSA-based signature schemes, such as RSA-
PSS or RSA ANS X9.31, and DSA and its elliptic curve variant ECDSA, for example
ECDSA ANS X9.62.
– The cryptographic hashing methods or “codes” are called Message Authentication
Codes (MAC). To avoid some confusion with the term “Media Access Control (MAC)”,
they are sometimes called Message Integrity Codes (MIC). The most common MAC
algorithms include the Keyed-Hash Message Authentication Code (HMAC), CBC-MAC
(CMAC), and Galois/Counter Mode (GCM) and GMAC. These can be further specified
as to which hashing ciphers and block sizes to use, such as HMAC-SHA256 or AES-
GMAC-128.
– Combinations of confidentiality and authentication modes are called authenticated
encryption (AE). Examples of AE modes are CCM (NIST SP800-38C), GCM (NIST
SP800-38D), CWC, EAX, IAPM, and OCB.
– Certificates are issued by Certificate Authorities (CA) as a method for certifying the
validated identity of a device or software application – the equivalent to a birth
certificate or passport for a human. Most certificates use the ITU X.509 format for
public key certificates, which bind a public key to the certified device or application,
which contains (and guards) the corresponding secret key. Public Key Infrastructure
(PKI) is the most commonly used method.
6.4 Internet cryptography
Internet cryptography uses cryptographic profiles defined in RFCs by the IETF. The
predominant RFCs include the following.
• Transport Layer Security (TLS) was derived from Secure Sockets Layer (SSL) and
specifies asymmetric cryptography for authentication of key exchanges via the Public Key
Infrastructure (PKI), symmetric encryption for confidentiality, and message authentication

– 16 – IEC TR 62351-13:2016 © IEC 2016
codes for message integrity. As indicated by the name, TLS provides security for the
transport layer. Although the most commonly implemented version is still TLS 1.0, the
newest version TLS v 1.2, defined in RFC 5246, should be specified for new
implementations. TLS includes many alternative cipher suites – these could or s
...