Lately, the news has been full of headlines and warnings about nebulous cyber threats to the power grid. We hear that hackers from other countries have “embedded software” into critical systems that monitor and control various aspects of the grid and that we are vulnerable to blackouts precipitated by these evil forces. No one who is knowledgeable about cyber crime disagrees that there are myriad hacker groups constantly looking for ways to make a dishonest buck, and there is ample evidence of foreign governments that would like to inflict harm on our industry and innocent people the world over. Yet often the people making these pronouncements – although presumably well intended – are less technically informed than might otherwise be appropriate for issuing such sweeping alarms.

For example, the notion that someone hacking into a company’s web server is equivalent to having a control system ‘hacked’ is simply not true in the vast majority of cases. Indeed, industrial automation experts have always distrusted the reliability of computers. And  despite the fact that computer reliability is extremely high compared to most manual methods, the vast majority of mission-critical systems are designed to be exceedingly fault-tolerant. This can be accomplished by various methods and practices including measures ranging from full redundancy (often with automatic failover software) to totally replicated equipment at alternate facilities and/or back up by one or more layers of independent safety equipment.

The reason for this protective stance being initially developed was quite basic: Industrial processes – whether generating or transmitting electric power, processing hydrocarbons or a part of countless other activities – can result in valuable equipment being damaged or entirely destroyed and people can be harmed or even killed should things go badly wrong. And although fault tolerance isn’t in itself a sufficient security blanket, it is often an effective first line of defense and an indicator that there are problems requiring further attention. This is not to say that we shouldn’t be concerned enough to take steps to strengthen our critical systems and infrastructure – naturally, we must. But such actions should be focused on the areas of greatest vulnerability and risk, initially targeting cyber assets whose compromise would yield unacceptable consequences that may not be readily preventable by routine fault detection and operator vigilance.

When discussing cyber threats to critical (cyber) assets, we must first understand the characteristics of – and especially the differences across – various classes of cyber assets. My definition of a vulnerable cyber asset is any intelligent system or device that has remote communications capabilities enabled (e.g., a DCS or SCADA system, a protective relay, an RTU, a smart meter, etc.). Communications may be via wireless technologies, LAN or WAN technologies or even conventional analog telephone lines. (Any such device that does not have a communications interface cannot be attacked without physical access to that device, so I will not consider them in this instance.)

We can further break these assets down into three (3) classes: 1. Devices having a fixed set of executable commands; 2. devices that also have some capacity for remotely configurable settings and functions; and 3. devices that also can be remotely reprogrammed to some degree.The first class of devices cannot be infected with malware because it is not pos­sible to alter their programming remotely.

The most that can happen in those cases is that unauthorized commands are sent to, and executed by, the device(s), which could ostensibly have dangerous results. The same is generally true for the second class of assets, but those types of devices may have remotely alterable configuration settings that significantly change the operation. A good example would be changing or disabling the protective functions of a relay. The third class of assets does support – or can at least be tricked into allowing – remotely alterable programming (e.g., a ‘server’, a router, a smart printer, etc.), and thus, can be infected by changing its programming.

Also, one must be careful about making sweeping judgments about which class a particular asset falls into. For example, RTUs can fall into any or all of these classifications. Unfortunately, however, most devices in the first two classes (and some in the third) have simple communication protocols that do not incorporate any facility for mutual authentication or encryption. That means that they can’t tell where a message actually comes from, so anyone who taps into their communication channel can potentially send fraudulent messages to those devices.

Encryption allows a sender and receiver to ‘scramble’ their messages so that an attacker can’t generate valid-looking fake messages unless they can decipher the encryption scheme. Today a range of products exists that can be placed into the communications channel – be it a phone line or a LAN – to add both authentication and encry­ption capabilities. (Authentication is a process that lets the device verify the sender of a received message, thus, allowing it to reject those from unauthorized sources.)

For IP-based LANs and WANs there are a range of network devices, such as switches and routers, which can be configured to perform both authentication and encryption and, in some cases, even act as a firewall. For utilities that have pushed IP networking out to the field (e.g., to substations and generating facilities) these devices can add another layer of security.

Many utilities have potentially dangerous remote dial-up telephone access into their substations that enables communications between the IEDs and remote users who need to access those devices. Ordinarily, dial-up circuits create a minimally secure or, in many cases, totally insecure “back door” into any subsystem having such remote access ports. One way to eliminate this security hole is to implement a VPN (virtual private network) connection between the remote users and the substation equipment.

Creating a VPN implicitly adds authen­ti­cation and encryption, essentially eliminating unauthorized access. There are “substation automation” products designed to provide this capability for either dial-up phone circuits or actual IP network connections – the latter for utilities that have extended IP networking to their substations. To further enhance security, some utilities have also incorporated link encryptors (sometimes referred to as “bump-in-the-wire” devices) on their RTU polling channels as well, thus, eliminating the possibility of attackers tapping into the communications paths and sending fake commands to the RTUs.

One area of serious concern is the microcomputer-based components being used to develop and build what is now commonly called the Smart Grid. For the concept of a smart grid to be ultimately successful, there must be communications from the generation management and scheduling levels all the way through the power delivery network to electric appliances at the customer premise. These distributed intelligence devices are also placed in communication networks at various levels along the grid in a variety of applications ranging from distribution automation to advanced metering infrastructure and many others. All of this implies a growing need for security equipment that is inherently secure and resistant to compromise to be installed on communications networks.

Although most control system providers – manufacturers and integrators alike – insist that they are addressing the vast majority of these issues, many existing hardware, software and communications weaknesses persist. Indeed, new vulnerabilities are constantly being identified and many questions about the application, adequacy and costs of security remain. The technologies required to address these concerns do exist, and NIST (National Institute of Science & Technology) has made an initial recommendation for possible standards, the latter of which will be examined and discussed in a future column.

About the Author
Dr. Shaw is a Certified Information Systems Security Professional (CISSP) and has been active in industrial automation for more than 30 years. He has authored two books (“Computer Control of Batch Processes” and “CYBERSECURITY for SCADA Systems”) and continues to write  extensively on a wide range of technical topics, issues and tends. He is currently Principal & Senior Consultant for Cyber SECurity Consulting, an industrial automation, security and technology firm.Inquiries, comments or questions regarding the contents of this column and/or other security-related topics can be emailed to timshaw@industryconsulting.org.