IEC 62351-8: 2020 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\u2019s 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: \u2013 local (direct wired) access to the object by a human user; by a local and automated computer agent, or built-in HMI or panel; \u2013 remote (via dial-up or wireless media) access to the object by a human user; \u2013 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\u2019s 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.<\/p>\n
| PDF Pages<\/th>\n | PDF Title<\/th>\n<\/tr>\n | ||||||
|---|---|---|---|---|---|---|---|
| 2<\/td>\n | undefined <\/td>\n<\/tr>\n | ||||||
| 5<\/td>\n | Annex ZA(normative)Normative references to international publicationswith their corresponding European publications <\/td>\n<\/tr>\n | ||||||
| 7<\/td>\n | English CONTENTS <\/td>\n<\/tr>\n | ||||||
| 11<\/td>\n | FOREWORD <\/td>\n<\/tr>\n | ||||||
| 13<\/td>\n | INTRODUCTION <\/td>\n<\/tr>\n | ||||||
| 14<\/td>\n | 1 Scope <\/td>\n<\/tr>\n | ||||||
| 15<\/td>\n | 2 Normative references <\/td>\n<\/tr>\n | ||||||
| 16<\/td>\n | 3 Terms and definitions <\/td>\n<\/tr>\n | ||||||
| 18<\/td>\n | 4 Abbreviated terms <\/td>\n<\/tr>\n | ||||||
| 19<\/td>\n | 5 RBAC process model 5.1 Overview of RBAC process model <\/td>\n<\/tr>\n | ||||||
| 20<\/td>\n | 5.2 Generic RBAC concepts Figures Figure 1 \u2013 Generic framework for access control <\/td>\n<\/tr>\n | ||||||
| 21<\/td>\n | 5.3 Separation of subjects, roles, and permissions 5.3.1 RBAC model Figure 2 \u2013 Diagram of RBAC with static and dynamic separation of duty (enhanced version of ANSI INCITS 359-2004) <\/td>\n<\/tr>\n | ||||||
| 23<\/td>\n | 5.3.2 Subject assignment (subject-to-role mapping) 5.3.3 Role assignment (role-to-permission mapping) Figure 3 \u2013 Subjects, roles, permissions, and operations <\/td>\n<\/tr>\n | ||||||
| 24<\/td>\n | 5.3.4 Permission assignment (mapping of actions to objects) 5.4 Criteria for defining roles 5.4.1 Policies 5.4.2 Subjects, roles, and permissions 5.4.3 Introducing roles reduces complexity <\/td>\n<\/tr>\n | ||||||
| 25<\/td>\n | 6 Definition of roles 6.1 Role-to-permission assignment inside the entity in general 6.1.1 General 6.1.2 Number of supported permissions by a role 6.1.3 Number of supported roles 6.1.4 Flexibility of role-to-permission mapping 6.2 Role-to-permission assignment with respect to power systems 6.2.1 Mandatory roles and permissions for IED access control <\/td>\n<\/tr>\n | ||||||
| 26<\/td>\n | Tables Table 1 \u2013 List of mandatory pre-defined permissions <\/td>\n<\/tr>\n | ||||||
| 27<\/td>\n | Table 2 \u2013 Pre-defined roles <\/td>\n<\/tr>\n | ||||||
| 28<\/td>\n | 6.2.2 Power utility automation using IEC 61850 Table 3 \u2013 List of pre-defined role-to-permission assignments <\/td>\n<\/tr>\n | ||||||
| 29<\/td>\n | Table 4 \u2013 LISTOBJECTS permission and associated ACSI services <\/td>\n<\/tr>\n | ||||||
| 30<\/td>\n | 6.3 Role to permission assignment for specific roles 6.3.1 General 6.3.2 Encoding specific roles <\/td>\n<\/tr>\n | ||||||
| 31<\/td>\n | Figure 4 \u2013 XACML structure <\/td>\n<\/tr>\n | ||||||
| 34<\/td>\n | 6.3.3 Evaluation context Table 5 \u2013 Evaluation Context <\/td>\n<\/tr>\n | ||||||
| 35<\/td>\n | 6.4 Role-to-permission assignment with respect to other non-power system domains (e.g. industrial process control) 7 RBAC credential distribution using the PUSH model <\/td>\n<\/tr>\n | ||||||
| 36<\/td>\n | Figure 5 \u2013 Schematic view of authorization mechanism based on RBAC <\/td>\n<\/tr>\n | ||||||
| 37<\/td>\n | 8 RBAC credential distribution using the PULL model 8.1 General <\/td>\n<\/tr>\n | ||||||
| 38<\/td>\n | 8.2 Secure access to an LDAP-enabled repository 8.2.1 General 8.2.2 PULL model with LDAP Figure 6 \u2013 Schematic view of authorization mechanism based on RBAC PULL model <\/td>\n<\/tr>\n | ||||||
| 39<\/td>\n | 8.2.3 LDAP Directory organization Figure 7 \u2013 RBAC PULL model using LDAP <\/td>\n<\/tr>\n | ||||||
| 40<\/td>\n | 8.3 Secure access to the RADIUS-enabled repository 8.3.1 General 8.3.2 PULL model with RADIUS <\/td>\n<\/tr>\n | ||||||
| 41<\/td>\n | 8.3.3 RADIUS security applying transparent TLS protection Figure 8 \u2013 RBAC PULL model using RADIUS <\/td>\n<\/tr>\n | ||||||
| 42<\/td>\n | Table 6 \u2013 Cipher suites combinations in the context of this document <\/td>\n<\/tr>\n | ||||||
| 44<\/td>\n | 8.4 Secure access to the JWT provider 9 General application of RBAC access token (informative) Figure 9 \u2013 RBAC model using OAuth2.0 and JWT <\/td>\n<\/tr>\n | ||||||
| 46<\/td>\n | Figure 10 \u2013 Session based RBAC approach (simplified IEC 62351-4 end-to-end security) <\/td>\n<\/tr>\n | ||||||
| 47<\/td>\n | 10 Definition of access tokens 10.1 General 10.2 Supported profiles 10.3 Identification of access token <\/td>\n<\/tr>\n | ||||||
| 48<\/td>\n | 10.4 General structure of the access tokens 10.4.1 Mandatory fields in the access tokens 10.4.2 Mandatory profile-specific fields 10.4.3 Optional fields in the access tokens Table 7 \u2013 Mandatory general access token components Table 8 \u2013 Mandatory profile specific access token components Table 9 \u2013 Optional access token components <\/td>\n<\/tr>\n | ||||||
| 49<\/td>\n | 10.4.4 Definition of specific fields <\/td>\n<\/tr>\n | ||||||
| 51<\/td>\n | Table 10 \u2013 AoR fields and format <\/td>\n<\/tr>\n | ||||||
| 52<\/td>\n | 10.5 Specific structure of the access tokens 10.5.1 Profile A: X.509 Public key certificate <\/td>\n<\/tr>\n | ||||||
| 54<\/td>\n | 10.5.2 Profile B: X.509 Attribute certificate <\/td>\n<\/tr>\n | ||||||
| 57<\/td>\n | 10.5.3 Profile C: JSON Web Token \u2013 JWT Table 11 \u2013 Mapping between ID and attribute certificate <\/td>\n<\/tr>\n | ||||||
| 59<\/td>\n | 10.5.4 Profile D: RADIUS token <\/td>\n<\/tr>\n | ||||||
| 61<\/td>\n | 11 Transport profiles 11.1 Usage in TCP-based protocols <\/td>\n<\/tr>\n | ||||||
| 62<\/td>\n | 11.2 Usage in non-Ethernet based protocols 12 Verification of access tokens 12.1 General 12.2 Multiple access token existence 12.3 Subject authentication <\/td>\n<\/tr>\n | ||||||
| 63<\/td>\n | 12.4 Access token availability 12.5 Validity period 12.6 Access token integrity 12.7 Issuer 12.8 RoleID <\/td>\n<\/tr>\n | ||||||
| 64<\/td>\n | 12.9 Revision number 12.10 Area of responsibility 12.11 Role definition 12.12 Revocation state 12.13 Operation 12.14 Sequence number <\/td>\n<\/tr>\n | ||||||
| 65<\/td>\n | 12.15 Revocation methods 12.15.1 General 12.15.2 Supported methods <\/td>\n<\/tr>\n | ||||||
| 66<\/td>\n | 13 Conformity 13.1 General 13.2 Notation 13.3 Conformance to access token format 13.4 Conformance to access token content 13.5 Access token distribution Table 12 \u2013 Conformance to access token format <\/td>\n<\/tr>\n | ||||||
| 67<\/td>\n | 13.6 Role information exchange 13.7 Mapping to existing authorization mechanisms 13.8 Security events 14 Repository interaction for the defined RBAC profiles Table 13 \u2013 Conformance to access token distribution <\/td>\n<\/tr>\n | ||||||
| 68<\/td>\n | Table 14 \u2013 Profile comparison <\/td>\n<\/tr>\n | ||||||
| 69<\/td>\n | Annex A (informative)Informative example for specific role definition A.1 Scope of annex A.2 Use case description A.3 XACML definition example Table A.1 \u2013 Permission assignment <\/td>\n<\/tr>\n | ||||||
| 70<\/td>\n | A.4 Role description <\/td>\n<\/tr>\n | ||||||
| 71<\/td>\n | A.5 Permission group description <\/td>\n<\/tr>\n | ||||||
| 72<\/td>\n | A.6 Permission description <\/td>\n<\/tr>\n | ||||||
| 75<\/td>\n | A.7 Request syntax for PDP <\/td>\n<\/tr>\n | ||||||
| 77<\/td>\n | Bibliography <\/td>\n<\/tr>\n<\/table>\n","protected":false},"excerpt":{"rendered":" Power systems management and associated information exchange. Data and communications security – Role-based access control for power system management<\/b><\/p>\n |