DD IEC/TS 62351-8:2011 - Page 2

Power systems management and associated information exchange. Data and communications security. Role-based access control | Status: Current

1 Scope This technical specification covers the access control of users and automated agents – in the following subjects – to data objects in power systems by means of role-based access control (RBAC). RBAC is not a new concept used by many operating systems to control access to system resources. RBAC is an alternative to the all-or-nothing super-user model. RBAC is in keeping with the security principle of least privilege, which states that no subject should be given more rights than necessary for performing that subject’s job. RBAC enables an organization to separate super-user capabilities and package them into special user accounts termed roles for assignment to specific individuals according to their job needs. This enables a variety of security policies, networking, firewall, back-ups, and system operation. A site that prefers a single strong administrator but wants to let more sophisticated users fix portions of their own system can set up an advanced-userrole. RBAC is not confined to users however, it applies equally well to automated computer agents, i.e., software parts operating independent of user interactions. The following interactions are covered by the scope of this technical specification:

• – local (direct wired) access to the object by a human user;
• – local (direct wired) access to the object by a local and automated computer agent, e.g. another object at the substation;
• – direct access by a user to the object using the objects’ 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, or a control centre application.

As in many aspects of security, RBAC is not just a technology; it is a way of running a business. As subject names change more frequently than role names and as role names change more frequently than the rights of a data model (e.g. IEC 61850), it is advisable to store the frequently changing entities (i.e. the subjects names) outside the object. Less frequently changing role names and rights are stored inside the object. RBAC thus provides a means of reallocating system controls as defined by the organization policy. The scope of this specification covers everything that is needed for interoperability between systems from different vendors. The purpose of this specification is therefore:

• – firstly, to introduce ‘subjects-roles-rights’ as authorization concept;
• – secondly, to promote role-based access control for the entire pyramid in power system management; and
• – thirdly, to enable interoperability in the multi-vendor environment of substation automation and beyond.

Out of scope for this specification 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 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 These issues will be addressed in IEC/TS 62351‑91.

The IEC 62351 series specifies end-to-end security in power systems so that secure connections are established between applications. RBAC is recognized as a potentially efficient and safe means to control access to data objects. Existing standards (see [ANSI INCITS 359-2004], [IEC 62443], and [IEEE 802.1X-2004]) in the process control industry and access control ([RFC2904] and [RFC2905]) are not sufficient as none of them specify either the exact role name and associated rights, the format of the access tokens or the detailed mechanism by which access tokens are transferred to and authenticated by the target system – however, all this information is needed though for interoperability.