The combination of renewable energies, traditional technology and optimised management promises to meet the economic and environmental challenges inherent in both energy generation and energy consumption. By Mark Pitchford, Field Applications Engineer, LDRA.
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, and Toyota 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.
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 defence against hacker intrusion is foremost. And, 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.
Figure 1: The more connectivity exists, the more points of system entry there are for potential attackers to leverage. The increasing levels of standardisation on particular protocols also make it easier for intrusive strikes that can cripple the whole system.
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. So what best practices can minimise the chance of your device providing the weak link for intruder attack?
What standards can offer
The US 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 organisations. Such a list of organisations 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) 14508 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-practise, 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 14508 (also known as the ‘Common Criteria’) defines IT security requirements categorised according to seven Evaluation Testing Assurance Levels (EALs), 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 also 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.
Adding safety as 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 14508 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 14508 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.
Certification management is challenging in any industry, even when standardisation 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 14508, 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.
Figure 2: By applying appropriate automation techniques, development teams can minimise overhead, streamline the transition between project phases, and show requirements traceability to development artefacts.
Fortunately, certification management tools now exist that automate and coordinate the processes and programming standards required, even when their developers must comply with multiple standards at various levels of safety and security. These tools boil compliance management down to the fundamentals. ISO 14508, for example, demands requirements traceability, static analysis, and dynamic analysis. Tools and tool chains now integrate to automate the labour-intensive aspects of all three objectives (Figure 2).
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 labour-intensive task.
Figure 3: Requirements traceability is a vital factor in meeting security and safety standards. Dynamically linking high-level requirements to source code and verification tasks immediately updates the traceability matrix to provide process transparency.
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 3).
Figure 4 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.
Figure 4: The Requirements Traceability Matrix (RTM) plays a central role in a development lifecycle model. Artefacts 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.
The ‘requirements’ of how the application is intended to function are often considered distinct from the ‘objectives’ of process standards such as ISO 14508 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 artefacts 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 14508, 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.
Author profile: Mark Pitchford has over 25 years’ experience in software development for engineering applications. He has worked on many significant industrial and commercial projects in development and management, both in the UK and internationally including extended periods in Canada and Australia. Since 2001, he has specialised in software test, and works throughout Europe and beyond as a Field Applications Engineer with LDRA.