Cybersecurity requirements for PACS and the resilience of PAC architectures

Introduction

Leverage pevious studies

WG B5.66 is a continuation of earlier study committee B5 and D2 working groups, specifically JWG B5/D2.46[1], WG B5.38[2], WG D2.31[3], WG D2.38[4], and WG D2.40[5]. The scope of work for B5.66 includes updates to the assessments and supporting data in Technical Brochure 427[2] and documents the analysis and findings of challenges to conform to the security requirements offered in selected standards that address internet protocol (IP)-based systems. To support the findings and recommendations the analysis identified actionable metrics for specific use cases, technical approaches that leverages the cybersecurity protection offered by time sensitive networking (TSN), and advanced technologies to improve access and use control during maintenance and testing. Lastly, looking to the future, an assessment of the benefits and challenges to migrate protection , automation, and control system (PACS) applications and telecom services to a cloud-based environment is described.

Within scope, the Technical Brochure (TB) introduces two emerging topics that should be of interest to PACS manager and solution providers.

• Governance requirements for algorithmic transparency.
• Migration strategies to leverage cloud computing services.

Due to page limitations, only a few of the topics address in the Technical Brochure are included in this summary. In addition to the those summarize here, following is a complete list of the topics included in the Technical Brochure.

• Update to TB 427 recommendations.
• Leveraging other work contained in standards, reports, and special publications.
• A review of the critical infrastructure and it dependency on the user and situation.
• The need to enforce security robustness.

• Why PACS security needs transparency.
• The potential migration to cloud computing services.

The challenge 

Forcasting the evolving threat landscape, advances in technologies to mitigate the potential consequences of these threats, and the imposition of emerging local laws and regulations created multiple issues for WG B5.66 subject matter experts (SMEs). As noted in the grid architecture of the future[6], a new paradigm is needed to address the issues over the near term (next 10 years) and the long term (next 20 years). For the two planning horizons estimates of the impact on electric power utility (EPU) cybersecurity policies, procedures, and organization directives (PP&OD) needed attention to improve the security posture of PACS operations. For example, in the near term the architecture and capabilities needed to implement an integrated security operation center (ISOC) and the technical skills of ISOC personnel were addressed.

Our technical approach

Based on WG B5.66’s assessments and supporting data in existing standards, Technical Brochures, and open source documentation a portrait of the emerging threat landscape was developed with particular attention paid to common PACS deployments. Overlaid on this portrait was the imposition of emerging laws and regulations. From this assessment it was clear that a dramatic sea change will be required to modernize existing EPU policies, procedures, and organizational directives. Each impact was associated with recommended solutions to improve the security posture of PACS operations. For example, the capabilities needed to implement an integrated security operation center (ISOC) were the center of attention and it became clear that the special personnel skills and advanced analytical tools are badly needed.

A well-defined model-based system engineering (MBSE) process was used to define black box and white box problem domain views of selected PACS-centric systems of interest. For this purpose, a commercial tool based on the Open Management Group (OMG) system modelling language was selected. The tool was used to construct business process modes to visualize the processes and their interaction between EPU organizations. The models were used to capture:

• The actors involved in the system of interest and information flow among them.
• The relevance of the information to humans or device entities receiving the information.
• The use of the information in terms of action taken.
• The quality of the information needed to perform the action taken.

System model constructs were used to identify the need to satisfy specific laws and regulations. In response, it was clear that PACS centric policies, procedures, and organizational directives changes were needed to seamlessly integrate security and data protection into their normal operations. For example, the models exposed the need for a combined role-based and attribute-based access control management plan.

Download on e-cigre

Technical Brochure 790

here

Framework for this Technical Brochure

Definition of the problem domain is critical

The importance of decision support and situational awareness for system operators is becoming more prominent as significant changes in the way systems need to be operated and controlled occur. Improved situational awareness at all control levels is necessary to ensure that operational decisions are properly made and executed, which is critical for maintaining the integrity of system operations. Therefore, while operators will remain at the core of grid operations, it is becoming more and more important that they are supported by advanced data-analytics and visualization tools [7].

An electric power utility must consider a wide range of operational PACS issues to manage the stability of their system and provide reliable power to their customers [8]. In this Technical Brochure, it is not practical to address the application and management of cybersecurity for the full range of applications. Future working groups will address the application and management of cybersecurity mechanisms for system control and data acquisition (SCADA) and network control for power system operation.

Focus on situational Assessment

One implementation of PACS is wide area protection, which will be the use case to illustrate the model-based system engineering (MBSE) methodology used by the authors of this TB.  Zachman’s life-cycle framework[9], MBSE is used to develop a formal specification of PACS. Figure 1 describes the data flows, processing, and control actions for wide-area protection and automation control system (WPACS)[10]. The concept of a WPACS is explained with the help of Figure 1, where typical PAC equipment are mapped onto a traditional SGAM (smart grid architecture model) matrix[6]. This matrix correlates the traditional four electrical sectors of (from left to right at the bottom) generation, transmission, distribution and consumer (including producers) with six hierarchical layers of operation named (bottom-up) as process, field, station, operation, enterprise and market levels. These levels are currently served by four layers of utility telecommunication networks named (bottom-up from the power network) as process, station, corporate and external network, shown on the left part of the picture.

WPAC is comprised of sensors, merging units, and phasor measuring units (PMU) at the field level, that collect data and sample values (SV), and act also as control units for equipment at the process level, using the process network. These data (including phasors) are transmitted and processed by phasor data concentrators (PDC) and intelligent electronic devices (IED) at the station level, using the station network, while transmitting direct command and trips to the process level.Phasor and status data are sent upward from the station level to super PDC (SPDC) at the operation level, using the corporate network, where wide-area IED (WIED) take wide-area protection decisions based on a system-side estimation, sending back trips and commands to the station level.These SPDCs and WIEDs also send reports to upper (national or area) control centers, at the market level, using the external network, where decisions about wide-area relay settings, trips and controls are sent back to the corporate level.

See a larger image

Target audience stakeholders

The target audience for this Technical Brochure includes protection engineers, field technicians, and managers of PAC systems. They understand the technical cybersecurity controls for access to and use of PAC systems. Given this audience, it is important to describe cybersecurity technical controls in their language. For this study, Table 1 describes seven stakeholder needs (SN) used to analyze the problem domain from a white box and black box perspective.  

See a larger image

Critical infrastructure depends on the user and situation

What is needed for Disaster recovery operations

During October 2017, Osterman Research conducted a survey of 125 organizations that have between 201 and 2500 employees. To qualify for the survey, organization had to have deployed a disaster recovery solution, have established disaster recovery practices, and the individual surveyed at each location had to be knowledgeable about disaster recover solution and processes[11]. A summary of the conclusion reached from this survey are an important part of the resilience issues.

• [EPU] organizations must have a way to recognize and recover from the various events that can take down key information technologies (IT) [and operation technologies (OT)] systems, sometimes at a moment’s notice.
• Ideally, decision makers will implement a disaster recovery capability that makes outages as invisible as possible to end-users.

From an EPU resilience point of view, the key findings from Osterman’s survey are:

• Recovery point objectives and recovery time objectives are getting substantially shorter over time, indicating that rapid recovery from outages of various types is becoming a higher priority for decision makers. Moreover, not only are decision makers focused on rapid recovery from failures, but also the need to lose as little data as possible is becoming a higher priority.
• There are multiple drivers for implementing robust disaster recovery capabilities, but the ability to recover from ransomware attacks is an “absolutely essential” role for disaster recovery by a substantial proportion of decision makers. 
• Disaster recovery that enables full access to all business applications [and operational applications] within a very short period is viewed as essential by a growing proportion of decision makers.
• Getting budget approval for disaster recovery initiatives is generally easier after a major weather, ransomware or similarly damaging event.
• Disaster recovery solutions are increasingly moving to the cloud at the expense of on-premises solutions, but most organization have implemented hybrid solutions that combine the best elements of both.

Ideally, the goal for PACS disaster recovery is zero downtime and zero data loss. To approach this goal, EPU’s need a continuity disaster recover (CDR) strategy. A successful CDR strategy should focus attention on the requirements to avoid downtime and a well-tested action plan to ensure quick recovery with minimal data loss.

Possible use of cloud-based services for disaster recovery

Understanding the threat landscape that impacts PACS operation is essential. Not all threats have the objective to interfere with, disrupt, or disable PACS operations. Thus, based on a risk assessment, the responsible organizational unit (ROU) needs to prioritize the potential impact. Regular and often backup of data at high-risk should be included in the ROU’s response to the PP&OD requirements.

Another approach is to use a purpose-built disaster recover-as-a-service (DRaaS) cloud provider. In this case, purpose-built needs to be carefully tailored to the PACS risk assessment and priorities. It is up to the ROU to ensure that the service level agreement (SLA) is acceptable.

Disaster recovery introduces the need for access controls that minimize complexity and response time. One approach is to use federated identity management (FIM)[13, 14]. Identity federation links a user’s identity across multiple security domains, each supporting its own identity management system. When two domains are federated, the user can authenticate to one domain, and then access resources in the other domain without having to log in a second time. 

Identity federation offers economic advantages, as well as convenience, to enterprises and their network subscribers. For example, multiple EPU organizational units can share a single application, with resultant cost savings and consolidation of resources. Single sign-on (SSO) is a vital component of identity federation, but it is not the same as identity federation. 

For FIM to be effective, the partners must have a sense of mutual trust and clearly defined liability. Authorization messages among partners in an FIM system can be transmitted using Security Assertion Markup Language (SAML) or a similar extensible markup language (XML) standard that allows a user to log on once for affiliated but separate cloud-based services or networks.

Performance measures of effectiveness

The measure of effectiveness (MoE) of an automated protection/detection system is speed of response measured as the time to containment and remediation. How well security information and event management (SIEM) analytics adjust to false-positives is critical to avoid overload in the system. To be successful, an endpoint security suite must balance prevention, detection, and control/remediation.

The objective is to verify that the cyber-physical security (CPS) solution is capable of detecting, preventing, and continuously logging threats accurately, while remaining resistant to false positives. Third party testing is recommended to obtain an unbiased assessment of the CPS solution. These tests should utilize real threats and attack methods that are being used by cybercriminals and other threat actors, based on attacks collected from a recognized global threat intelligence network. As described in the NSS Labs test methodology, using automated and manual threats, three key capabilities need to be stress-tested.

1. Inbound threat detection and prevention (prior to execution),
2. Execution-based threat detection and prevention (during execution), and
3. Continuous monitoring post-infection and ability to act in the event of compromise (post-execution).

Why PACS security needs transparency

As demonstrated in [15] transparency is a well-researched topic. The same cannot be said about addressing the topic of transparency requirements engineering. Of concern is the lack of models and rigorous methods needed to manage deployed transparency processes. In the context of PACS security, this Technical Brochure introduces a model-based systems engineering (MBSE) approach that can be tailored for highly-automated PACS operational environments. The benefits of this approach are:

• They limit the scope of analysis to ensure focus on the system of interest; e.g., PACS.
• They provide a rigorous (well-formed) foundation for solution providers to gracefully design and implement a recommended logical design.

Emerging local laws and regulations, such as the North Americal Electric Reliability Corporation (NERC) critical infrastructure protection (CIP) [16, 17] and the European Union (EU) general data protection regulation (GDPR)[18], impose security and privacy constraints that must be addressed. Some of these constraints are discussed in a specific context in the Technical Brochure.

Transparency can be divided into three main categories, which represent how meaningful the provided transparency is [15]. Table 2 is an enumeration (“E” symbol in the Name column) of the high-level capabilities needed. The last column in the table describes the preferred verification method. To perform verification, a comprehensive black-box and white-box analysis is needed, but this analysis is well beyond the scope of this Technical Brochure. Therefore, a future working group is needed to develop the appropriate MBSE models for analysis. In the interim, attention is next focused on PACS algorithmic transparency.

See a larger image

As various facets of EPU operations come to adopt algorithmic decision-making (ADM) it raises questions of how to maintain accountability and responsibility for those decisions, particularly when they can have a negative impact on individuals. Advanced secondary systems such as those conforming to IEC standards 61850 and 62351 need to ensure that personal data and mission critical data used in the ADM process are transparent so that those responsible organizational units can monitor, check, criticize, or intervene in those processes.

The ACM US Public Policy Council and the ACM Europe Council statement on algorithmic transparency and accountability[19] was tailored for the scope and objective of this TB. This set of principles is intended to support the benefits of ADM while addressing concerns applicable to PACS management. These principles should be addressed by PACS ROUs during every phase of PACS development and deployment to the extent necessary to minimize potential harms while realizing the benefits of ADM.

Awareness: EPU ROUs and supporting solution providers of PACS should be aware of the possible biases involved in their design, implementation, and use and the potential harm that biases can cause to individuals and the EPU’s intellectual property.

Access redress: Commensurate with EPU policies, procedures and organizational directives (PP&OD), EPU’s should adopt mechanisms that enable questioning and redress for individuals and groups that are adversely affected by algorithmically informed decisions.

Accountability: EPUs should note in their PP&OD that they will be held responsible for decisions made by the algorithms that they use, even if it is not feasible to explain in detail how the algorithms produce their results.

Explanation: EPU PACS and organizational units that use ADM should include approved documentation explaining both the procedures followed by the algorithm and the specific decisions that are made.

Data provenance: EPU PACS and organizational units that use ADM-learning mechanisms should include approved documentation describing the way in which the training data was collected and maintained with an exploration of the potential biases induced by the human or algorithmic data-gathering process. EPU documentation should include a note describing concerns over privacy, protecting intellectual property, or revelation of analytics that might allow malicious actors to game the system; thus, justifying EPU’s restricting access and use control of PACS to qualified and authorized individuals.

Auditability: Models, algorithms, data, and decisions should be recorded in approved EPU documents, so they can be audited in cases where harm is suspected.

Validation and testing: EPUs should require organizational units responsible for PACS management to use rigorous methods to validate their models and document those methods and results. They should routinely perform tests to assess and determine whether the model generates discriminatory harm.

Summary of findings & recommendations

Some of the key take-way points from the work in the TB are:

• Most findings in cigre’s Technical Brochure #427[2] still holds true, but the introduction of security measures such as the use of IEC 62351 is much slower than expected. GDPR and similar local laws and regulations are expected to solve several of the remaining issues related to the protection of personal identifiable information.
• Migrating selective PACS applications and telecommunication services to a cloud-based environment is a complex and speculative undertaking which introduces an additional set of risks, namely those associated with the cloud service provider (CSP) or amplifies pre-existing ones into the PACS ongoing due diligence duties. With an absence of comprehensive performance standards and metrics, the schedule and costs risks are substantial. For these reasons, an EPU must carefully weigh the financial and operation benefits of engaging a CSP against their risk tolerance and willingness to fund negative outcomes.
• Data protection impact assessment (DPIA) needs to be well designed and practiced ensuring the proper balance between the legitimate needs of PACS management and employee rights to privacy.
• Commercial tools are available to employ a PACS-centric data management platform (DMP), also referred to as a unified data management platform (UDMP), for collecting and analyzing large sets of data originating from disparate sources.
• Commercial solutions are available use a standards-based specification for security-smart data objects (SSDO) that are data-label aware with services based on that awareness. When properly implemented SSDO provides differential access and use control that is independent of network configuration.
• This Technical Brochure has reinforced the realization that security is closely interconnected with other properties of PACS and should be integrated into existing analysis rather than performed separately. Toward this end, an enhanced assurance case methodology to analyze and communicate security explicitly is needed so that cybersecurity aspects are considered with other PACS critical system properties within a security-informed use case.
• When technically feasible, segregate PACS networks from non-PACS OT and IT networks. Engineering workstations capable of programming PACS controllers should not be dual-homed to any other process control or information system network.
• Leverage hardware features that provide for physical control of the ability to program PACS controllers. This could take the form of switches controlled by a physical key. These keys should not be left in the PROGRAM or CONFIGURATION mode other than during scheduled events.
• Utilize a unidirectional gateway rather than bidirectional network connections for any applications that depend on the data provided by the PACS.
• Time sensitive networking is an interoperable deterministic ethernet solution that the smart grid may benefit from its interoperability. However, there are some specific security vulnerabilities, like potential attacks to the synchronization plane and to the real-time traffic that should be considered. Also, more work is needed to determine the extent of redesign needed to accommodate the definition of selected points and variable timing specifications.
• Prototype deployment of hybrid solutions coupling private and public cloud architectures for PACS applications and telecommunications needs more study to fully understand the challenges and risks. Information gained from study prototype deployments needs to be captured in use cases to provide enough guidance to EPUs considering this solution to improve PACS resilience.
• Smaller utilities need a similar capability that is affordable and less reliant on the need for their PACS employees to have these unique skills. For smaller utilities a federated security operations center (FSOC) based on a hybrid SDN architecture and cloud-based services may be attractive. More work is needed to explore these benefits and challenges.
• A Technical Brochure is needed to address the need for an “escape clause” in the policies, procedures, and organizational directive. Such an escape clause is needed to establish the rank order safety, security, etc. For example, IEC 62443[20] and IEC/dTR 63069 prioritizes safety over security. In other words, safety requirements must be satisfied to avoid harm to person, property, or the environment. Another example is emergency actions required to restore critical service. In this case emergency procedure over-ride security requirements.

Conclusions

The Technical Brochure offers an in-depth view of selected issues, benefits and concerns of proposed solutions that should be considered by EPU security teams to improve the resilience of PACS architectures. These focus on the need for improved people skills, dramatic changes to policies, procedures, and organizational directives to assign responsibility and accountability for maintaining a mature PACS security posture, and the use of advanced technologies and tools to implement a proactive or anticipatory security strategy.

Bibliography

1. CIGRE GTC B5/D2.46, "Application and Management of Cybersecurity Measures for Protection and Control," CIGRE, BT 603, décembre 2014.
2. CIGRE GT B5.38, "The impact of implementing cybersecurity requirements using IEC 61850," BT 427, août 2010. 978-85873-115-2
3. CIGRE GT D2.31, "Security architecture principles for digital systems in Electric Power Utilities," CIGRE, BT 615, avril 2015.
4. CIGRE GT D2.38, "Framework for EPU operators to manage the response to a cyber-initiated threat to their critical infrastructure", CIGRE, BT 698, septembre 2017. 978-2-85873-401-6
5. CIGRE GT D2.40, "Remote service security requirement objectives," CIGRE BT 762, March 2019. ISBN : 978-2-85873-464-1
6. "Grid Architecture - shaping our energy future". IEEE power & energy [Technical]. septembre/octobre 2019)
7. CIGRE GTC D2/C2.41, "Advanced Utility Data Management and Analytics for Improved Operation Situation Awareness of EPU Operations", BT 732, 2018.
8. CIGRE GTC C2/C4.37 "A proposed framework for coordinated power system stability control". ELECTRA [Technical]. 25-35. (decembre 2018) : http://www.cigre.org
9. J. A. Zachman, "A framework for information systems architecture," IBM systems journal, vol. 38, pp. 454-470, 1999. https://www.research.ibm.com/journal/sj38-23.html
10. Iony_Patriota_de_Siqueira, "Wide-area protection and automation control system," D. holstein, Ed., wholistic view of wide-area protection and automation control system ed, 2018.
11. Osterman_Research, "Understanding the critical role of disaster recover,", janvier 2018.: https://www.ostermanresearch.com/home/white-papers/,
12. S. Baumgärtner, T. Petersen, et J. Schiller, "The Concept of Responsibility: Norms, Actions and Their Consequences," p. 54, 4 avril, 2018. https://ssrn.com/abstract=3157667
13. Z. G. Mburu, L. Nderu, et M. Tobias, "REVIEW OF DIGITAL IDENTITY MANAGEMENT SYSTEM MODELS," International Journal of Technology and Systems, vol. 4, pp. 21-33, 2019.
14. G. K. Neil Wynne, "Critical capabilities for identity and access management as a service worldwide," Gartner, Inc., Rapport, 29 septembre 2016, ID: G00299338.
15. M. Hosseini, A. Shahri, K. Phalp, et R. Ali, "Four reference models for transparency requirements in information systems," Requirements Engineering, vol. 23, pp. 251-275, 2018. Accès: 'https://link.springer.com/content/pdf/10.1007/s00766-017-0265-y.pdf
16. "Petition of the NERC for approval of CIP reliability standards", version 5, NERC, 31 janvier 2013.
17. North American Electric Reliability Corporation, "Critical Infrastructure Protection (CIP) standards," ed.
18. "The EU general data protection regulation (GDPR)". New York, NY: Springer Berlin Heidelberg, 2017.
19. ACM US Public Policy Council et ACM Europe Council, "Statement on algorithmic transparency and accountability," www.acm.org/public-policy, Government Document 2017. www.acm.org/public-policy
20. TC 65 WG 10, "IEC 62443-2-4:2015 Industrial communication networks - Network and system security - Part 2-4: Installation and maintenance service providers," 1.0 ed. Geneva CH: International Electrotechnical Commission, 2015-06-30, p. 193.