Appendix: A Building Code for 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])
| Structural Building Code | (BC)2 Power |
| Structural integrity against hazards such as wind, lightning, rain, earthquake | Structural integrity of isolation and other mechanisms to resist tampering and other attacks |
| Fire safety: prevent, detect, isolate, safe exit | “Fireproof” materials in the form of coding standards, mechanisms to detect, isolate (domain separation), and recover |
| Physical safety of occupants: door and stairway dimensions, handrails | Security mechanisms that are easy to use and understand |
| Water and energy | Efficient and secure information flows |
| Security certified materials, components, and subassemblies | Secure development environments, languages, libraries, and modules |
| Inspection | Code review, static analysis |
| Stress test: Bring pipes to pressure, foundation bolts pull-out test | Dynamic analysis, fuzz testing. Design embedded systems sufficiently robust to enable scanning and fuzz testing |
| Certification | Certification, signed software |
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://ieeecybersec.wpengine.com/ [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://ieeecybersec.wpengine.com/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)”