BROWSE BY TECHNOLOGY










RTC SUPPLEMENTS


SPECIAL SECTION

CEO Network Security Panel

Joann Byres, CEO, Byres Security

THE QUESTION: With embedded devices increasingly connected not only to local networks, but also via gateways to the Internet and ultimately to large servers, the issue of security spreads from the servers to even the smaller and resource-limited devices. Where do you see the major vulnerabilities for such diverse networks and what do you see as the effective strategies for securing them?

JOANN BYRES, CEO, BYRES SECURITY

  • Page 1 of 1
    Bookmark and Share

Article Media

Anyone who uses a computer today is all too aware of the numerous security vulnerabilities occurring in commercial operating system and office software. However, most of us don’t realize that vulnerabilities are just as prevalent in hardware used for control in critical systems such as electrical power generation, oil and gas pipelines and water utilities.

Most of these supervisory control and data acquisition (SCADA) system vulnerabilities are not well publicized, but in the course of our research we have seen many industrial devices that are so flawed they could be easily exploited by an unskilled hacker. For example, one Programmable Logic Controller (PLC) failed while being scanned with a standard security port scanning tool, indicating a serious TCP implementation issue. In another case we saw a PLC that could be completely taken over with a simple buffer-overflow attack against the application layer protocol it used for inter-device coordination.

Sometimes the vulnerabilities are so serious that they have significant impacts on production and safety, even without the help of a hacker. For example, on August 19, 2006, the operators at Browns Ferry Nuclear Plant had to “scram” the reactor due to a potentially dangerous “high power, low flow” condition. The post-accident investigation showed that the redundant systems controlling the recirculating/cooling water system failed due to “excessive traffic” on the control network, causing the reactor to remain offline for two days. 

SCADA engineers don’t want their system to be vulnerable to attacks, but most of these devices (and the protocols they use) were designed at a time when security was not a consideration in the SCADA world. Since the primary focus in any SCADA controller is, quite reasonably, control functionality, security design has had to take a back seat over the years. Thus, most SCADA devices and protocols offer no authentication, integrity or confidentiality mechanisms, and can be completely controlled by any individual that can “ping” the device. Nor can they be easily patched or have security features added to them, even when security vulnerabilities are discovered. For example, adding even the most basic encryption technology to all the SCADA controllers in existence is a pipe dream. The existing CPUs do not have the horsepower to support encryption, and the replacement cycle for SCADA hardware is over 20 years. So, while some SCADA devices will be replaced, it is unlikely that all the control systems currently in use today will be able to natively support authentication before 2030. This leaves millions of legacy control systems open to attack from even the most inexperienced hacker.

SCADA security is not achieved by blindly applying IT security solutions, since the goals of IT security differ from those of the process control world. The IT security manager sees data confidentiality as paramount (don’t let those credit card numbers be stolen), while the plant manager focuses first and foremost on human and plant safety. These differences in goals can translate into huge differences in acceptable security practice. For example, using standard password lockout procedures just isn’t acceptable for most operator stations in SCADA control rooms—the default state needs to provide access for the operator, not lockout, the opposite of the IT assumption. Imagine the impact if, during a reactor emergency, the operator panics and misspells his password three times, causing the console to lock out all access for the next 10 minutes. Password lockout is considered good policy for protecting IT servers, but it certainly isn’t going to work in the control room of the average industrial facility.

A common industry response has been to rely on a single firewall to try to completely isolate SCADA systems from the outside world, assuming that all security problems arise from outside the SCADA system, and those that do make it in come through obvious pathways that can be managed by the firewall. Unfortunately, an analysis of 75 control-system security incidents between 2002 and 2007 showed that over half of the attacks came through secondary pathways such as dial-up connections, wireless systems and mobile devices. Many are human pathways such as contractors’ laptops, USB drives and inappropriate employee behavior. Others are communication systems that aren’t based on the typical local area network technologies—e.g., serial and telephone connections to remote process equipment, modems and wireless systems.

Fortunately, the standards bodies responsible for SCADA security, such as the International Society of Automation (ISA) and the International Electrotechnical Committee (IEC), are suggesting a more effective solution. They point out that effective security is created by layering multiple security solutions, so that if one is bypassed, another will provide the defense. Based on this defense-in-depth concept, they mandate a “zone and conduit” security model. A SCADA facility is first divided into a number of different security zones, based on the function, typical users and the potential consequences of failure. Next, security conduits are used to interconnect the zones, with industrialized firewalls or encryption devices managing the conduits. For example, in a refinery, a safety integrated system (SIS) might be in one zone, the process control system in second zone, the data historian in a third zone and the IT network in a fourth zone. Security breaches in each of these systems could result in different consequences, so it makes sense to handle each individually. 

For those devices like PLCs and SCADA controllers, where patching, anti-virus or security solutions aren’t available, the use of low-cost industrial security appliances directly in front of each control device (or group of devices) needing protection is gaining popularity. For example, aviation giant Boeing is currently deploying “SCADA endboxes” in their 777 manufacturing plant as a first stage in a worldwide rollout of a secure automation solution. These industrial security appliances act as security proxies for the SCADA devices, delivering security services (such as encrypted tunnels) to the SCADA controllers, while being able to take advantage of the security infrastructures offered by the IT department such as PKI certificate deployment and Metadata Access Protocol (MAP) policy servers. Without the SCADA endboxes to offer the “translation” of services, the PLCs simply could not be part of the Boeing security infrastructure. 

Going forward, more sophisticated protocols and architectures will be needed to manage these widely distributed security solutions. Protocols such as HTTPS, syslog and SNMP work well for deployments that include dozens of security appliances, but break down when the numbers climb into the hundreds or thousands. And things get even messier when the sources of data needed to make policy decisions can come from a large number of distributed real-time sources such as badge card readers and position location monitors. Boeing is basing their SCADA policy coordination on technologies such as Metadata Access Protocol (MAP), which offer promise in the ability to collect and coordinate large amounts of security information.  

Ultimately, the embedded devices used in SCADA systems will be able to be secure on their own. But that day is still many years off, and until then, the use of  SCADA endbox-type security solutions will be needed to fill the gap and protect our critical infrastructures.

Byres Security.
Lanzville, BC.
(250) 390-1333.
[www.byressecurity.com].