**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.  **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.[^1] 

# 

# 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[^2] 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.

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.

3.  **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.*

# **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.

# **Process Control System Definition** [^3][^4]

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.

![](media/image1.png){width="4.697916666666667in"
height="2.9583333333333335in"}

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.[^5] 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[^6]:

-   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[^7]

-   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.*

## 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:

```{=html}
<!-- -->
```
-   Physical and IT operating environment and controls

```{=html}
<!-- -->
```
-   Endangerment of Public Health and Safety

-   Environmental Damage

```{=html}
<!-- -->
```
-   Specific process control industry and function

```{=html}
<!-- -->
```
-   Loss of Production/Generation/Distribution

```{=html}
<!-- -->
```
-   Process control component technology and implementation

-   Safety-critical environment

```{=html}
<!-- -->
```
-   Harm to Personnel and Equipment

```{=html}
<!-- -->
```
-   Compromising of Proprietary Information

-   Liability

```{=html}
<!-- -->
```
-   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[^8].

## Secure Usage and Environment Assumptions[^9]

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

-   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[^11] 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[^12] , 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.

## Vulnerabilities[^13][^14]

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. {#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. .unnumbered}

#  {#section-3 .unnumbered}

# 2. The focus for defining vulnerabilities will be based on the following minimal set of PCS functions and capabilities: {#the-focus-for-defining-vulnerabilities-will-be-based-on-the-following-minimal-set-of-pcs-functions-and-capabilities .unnumbered}

#  {#section-4 .unnumbered}

# 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.

#  {#section-5 .unnumbered}

# 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.

#  {#section-6 .unnumbered}

# 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.

#  {#section-7 .unnumbered}

# 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.

#  {#section-8 .unnumbered}

# 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.

#  {#section-9 .unnumbered}

# 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.

#  {#section-10 .unnumbered}

# 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: {#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 .unnumbered}

#  {#section-11 .unnumbered}

# 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.[^15]

-   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.

## 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[^16]:

-   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.

```{=html}
<!-- -->
```
-   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.

# **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.

![](media/image2.png){width="6.302083333333333in"
height="4.378472222222222in"}

# **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.

![](media/image3.png){width="6.301388888888889in"
height="4.4006944444444445in"}

## 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

[^1]: By end-to-end security in life-cycle processes I'm implying the
    security engineering of criteria to be met; verification processes
    such as certification and accreditation to ensure that solutions are
    appropriately matched with the operating environment; and the
    ongoing security engineering to ensure that as systems evolve
    through upgrades and replacements, that the desired level of
    security is maintained.

[^2]: Vendors are to be engaged after the initial draft is complete

[^3]: This section exists for informational purposes to establish a
    context for the definition of the PCS. In that regard the issues of
    PCS system definition are identified so that reviewers can provide
    comments from a consistent basis. The conclusion that we can ignore
    the nomenclature of PLC vs. DCS vs. SCADA must be verified to be a
    correct assertion.

[^4]:

[^5]: This represents a recommendation for how we are to proceed with
    identification of distinct PCS vulnerabilities. The following
    section continues along this line of thought with specific
    recommendation for an approach to collect the required information.

[^6]: Although we are asserting this here in section 2, the final text
    of this section will be based upon the threats and policies defined
    in the Operational Security Environment section.

[^7]: An agent is defined as a human entity or active digital entity
    (process, message, mobile code, etc.).

[^8]: This overlap exists because policy statements are derived from an
    assessment of existing vulnerabilities.

[^9]: Many of the assumptions exist to highlight issues and invite
    discussion. They are not expected to remain in their current form.

[^10]: This is currently more of an "all-inclusive" list of issues that
    are relevant but not necessarily appropriate for this specification.
    We will not be able to answer the question of keep/discard until we
    get more substance to the document. Note also that some of these
    statements may be better stated in the form of policy or may be
    restated in the form of vulnerabilities of the PCS from which we can
    derive threat statements.

[^11]: Casual may not be the correct word. The intent is that published
    or advertised vulnerabilities will be addressed through proper
    installation and configuration of perimeter defense devices.

[^12]: Is the use of Fieldbus in this context accurate?

[^13]: For now the discussion will be focused on identifying the
    vulnerabilities that may be exploited. We will reach consensus on
    such a list and then recast the statements in the form of realized
    attacks -- i.e., the exploitation of vulnerability for some intended
    purpose. Note also that these statements include the notion of the
    implications resulting from exploitation of the stated
    vulnerability.

[^14]: I'd like to recommend that for now we stay away from talking
    threats and policies (per the CC). Instead we should talk in terms
    of vulnerabilities that are known given the current state of
    practice. We can also include discussion of known policies that
    either requires security or that have security implications.

[^15]: For now we can go with repeated statements, one each for the
    various forms of vulnerabilities against networked components.

[^16]: This information exists only as a placeholder for future
    discussion. Discussion of functionality (countermeasures or
    enforcement capability) should not occur without first defining the
    system and its operational environment. This is part of the
    bottom-up or middle-out approach.