30 September 2003
Source: http://cio.nist.gov/esd/emaildir//processcntrl/doc00007.doc

Author: Michael A McEvilley
Date: January 24, 2002

Process Control Security Requirements Forum
(PCSRF)

1 Introduction

This section will introduce and describe this security specification document in terms of its purpose, content, intended usage and application. Any technically focused material presented in this section will be expanded in the System Definition and Description Section.

1.1. Initiative Purpose

The National Information Assurance Partnership (NIAP - partnership between the National Security Agency (NSA) and the National Institute of Standards and Technology (NIST)), as part of the Critical Infrastructure Protection Program, provides technical support and guidance to industry to improve the information technology security posture of the systems and supporting operations that comprise the US national critical information infrastructure. One component of this effort addresses the IT security for the networked digital process control systems used to support industrial applications. The NIST Intelligent Systems Division of the Manufacturing Engineering Laboratory, the NIST Information Technology Laboratory and the NIST Electrical and Electronics Engineering Laboratory are working with industry to incorporate end-to-end security engineering into the life-cycle processes of process control systems and the components that comprise such systems.

The goal of this effort is the development of security specifications that characterize or establish a profile of the security functions and mechanisms that must be incorporated into identified components of process control systems. This effort is being carried out through the Process Control Security Requirements Forum (PCSRF), an industry group organized under the NIAP umbrella. The outcome of this work will be the development and dissemination of best practices and ultimately security standards that will be used in the procurement, development, and retrofit of industrial control systems.

The PCSRF is a working group comprised of representative organizations from the various sectors that make up the US process control industry and the vendors that design, produce, and/or integrate components and systems for the industry. The PCSRF is working with security professionals to assess the vulnerabilities and establish appropriate strategies for the development of policies and countermeasures that the U.S. process controls industry would employ through a combination of IT and non-IT mechanisms to reduce residual risk to an acceptable level. The Common Criteria for Information Technology Security Evaluation, also known as ISO/IEC 15408, is being used to document the results of this effort in the form of Common Criteria Protection Profile security specifications.

1.2 The Purpose of the SPS

Developing a CC-compliant protection profile requires the collection of information that fully describes the security problem that must be solved, the protections needed to address the problem, and substantiation that these protections are in fact appropriate and sufficient to solve the problem. This diverse information is then captured in the form of a Protection Profile that is a security specification framework that includes checks and balances to ensure the correctness of its component parts.

The SPS is not a protection profile. Rather than to work directly within the context of the CC's language and constructs, this effort will focus on developing and documenting requirements using the language of the process control industry operating domains and on generating an intermediate Security Profile Specification (SPS) which will be translated into one or more CC-compliant protection profiles.

One key distinction between the SPS and PP is that a PP focuses exclusively on the security functions and mechanisms. This SPS may include additional information such as safety-critical and performance information. This additional information will help to identify additional security-relevant information that if incorporated into the resultant protection profile would result in a more comprehensive and complete security specification.

1.3 The Scope of the SPS

This security profile specification defines the security criteria applicable to a Process Control System (PCS) that is employed in industry, and particularly in industries regarded as a component of the national critical information infrastructure. Candidate industries include the electric utilities, petroleum (oil & gas), water, waste, chemicals, pharmaceuticals, pulp & paper, and metals and mining.

A PCS can be characterized as a distributed collection of components that provide the following basic functions to control a complex process:

• Measurement - data collection

• Control - data assessment, information generation and response determination

• Manipulation - response execution

• Human-machine interface - processing of inputs from and presentation of information to human operators

The functions described above are continuous functions and there must be corresponding functions that transition the process from a dormant state to a continuous state; that maintains the execution of the process from a supervisory perspective; and that transition the process from a continuous state to a shutdown state. These functions can be categorized as:

• Startup, initial condition or set-point establishment

• System and process behavior management controls and discrete event logging

• Shutdown, backup and recovery

This specification addresses the above in the context of the security functionality that must be present to enable the continuous secure execution of the process that is being controlled. This specification simply makes an argument for security requirements to address the defined security problem, and in that respect and that respect alone, is a stand-alone document. However, to fully understand how the defined security functionality relates to the PCS in a general sense, this document must be read in conjunction with associated functional, performance, and safety specifications.

1.4 Application of the SPS

This SPS is developed to support the development of one or more CC-compliant PPs. The SPS will serve to 1) establish the minimal security criteria applicable across process control industry boundaries, and 2) provide guidance for the development of industry and/or operating facility-specific criteria in support of any of the application modes defined below. The PPs derived from this specification will be applied to serve in one or more of the following roles:

Acquisition/Procurement Vehicle - There are two contexts in which a security specification may serve the acquisition/procurement process:

• Statement of required security functionality - In this context, the specification would serve as the basis for communicating the minimal required security functionality that must exist in candidate products. The vendor community would develop components that incorporated the security functionality defined by the specification.

• Criteria to gauge sufficiency of available products - In this context the specification serves as the basis for determining how close a candidate product comes to matching the required security functionality.

• Verification of Product Compliance - There are several contexts in which the security specification would serve as a basis for determining the correctness of an implementation:

• Evaluation at the component level - The evaluation would serve to substantiate the correctness of the implementation of a well-defined set of security functions and mechanisms.

• Certification at the system level - The certification would serve to substantiate the correctness and suitability of the implementation for a given operational environment and operational context.

(note: products refer to components and systems, where systems are integrated components)

2 System Definition and Description

This section will define terms, define the system in terms of its components and will describe those portions of the system that are in scope relative to the requirements specified.

2.1 Section Overview

The intent of this section is to define the components of a process control system in an abstract manner such that the discussion that follows in subsequent sections may be broadly applied regardless of the physical or technology attributes of specific process control vendor products, either existing or yet to be developed. This specification is not intended to address those system components that exist in the process control facility that provide support for managerial, office automation or any other function not directly related to controlling the process control function of the facility. However, it does address the security requirements of those components of the PCS that interact with these functions.

2.2 Process Control System Definition

A PCS is comprised of a collection of discrete component types that are integrated together to manage an industrial production, transmission, or distribution process. These components may be categorized in terms of the fundamental function they provide within the PCS, such as a controller, sensor, transmitter or actuator. These components may be further characterized in terms of their basis for operation, which may be mechanical, pneumatic, hydraulic, electrical or electronic means. An additional categorization may be made when these fundamental functions are integrated together to provide multiple functions within a single physical housing, such as the combining of a sensor and transmitter function into a single physical unit.

The key control components of an industrial control system, including the control loop, the human machine interface (HMI), and remote diagnostics and maintenance utilities, are shown in Figure 1. A control loop consists of sensors for measurement, control hardware, process actuators, and communication of process variables. Measurement variables are transmitted to the controller from the process variable sensors. The controller interprets the signals and generates corresponding control signals that it transmits to the process actuators. This results in new values of the process variables, and the sensors transmit revised signals back to the controller. The human-machine interface allows a control engineer or operator to configure set points, control algorithms and parameters in the controller. The HMI also provides displays of process status information, including alarms and other means of notifying the operator of malfunctions. Diagnostic and maintenance tools, often made available via modems and Internet enabled interfaces, allow control engineers, operators and vendors to monitor and change controller, actuator, and sensor properties from remote locations. A typical industrial system contains a proliferation of control loops, HMIs and Remote Diagnostics and Maintenance tools built on an array of network protocols. Supervisory level loops and lower level loops operate continuously over the duration of a process at cycle times ranging on the order of minutes to milliseconds.

Figure 1 Key Control Components

In a large enterprise, there may be several geographically distributed industrial plants. Enterprise business operations can access plant information over the Internet or in some cases over a wide area network (WAN). The local area network (LAN) of a processing plant services the all of the operations within the plant while the actual control system of the plant sits on what has historically been a somewhat isolated peer-to-peer network. The systems at these levels can be categorized into two primary types of supervisory based control schemes, Distributed Control Systems (DCS) and Supervisory Control and Data Acquisition Systems (SCADA) [1][2][3]. DCS are used to control large, complex processes such as power plants or refineries, typically at a single site. SCADA systems are used to control (perhaps) less complex, but more dispersed assets where centralized data acquisition is as important as control. Typically distribution operations of water systems, gas pipelines, and electrical transmission lines use SCADA systems. Generic industrial control system network architectures are shown for both DCS and SCADA based control schemes in the Appendices. A glossary of terms describing the components found in the diagram also can be found in the Appendix of this document.

Despite the different nomenclature, the underlying concepts, components, and functions of DCS and SCADA systems are the same. Therefore, the target of this specification is a PCS in an abstract sense-it might be a DCS, a SCADA system, some combination of these, or other configurations. The PCS is characterized by components that record information, monitor information, transmit information, receive information, determine and issue command sequences. The goal of this SPS is to define vulnerabilities based upon this abstract representation of the PCS. Basing all discussion on that which is fundamental to the problem to be solved may alleviate the difficulty posed by the nomenclature used to define the components that comprise a PCS. The focus of this security profile specification is therefore limited to the identified components of a PCS that provide or utilize functionality characterized as follows :

The movement of data between two or more uniquely identifiable points via a communication means that incorporates digital pre and/or post processing of the transmitted data.

The access to a uniquely identifiable component by a uniquely identifiable agent

Control over the invoking of operations that may adversely affect the safety properties of the PCS or the process being controlled.

The collection of data associated with PCS component access, PCS behavior modification, PCS startup and shutdown.

3 Operational Security Environment

This section will describe the operational environment in which the system components will be placed. The operational environment will be discussed in the context of well-defined bounds that cover both how the system is intended to be used and where the system is intended to be used.

3.1 Section Overview

The security problem that must be addressed by process control system components and its operational environment is defined in terms of

Assumptions - The assumptions regarding the intended operational environment serve to bound the problem space and problem definition. They are expressed relative to the physical and IT operating environment, the technology employed in process control systems and the common and unique aspects of the varying process control industries that will make use of this specification.

Vulnerabilities - Statement of vulnerabilities are made within the context of the stated assumptions. Vulnerabilities apply to the process control system as well as to its IT and non-IT operating environment. The scope for definition of vulnerabilities should be initially broad-based since it may not be apparent that a security-relevant mechanism is required to ensure that exploitation of the vulnerability is minimized or eliminated. Vulnerabilities should be considered based upon the following contexts:

• Physical and IT operating environment and controls

• Endangerment of Public Health and Safety

• Environmental Damage

• Specific process control industry and function

• Loss of Production/Generation/Distribution

• Process control component technology and implementation

• Safety-critical environment

• Harm to Personnel and Equipment

• Compromising of Proprietary Information

• Liability

• Regulatory Constraints - Mandates, policies or directives that govern the use and application of process control systems are stated since they may require IT mechanisms to support the enforcement of the criteria. The scope of regulatory constraints to be considered overlaps the scope discussed for identification of vulnerabilities .

3.2 Secure Usage and Environment Assumptions

The following assumptions are made regarding the intended use of the PCS and the operational environment in which the PCS shall be used :

• This specification does not levy security requirements on system components that interface with the PCS but that are not directly responsible for controlling the defined process.
  
  Either in a separate assumption or as part of this elaboration, it will be stated that the security criteria for interfaces between the PCS and other systems will be defined in the Interfaces section of the specification, however the criteria for security functionality within any system to which the PCS interfaces will not be defined.

• Within a process control facility, PCS components may be directly or indirectly accessible to individuals that are granted access within the controlled confines of the PCS operations facility.
  
  This assumption addresses those individuals that are authorized to be within the confines of the process control facility. The authorization to be in the facility implies that opportunity exists to access the PCS. Such access may be possible via direct interaction to PCS components or via indirect access via the facility network infrastructure.

• Internet connectivity exists not as a direct connection to the PCS but via a common facility network backbone infrastructure.
  
  It is expected that will be some form of isolation between the PCS and the Internet. Such may not be the case and this assumption should only be included if it can provide meaningful information. Other considerations are whether or not PCS components are "visible" to the Internet.

• The PCS operations facility will have IT protection mechanisms in place to prevent casual access to the PCS from a location on the Internet.
  
  Such protection mechanisms may include firewalls, filtering routers and intrusion detection systems.

• Remote access to PCS components is available to product vendor personnel and authorized personnel employed at the process control facility.
  
  This is a capability assumption meaning that if we determine that this is valid, then we need to address the issue not as an assumption but as either the vulnerabilities associated with remote access or through policy for remote access.

• The degree of physical protection of PCS components, excluding communication medium, is largely a function of the specific process being controlled and the characteristics of the physical location of the process control facility.
  
  This assumption essentially states that we cannot define a minimum baseline of physical security and therefore, must consider vulnerabilities in the absence of reasonable physical protection.

• There is no physical protection of communication medium. There are no security services provided by non-PCS components that implement the internetworking capabilities utilized by the PCS components.
  
  There are no expectations for communication mediums to be secure. There are also no expectations that any security may be derived from components that implement the communications infrastructure.
  
  This assumption is here to provide a basis for a point that must be validated. Should this assumption hold, then the vulnerabilities resulting from lack of secure communication medium need to be addressed.

• PCS components that employ data communications protocols including Ethernet, TCP/IP (wired or wireless), and FieldBus , RS-232 serial, and all others not specified here are subject to the confidentiality and integrity criteria contained in this specification.
  
  The scope of the required protection mechanisms must be clearly stated. Any other protocols or communication medium used by the process control industry for which protection is required must be listed here.

• There may be security vulnerabilities that result in violation of safety criteria.
  
  If we can define these we must. Attention must be drawn to the issue that through exploitation of security vulnerability, a safety vulnerability may then exist. Since safety policy and mandated controls are in place - the failure to properly secure the system may result in a violation.

• Some security compromises may have to be made to avoid violation of safety criteria.

3.3 Vulnerabilities

IT security has not been a significant issue within the process control community. Process control systems were designed to meet performance, reliability, safety, and flexibility requirements and were typically physically isolated and employed communications protocols based on proprietary implementations. The adoption of communications protocols based on international standards, applications utilizing Internet technology and commercial off-the-shelf hardware and software by the process control industry has resulted in increased exposure and vulnerability to those with intent to disable or disrupt the operation of process control system components. As such, process control systems now operate within and are susceptible to the same threat environment as enterprise IT business systems.

The identification of vulnerabilities to which a process control system is exposed requires consideration of the following factors:

• Intended operational environment of the PCS

• Purpose, function and use of the PCS

• Technology employed in PCS components

• Communication medium employed to interconnect PCS components

• Human agents with intent to disrupt, destroy or incapacitate PCS operation

• Natural disaster events that may disrupt, destroy or incapacitate PCS operation

The diversity of operations, environments and technologies used by the various process control industries makes it an extremely complicated matter to define a single cohesive set of vulnerabilities because of the unique perspectives of each of the industries. Even within a single process control industry, the variation in methods of operations, equipment and technology employed tends to skew the perspectives such that focus is given to the process control system "at hand" rather than to address the problem at a higher and more abstract level. As a result, attempts to define industry wide vulnerabilities are difficult to accomplish in a purely top-down fashion. A recommended approach for defining across-the-board vulnerabilities is as follows:

1. Each representative process control industry will characterize the vulnerabilities in their operating environment based on an abstract view of the PCSs they operate. This abstract view is intended to reduce the complexity inherent to the various technologies and communications mediums that exist in a PCS. The abstract view will be based on a characterization of the PCS in terms of its components and communication mediums employed.

2. The focus for defining vulnerabilities will be based on the following minimal set of PCS functions and capabilities:

• Integrity of PCS components - this is the ability of the PCS components to ensure a secure execution environment that is protected from unauthorized access or tampering.

• Availability of PCS components - this is the ability of the PCS components to ensure a continuity of operation and/or provide indication for various failure modes.

• Integrity of PCS information - this is the ability of the PCS components to ensure that information is protected as it moves throughout the PCS such that transmitted information is identical to received information and that information transmitted from point a to point b is actually received at point b and at no other points.

• Authentication of PCS components - this is the ability of the PCS components to ensure that information is originating from the intended source, and that information originating from other sources can be identified as such.

• Integrity of PCS control functions - this is the ability of the PCS components to provide and to protect access to the functions used to configure, startup, shutdown, recover, backup, restore, upgrade, monitor and diagnose the PCS components.

• Monitoring/Logging of PCS operation - this is the ability of the PCS components to generate and to maintain information regarding events, command actions and PCS component state such that authorized individuals may reconstruct events or diagnose system operations.

3. The result of the individual process control industry efforts to identify vulnerabilities will be analyzed and then consolidated into a comprehensive statement of vulnerabilities. The anticipated output of this consolidation would be the following:

• Statement of vulnerabilities common across all process control industries

• Statement of vulnerabilities unique to a single process control industry

• Statement of vulnerabilities that are unique to local decisions for employing and operating PCS components

The following statements provide a characterization of the vulnerabilities that may be exploited for the intent of disrupting or otherwise preventing a PCS from accomplishing its designed intent.

• Information flows between PCS components are subject to interception and analysis.

• Information flows between PCS components are subject to interception and replay.

• Information flows between PCS components are subject to interception and modification and replacement.

• Information flows between PCS components may be inserted.

• Executable code may be uploaded to a PCS component.

• PCS components with responsibility for supervisory or control functionality have a security failure mode with safety-critical implications.

A PCS component with responsibility for supervisory or control functionality is unable to detect a pending PCS failure with safety-related implications due to the lack of state, trend-indicating, or other information that conveys the state of PCS integrity.

3.4 Mandated Policy

Policy statements establish mandatory constraints imposed by governmental, industry-specific or other controlling entities with respect to:

• Certification and accreditation criteria

• Limitations and constraints on the operations of PCS

• Safety-critical policy that has security implications

• Others?

4. Security Policy and IT Mechanism Implementation Objectives

This section will introduce the goals to be obtained by the system in terms of its ability to establish and maintain a secure operating environment for the PCS.

Functionality:

• Self-test on startup and perhaps periodic self-test during continuous operations.

• PCS capability to detect abnormal PCS component behavior and perhaps to respond to any detected state by notification to the operator and/or taking corrective/preventive action with or without operator intervention.

• Authentication of device for command/control messages. Authentication occurs in two contexts:
  
  1. Human user to PCS
  
  2. PCS component to PCS component

Appendix I - Process Control Systems and Industries Overview

Real-time computer control systems used in process control applications have many characteristics that are different than traditional information processing systems used in business applications. Foremost among these is design for efficiency and time-critical response. Security is generally not a strong design driver and therefore tends to be bypassed in favor of performance. Computing resources (including CPU time and memory) available to perform security functions tend to be very limited. Furthermore, the goals of safety and security sometimes conflict in the design and operation of control systems.

Digital industrial control systems can be either process-based or discrete-based. Process-based controls are used to control continuous processes such as fuel or steam flow in a power plant or petroleum in a refinery. Discrete-based controls (otherwise known as batch controls) control discrete parts manufacturing or "batches" of material in a chemical plant. Both utilize the same types of control systems, sensors, and networks. While efforts of the PCSRF are currently geared toward continuous processing systems, results will likely be applicable to discrete based systems.

The computer control systems used in process industries, including electric utilities, petroleum (oil & gas), water, waste, chemicals, pharmaceuticals, pulp & paper, and metals & mining can be divided amongst the usage of either DCS or SCADA technology and implementation depends on the geographic distribution of the operation. Network architectures that encompass processing operations involving the transformation of raw materials into a usable product in a continuous fashion follow the DCS scenario. On the other hand, the network architectures that encompass distribution operations of the usable products, typically over large distances, follow the SCADA scenario.

The electrical power infrastructure is made up of power generation facilities as well as transmission and distribution networks (electric power grid) that create and supply electricity to end-users. Power generation facilities include both fossil fuel and hydroelectric systems. Fossil fuel plants use a combustion process to heat water in a boiler to steam. The high-pressure steam, in turn, flows into a turbine, which spins a generator to produce electricity. Hydroelectric generation facilities utilize the force of water, via a dam, flowing into a turbine, which spins a generator to produce electricity. These generation facilities use DCS. The electric power grid is a highly interconnected and dynamic system consisting of thousands of public and private utilities and rural cooperatives. A SCADA system manages distribution systems by collecting the electric system data from the field and issuing control commands to the field.

Natural gas, crude, refined petroleum, and petroleum-derived fuels represent Oil and Gas substances. The Oil & Gas infrastructure includes the production holding facilities, refining and processing facilities, and distribution mechanisms (including pipelines, ships, trucks, and rail systems) for such substances. Refining and processing facilities make use of DCS while holding facilities and distribution systems utilize SCADA technology.

The water supply infrastructure encompasses water sources, holding facilities, filtration, cleaning and treatment systems and distribution systems. Like electric, oil and gas, the processing operations use DCS technology while the distribution operations use SCADA technology. A waste water treatment infrastructure is very similar to that of a water supply infrastructure. Chemical, pharmaceutical, pulp and paper, and metals and mining industries primarily fit into the category of processing facility and use DCS technology.

A comparison of these diagrams shows that at the higher level of the plant network architectures the plant operations are similar for plants containing either DCS or SCADA systems. At this level, everything resides on a local area network. These include general purpose workstations, printers, plant database, application servers and domain controllers. Communication outside the plant is typically established via a firewall to the Internet or a wide area network (WAN). Modems are also available, usually to allow remote access to employees working from home or on the road. The DCS and local SCADA components of a plant system typically reside on a peer to peer network.

2.3 DCS Component Characterization

A DCS is comprised of a supervisory layer of control and one to several distributed controllers contained within the same processing plant. The supervisory controller runs on the control server and communicates to its subordinates via a peer to peer network. The supervisor sends set points to and requests data from the distributed controllers. The distributed controllers control their process actuators based on requests from the supervisor and sensor feedback for process sensors. These controllers typically use a local field bus to communicate with actuators and sensors eliminating the need of point-to-point wiring between the controller and each device. There a several types of controllers used at the distributed control points of a DCS including machine controllers, programmable logic controllers, process controllers and single loop controllers depending on the application. Many of the distributed controllers on a DCS have the capability to be accessed directly via a modem allowing remote diagnostics and servicing by vendors as well as plant engineers.

2.4 SCADA Component Characterization

A SCADA typically consists of a Central Monitoring System (CMS), contained within the plant and one or more Remote Stations. The CMS houses the Control Server and the communications routers via a peer to peer network. The CMS collects and logs information gathered by the remote stations and generates necessary actions for events detected. A remote station consists of either a Remote Terminal Unit (RTU) or a Programmable Logic Controller (PLC) which controls actuators and monitors sensors. Remote stations, typically, have the added capability to be interfaced by field operators via hand held devices to perform diagnostic and repair operations locally. The communications network is the medium for transporting information between remote stations and the CMS. This is performed using telephone line, cable, or radio frequency. If the remote site is too isolated to be reached directly via a direct radio signal, a radio repeater is used to link the site.

Appendix II - Glossary of Terms - Generic Composite Industrial Control System Network Architecture

AC Drive - Alternating Current Drive synonymous with Variable Frequency Drive (VFD).

Application Server - A computer responsible for hosting applications accessed and used by multiple networked user workstations.

Backup Domain Controller - Backup domain controller to the Primary Domain Controller.

Control Server - A server hosts the supervisory control system, typically a commercially available application for DCS or SCADA systems, and communicates data between the Peer-to-Peer network and the LAN.

Data - A repository of information that usually holds plant wide information including process data, recipes, personnel data and financial data.

DC Servo Drive - A type of drive that works specifically with servo motors. Transmits commands to the motor and receives feedback from the servo motor's resolver or encoder.

Distributed Control System (DCS) - A supervisory control system typically controls and monitors set points to sub-controllers distributed geographically throughout a factory.

Distributed Plant - A geographically distributed factory that is accessible through the Internet by an enterprise.

Domain Controller - A Windows NT server responsible for managing domain information, such as login IDs and passwords.

Enterprise - A business venture or company that encompasses one or more factories.

Enterprise Resource Planning (ERP) System -A system that integrates enterprise-wide information including human resources, financials, manufacturing, and distribution as well as connect the organization to its customers and suppliers.

Fieldbus - A category of network that links sensors and other devices to a PC or PLC based controller. Use of Fieldbus technologies eliminates the need of point-to-point wiring between the controller and each device. A protocol is used to define messages over the fieldbus network with each message identifying a particular sensor on the network.

Firewall - A devise on a communications network that can be programmed to filter information based on the information content, source or destination.

Human Machine Interface (HMI) - The hardware or software through which an operator interacts with a controller. An HMI can range from a physical control panel with buttons and indicator lights to an industrial PC with a color graphics display running dedicated HMI software.

Internet - a system of linked networks that are worldwide in scope and facilitate data communication services. The Internet is currently a communications highway for millions of users.

Input/Output (I/O) - a module relaying information sent to the processor from connected devices (input) and to the connected devices from the processor (output).

Light Tower - A device containing series of indicator lights and an embedded controller used to indicate the state of a process based on an input signal.

Local Area Network (LAN) - A network of computers that span a relatively small space. Each computer on the network is called a node, has its own hardware and runs its own programs, but can also access any other data or devices connected to the LAN. Printers, modems and other devices can also be separate nodes on a LAN.

Machine Controller - A control system/motion network that electronically synchronizes drives within a machine system instead of relying on synchronization via mechanical linkage.

Modem - A device that allows a computer to communicate through a phone line.

Management Information System (MIS) - A software system for accessing data from production resources and procedures required to collect, process, and distribute data for use in decision-making.

Manufacturing Execution System (MES) - Systems that use network computing to automate production control and process automation. By downloading "recipes" and work schedules and uploading production results, a MES bridges the gap between business and plant-floor or process-control systems.

OPC Client/Server - A mechanism for providing interoperability between disparate field devices, automation/control, and business systems.

Peer-to-Peer network - A networking configuration where there is no server and computers connect with each other to share data. Each computer acts as both a client (information or service requestor) and a server (information or service provider).

Photo Eye - A light sensitive sensor utilizing photoelectric control that converts a light signal into an electrical signal ultimately producing a binary signal based on an interruption of a light beam.

Pressure Regulator - A device used to control the pressure of a gas or liquid.

Pressure Sensor - A sensor system that produces an electrical signal related to the pressure acting on it by its surrounding medium.

Primary Domain Controller - A Windows NT server responsible for managing domain information, such as login IDs and passwords.

Printer - A device that converts digital data to human readable text on a paper medium.

Process Controller - A proprietary, typically rack mounted, computer system that processes sensor input, executes control algorithms and computes actuator outputs.

Programmable Logic Controller (PLC) - A small industrial computer used in factories originally designed to replace relay logic of a process control system and has evolved into a controller having the functionality of a process controller.

Proximity Sensor - A non-contact sensor with the ability to detect the presence of a target, within a specified range.

Redundant Control Server - A backup to the control server that maintains the current state of the control server at all times.

Remote Terminal Unit (RTU) - A computer with radio interfacing used in remote situations where communications via wire is unavailable. Usually used to communicate with remote field equipment. PLCs with radio communication capabilities are also used in place of RTUs.

Servo Valve - An actuated valve that's position is controlled using a servo actuator.

Sensor - A device that senses or detects the value of a process variable and generates a signal related to the value. Additional transmitting hardware is required to convert the basic sensor signal to a standard transmission signal. Sensor is defined as the complete sensing and transmitting device.

Single Loop Controller - A controller that controls a very small process or a critical process.

Solenoid Valve - a valve actuated by an electric coil. A solenoid valve typically has two states: open and closed.

Supervisory Control and Data Acquisition System (SCADA) - Similar to a Distributed Control System with the exception of sub-control systems being geographically dispersed over large areas and accessed using Remote Terminal Servers.

Temperature Sensor - A sensor system that produces an electrical signal related to its temperature and, as a consequence, senses the temperature of its surrounding medium.

Variable Frequency Drive (VFD) - A type of drive that controls the speed, but not the precise position, of a non servo, AC motor by varying the frequency of the electricity going to that motor. VFDs are typically used for applications where speed and power are important, but precise positioning in not.

Workstation - A computer used for tasks such as programming, engineering, and design.

Wide Area Network - A network that spans a larger area than a LAN. It consists of two or more LANs connected to each other via telephone lines or some other means of connection.

Wireless Device - A device that can connect to a manufacturing system via radio or infrared waves to typically collect/monitor data, but also in cases to modify control set points.

References

1. George D. Jelatis, "Information Security Primer", Secure Computing Corporation, for EPRI.

2. Micrologic Systems Inc., "SCADA Primer", http://www.micrologic.com.ph/primers/scada.htm.

3. Natural Gas Information and Educational Resources, http://www.naturalgas.org.

4. Dr. Sam Bowser, "Real Time (RT) Security Strawman - (draft)", The Aerospace Corp., for The Open Group RT Forum Security Group.

5. B. Schneier and A. Shostack, "Breaking Up Is Hard To Do: Modeling Security Threats for Smart Cards", Counterpane Internet Security Web Site, http://www.counterpane.com/smart-card-threats.html.