CENELEC - EN IEC 62351-8
Power systems management and associated information exchange - Data and communications security - Part 8: Role-based access control for power system management
|Publication Date:||1 June 2020|
|ICS Code (Telecontrol. Telemetering):||33.200|
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-ornothing 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 provides thus 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 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 enduser'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.
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:
- user names and password definitions/policies
- management of keys and/or key exchange;
- engineering process of roles;
- assignment of roles;
- selection of trusted certificate 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-2004) in process control industry and access control (RFC 2904 and RFC 2905) are not sufficient as none of them specify neither the exact role name and associated permissions nor the format of the access tokens nor the detailed mechanism by which access tokens are transferred to and authenticated by the target system - all this information is needed though for interoperability.
On the other hand, IEEE 1686 already defines a minimum number of roles to be supported as well as permissions, which are to be addressed by the roles. Note that IEEE 1686 is currently being revised.
Throughout the document security events are defined as warnings and alarms. These security events are intended to support the error handling and thus to increase system resilience. It is important implementations provide a mechanism for announcing security events.
Note that for the processing of security warnings and alarms resulting from security logging events and monitoring information there exists separate documents specifying the handling. More specifically, security event handling is specified in IEC 62351-141 while the handling of monitoring objects is specified by IEC 62351-7.
Note that warnings and alarms are used to indicate the severity of an event from a security point of view. The following notions are used:
- a warning is intended to raise awareness but to indicate that it may be safe to proceed;
- an alarm is an indication to not proceed.
In any case, it is expected that an operator's security policy determines the final handling based on the operational environment.