​IEEE Invitational Workshop to Create ​a Building Code for Building Code for Power System Software Security: (BC)2 Power

November 16-18, 2016
University of Illinois at Urbana-Champaign

Purpose

The aim of this workshop is (1) to establish an initial consensus among industry and academic participants on the appropriate components of a “building code” that would be appropriate to reduce significantly the vulnerability of cyber components of electric grids to malicious attacks, and (2) to establish a research agenda for the creation of evidence that could justify the inclusion of additional elements in such a code. The workshop will be held under the auspices of the IEEE Cybersecurity Initiative, IEEE Smart Grid, and IEEE Power and Energy Society, with participation from UIUC’s Information Trust Institute; additional support is being sought from the NSF Secure and Trustworthy Cyberspace program.

The workshop proposal describing the scope, objectives, and the building code metaphor is included as an appendix to this call for contributions and participation.

What might a building code for power system software/firmware security look like?

Building codes applied to physical structures generally grow out of industry and professional society groups – suppliers, builders and architects – rather than from government, although adoption of codes by government provides a legal basis for enforcement. Building codes generally apply to designs, building processes, and the finished product. Code enforcement relies on inspections of structures during construction and of the finished product and also on certification of the skills of the participants in the design, construction, and inspection processes. Codes also take account of different domains of use of structures: code requirements for single-family dwellings differ from those for public buildings, for example.

Following the ideas expressed in [1] we aim to develop an analog to these processes that will improve assurance that software developed for the domain of medical devices will be free of many of the security vulnerabilities that plague software generally. Evidence to date is that a large fraction of exploitable security flaws are not design flaws but rather implementation flaws. An initial building code for power system device software/firmware security could focus on assuring that the final software that operates the device is free of these kinds of flaws, although it could address aspects of the development process as well. For example, the code might specify that modules written in a language that permits buffer overflows be subject to particular inspection or testing requirements, while modules written in type-safe languages might require a lesser degree of testing but a stronger inspection of components that translate the source language to executable form.

Considerations for Including a Particular Requirement in a Building Code for Power Systems Software Security

1. The first criterion should be the ability of the required item to reduce the vulnerability of software to exploitation. Specific evidence should be available to support claims of effectiveness.
2. Ease of evaluation. Requirements that are effective but require unusual expertise, time, or other resources to evaluate are not appropriate for inclusion in the code.
3. The appendix below
4. Requirements affecting only a narrow scope of vulnerabilities may not be appropriate to incorporate.

Participants Sought

To succeed, the workshop needs participation from (1) industry personnel familiar with the architecture and tools used to build power system devices and the software that controls them, (2) people familiar with the history of power system device regulation in general and people familiar with the history of computer security regulation, (3) researchers and practitioners familiar with cybersecurity issues generally and with security issues in power system software in particular, and (4) experts in relevant aspects of software engineering, including requirements, design, and (especially) implementation, test, and validation/verification methods.

Workshop Organization and Products

The meeting will be organized as two-day event with approximately 40 invited participants, starting in the evening of the first day (Nov. 16) and ending in the afternoon two days later (Nov 18). The meeting will open with a dinner session accompanied by an invited talk or panel on the history and current state of official guidance on the security of power system software. The next day will open with a general talk on the concept of a building code for security-critical software that will address the types of requirements a building code might include and the possible basis for deciding whether a particular element should be included in the code. Following this introduction, a series of short talks proposing possible elements of the code will be presented, based on submissions received in advance of the meeting.

In afternoon breakout sessions, the participants will be asked to discuss the proposed elements and to assess the strength of the evidence for including each proposed item in the code. When the group consensus is that stronger evidence is needed, research topics that might help establish that evidentiary basis will be identified. At the end of the afternoon, groups will report on their progress in a brief plenary session.

The breakout sessions will reconvene on the final morning of the workshop to consider the results of the plenary session and any evening discussions. The meeting will close with a two-hour plenary session in which consensus on an initial building code and research agenda will be sought.

Following the meeting, the Chair and Vice-Chair, in consultation with the workshop participants and Steering Committee will develop a report on the workshop documenting the initial draft building code and research agenda. The report will be placed on IEEE Cybersecurity’s website and will be published by the IEEE as well.

Where to send your contribution/request for invitation

If you are interested in participating, please send a note of not more than 600 words explaining (A) which of the four groups listed above you would represent and (B) at least one requirement you think would be appropriate to discuss at the workshop as a candidate for an initial building code, as well as evidence supporting the effectiveness of that requirement. If you are interested in the workshop but don’t have a specific element to propose, please include a description of your role in power system software development or in assuring software security. Submit this information to: http://goo.gl/forms/ysWg3JwJZyEd0Is13 no later than September 14, 2016.

Travel Support

Support for those requiring reimbursement of travel, lodging, and meal expenses is expected to be available from the workshop sponsors.

Reference

1. Landwehr, C. E. “A Building Code for Building Code: Putting What We Know Works to Work,” Proc. 29th Annual Computer Security Applications Conference (ACSAC), New Orleans LA., ACM, NY, pp.139-147. Available at: http://www.landwehr.org/2013-12-cl-acsac-essay-bc.pdf

Appendix: A Building Code for Power System Software Security: (BC)2 Power

Workshop Proposal

Introduction

Based on a recent essay by Landwehr [L13], the cybersecurity community has undertaken a number of initiatives exploring the metaphor of structural building codes as a guiding framework for building secure codes in critical systems. Under the auspices of the IEEE Cybersecurity Initiative [IEEE] and the National Science Foundation, a workshop was held in November 2014 to describe such a framework for medical devices [MDSSA, MDSSB]. The purpose of this document is to propose a workshop to explore the building code metaphor in the domain of electric power systems.

Modern infrastructure systems, such as those in electric power grids, are rapidly evolving into cyber-physical systems (CPS) in which distributed cyber assets for monitoring, communication, and control interface with a physical process for safe and efficient operation. In the power sector, assets include embedded systems in devices located at substations, poletops, or on customer premises (for example, smart meters) as well as more conventional server and workstation platforms hosting data historians and human-machine interfaces (HMI). This proliferation of assets exposes a growing and poorly understood attack surface, with potential attacks ranging from theft of service to massive, protracted outages. Since all other critical infrastructures and indeed the smooth function of modern society depend on electric power, the effect of a long-term, wide-area outage could be destabilizing on a historically unprecedented scale.

Workshop Objectives

The proposed workshop seeks to define the building code framework for software systems in electric power, from HMI to embedded systems firmware in field devices. The workshop will enumerate elements of such a code, and identify tools, processes, and methodologies that support these elements. This in turn will define adoption strategies and identify outstanding gaps to be addressed by the research and academic communities. The eventual goal is an adaptable structure to guide code implementation, addressing the following points as well as other aspects identified by workshop participants:

• Approaches to avoid and remove security flaws at design and implementation
• Choice of development environment, language, and libraries
• Tools for static and dynamic code analysis
• Evaluation of the finished product
• Certification
• Resilience, defined as safe operation or “soft landing” in case of attack or adverse event
• Built-in features to support attack detection, attribution, and forensics 

Intended Audience

We invite participation from diverse stakeholders with an interest in secure software in the power sector. This includes the academic and research community, but it is essential to enlist participation from power system equipment vendors (responsible for HMI software and device firmware), asset owners, security consultants, and policy specialists. This diversity is essential to ensure that the workshop product reflects the interests of all involved, and to maximize the probability that the framework will be adopted.

Document Organization

Subsequent sections of this document provide initial background discussion addressing workshop objectives, although we anticipate that the workshop will significantly change this understanding. We first sketch out the building code metaphor in the power system context, and enumerate a candidate list of elements of the building code. Next, we position our effort in relation to initiatives from NIST and the Security Development Lifecycle [SDL06, MSSDL], as well as the earlier work by members of the team in the medical device domain. We conclude with an overview of the particular challenges that arise applying this approach to the power system domain.

Building Code as Metaphor

The workshop aims to develop an analog to structural building codes focused on security properties of software. The objective of the code is to increase assurance that developed software will be free of many software vulnerabilities typically present in software developed according to current practices. Evidence suggests that exploitable security flaws arise from implementation rather than design flaws. The underlying motivation for creating this building code for the security of power system software and firmware is to provide a basis that developers can use to rule out the most commonly exploited classes of software vulnerabilities, as well as to build in mechanisms for recovery and attribution. To accomplish this, the code elements must be effective and relatively easy to adopt and evaluate.

Elements of a Building Code for Code

We enumerate candidate elements of (BC)2 Power by analogy to elements of structural building codes, given in the table below.

Analogs Between Structural Building Codes and Building Codes for Code
(adapted and extended from [L13])

Complementary Initiatives

Security Development Lifecycle

The Security Development Lifecycle [SDL06, MSSDL] outlines a sequence of practices to be followed from the security requirements phase through design, implementation, verification, release, and (incident) response. Analysis and, to the degree possible, reduction of the attack surface is a theme that recurs in various phases. SDL calls for threat modeling, which may guide adoption of elements in our building code, but may not be part of the building code itself.

The building code elements enumerated in this document in areas such as secure development environments, static and dynamic analysis, and fuzz testing map directly to counterparts in SDL, particularly in the implementation and verification phases.

NIST

The NIST framework [NIST14] provides a risk-based approach to managing cybersecurity risk, but is more oriented to the enterprise user rather than the developer. It outlines a tiered approach whereby an organization examines components of cybersecurity risk and undertakes measures to address it. The framework specifies functions to identify, protect, detect, respond, and recover. We may envision that building codes in the sense we propose support some of these functions. For example, an implementation of the NIST framework may legitimately claim that the identified risk is lower for software that is certified as having been built according to codes such as we propose than for software claimed to be functionally equivalent but without the certification. The objectives of the NIST framework and the building codes initiative are different in that the NIST framework addresses business process and risk management, while the building codes approach identifies practices, tools, and procedures to implement secure software.

Medical Device Software Security

Some of the organizers of the workshop proposed here have applied he building code concept in a workshop addressing software security in medical devices [MDSSA, MDSSB]. The workshop report includes an appendix that identifies code elements, grouped as follows:

• Elements intended to remove/avoid flaws at design
• Elements intended to avoid/detect/remove vulnerabilities at implementation
• Elements intended to assure software/firmware provenance and integrity
• Elements intended to impede attacker analysis or exploitation
• Elements to enable detection and attack attribution

We note that the latter three categories above do not remove or avoid vulnerabilities, but promote resiliency in the presence of vulnerabilities that persist in the developed software.

The workshop identified element categories for safe degradation, restoration, and maintenance without loss of integrity. No specific elements were proposed in these categories.

Challenges and opportunities in the power sector

The following are some of the specific challenges to security in the power grid domain. The list is not intended to be exhaustive.

Long component life

Power systems are characterized by a mixed ecosystem of legacy and modern components. The useful life of a component with respect to its power function is typically much longer than the firmware refresh cycle. Legacy components cannot support modern security measures, and today’s newly installed device will be “legacy” from the cyber standpoint through most of its useful life in the field. The building code must recognize this, and anticipate requirements for secure firmware upgrades and interoperability in mixed legacy environments.

Computational, communication, and power constraints

Power system devices must react to adverse conditions that arise suddenly (a tree falling across a power line) so as to maintain system safety, minimize outage, and protect difficult-to-replace equipment. Legacy devices achieve these objectives through thermal or electro-mechanical means with no or minimal programmable logic or inter-device communication. Modern protection schemes require rapid intra-device and distributed communication to respond intelligently to adverse conditions. It must be the case that the building code does not impede these requirements, especially considering the fact that field devices may be limited in computational and communication resources.

Security perimeter: Substation, Poletop, customer premise

Intelligence in smart grids is increasingly distributed and migrating to the grid edge (both physically and logically). Substations now include a variety of devices such as transformers, bus bars, and intelligent relays and breakers. More and more intelligence is moving to the field, in the form of devices such as poletop reclosers. This trend extends all the way to the customer premise in the form of smart meters. While one may argue for physical security of substation equipment within a fenced perimeter, we must assume that there is no meaningful physical security perimeter beyond rudimentary tamper detection on field and customer-premise equipment.

3rd party connections

Among other goals, smart grid is intended to enable the integration of renewable resources as well as new energy markets. Renewable resources may interface to utility grids at large scales (wind farms) or distribution scale (microgrids, customer-premise solar). Smart grid also enables third-party markets such as aggregation and home energy management. In all these cases, utilities must ensure the integrity of physical and financial transactions across interfaces with systems over which they have no administrative control.

References

[IEEE] http://cybersecurity.ieee.org/

[L13] Landwehr, C. E. “A Building Code for Building Code: Putting What We Know Works to Work,” Proc. 29th Annual Computer Security Applications Conference (ACSAC), New Orleans LA, ACM, NY, pp.139-147. Available at: http://www.landwehr.org/2013-12-cl-acsac-essay-bc.pdf

[MDSSA] Workshop to Develop a Building Code and Research Agenda For Medical Device Software Security: Final Report. Report GW-CSPRI-2015-01, January 8, 2015: http://www.landwehr.org/2015-01-landwehr-gw-cspri.pdf

[MDSSB] Landwehr, C.E., and Haigh, T. “Building Code for Medical Device Software Security”, IEEE Computer Society, March 2015. http://cybersecurity.ieee.org/images/files/images/pdf/building-code-for-medica-device-software-security.pdf

[MSSDL] Microsoft Security Development Lifecycle,
http://www.microsoft.com/en-us/sdl/default.aspx

[NIST14] National Institute of Standards and Technology. Framework for Improving Critical Infrastructure Cybersecurity, version 1.0, Feb. 12, 2014.
http://www.nist.gov/cyberframework/upload/cybersecurity-framework-021214.pdf

[SDL06] Michael Howard and Steve Lipner. “The Security Development Lifecycle: SDL: A Process for Developing Demonstrably More Secure Software (Developer Best Practices)”