BSI DD IEC/TS 62351-8:2011
$189.07
Power systems management and associated information exchange. Data and communications security – Role-based access control
Published By | Publication Date | Number of Pages |
BSI | 2011 | 47 |
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-user role. 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;
-
aselection 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.
PDF Catalog
PDF Pages | PDF Title |
---|---|
4 | CONTENTS |
7 | FOREWORD |
9 | INTRODUCTION |
10 | 1 Scope |
11 | 2 Normative references |
12 | 3 Terms, definitions and abbreviations 3.1 Terms and definitions |
14 | 3.2 Abbreviations |
15 | 4 RBAC process model 4.1 General Figures Figure 1 – Generic framework for access control |
16 | 4.2 Separation of subjects, roles, and rights Figure 2 – Diagram of RBAC with static and dynamic separation of duty according to (ANSI INCITS 359-2004) |
17 | Figure 3 – User, roles, rights and operations |
18 | 4.3 Criteria for defining roles |
19 | 5 Definition of roles 5.1 Role-to-right assignment inside the object in general 5.2 Role-to-right assignment with respect to power systems |
20 | Tables Table 1 – List of pre-defined role-to-right assignment |
21 | Table 2 – List of mandatory pre-defined rights |
22 | Table 3 – Pre-defined roles |
23 | Table 4 – Mandatory role-to-right mapping for service access control Table 5 – The ALLOW right Table 6 – The DENY right |
24 | Table 7 – VIEW right and associated ACSI services |
25 | 5.3 Role-to-right assignment with respect to other non-power system domains (e.g. industrial process control) 6 General architecture for the PUSH model 6.1 General |
26 | 6.2 Secure access to the LDAP-enabled service 7 General architecture for the PULL model 7.1 General Figure 4 – Schematic view of authorization mechanism based on RBAC |
27 | Figure 5 – Schematic view of authorization mechanism based on RBAC PULL model |
28 | 7.2 Secure access to the LDAP-enabled service 7.3 LDAP directory organization 8 General application of RBAC access token 8.1 General |
29 | 8.2 Session based approach |
30 | 8.3 Message based approach 9 Definition of access tokens 9.1 General Figure 6 – Session based RBAC approach |
31 | 9.2 Supported profiles 9.3 Identification of access token 9.4 General structure of the access tokens |
34 | 9.5 Specific structure of the access tokens |
38 | Table 8 – Mapping between ID and attribute certificate |
39 | 9.6 Distribution of the access tokens |
40 | 10 Transport profiles 10.1 Usage in TCP-based protocols 10.2 Usage in non-Ethernet based protocols 11 Verification of access tokens 11.1 Normative part |
41 | 11.2 Optional part 11.3 Revocation methods |
42 | 12 Interoperability 12.1 General 12.2 Supported access tokens 12.3 How to ensure backward compatibility |
43 | 12.4 How to extend the list of roles and rights 12.5 How to map this specification to specific authorization mechanisms |
44 | Bibliography |