The use of supervisory control and data acquisition (SCADA) became popular in the 1960s due to the expense of manual monitoring and control and an increase in the complexity of the systems. The blackout of 1965 in the northeastern United States prompted the U.S. Federal Power Commission to urge passage of the Electric Power Reliability Act of 1967, which would have mandated closer coordination among regional coordination groups. The National Electric Reliability Council was formed in 1968. These events also drove the development of large energy management systems for transmission SCADA. Early SCADA protocols were built on electromechanical telephone switching technology. At that time, the goal of communications security was to ensure that the command got to the mechanism for control (this security was typically implemented through repetition).
Subsequently, SCADA moved to digital communications, and the use of parity bits and checksums became prevalent for error checking and is still common today in the field. Many protocols were in use; typically, each manufacturer created its own, and some end users did the same. The network architecture was typically hierarchical, with the substations isolated. In the 1980s, a number of groups began working toward a common set of standards for protocols. The introduction of master stations and RTUs necessitated local area networks (LANs) and wide area networks (WANs), both of which can utilize more than one linking technology (e.g., satellite, telephone, wireless, power line carrier, fiber optics, or microwave) to connect RTUs to master stations. The RTUs typically perform actions requested by the master station and report out-of-bounds conditions; some also perform local control, logging, and reporting. This diversity of communication media and protocols has left its legacy in the field and has made it difficult to secure the infrastructure.
More recently, there has been a merging of the automation and business networks, with a linking of the automation WAN to the corporate network and, in some cases, an extension of these networks into customer sites. The use of intelligent electronic devices (IEDs) has also become common and has caused yet another shift in the communications architecture. Traditionally, the system was serial and hierarchical in nature: users communicated with the substation through an RTU or data concentrator (which then communicated with meters, relays, equipment, and so on), or users communicated directly with feeder devices (reclosers, switch controllers, and other equipment). With the advent of IEDs, there is much more networked information, which then flows up to substations and/or feeder devices using serial, direct-connect, wireless, and packet-switched circuits. The substation communication is often through a router on a LAN, along with the human-machine interface (HMI), data concentrator, equipment, and relays and may offer remote access to feeder-level devices. Figure 1 illustrates a typical architecture for modern SCADA systems. Since many electric grid systems are now built using traditional IT hardware and software, their attack surface is much larger, making them more vulnerable to cyberattack. With that in mind, deployed systems use a layered protection approach, with multiple levels of firewalls and “demilitarized zones,” as seen in Figure 1.
Even with this type of layered protection, the system is still vulnerable. The National Electric Sector Cyber Security Organization (NESCO) has published a white paper, “DNS as a Covert Channel Within Protected Networks,” that demonstrates DNS data exfiltration techniques that do not require direct connectivity to any external resource from the targeted device. An attacker can get information from the RTU out through the corporate firewall and create a communication path back to that device, highlighting the need to watch outgoing firewall data.
There is an increasing amount of evidence showing that attackers are now focusing on control systems. They are operating with varying motivations and intentions, including cybercrime, extortion, and warfare. In the area of cyberextortion, for example, we have been warned for years about the increased cyberextortion being practiced on electric utilities in Africa, Europe, India, and Mexico, where criminals threaten to cut off power if they are not paid. In a recent paper published by McAfee and the Center for Strategic and International Studies (CSIS), “In the Dark, Crucial Industries Confront Cyberattacks,” 200 industry executives from critical electricity infrastructure enterprises in 14 countries were surveyed. The survey group was composed of IT executives in the energy, oil and gas, and water sectors whose primary responsibilities include IT security, general security, and industrial control systems. According to the paper, “One in four survey respondents have been victims of extortion through cyberattacks or threatened cyberattacks.” And it follows that once a criminal finds an avenue of attack that works, the attacker tends to use it again and expand the list of victims. Nation-states have also been accused of using cyberattacks on control systems; such intrusions include the Russian cyberattack on Georgia’s pipelines and the alleged 2007 Russian attack on Estonia. In Kenneth Geers’s paper “Cyberspace and the Changing Nature of Warfare,” the author outlines the strategic reasons why cyberwarfare is on the rise with respect to the electric power sector, including the fact that the Internet is vulnerable to attack. Many may argue that the electric power system is not on the Internet. In many cases it is, however. Even more common is the scenario in which a device without a direct Internet connection is connected to the Internet at some point in its life cycle for software or firmware updates, configuration, or maintenance. Or the device may interface with another device (e.g., a laptop or USB drive) that has been on the Internet and carries an infection or malicious code.
The methods used for a cyberattack vary depending on the attacker and the motivation. Some attackers are physically able to access a site through local surveillance, by browsing wireless networks within close physical proximity or even by accessing the site physically as part of the cyberattack; some perform the entire attack from a computer that could be 10,000 mi away. In any case, typically the first step is to gather as much information as possible through publicly available sources (say, from the Internet). The Internet can provide names, physical layouts, installed equipment, data useful for social engineering, and port scanning for other data. After this reconnaissance, adversaries target specific components and systems using malware that exploits vulnerabilities to gain access to the system. There are many attack vectors for obtaining access to a SCADA system, from a brute-force attack through the business network to intercepting nonencrypted communications and playing them back, either to mimic control actions or to mask from the operator’s view the control actions that are really being performed. Attacks can vary from the relatively simple—such as that of the disgruntled former contractor who used existing privileges and gained access to the control system of a sewage treatment facility in Australia, then flooded the surrounding area with millions of liters of untreated sewage—to the Stuxnet worm, which was purportedly an attack on the Iranian nuclear industry using highly sophisticated malware and several zero-day vulnerabilities.
In the rest of this article we look at cybersecurity objectives and properties and discuss methods for minimizing cyberattacks as well as detecting and responding to attacks that do succeed. We then describe some cryptographic protocols commonly used to realize desired security properties such as confidentiality and integrity. With this background in mind, we explore the challenges of realizing secure control systems and some approaches that might work. We discuss control system security in general and use the example of modern SCADA systems to illustrate certain ideas. Finally, we review some key ongoing efforts in the control system security area involving the U.S. government, industry, and academia.
What Are the Goals and Objectives of Cybersecurity?
Cybersecurity tools and techniques are aimed at achieving three primary properties, namely, confidentiality, integrity, and availability (CIA). Confidentiality is the property that ensures that only authorized entities have access to sensitive information. For example, electricity market data and transaction information are considered sensitive and should only be accessible to authorized market agents and not to other entities such as system operators. Integrity is the property that ensures that any unauthorized modifications to data and information are detected. For example, an adversary should not be able to modify sensor data without detection. Availability is the property that ensures that critical systems and information must be available when needed. For example, communication networks supporting wide area measurement systems must be available to deliver data and information (e.g., synchrophasor measurements) even in the presence of malicious activity such as an adversary launching a denial-of-service (DoS) attack . For critical infrastructure such as the electric grid, availability and integrity are typically considered to be more important than confidentiality.
Other security properties of interest to control systems include nonrepudiation and privacy. Nonrepudiation involves assurances that a particular command or message was actually sent, as the receiving entity claims, and is typically realized using digital signatures. Privacy, as a special form of confidentiality, refers to adequate protection of personally identifiable information and functions so that only authorized entities have access to this data. For example, consumer energy consumption data need to be kept private as AMI systems are realized. Achieving these properties for all computing and communication systems supporting the electricity grid is a major research, development, deployment, and maintenance challenge.
A common approach to achieving these properties is to design, develop, and deploy cybersecurity technologies for protection, detection, and response. Protection systems devise security components such as key management, authentication and authorization, and perimeter defense that help ensure the CIA properties against a range of attacks. For example, encryption tools help provide confidentiality, cryptographic message authentication tools help provide integrity, and redundancy helps provide availability. Secure software and hardware development techniques are also an essential form of protection. Given the complexity of today’s systems, vulnerabilities are likely to remain after development that can be exploited by adversaries despite the use of advanced protection systems. To deal with this, detection tools observe network and system behavior to identify malicious activities and attacks. For example, intrusion-detection systems may look for malware signatures on the network. Finally, response tools are employed to enable administrators to deal with detected attacks and activities. For example, such tools may allow dynamic changes in firewall policies in order to limit information flow to and from adversaries to contain an attack. Collectively these protection, detection, and response systems create an ecosystem in which secure and trustworthy operations can be executed. Typically, these technical solutions are used in conjunction with appropriate training for people and the use of well-defined processes to form a comprehensive solution.
What Are Some Common Security Components?
Earlier, we discussed the three objectives of security, namely, confidentially, integrity, and authentication. Cryptography is used to provide confidentiality and integrity.
The workhorse of secure communications systems is symmetric cryptography. This is often called secret-key cryptography because the keys, which are the same at both ends of the communications link, must be kept secret. These algorithms are frequently identified by the length of their keys, e.g., the 128-bit Advanced Encryption Standard (AES). They can be thought of as codebooks that take a block of input data and encrypt it in a unique way based on the secret key. Figure 2 illustrates how a symmetric cipher could be used to protect data moving from a control center to a substation. The process unfolds as follows:
- The secret keys are generated, transported to the ends of the communications link, and loaded into cryptographic devices (often part of a larger computing device) so that they are only known to the authorized sender and receiver. If attackers are able to obtain a copy of this key, they could also decrypt the data, rendering the system insecure.
- The sender’s plaintext message is then passed through the codebook algorithm, where it is transformed into ciphertext. The output of the codebook is a function of both the key and the plaintext.
- The ciphertext is transmitted over the communication link.
- An eavesdropper listening in on the communications is able to intercept the ciphertext, but without the key the eavesdropper cannot decrypt the data and recover the plaintext. Thus, the symmetric cryptography provides confidentiality.
- The receiver passes the ciphertext through the codebook algorithm in reverse, using the secret key. The output of the codebook is the original plaintext.
Securely distributing the keys for symmetric-key cryptography is cumbersome, so asymmetric-key (also called “public-key”) cryptography, a newer form, is used to transport the secret keys and perform other types of authentication. Three common public-key systems are RSA, El-Gamal, and elliptic curve cryptography (ECC). The underlying mathematics of these algorithms are significantly different. All three, however, have a private key used to encrypt or sign a message and a related public key used to decrypt or verify messages, as shown in Figure 3. The originator of a message (e.g., a control center) signs the message with its encryption key, which is kept private. It then distributes its public key to everyone, including potential attackers. The legitimate receiver (e.g., a substation) uses the public key to verify that the message indeed came from the claimed source. An attacker could also use the public key to verify the message. But if an attacker attempts to forge a message, the verify operation will fail. Thus, public-key cryptography can be used to provide integrity and nonrepudiation. Nonrepudiation lets a third party verify that a message came from the entity holding the associated private key. Public-key cryptography may also be used to provide confidentiality for small messages (e.g., a key for symmetric encryption) by encrypting them with the public key and then having the intended recipient decrypt them with its private key.
Hash functions, such as the Secure Hash Algorithm with 256-bit output (SHA-256), are used to produce a mathematical fingerprint of a message or file. The hash function takes in a file of arbitrary size (often quite large) and produces a fixed-length output. Hash functions have the following properties:
- Given a file and its corresponding hash, it is very difficult to find another file that will produce the same hash output.
- It is very difficult to produce two files that when hashed will yield the same hash output.
The hash output may then be signed using asymmetric cryptography. The resulting signed hash lets a receiver check the integrity of a large file by recalculating the hash and comparing it with a hash signed with the private key of the sender.
Certification authorities are organizations that verify the credentials of a user, device, or software and then use asymmetric cryptography together with a hash function to issue the entity a digital certificate (e.g., under the X.509 standard) that may then be used for authentication over a network. Public-key infrastructure, using certification authorities, hash functions, and of course public-key cryptography, is often used to build authentication and key management systems.
Cryptography is helpful in addressing many security issues. But the use of cryptography within the power grid is challenging for the following reasons:
- Legacy systems often lack the computing power and bandwidth necessary to support strong cryptography. SCADA systems often remain in the field for years, making it impractical to support the newer, more computationally intensive algorithms required as the attacker’s computing power increases over the years.
- Cryptography often relies on random number generators with high entropy. Many embedded devices lack the means to produce good random numbers.
- The key distribution and revocation process can be labor-intensive and prone to errors. This is especially true when multiple organizations are involved in the process. Mistakes made in the key management process may reduce the ability to communicate, which affects availability.
There are many other security functions used to enhance the integrity and availability of systems. Antitamper mechanisms are frequently used to protect hardware accessible to potential attackers (e.g., smart meters). These mechanisms deter the reverse-engineering of devices to recover cryptographic keys or firmware that would disclose how a device operates.
Why Is Cybersecurity for Control Systems Challenging?
There are several contributing factors that make cybersecurity of control systems a challenge. Three of these challenges are:
- the clash between the operations team and IT team cultures
- the porting of legacy control software to common off-the-shelf (COTS) platforms
- the long life cycle of control systems.
The first is a cultural issue. The SCADA system engineers are responsible for the configuration and operation of any process. This includes a requirement to assure that certain control systems, such as SCADA systems, are always available. In many cases, a control system is expected to operate a plant over periods of many years with no shutdown or reduction in product manufactured by that control system. This means that availability is one of the most important requirements for any control system. Today’s modern control systems are built using open-standard IT technologies such as Microsoft Windows–based computers and Ethernet networks that include commercial routers, switches, and firewalls. Because the SCADA system engineers are responsible for the operation of the process, they feel responsible for all of the equipment required to run the process. Because IT systems are now part of the equipment required to run the process, the IT department feels it is responsible for the IT equipment running that process. This leads to a clash between the IT department and the process engineering department. Among the factors contributing to this clash are items related to the management and maintenance of those IT assets. One example concerns the installation of security updates in the IT equipment. IT typically pushes out security updates shortly after they are available, and most security updates require a reboot of the computers being updated. These reboots are usually done at a time controlled by the IT department. A reboot of a control system computer can severely affect a process operator’s ability to operate a process safely, and so the process engineering team wants more control over when the updates are installed.
Another example results from migration to Ethernet networks. Many modern control systems integrate the status of Ethernet components such as switches and routers into the overall system status displays. IT wants to manage and monitor the Ethernet equipment, and this can result in a loss of view of that equipment status to the SCADA operators. One way to sum up the clash is that IT is focused on the protection of the intellectual assets of the company while SCADA system engineering focuses on the protection of the physical assets and manufacturing capabilities of the company. The priorities of the two can easily conflict, leading to a clash between the two organizations.
Standards organizations such as the ISA99 standards development committee have recognized the unique security management needs of SCADA and control systems and are drafting security standards for those systems. The intent of ISA99’s proposed standards is to complement the IT standards that already exist while addressing those areas that need special attention for control systems. The North American Electric Reliability Corporation (NERC), the successor to the National Electric Reliability Council, has also realized the need for standards for control systems that control the generation and distribution of power and has created the NERC-CIP standards, which help guide the owners and operators of critical SCADA power systems.
The migration from proprietary control systems to open systems–based control has also contributed to some of the challenges. The IT industry and the control industry have evolved at different rates. While the IT industry was moving to PCs and servers, the control industry was still producing proprietary systems on proprietary networks. The control industry’s shift to open systems followed that of the IT industry by approximately seven years, and the control system industry is approximately that far behind in understanding how to develop and deploy secure systems. Many security issues that existed in IT systems six or seven years ago are now just starting to appear in control systems. One reason for this is that the way the migration of control systems to open systems occurred was to port as much of the proprietary software to open system–based platforms as possible. Because the proprietary control systems had an implicit trust in the communications among devices in those systems, very few checks were performed in the code. Once ported to an open system, an application or device may become compromised by invalid input. Control device protocols were also developed with implicit trust, meaning that as they were moved to Ethernet, there was no attempt to add such things as authenticated and authorized communications.
Users of control systems expect them to last for a long time. It is not unusual for a control system to operate a plant for a period of 20 years or more. Most operators don’t expect to have to change the control system during that period. This period far exceeds the life cycle of any modern piece of open-systems hardware or software. The IT industry has a turnover rate of new systems every three to five years, while the turnover rate for control systems has traditionally exceeded 20 years. As the control industry evolves further, the turnover rate will have to decrease. This will be a significant challenge for the industry as we move forward.
How Does One Design Secure Systems?
There are several steps that can be taken to design secure control systems. First, consider procuring components that were designed with security in mind. Designing with security in mind means, for example, that the vendor of those components can demonstrate that it has integrated a security development life cycle (SDL) into its development process. The SDL will include security steps at all phases of development. This means there are security requirements for the product. Roles are defined for the configuration, operation, and administration of control systems. These roles should include privileges for each role and identifying how the device responds when a user attempts to perform an operation on the device that the user does not have privileges to perform. Providing a role with only those privileges necessary to perform the associated functions is commonly called least privilege. The device should be deployed with least privilege already configured, so that the end user or integrator does not have to perform any additional steps for the device to be secure.
Many control devices will require security devices in the network that act as compensating controls to assist in securing them. When this is the case, the device specification should define the compensating control, how to configure it, and an explanation of why it is required. The device vendor should be following secure coding practices. Finally, the device vendor should have processes in place to respond to a security vulnerability disclosure if one ever occurs for its product. These are just some of the steps required. There are many good examples of SDLs available, including Microsoft’s Security Development Lifecycle, the Open-Web Application Security Project, and the Common Lightweight Application Security Process.
Once components are procured, system integrators also need to have methodologies for developing and configuring control systems for end users. The system integrator is responsible for integrating all of the pieces that together form a control system. As a control system is integrated, it will consist of multiple devices connected to multiple areas of a process with multiple functions. A model for how a control system is to be configured and information is to flow within it exists within the international ISA-95 standard. This model provides a topology to be applied while designing and configuring a control system. This topology provides a natural defense-in-depth approach to help protect the more vulnerable components of a control system. In addition to ISA-95, the International Society of Automation (ISA) standards committees have formed the previously mentioned ISA99 standards development committee, which is developing the security requirements for industrial automation and control systems. The ISA-99 standards build on the reference models in ISA-95 and create security reference models for a typical SCADA system and a typical digital control system, the two classic types of control systems.
What Is Being Done to Secure Control Systems Today?
It is important to note that if the attackers and attack vectors are studied, a common set of high-ranking vulnerabilities can be created that will significantly affect the success of the attack. There are many good studies that can be found on common vulnerabilities and recommendations. Here are several:
- “Common Cyber Security Vulnerabilities Observed in Control System Assessments by the INL NSTB Program” (November 2008, U.S. Department of Energy)
- “Catalog of Control Systems Security: Recommendations for Standards Developers” (June 2010, U.S. Department of Homeland Security; www.us-cert.gov/control_systems)
- “Common Cyber Security Vulnerabilities Observed in DHS Industrial Control System Assessments” (July 2009, U.S. Department of Homeland Security).
Many organizations and governments have spent millions of dollars and years’ worth of effort in studying and recommending good practices for control systems security. In addition, most vendors today are actively including security in the design of their products. Table 1 provides examples of representative work in this area, rather than an exhaustive list of the many activities currently taking place.
table 1. Representative efforts in the area of best practices for control systems security.
|Type||Description||Title and URL|
|Organization||DHS||Industrial Control Systems Joint Working Group (ICS JWG);
Cross Sector Cyber Security Working Group (CSCSWG);
IT Sector Coordinating Council (IT SCC);
Communications Sector Coordinating Council (CommSCC)
|Organization with enforced standards||NERC||Cyber Attack Task Force (CATF) and several related task forces
Security guidelines: NERC 1300, CIP-002-1 through CIP-009-1
|Publication||National Institute of Standards and Technology (NIST) SP800-53R3||NIST Special Publication 800-53, Revision 3|
|Publication||NISTIR 7628||NIST publication on guidelines for smart grid cybersecurity|
|Publication||DOE-supported and industry-led roadmap||Roadmap to Secure Control Systems in the Energy Sector|
|Working Groups/Research||DOE||Office of Electricity Delivery and Energy Reliability;
Control Systems Security;
Cyber Security for Energy Delivery Systems (CEDS)
National SCADA Test Bed (NSTB)
Draft road map
|Working Group||NIST Smart Grid Interoperability Panel (SGIP)||NIST Smart Grid Interoperability Panel,
Cyber Security Working Group (CSWG)
|Working Group||UCA International Users Group OpenSG||Open SG Security Working Group’s Advanced Security Acceleration Project (ASAP-SG)|
|Standards/Working Group||International Electro-technical Commission (IEC) Technical Committee 57 Working Group 15||Data and Communications Security; focused on security for protocols 60870-5, 60870-6, 61850, 61970, and 61968|
|Standards||AGA 12||Cryptographic Protection of SCADA Communications
Part 2, Performance Test Plan
|Standards||API 1164||Pipeline SCADA Security|
|Standards||FIPS 140-2||Security Requirements for Cryptographic Modules|
|Standards||IEC 62210||Power System Control and Associated Communications—Data and Communication Security|
|Standards||IEC 62351||Power Systems Management and Associated Information Exchange—Data and Communications Security, Part 1 (there are seven parts, all of which can be found on the IEC Web site)|
|Standards||IEEE 1686, IEEE 1402||Standard for Intelligent Electronic Devices (IEDs) Cyber Security Capabilities
IEEE Guide for Electric Power Substation Physical and Electronic Security
|Standards||ISA-99||Manufacturing and Control Systems Security|
|Academic Research||Trustworthy Cyber Infrastructure for the Power Grid||Trustworthy Cyber Infrastructure for the Power Grid|
This article provides an introduction to relevant cybersecurity concepts and issues pertaining to emerging modern electric grid systems. We looked at the history of these systems, the objectives of cybersecurity, challenges in addressing security for control systems, common security tools and components, processes for designing secure grid systems, and some key efforts under way today.
Julie Hull is with Honeywell ACS Research Labs.
Himanshu Khurana is with Honeywell ACS Research Labs.
Tom Markham is with Honeywell ACS Research Labs.
Kevin Staggs is with Honeywell ACS Research Labs.