How to secure the smart grid and SCADA Know the areas of the smart grid that demand extra care when it comes to security measures and why these particular areas are vulnerable today. By Johan Dams Technical Director WRD Systems We usually read articles about stolen Social Security Numbers, stolen credit-card information, data theft and other security breaches in a wide variety of businesses and organisations. The energy sector is not immune to these risks. With the increasing implementation of smart-grid technologies and the use of networked devices therein, the energy sector becomes an ever more viable and attractive target. This article identifies areas of the smart grid that demand extra care when it comes to security measures and why these particular areas are vulnerable today. Although the smart grid is much more than just remote meter reading, we want to start this paper with a security example that exists today and is that implemented on a large scale. Automatic meter reading (AMR) and the buildup towards advanced metering infrastructure (AMI) has already been deployed in the United States and forms an interesting beginning for the security discussion. Remote metering makes it easier and more efficient for energy providers to bill their customers. Timely read-outs of the meter, such as once a day, allows for accurate and up-to-date information on customer usage patterns, which in turn allows for energy companies to optimise their energy generation process. The meters themselves are equipped with a transmitter/receiver capability, which either can be read remotely from a handheld device or over the air over long distances using RF technologies. Initial observations of existing smart meters Some of the issues we found during the inspection of such a widely deployed meter include, but are not limited to: • No encryption of the data sent or received by the meter • No authentication procedure between meter and local / remote reader • Potential to read and write (modify) the program code stored in the meter electronics Meters that do implement some level of authentication and password protection have serious flaws in their implementation. For example, a metering protocol such as IEC60870-5-102 (which is luckily not widely adapted, but serves fine as an example) have functions to read data from the meter that do not require authentication and another set of functions such as for example the disconnect that needs a password. One particular meter we reviewed allowed one to retrieve said password using the unprotected read function, making the authentication for the disconnect function pointless. Other such findings have been previously published by security researchers, such as in C4 Security's article "The Dark Side of the Smart Grid -- Smart Meters (in)Security."1 Another example that presented a highly publicized smart-meter hack is described by Mike Davis in "SmartGrid Device Security, Adventures in a New Medium."2 While one might assume that the data contained on and transmitted from a simple device such as this is nonsensitive, this is definitely not the case. Usage patterns obtained from the device provide valuable information which can indicate when someone is physically present and therefore can be utilised to determine the time frames when the location is unoccupied. This information can be easily gathered and used to plan a break-in. If suddenly usage patterns decrease, this can be an indication that the occupants are on holiday. All this information can be easily gathered without having to have a physical presence near the target house to monitor for such patterns, by deploying an electronic data logger somewhere in the neighbourhood. Indeed, it becomes easy to monitor multiple targets at once. Furthermore, many of these meters contain a remote 'disable' feature, which can be used to remotely disconnect the supply of electricity, for example because the end user did not pay the bill. Since the meter does not have adequate security measures in place, it is straight forward to exploit this feature for example to turn off the electricity (and possibly security systems) to a house, perhaps for vandalism, or because it is targeted for robbery. Since the on-board meter electronics are not well protected due to an easily bypassed tamper protection, the code running on the meter could be downloaded. This means that an attacker can study the code to develop a deep understanding of its operations, and look for potential security issues. Additionally, since these devices have few resources and are design for low power consumption, features such as a proper random number generator, cryptographic accelerators, and other features we've come to expect are often missing and can compromise security. Even without physical compromising the meter, side channel attacks and others are possible. One particular example we found is where a communications module is used and whereby the security key has to be transmitted over a physical bus from the main processor to the communications module, allowing it to be easily intercepted. This has also been demonstrated in Travis Goodspeed's article.3 EE Times-India | eetindia.com Copyright © 2013 eMedia Asia Ltd. Page 1 of 4 More than meters Of course, the smart grid is much more than just metering. Figure 1 shows the different levels from a high level, all of which need special care when it comes to security. We'll discuss these other domains in the next section. Figure 1: The smart grid. Security Security is one of those areas that very often gets ignored because it's seen as an overhead expense, not as something that adds value and can be charged for. It also slows the development process: it's not something that can be added on at a later time, it has to be part of the overall design. Security should be a focal point, but currently it's not due to cost and time-to-market pressure. Security must be a planned up front investment. Many of the device manufacturers have no real experience with security in the first place -- it has never been an issue in the past. In addition, developers do not really think in terms of security. They might implement some basic security as a bare-bones solution, but it's usually nothing that will hold up for a long time. The more the smart grid becomes a reality (the complete grid, not just smart meters), the more it will become a primary target for attacks. Security is an area where knowing a little on the topic is extremely dangerous: people implementing cryptography (or worse, rolling their own) think it works, without realising or even being able to identify the gaping holes they left behind, or just not being able to see that their implementation is wrong due to lack of knowledge on the subject at hand. When we see the current security problems in other sectors, such as at banks, medical facilities, credit card numbers that get stolen, Social Security numbers in plain sight unencrypted, the ease with which password databases seem to be hacked, and so on, it's obvious to us that not even the basic concepts (like a password with a proper salt and proper password hash function) are known, understood, and properly implemented. And this is in a business sector that has years of experience with this matter. To believe that the smart grid will be different is wishful thinking. Securing SCADA We can already see some of the problems today in a different segment of the smart grid: SCADA systems. SCADA systems form the core control systems and monitor the power plants and other large infrastructure. At some point in the past, these systems became interconnected. First over private networks, and later over the public Internet. However, these systems were never designed with that capability in mind. They have never had strong security components integrated, since they were never planned to be connected to a public network where anyone could attempt to hack into the critical areas. The issue is that these systems today are migrating to world of open IT standards such as TCP/IP, Ethernet, etc, to communicate and interact. While this also allows them to inherit the security mechanisms from that world, these mechanisms are in our view not the proper ways to secure critical infrastructure. Assuming your security implementation is good just because other people use it and have not run into problems, does not mean your security is truly good. When security on critical systems fails, it does not just break a single banking site or corporate network -- breakage can mean that entire power-grid segments will fail, with much more serious results. Similar conclusions were drawn in "Security of power grids: a European perspective."5 EE Times-India | eetindia.com Copyright © 2013 eMedia Asia Ltd. Page 2 of 4 Security is also not just about encryption. Even if the data itself is encrypted, there can still be tell tale signals that leak out that might be able to allow an attacker to identify, learn, and abuse. The communication infrastructure should ensure that information leaks of this kind do not occur, in order to guarantee that the communicating entities remain anonymous. For example, while a secure connection with a bank might not be easily broken in itself, other network traffic that is present and which might have nothing to do with the banking itself can leave clues and critical information behind. The same is true for computers running SCADA systems or other devices on the smartgrid network. Finding solutions to these problems requires specific expertise and costs money to do properly. However, these solutions do not necessarily eliminate other types of attacks such as denial of service attacks. Especially when coordinated, these kinds of attacks can easily disrupt normal operation in a network. If there are time critical aspects (such as is the case with SCADA, IEC61850, and others), this can severely impact the operation of the distribution grid. Also, since smart meters and other embedded systems are generally very low-power devices with very little resources, setting up a proper defence at their end is nearly impossible. Attacks can include malformed packets being injected in the network and these can disrupt normal operations because the embedded devices do not know how to properly discard them, perhaps because they don't have enough input validation code. The use of a generic operating system, such as Microsoft Windows, brings with it all the security issues that corporate network administrators experience today. A generic operating system is not a intelligent choice to use in critical infrastructure. Recent attacks against SCADA systems, such as Stuxnet, have been in part very successful due to the target systems running generic operating systems, for example it is possible to compromise a system just by inserting an infected USB stick. Furthermore, while a corporate network is relatively isolated, the smart grid is much more distributed, and therefore becomes a very large network that is difficult to manage when it comes to security. Existing tools simply do not scale well to this magnitude. Substation automation Let's take IEC 61850 as an example. It is an international standard which provides a very detailed specification of a layered substation communication architecture. This architecture is composed of abstract definitions of classes and services independent of underlying protocol stacks and deployment platforms. A simplified overview is given in figure 2. The standard was originally developed for substation automation and its models are applicable to intersubstation communications. The standard also provides for substation-to-control-centre communications, distributed automation communications, metering, equipment connection monitoring and diagnosis, and intelligent electronic device (IED) to engineering systems communication. Figure 2: IEC 61850. It was not however, developed with security in mind; that capability is described in the separate IEC62351 standard. It relies on SSL/TLS for message confidentiality and on commonly deployed hashing algorithms and public key cryptographic algorithms for integrity and authentication. However, IEC 61850 has very strict latency requirements -- less than 4ms. Together with the need to increase the key length over time, we see that the amount of time to encrypt/decrypt and authenticate adds to the latency challenge. EE Times-India | eetindia.com Copyright © 2013 eMedia Asia Ltd. Page 3 of 4 To prevent this, we could opt for faster processors in IEDs, processors with embedded cryptographic accelerators, ASIC based co-processors etc., however there are serious constraints (see Hohlbaum's article)5 that limit these potential improvements, such as: • IEDs are enclosed to prevent dust and dirt, making fans useless for cooling the faster devices. • Processing power will always be limited when compared with the state of the art for which many cryptographic protocols are designed. • A typical IED has a life time of ~10 years and it must be backward compatible. • Cost impacts of some of the hardware decisions can be prohibitive. • All the authentication certificates need to be handled properly somehow. A practical attack on a IEC 61850 GOOSE message, used for trips, alarms, interlocking and status, can be performed as explained in Juan Esteban Hoyos Pareja et. al.4 Even without the ability to decode and spoof the messages, the network could be disrupted in such a way that it becomes congested (by use of a denial of service attack), causing messages to be delayed, or not to be delivered at all. Since latency is very important (recall < 4ms), this can lead to serious problems. Furthermore, IED and other devices' software implementations could be vulnerable through buffer overrun/overflow exploits. These exploits are very well known and form attack vectors through which virus and other malware can be injected, or which can simply cause the device in question to freeze or become unstable. When these kinds of problems are identified and the device in question is already deployed, they can be fixed through remote firmware updates -- after all "what is considered secure today may be proven otherwise tomorrow." However, this mechanism in itself presents itself as an attack vector if the mechanism can be exploited by an attacker. For example, an attacker could use implementation faults in the update mechanism to upload a modified and compromised version of the firmware and prevent future legitimate firmware updates. Special needs A chain is only as strong as its weakest link, and the smart grid as envisioned today is a very long and diverse chain indeed. Security issues exist at several levels in the smart grid, starting at the smart meter in the homes of consumers and continuing all the way to the SCADA systems monitoring the power generation and including the substations in between. All these systems are very different from one another, meaning that security solutions implemented at one level do not translate directly to all other levels. This stands in sharp contrast to the traditional corporate network and thus the solutions developed for these traditional computer networks are not directly suited and probably not the best match for the smart grid. Code that is deployed inside smart meters and other devices can contain various security problems that are not identified during testing. It is therefore crucial that thorough code reviews are done by security experts within the embedded field. These reviews need to be done independently from the core development team to eliminate bias and to make sure that an independent set of eyes can do the review, not someone who has been working on, tested, or designed the software in the first place. Furthermore, the deployment of proprietary protocols and custom security implementations that have not been subjected to peer review by the security community do not help at all. These practices should be abolished and open standards have to be developed across all aspects of the smart grid. Finally, let's not forget another important link in the chain: the human factor. It is important that employees have adequate training in order to prevent social attacks, something for which there is no technical solution. References 1. C4 Security. "The Dark Side of the Smart Grid -- Smart Meters (in)Security," 2009. 2. Davis, Mike. "SmartGrid Device Security, Adventures in a New Medium," Black Hat USA 2009. 3. Goodspeed, Travis. "Extracting Keys from Second Generation Zigbee Chips," Black Hat USA. 4. Juan Esteban Hoyos Pareja, Timothy X. Brown, Mark Dehus. "A Practical Attack on Cyber-infrastructure," University of Colorado, Boulder, 2012. 5. Hohlbaum, Frank, Markus Braendle, and Fernando Alvarez. "Cyber Security Practical considerations for implementing IEC 62351," ABB, 2010. 6. Leita, Corrado and Marc Dacier. "Security of power grids: a European perspective," Symantic, 2012. About the author During his professional career, Johan Dams has been involved in many projects around the world in the fields of embedded systems, software engineering, and security among others. He is a published researcher working in the fields of cryptography and robotics and has over ten years of experience running software teams. He is the systems technical director at WRD Systems and is a lecturer at the Vaasa University of Applied Sciences in Finland. EE Times-India | eetindia.com Copyright © 2013 eMedia Asia Ltd. Page 4 of 4