Dálkově řízené systémy

Oblast zaměření: Dálkově řízené systémy
Komise : IEC/TC 57 (Power systems management and associated information exchange)
Původce: ISO\IEC\CEN\CENELEC
K připomínkám do: 14.05.2019
Zobraz více Zobraz méně
 

The scope of this standard is to facilitate role-based access control (RBAC) for power system management. RBAC assigns human users, automated systems, and software applications (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;

local (direct wired) access to the object by a local and automated computer agent, e.g. another object at the field site;

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, a distributed energy resource at an end-user’s facility, or a control centre application.

While the standard 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 standard 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], and [IEEE 802.1X-2004]) in process control industry and access control ([RFC2904] and [RFC2905]) 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 revised.

Throughout the document security events are defined as warnings and incidents. 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.

It is recommended that the security warning and alarms throughout the document are implemented by log events as specified by IEC 62351-14 or by monitoring objects as 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 notion is used:

– A warning was 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.

Oblast zaměření: Dálkově řízené systémy
Komise : IEC/TC 57 (Power systems management and associated information exchange)
Původce: ISO\IEC\CEN\CENELEC
K připomínkám do: 14.05.2019
Zobraz více Zobraz méně
 

Amendment

Oblast zaměření: Dálkově řízené systémy
Komise : IEC/TC 57 (Power systems management and associated information exchange)
Původce: ISO\IEC\CEN\CENELEC
K připomínkám do: 21.05.2019
Zobraz více Zobraz méně
 

Amendment