Posted by Michael Avari on August 25, 2017
A recent “Innovation Spotlight” in the IEEE XPLORE Digital Library announced “a first-of-its-kind charger that allows plug-in electric vehicles (PEVs) to deliver excess capacity to the power grid and recharge during off-peak hours.” Promising new technologies often evoke questions about security. Suppose a bad actor exploits the connection somehow and brings down portions of the network or grid?
If this seems far-fetched, PCWorld has expressed concern since 2013 that, “Hackers could use vulnerable charging stations to prevent the charging of electric vehicles in a certain area, or possibly even use the vulnerabilities to cripple parts of the electricity grid…”
NIST recognizes the risk too. Their “Guidelines for Smart Grid Cybersecurity” build a logical reference model with seven domains, including “customer and customer devices.” PEVs and electric vehicle service elements are also included.
More generally, BloombergBusiness warned, “Making the electricity grid greener is boosting its vulnerability to computer hacking, increasing the risk that spies or criminals can cause blackouts.”
“Adding wind farms, solar panels, and smart meters to the power distribution system opens additional portals through which hackers can attack the grid…”
One does not have to conduct a deep investigation to find myriad of articles on the projected proliferation of the Internet of Things and the next generation of our connected world. It is when such “things” begin to connect to the grid or to control systems controlling the grid that one needs to take pause. Ericsson (2010) in “Cyber Security and Power System Communication—Essential Parts of a Smart Grid Infrastructure” warns, “The fact that SCADA/EMS [supervisory control and data acquisition/energy management systems] systems now are being interconnected and integrated with external systems creates new possibilities and threats.”
The problem is not always easy to define or locate in a large network, but the security risks described in these reports disquiet our intuition as engineers and executives. A systems view of power, communications, and control networks requires us to analyze and remediate threats in a systematic way. But how?
Documents in this field abound from the Department of Energy, International Standards Organization (ISO), NERC, NIST, Software Engineering Institute (SEI), and SANS Institute. Some serve as frameworks. At least one is a normative standard for process and documentation (ISO 27001). Still others are maturity models (DOE—see below, SEI) or guidelines (NIST).
Good IT infrastructure practice aside (physical security, network security, resiliency plans, etc.), application software is an area where benefits may be reaped with great yield. The Department of Homeland Security agrees:
“The nation’s critical infrastructure (energy, transportation, telecommunications, banking and finance, and more), businesses and services are extensively and increasingly controlled and enabled by software. However, weaknesses in software may expose vulnerabilities that put our critical infrastructure resources at risk.”
Fortunately, there are processes one can follow. There are industrial models to measure an enterprise’s security plans and performance against best practices. These can satisfy such standards and assure a systematic management of risk. Security practitioners in this field have developed systematic ways to thinks about and continuously improve application security. Here is a proposed, focused direction founded on the best practices as developed by experts:
The guide outlines a way to establish a risk management program:
“The goal of a risk management program is to identify the risks, understand their likelihood and impact on the business, and then put in place security controls that mitigate the risks to a level acceptable to the organization. In addition to assessment and mitigation, a robust risk management program includes ongoing evaluation and assessment of cyber security risks and controls throughout the life cycle of smart grid component software.”
In addition to providing the elements of a risk management program, the guide provides ways to assess people, policy, process, and technology risks. It also gives specific requirements and controls for each smart grid component or subsystem, such as advanced metering, SCADA, thermal storage, home portals, and so on. Consider the guide as the compass guiding you toward a structure for risk assessment.
The SANS Institute “2015 State of Application Security” observes,
“It is far better to build in security during the development process. Tens or hundreds or thousands of builders and analysts can do a lot more to build secure applications than a much smaller number of defenders can do after an app is in production—as long as builders have the training, tools and time they need to do the job.”
The Building Security In Maturity Model (BSIMM) shows us how. This is a descriptive data-driven model, the latest version of which is founded on surveys of software initiatives of 100+ major firms. BSIMM consolidates this data and presents 12 application security practices with discrete activities in each practice. The objective is to build a software security foundation consistent with project and business objectives.
If the smart grid guide is the compass, consider BSIMM as the roadmap for application security. Because it is not normative or prescriptive, a project team may engage in the activities as appropriate to the particular application, or the department or enterprise policy encompassing many applications. It is a maturity model in the sense that activities are organized into three progressive levels. Finally, it may be used as a benchmark model because a team or company may measure its performance against the activities of the entire sample population of leading application providers.
BSIMM encompasses activities one would normally associate with building security in, such as architecture analysis, code review, and security testing. Yet it goes beyond that to support a culture of security in governance, intelligence, and deployment. As such, it intersects with the application asset protection controls in other enterprise-wide standards and guidelines published by DOE, ISO, and NIST.
It may be true that there will be a shortage of security engineers that would make it difficult for an IT department to build that capability internally. But that is not the primary impetus for this recommendation. Teaming with outside expertise accomplishes several salutary objectives:
The aerospace and defense industries rely extensively on independent review and third-party testing. They thus provide a proven model and the requisite processes for other industries.
By now, you may be thinking that the foregoing three areas make sense for applications and systems directly under your control.
It is becoming increasingly important to practice supply chain security. The DOE Cybersecurity Maturity Model (C2M2), which is the core of both in the Electric Sector C2M2 and Oil and Gas Sector C2M2, states, “When evaluating how completely a practice is performed, be sure to consider both traditional and emerging enterprise IT assets and any industrial control systems (ICS) in use, including process control systems, supervisory control and data acquisition (SCADA) systems, and other OT [operational technology].”
The Energy Sector Working Group’s “Roadmap to Achieve Energy Delivery Systems Cybersecurity” cites one strategic objective, among others, as “Vendor systems and components using sophisticated secure coding and software assurance practices widely available.”
The DOE provides some tools for supply chain security. One is the National SCADA Test Bed, a consortium of sorts of national labs. The labs are researching cryptographic keys, dynamic network reconfiguration based on threats, and other groundbreaking technologies. I invite discussion among the readers of this article to comment on whether, following again the practice of aerospace and defense, methodological and uniform independent standards, and testing might facilitate attaining the supply chain security objective. Vendor attestation is not enough.
Another, arguably more practical, tool the DOE provides is the “Cybersecurity Procurement Language for Energy Delivery Systems.” This tool provides supplier contract language. For example,
“The Supplier shall provide a Quality Assurance program and validate that the software and firmware of the procured product have undergone Quality Control testing to identify and correct potential cyber security weaknesses and vulnerabilities. This testing shall include fuzz testing, static testing, dynamic testing, and penetration testing.”
The proposed language thus clearly places the responsibility for product security on the supplier. Clearly, this isn’t just a matter of compliance or good security practice. It’s also one of good strategic business practice too, to protect the firm and the consumer. Project managers and systems designers within enterprises may wish to consider adding language that sets activity and testing standards for suppliers based on recommendations 1-3 above.
Securing our infrastructure, smart grid, and IoT environments imposes on all industry participants exigencies to manage risk in components, subsystems, and systems. National and industry standards are sometimes too broad or not deep enough. It is my hope that the few recommendations made in this article provide actionable, specific steps toward achieving cyber security in application software for the energy industry.