Security flaws found in embedded systems in utilities

Unfortunately, in many cases the assessments have not returned positive results. Aged, 30-year-old infrastructure technologies built without regard for today's electronic security risks and deregulation, have combined to cause major security holes in the utility infrastructure.

Much of the equipment used by utility companies contains an important design flaw that can make it vulnerable to electronic attacks. That flaw has to do with the fact that industrial automation monitoring and control systems, whether designed to manage complex local operations or implemented as a wide area network to monitor and control a utility company's transmission and distribution systems, are deterministic in nature.

A deterministic design or determinism simply means when a master system issues a command to a subordinate device, the master expects a response back within a finite period of time. These systems have existed for some time and determinism is still prevalent in today's embedded systems.

To guarantee the response time between interconnected devices, most industrial automation (IA) systems were designed to operate on isolated networks such as twisted pairs, current loops, private leased lines, or dedicated local area networks. For safety purposes, most of these distributed devices employ embedded processors to collect status information from processes or subordinate equipment and/or to control their operation locally.

These IA systems were designed to be operated by a single company or team of maintenance engineers on a secure, privately-owned network. Embedded processors used within these intelligent electronic devices (IEDs), their operating systems and the applications that run on them, have been designed over the years with speed and efficiency as the leading design criteria. As a result, security issues received lesser importance.

The business needs and therefore the operational realities of the companies that employ IA systems, are constantly changing; but the basic design criteria of the IEDs employed by the systems have not.

For example, take the electric utility marketplace. A business reality is deregulation — what was originally one company managing an IA system is now multiple companies. In some cases the companies have a customer-vendor relationship, while in other cases they may actually have a competitor relationship. The operational reality to deregulation is their IA networks are still interconnected, they are still sharing production and business data, and they still share responsibility for the safety, operation and maintenance of the networks. In many cases, two, three or even four different and possibly competing companies share the same equipment and data.

Another business reality is cost cutting — utility companies must find less expensive means to operate their business without sacrificing customer service or safety. The operational reality to cost cutting in an IA system is switching from high-cost leased lines to less expensive public networks such as the Internet or even wireless networks.

Over the last two years the cost of Internet access has dropped dramatically. With the introduction of DSL, a packet-based high-speed connection can be dropped almost overnight to nearly any location. While still logically connected to other utility companies, including competitors, utilities are now facing even more risk to their systems — the hacking and cyber-terrorist community of the Internet.

Operators implementing new packet-based infrastructures are sure to implement firewalls and possibly VPNs to protect their data as it flows between industrial automation masters systems and the end point's intelligent electronic devices, or IEDs.

However, these systems that are being re-routed over the Internet are deterministic in nature, and the Internet is a best-case delivery medium. A simple slowdown in the Internet that frustrates the average user when surfing the Web could be considered a Denial of Service (DoS) attack by a deterministic system, resulting in loss of data and possibly cause shut-downs in factory, power plant or distributed operations.

At a recent industry summit discussing security issues for utility companies, it was shown just how easy it is for a hacker to craft a rogue packet, based on well publicized Internet-based attacks, to lock-up a firewall, a VPN appliance, a master station or even an IED.

Though not too impressive from a demonstration viewpoint, the exercise depicted the underlying vulnerabilities of the systems and how simple it could be to shutdown the communications channels between facilities thereby creating a very real safety or reliability issue. The embedded processors and their operating systems employed in today's IEDs were never designed to keep pace with the number of new attacks, from outsiders as well as insiders, which are being published on a daily basis.

Bump- in-the-wire

One way to address the issues raised by deterministic systems is with bump-in-the-wire technology. The concept is based on a device placed between a particular piece of equipment and a modem, allowing an after-market security device to be put on the communications link.

These devices incorporate very sophisticated cryptographic technology. This is not because the equipment needs extremely high security, but because these products can perform their tasks at very high speeds, without interfering with the deterministic functions of the equipment being protected.

To address the operational realities faced by companies that employ IA systems, vendors of IEDs, embedded processors and RTOSes need to raise security issues to the forefront in future design criteria.There are several steps embedded systems developers can take to improve the designed-in security of their products:

1) Boot into a known secure state to eliminate the risk of unpredictable operations.

2) Evaluate and only execute authorized software or firmware to reduce the risk of compromise by viruses or Trojan horses.

3) Employ robust and scalable authentication and authorization, focusing on roles and policies for automated processes as well as large numbers of maintenance, security and vendor personnel.

4) Be able to be managed securely both locally and remotely.

In addition, embedded systems' operating systems and applications need to be updated securely using code authentication techniques to validate that the update is from a trusted source and unchanged.

It will also be necessary to implement proven cryptographic algorithms and protocols for encryption, integrity, authentication and authorization to protect confidential data and verify the integrity and source of data or operator commands.

These embedded systems must be designed to perform cryptographic operations in a secure manner, addressing key generation, key usage, key exchange and non-exposure of private key materials. It is also necessary that they be designed in such as way as to separate data types, such as so-called red data and black data, to eliminate the possibility of confidential information leakage.

The human side of the design should not be ignored either. Any system employing an embedded network of devices, needs to have provisions for an audit capability to assist security personnel looking for attack profiles or attack forensic information. The physical security of such devices should not be ignored either, with tamper-evident enclosures or active monitoring capabilities for physical and electronic attacks

Most importantly, they should be designed to meet, federal and iternational security standards such as Common Criteria and FIPS Publication 140-2.