Communication and Security for the Smart Grid
Security: Key to Smart Energy Software Development
The build-out of the Smart Grid involves many millions of connected devices, large and small. And with that comes increased vulnerability. While adherence to security and safety standards is not yet officially mandated, it will be prudent for developers to build devices and code that can achieve certification when that day arrives.
MARK PITCHFORD, LDRA
Page 1 of 1
Smart Energy—with its intelligent distribution of power and ultra-efficient potential—offers hope for a holistic view of energy. Its combination of renewable energies, traditional technology and optimized management promise the ability to meet the economic and environmental challenges inherent in both energy generation and energy consumption.
As our reliance on fossil fuels diminishes, transport too will be drawn into this M2M connected world where electricity becomes the only viable option. The emergence of an ever-increasing pool of hybrid and electric cars from Chevrolet, Nissan, Toyota and Tesla portends the new road of travel.
Security is the dark cloud hanging over this bright future. While Chevrolet’s Volt is lauded as the first vehicle with its own IP address and ease of Internet access for onboard information systems, the IP address also provides a ready-made access point. Such a standard interface with its well-defined protocol provides an easy target for anyone looking to cause problems or to locate a particular car. Just imagine the gang’s discussion, “Hey, Josh Jones is on vacation. Let’s nail that audio system of his.”
The criticality of security for such systems didn’t just start with “Smart Energy.” As long ago as 1982, a Trojan virus inserted into SCADA system software caused a massive natural gas explosion along the Trans-Siberian pipeline. In January 2003, the Davis-Besse Nuclear Power Station’s private network, infected with the “slammer worm” virus, lost safety monitoring for five hours. Clearly, SCADA systems with their roots in the 1970s weren’t written for this connected world where defense against hacker intrusion is foremost. At that time, internal networks similarly were considered safer, less vulnerable to external attack.
However, the 2011 crash of a CIA drone in Iran shows that not all systems can withstand hacking even in a presumably more protected environment such as aviation. In that incident, local authorities claimed that they diverted the vehicle by hacking its GPS. Their claim gained credence when Professor Todd Humphreys of the University of Texas and a group of U.S. researchers hacked a UAV in front of representatives of the U.S. Department of Homeland Security. Notably, Humphries was no UAV expert. He simply knew the interface and exploited those vulnerabilities to affect the flight information of the drone.
With the advent of a massive connected energy network, there is no room for security complacency. The Smart Grid offers unprecedented opportunity for the unprincipled and fanatical to disrupt, destroy and dominate. Let’s look at what best practices can minimize the chance of your device providing the weak link for intruder attack.
What the Standards Can Bring to the Table
The U.S. National Institute of Standards and Technology (NIST) published “Release 2.0 of the NIST Framework and Roadmap for Smart Grid Interoperability Standards” (Special Publication 1108R2) in February 2012. It outlines the progress made in Phases II and III of NIST’s three-phase plan to establish Smart Grid interoperability.
Highlighting the work in progress, it lists 20 standards-setting organizations. Such a list of organizations does little to reassure a team facing the task of developing devices now for a commercial marketplace immediately hungry for products.
Some standards, such as references standards developed by the “Object Linking and Embedding for Process Control (OPC) Foundation” may be a mixed blessing. This industry consortium creates and maintains standards for open connectivity of industrial automation devices and systems. While the benefits of open connectivity are clear, its published protocol implies more accessibility than would have been the case 20 years ago when communications to such devices often involved a unique protocol.
Other standards ensure that security is central to development in every element of the design. The development process outlined in International Organization for Standardization (ISO) 15408 is designed to result in a secure finished product. Complementing this process standard are coding standards, such as CERT C, a high-level programming language subset that ensures software is written as securely as possible.
Although neither standard is mentioned in the NIST report, to date, NIST has so far adopted best-practice, established standards from elsewhere. It therefore seems inevitable that standards like these will emerge during Smart Grid Interoperability Panel (SGIP) Phases II and III. Developers who adopt such recommended approaches now will position themselves ahead of the game.
ISO 15408 (also known as the “Common Criteria”) defines IT security requirements categorized according to seven Evaluation Testing Assurance Levels (EALs), as displayed in Table 1, with EAL 7 representing the most secured system. Security functional requirements include audit, communications, cryptography, data protection, authentication, security management, privacy and protection of Targets of Evaluation (TOEs).
ISO 14508 defines a range of Evaluation Assurance Levels (EALs), which determine the process rigor associated with each software component.
ISO 15408 suggests the use of language subsets, also known as coding standards. Suitable language subsets include CERT C and CWE, both of which help secure code by detailing constructs and practices for developers to avoid.
When Safety Is Also a Concern
It is entirely possible that a safety-critical device might be used within the Smart Energy grid, and that implies a requirement for the software to adhere to safety AND security standards.
From a software perspective, security-focused ISO 15408 and safety-specific IEC 61508 standards do overlap. Both place considerable emphasis on configuration management, software development, quality assurance, verification and planning.
Just as ISO 15408 recommends the use of language subsets to enhance software security, IEC 61508 advises that a safety-related coding standard should be used. In this case, appropriate subsets such as MISRA C consist primarily of lists of constructs and practices for developers to avoid when writing safe code. It is entirely possible to adhere to coding rules from both safety AND security focused language subsets.
Managing Security Compliance Along with Other Standards
Certification management is challenging in any industry, even when standardization is mature and processes defined. The Smart Grid has the potential of increasing that challenge significantly with the likelihood that developers will need to adhere to a multitude of technology and communication protocols as well as security (ISO 15408, CERT C, CWE) and safety (IEC 61508, MISRA C) standards. However, with market pressure to release Smart Grid applications as soon as possible, improvements in time-to-market and development costs are also important.
Fortunately, certification management tools now exist that automate and coordinate the processes and programming standards required, even when developers must comply with multiple standards at various levels of safety and security. These tools boil compliance management down to the fundamentals. ISO 15408, for example, demands requirements traceability, static analysis and dynamic analysis. Tools and tool chains now integrate to automate the labor-intensive aspects of all three objectives (Figure 2).
By applying appropriate automation techniques, development teams can minimize overhead, streamline the transition between project phases, and show requirements traceability to development artifacts.
The standard directs that high-level requirements are detailed and traced to low-level requirements, design documents, design documents to code, and code to tests—and back up again to gain “bidirectional requirements traceability” end-to-end throughout the software development lifecycle.
If requirements could be relied on to never change from their initial version, then traceability would be relatively straightforward. However, that is rarely the case, and consequently the maintenance of a permanently up-to-date requirements traceability matrix (RTM) becomes a very labor-intensive task.
To help manage this matrix of relationships, requirements-traceability tools link system requirements to the products of each development phase. The resulting automated bidirectional tracing of requirements ensures that the developed device does exactly what is specified by the final set of requirements—no more, no less, and no matter how often requirements change (Figure 4).
The Requirements Traceability Matrix (RTM) plays a central role in a development lifecycle model. Artifacts at all stages of development directly link to the RTM, and changes within each phase automatically update the RTM so that overall development progress is evident from design through coding and test.
Figure 5 shows a more abstract interpretation of how the Requirements Traceability Matrix impacts each phase of the development lifecycle. For example, it illustrates how requirements are traced from high-level requirements (Tier 1), through low-level requirements (Tier 2) to implementation (Tier 3) where the coding rules from the selected language subsets are applied.
The “requirements” of how the application is intended to function are often considered distinct from the “objectives” of process standards such as ISO 15408 or IEC 61508, but traceability to both is essential.
For example, providing evidence of adherence to a language subset shows adherence to a particular objective specified in the process standard. It is impractical to manually check for compliance to a comprehensive set of rules such as those specified in CERT C, CWE or MISRA. Automated static analysis techniques are therefore used to highlight the precise location of any violations, or to generate artifacts providing evidence that there are none.
Another objective will be to prove that the different parts of the code have been executed to a degree appropriate to the criticality of the system. Dynamic analysis tools can be used to gather information on which parts of the code have been exercised during the test process.
These dynamic tools also provide traceability to the requirements by showing that the code responds to specified input data in the appropriate manner.
The use of “independently developed testing tools and test suites” such as these static test, dynamic test and requirements tracing tools is encouraged by the NIST framework.
Cost-Effective Safety and Security
At present, Smart Grid development projects are not obliged to meet ISO 15408, IEC 61508, MISRA, CERT C, or CWE. Even if they were, those standards do not insist on the use of automated tools or on the automation of the development process.
However, especially given the potential of their expanded role to seriously expose the economic and national infrastructure to extensive risk, the need for the Smart Grid and all the devices it entails to be secure is vital to avoid malicious control and manipulation of the network. It therefore seems inevitable that future releases of the “NIST Framework and Roadmap for Smart Grid Interoperability Standards” will advocate adherence to security- and safety-critical standards as necessary steps in protecting national infrastructures while helping countries achieve economies of scale in power generation and management.
Companies wanting to get a head start over the competition need to seek out ways to efficiently implement safety and security processes in their development cycle. Modern tools that automate requirements traceability and analysis while tracking certification/standards compliance ensure teams manage system development in an efficient and cost-effective manner.
LDRA Technology, Boston, MA. (855) 855-5372. [www.ldra.com].