Security Requirements for EPU Remote Services

Author: Dennis Holstein, USA

Foundational Requirements for Access Control and Use Control

Figure 7 is the use case to focus attention on the need for the CPS system of interest to provide the capabilities needed to verify remote user access to and use of EPU communication networks and the devices connected to the network. The remote endpoint device is not the human user, it is a workstation of some type and hopefully an EPU authorized device with a control identifier. A personal device is acceptable if it has been authorized by the PP&OD.
IEC 62443 and other standards focus attention on the security of the client device. CIGRE study committees B5 and D2 have published several technical brochures on the security issues associated with these devices. Of particular concern is the use of personal devices. The problem is that these devices are used in many personal activities such as surfing the Internet, downloading free software applications, and streaming videos and music. Thus, personal devices are subject to malware infections that can spread from the personal device to other devices on EPU's networks. Obviously, not a good situation.

Therefore, the enumerated list of client devices includes the key work "approved". Only EPU approved devices should be used for remote services, including those by contracted service personnel.

Table 2 is used to begin the discussion of access to and use control of the EPU's communication network. The cyber-physical security system in use is designed to meet some of the needs in Table 1 subject to the assumptions of trust stated earlier. IEC 62443 describes "foundational requirements" to establish the basis for "derived requirements". It may be beneficial to further qualify these requirements as functional requirements 'F', physical requirements 'Ph', or extended requirements 'E'.

Another interesting observation shown in Figure 8 is the relationship between use control and access control. Access control relies on the capability to ensure that all access control points have been identified and approved for secure access to the EPU's communication network (Id=5.1.1). In addition, there is a physical requirement to secure all access points in locked cabinets and facilities (Id=5.1.2).
Access control is a prerequisite for use control; i.e. the requirements for "access control" must be satisfied for "use control" to be effective. Where applicable, use control includes the need for digital certificates (Id=5.2.1) to be used to verify the permissions for any entity that has gained access to the network. This requirement imposes the need for a designated authority to verify the authenticity of the certificate (the adage of trust but verify).

Returning to Figure 7, access control identifies the need to ensure all entity identification and authentication has been verified and approved. This includes the association between the human user and remote user device. This is verified at the time when the remote user logs-on to the remote user device.

This objective introduces the concept of a binding credential (BC). In this context, a BC is defined as any mechanism that provides a link between a user and a device, based on the user's identity. In addition, BCs can be used in conjunction with biometric capabilities in personal devices to ensure the presence of the user. Such presence is offered as digital forensic evidence with a chain-of-custody (CoC). A signed access token is one example of a BC. There must be an organization that is responsible for issuing approved tokens and certificates. How this is reliably accomplished is the subject of much debate. An EPU may choose to do this by assigning the responsibility to an internal organization, and others may choose to assign the responsibility to a third-party organization. In either case, the EPU must vet the trustworthiness of the organization assigned this responsibility.
IEC 62351-8 includes the use of signed access tokens and digital certificates. The objective is to satisfy the requirements specified by ID=5.1 and ID=5.2.
However, as shown in Figure 8, this requires a use case to authenticate the credentials and permissions. The participants in this use case are the remote user, the RoU manager responsible for the assets to be accessed, and a trusted EPU authenticator. Some EPUs will task an internal organization to be the authenticator, and others will contract for this service. In either case, trust in the authentication process is critical. The "rake" symbolizes the complexity of this process, which is well beyond the scope of this article.
Be careful not to rely totally on role-based access control (RBAC) because attribute-based access control (ABAC) is equally important.

Figure 9 describes a common list of roles and permissions associated with remote services is shown. Each responsible organizational unit (engineering, maintenance, etc.) will add to this list as needed.

To satisfy the GDPR requirements discussed earlier, ABAC requirements in Figure 10 are more extensive because of the potential to expose personal identifiable information commonly used in remote service user identities. This is further exacerbated by the restrictions imposed on the location of the remote service entity; e.g., located in a restricted zone. Another ABAC feature is time of use. Many remote service support functions are, or should be, restricted. For example, contracted service personnel may only be authorized access for specified times. Maintenance personnel may also be restricted as to when they can access the networks and specific IEDs.
The combination of RBAC and ABAC with features enumerated in Figure 9 and Figure 10 is needed to provide the CPS capabilities specified in IEC 62351-8.

Relion advanced protection & control.
BeijingSifang June 2016