1.1 General
The scope of this part of IEC 62351 is to facilitate role-based access control (RBAC) for power system management. RBAC assigns human users, automated systems, and software applications (collectively called "subjects" in this document) to specified "roles", and restricts their access to only those resources, which the security policies identify as necessary for their roles.
As electric power systems become more automated and cyber security concerns become more prominent, it is becoming increasingly critical to ensure that access to data (read, write, control, etc.) is restricted. As in many aspects of security, RBAC is not just a technology; it is a way of running a business. RBAC is not a new concept; in fact, it is used by many operating systems to control access to system resources. Specifically, RBAC provides an alternative to the all-or nothing super-user model in which all subjects have access to all data, including control commands.
RBAC is a primary method to meet the security principle of least privilege, which states that no subject should be authorized more permissions than necessary for performing that subject’s task. With RBAC, authorization is separated from authentication. RBAC enables an organization to subdivide super-user capabilities and package them into special user accounts' termed roles for assignment to specific individuals according to their associated duties. This subdivision enables security policies to determine who or what systems are permitted access to which data in other systems. RBAC thus provides a means of reallocating system controls as defined by the organization policy. In particular, RBAC can protect sensitive system operations from inadvertent (or deliberate) actions by unauthorized users. Clearly RBAC is not confined to human users though; it applies equally well to automated systems and software applications, i.e., software parts operating independent of user interactions.
The following interactions are in scope:
– local (direct wired) access to the object by a human user, a local and automated computer agent, or a built-in human machine interface (HMI) or panel;
– remote (via dial-up or wireless media) access to the object by a human user;
– remote (via dial-up or wireless media) access to the object by a remote automated computer agent, e.g., another object at another substation, a distributed energy resource at an end user’s facility, or a control centre application.
While this document defines a set of mandatory roles to be supported, the exchange format for defined specific or custom roles is also in scope of this document. This is achieved by defining two different encoding approaches to handle the definition of custom roles, either based on specific permissions or based on constraints to existing permissions. The definition on handling custom based roles was started in IEC 62351-90-1 and taken over into the IEC 62351-8:2020.
Moreover, additionally to the definition of custom roles based on associated permissions, this document also includes options how to assign permissions to objects in a general way.
Referencing documents will provide a mapping to a concrete data model to ensure an interoperability for standard roles used in different data models as well as for custom defined roles. Referencing documents might be standards such as IEC PAS 61850-90-19 or IEC 60870-5-7:2025 or also definitions by an operator.
Out of scope for this document are all topics which are not directly related to the definition of roles and access tokens for local and remote access, especially administrative or organizational tasks, such as:
– definition of usernames and password definitions/policies;
– management of keys and/or key exchange;
– engineering process of roles;
– assignment of roles;
– selection of trusted certification authorities issuing credentials (access tokens);
– defining the tasks of a security officer;
– integrating local policies in RBAC.
NOTE Specifically, the management of certificates is addressed in IEC 62351-9.
Existing standards (see ANSI INCITS 359-2004, IEC 62443 (all parts), and IEEE 802.1X-2020) in process control industry and access control (RFC 2904 and RFC 2905) are not sufficient for addressing specifics of power system automation as none of them specify either the exact role name and associated permissions or the format of the access tokens nor the detailed mechanism by which access tokens are transferred to and authenticated by the target system.
This is addressed in this document by defining the access token format, distribution and verification based on existing technology
Throughout the document security events are defined. These security events are intended to support the error handling and thus to increase system resilience. Implementations need to provide a mechanism for announcing security events.
The information about security events and potential detailed information can only be provided by the entity based on the availability of this information through the underlying platform or utilized components.
It is strongly recommended that the security events defined throughout the document are made available to the operational infrastructure by cyber security events as specified in IEC 62351-14 and/or by monitoring objects as specified in IEC 62351-7. Annex A provides a mapping of the defined events in this document to the notion of IEC 62351-14.
Notices, warnings, errors, and alarms are used to indicate the severity of an event from a security point of view. The following notion from IEC 62351-14 is used:
– A notice refers to a cyber security related activity during the routine use or maintenance of an entity. It does not relate to a cyber security breach or attack or deviation from the normal operating condition of an entity.
– A warning is a deviation from the normal operating condition of an entity but not necessary a cyber-attack.
– An error describes an unforeseen condition, which can indicate unauthorized activity. It might not require immediate action.
– An alarm is an indication of a serious problem, which might indicate unauthorized activity. Action is expected to be taken immediately.
In any case, it is expected that an organization’s security policy determines the final handling of events based on the operational environment. For instance, the assessment of one of more alarms could rise to the level of an incident.
1.2 Published versions of the standard and related namespace names
Table 1 provides a reference between all published editions, amendments or corrigenda of this document and the full name of the namespace.
Table 1 – Published versions and related namespace names [...]
1.3 Identification of the code component
The code components associated with this document are XACML examples in XML files for the definition of custom based roles as well as example LDAP schema as LDIF files as well as the definitions for RBAC access tokens for profile A and B as ASN file and Profile C as JSON file.
The parameters which identify the code components are provided in Table 2: Table 2 – Attributes of the IEC 62351-8 code component [...]
Note that the code components do not provide an own namespace and rather rely on the XACML namespaces defined in the associated W3C specification.
1.4 Code Component distribution
Each Code Component is a ZIP package containing the electronic representation of the Code Component itself, with a file describing the content of the package (IECManifest.xml).
The life cycle of a code component is not restricted to the life cycle of the related publication. The publication life cycle goes through two stages, Version (corresponding to an edition) and Revision (corresponding to an amendment). A third publication stage (Release) allows publication of Code Component in case of urgent fixes of InterOp Tissues, thus without need to publish an amendment.
Consequently, new releases of the Code Component may be released, which supersedes the previous release, and will be distributed through the IEC TC 57 web site at:
https://www.iec.ch/tc57/supportdocuments
The latest version/release of the code component will be found by selecting the file for the code component with the highest value for VersionStateInfo, e.g. IEC_62351-8.ASN1-JSON-XACML-LDIF-Examples.{VersionStateInfo}.full.zip.
The code components associated with this IS are XACML example files for the definition of custom based roles. It is available as a full version only. It is freely accessible on the IEC website for download at https://www.iec.ch/tc57/supportdocuments, but the usage remains under the licensing conditions.
In case of any differences between the downloadable code component and the IEC pdf published content, the downloadable code component is the valid one; it might be subject to updates. See included history files.
