Smart Devices, Smart Grids, and Cybersecurity
Our world is becoming a more connected place, which can allow us to do amazing things. But it also gives the bad guys a chance to wreak havoc.
Join the DZone community and get the full member experience.Join For Free
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" builds 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..."
Securing the Smart Grid Infrastructure
One does not have to conduct a deep investigation to find myriad 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?
Analyzing Threats Systematically
Documents in this field abound from the Department of Energy, International Standards Organization (ISO), NERC, NIST, Software Engineering Institute (SEI), and the 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 practices aside (physical security, network security, resiliency plans, etc.), application software is an area where benefits may be reaped with a 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."
Developing a Cybersecurity Risk Management Plan
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 think 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 cybersecurity 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.
2. Next, build security into the application or system as it is being designed, developed, tested, and deployed.
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.
3. Engage an expert partner for independent analysis, testing, or other activities.
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 up with outside expertise accomplishes several salutary objectives:
- It provides the proverbial additional set of eyes and ears. Independent analysis and inherent depth of cross-industry knowledge can quickly identify and remediate root causes of vulnerabilities and risks. It can also guide an internal team to best practices along a path of least resistance and maximum gain.
- Boards understand the need for analysis and testing functions provided by an independent entity and welcome the resulting objective, dispassionate data, and conclusions. It follows from this, in some cases, that budgets for these engagements may often be found or readily justified outside regular operating expenses.
- The engagement of an application security partner is often welcome by internal and external governance, risk management, and compliance (GRC) functions, and by counter-parties.
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.
4. What about the security of vendor products and components, particularly commercial off-the-shelf (COTS) software, that may affect your system?
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 cybersecurity 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 cybersecurity in application software for the energy industry.
Build and implement comprehensive and customized cybersecurity plans.
Published at DZone with permission of Michael Avari, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.