Security Requirements for EPU Remote Services

Author: Dennis Holstein, USA

Information technology (IT) and operational technology (OT) cyber-physical security protection for remote services is a complex subject that requires equal attention be given to local laws and regulations, operating constraints, and organizational constraints imposed on an electric power utility (EPU).

In response to these constraints an EPU employs both technical and non-technical controls to securely operate and manage remote services. Figure 1 shows a typical topology for an EPU system of interest (SoI).
Two assumptions are critical for this article: 1) remote access is provisioned through one or more untrusted networks and 2) the end-point at the remote site is untrusted. The depicted reference architecture is a logical representation. Components such as network segments, network and security devices as well as power automation and control systems and devices may vary in number, features and implementation characteristics. The objective is to have an artifact and representation in place as baseline for more granular definitions, policy decisions and for the mapping to standards and regulations.

Who is the Stakeholder and What is Needed?
Our first task is to identify the stakeholders and describe the CPS capabilities for remote services that they need. In Table 1 our focus is on the EPU users and four factors that influence the deployment of an acceptable solution: 1) legal compliance, 2) governance framework, 3) remote service security, and 4) remote service security solution. We will address items 1, 2, and 4 at a high-level. More technical detail will be offered for item 3.

The need for an Adaptable Cyber-Physical Security Solution

Given the emerging privacy protection laws and regulations, the evolving critical infrastructure protection (CIP) requirements, and the use of modern technologies (such as cloud services) creates a complex landscape of challenges that must be addressed (SN-1.1).  In response to this situation, EPUs need to solicit the support of subject matter experts (SMEs) with legal, technology, and human behavior expertise to establish a governance framework (SN-1.2). In the context of remote services, a model-based systems engineering (MBSE) methodology is used in this article. We start with Figure 2, the use case to identify applicable laws and regulations the impact CPS (cyber-physical security) solutions for remote services.
Navigating the complexity of security requirements from applicable laws, regulations, standards, and guidelines is the first challenge addressed by this article. One approach used in this article, is to identify and characterize the fundamental CPS requirement objectives (not context) imposed on implementation and operation of EPU remote services.

To formalize this approach, we use a modern technique called model-based systems engineering (MBSE), which requires an introduction to the System Modelling Language (SysML) notation developed by the Open Management Group (OMG).

At this level, some relationships between requirement objectives are identified. For example, in Figure 3, EPU security policies, procedures and organizational directives (PP&ODs) should trace to local laws and regulations. Both the EU's GDPR (General Data Protection Regulation) and the NERC CIP regulations that address remote services must be satisfied. The motivation for these regulations is quite different.

  • GDPR is focused on protection sensitive personal identifiable information (PII) that is commonly used for remote service log-on verification. More on this later
  • NERC CIP is focused on protecting the bulk electric system from cyber-physical attack that impacts the reliability of the system

Interpretation of the GDPR and the CIP are significant challenges. Countries that have adopted these regulations have their own unique interpretations that are described in their governing specifications. A good example is wide variation of applying the GDPR in more than 80 countries. This situation is made more complicated in the United States where several states have applied additional constraints and enforcement regulations.
To address this issue, one approach is to look to international standards for interpretation guidance. A good example is the use of IEC 62443, a multipart standard. Figure 5 identifies two parts of this standard that are particularly important for remote services. Part 3-2 focuses attention on segmentation requirements (called zones) to isolate control systems from direct connection to a remote service terminal. Security is enabled by a modern gateway (Id=4.1.1) for cybersecurity protection. The gateway is shown as a component contained in the security zone, which is sometimes referred to as an edge device.

Requirements for the security zone should be addressed in the PP&OD, which is indicated by the containment symbol on the association. Part 2-4 includes multiple remote service requirements that are imposed on the solution provider. Both parts are well-written and should be implemented to ensure that all entities (human and device) granted access to the EPU's network have been authenticated as a trusted entity.

The center point for the model shown in Figure 4 is the remote service security objective. (Id 5). Everything is built off this security objective, which requires that all entities granted access to the EPU's networks to be authenticated as a trusted entity. Remote service CPS objectives must satisfy all applicable requirements in the PP&OD. Most importantly, the approach is to use language that can be applied to both technical controls and non-technical controls (e.g. personal staffing). This requires the analyst to pay careful attention to the relationships between fundamental CPS objectives.
Authenticating a remote user is a challenge because we assume that all users are treated as an observer untrusted until authenticated.

Figure 5 shows that an unauthorized remote user, called an observer, is commonly categorized as hacker simply trolling the network, or an agent of criminal organization seeking to steal intellectual property or disrupt the operation, or an agent of a nation state. Publications in the open literature has described many of these examples.

CIGRE study committees B5 and D2 have published several technical brochures that address the issue of an 'insider threat". If the remote user has been authenticated to access the network, the authentication includes the role authorized. For example, a role may only allow the remote user to "read" data, not to change data or initiate an operational command. Furthermore, the role may be restricted to changing selected set point values. Other roles have more extensive "read/write" privileges that can initiate an operational action.
If the authenticated remote user is trusted, but compromised, the risks are significant because the user knows the detailed operation of the system or system function. With such knowledge it is possible to interfere with, disrupt, or disable a critical function.
For this reason, all actions performed on the network need to be logged and securely reported to a defined interface for post event forensic analysis. The CPS solution deployed is responsible for logging and reporting. CIGRE technical brochure #698:2017 includes an extensive discussion on this issue in clause 2.4.

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.

More IEC 62443 Foundational Requirements

In all, IEC 62443 includes seven foundational requirements that must be satisfied by the remote service objective. Table 3 shows the list. Access control and use control were discussed previously.

Data confidentiality (Id=5.3) and data integrity (Id=5.4) bring into play the need for a manageable encryption mechanism. An effective encryption mechanism needs to minimize the processing and memory requirements for the devices performing encryption and decryption.
This is not a problem for high-powered work stations, but it can be a problem for communication network devices (switches, routers, gateways) and IED connected to the network (protective relays, pole-top devices). Equally important are the encryption key life-cycle requirements. CIGRE's technical brochure #603:2014 includes an extensive discussion of these issues in Annex M.

Summary - Lessons Learned
Although combing RBAC and ABAC models provides the needed flexibility, the problems of managing this combined system need more work, probably a new CIGRE D2 working group is needed to develop the framework for a user-friendly and cost-effective management scheme.
There are no third-party certificates that can be trusted now, and without the assumption of liability there won't be any in the future.
A trusted electronic device capable of obtaining and safeguarding electronic evidence is needed.
More specifically:
a.  The device must bind the user's identity to his/her personal device
b.   Has a core of trust that can protect the integrity of one or more electronic pieces of evidence within a trusted execution environment
c.   Ensure that only authorized entities have access to the evidence,
d.   Can witness the traceability of evidence, and
e.    Can send digital evidence to any other entity with the authority to safeguard the electronic evidence

Timely response to an event identifies the need to ensure all alarms triggered by a cyber-induced remote service event is published to an approved interface. It is important to note that simply logging these events is only a prerequisite. Publication of the logged events is needed to ensure timely response.
A standard is needed to normalize the decision process to authenticate remote access and use privileges. 

Biography

Dennis Holstein has a BS from Iowa State University and a MS degree from the University of Southern California. He worked on advanced airplane designs for the Air Force's B-70 and F-108 projects, and other military and space programs. He worked at Logicon Corp. He returned to the Aerospace Corporation participating in UCA team meetings with a focus on OOAD. Dennis later joined SRS Technologies in Newport Beach, CA as Vice-President and General Manager of a new division. In 1999, he left SRS Technologies to form OPUS Consulting Group (OCG) with John Tengdin. Dennis is actively involved in IEEE PES and CIGRE working groups. In 2006 he received the CIGRE Technical Committee Award from SC B5 and in 2015 the CIGRE B5 Outstanding Service Award.