Standards Development

Scope

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 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 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. Moreover, additionally to the definition of custom roles based on associated permissions, this document also includes to assignment of permissions to objects in the IEC 61850 data model, to ensure an interoperability also for custom defined roles. For this this document relies on IEC/TR 61850-90-19.

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 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-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 should provide a mechanism for announcing security events.

The information about the 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.

Note that notice, 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 may indicate unauthorized activity. It may not require immediate action.

–        An alarm is an indication of a serious problem, which may indicate unauthorized activity. Action is recommended 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.