How to secure the smart grid and SCADA

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