IEEE C37240 2014 Substation Security

IEEE Standard Cybersecurity
Requirements for Substation

Automation, Protection,
and Control Systems
IEEE Power and Energy Society
Sponsored by the
Power System Relaying Committee
and the Substations Committee
IEEE
3 Park Avenue IEEE Std C37.240™-2014
New York, NY 10016-5997
USA
Authorized licensed use limited to: University of Illinois. Downloaded on January 25,2019 at 01:45:41 UTC from IEEE Xplore. Restrictions apply.
IEEE Std C37.240™-2014

and Control Systems
Sponsor
Power System Relaying Committee and Substations Committee

of the
IEEE Power and Energy Society
Approved 10 December 2014
IEEE-SA Standards Board
Abstract: Cybersecurity measures require that a balance be achieved between technical
feasibility and economic feasibility and that this balance addresses the risks expected to be
present at a substation. Further, cybersecurity measures must be designed and implemented in
such a manner that access and operation to legitimate activities is not impeded, particularly
during times of emergency or restoration activity. This standard presents a balance of the above
factors.
Keywords: critical infrastructure protection, cybersecurity, electronic access, encryption,

IEEE C37.240™, remote access, password management, substations
The Institute of Electrical and Electronics Engineers, Inc.

3 Park Avenue, New York, NY 10016-5997, USA
Copyright © 2015 by The Institute of Electrical and Electronics Engineers, Inc.

All rights reserved. Published 30 January 2015. Printed in the United States of America.
IEEE is a registered trademark in the U.S. Patent & Trademark Office, owned by The Institute of Electrical and Electronics
Engineers, Incorporated.
PDF: ISBN 978-0-7381-9437-0 STD20046

Print: ISBN 978-0-7381-9438-7 STDPD20046
IEEE prohibits discrimination, harassment, and bullying.

For more information, visit http://www.ieee.org/web/aboutus/whatis/policies/p9-26.html.
No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior written permission
of the publisher.
Important Notices and Disclaimers Concerning IEEE Standards Documents
IEEE documents are made available for use subject to important notices and legal disclaimers. These
notices and disclaimers, or a reference to this page, appear in all standards and may be found under the
heading “Important Notice” or “Important Notices and Disclaimers Concerning IEEE Standards
Documents.”
Notice and Disclaimer of Liability Concerning the Use of IEEE Standards
Documents
IEEE Standards documents (standards, recommended practices, and guides), both full-use and trial-use, are
developed within IEEE Societies and the Standards Coordinating Committees of the IEEE Standards
Association (“IEEE-SA”) Standards Board. IEEE (“the Institute”) develops its standards through a
consensus development process, approved by the American National Standards Institute (“ANSI”), which
brings together volunteers representing varied viewpoints and interests to achieve the final product.
Volunteers are not necessarily members of the Institute and participate without compensation from IEEE.
While IEEE administers the process and establishes rules to promote fairness in the consensus development
process, IEEE does not independently evaluate, test, or verify the accuracy of any of the information or the
soundness of any judgments contained in its standards.
IEEE does not warrant or represent the accuracy or content of the material contained in its standards, and
expressly disclaims all warranties (express, implied and statutory) not included in this or any other
document relating to the standard, including, but not limited to, the warranties of: merchantability; fitness
for a particular purpose; non-infringement; and quality, accuracy, effectiveness, currency, or completeness
of material. In addition, IEEE disclaims any and all conditions relating to: results; and workmanlike effort.
IEEE standards documents are supplied “AS IS” and “WITH ALL FAULTS.”
Use of an IEEE standard is wholly voluntary. The existence of an IEEE standard does not imply that there
are no other ways to produce, test, measure, purchase, market, or provide other goods and services related
to the scope of the IEEE standard. Furthermore, the viewpoint expressed at the time a standard is approved
and issued is subject to change brought about through developments in the state of the art and comments
received from users of the standard.
In publishing and making its standards available, IEEE is not suggesting or rendering professional or other
services for, or on behalf of, any person or entity nor is IEEE undertaking to perform any duty owed by any
other person or entity to another. Any person utilizing any IEEE Standards document, should rely upon his
or her own independent judgment in the exercise of reasonable care in any given circumstances or, as
appropriate, seek the advice of a competent professional in determining the appropriateness of a given
IEEE standard.
IN NO EVENT SHALL IEEE BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO:
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE PUBLICATION, USE OF, OR RELIANCE
UPON ANY STANDARD, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE AND
REGARDLESS OF WHETHER SUCH DAMAGE WAS FORESEEABLE.
Translations
The IEEE consensus development process involves the review of documents in English only. In the event
that an IEEE standard is translated, only the English version published by IEEE should be considered the
approved IEEE standard.
Official statements
A statement, written or oral, that is not processed in accordance with the IEEE-SA Standards Board
Operations Manual shall not be considered or inferred to be the official position of IEEE or any of its
committees and shall not be considered to be, or be relied upon as, a formal position of IEEE. At lectures,
symposia, seminars, or educational courses, an individual presenting information on IEEE standards shall
make it clear that his or her views should be considered the personal views of that individual rather than the
formal position of IEEE.
Comments on standards
Comments for revision of IEEE Standards documents are welcome from any interested party, regardless of
membership affiliation with IEEE. However, IEEE does not provide consulting information or advice
pertaining to IEEE Standards documents. Suggestions for changes in documents should be in the form of a
proposed change of text, together with appropriate supporting comments. Since IEEE standards represent a
consensus of concerned interests, it is important that any responses to comments and questions also receive
the concurrence of a balance of interests. For this reason, IEEE and the members of its societies and
Standards Coordinating Committees are not able to provide an instant response to comments or questions
except in those cases where the matter has previously been addressed. For the same reason, IEEE does not
respond to interpretation requests. Any person who would like to participate in revisions to an IEEE
standard is welcome to join the relevant IEEE working group.
Comments on standards should be submitted to the following address:
Secretary, IEEE-SA Standards Board

445 Hoes Lane
Piscataway, NJ 08854 USA
Laws and regulations
Users of IEEE Standards documents should consult all applicable laws and regulations. Compliance with
the provisions of any IEEE Standards document does not imply compliance to any applicable regulatory
requirements. Implementers of the standard are responsible for observing or referring to the applicable
regulatory requirements. IEEE does not, by the publication of its standards, intend to urge action that is not
in compliance with applicable laws, and these documents may not be construed as doing so.
Copyrights
IEEE draft and approved standards are copyrighted by IEEE under U.S. and international copyright laws.
They are made available by IEEE and are adopted for a wide variety of both public and private uses. These
include both use, by reference, in laws and regulations, and use in private self-regulation, standardization,
and the promotion of engineering practices and methods. By making these documents available for use and
adoption by public authorities and private users, IEEE does not waive any rights in copyright to the
documents.
Photocopies
Subject to payment of the appropriate fee, IEEE will grant users a limited, non-exclusive license to
photocopy portions of any individual standard for company or organizational internal use or individual,
non-commercial use only. To arrange for payment of licensing fees, please contact Copyright Clearance
Center, Customer Service, 222 Rosewood Drive, Danvers, MA 01923 USA; +1 978 750 8400. Permission
to photocopy portions of any individual standard for educational classroom use can also be obtained
through the Copyright Clearance Center.
Updating of IEEE Standards documents
Users of IEEE Standards documents should be aware that these documents may be superseded at any time
by the issuance of new editions or may be amended from time to time through the issuance of amendments,
corrigenda, or errata. An official IEEE document at any point in time consists of the current edition of the
document together with any amendments, corrigenda, or errata then in effect.
Every IEEE standard is subjected to review at least every ten years. When a document is more than ten
years old and has not undergone a revision process, it is reasonable to conclude that its contents, although
still of some value, do not wholly reflect the present state of the art. Users are cautioned to check to
determine that they have the latest edition of any IEEE standard.
In order to determine whether a given document is the current edition and whether it has been amended
through the issuance of amendments, corrigenda, or errata, visit the IEEE-SA Website at
http://ieeexplore.ieee.org/xpl/standards.jsp or contact IEEE at the address listed previously. For more
information about the IEEE SA or IEEE’s standards development process, visit the IEEE-SA Website at
http://standards.ieee.org.
Errata
Errata, if any, for all IEEE standards can be accessed on the IEEE-SA Website at the following URL:
http://standards.ieee.org/findstds/errata/index.html. Users are encouraged to check this URL for errata
periodically.
Patents
Attention is called to the possibility that implementation of this standard may require use of subject matter
covered by patent rights. By publication of this standard, no position is taken by the IEEE with respect to
the existence or validity of any patent rights in connection therewith. If a patent holder or patent applicant
has filed a statement of assurance via an Accepted Letter of Assurance, then the statement is listed on the
IEEE-SA Website at http://standards.ieee.org/about/sasb/patcom/patents.html. Letters of Assurance may
indicate whether the Submitter is willing or unwilling to grant licenses under patent rights without
compensation or under reasonable rates, with reasonable terms and conditions that are demonstrably free of
any unfair discrimination to applicants desiring to obtain such licenses.
Essential Patent Claims may exist for which a Letter of Assurance has not been received. The IEEE is not
responsible for identifying Essential Patent Claims for which a license may be required, for conducting
inquiries into the legal validity or scope of Patents Claims, or determining whether any licensing terms or
conditions provided in connection with submission of a Letter of Assurance, if any, or in any licensing
agreements are reasonable or non-discriminatory. Users of this standard are expressly advised that
determination of the validity of any patent rights, and the risk of infringement of such rights, is entirely
their own responsibility. Further information may be obtained from the IEEE Standards Association.
Participants
At the time this IEEE standard was completed, the Substations Committee H13 and C10 Working Group
had the following membership:
Sam Sciacca, Power System Relaying Committee H13 Working Group Chair
Tim Tibbals, Substations Committee C10 Working Group Chair
Ed Cenzon Randy Hamilton Craig Preuss

Cathrine Dalton Richard Harada Neil Saia
Michael Dood Chris Huntley Sam Sciacca
Ronald Farquharson Anthony Johnson Stephen Thompson
Michael Fauchon Steven Kunsman Tim Tibbals
John Galanos Marc LaCroix Alex Wang
Didier Giarratano Theo Laughner Solveig Ward
Bob Haberman Richard Liposchak Murty Yalla
The following members of the individual balloting committee voted on this standard. Balloters may have
voted for approval, disapproval, or abstention.
William Ackerman Randall Groves Bruce Muschlitz

Satish Aggarwal David Harris Michael Newman
Ali Al Awazi Roger Hedding Charles Ngethe
Steven Alexanderson Hamidreza Heidarisafa Joe Nims
Jay Anderson Werner Hoelzl Gary Nissen
John Banting Jerry Hohn Lorraine Padden
David Bassett David Horvath Bansi Patel
Philip Beaumont Chris Huntley Ulrich Pohl
Robert Beresh David Ingram Bogdan Popescu
Oscar Bolado Ronald Jarrett Craig Preuss
James Bougie Brian Johnson John Randolph
Sheila Brown Lars Juhlin Michael Roberts
Gustavo Brunello Innocent Kamwa Charles Rogers
William Byrd Piotr Karocki Thomas Rozek
Paul Cardinal Bogdan Kasztenny Bartien Sayogo
Suresh Channarasappa Yuri Khersonsky Thomas Schossig
Robert Christman James Kinney Sam Sciacca
Stephen Conrad Hermann Koch Douglas Seely
James Cornelison Joseph L. Koepfinger Devki Sharma
Luis Coronado Jim Kulchisky Mark Simon
Randall Crellin Saumen Kundu David Singleton
Ratan Das Steven Kunsman Veselin Skendzic
Kevin Donahoe George Kyle Jerry Smith
Gary Donner Chung-Yiu Lam John Spare
Michael Dood Raluca Lascu Scott Sternfeld
Douglas Dorr Theo Laughner Tyler Stinson
Randall Dotson Otto Lynch Gary Stoedter
Ernest Duckworth Bruce Mackie William Taylor
Dan Dwyer Pierre Martin John Tengdin
Kenneth Fodero David Mazur David Tepen
Fredric Friend John McDonald Eric Thibodeau
Adam Gauci Sujeet Mishra Vincent Tume
Frank Gerleve Jeffery Mizener Demetrios Tziouvaras
Jeffrey Gilbert Jose Morales Joe Uchiyama
Mietek Glinkowski Adi Mulawarman Dmitri Varsanofiev
Jalal Gohari Jerry Murphy John Vergis
Roman Graf R. Murphy Jane Verner
vi
Copyright © 2015 IEEE. All rights reserved.
Ilia Voloh Kenneth White Richard Young
John Wang Philip Winston Shuhui Zhang
Solveig Ward Daidi Zhong
When the IEEE-SA Standards Board approved this standard on 10 December 2014, it had the following
membership:
John Kulick, Chair

Jon Walter Rosdahl, Vice Chair
Richard H. Hulett, Past Chair
Konstantinos Karachalios, Secretary
Peter Balma Michael Janezic Ron Petersen

Farooq Bari Jeffrey Katz Adrian Stephens
Ted Burse Joseph L. Koepfinger* Peter Sutherland
Clint Chaplin David J. Law Yatin Trivedi
Stephen Dukes Hung Ling Phil Winston
Jean-Philippe Faure Oleg Logvinov Don Wright
Gary Hoffman T. W. Olsen Yu Yuan
Glenn Parsons
*Member Emeritus
Also included are the following nonvoting IEEE-SA Standards Board liaisons:
Richard DeBlasio, DOE Representative

Michael Janezic, NIST Representative
Patrick Gibbons
IEEE-SA Content Production and Management
Erin Spiewak
IEEE-SA Technical Program Operations
vii
Introduction
This introduction is not part of IEEE Std C37.240™-2014, IEEE Standard Cybersecurity Requirements for Substation
Automation, Protection, and Control Systems.
This document provides technical requirements for substation cybersecurity. It presents sound engineering
practices that can be applied to achieve high levels of cybersecurity of automation, protection, and control
systems independent of voltage level or criticality of cyber assets. Cybersecurity includes trust and
assurance of data in motion, data at rest, and incident response.
viii
Contents
1. Overview .................................................................................................................................................... 1
1.1 Scope ................................................................................................................................................... 1
1.2 Reason ................................................................................................................................................. 1
2. Normative references.................................................................................................................................. 2
3. Acronyms and abbreviations ...................................................................................................................... 3
4. Use of this standard .................................................................................................................................... 4
5. Description of cybersecurity ....................................................................................................................... 4

5.1 Problem statements from utilities and operational challenges ............................................................. 4
5.2 Components of interest ........................................................................................................................ 5
5.3 High-level security goals ..................................................................................................................... 6
6. Cybersecurity requirements ........................................................................................................................ 7

6.1 High level requirements and priorities for interface categories ........................................................... 7
6.2 System communications components .................................................................................................. 9
6.3 Functional Requirements ....................................................................................................................12
6.4 User authentication and authorization ................................................................................................14
6.5 Data-in-motion protection ..................................................................................................................21
6.6 Configuration management ................................................................................................................21
6.7 Security event auditing and analysis/incident response ......................................................................22
6.8 Security testing ...................................................................................................................................24
ix
and Control Systems
IMPORTANT NOTICE: IEEE Standards documents are not intended to ensure safety, security, health,
or environmental protection, or ensure against interference with or from other devices or networks.
Implementers of IEEE Standards documents are responsible for determining and complying with all
appropriate safety, security, environmental, health, and interference protection practices and all
applicable laws and regulations.
This IEEE document is made available for use subject to important notices and legal disclaimers.
These notices and disclaimers appear in all publications containing this document and may
be found under the heading “Important Notice” or “Important Notices and Disclaimers
Concerning IEEE Documents.” They can also be obtained on request from IEEE or viewed at
http://standards.ieee.org/IPR/disclaimers.html.
1. Overview
1.1 Scope
This document provides technical requirements for substation cybersecurity. It presents sound engineering
practices that can be applied to achieve high levels of cybersecurity of automation, protection, and control
systems independent of voltage class or criticality of cyber assets. Cybersecurity includes trust and
assurance of data in motion, data at rest, and incident response.
1.2 Reason
Modern substation automation, protection, and control systems, while using technology advancements to
achieve greater power-system reliability, can be vulnerable to a multitude of cybersecurity threats. These
vulnerabilities and threats can lead to overall power-system integrity issues. With the increasing
dependency on communication technology and the growing pressure of a secure utility infrastructure,
various standardization bodies are in the process of developing cybersecurity standards where very little
effort has gone into the harmonization or rationalization of these standards to substation applications.
Examples of important standards to the utility community are the following:
1
IEEE Std C37.240-2014
IEEE Standard for Cybersecurity Requirements for Substation Automation, Protection, and Control Systems
 IEC 62351, Power systems management and associated information exchange—Data and
communication security.
 IEEE Std 1686™, IEEE Standard for Intelligent Electronic Devices Cybersecurity Capabilities. 1
 IEEE Std 1711™, IEEE Trial-Use Standard for a Cryptographic Protocol for Cybersecurity of
Substation Serial Links.
 NERC CIP, Critical Infrastrucure Protection. 2
This standard builds on the other work to date to produce a specification for a technically feasible
cybersecurity implementation.
2. Normative references
The following referenced documents are indispensable for the application of this document (i.e., they must
be understood and used, so each referenced document is cited in text and its relationship to this document is
explained). For dated references, only the edition cited applies. For undated references, the latest edition of
the referenced document (including any amendments or corrigenda) applies.
ANSI INCITS 359-2004, American National Standards for Information Technology—Role Based Access
Control. 3
IEC 62351-8, Power systems management and associated information exchange—Data and
communications security—Part 8: Role-based access control. 4
IEEE Std 1402™, IEEE Guide for Electric Power Substation Physical and Electronic Security. 5,6
IEEE Std 1686, IEEE Standard for Intelligent Electronic Devices Cyber Security Capabilities
IEEE Std 1711, IEEE Trial-Use Standard for a Cryptographic Protocol for Cyber Security of Substation
Serial Links.
NISTIR 7628, Guidelines for Smart Grid Cybersecurity: Vol. 1, Smart Grid Cyber Security Strategy,
Architecture, and High-Level Requirements. 7
1
Information on references can be found in Clause 2.
2
NERC publications are available at http://www.nerc.com/pa/Stand/Reliability%20Standards/Forms/AllItems.aspx.
3
ANSI publications are available from the Sales Department, American National Standards Institute, 25 West 43rd Street, 4th Floor,
New York, NY 10036, USA (http://www.ansi.org/).
4
IEC publications are available from the Sales Department of the International Electrotechnical Commission, 3 rue de Varembé, PO
Box 131, CH-1211, Geneva 20, Switzerland (http://www.iec.ch/). IEC publications are also available in the United States from the
Sales Department, American National Standards Institute, 25 West 43rd Street, 4th Floor, New York, NY 10036, USA
(http://www.ansi.org).
5
The IEEE standards or products referred to in this clause are trademarks of The Institute of Electrical and Electronics Engineers, Inc.
6
IEEE publications are available from The Institute of Electrical and Electronics Engineers, 445 Hoes Lane, Piscataway, NJ 08854,
USA (http://standards.ieee.org/).
7
NIST publications are available from the National Institute of Standards and Technology, 100 Bureau Drive, Stop 1070,
Gaithersburg, MD 20899-2300, USA (http://www.nist.gov/index.html).
2
IEEE Std C37.240-2014
3. Acronyms and abbreviations

CIP critical infrastructure protection
CMA connection-monitoring authority
GOOSE generic object-oriented substation event
GIS gas-insulated substation
HMI human-machine interface
IDS intrusion-detection systems
IED intelligent electronic device
IPS intrusion-protection systems
LAN local-area network
MU merging unit
NCIT nonconventional instrument transformer
RBAC role-based access control
RCCA remote-connection controlling authority
RIA remote IED access
RIAG remote IED access gateway
RTU remote-terminal unit
RUC remote-user community
SCADA supervisory control and data acquisition
SCS substation control system
SIPS system integrity protection schemes
SNMP simple network-management protocol
VPN virtual private network
WAMS wide-area measurement system
WAN wide-area network
3
IEEE Std C37.240-2014
4. Use of this standard

Cybersecurity in substation automation, protection, and control systems is widely recognized as a critical
component in overall reliability of electricity supply. The North American Electric Reliability Corporation
(NERC) critical infrastructure protection (CIP) standards have addressed a number of objectives that are to
be accomplished in a cybersecurity program but have left the technical details and methods to the
individual implementer. It can, however, be deduced that any cybersecurity program for the electric utility
substation environment must have certain characteristics:
 Technical Feasibility: The cybersecurity of a substation must be technically feasible in a substation

environment. There are many aspects of substation operation that may preclude the use of
cybersecurity technologies that are employed in other environments, such as commercial, financial,
and military aaspects. Additionally, the program must be able to be deployed in a timely manner. A
cybersecurity program that requires the replacement of a massive amount of automation,
protection, and control equipment is not feasible, as the deployment might take many years, leaving
the utility vulnerable through the deployment period.
 Economic Feasibility: A cybersecurity program must take into account the size of the deployment
and the ability of the utility to accomplish deployment at a cost acceptable to the stakeholders,
which includes both shareholders and ratepayers of the utility.
 Operational Feasibility: Utility substations have specific operational and maintenance

requirements that must be considered in the development of the cybersecurity program. For
example, a cybersecurity program that relies solely on having a local-area/wide-area network
(LAN/WAN) connection to the substation may be impractical as loss of communications to the
substation is likely under a number of typical fault scenarios. The cybersecurity system must not
become an undue impediment for the critical functions of substation operation to occur.
This standard presents the minimum requirements for a substation cybersecurity program, keeping in
perspective the technical, economical, and operational feasibility of deployment. A utility deploying a
cybersecurity program that meets the requirements of this standard will have developed a program that
considers all of the above elements and represents the best practices as employed by the industry.
5. Description of cybersecurity
5.1 Problem statements from utilities and operational challenges
Utilities have a wide variety of components that utilize communication, varying from vacuum tube power-
line carriers to multifunction microprocessor relays utilizing a high-speed WAN. The “channel” or
“communication medium” used varies from utility-owned dedicated-pilot wires, microwave, or fiber
networks to leased infrastructure, including dial up and cellular, which is basically shared with the public.
Because of the variability in communication systems, using a standardized approach comes with some level
of difficulty. Either the standards need to provide direction for each type of communication or multiple
standards need to exist. Clearly, applying a one-size-fits-all approach for cybersecurity will not be effective
and may limit the ability of the utility to do its job—namely, keeping the lights on.
It is important to note that utilities have two different definitions for reliability. The concept of reliability is
made up of the following two factors:
4
IEEE Std C37.240-2014
 Security, in terms of reliability, is the ability of a system to refrain from operation when it is not
expected to operate.
 Dependability is the ability of a system to operate properly when called upon to operate.
Often these two factors are opposed in that, in order to get more of one, a sacrifice must be made in the
other. This is very different from the security of keeping the equipment protected and free from any
vulnerabilities that may either impede or cause unintended operation. In this definition of security, there are
two main classifications: physical security and cybersecurity. Physical security is via local contact whereas
cybersecurity is concerned with data at rest and data in motion.
With regards to data in motion, there are some key points that distinguish the different aspects of
cybersecurity. Some communications networks are self-contained and do not have any point of presence
accessible by external connectivity. This is true of protective-relay pilot channels. Other networks traverse
the public switched network where there are multiple touch points by which external connectivity can be
made. Each type must be classified to determine the risk and, therefore, the applicable security
requirements, design, and deployment.
Utilities rely on remote access in order to maintain reliability. Utilities are mandated by NERC, the Federal
Energy Regulatory Commission (FERC), or other organizations to use this data to investigate outages and
to recognize that the power system may be in a compromised operational state. Data regarding power-
system faults must be gathered within minutes so that they can be analyzed not only to restore power in the
case of an outage but to restore the system to normal should a misoperation occur. The utility has a “select”
team of individuals that require access to the substation and central recording systems, such as supervisory
control and data acquisition (SCADA), at a moment’s notice. Any implementation of cybersecurity barriers
must allow these individuals access. In the same vein, it must be limited to individuals that need this access.
Individuals that can access sensitive data need to have appropriate credentials and authority. The general
utility-employee population must not have access to sensitive data. The type of user access is very
dependent on the equipment being accessed. Some can be done via a company network and others via a
dial-up connection. The type of security barriers employed must be tailored to the equipment and the
requirements. Speed is not as important as accessibility. Often, the data files are small, and even a small
bandwidth can suit the needs of most applications. Higher bandwidth may be a consideration when it is
considered as an aggregate when multiple points are sending information at the same time. Engineers may
also require access to remotely configure the devices. Good security practice provides role-based privileges
based on the responsibilities of the users.
As security requirements become adopted, some utilities will be able to fit the requirements to their existing
architecture or certain aspects of it. Others will need to update their architecture. There will also be a group
that will remove remote communications by unplugging the cord to comply, which puts the company at
risk of being unable to meet their reliability requirements. Utilities are not always in a position to recoup
the investment required to update their systems to meet the requirements imposed by the modern
cybersecurity threatscape. It is the need to balance conflicting requirements that every utility must confront
and respond to as a part of their short-term and long-term strategies.
5.2 Components of interest
This standard is designed to cover a wide range of components of a substation protection and control
system, including process components such as design, engineering, and maintenance functions. The
substation automation, protection, monitoring and control system components (actors) may include the
following:
 System/protection engineering, and maintenance (local and remotely accessed)

 Engineering work place
5
IEEE Std C37.240-2014
 Station human-machine interface (HMI)

 Teleprotection
 Substation control system (SCS)
 Intelligent electronic device (IED)/relay
 Breaker IED
 Remote-termina unit (RTU)/gateway
 Time
 GPS
 Distribution management system
 Asset monitoring
 Merging unit (MU)/sensor
 Intelligent CT/PT (NCIT)
 PMU/PMU data concentrator
 Security management (external and internal)
 Physical security system components [access control, (PSP) intrusion detection, CCTV monitoring]
 SCADA (external)
 System integrity protection schemes (SIPS) (external)
 Wide-area measurement systems (WAMS) (external)
 Time server (external)
 Distribution sensor (external)
Data at rest and the protection of files, whether in hard copy or existing on IEDs, is also critical in a sound
cybersecurity program. Engineering manuals, drawings, and lists of passwords that are not secured can
easily compromise the most elegant of technology solutions. The protection of data at rest is outside the
scope of this document; however, work in this important area continues to evolve in other groups within the
IEEE Power and Energy Power System Relaying Committee and could be the topic of an amendment to
this standard in the future.
5.3 High-level security goals
Long before NERC CIP and the present environment of cybersecurity awareness, utilities had recognized
the vital nature of substation assets and the need for security at substation locations. While the degree of
security concerns varied depending on a number of factors (voltage class, operational criticality, physical
location, etc.) the goals of the security program uniformly address a number of foundational requirements.
6
IEEE Std C37.240-2014
5.3.1 Foundational requirements
Table 1, developed from ISA 99, Industrial Automation and Control Systems Security 8, lists the
foundational requirements of any cybersecurity program for electric utility substations.
Table 1 —Cybersecurity program foundational requirements

AC: Access Control Restrict access to selected devices and information to only authorized
personnel.
UC: Use Control Restrict use of selected devices and information to only authorized
personnel.
DI: Data Integrity Protect the integrity of data against unauthorized changes.
DC: Data Confidentiality Protect the confidentiality of data against eavesdropping.
RDF: Restrict Data Flow Restrict the flow of data to protect against the publication of
information to unauthorized sources.
TRE: Timely Response to Event Respond to security violations taking timely corrective action in
mission critical or safety critical situations.
NRA: Network Resource Availability Protect the availability of all network resources against denial of
service attacks.
5.3.2 Physical security
Essential to any cybersecurity program is an overlying physical-security program that monitors and
controls physical access to the cyber assets. Unrestricted physical access to cyber assets will eventually
lead to a lessening of effectiveness of the cybersecurity elements. IEEE Std 1402 establishes appropriate
levels of physical security and access control for substations. This standard should be applied as the
minimum level of physical security to overlay and enhance the cybersecurity program.
5.3.3 Data at rest
The protection of data at rest is critical to a sound cybersecurity program. Data at rest includes file-type
data of IEDs (configuration files, data files, etc.) as well as hard copy information (IED instruction
manuals, station drawings, etc.). Data at rest is the ongoing topic of a working group of the Power System
Relaying Committee which is expected to produce a standard in this area sometime in the future. Any work
resulting in this area will be evaluated for inclusion by reference into future revisions of IEEE Std C37.240.
6. Cybersecurity requirements
6.1 High level requirements and priorities for interface categories
NISTIR 7628 establishes a methodology for addressing and evaluating the requirements of cybersecurity
programs. An important aspect of a utility cybersecurity program is to map the program to the elements
identified in NISTIR 7628 with regards to confidentiality (C), integrity (I) and availability (A). Table 2
illustrates a mapping of a hypothetical substation cybersecurity program with the NISTIR 7628
requirements.
8
ISA publications are available from The International Society of Automation at https://www.isa.org/standards-publications/
7
IEEE Std C37.240-2014
Table 2 —Substation cybersecurity requirements mapped to NISTIR 7628*

C I A
1a Interface between control systems and equipment with high availability and with computing L H H
and/or bandwidth constraints, for example:
- between transmission SCADA and substation equipment
- between distribution SCADA and high priority substation and pole-top equipment
- between SCADA and DCS within a power plant
Serial protocol interface between substation and the National Control Center (NCC) for critical
measurements and control, e.g., SCADA
Generic object-oriented substation event (GOOSE) communications (compute constraints), e.g.,
bay to bay or substation to substation
1b Interface between control systems and equipment without high availability but with compute L H M
and/or bandwidth constraints, for example:
- Between distribution SCADA and lower priority pole-top equipment
- Between pole-top IEDs and other pole-top IEDs
Serial protocol interface between substation and NCC for non-critical measurements and
monitoring, e.g., asset monitoring
1c Interface between control systems and equipment with high availability, without compute nor L H H
bandwidth constraints, for example: between transmission SCADA and substation automation
systems
High-bandwith protocol interface between
- Substation and NCC for critical measurements and control, e.g., SCADA
- WAMS
- SIPS
- Teleprotection (high availability, time critical)
1d Interface between control systems and equipment without high availability, without compute L H M
nor bandwidth constraints, e.g., between distribution SCADA and backbone network-connected
collector nodes for distribution pole-top IEDs
Asset monitoring using Ethernet network, local HMI, maintenance, engineering (e.g., DR
uploads)
8 Interface between sensors and sensor networks for measuring environmental parameters, usually L M M
simple sensor devices with possibly analog measurements, for example: between a temperature
sensor on a transformer and its receiver
9 Interface between sensor networks and control systems, for example: between a sensor receiver L M M
and the substation master, e.g., asset monitoring and SCS or RTU/e.g., MU and bay device
(IED)
13 Interface between systems and mobile field crew laptops/equipment, for example: L H M
- Between field crews and gas-insulated substations (GISs)
- Between field crews and substation equipment
16 Interface between engineering/maintenance systems and control equipment, for example: L H M
- Between engineering and substation relaying equipment for relay settings
- Between engineering and pole-top equipment for maintenance
- Within power plants
17 Interface between control systems and their vendors for standard maintenance and service, for L H L
example: between a SCADA system and its vendor
18 Interface between security/network/system management consoles and all networks and systems, H H H
for example: between a security console and network routers, firewalls, computer systems, and
network nodes
*L = Low, M = Medium, and H = High. The pink cells indicate most critical. The yellow cells indicate intermediate.
The requirements and practices presented in this standard address interfaces shown in Table 2 that are high
for any combination of C, I,Std and A.
8
IEEE Std C37.240-2014
6.2 System communications components
6.2.1 Communication network components
Communication networks are composed of devices that connect and facilitate transfer of information both
between IEDs within the substation and between substation IEDs and systems external to the substation
over a wired or wireless LAN or WAN. A device may model one or more communications functions. The
substation IEDs (protective relay, bay controller, RTU) are part of the communication network.
6.2.2 Substation network components
6.2.2.1 Background
The following subclauses provide brief descriptions of substation network components. More complete
descriptions can be found in IEEE Std 1615. 9 These devices are often provided by the manufacturers with
cybersecurity functions included in the product.
6.2.2.2 Network switch
A network switch provides Layer 2 or Layer 3 switching. Network switches provide LAN communication
and must be manageable to support configuration of security parameters.
6.2.2.3 Router
A router provides communication between different types of networks such as between an Ethernet
network LAN and WAN. The different types of networks can consist of various mediums and protocols
and the router is responsible for the appropriate conversions.
6.2.2.4 Serial device server
A serial device server provides communication to serial devices and may encapsulate the serial data in
other protocol formats such as TCP packets for communication over Ethernet networks.
6.2.2.5 Wireless access point/base station
A wireless access point/base station provides bridging between wireless devices and wired networks. The
radio technologies employed in these devices include IEEE 802.11TM, IEEE 802.15TM and short-range/low-
power radio technology.
6.2.3 Substation device security requirements
All substation communications devices shall implement all normative requirements of IEEE 1686™.
9
This publication is available from The Institute of Electrical and Electronics Engineers, 445 Hoes Lane, Piscataway, NJ 08854, USA
(http://standards.ieee.org/).
9
IEEE Std C37.240-2014
6.2.4 Network-switch security requirements
6.2.4.1 Authentication
The network switch shall support a mechanism to allow authentication of devices or users that connect to
its ports before allowing the device or user to communicate on the network.
6.2.4.2 Configuration
Network switches shall be configured to limit port bandwidth to mitigate the effects of denial-of-service
attacks. Configuration shall be application specific and shall be determined by the network-design engineer
prior to installation of the switch.
6.2.4.3 Virtual local-area network (VLAN)
Network switches should be capable of configuring virtual LANs, (VLANs). VLANs allow the creation of
LAN segments that can be used to segregate network traffic. This segregation allows only members of the
VLAN to communicate to each other, providing isolation from the rest of the LAN. VLANs also limit
broadcast domains to provide further protection from the effects of denial-of-service attacks.
6.2.5 Router requirements
Ethernet (LAN) ports on the router shall provide the same level of security as noted in 6.2.4. WAN ports on
the router shall support a means to establish secure tunnels that are encrypted. Secure tunnels allow data to
flow through unprotected networks, i.e., the Internet. Routers shall provide the mechanism to log
activities/connections taking place between the router and the WAN as defined in 5.2.3 of IEEE Std 1686-
2013.
6.2.6 Serial-device server requirements
6.2.6.1 Port management
Ethernet (LAN) ports on the serial device server shall provide the same level of port management and port
security as the network switch.
6.2.6.2 Encryption handling
The serial device server shall be capable of receiving data through its serial port whether encrypted or
unencrypted. Data from the serial port server shall be encapsulated in data packets and delivered to the
host.
10
IEEE Std C37.240-2014
6.2.7 Wireless access point/base-station requirements
6.2.7.1 Authentication
The wireless access point/base station shall employ a mechanism to authenticate devices or users that
connect to its ports before allowing the device to communicate on the network.
6.2.7.2 Encryption of transmission
The wireless access point/base station shall encrypt the wireless data with a minimum 128-b encryption.
Wired-equivalent privacy (WEP) shall not be employed.
6.2.7.3 Network identification broadcast
The wireless access point/base station shall not be set to broadcast the wireless network ID such that client
devices must know the identity of the network to which they are connecting.
6.2.8 Firewalls, VPNs, proxies, and key management
6.2.8.1 Firewall
The firewall provides protection from unauthorized access to and from the substation LAN when it is
connected to the Internet or other unprotected external networks. The firewall can provide isolation for
specified router interfaces from unprotected external networks. All traffic to and from the substation LAN
shall pass through the firewall.
6.2.8.2 VPN
Virtual private networks (VPNs) shall be used to provide secure data paths between the substation LAN
and remote sites such as other substations or SCADA master/client applications. The VPN shall provide
authentication of packets from a known and trusted sender. The VPN shall provide encryption with a
minimum 128-b key to protect packets from being read by an unauthorized receiver.
6.2.8.3 Proxy and address translation
Routers on the network shall deploy proxy access-resolution protocol (ARP) and address translation to hide
the substation LAN IP addresses from the Internet or unprotected network.
6.2.8.4 Network intrusion detection/protection
Intrusion-detection systems (IDSs) monitor network traffic for specific patterns (signatures) and provide
alerts to network managers if these signatures are detected. IDS rely on pattern matching of recognized
attack methods and weaknesses of networks. There are some concerns about the use of IDS; it is necessary
to keep signatures updated to the newest attack methods through maintenance of servers. Additionally,
false positives can occur if legitimate data matches an attack signature.
11
IEEE Std C37.240-2014
Intrusion-protection systems (IPSs) react to specific patterns detected by IDS systems and attempt to shut
down the connection from the incoming device. Consideration must be taken when using an IPS as it has
the potential to shut down a connection on a critical protection-and-control network on a false positive
detection.
Substation LANs shall deploy IDSs/IPSs to monitor and protect the network.
6.2.8.5 Key/certificate management
Network devices that are capable of sending and receiving encrypted data shall have a key to perform the
encryption/decryption. Keys shall be kept secret and secure to ensure other devices cannot snoop the
encrypted data or inject encrypted data onto the network.
6.3 Functional Requirements
6.3.1 Remote IED Access
Remote IED Access (RIA) is defined as making a connection to an IED (or IEDs) from a location external
to the physical substation control house or defined control area electronic security perimeter. This access
for activities includes the following:
 IED maintenance and configuration

 Record and file downloading [e.g., fault records, sequence-of-events (SOE) records, diagnostics]
 Cybersecurity monitoring/maintenance (IEEE 1686 activities)
6.3.2 Communications paths
Communications paths for remote access to IEDs shall be on demand and shall not be permanently
connected. All connections to substation IEDs shall be made through a centralized facility or gateway
mechanism called a Remote IED Access Gateway (RIAG). The location of the RIAG can be at the
substation or at a location remote to the substation to provide the functionality described in this subclause.
At no time shall a remote user be connected directly to an IED bypassing the RIAG. The RIAG shall be an
IEEE Std 1686 compliant device.
6.3.3 Dial-up connections
Dial-up service is defined as a direct, one-to-one connection made on an on-demand basis that only exists
for the duration of the exchange of data, after which it is terminated. This kind of connection is sometimes
made over a “plain old telephone service” (POTS) line. Examples of dial-up service include:
 Hard-wired telephone service by a third party

 User-owned facilities (microwave, orderwire, fiber optics)
 Wireless/cellular communications (GSM, CDMA)
If dial-up connections are employed, the communications connection to and from the RIAG shall be
physically isolated when not in use. Examples of disabling mechanisms include, but are not limited to:
12
IEEE Std C37.240-2014
 Physical disconnection of phone line conductors

 Removal of power from modem, microwave channel, or com path interface
 Removal of power from the RIAG if the RIAG is located at the substation
Control of the mechanism to physically isolate the dial-up control path shall be under the control of an
authority independent of the remote access user (e.g., the SCADA/EMS organization). To connect to a
path, the remote access user shall authenticate to the appropriate authority in the SCADA/EMS
organization. Upon proper authentication, the SCADA/EMS organization will issue the command to enable
the pathway to the requested substation. The SCADA/EMS organization shall be responsible for allowing
the pathway to remain open only for the period of time that it is in use by the requesting remote user. The
pathway shall then be disconnected by the SCADA/EMS organization.
6.3.4 Network connection
For substations employing network or internet connectivity for remote user access, connection to the
substation shall be made through a secure connection technique such as a VPN or virtual circuit.
6.3.5 Encryption
All communications used for remote access shall be encrypted. Serial communications shall take place
through an IEEE Std 1711 compliant mechanism, such as a bump-in-the-wire appliance or an embedded
application in the RIAG and the remote user terminal. Network connections shall employ a minimum of
128-b encryption.
6.3.6 Remote IED access gateway
6.3.6.1 Background
The RIAG shall be an IEEE Std 1686 compliant appliance that controls all access to the remote device or
substation gateway. Configuration control of the RIAG shall be under the authority of an entity separate
from the authorized user list and shall be maintained and controlled in accordance with the owner’s
cybersecurity plan.
The RIAG shall provide, as a minimum, the features listed in the following subclauses.
6.3.6.2 User authentication
The RIAG shall permit only authorized users to employ the remote access pathway. The RIAG shall have a
secure and readily monitored mechanism to add and delete authorized users such as a link to the utility
corporate IT directory of authorized personnel.
6.3.6.3 IED access restriction
The RIAG shall permit access to IEDs on a user-login (role-based) basis. The RIAG shall maintain a list of
authorized users and the IEDs to which each user is permitted access. It shall not be possible for a user to
access an IED for which positive assertion of access has not been made. The RIAG shall monitor and log
all changes to the permission levels and authorized user list in compliance with 5.6.2.1 of IEEE Std 1686-
2013.
13
IEEE Std C37.240-2014
6.3.6.4 IED application control
The RIAG shall control which application(s) are permitted to be used for connection on both an IED and
authorized-user basis. It shall not be possible to access an IED with an application that is not authorized to
be used with that IED. Similarly, all authorized users will be restricted to applications that can be used by
that user for each IED.
6.3.6.5 Remote-access connection monitoring
Remote-access connection monitoring shall be performed by an entity of the owner which is independent
from both the remote-user community (RUC) and the remote-connection controlling authority (RCCA).
This connection-monitoring authority (CMA) shall report to the owner’s cybersecurity compliance
authority.
6.3.6.6 Dial-up access
Connection requests through a dial-up application shall be monitored and logged by the RCCA, which shall
be independent from the RUC. The connection shall be logged as to when it was made, the duration of the
connection, and the user that requested the connection.
The connection shall be periodically checked for connectivity by the CMA through periodic and random
attempts to establish the dial-up connection. If the CMA determines that the connection is available (e.g.,
the connection is made/not in use by an authorized user as per the procedural direction established), the
CMA shall immediately direct the RCCA to disable the connection. The incident shall be reported to the
user entity responsible for monitoring cybersecurity compliance and remedial action shall be initiated.
6.3.7 Network access
Network access shall be monitored by the CMA through simple network-management protocol (SNMP)
queries of the RIAG (or other methods which provide similar functionality) as described in IEEE Std 1686.
SNMP polls for log-in management information bases (MIBs) will be performed automatically not less
than once per hour at random intervals. SNMP records shall be kept by the CMA in accordance with the
owner-established cybersecurity procedures and be available for periodic review or remedial action. The
traps shall be sent to the CMA for any unsuccessful login attempts per 5.3.2.1 of IEEE Std 1686-2013,
timed log-outs per 5.32.3.3 of IEEE Std 1686-2013, and other events and alarms as described in 5.3 of
IEEE Std 1686-2013. In the event of receiving a trap associated with a RIAG, the incident shall be reported
to the owner’s cybersecurity compliance authority for further action.
6.4 User authentication and authorization
6.4.1 User authentication principles
The SCS and devices shall enforce multi-factor user authentication so that systems, devices, and other
resources are only used by appropriately authenticated users.
Multi-factor means that a user must provide more than one item (or credential) to gain access. This requires
that the user shall provide credentials to demonstrate that the user is the right user (identification) and a
credential that proves the identification provided (validation).
14
IEEE Std C37.240-2014
Identification shall be through use of an object (token). A token can be one of the following:
 a key
 a USB stick
 a swipe card
 a property of the user (such as a fingerprint or a retina pattern)
 a username
The system or device shall ask the user to supply the user’s credentials as the first step in gaining access to
the system or device. A user need not be a “human” as another system can be a user of a target system. In
this case, the token would be a digital identifier (a string of bits) that is provided through the
communication channel between the two systems during the initial stages of establishing a communication
link.
Validation is achieved through providing information that is personally known by the user. Typically this
would be a password or pin but validation could be achieved via a pass phrase or a secret answer to a
question that is asked by the system or device. User passwords have special requirements that are discussed
in 6.4.8.
In the remainder of this section, the focus is on a user identifier and a user password but all the provisions
described apply equally to other combinations of identification and validation listed above.
6.4.2 User-authentication blocking
The SCS shall block a user if a number of consecutive authentication failures occur within a defined period
of time. Systems may become compromised because they do not prevent multiple attempts to enter the
correct password from occurring thus allowing an attacker to try different passwords until the correct one is
found. If the login attempt is through one of the communication channels to the system or device, automatic
password generators can continuously make login attempts until successful. It is therefore mandated that
the system or device shall monitor failed attempts to authenticate and shall maintain a count of the number
of consecutive times a user has failed to successfully log on. If the count reaches a defined limit, the user is
blocked. Blocking a user means that the user is temporarily denied access even if they should enter the
correct password. The number of failed attempts that triggers a user being blocked shall be between two
and five, configurable between those limits.
The blocking of a user is a temporary state that can be released automatically after a certain period of time
or could only be released by manual intervention by a user with appropriate authorization, or both. The
time period before an automatic block release occurs is not mandated and could be any period from several
seconds to several hours or days, depending on the sensitivity of the channel, the user, and the technical
capability of the system. Automatic releasing itself could be monitored and controlled to prevent a
continuous cycle of block and release occurring so that only a certain number of consecutive automatic
releases are permitted before a manual release is required.
The blocking a user account shall be logged with the event reason, “User account blocked,” and shall
contain the identifier of the user account. Releasing a blocked account, whether automatic or manual, shall
be logged with the event reason, “User account block released,” and shall contain the user identifier and the
release mechanism (automatic or manual).
15
IEEE Std C37.240-2014
6.4.3 User-authentication session
The substation system and devices shall enforce the need for a user who has been authenticated and granted
access to subsequently terminate their access when they have completed their task. The substation system
and devices shall automatically terminate the access of a user after a period of inactivity.
Once a user has been authenticated and has gained the access to the system or device, the user is “logged
on.” Procedures shall require that the user “log off” when finished in order to maintain security and prevent
an unauthorized person from using the same access. The system or device shall also monitor activity of the
user and, after a period when it has been determined that the user has not been active, it shall automatically
terminate the access to maintain security.
The determination of inactivity will vary according to the access interface. A user of an HMI shall be
deemed inactive if the user has not pressed any button for the defined period. On a workstation, the same
principle shall apply. In the case where the user is another system or a utility, such as an automatic
monitoring or extraction tool that periodically accesses the system for data gathering, the criteria for
inactivity may be different according to the protocol used and the needs of the system or utility. In a similar
manner the defined period of inactivity may be different for different users. On an HMI it may be in the
order of minutes whereas a system-to-system access may impose an inactivity period of just a few seconds.
It is permissible to allow these periods to be configurable by a user or by a system configurator.
The handling of the close-down and termination of any applications or activities that the user was executing
prior to the inactivity termination being enacted are outside the scope of this standard. However, if such
applications or activities were themselves part of an ongoing cybersecurity operation, such as an update to a
password, the termination of that operation shall be designed so as not to compromise the device or security
system.
6.4.4 User-authentication administration
The substation owner or organization shall maintain a list of users who are permitted to have access to the
systems and devices, and shall have procedures in place that control the addition, modification and removal
of entries in the list. The substation owner or organization shall have a procedure for ensuring that users
who no longer need access are removed from the list and from the system.
There is a necessary administrative burden that accompanies the need for user authentication. It means that
there shall be a list of user identifiers that includes details of the actual user assigned to that identifier. At a
minimum these shall be as follows:
 Name
 Position
 Contact details
 Date/time that user was added to the list
Optionally, two other items may be useful to record.

 Expiration date/time of user’s identifier
 Date/time that user was removed from the list
Expiration date allows the possibility of temporarily allowing a user to have access with a definite
date/time limit on that access after which the access shall be removed (this does not imply that there is
some means by which the system is able to automatically prevent the user having access after this
date/time; it can still be done manually).
16
IEEE Std C37.240-2014
If the expiration date/time should occur while the user is logged on, the system may or may not
automatically revoke the user’s access and log the user off the system. If the system opts to leave the user
connected, the revocation of the user’s access shall occur when the user next logs off (or is disconnected by
inactivity).
Removal of users from the list and the system is important to prevent unauthorized access to the system and
devices by users such as ex-employees and contractors no longer requiring access. The date/time that user
was removed is useful to show that a user has been removed for audit purposes.
6.4.5 User-authentication logging
The substation system and devices shall maintain records of when users accessed the system and for how
long. The substation system and devices shall maintain records of failed attempts to access the system.
Monitoring of access shall be achieved through use of logs that record details of the users making the
access. The logs shall be preserved for at least 90 days and must be non-volatile, read-only, and non-
erasable by a user.
The logs shall record the following:
 The identifier of the user gaining access
 The date/time of the start of the session
 The date/time of when the session finished (and also if it ended manually or automatically due to
inactivity or due to automatic revocation through the occurrence of the date/time of expiration of
the user account)
 The interface through which the user gained access (e.g., HMI, remote through Port 1, etc.)
Failed attempts to access the system shall also be recorded in the logs to record the following:
 The identifier used to attempt access

 The date/time of the attempt
 The interface through which the user attempted access (e.g., HMI, remote through Port 1, etc.)
 The reason for the failure. These shall be as follows:
 Unrecognized identifier (not present in the list)
 Unauthorized identifier (identifier was removed from the list)
 User access expired (temporary access now ended)
 Incorrect password (not the password associated with the identifier)
 Account blocked (The user has entered several incorrect passwords and has reached the limit
of attempts allowed.)
It is not mandatory to maintain lists of user identifiers that have been removed within the devices or
systems themselves. If such a list is present in the device or system and an attempt is made to logon with an
identifier present in the list, the log entry shall show that reason as “Unauthorized Identifier.” Otherwise,
the log entry shall show the reason as “Unrecognized Identifier.”
17
IEEE Std C37.240-2014
6.4.6 User-authorization principles
The substation system and devices shall have the features and functions required so that authenticated users
are granted privileges and access control levels commensurate with the task(s) for which they are
authorized.
Privileges are very much dependent on system architecture and implementation. However, it is a principle
of good security that an authenticated user does not have more privilege than is required to perform the task
(principle of least privilege). This reduces the possibility of a user accidentally (or perhaps deliberately)
causing an incident through making unauthorized changes to which the user should have no access. For
example, a user who is tasked with monitoring certain measurements should not be granted the privilege to
change configuration.
The simplest authorization scheme is one that merely provides differing levels of access, such as having
read access or write access, without making distinction between the objects that can be read or written or
the actual tasks for which a user is authorized. In this type of scheme, a user granted read access shall be
able to read all objects. However, this is incompatible with the concept of least privilege as it may permit
such users to be able to read data to which they should not have access. For example, the user tasked with
checking measurements would also be able to read settings or event data.
A more restrictive system may impose categories on the data so that measurements are categorized
differently from settings, which are categorized differently from event data. For example, a user who is
granted access to read measurement categorized data has no access to other categories so the user cannot
read settings or event data. But this scheme brings with it new issues. How does a user who needs access to
both settings and event categories obtain it? Can such a system support multiple category privileges?
The most flexible scheme, but one providing appropriate restrictions, is one that is based on granting access
to objects and resources according to the user’s role. This is role-based access control (RBAC), which is
described in 6.4.10. This type of scheme will allow a user to have appropriate access to all the areas of the
system or device needed for a task (role), yet it restricts access to all other areas and resources.
6.4.7 User-authorization administration
The substation owner or organization shall maintain a list of the privileges of users who are permitted to
have access to the systems and devices and shall have procedures in place that control the addition,
modification, and removal of privileges in the list. The substation owner or organization shall have a
procedure for ensuring that the privileges of users can be revoked if the user no longer has a need for them.
Associated with the need to maintain a list of users and their identifiers is the additional requirement to
record the privileges that a user has been assigned. It shall be possible to modify the privileges of a user to
grant them more (or less) access as needed for their role or task.
Many authentication schemes and systems exist, ranging from a simple user list held within the device or
system to an independent user authentication server that provides the authentication service to a network of
many devices. Irrespective of which one is used the same principles shall apply.
6.4.8 Password authentication
The substation system and devices shall implement a secure and robust password scheme that incorporates
strong passwords that cannot be read from the system or be viewed by monitoring the communications
traffic within the system or between the system and an external entity.
Strong passwords shall be achieved by complying with 5.1.3 of IEEE Std 1686-2013.
18
IEEE Std C37.240-2014
The substation system shall reject a password that does not meet the robustness measures defined above
and ask the user to enter the password again. This is limited only to when the user is entering a new
password as part of a password update activity. The failed attempt shall be logged with the event reason as
“Password update failed robustness check.” The system shall not be required to limit how many failed
attempts a user may make to enter a new password, but each one shall be logged as described.
Systems and devices shall prevent passwords from being viewed, extracted, or displayed either directly or
indirectly through viewing of logs, download of settings, extraction of records, or other data transfer
mechanisms.
Passwords shall not be stored in files or documents in plain text. Where it is necessary to store a password
in a file, it shall be stored in encrypted form. The type of encryption, together with the handling of
encryption keys, is outside the scope of this standard.
Passwords shall not be transmitted through communication lines in plain text. Where it is necessary to
transmit a password, such as when logging onto a system from a remote interface, the password shall be
transmitted in encrypted form. The type of encryption, together with the handling of encryption keys, is
outside the scope of this standard.
6.4.9 Password management
Passwords shall be managed within the substation cybersecurity system such that appropriate authorization
is required to edit a password. Passwords should be regularly changed (refreshed) at intervals not exceeding
12 months.
It is expected that a user shall be able to change their password at any time when they are logged onto the
system or device. A user’s password cannot be changed by any other user unless they have the
authorization to do so (See 6.4.6). Changing a user password shall cause a suitable event to be logged with
the reason for event “Password Changed.” The event shall record the identifier of the user whose user
password was changed and the identifier of the user who changed it. The event shall not record the
passwords.
Refreshing the passwords at regular intervals protects the system against repeated attacks should a
password become known to unauthorized users. The more frequently the password is refreshed, the less
exposure there is to unauthorized access from a compromised password. However, making the frequency
too quick introduces a new set of issues. Substations may have many pieces of equipment with passwords,
and a utility may have many substations. Refreshing passwords in all the equipment in all the substations is
a logistics and management issue that should not be considered lightly, so a password-refreshing frequency
should not mandate a period that is onerous, if not impossible, to achieve. A maximum period of 12
months, however, ensures that passwords are refreshed at least once a year and is an achievable
requirement.
When changing (or refreshing) a password, there may be nothing to stop a user from making two password
changes to return the password to its current value (or even just typing in the same password again),
ensuring that the password refresh requirement is met but not actually achieving the essence of the
requirement. Measures could be defined to require the system to store a defined number of previous
passwords and prevent them from being used again, but for some systems and devices this may be yet
another onerous requirement that is constrained by the storage capability of the device or system. The
policy and management of the substation security shall include directives to forbid use of previous
passwords. Where a device or system does have the capability to store previously used passwords, it is
mandated that the device or systems shall preserve, as a minimum, the last two passwords used and store up
to a maximum of eight previously used passwords.
19
IEEE Std C37.240-2014
6.4.10 Role-based access control
6.4.10.1 Background
The role-based access control (RBAC) model as defined by ANSI INCITS 359-2004 describes roles in line
with the organizational structure and processes of electrical users.
6.4.10.2 Compliance
Energy systems implementing RBAC in computers and devices shall be compliant with both IEC 62351-8
and with the IEEE Std 1686.
6.4.10.3 Number of roles
At least four roles shall be employed.
6.4.10.4 Central management
The roles shall be managed centrally.
6.4.10.5 Areas of responsibility
The system shall support the areas of responsibility. These areas of responsibility shall be reflected as
security-perimeter levels and aligned with the overall security policy.
The roles shall be distributed across the entire security perimeter. The roles shall be consistent within all
the different devices. Roles shall be the consistent means by which, if the separation of responsibility exists
at the process level in the security perimeter, and this shall be reflected within the role definition. For
example, a maintenance engineer could be authorized to configure a device at a certain voltage class and be
only authorized to read the configuration at another voltage class of the same substation.
6.4.10.6 Time limitation
The roles shall have no limitation of time as it is reflecting the organization, but an individual assignment
of different roles shall be assessed on a regular basis defined by the internal security policy and procedure
as defined by NISTIR 7268 SG-IA1.
6.4.10.7 Multiple-role assignments
In the case of multiple-role assignments to an individual (it is possible in the model as defined in
ANSI INCITS 359-2004), it shall be demonstrated that there is no conflict in the rights definition. In other
words, if an individual has Role A and Role B, it shall be demonstrated that, if Role A authorizes an
individual to perform Action1, Role B does not prohibit Action1.
20
IEEE Std C37.240-2014
6.4.10.8 System access
The system shall have no backdoor access points. A backdoor access point is typically an access
mechanism embedded in the system by the vendor or programmer that is not documented.
6.5 Data-in-motion protection
A cybersecurity zone is a physical boundary in which the security posture of the assets/devices contained
within that zone is homogeneous. All data that moves from one zone of cybersecurity to another shall be
encrypted. Serial connections shall comply with IEEE Std 1711. Network communications shall employ
transport layer security (TLS). Data that moves totally within a single zone of cybersecurity may be sent
unencrypted.
6.6 Configuration management
6.6.1 Device-configuration management
The purpose of central configuration management is to provide control of the configuration of devices that
are on the substation network. Control of configuration includes management of who and what has access
to configure devices, storage of configuration and operating software/firmware for backup and recovery
purposes, and logging and alarming of configuration changes. Configuration management provides secure
access to devices and automation that allow processes to be introduced that could increase efficiency and
reduce errors that could lead to incorrect operation. Configuration-management systems shall have the
same cyber requirements as substation devices.
Central configuration management shall provide the following:
 Storage of device configuration

 Storage of device firmware
 Detection and alarm notification of changes to device configuration
 Logging of device configuration changes
 Restoring of the archived device configuration
 Restoring of archived device firmware
 Distribution of configuration and firmware to multiple devices on the network
6.6.2 Quality assurance/auditing
It is essential to provide control over who has access to the configuration and firmware level of devices in
the substation network. Only tested and approved configurations and firmware shall be deployed in live
systems.
To avoid unauthorized personnel from accessing device configuration and firmware, the systems shall
provide the following:
 Centralized user authentication by which users are required to authenticate against a centrally
managed database to keep information up to date
21
IEEE Std C37.240-2014
 User privilege levels to allow viewing of configuration only, limited configuration, and full
configuration
 Logging of user access and configuration activities performed while logged onto the device as
defined in IEEE Std 1686
Access control management software may be used to provide the required functionality.
6.6.3 Configuration management/trusted networks and trusted devices
For authorized user identification and verification that the configuration file and firmware is received by
the correct file servers, both the user and file servers shall be authenticated through a centrally managed
database.
6.6.4 Configuration file server
The file server or software application that is providing the configuration file or device firmware file shall
be authenticated against a centralized database.
6.7 Security event auditing and analysis/incident response
6.7.1 Background
In the event that a cybersecurity incident is discovered, the user shall make a full assessment of the
situation as quickly as possible due to the following:
 The incident is unlikely to be an isolated incident

 Left unmitigated, more attacks may occur
Recovery and remediation will require the user to determine five things regarding the attack:
 Who
 What
 Where
 When
 Why
Depending on the security features of the device and administrative procedures in effect, it may not be
possible to determine all of these parameters. In such cases, consideration shall be given to upgrading IED
technology and installation/maintenance procedures to provide a better analysis of the attack. Without
understanding the who, what, where, when, and why, it will be very difficult to develop an effective
remedial plan to prevent attacks in the future.
22
IEEE Std C37.240-2014
6.7.2 Who
The source of the attack shall be identified to determine how to best prevent future attacks of this nature. If
the source is an outside agency without authorized access (direct or remote) to the device or substation,
technical solutions will be the primary remediation. If, on the other hand, the source is determined to be
someone with authorized access to the device or substation (employee, contractor, or authorized third
party), procedures such as modification of password policies, background checks, and restrictions on
laptop/configuration software use shall be reviewed.
If the technology is not available to determine who from the device itself, frequently the other parameters,
when determined, will provide some insight to the attacker’s identity. Of paramount concern will be the
situation where the attacker is identified as an employee, contractor, or authorized third party. In such
cases, the user shall consider any other sites that the attacker had access to and inspect for other similar
activity.
6.7.3 What
What the attack was (in other words, the nature of the attack) shall be thoroughly analyzed. The type of
attack will have a major impact on the recovery and remediation of the attack. For example, if data theft
(e.g., configuration upload) has occurred, the user shall determine if passwords have been compromised.
Personnel will typically reuse passwords for similar applications, and the compromising of those passwords
creates a larger issue within the user’s environment. Recovery in this instance may include the wholesale
change of all IED access configuration software passwords.
If settings have been changed to render faulty operation, the user shall examine similar devices to see if
changes have been made there as well. Also, the nature of the change may provide a clue to the source.
Subtle changes, such as raising/lowering relay target values or setpoints, may indicate a person with
specific knowledge about the user’s facilities and perhaps access to the device‘s configuration software.
Badly corrupted configurations or blindly operated points that are easily detected may suggest an outside
hacker.
6.7.4 Where
Where the attack took place is a two-fold question: where in terms of the location of the asset (e.g.,
substation location) and where in the substation (which IEDs, communications processors, gateways, etc.).
Identifying the substation itself may be important if the attack is determined to be from a threat with access
to the station. If the threat is traced to a contractor, for example, all stations in which the contractor had
access shall be evaluated for the possibility that they too have been attacked. Attacks which are limited to a
geographical area will similarly help to identify which personnel may be involved.
The other aspect is which devices in the substation have been attacked. It is important to determine the
brand, model, and firmware version of the device attacked to provide further clues on both the nature of the
attack and the probability of widespread attack elsewhere on the system. Benefits of this information
include:
 Gaps in security for various products shall be brought to the vendor’s attention for technical
remediation.
 Vulnerable devices shall be removed from the system or restricted in access by procedural means.
 Inspection of other substations can be more easily facilitated if the user knows where to look
(which devices) and what to look for
23
IEEE Std C37.240-2014
6.7.5 When
When the attack took place can be an important tool in determining who. Knowing when can allow the user
to correlate the attack with authorized personnel movement and work shifts, vendor and contractor site
activities, and hacker activity (e.g., attacks occurring from another time zone).
The attacks may also be correlated to other activities and procedures, such as the installation of new
firmware, password changes, employment changes, labor disputes/negotiations, activities, (internally and
externally), and communication system changes.
6.7.6 Why
Though not a technical issue per se, why an attack took place is an important step in the prevention of
future attacks. Opportunistic and casual attackers strive for personal gratification and to further their
causes, and little can be done other than to harden assets from a technical nature and assist law enforcement
with the apprehension of those responsible. But attacks generated by disgruntled employees, contractors, or
vendors are the most difficult to detect/prevent, and consideration shall be given to preventing situations
that would cause someone to seek redress through this method. Correlation of such attacks to cause can be
useful in the prevention of future attacks. Users can and should monitor the temperament of any personnel
(internal, contractors, vendors, system integrators, etc.) who could launch such an attack and address
concerns before they lead to cyber attacks or escalate security measures in the event that confrontation is
expected.
6.8 Security testing
Regular testing of the cybersecurity systems designed to protect the substation network environment is a
key component of any substation cybersecurity strategy. Testing demonstrates that current cybersecurity
systems are capable of defending against well-known attack methods, as well as new methods.
Testing shall include, but is not limited to, the following:
 Periodic reviews of cybersecurity policy and procedures, as related to staff, managers, executives,
and external contractors
 Independent “White Hat” penetration tests
 Physical security audits
 Periodic audit of firewall policies
 Periodic audit of software versions and patch level as related to current attack methods as well as
recently discovered vulnerabilities
 Other elements as/where required
24
I
EEE
st
andards
.i
eee.
org
Phone:+17329810060 Fax:+17325621571
©IEEE

IEEE C37240 2014 Substation Security

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IEEE C37240 2014 Substation Security

Uploaded by

Copyright:

Available Formats

IEEE Standard Cybersecurity

Requirements for Substation

IEEE Power and Energy Society

IEEE Standard Cybersecurity

Power System Relaying Committee and Substations Committee

Approved 10 December 2014

IEEE-SA Standards Board

Keywords: critical infrastructure protection, cybersecurity, electronic access, encryption,

The Institute of Electrical and Electronics Engineers, Inc.

Copyright © 2015 by The Institute of Electrical and Electronics Engineers, Inc.

PDF: ISBN 978-0-7381-9437-0 STD20046

IEEE prohibits discrimination, harassment, and bullying.

Comments on standards should be submitted to the following address:

Secretary, IEEE-SA Standards Board

Laws and regulations

Ed Cenzon Randy Hamilton Craig Preuss

William Ackerman Randall Groves Bruce Muschlitz

John Kulick, Chair

Peter Balma Michael Janezic Ron Petersen

Richard DeBlasio, DOE Representative

3. Acronyms and abbreviations ...................................................................................................................... 3

4. Use of this standard .................................................................................................................................... 4

5. Description of cybersecurity ....................................................................................................................... 4

6. Cybersecurity requirements ........................................................................................................................ 7

 NERC CIP, Critical Infrastrucure Protection. 2

3. Acronyms and abbreviations

CMA connection-monitoring authority

GOOSE generic object-oriented substation event

GIS gas-insulated substation

HMI human-machine interface

IDS intrusion-detection systems

IED intelligent electronic device

IPS intrusion-protection systems

LAN local-area network

NCIT nonconventional instrument transformer

RBAC role-based access control

RCCA remote-connection controlling authority

RIA remote IED access

RIAG remote IED access gateway

RTU remote-terminal unit

RUC remote-user community

SCADA supervisory control and data acquisition

SCS substation control system

SIPS system integrity protection schemes

SNMP simple network-management protocol

VPN virtual private network

WAMS wide-area measurement system

WAN wide-area network

4. Use of this standard

 Technical Feasibility: The cybersecurity of a substation must be technically feasible in a substation

 Operational Feasibility: Utility substations have specific operational and maintenance

5.1 Problem statements from utilities and operational challenges

5.2 Components of interest

 System/protection engineering, and maintenance (local and remotely accessed)

 Station human-machine interface (HMI)

5.3 High-level security goals

5.3.1 Foundational requirements

Table 1 —Cybersecurity program foundational requirements

5.3.2 Physical security

5.3.3 Data at rest

6.1 High level requirements and priorities for interface categories

Table 2 —Substation cybersecurity requirements mapped to NISTIR 7628*

6.2 System communications components

6.2.1 Communication network components