Control Systems and SCADA Security


John H. Saunders, Ph.D.




“The sky is falling” rhetoric associated with critical infrastructure protection (CIP) has become mainstream. In just the last 6 months entire new journals have been created to focus on this topic[1], and a new CIP division has been created within the Department of Homeland Security (DHS)[2]. While much of this rancor in CIP is focused upon physical destruction, and weapons of mass destruction threats, other is focused upon critical information infrastructure protection (CIIP). Within the umbrella of CIIP is an area of concern known as control systems (CS).


Control systems are defined in more depth below, but are essentially “low level” computer/communications systems for operating electrical grids, transportation networks, pipelines, and other national infrastructure systems. It has been the author’s view, that while much haranguing over the challenges in control systems seem to exist; few seem to understand the real basis of the challenges in this area. Additionally, information on efforts in government and in industry to create guidelines and standards to protect CS’s is scarce. At a conference I attended in late 2002, billed as a “Summit on Prevention of Cyberterrorism”[3], and attended by top names from Government and industry, the discussions never moved beyond a superficial level. And the focus was primarily upon traditional computer/communication networks, not control systems. Yet this conference was touted as a “premiere effort.” 


In this paper, I will attempt to set apart organizations that are doing “real” work for advancing the protection of control systems. As might be expected these groups are largely composed of industry representatives who own and operate the infrastructure. This paper will provide the reader with inroads into published guidelines for improving the security of CIP control systems. It will establish a definition for CS’s, explain the peculiarities associated with security of these systems, and address government and industry efforts to improve overall CS security. The paper will especially focus upon two committees, the SP-99 of the Instrumentation, System and Automation (ISA) Society, and the Process Control Security Requirements Forum (PCSRF) at the National Institute for Systems and Technology (NIST). A more in-depth analysis of documents generated by these committees is provided. In order to understand the issues with control systems we first need to provide a definition for Control System.


What is a Control System?


CS’s are electronic and/or electro-mechanical system with sensors used to monitor & change levels of air, water/fluid, electricity, traffic, natural gas, etc. using valves, pumps, transformers, and switches. Figure 1 below portrays a simple control system. This is a mockup of a water tower system with pumps to fill the tower and valves to control water release. Not shown here are two other towers (off to the left) that are also part of this small “city wide” system. While the reservoirs etc are only models, the control system here is the same that would be used in a full-scale system. This system and others are being utilized at the National Institute for Systems and Technology at their Gaithersburg, Maryland site for research into CS security.


Figure 1 - Simple Control System (CS)

CS’s are widely used throughout the world but are more prevalent in developed countries. They are used to automate pumping of the water we drink, distributing the fuel we use for heating, and delivering the electricity we consume. At the heart of CS’s are computing devices with varying levels of intelligence. These devices make many decisions about adjusting system settings based upon inputs from sensors spread around the control network. Table 1 below provides a basic description of some of these devices. Appendix B provides some photographs of these devices. Understanding how CS’s operate is important for understanding security issues in the same vein that understanding how computers, switches, and routers operate is important for the control of network security.  Ironically there is often more CS expertise resident in less developed countries. The focus there is upon maintaining these devices. In developed countries older systems are simply replaced with newer devices.






Programmable Logic Controller

Could be described as a very simple computing device. In a repeating cycle it looks at its inputs and depending upon their state, turns on/off its outputs.  Contains relays, counters, timers, and data storage locations. “Real time” response is an important element. Operation is governed by standard IEC 61131-3.  They are programmed via an Instruction List (IL), Ladder Diagram (LD), Function Block Diagram (FBD) or Structured Text (ST).

Remote Terminal/Telemetry Unit (RTU)

A device typically in a distant location that monitors and makes simple decisions.  It relays its status to a more central collection agent via a typically slow (e.g. 9600 bps) communications channel, and may also receive instructions.

Intelligent Electronic Device (IED)

A generic name for a “hub” device which possess greater intelligence and therefore decision making capability. These devices are specific purpose, quite sophisticated and typically reside at a regional collection point such as an electrical power substation.

Human Machine Interface (HMI) Monitor

A visual monitor that depicts the complete components of a large distributed system and that conveys a real time operational state. The HMI will be found at a single central location and is usually running on a general purpose computer. There is a small group of software providers in this market space.

Supervisory Control And Data Acquisition

Not actually a single device but more typically a full scale general purpose computer or set of computers. Typically in use in very large systems such as a utility company’s central control or a regional transportation systems HQ. May monitor thousands of RTUs and/or PLCs.


The number of major manufacturers of control system devices such as PLC’s and RTU’s is relatively small. Appendix A lists the major CS companies. However there are a considerably larger number of smaller companies who specialize in the application of these devices to solve a wide array of challenges. So you may find, for example, an Allen-Bradley PLC-5/1771 simultaneously utilized in a wastewater facility, in an airfield lighting system, and on a steel mill production line.


These devices have a significantly longer operational life than computers. Whereas a computer may have a 3-4 year operating life, a PLC or IED may be in operation for a decade or even two. As such standards in this arena have evolved slowly. There is no one agreed upon standard such as those in the desktop computing world like IP or RS-232. Competing communications and processing standards in CS such as MODBUS, DNP, OPENNET, and Profibus remain common.


Where CS computing devices physically reside depends upon the size, complexity, and economic viability of the overall system. Appendix B’s diagram 1 portrays a larger scale system with combinations of the computing devices. Larger scale combined systems are often referred to collectively as Distributed Control Systems (DCS). A DCS may be spread across hundreds of miles and have thousands of control devices.


Traditionally safety has a big issue in control systems. Preventing pipelines from bursting, trains from colliding, and electrical transformers from exploding are important considerations. At the same time there is considerable pressure placed upon utilities and other companies utilizing CS’s to provide uptimes approaching 100%.  Unlike computer networks, control systems are not taken out of service for maintenance. When they are out of service, they are considered “down.” Additionally, unlike computer networks, the “code” in a device such as an RTU is rarely updated. During its entire lifespan, its code and the hardware functionality may never be changed.


Security Issues in Control Systems


Until very recently security has not been an issue looming large in control systems. Presidential Decision Directive 63 provided the first boost to the issue.  The events of September 11, 2001 certainly increased the pressures to look at vulnerabilities within this area. The more recent National Strategy to Secure CyberSpace[4] (NSSCS) brings out these issues as well.


Retrofitting security into control systems devices is problematic. The NSSCS report, when referring to CS devices states, “Security features are not easily adapted to the space or power requirements. In addition, these systems operate in real time and security measures could reduce performance and impact the synchronization of larger processes.” This report tasked DHS and the Department of Energy (DOE) to develop 1) best practices and new technology to increase security of DCS/SCADA, and 2) a prioritized plan for short term cyber security improvements.


Some of the increasingly important issues associated with CS’s include the following:


  • Remote connectivity to/control of DCS devices. The low cost and expanding availability of Internet access is pushing DCS’s to use the internet as a channel for communication. For large scale systems spanning hundreds or thousands of miles, a vendor must utilize whatever communications channels are available in that area.
  • Standardization of DCS Protocols. Virtually all vendors now offer IP based protocols for CS devices. Additionally, On Line Linking & Embedding (OLE) for Process Control, called OPC, is a rising protocol based upon Microsoft specifications (or lack thereof). It should be noted that OPC is a very complex protocol, and details on its operation is known by only a very small, select group of experts.
  • Connection of DCS & Business LANs. A desire to have more data and greater control over operations is pushing connectivity to business networks. By opening up this “door” the CS is exposed to additional vulnerabilities.
  • “Windowing” of DCS & SCADA Control. A move away from command line interfaces and other “more primitive” interfaces is pushing the use of standard Windows environments for command and control of CS’s.


The saving grace in security for most CS’s has been vendor specific / proprietary protocols and the large number of disconnected systems. This situation can be likened to the mini-computer world of the 1970s and 1980’s.  Each vendor has its own standards and protocols. It is difficult to become expert with more than one vendor’s standards, and connecting units together requires specially built equipment.  


On the contrary side, many of the older systems lack even the most basic security measures such as passwords. Almost always messages are sent in the clear.



Security Standards for Control Systems


Establishing security standards in CS can be somewhat problematic because there are so many devices, protocols and applications involved. Nonetheless efforts on a National scale and also within various infrastructure sectors are progressing. In the electrical sector, the Federal Energy Regulatory Commission, North American Electric Reliability Council (NERC), and the Electric Power Research Institute all conduct research and publish guidelines. In the oil and chemical processing arena the Chemical Industry Data Exchange has created an extensive set of guidelines. In the gas and oil pipeline sector the American Gas Association (AGA) has produced one of the best courses available. Irrespective a need was felt by CS suppliers and by major consumers that “across the board” efforts to provide security guidance would benefit all sectors. Such was the origin of the PCSRF and the SP-99 from ISA.


The Process Control Security Requirements Forum (PCSRF)


The PCSRF is a working group formed from the National Information Assurance Partnership (NIAP). Its structure is shown below. The Intelligent Devices group at NIST, headed by Keith Stouffer, has been tasked to lead this effort.  A contractor, Decisive Analytics, has been responsible for compiling much of the work and producing the documents.



The overall goal of the effort is to “to characterize the minimal security capabilities to be provided by the product components that comprise an Industrial Control System (ICS), and the minimal security capabilities that must be exhibited by the ICS after the product components have been integrated together to form an ICS. “ The diagram below portrays the planned functionality of the forum.



To date the PCSRF has produced two documents. They are:


  1. Security Capabilities Profile for Industrial Control Systems, (SCPICS) and
  2. System Protection Profile for Industrial Control Systems (SPPICS)


Neither of these documents has yet been released for public comment. And as of this time the System Protection Profile for Industrial Control Systems is still in preliminary review.


The SCPICS lays out the mission of the PCSRF and defines its relationship to the ISA’s SP-99 and to the Common Criteria[5]. It addresses the issues concerned with CS vulnerabilities. It also takes a brief look at CS objectives, and then lays out requirements for improving security in CS’s. Among these requirements are many which already exist within computer networks but which are largely absent from distributed control systems. The following are some of the major areas where improvements are suggested for CS’s:


  • Residual Risk assessment
  • Test & verification for security
  • Ownership of the security function
  • Access control mechanisms
  • Event trace – intrusion detection
  • Operational configuration integrity
  • Secure channels
  • Boundary defense devices
  • Network addressable field devices
  • Secure User interface states such as degraded mode operation.


The SPP is an ISO 15408 based document. This means it has security functional requirements (SFR) and security assurance requirements (SAR) that cover the accreditation of systems using system protection profiles (SPP) and system security targets (SST). Those familiar with the Common Criteria[6] will recognize these goals, which align with that effort.


The ISA-SP99, Manufacturing and Control Systems Security Committee


The Instrumentation, Systems and Automation (ISA) Society is a 38,000 member organization devoted to automation and control. It focuses upon the theory, design, manufacture, and use of sensors, instruments, computers, and systems. As in any membership organization of this size, it sponsors conferences, education and training, and technical committees for establishing processes and standards.


A specific committee of the ISA, labeled SP99, was formed in 2002 to “establish standards, recommended practices, technical reports, and related information that will define procedures for implementing electronically secure manufacturing and control systems and security practices and assessing electronic security performance.[7]  As can be seen from the voting membership list in Appendix C, voting representation on the committee comes primarily from industrial organizations such as Dow Chemical, Bayer Pharmaceuticals, Kraft, and 3M.


The SP-99 established an ambitious calendar to get a standard for controls systems security released by April 2003. While that deadline was missed, they were successful in issuing a draft that was approved by voting members of the committee in August 2003. The draft was introduced to the general membership at the Annual ISA Conference in Houston Texas in October 2003. The standard is now in a period for gathering comments from the general ISA Membership. What is expected to be the final version of Technical Report 1 was issued to Voting Members for review and confirmation, with a deadline of 9 Feb. 2004. This is a much longer process with comments being accepted through 2005.


SP-99 has 3 major parts as follows:


I. Security Technologies for Manufacturing and Control Systems

II. Integrating Security into the Manufacturing and Control System Environment

III. Testing, Audits and Metrics for Manufacturing and Control Systems Security


Part I deals primarily with laying out the different technology options that are available. So it covers basic security technology such as access control mechanisms and perimeter defense technology. It looks at the pros and cons for each approach, especially related to CS’s. Part II deals with imbedding these into current environments. It looks at building a program to inculcate security across the depth and breadth of the control system enterprise. This is typically quite difficult due to the stable environments of CS. Making changes in these environments is difficult. Finally Part III uses a design adopted from the “V” Model, ISO/IEC 12119 Standard, frequently used in Europe for defining software quality and for testing. Part III looks at test plan development, covers operational security measures, and discusses periodic auditing. Overall the SP-99 should provide an effective base for assisting CS organizations about programs and technology adoption.




This paper has provided a look into the structure and makeup of control systems. It has laid out some of the current weaknesses with these systems. It has provided additional rationale on how growing issues such as Internet connectivity may be worsening the security of control systems. Finally it has outlined a few industry efforts that are attempting to establish standards and propagate information to improve the overall security for information infrastructure protection relating to control systems.


Writing standards and guidelines is different than enforcing them or offering incentives to use them. Not long after the September 11th 2001 event, Congress passed Public Law 107–188—June 12, 2002 Public Health Security And Bioterrorism Preparedness And Response Act Of 2002. This act provided grant funding on the average of $150,000 per institution for water/sewage utilities to improve the security posture of their organization. The utilities could spend the money as they wished to include “improvements to electronic, computer, or other automated systems and remote security systems.” Incentives such as these are needed before we will see real improvement in the security of control systems in our country. We should not wait until a massive attack cripples our infrastructure.






Falco, J., Stouffer, K., Wavering, A., and Proctor, F. IT Security for Industrial Control Systems. NIST, Gaithersburg,MD. Retrieved on February 5, 2003 from


General Accounting Office. (2003, October) Critical Infrastructure Protection: Challenges in Securing Control Systems. Washington, DC.


Process Control Security Requirements Forum. System Capabilities Profile for Industrial Control Systems. (2003) Version 1.0 May 22. NIST. Gaithersburg, MD.


Process Control Security Requirements Forum.  System Protection Profile – Industrial Control Systems. (2004) Version 0.91 February 4.. NIST. Gaithersburg, MD.


Sheldon, F. Potok, T., Loebl, A., Krings, A. and Oman, P. Managing Secure Survivable Critical Infrastructures To Avoid Vulnerabilities


Stamp, J., Dillinger,J. Young , W. and  DePoy, J. Common vulnerabilities in Critical Infrastructure Control systems. Sandia National Labs Albuquerque, NM. Published 11 November 2003.


The White House. (2003, February) National Strategy to Secure Cyberspace. Washington, DC.


What is a PLC?

Appendix A – Major Control Systems Manufacturers

  1. Allen-Bradley (Rockwell) - Milwaukee, Wisconsin, $4 B
  2. Alstom - , Paris, France,,  $21 B
  3. Asea Brown Boveri Ltd (ABB), Zurich, Switzerland,
  4. Emerson Process Management
  5. GE Industrial -
  6. GE Power -
  7. Honeywell -
  8. Motorola -
  9. National Instruments -
  10. Invensys/Foxboro -
  11. Siemens -
  12. Schneider Electric -

Appendix B – Control Systems Devices


1. Programmable Logic Controller (PLC)


2. Remote Terminal Unit (RTU)



3. Intelligent Electronic Device (IED)

4. Human Machine Interface




5. Generic Distributed Control System with SCADA


Appendix C - Voting Members of SP-99


Charles Robinson, Staff Contact, ISA, Phone: (919) 990-9213, Fax: (919) 549-8288, Email:


Paul Baybutt
Phone: (614) 841-9800

Rahul Bhojani
Phone: (281) 383-7608
Fax: (281) 383-5487

Dennis Brandl

Eric Byres
Phone: (604) 453-4017
Fax: (604) 436-0286

Keith Chambers
Phone: (805) 241-3280
Fax: (805) 241-3280

Jason Christman
Phone: (301) 483-6000 x2411

Eric Cosman
Phone: (989) 639-3151
Fax: (989) 638-3018

Jean-Pierre Dalzon
Phone: (331) 485-9354
Email: Todd Davis
Phone: (403) 301-5023
Fax: (403) 259-2926

Ronald Derynck
Phone: (403) 299-4754
Fax: (403) 272-2299

Ronald Forrest
Phone: (614) 292-3546
Fax: (614) 292-1468

Thomas Good
Phone: (302) 695-0070
Fax: (302) 695-0531

Evan Hand
 Vice Chair
Phone: (847) 646-5292
Fax: (847) 646-6269

Matthew Lees
Phone: (908) 709-4818

Charles Mastromonico
Phone: (803) 725-1617
Fax: (803) 725-1744

Winfield Matz
Phone: (713)722-2805
Fax: (713)932-0222



Greg Morningstar
Phone: (319) 286-5948
Fax: (319) 286-5911

Ashok Nangia
Phone: (651) 778-4570
Fax: (651) 778-5529

Shinji Oda
Phone: (972) 417-2750
Fax: (972) 416-3966

Richard Oyen
Phone: (440) 585-6021
Fax: (440) 585-8589

John Saunders
Phone: (202) 685-2078
Fax: (202) 685-3974

Marvin Schilt
Phone: (414) 382-3025

Bryan Singer
Phone: 205 621 8170
Fax: 205 621 8710

Carl Sossman
Phone: (803) 502-9642
Fax: (803) 502-3042

Leon Steinocher
Phone: (281) 263-3892
Fax: (281) 263-5109

Bradley Taylor
Phone: (410) 293-6132
Fax: (410) 293-2215

David Teumim
Phone: (610) 398-5546

Donovan Tindill
Phone: (780) 945-4033
Fax: (780) 448-9191

Loren Uden
Phone: (815) 942-7633
Fax: (815) 942-7768

Robert Webb
 Managing Director
Phone: 650-654-5251

Joseph Weiss
Fax: (408) 253-7974



[1] Journal of Homeland Security and Emergency Management, Berkeley Electronic Press

[2] Information Analysis & Infrastructure Protection Division

[3] Sector 5, Gartner Group, October 2002.

[4] National Strategy to Secure Cyberspace, February 2003. p. 32.

[5] An effort to lay out standards for software based upon testing to attain assurance levels

[6] ibid 5.

[7] ISA-SP99, Manufacturing and Control Systems Security at