Call for Research Proposals

Call for Proposals: Center for Infrastructure Trustworthiness in Energy Systems

Proposals due 29 September 2023

The Center for Infrastructure Trustworthiness in Energy Systems (CITES) is an NSF supported University/Industry Cooperative Research Center (I/UCRC)*, established in mid-2021. CITES is offering here its third Call For Proposals. Responders are restricted to faculty and staff members of CITES member universities (University of Illinois Urbana-Champaign, University of Arkansas, Florida International University). Proposals are sought that address one or more of the ‘Needs Assessment’ areas that have been established for this call by the CITES board of member industries.

These areas are:

  • Zero-trust Networking 
  • Operational Technology System Architecture 
  • Secure Software Development and Lifecycle
  • Interacting Systems 
  • Energy System Protection 
  • Data Trust and Integrity 
  • Secure Digital Infrastructure for Energy 

Please review the ‘CITES 2023 Needs Assessment’ below for more complete description of these areas and representative samples of potential projects, and suggestions by the CITES Industry Advisory Board. Please also note that the IAB expresses considerable interest in the application of methodologies (such as formal methods) to problems in these areas, and that CITES can help researchers who are expert in these areas but not conversant in energy trustworthiness to find conversant partners.

On 7 September 2023, 12:30-2 CDT we hosted a webinar describing the program and answering any questions potential respondents had. 

7 September 2023 Webinar and Q&A recording:

A recording of the webinar is currently available to view on Illinois MediaSpace by clicking this link.

Proposals should be formatted as follows:

  • Abstract (100 words). 
  • PIs, affiliations, and contact information.
  • Identity of Needs Assessment area(s) addressed. 
  • Project description (approximately 5 pages). 
  • Project duration (6 months, 1 year, 1.5 year, 2 year), and quarterly milestones (e.g., 2 milestones for a 6 month project, 8 for a two year project).
  • Budget of direct costs (e.g., time and benefits for faculty, time and benefits for students, travel). Each project should budget for at least one trip for one person annually to attend an I/UCRC for reporting. Please note that member universities have agreed to NSF’s stipulation of no more than 10% overhead on direct costs. A draft template for the budget is located here.

Timeline

29 September 2023 – Responses due, one pdf file emailed to nsf-cites-proposals@mx.uillinois.edu

7 November 2023 – Short presentation (remote possible) to IAB at CITES annual meeting

1 January 2024 – Start of selected projects

 

Any questions regarding this call for proposals can be emailed to Mike Prosise at nsf-cites-proposals@mx.uillinois.edu 

CITES 2023 2023 Needs Assessment

The academic leadership and Industrial Advisory Board of CITES offer a list of seven general topical areas for focus in the 2023 proposal cycle. Proposals should clearly identify which of these areas they address. Some IAB comments on the topics are included to help inform proposers’ consideration of areas and methodologies of particular interest to (at some) IAB members.

1.  Zero Trust Networking
The fundamental idea behind zero-trust networking is to push provenance, authentication, integrity, and policy checking to edge devices in the network. In a zero-trust network compromised network devices might impede legitimate traffic, but edge devices are not fooled by corrupted traffic. Design and installation of zero-trust technology introduces significant added complexity to security management on edge devices. A real challenge is understanding if and how zero-trust networking can be effectively deployed in energy system OT networks.

Example (but not exclusive) problems: 

  • OT systems cannot depend on cloud-based solutions for managing security credentials, policies, and associated data. Where should internal servers that manage them be placed with a company’s system in such a way that the system is resilient to attempts to interfere with them?
  • Zero-trust networks push security questions to the edge, but still rely on the network delivering the traffic to these devices. What kinds of network architectures and traffic management are best suited for making traffic delivery resilient to interference?

IAB Suggestions:

  • Be clear on “effectiveness” sought for proposed solutions, e.g., ease of use, lower costs, properties that can be proven using mathematical techniques, etc.
  • Any discussion about resilience should be clear about which attributes of resilience are addressed and means of acquiring evidence to support claimed resilience. This could be a significant part of the work. 
  • Address how zero trust approaches cross the IT/OT boundary without creating additional risks. 

2.  OT System Architecture
The classic Purdue model for OT systems defines system layers Enterprise, DMZ, Operational and Control, Process, and Physical, being focused on the physical organization of devices. Practice now is to shoe-horn logical constructs such as protection layers and 3rd party presence into the Purdue model, leading to lack of clarity and expression of intention. What is needed is a model for OT architectures that captures new technologies and is general enough to last for twenty years.

Example (but not exclusive) problems:

  • Develop an architectural model focused on cyber-security and illustrate its application in operational systems such as those that use OT pub-sub protocols, like IEC 61850 GOOSE and Open Field Message Bus (OpenFMB).
  • Develop an approach to OT System Architecture design that uses ideas from technologies such as Zero-Trust Networking, Software Defined Networking and Trusted Execution Modules, and/or Cyber-Informed Engineering (see https://inl.gov/cie/) to enable a systematic approach to assuring integrity and enhancing cyber-security.
  • Human factors considerations related to understanding the architecture and ramifications that changes to the architecture may have. 

IAB Suggestions:

3.  Secure System/Software Development and Lifecycle 
A significant factor that leads to compromised computer systems is design and implementation flaws in the software components, and the ways they are connected to create a system. Security must be “baked” in, and part of that involves the methodologies and testing that are used in the development of that system or software. The needs extend throughout the entire lifecycle (requirements, planning, design, development, testing, deployment, maintenance).

Example (but not exclusive) problems:

  • Define the background/scope, including needs of utilities, needs of vendors, and needs of system integrators/distributors/wholesalers and subcontractors with respect to the lifecycle of security in software and systems. This would include a product lifecycle definition from identifying the product/needs for a product all the way through end of life and disposal.
  • A gap analysis of the software and system lifecycle, comparing tools that are available for managing the lifecycle available, with needs.

IAB Suggestions:

Since common weaknesses (cwe.mitre.org) are the raw material of vulnerabilities, consider methods/tool/guidance to prevent/mitigate specific CWEs that would thereby cripple many vulnerabilities, especially latent ones.

4.  Interacting Systems
New devices, applications, and systems designed to improve security are often envisioned without considering the dependence that the security they provide has on the security of the new entity itself. For example, introduction of
PKI within an OT network necessitates introduction of a certificate server, which, if compromised or inaccessible, inhibits the security apparatus that depends on the PKI. The challenge is to identify techniques, methodologies, and/or analyses that help one to identify, consider, or forestall the risks attendant with introduction of that technology.

Example (but not exclusive) problems

  • A critical component of any security system is effective and high-integrity device authentication. Security that relies on this impedes threats to that would otherwise exist to authentication systems. A problem is to identify such device identification techniques and quantify the reduction of risk to an OT’s authentication system.
  • OT software technology is created using a variety of commercial and open-source software modules. A software bill-of-goods may (and soon will) be associated with deployed code, so that when a vulnerability is reported in some module the dependency of other modules on that flaw can be identified. The problem is to proactively determine which software modules have the most significant impact on the system if they were to fail.
  • Industrial internet of things devices may become involved in control systems. These rely on cellular communication, probably 5G, and may interact with cloud-based systems for things like state-estimation. How might these technologies be used together, and what are the benefits and (importantly) risks of that integration.

IAB Suggestions:

  • Determine gaps in cyber-physical systems modeling languages and tools for interacting energy systems. E.g., how can one connect Modelica, SysML, or AADL. What are the gaps and how can they be filled?
  • The composition problem for security is hard. Even if we just had a set of constraints that allowed us to solve it for specific cases, that might be worthwhile.

5.  Energy System Protection 
Advancing software and hardware technologies for protecting energy systems from cyber malfeasance. This needs area is broad.

Example (but not exclusive) problems:

  • Intrusion detection tailored to energy systems
  • Technologies for describing and analyzing cyber-attacks and defenses in energy systems
  • Hardware support for device identification
  • Decision aids for application of security controls in energy systems
  • Security for energy system micro-electronics
  • Evaluation of access-control devices against formalized security policies typical in energy systems
  • Protection against insider risk
  • Models for determining/providing the “right” level of cryptographic strength of techniques that provide confidentiality, and integrity
  • Automate techniques to assess security posture, provide options to improve security management, add detection mechanisms, mitigate possible vulnerabilities
  • Many others that are focused on protection in energy systems. 

IAB Suggestions:

  • For any proposed problem and solution, what specific metrics can be defined and measured to provide technical evidence of improvements/capabilities? Is it harder for the adversary? Easier for the defender?

6.  Data Trust and Integrity 
Grid modernization increases reliance on data for human and machine-assisted management of grid operations. Emerging technologies such as machine learning and other advanced analytics increase that data dependency by several orders of magnitude. New concepts like zero trust challenge traditional data architecture assumptions. Use of digital twins for near real-time and real-time simulations require data from multiple sources to describe operating conditions.

Example (but not exclusive) problems:

  • Develop metrics that define data quality for training sets, e.g., including provenance information to mitigate data poisoning threats.
  • Develop means of managing data and continuously assessing its trustworthiness in distributed and decentralized applications that include on premise and cloud-based storage.
  • Develop data schema standards to eliminate the friction of standardization and normalization of aggregated data from different sources. 

IAB Suggestions:

  • Data is an under-utilized and under-valued asset in critical infrastructure OT environments. We need to re-examine the compliance-first data governance approach which may prevent data from achieving full productive value in organizations.
  • We need to re-examine of two of the three data pillars - integrity and availability in these environments. For instance, machine learning models ingest large volumes of data as training datasets to help assist in semi-autonomous and fully autonomous grid operations.
  • Dataset integrity needs to be defined by quality standards, metadata requirements, and trusted provenance solutions.
  • Data availability for zero trust authentication and authorization and other distributed and decentralized use cases may require significantly different data storage architectures than those currently deployed today in OT environments.

7.  Secure Digital Infrastructure for Energy 
Society is on the cusp of a new energy ecosystem, driven by requirements for efficiency and
decarbonization as well as advances in energy sources, electric transportation, and market models. Realizing this vision will require a secure digital infrastructure for secure interoperability, trust relations among multiple stakeholder communities, secure and verifiable transactions, integration of nonconventional generation at multiple grid scales, and secure cloud operations.

Example (but not exclusive) problems:

  • Secure integration of alternative energy resources, in distribution and transmission systems. Stability under high penetration of some alternative energy resources such as wind and solar present a challenge to system stability due to their intermittent nature. This can be potentially addressed by storage at all grid scales. IEEE 1547-2018 (in revision) for distributed energy resource (DER) integration mandates “ride through” for certain classes of DER to avoid the stability impact from a high penetration of DER all tripping at once in response to a disturbance. This integration requires complex control and communication, possibly between a utility and a third-party virtual power plant. How can we secure this communication and develop trust that the control commands are safe?
  • Electric transportation. EV charging presents a significant grid impact, particularly as fast charging technology emerges. Fast charging requires more power for shorter duration than the currently typical charging operation that takes hours to complete. An error or malicious operation in fast charging can impact the vehicle, the charger, and possibly the distribution grid. The vehicle battery must authenticate to the charging provider to ensure correct billing and road use taxes. This should preserve vehicle operator privacy as to routes driven. Scheduling in an environment with many vehicles, or for a fleet of electric buses, must be done carefully so as to maintain system safety and fair (possibly time-sensitive) billing.
  • What is the potential of edge-to-cloud frameworks for cyber-physical models running in faster than real time to verify correct AEPS-DER interoperability?

IAB Suggestions:

  • Given the complexity of such interactions, the design of the solutions should include formal modeling to provide deductive evidence / high assurance that the system is robust. Or, at least so one can efficiently find the too-easy to find robustness counterexamples.

Top of Page