Securing supervisory control & data acquisition systems
Abdo Y. Saad
In the wake of the Sept. 11 terrorist attacks on the World Trade Center and the Pentagon, more companies throughout the United Stated and most likely throughout the world are going to reassess their security and back-up plans. Plans that were already begun and shelved, for one reason or another, are going to be pulled from the dusty drawers and new ones will be created.
Supervisory control and data acquisition (SCADA) systems monitoring and controlling the infrastructure networks throughout the nation should undoubtedly be given serious attention. After all, SCADA systems lag behind others when it comes to security.
SCADA systems range from the simple ones such as monitoring an office climate to the very complex such as monitoring and/or controlling vast networks of gas and oil pipelines, energy, telecommunications, water and waste control, and nuclear power plants. These systems have evolved over the years, from limited tone telemetry systems to multi-functional ones covering a large number of different users and organizations. This evolution has left these systems more exposed than ever due to the increased exposure and use of the Internet. Efforts must be made to keep them secure in the future in order to protect the whole operating environment and the national grid.
SCADA systems control and monitor in real-time a variety of very critical devices and stations such as compressors, regulators and remote operated valves. An inside or outside security breach could have dire consequences.
In general, SCADA systems have made the leap from proprietary systems to open architecture ones; they run on different platforms, communicate with different types of remote terminal units (RTUs) using a variety of communications protocols, and spanning several networks.
It is true that SCADA systems have been historically secure. This is, to a great extent, due to the fact that these systems have been isolated physically as well as electronically. They have been for the most part, stand-alone systems on isolated networks serving isolated control room environments.
Recently, this picture has been in a constant state of change, however. SCADA systems have had to be connected to other corporate networks and used more heavily by non-controllers such as accountants, traders, engineers, planners, and technicians.
Although it has been generally secure and has never had to deal with any serious break-ins, the SCADA community has already started to confront the issue of cyberterrorism (1).
[ILLUSTRATION OMITTED]
Physical security is definitely of paramount importance but securing IT systems is very important as well. Breaking into IT systems has the potential of causing a tremendous amount of damage to the infrastructure ranging from serious shutdowns to blackouts and business interruption, let alone the resulting snowballing effect.
Undoubtedly, attacking physical targets has created the most terror but with ongoing efforts to augment the physical security fortifications, cyber terrorism will likely increase in intensity and frequency as the Internet remains highly vulnerable not to mention the politically motivated cyber attacks and the business (trade secrets) spying. Also, the utility systems are becoming increasingly more vulnerable for the amateur type of hackers; no extensive and rare skills are needed anymore for some types of hacking.
Developing and implementing security features have been progressing at a very slow pace (2). The SCADA software industry in general has not exhibited much enthusiasm to make security pervasive in SCADA systems and, despite a modest improvement over the last couple years, companies that use SCADA systems have not lobbied tilts industry hard enough.
Utilities are an integral and important part of the infrastructure, which makes them attractive targets for terrorists and hackers. The security of SCADA systems has to be addressed with a thorough approach. A SCADA network is as secure as the weakest link.
Recently, there have been efforts headed by the Gas Technology Institute (GTI) to incorporate encryption in SCADA systems and these efforts should continue and be accelerated. It’s important that encryption be embedded in future SCADA systems and field devices (RTUs must be capable of handling fast enough processing of encrypted messages) and made an option that would be, as the system security administrator sees fit, turned on or off for different devices and/or components of the system
Using encryption comes with a responsibility; communications with field devices, for example, might be lost if encryption keys are compromised. The topic of encryption alone could be the subject of many papers but it is important to point out that clear and complete plans should be prepared to address different issues on the use of encryption such as deciding on what algorithms to use (there’s a range of opinions on this issue;) how often to change the keys (at a rate that is faster than break time-not an easy task;) how to deliver new keys and whether to use a different algorithm for key exchange; whether to use the same key(s) for all devices or different keys for different devices; using `salting and chaining’-padding the messages to eliminate predictability that is common to RTU communications; handling a scenario where the keys are compromised and handling “if all else fails” scenario.
Although encryption could contribute highly to making SCADA traffic and communications over open networks more secure, using encryption alone does not provide secure enough systems. It does not, for example, prevent somebody from gaining access to SCADA systems and thus use the same encryption tool the systems provide to issue unwanted control requests.
We have to come to terms with living with tight security despite how inconvenient and unpleasant it could be at times. The protection of SCADA systems requires a more pervasive application of security throughout the system and beyond. It is necessary to adopt a thorough approach when it comes to SCADA security, from selecting the products to implementing them; from prevention and planning for contingencies to recovery: from developing security procedures to adopting security practices; from protecting against cyber-attacks to securing the SCADA systems themselves. Here are some suggestions:
* House the systems in physically secure locations.
* Deploy, as a minimum, operating systems that are certified to meet the C2 security level defined by the National Computer Security Center (NCSC.) Keep your control access lists and audits up-to-date.
* Secure your networks in general and “isolate” your control network in particular. General user access should preferably be made available on a separate system and network. Figure 1 shows a configuration where the control network is isolated from the corporate network and the Internet lay a firewall with one of the users having access to both networks. This configuration does not address the issue of routers and proxy servers and where to place them in order to alleviate bottlenecks. A firewall architecture could be a combination of firewall software and hardware routers where routers could also screen the traffic. It is important, when designing the architecture, to lessen the possibility of a security breach on a single machine jeopardizing the whole network.
* Use encription for sensitive data traffic, including control requests. Lobby your vendor to make encryption embedded into your SCADA systems. Also, Virtual Private Network (VPN) should be used when users access the systems over public networks.
* Secure communications links that use telephone companies’ networks, e.g., frame relay, or other open networks.
* Make peripherals, such as terminal servers, more secure lay prohibiting remote access, among other things.
* Protect the remote terminal units and critical remote devices.
* Lobby your vendor for more granularity in implementing security, e.g. strong authentication, segregation of responsibilities, and tight restriction of access privileges (3). The nature of using databases in SCADA systems differs from other applications.
* Plan for contingencies such as evacuation of control centers, and loss of the primary system(s).
* Make plans for handling a cyber attack (what to do the moment the attack is discovered) and make recovery plans (what to do after a compromising attack.)
* Assess your systems security `fortifications’. A good way is to have your systems security audited (preferably by a third party) and make adjustments accordingly.
* Assign an IT security administrator to manage the security needs of your systems and make security patch installation a priority.
* Take advantage of available information sharing and warning services offered by various organizations such as the Computer Emergency Response Team Coordination Center (CERT/CC) and the American Gas Association (AGA), and governmental agencies such as the Federal Bureau of Investigation (FBI), the Department of Transportation (DOT). One recently formed body is the Energy Information Sharing and Analysis Center (ENERGY/ISAC). ENERGY/ISAC channels the information from various sources and provides it to its subscribed members.
Security is a moving target; with the rapid creation and implementation of new technologies, what is secure today might not be secure tomorrow; so, it is highly essential to keep on maintaining and assessing security plans continuously.
ACKNOWLEDGEMENT
Thanks to Charlie Salerno and Jaclyn Piudik for useful feedback.
Securing Supervisory Control and Data Acquisition Systems
REFERENCES
(1) California hack points to possible IT surveillance threat, by Dan Verton, Computerworld June 13, 2001.
(2) Encryption Provides Low-Cost SCADA Operating Security, by John A. Kinast and William F. Rush, Jr., Ph.D., Institute of Gas Technology,
(3) Con Edison protects SCADA with multi-level security system, by Abdo Y. Saad; Pipe Lane & Gas Industry, October 1999 Vol. 82 No 10.
Author’s Note: Abdo Saad has worked for Con Edison Company of New York, Inc. for 14 years, seven of them as a consultant. He is currently in charge of a computer group in energy management Prior, he worked at the Control Center supporting the Gas department’s Supervisory Control and Data Acquisition (SCADA) system. In that capacity, Mr. Saad worked in the areas of process control, communications. database management, system management, LAN administration, programming, and trouble-shooting.
Mr. Saad has worked on all the phases of man), projects from designing to programming, implementing, and testing. He has written various applications slice) as a NSCF access security subsystem, multi-screen display function, RTU time synchronization. historical extraction, and an extensive data acquisition subsystem that sup ports communications using telephony, Cellular Digital Packet Data (CDPD), and TCP/IP sockets over Frame Relay. Mr. Saad has made several presentations on his work to industry, groups. He holds academic honors and is a member of the Eta Kappa Nu (EKN), the Electrical Engineering Honor Society.
COPYRIGHT 2002 Oildom Publishing Company of Texas, Inc.
COPYRIGHT 2008 Gale, Cengage Learning
