dISA-99 00 01

DRAFT dISA-99.00.
01
DRAFT dISA-99.00.01
Manufacturing and Control Systems Security
Part 1: Concepts, Models and Terminology
Draft 2, Edit 3
October 2005
THIS DRAFT VERSION IS STRICTLY FOR REVIEW BY

ISA-SP99 MEMBERS ONLY
This document is a draft that represents work being done by an ISA Standards Committee leading to the
development of an ISA Standard. ISA grants permission to anyone to reproduce and distribute copies of this
draft ISA standard, in whole or in part, but only for the following purposes and only as long as the recipient
is not charged any fee for the copy (nor may the copy be included as part of a package with other materials
or presentations for which a fee is charged):
1.
Review of and comment on the draft standard;
2.
Provide to others for review and comment;
3.
Promotion of the standard; or
4.
Informing and educating others about the standard.
In addition, all copies must reproduce a copyright notice as follows:

Copyright 2005 ISA. All rights reserved. Reproduced and distributed with permission of ISA.
ISA reserves all other rights to the draft standard. Any other reproduction or distribution without the prior
written consent of ISA is prohibited.
The reader is cautioned that this document has not been approved and cannot be presumed to reflect the
position of ISA or any other committee, society, or group. Although every effort has been made to ensure
accuracy, neither ISA, members of the S&P Department, nor their employers shall be held liable for errors or
limitations.
dISA-99.00.01 (Draft 2, Edit 3)
DRAFT dISA-99.00.01
Editors Comments
This is a working draft, owned and maintained by Working Group #3 of the ISA SP-95 committee. All updates and
revisions are tracked using a two-tiered structure that includes a Draft number and an Edit number.
Document content is developed in a series of smaller documents, each containing material for a specific section. New
Drafts are typically created after each comprehensive review of document content (e.g., working group meetings), with
Edits being created as individual sections are added or updated.
Explanatory and editorial comments (such as this one) appear throughout this document in this boxed format. They
will not appear in final or published versions of the document.
dISA-99.00.01
Part 1: Models and Terminology
ISBN: 1-55617- 975-8
Copyright 2005 by the Instrumentation, Systems and Automation Society. All rights reserved. Not for
resale. Printed in the United States of America.
ISA
67 Alexander Drive
P. O. Box 12277
Research Triangle Park, NC 27709 USA
October 2005
DRAFT dISA-99.00.01
Preface
This preface, as well as all footnotes and annexes, is included for information purposes and is not part of
dISA 99.00.01.
This document has been prepared as part of the service of ISA, the Instrumentation, Systems and
Automation Society, toward a goal of uniformity in the field of instrumentation. To be of real value, this
document should not be static but should be subject to periodic review. Toward this end, the Society
welcomes all comments and criticisms and asks that they be addressed to the Secretary, Standards and
Practices Board; ISA; 67 Alexander Drive; P. O. Box 12277; Research Triangle Park, NC 27709;
Telephone (919) 549-8411; Fax (919) 549-8288; E-mail: standards@isa.org.
The ISA Standards and Practices Department is aware of the growing need for attention to the metric
system of units in general, and the International System of Units (SI) in particular, in the preparation of
instrumentation standards. The Department is further aware of the benefits to USA users of ISA
standards of incorporating suitable references to the SI (and the metric system) in their business and
professional dealings with other countries. Toward this end, this Department will endeavor to introduce
SI-acceptable metric units in all new and revised standards, recommended practices, and technical
reports to the greatest extent possible. Standard for Use of the International System of Units (SI): The
Modern Metric System, published by the American Society for Testing & Materials as IEEE/ASTM SI 1097, and future revisions, will be the reference guide for definitions, symbols, abbreviations, and
conversion factors.
It is the policy of ISA to encourage and welcome the participation of all concerned individuals and
interests in the development of ISA standards, recommended practices, and technical reports.
Participation in the ISA standards-making process by an individual in no way constitutes endorsement by
the employer of that individual, of ISA, or of any of the standards, recommended practices, and technical
reports that ISA develops.
CAUTION ISA adheres to the policy of the American National Standards Institute with regard to
patents. If ISA is informed of an existing patent that is required for use of the standard, it will
require the owner of the patent to either grant a royalty-free license for use of the patent by users
complying with the standard or a license on reasonable terms and conditions that are free from
unfair discrimination.
Even if ISA is unaware of any patent covering this Standard, the user is cautioned that
implementation of the standard may require use of techniques, processes, or materials covered
by patent rights. ISA takes no position on the existence or validity of any patent rights that may be
involved in implementing the standard. ISA is not responsible for identifying all patents that may
require a license before implementation of the standard or for investigating the validity or scope
of any patents brought to its attention. The user should carefully investigate relevant patents
before using the standard for the users intended application.
However, ISA asks that anyone reviewing this standard who is aware of any patents that may
impact implementation of the standard notify the ISA Standards and Practices Department of the
patent and its owner.
Additionally, the use of this standard may involve hazardous materials, operations or equipment.
The standard cannot anticipate all possible applications or address all possible safety issues
associated with use in hazardous conditions. The user of this standard must exercise sound
professional judgment concerning its use and applicability under the users particular
circumstances. The user must also consider the applicability of any governmental regulatory
limitations and established safety and health practices before implementing this standard.
October 2005
DRAFT dISA-99.00.01
The following people served as active members of ISA-SP99 Working Group 3 for the preparation of this
document:
Name
Company
Jim Bauhs
Cargill
Rahul Bhojani
Bayer
Mike Bush
Rockwell Automation
Rich Clark
Invensys Wonderware
Eric Cosman ***
The Dow Chemical Company
Jean-Pierre Dalzon
ISA
Ronald Derynck
Verano
David Elley
Aspen Technology Inc.
Robert Evans
Idaho National Laboratories
Jim Gilsinn
NIST
Tom Good
DuPont
Ron Greenthaler
TXU Energy
Evan Hand **
Kraft Foods
Dennis Holstein
OPUS Publishing
Chuck Hoover
Rockwell
Rene Lara
Invensys
Dave Mills
Procter & Gamble
Johan Nye
ExxonMobil
Richard Oyen
ABB
Dale Peterson
Digital Bond
Ernie Rakaczky
Invensys
Jens Seest
Novo Nordisk A/S
Ron Sielinski
Microsoft
Bryan Singer *
Rockwell Automation
Leon Steinocher
Fluor Enterprises
Joe Weiss
***
KEMA Consulting
**
Chairman
Editor
Reviewer
Bob Webb
*
Contributor
****
Vice Chairman
Secretary
October 2005

DRAFT dISA-99.00.01
Contents
1
Scope
1.1
Functional Elements
10
1.2
Activity-Based Criteria
11
1.3
Asset-Based Criteria
12
Normative References
2.1
10
13
Other References
13
Definitions
14
3.1
Common Terms and Definitions
14
3.2
Abbreviations
38
Manufacturing and Control Systems Security Overview
41
4.1
Current Environment
41
4.2
Current Systems
42
4.3
Current Trends
43
4.4
Elements of Security
44
Manufacturing and Control Systems Concepts
45
5.1
Security Context
45
5.2
Security Zones
53
5.3
Conduits (Information Flows)
54
5.4
Security Levels
55
5.5
Policy
56
Models
61
6.1
Reference Model
61
6.2
Physical Models
67
6.3
Logical Models
73
6.4
Functional Models
81
6.5
Conceptual Models
88
October 2005
DRAFT dISA-99.00.01

Figures
Figure 1 Functional Scope ....................................................................................................................... 11
Figure 2 - Comparison of Objectives .......................................................................................................... 44
Figure 3 Context Model............................................................................................................................ 45
Figure 4 General Reference Model ......................................................................................................... 62
Figure 5 DCS Example using the General Reference Model .................................................................. 65
Figure 6 Example Reference Model with Security Zones........................................................................ 66
Figure 7 Process Manufacturing Control System Example ..................................................................... 68
Figure 8 Manufacturing Hierarchy Model................................................................................................. 69
Figure 9 SCADA Physical Hierarchy Model............................................................................................. 71
Figure 10 Vehicle Physical Hierarchy Model ........................................................................................... 72
Figure 11 Multi-plant Zone Model ............................................................................................................ 74
Figure 12 Separate Zones ....................................................................................................................... 74
Figure 13 Enterprise Conduit ................................................................................................................... 78
Figure 14 Functional Hierarchy Model..................................................................................................... 81
Figure 15 Activity Model........................................................................................................................... 85
Tables
Table 1 Types of Loss by Asset Type...................................................................................................... 47
October 2005

DRAFT dISA-99.00.01
Foreword
The content of this section will finalized after all other sections have been completed or when significant changes are
made to the structure and content of the major sections of the document.
This document is Part 1 of a multi-part standard that addresses the subject of Manufacturing and Control
Systems security.
The scope of this Part 1 standard is limited to describing the basic concepts and models related to
security. Subsequent parts will address the application of these concepts and models in areas such as
security program definition and the minumum security reqyuirements. In this standard, terms such as
enterprise, controls, process control, and manufacturing are used in their most general sense and
are held to be applicable to a broad sector of industries.
This Part 1 standard is structured to follow IEC (International Electrotechnical Commission) guidelines.
Therefore, the first three clauses present the scope of the standard, normative references, and
definitions, in that order.
Clause 4 is informative. The intent is to provide a broad overview of the subject and establish the frame of
reference for more detailed descriptions that follow.
Clause 5 is normative. It describes basic concepts that establish the scope of manufacturing and control
systems security.
Cluase 6 is normative. It describes a series of models that address various physical aspects of the topic.
Clause 7 is normative. It describes the corresponding logical models of security.
Clause 8 is normative. It describes models that represent the logical or functional view of manufacturing
and control systems security.
Clause 9 is normative. It describes various conceptual models that may be used to assess effectiveness
of a security program or the resulting systems.
October 2005
DRAFT dISA-99.00.01

Introduction
This is the first in a series of standards that address the subject of Manufacturing and Control Systems1
security. The subject of this standard is Concepts, Models and Terminology, and the purpose is to
establish the basis for the remaining standards in this series.
Typical questions addressed by this standard include:
a) What is the general scope of application for Manufacturing and Control Systems Security?
b) How can the components of a Manufacturing and Control System be grouped or classified for the
purpose of defining and managing security?
c) What are the different electronic security objectives for control system applications?
d) How can these levels be established and codified?
e) What are the key security terms and concepts and how are they defined in this context?
The material contained in this document:
establishes the scope of application by defining the types of Manufacturing and Control Systems
that are the focus of the standard
defines the most common general terms used to describe various aspects of the subject
describes the basic concepts that form the foundation for further analysis of the activities, system
attributes, and actions that are important to provide electronically secure control systems, and
introduces a set of basic models that provide a framework or reference for additional standards in
the series.
Each of these elements is addressed in more detail in subsequent sections of this standard.
Document Outline
The first section defines the scope of the standard. This is done by first defining the term Manufacturing
and Control Systems in terms of the types of systems to which it is applied. This is followed by a
description of scope in term of functional elements, each of which in turn exists at various levels of a
hierarchy that has been established and applied by other standards. Finally, activity and asset based
criteria are provided to determine whether a particular item is included within the scope of this standard.
It is common for documents such as this to build on previous standards. A list of normative references is
included to document these dependencies.
The third section is a comprehensive list of terms and definitions. Most are drawn from established
references, but some are derived for the purpose of this standard. The objective is to establish common
terms that will also be used in subsequent standards in this series.
With scope, context and terminology established, the next task is to describe several concepts that form
the basis of this series of standards. Many of these concepts are well established within the security
discipline, but their applicability to industrial systems may not have been clearly described. In some cases
the nature of industrial systems leads to an interpretation that may be slightly different than that used for
more general information technology applications.
The term Manufacturing and Control Systems is described in more detail in the Scope section.
ISA-99.00.01 (Draft 2, Edit 3)

Last saved 10/12/2005 4:02:00 PM by isa; Printed 10/12/2005 4:03:00 PM
October 2005

ISA-99.00.01
The final section of the standard describes a series of models that can be used to illustrate and examine
the basic elements of security for Manufacturing and Control Systems. As with the concepts, several
models are based on more generic views, with some aspects adjusted to address specific aspects of
industrial applications.
Related Standards
With the basic concepts established in this standard, additional standards in the series are planned to
address more detailed aspects of the subject. Additional standards currently planned or under
development include:
ISA 99.00.02 Establishing a Manufacturing and Control Systems Security Program

Gives practical guidance and direction on how to establish the business case for a security program
and how to design the program to meet business needs.
ISA 99.00.03 Operating a Manufacturing and Control Systems Security Program

Describes how a security program is operated after it is designed and implemented.
ISA 99.00.04 Specific Security Requirements for Manufacturing and Control Systems
Defines the characteristics of Manufacturing and Control Systems that differentiate them from other
Information Technology systems from a security point of view. Based on these characteristics,
establishes the security requirements that are unique to this class of system.
October 2005

DRAFT dISA-99.00.01

1 Scope
The subject of this standard is the Manufacturing and Control Systems Security. In defining the scope of
this standard the term Manufacturing and Control Systems is applied in the broadest practical sense,
encompassing all types of manufacturing plants and facilities, as well as other processing operations
such as utilities (i.e., electric, gas and water), pipelines and transportation systems or other industries
which use automated or remotely controlled assets.
Specifically, Manufacturing and Control Systems include all systems that can affect or influence the safe,
secure and reliable operation of an industrial process. They include, but are not limited to:
process control systems, including Distributed Control Systems (DCS), Programmable Logic
Controllers (PLC), Remote Terminal Units (RTU), Intelligent Electronic Devices (IED),
Supervisory Control and Data Acquisition (SCADA), networked electronic sensing and control,
and monitoring and diagnostic systems (In this context, process control systems include Basic
Process Control System (BPCS) and Safety Instrumented System (SIS) functions, whether they
are physically separate or integrated.)
associated information systems such as advanced or multi-variable control, online optimizers,

dedicated equipment monitors, graphical interfaces, process historians, manufacturing execution
systems and plant information management systems
associated internal, human, network, or machine interfaces used to provide control, safety, and
manufacturing operations functionality to continuous, batch, discrete, and other processes.
For the purpose of this standard, the term Security is considered to mean the prevention of illegal or
unwanted penetration of or interference with the proper and intended operation of the Manufacturing and
Control System. The particular focus of this standard is cyber or electronic security, which includes
computer, network or other programmable components of the system. A more detailed definition of the
term Security is contained in the Concepts section of this document.
Scope may also be defined by listing or describing the functional elements included, or by providing a set
of criteria for selecting elements that are considered to be included. Each of these methods is applied in
the following sections.
1.1
Functional Elements
The scope of this standard can be expressed in terms of the range of functionality addressed. Such
functionality is usually described in the form of a model. One such model was initially defined in the
Reference Model for Computer Integrated Manufacturing2. It describes a series of levels within an
integrated manufacturing system.
It is also important to understand the scope of this standard with respect to other standards which
address the subject of security of generica information technology. One such standard is ISO 177993,
which provides general recommendations for information security management.
Using the Purdue model as a reference, it is possible to position this standard with respect to ISO 17999
and describe the specific areas of focus. This is shown in the following figure.
Purdue Research Foundation, A Reference Model for Computer Integrated Manufacturing, 1989, ISBN
1-55617-225-7
ISO/IEC 17799, Information technology Code of practice for information security management, 2000
10

October 2005
Company Management
Information
Company Production
Assignment Scheduling
Supervision
Company Production
Scheduling Assignment
Level 4
Operational & Production

Supervision
Production Scheduling
& Operational
Management
Level 3
Supervisors Console
Inter-Area Coordination
Level 2
Supervisors Console
Supervisory Control
Level 1
Operators Console
Direct Digital Control
Purdue reference Model Levels
Level 5
Controllers
Process
Process Safety
(ISA 84,
IEC 61508,
IEC 61511)
Company Management
Data Presentation
Mfg Security Policies

and Practices
(ISA 99)
ISA-99.00.01
Com
mon
tech
IT Security Policies and Practices
nolo
gies
(ISO 17799)
, pol
icies
and
prac
tices

Figure 1 Functional Scope

In terms of this model, the primary focus of this standard is on levels 0 through 3 of this hierarchy.
Business Planning and Logistics Systems (i.e., Level 4) are not explicitly addressed within the scope of
this standard, although the integrity of data communications between this and the other levels are
considered.
1.2
Activity-Based Criteria
It is also possible to describe the scope of the standard in terms of the activities that are addressed. A
system should be considered to be within in the scope of this standard if any of the following criteria are
met:
a)
b)
c)
d)
e)
The activity performed is critical to process safety;

The activity performed is critical to process reliability or availability;
The activity performed is critical to process efficiency;
The activity performed is critical to product quality;
The activity performed is critical to maintaining regulatory compliance.
October 2005

11
DRAFT dISA-99.00.01
1.3

Asset-Based Criteria
The scope of the standard can also be defined in terms of the assets for which security and protection are
required. An asset should be considered to be within in the scope of this standard if any of the following
criteria are met:
a)
b)
c)
d)
e)
f)
g)
h)
i)
The asset has significant economic value to the manufacturing or operating process;
The asset performs a function critical to operation of the manufacturing or operating process;
The asset, in sufficient quantity, is a significant portion of inventory;
The asset is necessary as a material for product manufacturing;
The asset represents intellectual property of the manufacturing or operating process;
The asset is necessary to operate and maintain security for the manufacturing or operating process;
The asset is necessary to protect personnel, contractors and visitors;
The asset is a legal requirement, especially for security purposes;
The asset is needed for disaster recovery purposes.
This includes systems whose compromise could result in the endangerment of public or employee health
or safety, loss of public confidence, violation of regulatory requirements, loss or invalidation of proprietary
or confidential information, economic loss or impact on entity, local or national security
12

October 2005

DRAFT dISA-99.00.01
2 Normative References
The following normative documents contain provisions, which through reference in this text constitute
provisions of this part of this standard. At the time of publication, the editions indicated were valid. All
normative documents are subject to revision, and parties to agreements based on this part of this
standard are encouraged to investigate the possibility of applying the most recent editions of the
normative documents indicated below. Members of IEC and ISO maintain registers of currently valid
normative documents.
1. ANSI/ISA 95.00.01-2000, Enterprise-Control System Integration Part 1: Models and Terminology
2. ANSI/ISA-88.01-1995, Batch Control Part 1: Models and Terminology
3. ISO/IEC 7498: Information processing systems Open System Interconnection Basic reference
Model, Part 2: Security Architecture
4. CNSS Instruction No. 4009, National Information Assurance Glossary, May 2003,
http://www.cnss.gov/Assets/pdf/cnssi_4009.pdf
5. SANS Glossary of Terms used in Security and Intrusion Detection, May 2003,
http://www.sans.org/resources/glossary.php
6. RFC 2828, Internet Security Glossary, May 2000
7. Federal Information Processing Standards (FIPS) PUB 140-2, (2001) SECURITY REQUIREMENTS
FOR CRYPTOGRAPHIC MODULES, Section 2, Glossary of Terms and Acronyms, U.S. National
Institute of Standards and Technology.
8. Federal Information Processing Standards Publication, FIPS PUB 140-2, Security Requirements for
Cryptographic Modules, December 2002
2.1
Other References
The following documents contain material referenced in this standard.

a)
Purdue Research Foundation, A Reference Model for Computer Integrated Manufacturing, 1989,
ISBN 1-55617-225-7
October 2005
13
DRAFT dISA-99.00.01

3 Definitions
This section lists the terms, definitions and abbreviations used in this standard.
3.1
Common Terms and Definitions
Wherever possible, definitions have been taken from established industry sources. Specific sources cited
include:
[1] CNSS Instruction No. 4009, National Information Assurance Glossary, May 2003,
[2] SANS Glossary of Terms used in Security and Intrusion Detection, May 2003,
http://www.sans.org/resources/glossary.php
[3] RFC 2828, Internet Security Glossary, May 2000
[4] Federal Information Processing Standards (FIPS) PUB 140-2, (2001) SECURITY REQUIREMENTS
FOR CRYPTOGRAPHIC MODULES, Section 2, Glossary of Terms and Acronyms, U.S.
National Institute of Standards and Technology.
[5] ISO/IEC 7498: Information processing systems Open System Interconnection Basic reference
Model, Part 2: Security Architecture
[6] Federal Information Processing Standards Publication, FIPS PUB 140-2, Security Requirements for
Cryptographic Modules, December 2002
Unused terms and definitions will be deleted after the latter clauses of this draft standard have been completed.
The following terms have been identified.

3.1.1
access
the ability and means to communicate with or otherwise interact with a system in order to use system
resources to either handle information or gain knowledge of the information the system contains [3]
3.1.2
access authority
an entity responsible for monitoring and granting access privileges for other authorized entities. [3]
3.1.3
access control
the protection of system resources against unauthorized access; a process by which use of system
resources is regulated according to a security policy and is permitted by only authorized entities (users,
programs, processes, or other systems) according to that policy. [3]
3.1.4
access control center (ACC)
a computer containing a database with entries that define a security policy for an access control service.
An ACC is sometimes used in conjunction with a key center to implement access control in a key
distribution system for symmetric cryptography. [3]
14
October 2005

3.1.5
DRAFT dISA-99.00.01
access control list (ACL)
a mechanism that implements access control for a system resource by enumerating the identities of the
system entities that are permitted to access the resource. [3]
3.1.6
accountability
the property of a system (including all of its system resources) that ensures that the actions of a system
entity may be traced uniquely to that entity, which can be held responsible for its actions [3]
3.1.7
administrative security
management procedures and constraints to prevent unauthorized access to a system [3]

3.1.8
adversary
an entity that attacks, or is a threat to, a system [3]

3.1.9
application
a software program that performs a specific function directly for a user and can be executed without
access to system control, monitoring, or administrative privileges [1]
3.1.10 application layer protocols
Protocols specific to executing network applications such as email and file transfer. Layer 7 of the OSI
reference model in standard ISO 7498, Information Technology Open Systems Interconnection Basic
Reference Model
3.1.11 association
cooperative relationship between system entities, usually for the purpose of transferring information
between them [3]
3.1.12 assurance
attribute of an information system that provides grounds for having confidence that the system operates
such that the system security policy is enforced [3]
3.1.13 asymmetric cryptography
cryptographic techniques that use complimentary asymmetric functions to encrypt and decrypt
information, to sign and verify digital signatures, to issue and validate digital certificates, or to reach
agreement on a shared secret key [3]
3.1.14 attack
assault on system security that derives from an intelligent threat, i.e., an intelligent act that is a deliberate
attempt (especially in the sense of a method or technique) to evade security services and violate the
security policy of a system [3]
NOTE:
There are different commonly-recognized classes of attack:
An "active attack" attempts to alter system resources or affect their operation. A "passive attack" attempts to learn or
make use of information from the system but does not affect system resources.
October 2005
15
DRAFT dISA-99.00.01

An "inside attack" is an attack initiated by an entity inside the security perimeter (an "insider"), i.e., an entity that is
authorized to access system resources but uses them in a way not approved by those who granted the
authorization. An "outside attack" is initiated from outside the perimeter, by an unauthorized or illegitimate user
of the system (an "outsider"). Potential outside attackers range from amateur pranksters to organized criminals,
international terrorists and hostile governments.
3.1.15 audit
an independent review and examination of records and activities to assess the adequacy of system
controls, to ensure compliance with established policies and operational procedures, and to recommend
necessary changes in controls, policies, or procedures [1]
3.1.16 audit service
security service that records information needed to establish accountability for system events and for the
actions of system entities that cause them [3]
3.1.17 authenticate
to verify the identity of a user, user device, or other entity, or the integrity of data stored, transmitted, or
otherwise exposed to unauthorized modification in an IS, or to establish the validity of a transmission. [1]
3.1.18 authentication
a security measure designed to establish the validity of a transmission, message, or originator, or a
means of verifying an individual's authorization to receive specific categories of information. [1]
3.1.19 authorization
a right or a permission that is granted to a system entity to access a system resource [3]
3.1.20 authorization process
a procedure for granting authorization rights [3]
3.1.21 automated information system (AIS)
an organized assembly of resources and procedures--i.e., computing and communications equipment
and services, with their supporting facilities and personnel--that collect, record, process, store, transport,
retrieve, or display information to accomplish a specified set of functions [3]
3.1.22 automation cell (AC)
zone within a larger zone within a plant, used to partition a large plant into separate major areas with
independent production missions
3.1.23 availability
the property of a system or a system resource being accessible and usable upon demand by an
authorized system entity, according to performance specifications for the system; i.e., a system is
available if it provides services according to the system design whenever users request them [3]
3.1.24 bandwidth
commonly used to mean the capacity of a communication channel to pass data through the channel in a
given amount of time. usually expressed in bits per second. [3]
16
October 2005

DRAFT dISA-99.00.01
3.1.25 black channel

communication channel without available evidence of design or validation according to IEC 61508 and
IEC WD/61784-3
3.1.26 boundary
a software, hardware, or physical barrier that limits access to a system or part of a system [1]
3.1.27 British Standard 7799
Part 1 is a standard code of practice and provides guidance on how to secure an information system. Part
2 specifies the management framework, objectives, and control requirements for information security
management systems [B7799]. The certification scheme works like ISO 9000. It is in use in the UK, the
Netherlands, Australia, and New Zealand and might be proposed as an ISO standard or adapted to be
part of the Common Criteria.
3.1.28 certificate
See digital certificate
3.1.29 certification authority
an entity that issues digital certificates (especially X.509 certificates) and vouches for the binding between
the data items in a certificate. [3]
3.1.30 cipher
cryptographic algorithm for encryption and decryption [3]
3.1.31 ciphertext
data that has been transformed by encryption so that its semantic information content (i.e., its meaning) is
no longer intelligible or directly available [3]
3.1.32 cleartext
data in which the semantic information content (i.e., the meaning) is intelligible or is directly available [3]
3.1.33 client
a device or application receiving or requesting services or information from a server application. [4]
3.1.34 client-side policy enforcement
technological means to ensure that a remote client, before being given access to a server network, is in
accordance with policies imposed by the server network zone
NOTE:
Such policies could refer to installation/update/status of virus checkers, installation/update/status of host based intrusion
detection systems, configuration settings, user accounts, restrictions on concurrent network connections, or installed
applications. This functionality has different names depending on the vendors. One common designator for the underlying
concept is the client quarantine.
October 2005
17
DRAFT dISA-99.00.01

3.1.35 Common Criteria for Information Technology Security

the Common Criteria" is a standard for evaluating information technology products and systems, such as
operating systems, computer networks, distributed systems, and applications. It states requirements for
security functions and for assurance measures [3]
3.1.36 communication channel
logical connection between two or more end-points within a communication system
3.1.37 communication path
logical connection between a source and one or more destinations, which could be devices, physical
processes, data items, commands or programmatic interfaces
NOTE:
The communication path is not limited to wired or wireless networks, but includes other means of communication such as
memory, procedure calls, state of physical plant, portable media, human interactions etc.
3.1.38 communication security (ComSec)

1) measures that implement and assure security services in a communication system, particularly those
that provide data confidentiality and data integrity and that authenticate communicating entities
2) state that is reached by applying security services, in particular, state of data confidentiality, integrity,
and successfully authenticated communications entities [3]
NOTE:
This phrase is usually understood to include cryptographic algorithms and key management methods and processes,
devices that implement them, and the life cycle management of keying material and devices.
3.1.39 communication security layer

communication layer that includes all the necessary measures to provide secure transmission of data in
accordance with specific requirements
3.1.40 communication system
arrangement of hardware, software and propagation media to allow the transfer of messages (ISO/IEC
7498 application layer service data units) from one application to another
3.1.41 compromise
the unauthorized disclosure, modification, substitution, or use of sensitive data (including plaintext
cryptographic keys and other critical security parameters) [6]
3.1.42 computer security
measures and controls that ensure confidentiality, integrity, and availability of information system assets
including hardware, software, firmware, and information being processed, stored, and communicated [1]
3.1.43 confidentiality
Assurance that information is not disclosed to unauthorized individuals, processes, or devices. [1]
18
October 2005

DRAFT dISA-99.00.01
3.1.44 contingency plan

plan for emergency response, backup operations, and post-disaster recovery in a system as part of a
security program to ensure availability of critical system resources and facilitate continuity of operations in
a crisis [3]
3.1.45 control network (CN)
those networks of an enterprise that are the subject to this standard, typically connected to equipment
that controls physical processes and that is time or safety critical
NOTE:
The CN can be subdivided into zones, and there can be multiple separate CNs within one enterprise and site.
3.1.46 controlled space

three-dimensional space surrounding system equipment, within which unauthorized individuals are
denied unrestricted access and are either escorted by authorized individuals or are under continuous
physical or electronic surveillance [1]
3.1.47 cost
value impact to the organization or person that can be measured.
3.1.48 countermeasure
an action, device, procedure, or technique that reduces a threat, a vulnerability, or an attack by
eliminating or preventing it, by minimizing the harm it can cause, or by discovering and reporting it so that
corrective action can be taken [3]
3.1.49 credential(s)
Data that is transferred or presented to establish either a claimed identity of an entity [3]
3.1.50 critical
a condition of a service or other system resource such that denial of access to (i.e., lack of availability of)
that resource would jeopardize a system users ability to perform a primary function or would result in
other serious consequences [3]
3.1.51 critical security parameter (CSP)
security-related information (e.g., secret and private cryptographic keys, and authentication data such as
passwords and PINs) whose disclosure or modification can compromise the security of a cryptographic
module [6]
3.1.52 cryptanalysis
the mathematical science that deals with analysis of a cryptographic system in order to gain knowledge
needed to break or circumvent the protection that the system is designed to provide [3]
3.1.53 cryptographic algorithm
algorithm that based upon the science of cryptography, including encryption algorithms, cryptographic
hash algorithms, digital signature algorithms, and key agreement algorithms [3]
October 2005
19
DRAFT dISA-99.00.01

3.1.54 cryptographic key

(usually shortened to just "key") An input parameter that varies the transformation performed by a
cryptographic algorithm [3]
3.1.55 cryptographic Key
A parameter used in conjunction with a cryptographic algorithm that determines:
the transformation of plaintext data into ciphertext data

the transformation of ciphertext data into plaintext data
a digital signature computed from data
the verification of a digital signature computed from data
an authentication code computed from data
an exchange agreement of a shared secret. [4]
3.1.56 cyberattack
exploitation of the software or firmware vulnerabilities of information technology-based control
components.
3.1.57 cyclic redundancy check (CRC)
type of checksum algorithm that is not a cryptographic hash but is used to implement data integrity
service where accidental changes to data are expected [3]
3.1.58 data compromise
security incident in which information is exposed to potential unauthorized access, such that unauthorized
disclosure, alteration, or use of the information may have occurred [3]
3.1.59 data confidentiality
property that information is not made available or disclosed to unauthorized individuals, entities, or
processes (i.e., to any unauthorized system entity) [5]
3.1.60 data encryption key (DEK)
a cryptographic key that is used to encipher application data.[3]
3.1.61 data integrity
property that data has not been changed, destroyed, or lost in an unauthorized or accidental manner [3]
NOTE:
This term deals with constancy of and confidence in data values, not with the information that the values represent (see:
correctness integrity) or the trustworthiness of the source of the values (see: source integrity).
3.1.62 data link layer protocols

Protocols for interpreting electrical signals as data, error checking, physical addressing and media access
control. [2]
3.1.63 data origin authentication
corroboration that the source of data received is as claimed [5]
20
October 2005

DRAFT dISA-99.00.01
3.1.64 decryption
The process of changing ciphertext into plaintext using a cryptographic algorithm and key. [3]
3.1.65 defense in depth
a security architecture based on the idea that any one point of protection may, and probably will, be
defeated. It implies layers of security and detection, even on single systems and provides the following
features:
attackers are faced with breaking through or bypassing each layer without being detected
a flaw in one layer can be protected by capabilities in other layers
system security becomes a set of layers within the overall network security
security is improved by requiring the attacker to be perfect while ignorant
3.1.66 demilitarized zone (DMZ)

a perimeter network segment that is logically between internal and external networks. It purpose is to
enforce the internal networks policy for external information exchange and to provide external, untrusted
sources with restricted access to releasable information while shielding the internal networks from outside
attacks [1]
3.1.67 denial of service (DoS)
the prevention or interruption of authorized access to a system resource or the delaying of system
operations and functions [3]
3.1.68 digital certificate
a certificate document in the form of a digital data object (a data object used by a computer) to which is
appended a computed digital signature value that depends on the data object. [3]
3.1.69 digital signature
a value computed with a cryptographic algorithm and appended to a data object in such a way that any
recipient of the data can use the signature to verify the datas origin and integrity [3]
3.1.70 distributed control system (DCS)
type of control system in which the system elements are dispersed but operated in a coupled manner,
generally with coupling time constants much shorter than those found in SCADA systems
NOTE:
Digital control systems are commonly associated with continuous processes such as electric power generation; oil and
gas refining; chemical, pharmaceutical and paper manufacture, as well as discrete processes such as automobile and
other goods manufacture, packaging, warehousing, etc.
3.1.71 domain
an environment or context that is defined by a security policy, security model, or security architecture to
include a set of system resources and the set of system entities that have the right to access the
resources [3]
October 2005
21
DRAFT dISA-99.00.01

3.1.72 domain authentication server

server that stores and manages user accounts and credentials for the users of the associated network
domain
3.1.73 Domain Name System (DNS)
the main Internet operations database, which is distributed over a collection of servers and used by client
software for purposes such as translating a domain name-style host name into an IP address (e.g.,
"rosslyn.bbn.com" is "192.1.7.10") and locating a host that accepts mail for some mailbox address [3]
3.1.74 dual control
procedure that uses two or more entities (usually persons) operating in concert to protect a system
resource, such that no single entity acting alone can access that resource [3]
NOTE:
dual control provides a countermeasure to attacks by a single disgruntled, subverted or coerced insider
3.1.75 electronic security

includes the concepts of identification, authentication, accountability, authorization, availability and
privacy. The objective is to preclude unauthorized use, modifications to, disclosure, loss of revenue or
destruction of critical systems or informational assets in an effort to reduce the risk of personal injury or
possibility of endangering public health, loss of public or consumer confidence, disclosure of sensitive
assets, and protection of business assets. These concepts are applied to any system in the production
process and include both standalone and networked components. Communications between systems
may be either through internal messaging or by any human or machine interfaces that authenticate,
operate, control, or exchange data with any of these control systems.
3.1.76 encryption
cryptographic transformation of data (called "plaintext") into a form (called "ciphertext") that conceals the
datas original meaning to prevent it from being known or used. If the transformation is reversible, the
corresponding reversal process is called "decryption", which is a transformation that restores encrypted
data to its original state. [3]
3.1.77 evaluated system
refers to a system that has been evaluated against security criteria such as the TCSEC or the Common
Criteria [3]
3.1.78 external device (ED)
all devices that can contain computer programs or data except for those of the protected industrial
automation plant
3.1.79 external network (EN)
all networks except for the (possibly distributed) Control Network
3.1.80 fail safe
automatic protection of programs and/or processing systems when hardware or software failure is
detected [1]
22
October 2005

DRAFT dISA-99.00.01
3.1.81 fieldbus network

communication system used in industrial automation or process control applications
NOTE:
This concept is further detailed in [IEC 61158] and [IEC 61784-1].
3.1.82 filtering router

an internetwork router that selectively prevents the passage of data packets according to a security policy
[3]
3.1.83 firewall
an inter-network gateway that restricts data communication traffic to and/or from one of the connected
networks (the one said to be "inside" the firewall) and thus protects that network's system resources
against threats from the other network (the one that is said to be "outside" the firewall) [3]
NOTE:
A firewall may be either an application installed on a general-purpose computer or a dedicated, potentially proprietary
platform (appliance), that forwards or rejects/drops packets on a network. Typically firewalls are used to define zone
borders.
3.1.84 firewall host

general-purpose computer or dedicated proprietary platform on which a firewall application runs
3.1.85 flooding
an attack that attempts to cause a failure in (especially, in the security of) a computer system or other
data processing entity by providing more input than the entity can process properly [3]
3.1.86 gateway
a relay mechanism that attaches to two (or more) computer networks that have similar functions but
dissimilar implementations and that enables host computers on one network to communicate with hosts
on the other; an intermediate system that is the interface between two computer networks [3]
3.1.87 guard
a gateway that is interposed between two networks (or computers, or other information systems)
operating at different security levels (one level is usually higher than the other) and is trusted to mediate
all information transfers between the two levels, either to ensure that no sensitive information from the
first (higher) level is disclosed to the second (lower) level, or to protect the integrity of data on the first
(higher) level [3]
3.1.88 hash function
an algorithm that computes a value based on a data object (such as a message or file; usually variablelength; possibly very large), thereby mapping the data object to a smaller data object (the "hash result")
which is usually a fixed-size value
NOTE 1: The kind of hash function needed for security applications is called a "cryptographic hash function", an algorithm for which
it is computationally infeasible (because no attack is significantly more efficient than brute force) to find either (a) a data
object that maps to a pre-specified hash result (the "one-way" property) or (b) two data objects that map to the same hash
result (the "collision-free" property).
NOTE 2: A cryptographic hash function is a form of checksum in which any alteration of the checked information is likely to cause
each of the bits of the checksum to be complemented with independent mean probabilities of 0,5.
October 2005
23
DRAFT dISA-99.00.01

3.1.89 host
a computer that is attached to a communication subnetwork or internetwork and can use services
provided by the network to exchange data with other attached systems [3]
3.1.90 host-based intrusion detection system (HIDS)
application that detects attacker activity on a host from characteristics such as change of files (file system
integrity checker), operating system call profiles, etc (See intrusion detection)
3.1.91 identity-based security policy
security policy based on the identities and/or attributes of a user, a group of users, or entities acting on
behalf of the users and the resources/objects being accessed [5]
3.1.92 INFOSEC
an abbreviation for "information security", referring to security measures that implement and assure
security services in computer systems (i.e., COMPUSEC) and communication systems (i.e., COMSEC).
[3]
3.1.93 integrity
the quality of a system reflecting the logical correctness and reliability of the operating system; the logical
completeness of the hardware and software implementing the protection mechanisms; and the
consistency of the data structures and occurrence of the stored data. [1]
NOTE:
In a formal security mode, integrity is interpreted more narrowly to mean protection against unauthorized modification or
destruction of information.
3.1.94 interception
capture and disclosure of message contents; often referred to as sniffing, or use of traffic analysis to
compromise the confidentiality of a communication system based on message destination or origin,
frequency or length of transmission, and other communication attributes.
3.1.95 interface
A logical entry or exit point of a cryptographic module that provides access to the module for logical
information flows representing physical signals. [4]
3.1.96 intranet
computer network, especially one based on Internet technology, that an organization uses for its own
internal, and usually private, purposes and that is closed to outsiders [3]
3.1.97 intrusion
Unauthorized act of bypassing the security mechanisms of a system. [1]
3.1.98 intrusion detection
a security service that monitors and analyzes system events for the purpose of finding, and providing
real-time or near real-time warning of, attempts to access system resources in an unauthorized manner
[3]
24
October 2005

DRAFT dISA-99.00.01
3.1.99 IP address
inter-network address of a computer that is assigned for use by the Internet Protocol and other protocols
[3]
3.1.100 key center
centralized key distribution process (used in cryptography), usually a separate computer system, that
uses key-encrypting keys (master keys) to encrypt and distribute session keys needed in a community of
users [3]
3.1.101 key distribution
The transport of a key and other keying material from an entity that either owns the key or generates the
key to another entity that is intended to use the key. [3]
3.1.102 key distribution
process that delivers a cryptographic key from the location where it is generated to the locations where it
is used in a cryptographic algorithm [3]
3.1.103 key encapsulation
key hiding technique for storing knowledge of a cryptographic key by encrypting it with another key and
ensuring that only certain third parties called "recovery agents" can perform the decryption operation to
retrieve the stored key [3]
3.1.104 key encrypting key (KEK)
cryptographic key that is used to encrypt other keys, either DEKs or other KEKs, but usually is not used
to encrypt application data [3]
3.1.105 key escrow
key recovery technique, such as key escrow or key encapsulation, for storing knowledge of a
cryptographic key or parts thereof in the custody of one or more third parties called "escrow agents", so
that the key can be recovered and used in specified circumstances [3]
3.1.106 key establishment
process that combines the key generation and key distribution steps needed to set up or install a secure
communication association [3]
3.1.107 key generation
process that creates the sequence of symbols that comprise a cryptographic key [3]
3.1.108 key length
number of bits needed to be able to represent any of the possible values of a cryptographic key [3]
October 2005
25
DRAFT dISA-99.00.01

3.1.109 key management

process of handling and controlling cryptographic keys and related material (such as initialization values)
during their life cycle in a cryptographic system, including ordering, generating, distributing, storing,
loading, escrowing, archiving, auditing, and destroying the keys and related material [3]
3.1.110 key pair
A public key and its corresponding private key used with a public key algorithm. [3]
3.1.111 key recovery
techniques that provide an intentional, alternate (i.e., secondary) means to access the key used for data
confidentiality service in an encrypted association [3]
3.1.112 key transport
key establishment method by which a secret key is generated by one entity in a communication
association and securely sent to another entity in the association [3]
3.1.113 keyed hash
cryptographic hash in which the mapping to a hash result is varied by a second input parameter that is a
cryptographic key [3]
3.1.114 local area network (LAN)
- a communications network designed to connect computers and other intelligent devices in a limited
geographic area (typically under 10 km). [2]
3.1.115 latency
The time interval between when a message is sent by one device and received by a second device.
3.1.116 least privilege
principle that a security architecture should be designed so that each system entity is granted the
minimum system resources and authorizations that the entity needs to do its work
3.1.117 manufacturing and control systems
includes all systems (personnel, hardware, and software) that can affect or influence the safe, secure and
reliable operation of an industrial process. They include, but are not limited to:
process control systems, including Distributed Control Systems (DCS), Programmable Logic
Controllers (PLC), Remote Terminal Units (RTU), Intelligent Electronic Devices (IED), Supervisory
Control and Data Acquisition (SCADA), networked electronic sensing and control, and monitoring and
diagnostic systems (In this context, process control systems include Basic Process Control System
(BPCS) and Safety Instrumented System (SIS) functions, whether they are physically separate or
integrated.)
associated information systems such as advanced or multi-variable control, online optimizers,

dedicated equipment monitors, graphical interfaces, process historians, manufacturing execution
systems and plant information management systems
26
October 2005

DRAFT dISA-99.00.01
associated internal, human, network, or machine interfaces used to provide control, safety, and
manufacturing operations functionality to continuous, batch, discrete, and other processes.
3.1.118 malicious logic

hardware, software, or firmware that is intentionally included or inserted in a system for a harmful purpose
[3]
3.1.119 malware
a contraction of "malicious software". (See: malicious logic)
3.1.120 man-in-the-middle
form of active attack in which the attacker intercepts and selectively modifies communicated data in order
to masquerade as one or more of the entities involved in a communication association [3]
3.1.121 manufacturing operations
Manufacturing operations encompass the collection of production, maintenance, and quality assurance
operations with other activities of a production facility. Operations include:
manufacturing or processing facility activities that coordinate the personnel, equipment, and
material involved in the conversion of raw materials and/or parts into products
functions that may be performed by physical equipment, human effort, and information systems
managing information about the schedules, use, capability, definition, history, and status of all
resources (personnel, equipment, and material) within the manufacturing facility
3.1.122 network-based intrusion detection system (NIDS)

application that reads all packets, not just those sent to it, from a network and detects potentially
malicious packets based on rules or algorithms (See: intrusion detection)
3.1.123 masquerade attack
type of attack in which one system entity illegitimately assumes the identity of another entity [3]
3.1.124 network layer protocol
protocols for routing of messages through a complex network. Layer 3 of the OSI reference model. [2]
3.1.125 non-repudiation
a security service that provides protection against false denial of involvement in a communication. [3]
3.1.126 one-way function
mathematical function, f, which is easy to compute but for which, for a general value y in the range, it is
computationally difficult to find a value x in the domain such that f(x) = y [3]
October 2005
27
DRAFT dISA-99.00.01

3.1.127 out of band

transfer of information using a channel that is outside (i.e., separate from) the channel that is normally
used [3]
NOTE:
Out-of-band mechanisms are often used to distribute shared secrets (e.g., a symmetric key) or other sensitive information
items (e.g., a root key) that are needed to initialize or otherwise enable the operation of cryptography or other security
mechanisms.
3.1.128 password
a secret data value, usually a character string, that is used as authentication information. [3]
3.1.129 penetration
successful, repeatable, unauthorized access to a protected system resource [3]
3.1.130 personal identification number (PIN)
An alphanumeric code or password used to authenticate an identity. [4]
3.1.131 physical layer protocol
protocols for transmitting raw electrical signals over the communications channel. Deals with
transmission physics such as cabling, modulation, and transmission rates. Layer 1 of the OSI reference
model. [2]
3.1.132 plaintext
data that are input to and transformed by an encryption process, or that are output by a decryption
process. [3]
3.1.133 point-to-point protocol (PPP)
The protocol defined in RFC 1661, the Internet standard for transmitting network layer datagrams (e.g. IP
packets) over serial point-to-point links.
3.1.134 private key
secret component of a pair of cryptographic keys used for asymmetric cryptography [3]
3.1.135 privilege
an authorization or set of authorizations to perform security relevant functions, especially in the context of
a computer operating system [3]
3.1.136 production traffic
communications exchanged between the CN and external users in order to facilitate the intended
operation of the systems, e.g. physical plant status, production orders, control programs, etc, including
configuration, test, and maintenance of control related devices, but not security related devices
NOTE:
28
The intent is to include all communications associated with normal plant operation, but to exclude all communications
related solely to IT and security infrastructure management, e.g. firewall configuration, log messages, authentication
exchanges, etc. Production traffic is the reason why there is an interconnection between the CN and other networks.
October 2005

DRAFT dISA-99.00.01
3.1.137 protection profile

an implementation-independent set of security requirements for a category of Targets of Evaluation
(TOEs) that meet specific consumer needs. [4,6]
3.1.138 protocol
set of rules (i.e., formats and procedures) to implement and control some type of association (e.g.,
communication) between systems [3]
3.1.139 proxy server
computer process often used as, or as part of, a firewall that relays a protocol between client and
server computer systems, by appearing to the client to be the server and appearing to the server to be
the client [3]
3.1.140 proxy gateway
gateway that terminates an incoming connection and opens a new connection to the destination on the
same or a different network interface to pass on the traffic
NOTE:
Because a new connection is made from the proxy to the destination, the destination is protected against any layer 3 and
layer 4 malformed packets from external sources. Mostly, proxies copy data between their interfaces without further
inspection, which does not prevent application level attacks or protocol tunneling. Some proxy firewalls actually evaluate
the traffic for some protocols. This may be, in contrast to stateful inspection, not only done by pattern matching on the
payload, but by actually processing the content.
3.1.141 pseudo-random
sequence of values that appears to be random (i.e., unpredictable) but is actually generated by a
deterministic algorithm [3]
3.1.142 pseudorandom number generator (PRNG)
An algorithm that produces a sequence of bits that are uniquely determined from an initial value called a
seed. The output of the PRNG appears to be random, i.e., the output is statistically indistinguishable
from random values. A cryptographic PRNG has the additional property that the output is unpredictable,
given that the seed is not known. [3]
3.1.143 public key
publicly-disclosable component of a pair of cryptographic keys used for asymmetric cryptography
3.1.144 public key certificate
a set of data that uniquely identifies an entity, contains the entitys public key, and is digitally signed by a
trusted party, thereby binding the public key to the entity. [4]
3.1.145 public key (asymmetric) cryptographic algorithm
A cryptographic algorithm that uses two related keys, a public key and a private key. The two keys have
the property that deriving the private key from the public key is computationally infeasible. [4]
3.1.146 public key infrastructure (PKI)
a framework that is established to issue, maintain, and revoke public key certificates. [3]
October 2005
29
DRAFT dISA-99.00.01

3.1.147 random
(security usage) unpredictable and "unguessable" [3]
3.1.148 redundancy
existence of means, in addition to the means which would be sufficient for a functional unit to perform a
required function or for data to represent information
NOTE 1: Redundancy is used primarily to improve reliability or availability.
3.1.149 reflection attack

type of replay attack in which transmitted data is sent back to its originator [3]
3.1.150 rekey
change the value of a cryptographic key that is being used in an application of a cryptographic system [3]
3.1.151 reliability
ability of a system to perform a required function under stated conditions for a specified period of time [3]
3.1.152 remote access workplace
host on which actual applications execute (e.g., a Control Network user interface), which is mirrored via a
remote access protocol to a remote access client
NOTE:
This can also be used by staff in the plant to monitor locally the activities conducted from the remote client, or vice versa.
There could be multiple remote access workplaces in a Control Network.
3.1.153 remote client (RC)

host outside the control network that is temporarily or permanently connected to the control network via a
communication link in order to directly or indirectly interactively access parts of the control equipment on
the Control Network
3.1.154 replay attack
attack in which a valid data transmission is maliciously or fraudulently repeated, either by the originator or
by an adversary who intercepts the data and retransmits it, possibly as part of a masquerade attack [3]
3.1.155 repudiation
denial by one of the entities involved in a communication of having participated in all or part of the
communication [5]
3.1.156 residual risk
the remaining risk after the security controls have been applied. [1]
3.1.157 risk
An expectation of loss expressed as the probability that a particular threat will exploit a particular
vulnerability with a particular harmful result. [3]
30
October 2005

DRAFT dISA-99.00.01
3.1.158 risk analysis, risk assessment

process that systematically identifies valuable system resources and threats to those resources,
quantifies loss exposures (i.e., loss potential) based on estimated frequencies and costs of occurrence,
and (optionally) recommends how to allocate resources to countermeasures so as to minimize total
exposure
3.1.159 risk management
process of identifying and applying countermeasures commensurate with the value of the assets
protected based on a risk assessment. [1]
3.1.160 role-based access control (RBAC)
form of identity-based access control where the system entities that are identified and controlled are
functional positions in an organization or process [3]
3.1.161 router
a computer that is a gateway between two networks at OSI layer 3 and that relays and directs data
packets through that internetwork. The most common form of router operates on Internet Protocol (IP)
packets [3]
3.1.162 rule-based security policy
security policy based on global rules imposed for all users. These rules usually rely on comparison of the
sensitivity of the resource being accessed and the possession of corresponding attributes of users, a
group of users, or entities acting on behalf of users [5]
3.1.163 safety
property of a system being free from risk of causing harm to system entities and outside entities [3]
3.1.164 secret
condition of information being protected from being known by any system entities except those who are
intended to know it [3]
3.1.165 secret key
a cryptographic key, used with a secret key cryptographic algorithm that is uniquely associated with one
or more entities and should not be made public. [4]
3.1.166 secret key (symmetric) cryptographic algorithm
a cryptographic algorithm that uses a single secret key for both encryption and decryption. [4]
3.1.167 security
1) measures taken to protect a system
2) condition of a system that results from the establishment and maintenance of measures to protect the
system
October 2005
31
DRAFT dISA-99.00.01

3) condition of system resources being free from unauthorized access and from unauthorized or
accidental change, destruction, or loss [3]
3.1.168 security architecture
plan and set of principles that describe the security services that a system is required to provide to meet
the needs of its users,
a) the system elements required to implement the services, and
b) the performance levels required in the elements to deal with the threat environment [3]
3.1.169 security audit
an independent review and examination of a system's records and activities to determine the adequacy of
system controls, ensure compliance with established security policy and procedures, detect breaches in
security services, and recommend any changes that are indicated for countermeasures [5]
3.1.170 security audit trail
a chronological record of system activities that is sufficient to enable the reconstruction and examination
of the sequence of environments and activities surrounding or leading to an operation, procedure, or
event in a security-relevant transaction from inception to final results [3]
3.1.171 security components (also called security countermeasures)
techniques such as firewalls, authentication modules, or encryption software used to improve the security
performance of the manufacturing and control system.
3.1.172 security domain
an environment or context that is defined by a security policy, security model, or security architecture to
include a set of system resources and the set of system entities that have the right to access the
resources
3.1.173 security event
occurrence in a system that is relevant to the security of the system [3]
3.1.174 security function
function implemented by a security-related system, intended to achieve or maintain a secure state for the
system with respect to a specific category of threat
3.1.175 security gateway
gateway that separates trusted (or relatively more trusted) hosts on the internal network side from
untrusted (or less trusted) hosts on the external network side [3]
3.1.176 security incident
security event that involves a security violation [3]
32
October 2005

DRAFT dISA-99.00.01
3.1.177 security intrusion

security event, or a combination of multiple security events, that constitutes a security incident in which
an intruder gains, or attempts to gain, access to a system (or system resource) without having
authorization to do so [3]
3.1.178 security level (SRL)
hierarchical classification of security functions and processes that provide resistance to attack
3.1.179 security management infrastructure
system elements and activities that support security policy by monitoring and controlling security services
and mechanisms, distributing security information, and reporting security events [5]
3.1.180 security management network (SMN)
network that is dedicated to administrating a set of security device, where each of those devices is
connected to the SMN via a dedicated network interface, such that no production traffic flows through the
SMN so that the SMN realizes out-of-band management of the connected security mechanisms
3.1.181 security measure
measure against possible security attacks on a communication system
3.1.182 security perimeter
boundary of the domain in which a security policy or security architecture applies; i.e., the boundary of the
space in which security services protect system resources [3]
3.1.183 security performance
security performance may be evaluated in terms of a programs compliance, completeness of measures
to provide specific threat protection, post compromise analysis, review of changing business
requirements, new threat and vulnerability information, and periodic audit of control systems to ensure
that security measures remain effective and appropriate. Tests, audits, tools, measures, or other methods
are required to evaluate security practice performance.
3.1.184 security policy
a set of rules and practices that specify or regulate how a system or organization provides security
services to protect sensitive and critical system resources [3]
3.1.185 security practices
provide a means of capturing experiences and activities that help ensure system protection and reduce
potential systems compromise. Subject areas include physical security, procedures, organization,
design, and programming. Security practices include the actual steps to be taken to ensure system
protection.
October 2005
33
DRAFT dISA-99.00.01

3.1.186 security procedures

define exactly how practices are implemented and executed. They are implemented through personnel
training and actions using currently available and installed technology (such as disconnecting modems).
Procedures and contained criteria also include more technology-dependent system requirements that
need careful analysis, design, planning, and coordinated installation and implementation.
3.1.187 security program
brings together all aspects of managing security, ranging from the definition and communication of
policies through implementation of best industry practices and ongoing operation and auditing.
3.1.188 security services
mechanisms used to provide confidentiality, data integrity, authentication or non-repudiation of
information. [3]
3.1.189 security violation
act or event that disobeys or otherwise breaches security policy
3.1.190 separation of duties
practice of dividing the steps in a system function among different individuals, so as to keep a single
individual from subverting the process. (See: dual control)
3.1.191 server
a device or application that provides information or services to client applications and devices. [3]
3.1.192 sniffing
See Interception
3.1.193 split knowledge
security technique in which two or more entities separately hold data items that individually convey no
knowledge of the information that results from combining the items (See: dual control)
3.1.194 spoof
pretending to be an authorized user and performing an unauthorized action. [3]
3.1.195 static filtering firewall
firewall that bases its forwarding decisions between its two or more network interfaces on rules that
inspect ISO/OSI layer 3 and layer 4 information without keeping state information
Note: This type of filtering is often available in low-end routers and modems.
34
October 2005

DRAFT dISA-99.00.01
3.1.196 stateful filtering firewall

firewall that bases its forwarding decisions between its two or more network interfaces on rules that
inspect ISO/OSI layer 3 and layer 4 information and associated session / conversation state information,
permitting determination of whether certain incoming data are unsolicited or in response to a previous
outgoing request
Note: This type of functionality is typically available with mid-range routers as well as dedicated firewalls.
3.1.197 stateful inspection firewall
enhanced stateful filtering firewall that bases its forwarding decisions between its two or more network
interfaces on rules that inspect ISO/OSI layer 3, layer 4 and application layer information to determine
whether the data stream corresponds to expectations for the application
NOTE:
Stateful inspection firewalls can be used to securely filter protocols with complex port behavior (e.g. FTP) or to determine
whether a port is used to tunnel data belonging to an unexpected application. Such firewalls are limited to a small productspecific set of application protocols. For other protocols these firewalls typically rely on stateful filtering.
3.1.198 supervisory control and data acquisition (SCADA) system

type of loosely-coupled distributed monitoring and control system commonly associated with electric
power transmission and distribution systems, oil and gas pipelines, and water and sewage systems
3.1.199 survivability
ability of a system to remain in operation or existence despite adverse conditions, including both natural
occurrences, accidental actions, and attacks on the system
3.1.200 symmetric cryptography
branch of cryptography involving algorithms that use the same key for two complementary steps of the
algorithm [5]
3.1.201 symmetric Key
a single cryptographic key that is used with a secret (symmetric) key algorithm. [3]
3.1.202 symmetric key algorithm
See Secret Key Cryptographic Algorithm. [3]
3.1.203 system owner / operator
business enterprise responsible for operating a DCS or SCADA system
3.1.204 system security officer
person responsible for enforcement or administration of the security policy that applies to the system
3.1.205 system software
The special software within the cryptographic boundary (e.g., operating system, compilers or utility
programs) designed for a specific computer system or family of computer systems to facilitate the
operation and maintenance of the computer system, and associated programs, and data. [4]
October 2005
35
DRAFT dISA-99.00.01

3.1.206 third party protection

protection of non-involved parties from damage consequential to an attack and any resulting response
3.1.207 threat
the potential for violation of security, which exists when there is a circumstance, capability, action, or
event that could breach security and cause harm [3]
3.1.208 threat action
an assault on system security [3]
3.1.209 threat analysis
the analysis of the probability of occurrences and consequences of damaging actions to a system [3]
3.1.210 threat consequence
a security violation that results from a threat action [3]
3.1.211 throughput
the maximum continuous traffic rate that a device can handle without dropping a single packet. [2]
3.1.212 traffic analysis
inference of information from observable characteristics of data flow(s), even when the data is encrypted
or otherwise not directly available, including the identities and locations of source(s) and destination(s),
and the presence, amount, frequency, and duration of occurrence
3.1.213 Trojan Horse
a computer program that appears to have a useful function, but also has a hidden and potentially
malicious function that evades security mechanisms, sometimes by exploiting legitimate authorizations of
a system entity that invokes the program [3]
3.1.214 user
person, organization entity, or automated process that accesses a system, whether authorized to do so or
not [3]
3.1.215 virtual private network (VPN)
a restricted-use, logical (i.e., artificial or simulated) computer network that is constructed from the system
resources of a relatively public, physical (i.e., real) network (such as the Internet), often by using
encryption (located at hosts or gateways), and often by tunneling links of the virtual network across the
real network
3.1.216 vulnerability
a flaw or weakness in a system's design, implementation, or operation and management that could be
exploited to violate the system's integrity or security policy. [3]
36
October 2005

DRAFT dISA-99.00.01
3.1.217 wide area network (WAN)

- a communications network designed to connect computers over a large distance, such as across the
country or world. [4]
3.1.218 wiretapping
attack that intercepts and accesses data and other information contained in a flow in a communication
system [3]
NOTE 1: Although the term originally referred to making a mechanical connection to an electrical conductor that links two nodes, it
is now used to refer to reading information from any sort of medium used for a link or even directly from a node, such as
gateway or subnetwork switch.
NOTE 2: "Active wiretapping" attempts to alter the data or otherwise affect the flow; "passive wiretapping" only attempts to observe
the flow and gain knowledge of information it contains.
3.1.219 worm
a computer program that can run independently, can propagate a complete working version of itself onto
other hosts on a network, and may consume computer resources destructively [3]
3.1.220 zone
set of network segments, network devices, and hosts for which the same security policies and
requirements are valid
NOTE:
A zone has a clear border with other zones. The security policy of a zone is typically enforced by a combination of
mechanisms both at the zone edge and within the zone. Zones can be hierarchical.
October 2005
37
DRAFT dISA-99.00.01
3.2

Abbreviations
This section defines the abbreviations used in this document.

ACC
Access Control Center [RFC 2828]
ACL
Access Control List [RFC 2828]
AES
Advanced Encryption Standard
AIS
Automated Information System
ANSI
American National Standards Institute
ATM
Asynchronous Transfer Mode
CC
Common Criteria [ISO/IEC 15408]
CERT
Computer Emergency Response Team
CGI
Common Gateway Interface
CIP
Common Industrial Protocol (formerly Control and Information Protocol)
CMVP
Cryptographic Module Validation Program
COM
Component Object Model
COTS
Commercial Off The Shelf
CPU
Central Processing Unit
CRC
Cyclic Redundancy Check [RFC 2828]
CVE
Common Vulnerabilities and Exposure
DAC
Discretionary Access Control
DCOM
Distributed Component Object Model
DCS
Distributed Control System
DDoS
Distributed Denial-of-Service
DEK
Data Encryption Key [RFC 2828]
DES
Digital Encryption Standard
DLL
Data Link Layer [ISO/IEC 7498-1]
DMZ
Demilitarized Zone
DoS
Denial-of-Service
EMI
Electro-Magnetic Interference
ERP
Enterprise Resource Planning
FAL
Fieldbus Application Layer [IEC 61158-5]
FCS
Frame Check Sequence [ISO/IEC 8802-1]
FIPS
Federal Information Processing Standards
FTP
File Transfer Protocol
GPS
Global Positioning System
GUI
Graphical User Interface
HIDS
Host Intrusion Detection System
38
October 2005

HMI
Human Machine Interface
HTTP
Hyper Text Transfer Protocol
HTTPS
Hyper Text Transfer Protocol Secure
ICMP
Internet Control Message Protocol
IDS
Intrusion Detection System
IED
Intelligent Electronic Devices
IEEE
Institute of Electrical and Electronics Engineers
IETF
Internet Engineering Task Force
IP
Internet Protocol
IPsec
Internet Protocol Security
ISA
The Instrumentation, Systems, and Automation Society
IT
Information Technology
KEK
Key Encryption Key [RFC 2828]
LAN
Local Area Network
MAC
Media Access Control
MES
Manufacturing Execution System
NAT
Network Address Translation
NFAT
Network Forensics and Analysis Tool
NIC
Network Interface Card
NIDS
Network Intrusion Detection System
NIST
U.S. National Institute of Standards and Technology
NSA
National Security Administration
OEM
Original Equipment Manufacturer
OLE
Object Linking and Embedding
OPC
OLE for Process Control
OS
Operating System
OSI/RM
Open Systems Interconnect Reference Model
PAP
Password Authentication Protocol
PCN
Process Control Network
PDU
Protocol Data Unit [ISO/IEC 7498-1]
PGP
Pretty Good Privacy
PIMS
Process Information Management System
PIN
Personal Identification Number
PKI
Public Key Infrastructure
PLC
Programmable Logic Controller
PPP
Point-to-Point Protocol
October 2005
DRAFT dISA-99.00.01
39
DRAFT dISA-99.00.01

PRNG
Pseudorandom Number Generator
RBAC
Role-Based Access Control
RBAC
Role-Based Access Control [RFC 2828]
RFC
Request For Comment
ROM
Read-Only Memory
RRAS
Routing and Remote Access Service
RSA
Rivest, Shamir and Adleman
RTOS
Real-time Operating System
RTU
Remote Terminal Unit
SAM
Security Accounts Manager
SCADA
Supervisory Control and Data Acquisition
SDU
Service Data Unit [ISO/IEC 7498-1]
SMTP
Simple Mail Transfer Protocol
SSH
Secure Shell
SSL
Secure Sockets Layer
SSO
Single Sign On
TCP
Transmission Control Protocol
TLS
Transport Layer Security
ToE
Targets of Evaluation
UDP
User Datagram Protocol
USB
Universal Serial Bus
VDS
Virus Detection System
VLAN
Virtual Local Area Network
VPN
Virtual Private Network
WAN
Wide Area Network
WLAN
Wireless Local Area Network
40
October 2005

DRAFT dISA-99.00.01
4 Manufacturing and Control Systems Security Overview

The purpose of this section is to provide a brief overview of the current situation with respect to the
security of Manufacturing and Control Systems, in order to establish the need for standards and guidance
in this area.
The audience for this document includes all users of Manufacturing and Control Systems (including
facility operations, maintenance, engineering and corporate components of user organizations),
manufacturers, suppliers, and security practitioners. This document is also a reference for those
responsible for the integration of plant control systems and company or corporate networks. Mutual
understanding and cooperation between Information Technology (IT) and Manufacturing organizations is
important for the overall success of any Security initiative.
Specifically, this section addresses the following questions:
What is the current situation with respect to the security of these systems, and where are the
major opportunities or imperatives?
What are the significant drivers and developments that have led to the need for increased
attention to the security of industrial automation systems?
These and other related questions are addressed in the following sections.
4.1
Current Environment
Partners in one business venture may also be competitors in another business. However, because
Manufacturing and Control Systems equipment is directly connected to a process, loss of trade secrets or
interruption in the flow of information are not the only consequences of a security breach. Far more
serious can be the potential loss of production, environmental damage, regulatory violation, or
compromise to the safety of an operation. The latter may have ramifications beyond the targeted
company; they may grievously damage the infrastructure of the host region or nation.
External threats are not the only concern; knowledgeable insiders with malicious intent or even an
innocent unintended act can pose a serious security risk. Additionally, modifying or testing of operational
systems have led to unintended cyber impacts on Manufacturing and Control System operations. The
number and consequence of these impacts have been exacerbated by the growing dependence on nonmanufacturing and Control System personnel performing security testing on these systems. Combining
all these factors, it is easy to see that the probability of someone gaining unauthorized or damaging
access to a manufacturing process has increased.
While these technology changes and partner relationships may be good for business, they increase the
potential risk for compromising security. As the threats to businesses increase, so does the need for
security.
October 2005

41
DRAFT dISA-99.00.01
4.2

Current Systems
Process automation systems that support the process and manufacturing enterprise have evolved from
individual, isolated computers with proprietary operating systems and networks to interconnected
systems and applications employing widely used and well understood open systems technology (i.e.,
operating systems and protocols). These automation systems are now being integrated with enterprise
systems and other business applications through site and corporate communication networks. This
integrated architecture provides significant business benefits including the following:
a) Increased visibility of shop floor activities (work in process, equipment status, production schedules),
enabling improved business analysis and decision making.
b) Integrated manufacturing systems that have more direct access to and from enterprise information,
enabling a more responsive manufacturing enterprise.
c) Common interfaces that reduce overall support costs and permit remote support of production
processes.
d) Improved data accessibility that provides the ability to conduct analyses to drive out production costs
and improve productivity.
e) Remote monitoring of the process control systems that allows problems to be solved more quickly
and reduces support costs.
ANSI/ISA standards, such as the ANSI/ISA-50 (Fieldbus) series, ANSI/ISA-84 (Application of Safety
Instrumented Systems for the Process Industries) series, ANSI/ISA-88 (Batch Control) series, ANSI/ISA91.00.01-2001 (Identification of Emergency Shutdown Systems and Controls that Are Critical Maintaining
Safety in Process Industries), and ANSI/ISA-95 (Enterprise-Control System Integration) series, have
added considerable value to the Manufacturing and Control Systems community by establishing models,
terms, and information exchanges that provide the ability to share information in an open and
standardized way (visit http://www.isa.org/standards/ for additional information on these standards).
However, this ability to exchange information increases vulnerability to misuse and attack by individuals
with malicious intent and introduces potential risks to the enterprise that uses Manufacturing and Control
Systems.
Manufacturing and Control Systems configurations can be very complex, in terms of physical hardware,
programming and communications. This complexity can often result in it being difficult to determine:
who is authorized to have access to electronic information,
when they are to have access to the information,
what data or functions they should be able to access,
where the access request is coming from, and
how the access request is being made.
42

October 2005

4.3
DRAFT dISA-99.00.01
Current Trends
There are several trends that are contributing to the increased emphasis on security of industrial control
systems.
In recent years there has been a marked increase in malicious software attacks on business and
personal computer systems. Businesses have reported an increase in the number of unauthorized
attempts (either intentional or unintentional) to access electronic information.
Worldwide, an increasing percentage of the population has become computer literate, and attacking
computer and communications systems has become a hobby with high-profile news coverage. In
fact, tools to automate attacks are now publicly available on the Internet. The external threat goes
beyond the hobbyist and includes cyber criminals and cyber terrorists who may have more resources
and knowledge to attack a Manufacturing and Control System.
The number of joint ventures, alliance partners, and outsourced services in the industrial sector has
increased dramatically, leading to a more complex situation with respect to the number of
organizations and groups contributing to security.
Manufacturing and Control Systems have evolved from isolated networks based on proprietary
technologies to standards-based networks connected to the rest of the enterprise and to other
enterprises.
All of these factors have combined to significantly increase the risks to businesses associated with the
design and operation of their Manufacturing and Control Systems. At the same time, electronic security
has become a more significant and widely acknowledged concern.
People with knowledge of features provided by open operating systems and networks could potentially
intrude into console devices, remote devices, databases and, in some cases, control platforms. The
impact of intruders on Manufacturing and Control Systems may include:
a) Unauthorized access, theft, or misuse of confidential information
b) Loss of integrity or reliability of process data and production information
c) Loss of system availability
d) Process upsets leading to inferior product quality, lost production capacity, compromised process
safety, or environmental releases
e) Equipment damage
f)
Personal injury
g) Violation of legal and regulatory requirements

h) Public health and confidence
i)
Impact on a nations security.
The focus on unauthorized access has broadened from attackers or disgruntled employees to include
deliberate terrorist activities aimed at harming large groups and facilities. This shift requires a more
structured set of guidelines and procedures to define electronic security applicable to Manufacturing and
Control Systems, as well as the respective connectivity to other systems.
October 2005

43
DRAFT dISA-99.00.01
4.4

Elements of Security
Information security typically includes three properties (confidentiality, integrity, and availability) that are
often abbreviated by the acronym "CIA." In a typical information technology security strategy the primary
focus is on confidentiality and the necessary access controls needed to achieve. Integrity falls to the
second priority and availability is the lowest.
In the Manufacturing and Control Systems environment, there is generally an inversion of these
properties. Security in Manufacturing and Control Systems is primarily concerned with maintaining the
availability of all system components. There are inherent risks associated with industrial machinery that is
controlled, monitored, or otherwise affected by Manufacturing and Control Systems. Therefore integrity is
second in importance. Bringing up the end is confidentiality. Often the data is raw in form and must be
analyzed within context to have any value.
The facet of time responsiveness cannot be lost. Control systems often have requirements of system
responsiveness in the 1 ms range whereas traditional business systems are able to successfully operate
with single or multiple second response times.
The following diagram depicts the difference.
Manufacturing & Control Systems
Traditional Information Technology
Availability
Confidentiality
Integrity
Integrity
Confidentiality
Availability
Priority
Figure 2 - Comparison of Objectives

It is also important to note that certain operational requirements will result in individual components or the
systems as a whole having different priorities for these properties (i.e. integrity or availability concerns
may outweigh confidentiality, or vice versa). This may in turn lead to the deployment of different
countermeasures to achieve these security properties.
Increasingly the data that are generated from the Manufacturing and Control systems is being fed to the
Business systems. In turn, information from business systems is being used to directly influence
manufacturing operations. This tighter coupling of business and manufacturing systems has increased
the requirements for secure systems.
44

October 2005
DRAFT dISA-99.00.01
5 Manufacturing and Control Systems Concepts

This section introduces some of the underyling concepts that form the foundation of Manufacturing and
Control Systems security. Many of these concepts are well established within the security discipline, but
their applicability to industrial systems may not have been clearly described. In some cases the nature of
industrial systems leads to an interpretation that may be slightly different than that used for more general
information technology applications.
5.1
Security Context
A thorough understanding of security requires familiarity with concepts such threats, risks and
countermeasures, as well as the relationships between them. This is best accomplished through the use
of a simple context model that describes these terms and relationships.
Such a model is provided in the international standard ISO/IEC 15408 (Common Criteria), Part 14. It is
reproduced in the following figure.
value
Owners
wish to minimize
impose
to reduce
Countermeasures
that may
possess
that may be
reduced by
Vulnerabilities
may be aware of
Threat Agents
that
exploit
give rise to
leading
to
Risk
that increase
Threats
to
to
Assets
wish to abuse and/or may damage
Figure 3 Context Model
This model begins with the idea that Assets are subjext to Threats, which in turn come from Threat
Agents. These threats increase the level of Risk to the assets by exploting Vulnerabilities. Each asset has
an Owner who will minimize risk by applying Countermeasures.
ISO/IEC 15408 (provide detailed reference)
October 2005
45
DRAFT dISA-99.00.01

Several of these elements are described in more detail in subsequent sections of this document.
5.1.1
Assets
In order to fully understand risk to the manufacturing environment, it is first necessary to catalog all
assets within an organization that require protection. Assets may be defined in terms of Manufacturing
and Controls Security as any tangible or intangible object that is owned by an organization, and has
either a perceived or actual value to an organization.
5.1.1.1
Types of Assets
Assets may be assigned any of the following three categories:

Non-physical Non-physical assets are those that are of an informational nature. These can include
intellectual property, algorithms, proprietary practices, process specific knowledge, or other informational
elements that encapsulate an organizations ability to operate or innovate. Further, this can include such
items as public reputation, buyer confidence, or other measures that if impacted, have direct impact upon
the business. Automation logic stored electronically is not considered a non-physical asset but is
considered a process asset due to its special nature as explained in the section Process Assets.
Non-physical assets may be in the form of personal memory, documents, information contained on
physical media, or electronic storage records dealing with the informational asset. Non-physical assets
also can include test results, regulatory compliance data, or any other informational that could be
considered sensitive, proprietary, or could potentially either provide or yield a competitive advantage.
Loss of non-physical assets often has very long lasting and damaging effects to an organization.
Physical Assets Physical assets include any tangible, physical component or group of components
belonging to an organization. In the Manufacturing and Controls environment, these may include control
systems, physical network components and transmission media, conveyance systems, walls, rooms,
buildings, or any other physical objects that are in any way involved with the control, monitoring, or
analysis of manufacturing processes, or in support of the general business.
Process Assets Process assets are those non-physical assets that contain the automation logic to be
employed in executing the manufacturing process. Manufacturing processes are highly dependent upon
the repetitive or continuous execution of precisely defined events. Compromise of process assets could
come through either physical (e.g. destruction of media) or non-physical (e.g. unauthorized modification)
means, and result in some sort of loss of integrity or availability to the process itself.
5.1.1.2
Valuation of Assets
In order to meet the qualification of either non-physical or physical asset, the object must be either owned
by or under the custodial duties of the organization. It also must have a definite and measurable value to
the organization. Value may be categorized by:
Direct Loss Direct loss represents the cost of replacing the asset directly. For a physical asset, this
could include the replacement cost for the device itself. Non-physical assets have little to no direct loss,
as the medium used to store the device is typically low-cost.
Indirect Loss Indirect loss represents any loss that may be realized to the organization as a result of
the loss of the asset. This could include losses due to process downtime, rework, or other production
costs due to loss of the asset. Indirect losses for physical assets typically include downstream effects
due to loss of the component. Indirect losses for non-physical assets often are great, due to such losses
as loss of public confidence, regulatory violation, loss of competitive advantage from release of
intellectual property, etc.
46
October 2005
DRAFT dISA-99.00.01
5.1.1.3
Means of Asset Valuation
For any type of loss, either quantitative or qualitative analysis may be appropriate. Some organization
will also consider qualitative valuation to be sufficient reasoning for expressing asset loss in the risk
analysis process:
Quantitative Valuation of Assets Quantitative valuation of assets is accomplished by associating
precise monetary loss for a given asset. This could come in terms of cost of replacement, cost of lost
sales, or other monetary measures. Quantitative analysis requires a rigorous cost analysis to obtain a
precise number, but does afford an organization a much clearer picture of potential impact from loss.
Qualitative Valuation of Assets Many assets may only be analyzed in terms of qualitative loss.
Qualitative loss typically expresses a more abstract level of loss such as a percentage, low impact, high
impact, no impact, etc. Initiating a risk assessment process may begin with a qualitative valuation of
assets for documenting high level risks and for justifying the business case for spending money on
remediation to reduce a risk, and later be supported by a quantitative analysis for a detailed picture of
risk exposure.
5.1.1.4
Categorization of Loss
Assets that are lost in some manner can come from any of the following:
Asset Type
Direct Loss
Indirect Loss
Qualitative or
Quantitative?
Non-physical
Low direct loss, as the

storage mediums are often
cheap and easily replaceable
High indirect loss often due to

loss of intellectual property,
compromise of proprietary
procedures, violation of
regulatory compliance, etc.
Typically Qualitative
analysis is sufficient
Physical
Can be high direct loss,

represented by the
replacement cost for the
asset.
Downstream effects as a result

of loss, including loss of
control, loss or damage to
other assets, downtime losses,
etc
Qualitative or Quantitative,
may begin with qualitative
for high level risks, and
quantitative for greater
precision
Process
Direct loss comes from

damage to physical assets as
a result of loss of integrity or
availability, and the
interruption of precise
sequencing or consistent
nature of a process
Indirect losses come from

downtime, rework, reengineering, or other efforts to
restore control over the
manufacturing process.
Mostly qualitative, but

some downstream
impacts may be
quantitative.
Table 1 Types of Loss by Asset Type
October 2005
47
DRAFT dISA-99.00.01
5.1.2

Risk
There are a number of ways to look at risk. In general, the risk calculation is a function of Threat,
Vulnerability and Cost. These terms are described in the terms and Definitions section of this document.
The following methodology and risk factors5 are defined to provide a basis for understanding security
levels and risk tolerance, and a useful way to quantify the risk factor and test it against user defined case
studies.
Any sound vulnerability risk assessment methodology should analyze all involved systems holistically
in a layered approach, starting with what is closest to the threat, then working inward.
Vulnerabilities should be prioritized based on the criticality of the system(s), severity of the
vulnerability, and the likelihood that the vulnerability can be exploited.
Likelihood, based on out of 4 attempts, is used to determine how many times an attack would be
successful given the vulnerability and available known exploits.
Risk Factor = Criticality (value 1 through 5) x Vulnerability (severity 1 through 5) x Likelihood
(probability value 1 through 4)
Resulting risk factor ranges from 0 to 100. For example, Criticality=3, Vulnerability=5,
Likelihood=2, yields a risk factor of 30.
End users should rank and include the cost of mitigation or cost to repair in their estimate of
Vulnerability.
End users should decide on the appropriate corrective measures for mitigating the most security
exposures for the least financial exposure.
5.1.2.1
Risk tolerance level
Another approach is to describe the corporate policy in regards to managing manufacturing-related risk
called risk tolerance. This approach assigns a risk tolerance level for different types of risks:
personnel safety such as death or injury
process safety such as death, injury, equipment damage, business interruption
information security such as cost, legal violations, loss of brand image
environmental risk such as notice of violation, legal violations, major impact
business continuity such as business interruption
The value of this approach is that manufacturing cyber security does not, in general, introduce new risks
is viewed as a different threat source that contributes to existing risks. Thus, manufacturing cyber security
does not need to reinvent the organization risk tolerance level; they are simply derived from other risk
management practitioners in the organization.
These risk factors were developed by Jonathan Pollett (PlantData) and presented at the UTC
TELECOM 2005 conference.
48
October 2005
DRAFT dISA-99.00.01
5.1.2.2
Responses to Risk
There are several potential responses to risk. Some combination would be used in each situation,
depending on the circumstances.
Avoid the risk Involves making the appropriate business decisions in which the risk is not taken. This
involves saying no to something, whether a new vendor product, system or relationship.
Mitigate or reduce the risk Through the implementation of security controls or by reducing the
consequence of an attack, risks can be reduced to an acceptable level. The key here is to achieve a level
of good enough security, not the elimination of risk.
Accept the risk There is always an option to accept the risk, to see it as the cost of doing business.
Some risks need to be taken and cannot be cost effectively mitigated or transferred.
Transfer or insure the risk Establishing some sort of insurance or agreement that transfers the risk to
a third entity. Insurance cannot always be effective, since it may not always cover you completely. Just
because a cyber-insurance policy may cover you from certain damages, it may never recover you from
the loss of customer confidence.
Design the risk out - One form of mitigation is to design the risk out or the system. Some risks exist
simply because access is available to something to which no access is ever needed. By completely
disabling the unnecessary function or welding the function from access, the risk can be mitigated.
5.1.3
Threats
Threat agents (also known as adversaries or attackers) come in a multitude of different forms and formats
such as:
Insider a trusted person, employee, contractor or supplier who has information that is not generally
known to the public.
Outsider A person or group not trusted with inside access. May or may not be known to the targeted
organization. May or may not have been an insider at one time.
Natural An act of God such as a storm, earthquake, flood, tornado or the like. Generally a physical
risk.
Accidental A risk is generated by someone unfamiliar with proper procedure and policy, or by honest
oversight. It is also likely that all the risks are not known and may be uncovered by accident as complex
manufacturing and control systems are operated.
Non-validated changes Updates, corrections and other changes to operating systems, application
programs, configurations, connectivity, and equipment can provide an unexpected security threat to the
manufacturing and control systems or the respective production.
5.1.4
Vulnerabilities
In simple terms, vulnerabilities are inherent weaknesses in systems, components, or organizations. A

formal definition is:
Weakness in and information system. System security procedures, internal controls or implementation
that could be exploited.
October 2005
49
DRAFT dISA-99.00.01

Source: CNSS Instruction No. 4009, National Information Assurance Glossary, May 2003,
Vulnerabilities may be the result of intentional design choices or may be accidental, resulting from the
failure to understand the operational environment. Vulnerabilities are not limited to the electronic or
network systems. An understanding of the interaction between physical and cyber vulnerabilities is critical
to establishing effective M&CS security.
A Manufacturing and Control System initially having limited vulnerability may become more vulnerable
with changing environment, changing technology, system component failure, unavailability of component
replacements, personnel turnover, greater threat intelligence, among others.
A careful matching of vulnerabilities to threats will provide a hierarchy of opportunities to improve the
security of the Manufacturing and Control System.
5.1.5
Attacks
Threats that become action are known as attacks (sometimes referred to as an intrusion). Whether
designing components and systems or implementing a security program within a site or organization, it is
necessary to model attacks in order to ensure that countermeasures are in place to identify and deter
them.
Attack Trees (sometimes referred to as Attack Graphs) provided a structured means of representing
multiple hostile events that typically occur.
Passive Passive information gathering can provide a potential intruder with valuable information.
Passive information is usually gathered by casual verbal communications with employees and
contractors; however, passive information can be gathered with visual observations by persons inside or
outside the facilities. Passive information gathering could include data about shift changes, equipment
operation, supply logistics, patrol schedules, and other vulnerabilities. Passive information gathering may
be difficult to detect, especially when information is gathered in small increments from several sources.
Maintaining observation for unusually curious persons, photographers, and personnel often outside of
their areas of responsibility can help recognize passive information gathers, especially when combined
with accurate background check information.
Sniffing Sniffing is a method of connecting to a communications stream for the purpose of gathering
data and information about the system connected to the communications stream. Wiretapping is the most
widely known means of sniffing, gathering voice signals from telephone lines. Sniffing can be very
sophisticated and devices are publicly available to sniff data on various communication networks.
Although these devices are commonly utilized for troubleshooting networks and analyzing data traffic,
they can also be utilized to gather specific data about any transaction occurring across the network.
Sniffers are nearly impossible to detect as they only read the information moving across the connected
media and do not provide signals into the signaling path. Hard connected sniffing can be detected with
modern communication control devices, such as intelligent data network switches, but wireless sniffing is
nearly impossible to detect even with very sophisticated and expensive radio telecommunications
equipment. Sniffing access can be reduced by controlling and closing unused voice and data ports in the
plant and by providing intelligence in communication control equipment.
50
October 2005
DRAFT dISA-99.00.01
Communication Communication attacks can occur in several forms. The intent of a communication
attack is to disrupt communications for M&CS. This may occur at several levels within the M&CS from the
computer processor level to attacks from outside the enterprise, as in the feared Denial-of-Service
attack on telephony and data systems. Undetected Trojans can cause computers or processors to
effectively slow by processing magnitudes of meaningless transactions, therefore not having sufficient
available processing power to perform M&CS operations. As M&CS systems move closer to off-the-shelf
solutions, virus protection and dictionaries will necessarily become part of each system. Firewalls,
physical disconnecting means, data tunnels, and other schemes may be necessary to provide acceptable
security levels.
Injection A form of attack on a database-driven Web site in which the attacker executes unauthorized
SQL commands by taking advantage of insecure code on a system connected to the Internet, bypassing
the firewall. SQL injection attacks are used to steal information from a database from which the data
would normally not be available and/or to gain access to an organizations host computers through the
computer that is hosting the database.
Replay Signals may be captured from control system communications paths and replayed later to
provide access to secured systems or to falsify data in the Manufacturing and Control System. Potential
intruders can replay access control signals, biometric signals, and other Manufacturing and Control
System signals to gain unauthorized access to secured areas or systems, hide illegitimate activities, or
provide false distractions. A properly designed Manufacturing and Control System will combine multiple
paths for data acquisition, signaling and control to prevent a single tap from gathering replay information
for an entire subsystem, equipment, application or database. Intrusion detection devices can alarm
potential tap locations and application subroutines can provide some validation of collected data.
Wireless communication in Manufacturing and Control System makes gathering of replay information
almost impossible to detect although transmitting replay into the system can be detected when combines
with other security control means, such as time stamping among others.
Spoofing and Impersonation To fool. In networking, the term is used to describe a variety of ways in
which hardware and software can be fooled. Forging an e-mail header to make it appear as if it came
from somewhere or someone other than the actual source. IP spoofing, for example, involves trickery
that makes a message appear as if it came from an authorized IP address.
Operator Error Operator errors, including mistakes and negligence can be perceived as an attack to
the Manufacturing and Control System or overall enterprise. More critical operator activities should
include procedures for validation of operator commands and instructions, before the signal is executed by
the system. Operator activities to correct alarm conditions may not require as much validation as other
routing critical control activities. Some validations of appropriate command entry ranges can be
configured into DCS and other control devices at the expense of adding complexity and cost to the
Manufacturing and Control System. Operator error can be reduced with training, peer validation,
supervisor validation, system alarming routines and other application programs within the Manufacturing
and Control System.
Social Engineering The act of obtaining or attempting to obtain otherwise secure data by conning an
individual into revealing secure information. Social engineering is successful because its victims innately
want to trust other people and are naturally helpful. The victims of social engineering are tricked into
releasing information that they do not realize will be used to attack a computer network. For example, an
employee in an enterprise may be tricked into revealing an employee identification number to someone
who is pretending to be someone he trusts or representing someone he trusts. While that employee
number may not seem valuable to the employee, which makes it easier for him to reveal the information
in the first place, the social engineer can use that employee number in conjunction with other information
that has been gathered to get closer to finding a way into the enterprises network.
October 2005
51
DRAFT dISA-99.00.01

Phishing A type of security attack that relies on social engineering in that it lures the victim into
revealing information based on the human tendency to believe in the security of a brand name because
they associate the brand name with trustworthiness.
Malicious Code Malicious code attacks can take the form of viruses, worms, automated exploit, or
Trojans. The purpose of the code may be to gather information about systems or users, destroy system
data, provide a foothold for further intrusion into the system, falsify system data and reports, or provide
time consuming irritation to system operations and maintenance personnel.
A Virus is a program or piece of code that is loaded onto your computer without your knowledge and
runs against your wishes. Viruses can also replicate themselves. All computer viruses are manmade.
A simple virus that can make a copy of itself over and over again is relatively easy to produce. Even
such a simple virus is dangerous because it will quickly use all available memory and bring the
system to a halt. An even more dangerous type of virus is one capable of transmitting itself across
networks and bypassing security systems.
A Worm is a program or algorithm that replicates itself over a computer network and usually performs
malicious actions, such as using up the computer's resources and possibly shutting the system down.
Automated Exploit code is placed into the system to gather information or notify someone or other
systems when specific events or transactions occur. Relatively simple exploit code can gather
information for future intrusions, financial exploitation, or statistical purposes (marketing). Automated
exploit code can utilize other resources or applications already within the system to enhance its
capabilities to gather information or destroy data. Fully automated exploit code is usually called a
worm.
A Trojan Horse is a destructive program that masquerades as a benign application. Unlike viruses,
Trojan Horses (also known as Trojans) do not replicate themselves but they can be just as
destructive. One of the most insidious types of Trojan horse is a program that claims to rid your
computer of viruses but instead introduces viruses onto your computer.6
Denial of Service Denial (or degradation) of Service attacks impact the availability of network,
operating system, or application resources. A popular form of network-based denial of serve is the
distributed denial of service (or DDoS) attack which leverages multiple compromised devices to impact
the maximum damage on a network, device, or application.
Physical Destruction
Information is required for this section, or it will be removed.
Escalation of Privileges
Invalid Data, Commands, or Messages

Reference Webopedia.com web page
52
October 2005
DRAFT dISA-99.00.01
5.2
Security Zones
Security can be described as the actions required to keep unwanted things out, allowing wanted things to
enter, preventing confidential things from leaking out and maintaining the integrity and availability of the
system being protected. These are the same for both physical security (not covered in this standard) and
cybersecurity. The level of security can be expressed in terms of an index of risk probability from 0 (no
risk of a breach event) to 1 (100% chance of a breach event). Risk analyses are run to mitigate security
risks that are either too unlikely to be of concern or too expensive to protect against. Every situation has
a different security index that it is deemed to be acceptable.
Building on this concept is the idea of a security Zone. A Zone implies that there are things that need to
be protected (inside the Zone) and those that do not (outside the area under protection). This applies to
the cyber environment in that there are systems that are included in the security Zone and all others that
are outside the Zone. There can also be Zones within Zones, or sub-Zones, that are used to provide a
layered security environment giving defense in depth and addressing multiple levels of security
requirements.
With a Zone comes a border. That is the boundary between those things that are included and those that
are excluded. Also implied is a need to access the assets within a Zone from both within and without.
This defines the communication and access (conduits) that are required to allow information and people
to move within and between the security Zones.
5.2.1
Zone Types
Zones can be defined in either a physical sense (a Physical Zone) or in a logical manner (Virtual Zone).
Physical Zones are security groupings that are made by grouping actual physical assets together into
security Zones. In this type of Zone it is easy to determine which Zone an asset belongs to.
Virtual Zones are grouping of assets, or parts of physical assets into security Zones. Here the
determination is based on the function being provided rather than the location of the actual asset that
provides the function.
5.2.2
Assess Requirements
When defining a security Zone, you must first assess the security requirements (security goals) and then
determine whether a particular asset should be considered within the Zone or outside the Zone. The
security requirements can be broken down into the following types:
Physical Access and Proximity Physical security Zones are used to limit access to a particular area
because all the systems in that area require the same level of trust of their human operators, maintainers
and developers. This does not preclude the possibility of having a higher level physical security Zone
embedded within a lower-level physical security Zone or a higher-level communication access Zone
within a lower-level physical security Zone. In the case of physical Zones, locks on doors or other
physical means protect against unauthorized access. The boundary is the wall or cabinet that restricts
access. The conduit is the door that allows access to occur if the authorizing agent (the lock) grants
access.
One example of a physical security Zone is a typical manufacturing plant. Authorized people are allowed
into the plant by an authorizing agent (security guard or ID) and unauthorized people are restricted from
entering by the same authorizing agent and fences.
October 2005
53
DRAFT dISA-99.00.01

Assets that are within the security border are those that must be protected to a given security level, or
policy. All devices that are with in the border must share the same level of security requirements. In
other terms, they must be protected to meet the same security policy. Protection mechanisms can differ
depending on the asset being protected.
Assets that are outside the security Zone are by definition at a lesser or different security level. They are
not protected to the same security level, and by definition can not be trusted to the same security level or
policy.
Communications Access In order for a group of assets within a security border to provide value, there
must be links to assets outside of the security Zone. This access can be in any form from physical
movement of assets (products) and people (employees and vendors) to electronic communication with
entities outside of the security Zone.
Remote communications is the transfer of information to and from entities that are not in close proximity
to each other. For purposes of this document, remote access is defined as communication with assets
that outside of the perimeter of the security Zone being addressed..
Local access is usually that communication that exists between assets within a single security Zone.
5.3
Conduits (Information Flows)
Information must flow into, out of and within a security Zone. Even in a non-networked system, some
communication exists (intermitted connection of programming devices to create and maintain the systems
as an example.)
A Conduit is a group of communications that can be logically organized into a sum of information flows
within and external to a Zone. It can be a single service (i.e. a single Ethernet network) or can be madeup of multiple data carriers (multiple network cables and direct physical accesses). Conduits are different
from Zones in that they can cross Zone boundaries.
5.3.1
Secure Conduits
Secure conduits have built in security protection that meets a specific security policy. It follows that
secured conduits would be contained within a security Zone. End to end security is at the same level as
the Zone that contains it. A secured conduit that crosses into a sub-Zone is unsecured for the sub Zone,
but secured within the parent Zone.
5.3.2
Insecure Conduits
Insecure conduits can be both within and extend outside the security Zone. All conduits that allow
communication from outside the security Zone are by definition unsecured.
5.3.3
Channels
Channels are the specific communication links that are established within a communication conduit.
Channels inherit the security properties of the conduit that is used as the communication media (i.e. a
channel within a secured conduit will maintain the security level of the secured conduit). Channels can
contain their own level of security to allow access of outside communication with a secured Zone.
Secured channels are the means used to connect different security Zones and sub Zones.
54
October 2005
DRAFT dISA-99.00.01
5.3.3.1
Secure Channels
Secure channels are communication links that are set up to allow trusted communication to exist with
other security Zones. A secure channel can be used to extend a virtual security Zone to include entities
that are outside the physical security Zone.
5.3.3.2
Insecure Channels
Insecure channels are those communication paths that are not at the same level of security as the
security Zone under study. The communications to and from the reference Zone (the Zone that defines
the communication as insecure) need to be validated prior to accepting the information as valid.
5.4
Security Levels
RFC 2828 defines security level as The combination of a hierarchical classification level and a set of
non-hierarchical category designations that represent how sensitive information is. Information sensitivity
may be defined as Low, Medium and High.
Security levels maybe viewed as an analogous approach to safety integrity levels (SIL). Five levels of
security, which are independent of the technique used to perform the risk assessment, are defined.
Level 0: No security information flows freely within and between all zones. Access and use of data
are not controlled. There is no assurance of integrity, confidentiality, restriction of data flow, and no
detection, reporting and response to violations.
Level 1: Role Based Access Control (RBAC), based on ANSI X9.69, for 2-way information exchange.
This level ensures that attributes of system files are set to standard release values. At this level, no
action is taken, and system services are not affected.
Level 2: RBAC for selected 1-way information exchange. This level provides adequate security
control for most environments. Some of the settings of system files and parameters are modified,
restricting system access to reduce the risks from security attacks. Security weaknesses and any
modifications made to restrict access are reported. At this level system services are not affected.
Level 3: Same as Level 2, but this level renders a highly secure system. System files and parameters
are adjusted to minimize access permissions. Most system applications and commands function
normally, but at this level, security considerations take precedence over other system behavior.
Level 4: No communication channels exist between any zones. Communication security and
information security within a zone is a local matter.
Level 0 and 4 are bounding conditions and are not addressed in this document. Levels 1, 2 and 3 are
used to quantify the security requirements in terms of security levels.
For the purpose of this discussion, the security requirements are quantified in terms of the strength of
integrity, confidentiality, authentication, authorization, etc. that relates the risk assessment (and security
policies) to the consequence. For example, communication performance requirements (response time) or
resource constraints (bandwidth) means one cannot, within these constraints practically enforce
confidentiality of information flowing over the conduit between the enterprise network and the control
network. But, if the risk assessment places the insider threat as the top priority, strengthening the
authentication and authorization for access to and use of devices or information is the first order of
business. Then, depending on the perceived consequences of the insider threat, security level 1 is
required to control access to some devices or process, level 2 for others and level 3 for those that are
mission critical. For this example, the conduit is the same for all three levels between the enterprise
network and the control network.
October 2005
55
DRAFT dISA-99.00.01
5.5

Policy
Security policies enable a company to follow a consistent program in order to maintain an acceptable
level of security. A company has policies at different levels in its organization, ranging from governance or
management policies that are established at the company or corporate level, to operation policies that
define the details of how security is administered. Policies at the most specific level are the company's
standard against which security audits can measure compliance.
Security policy is the set of rules and practices that specify or regulate how a system or organization
provides security services to protect sensitive and critical system resources. Policy unambiguously states
what is mandatory. Because policy is mandatory and unambiguous, it makes audits possible. It is the
measuring stick against which audits test the actual practices of the organization.
Complementing policy are procedures. Security procedures define in detail the sequence of steps to be
taken in order to provide a certain security measure. Because of their level of detail, procedures apply to
a specific issue. They may pertain to a specific technology. Policies reference procedures and mandate
their use.
Contrasting with policy and procedures are guidelines. Guidelines are not mandatory. They are intended
to describe a way to do something desirable but not mandatory. Because guidelines are not mandatory
and may be ambiguous, practices cannot be audited against guidelines. Guidelines are sometimes
written by a group that does not have the authority to require them to be followed. Guidelines are
inappropriate to describe practices that need to be mandatory.
Company standards specify required actions and conditions that must be met.
Since a company will have different policies and procedures for different parts of the company, they
should be adequately coordinated. The security policy for manufacturing and control systems needs to be
coordinated with corporate IT security. The security program will work more successfully if there are good
working relationships among the parties, and a well-coordinated set of policies can support good
relationships.
Some consistency to the structure of the various policies and procedures increases the coherence of the
set of policies and procedures. Each policy or procedure document has a short but precise statement of
its purpose. It also has a statement of scope that defines where the document applies. It has a
description of the risks that it is intended to reduce. The key principles of the document are described.
These common items guide the reader by providing more information on the intention of the policy or
procedure. They also describe the intent of the document to provide guidance that is useful when the
document needs to be revised.
The company's security policies take into account legal, regulatory, and contractual obligations.
The company's security policies and procedures contain instructions on how compliance is to be
measured and how the policies are to be updated. The recognition that the policy needs to be updated
often arises when audits are performed or evaluated. Audits may identify ambiguities in policies and
procedures as well as parts of policies and procedures that do not make clear what the required process
or outcome is. Audits can identify issues that should be added to policies and procedures. Audits may
also identify requirements that should be re-evaluated and possibly retracted.
Policies and procedures need to allow for unforeseen circumstances that can make it infeasible to follow
them. Policy should state how exceptions to policy and procedures should be documented and approved.
This approach of documenting approved exceptions leads to better clarity of the state of security than
leaving imprecision and ambiguity in the policies and procedures.
56
October 2005
DRAFT dISA-99.00.01
Policies need to be written unambiguously with respect to what is a requirement versus what is optional
advice. Precise use of words like "shall", "must", "may", and "is" removes the ambiguity. Policy
statements can define these words in their introduction sections to be more precise. "Shall" and "must"
are used for requirements. "May" is used for advice that can be taken optionally, and therefore is not
used in the mainstream of policies and procedures. It can be appropriate to provide options for
addressing a requirement. Phrases like "when possible" or "unless necessary" introduce ambiguity unless
they are combined with a statement of the method to use to determine whether the case is possible or
necessary.
Policies and procedures identify who is responsible for what. Is the process control staff responsible for
the control network? Is it responsible for a "demilitarized zone" between the control network and the
corporate LAN? If the corporate information systems department is responsible for conditions that require
the process control staff to perform certain operations, then these operations need to be described.
For a company that is only starting to create its security program, policies and procedures are a good
place to start. They can be written initially to cover the set of starting practices that the organization is
equipped to handle in the near term. Over time they can be revised and tightened as the organization's
capability grows. They can be put into place without the lead-time of procuring and installing systems and
devices.
5.5.1
Corporate Level Policy
The policy at the corporate level mandates the security program and sets the direction. It states the
organization's overall security objectives.
The policy statement of top management is circumspect enough that it remains pertinent and accurate
through changes in the structure of the company organization, changes in system and security
technology, and changes in the kinds of security threats. By being circumspect, the policy can be stable
and will need to be rewritten only when the company's basic position on security changes.
The policy statement is unambiguous. It clearly identifies what is required.
The company-level policy identifies areas of responsibility and assigns accountability for those areas.
The policy can define the relationship between the IT department and plant operations and identify their
different responsibilities. The policy can differentiate security objectives of the control system from those
of the corporate network. For example, maintaining confidentiality may be a top objective of security for
the corporate network while maintaining continuous operation may be a top objective for the control
system.
The policy identifies particular standards and regulations that apply to the organization. It may identify
training as an important component of the security program. The policy may indicate the consequences
for policy violations.
The policy is communicated throughout the organization so that it is understood by all employees.
5.5.2
Operational Policies and Procedures
Operational policies and procedures are developed at lower levels of the organization to specify how the
corporate security policy is carried out in the sub-organization. Security procedures put the policy into
effect. They define what the organization will do in order to achieve the objectives and to meet the
requirements of the policy. The procedures establish processes that will address all of the concerns of
the policy.
October 2005
57
DRAFT dISA-99.00.01

The procedures address all phases that are needed in a security program, such as:
a) system design
b) procurement
c) process operation
d) system maintenance
e) personnel
f) audit
The procedures identify specific activities, who is accountable for their performance, and when activities
will be done.
The written procedures describe the process by which they will be changed as changes in the situation
develop. A policy or procedure has an identified owner who is responsible for recognizing when updates
are needed and for insuring they are made.
The effectiveness of policies and procedures should be measured in order to determine that they serve
their intended purpose. The cost to the organization should also be measured so that the organization
can determine whether the policies need to be changed to be made more cost effective.
Procedures also need to be updated to reflect changes in technology.
The procedures are able to support audits. A security audit compares the observed actions of the
company against the written procedures.
5.5.3
Topics Covered by Policies and Procedures
The sections below identify some of the topics covered by policies and procedures. Every organization is
different and should determine the appropriate policies and procedures that are applicable for their
Manufacturing and Control Systems.
5.5.3.1
Risk Assessment
Risk assessment is vital to developing a security program that is cost effective, that provides a uniform
layer of adequate security, but which does not require equipment or procedures that are too costly and
significantly beyond the range of adequate security. But risk assessment is complex and needs to be
tailored to the organization. The policy on risk assessment defines the level of risk that is acceptable. This
level varies depending upon the location and circumstances.
5.5.3.2
Access Management
Security is provided in a system by restricting access to information to only those users who need access
and are trusted with the access. Access management policy identifies the different classes of information.
It identifies the different roles of users and what kind of access each role needs to which classes of
information. It specifies the responsibilities of employees to protect information and of administrators to
maintain access management procedures.
5.5.3.3
Physical Security
The security of the control system depends upon the physical security of the space that contains the
control system. A physical security policy may already exist for the plant site before the security policy is
written for the control system. The control system security policy should include a reference to the
physical security policy and state its dependency.
58
October 2005
DRAFT dISA-99.00.01
The security policy for the control system must contain enough specifics on physical security to make any
specific application of the site physical security policy to the control system. For example, some
equipment must be in locked cabinets and the keys must be kept in a restricted place.
5.5.3.4
Control System
Policies and procedures describe secure architectures of control systems including such issues as the
following examples:
a)
b)
c)
d)
e)
f)
g)
Recommended network architectures

Recommended firewall configuration
User authorization and authentication
Interconnecting different process control networks
Domains and trust relationships
Anti-virus management
System hardening in terms of closing ports, disabling unused services, and avoiding the use of
dangerous services
h) Access to the web
i) Email
5.5.3.5
Portable Devices
Portable devices pose all of the security risks of stationary equipment, but their mobility makes it less
likely that they will be covered by the normal security procedures from installation to audit. Thus a special
policy is often needed to cover portable devices. The policy should require the same security protection
as a stationary device, but the technical and administrative mechanisms that provide this protection may
differ.
5.5.3.6
Remote Access
Remote access bypasses the security controls of the boundaries of the system. It extends the trusted
zone to a completely different geographic location and includes a computer that may not have undergone
the security checks of the computers that are physically in the area of the trusted zone. Different
mechanisms are required in order to provide the same level of security as the trusted zone.
5.5.3.7
Personnel
Personnel issues are likely to be covered in the corporate personnel and IT security policies. The control
system security policy provides specifics where the more general policies do not cover control system
aspects. For example, the control system security policies make sure that the personnel screening and
monitoring practices are coordinated with the control system access roles.
5.5.3.8
Subcontractor Policy
Security issues cover work that may involve subcontractors in roles such as supplier, integrator,
maintenance service, or consultant. A security policy that covers subcontractors addresses the
interactions with the subcontractor that could open vulnerabilities. The policy identifies the responsibilities
of the different parties. It addresses the changing responsibilities as projects progress through their
phases and as materials and systems are delivered. The policy may require certain terms to be written
into contracts with subcontractors.
October 2005
59
DRAFT dISA-99.00.01
5.5.3.9

Security Auditing
The security of the system is audited regularly to measure the degree of compliance with the security
policies and practices. The security policy addresses the need for audits and specifies the responsibility,
the regularity, and the requirement for corrective action.
5.5.3.10
Security Policy Updating
The security policy is monitored to determine changes that are needed in the policies themselves.
Monitoring of security policy is a part of each policy and procedure document. The overall approach is set
forth in the corporate security policy. Each operational policy and procedure document contains a
statement of when and by whom the policy or procedure itself is to be reviewed and updated.
60
October 2005

DRAFT dISA-99.00.01
6 Models
This section describes a series of models that provide various views of the subject of manufacturing and
Control Systems security. The objective is to identify the requirements and important characteristics of
the environment at a level of detail necessary to address security issues with a common understanding of
the framework and vocabulary.
In order to fully address this objective various types of models may be required, each describing the
overall scope from a different logical perspective. Examples include:
a) logical models showing levels of systems and devices ranging from enterprise to control module, or
how different security requirements and constraints apply for various portions of the overall
environment
b) physical models that describes the hierarchy from physical infrastructure to applications
c) conceptual models that serve to illustrate a specific topic or concept
In each of the above cases, models have already been defined in other standards or publications.
Wherever possible, these established models will be used in this standard.
6.1
Reference Model
When describing a standard or direction it is first necessary to establish a frame of reference for the more
detailed information that follows. This frame of reference is commonly referred to as a reference model,
a term that became popular with the success of the ISO Seven Layer model for Open Systems
Interconnection. The NASA Office of Standards and Technology (NOST) define the term as:
A reference model is a framework for understanding significant relationships among the entities of
some environment, and for the development of consistent standards or specifications supporting that
environment. A reference model is based on a small number of unifying concepts and may be used
as a basis for education and explaining standards to a non-specialist.7
The general reference model that forms the basis if this standard is shown in the following diagram. It is
based on the Purdue Reference Model (PRM) for Computer Integrated Manufacturing, and the Functional
Hierarchy Model of ANSI/ISA-95.00.01-2000. In addition to the control hierarchy from PRM and ISA-95,
the General Reference Model also shows the separation between Control and Safety systems and
networks as specified in ANSI/ISA-84.01-1996. This hierarchical model describes the functions and
activities from the Process (Level 0) to the Enterprise (Level 5).
NASA/Science Office of Standards and Technology (NOST),

http://ssdoo.gsfc.nasa.gov/nost/isoas/us04/defn.html
October 2005
61
DRAFT dISA-99.00.01

Level 5
Enterprise
Level 4
Site Business Planning

and Logistics
Level 3
Site Manufacturing
Operations and Control
Level 2
Area Supervisory Control
Level 1
SafetyCritical
Level 0
Basic
Control
Enterprise
Manufacturing
Control
Safety
Process
Figure 4 General Reference Model

6.1.1
Levels of the Reference Model
Note to Committee: ISA-95 and the Purdue Reference Model specify Level 3 as the Area level and Level 2 as the
Supervisory Level. However, in practice, Level 3 is becoming the plant-wide control and scheduling level. The
advantages of having a single plant-wide network at Level 3 are that it minimizes the number of security control points
between Level 4+ (business) and Level 3- (operations and control). This section assumes that Level 3 is the plant-wide
control and scheduling level, and Level 2 is the Supervisory / Area level. Since this is a departure from ISA 95, it
should be discussed and agreed in committee.
6.1.1.1
Level 5 Enterprise
Level 5 functions include corporate or regional financial systems and other corporate infrastructure
components such as email systems. Level 5 activities include, but are not limited to:
a)
b)
c)
d)
enterprise accounting
business to business interactions
business to customer interactions
individual plant production targets
6.1.1.2
Level 4 Site Business Planning and Logistics
Level 4 functions include production scheduling, operational management, and maintenance

management for an individual plant or site in an enterprise. Level 4 activities include, but are not limited
to:
a) raw material and spare parts usage and available inventory,
b) overall energy usage and available inventory,
62
October 2005

c)
d)
e)
f)
g)
h)
i)
j)
DRAFT dISA-99.00.01
overall goods in process and production inventory,

quality control information,
machinery and equipment use and life history,
manpower use data,
basic plant production schedule,
preventive maintenance schedules
optimum inventory levels of raw materials, energy sources, spare parts, and goods in progress
capacity planning
As the capacity and speed of global communications improve, some Level 4 functions may become
centralized at the Level 5 Enterprise level. Enterprise Resource Planning (ERP) systems usually integrate
at this level to the process servers and historians.
6.1.1.3
Level 3 Site Manufacturing Operations and Control
Level 3 functions include dispatching production, detailed production scheduling, reliability assurance and
site-wide control optimization. Level 3 activities include but are not limited to:
a)
b)
c)
d)
e)
f)
reporting on production
data on production, inventory, manpower, raw materials, spare parts, and energy usage
data collection and offline analysis to support engineering functions
personnel functions such as work period statistics
detailed production schedule
optimizing the costs for individual production areas
6.1.1.4
Level 2 Area Supervisory Control
Level 2 includes the manufacturing operations equipment for an individual production area. There are
typically multiple production areas in a plant such as distillation, conversion, and blending in a refinery.
Level 2 typically includes the following functions:
a)
b)
c)
d)
operator human-machine interface

operator alarms and alerts
supervisory control functions
process history collection
6.1.1.5
Level 1 Basic Control
Level 1 includes process monitoring and control equipment. Process monitoring equipment reads data
from sensors, may execute an algorithm, and maintains process history. Examples of process monitoring
systems include tank gauging systems, continuous emission monitors, and temperature indicating
systems. Process control equipment is similar. It reads data from sensors, executes a control algorithm,
and sends an output to a final element (e.g. control valve). Level 1 controllers are directly connected to
the sensors and final elements of the process.
Level 1 includes continuous control, sequence control, batch control, and discrete control. Many modern
controllers include all types of control in a single device.
Examples of Level 1 equipment include:
October 2005
63
DRAFT dISA-99.00.01

a) Distributed Control System (DCS) controllers

b) Programmable Logic Controllers (PLC)
c) Remote Terminal Units (RTU)
6.1.1.6
Level 0 Process
The process includes a number of different types of manufacturing facilities in all sectors, including but
not limited to: discrete parts manufacturing, hydrocarbon processing, product distribution,
pharmaceuticals, pulp and paper, electric power, etc.
Level 0 includes the sensors and final elements that are directly connected to the process and process
equipment.
6.1.1.7
Safety - Critical
Safety-critical systems include protective systems and safety instrumented systems that monitor the
process and take automatic action to return the process to safe state if it exceeds safe limits. This
category also includes systems that monitor the process and alert an operator of impending unsafe
conditions.
Although the reference model shows the safety-critical systems as a separate level, this is not necessarily
the case in all situations. It is possible to implement safety-critical systems within the same level as basic
control, using appropriate logical separation. The depiction shown in this reference model was chosen as
a means of emphasizing the need for this separation in order to ensure the integrity of the safety
functions.
6.1.2
Separation strategy
The separation strategy relies on a defense-in-depth approach to protect these assets. This strategy as
depicted in the Reference Model (above) should consist of both logical and physical barriers with
component placement behind successive barriers based upon criticality. This strategy essentially
represents a high-level abstraction of how data flow between levels will be managed when dealing with
the various trust-levels.
The basic trust levels are summarized as follows:
Trust Level 0 (level 0 represents the process).
Trust Level 1 (level 1 represents the controls).
Trust Level 2 (level 2 supervisory controls). {level 1 and 2 may be combined}
Trust Level 3 (level 3 data collection).
Change is more stringently controlled within each successive barrier and emphasis is placed on
controlling connectivity. Assets that exist within the same trust level are generally safe to communicate
freely with each other. Allowed communications are based upon protective measure that exist at the
boundaries of adjoining levels.
Connectivity between data and logistics should be outgoing only (not bi-directional).
The control assets should be physically isolated such that no network connectivity exits with another
system located in the levels 3-5. An exception would be the communications path that is one way
outbound only to level 3.
64
October 2005

6.1.3
DRAFT dISA-99.00.01
Characteristics of the Reference Model
6.1.3.1
Scope of Control
The scope of control decreases as you traverse the reference model hierarchy from highest to lowest
levels. At Level 5, the scope is the entire enterprise. At Level 4 and 3, the scope is an entire site or plant
location. At Level 2 and Level 1, the scope decreases to a single area or piece of plant equipment.
As the scope of control decreases, the potential scale of failure also decreases. Thus, at the lowest levels
of the reference model hierarchy, a system or network failure will only affect part of the plant, but can
cause significant physical damage or impacts on regulatory conformance.
6.1.3.2
Real-time Response
The speed of response of control actions increases as you traverse the reference model hierarchy from
highest to lowest levels. At Level 0, response times are typically in milliseconds, Level 1, response times
are typically in seconds, Level 2 in minutes, Level 3 in hours, and Levels 4 and 5 in days.
6.1.3.3
Availability
Availability requirements increase as you traverse the reference model from highest to lowest levels.
Each level typically increases availability requirements by an order of magnitude. To achieve this
availability requirement, operator workstations, networks and controllers at Levels 2 and 1 are typically
redundant.
Enterprise Network
Level 5 - Enterprise
Enterprise Financial Systems
WAN
Router
Level 4 - Site Business Planning

Site Business Network
Production
Control
Optimizing
Control
Level 3 - Site Manufacturing Operations
Process
History
Process Control Network
Supervisory
Control
Production Control
Optimizing Control
Process History
Windows Domains
Level 2 - Area Supervisory Control
Supervisory
Control
Operator Interface
Site Production Scheduling

Site Accounting
Supervisory Controllers
Primary Operator Interface
Operator Interface
Level 1 - Basic Process Control

Batch
Control
Discrete
Control
Continuous
Control
Process
Monitoring
Batch Controllers
Continuous Controllers
Discrete Controllers
Process Monitoring
Level 0 - Field Instrumentation

Sensors, Transmitters, Control Valves
Field Networks (e.g. Foundation Fieldbus, Profibus)
Process
Protective
System
Safety-Critical
Protective Systems
Safety Instrumented Systems
Figure 5 DCS Example using the General Reference Model
October 2005
65
DRAFT dISA-99.00.01

Level 5
Enterprise
Level 4
Site Business Planning

and Logistics
Level 3
Site Manufacturing
Operations and Control
Level 2
Area
Control
Area
Control
Level 1
Basic
Control
Basic
Control
Level 0
Process
Process
SafetyCritical
SafetyCritical
Enterprise
Security Zone
Manufacturing
Security Zone
Area
Security Zone
Safety
Security Zone
Figure 6 Example Reference Model with Security Zones
66
October 2005

6.2
DRAFT dISA-99.00.01
Physical Models
Modern control systems are complex computer networks consisting of many interconnected components
that perform a variety of tasks to safely and efficiently operate chemical plants, auto parts manufacturing
plants, pipelines, electric generation, transmission and distribution networks and many other types of
industrial facilities, transportation systems and utilities.
At one time these systems were isolated from other computers in the enterprise and used proprietary
hardware, software and networking protocols. This is no longer the case as control system vendors have
adapted Commercial-Off-The-Shelf (COTS) information technology because of its cost advantages and
business needs have driven the integration of control systems with business information systems.
From a security perspective we are concerned with the control equipment itself, the users of that
equipment, the connections between control system components and the inter-connections with business
systems and other networks.
This standard is intended to apply to the broad range of manufacturing and control systems used across
multiple industry segments. Therefore the physical model must start at a high level and be generic
enough to fit the many situations where control systems are deployed.
The following figure illustrates a typical configuration for a continuous or batch process manufacturing
facility. It shows the components of the system, the types of users who require access to the system and
indicates (very generally) the information flows between components. Control systems used by other
industries and utilities follow similar concepts but vary in the details according to the requirements and
operating practices appropriate to the industry segment. Indeed individual companies within the same
industry may take somewhat different approaches to the design and configuration of their control
systems.
October 2005
67
DRAFT dISA-99.00.01
Sales

Finance
Plant
Manager
Business
Systems
PIMS
Engineer
AMS
Engineering
Station
Technician
Supervisor
Operator
Recipe
Manager
Recipe
Manager
Controller
HMI
Field Device
Personnel
Components
Figure 7 Process Manufacturing Control System Example
68
October 2005

6.2.1
DRAFT dISA-99.00.01
Manufacturing Hierarchy Model
The physical assets of a batch, continuous, or discrete manufacturing enterprise are usually organized in
a hierarchical fashion as described in ANSI/ISA S95.01. For the purposes of this standard, this model is
extended to include control equipment and field I/O that are outside the scope of ANSI/ISA-95 but need to
be considered when dealing with security.
May be
linked by
May
Contain
Data Center
Internet
Enterprise
May
Contain
May be
linked by
May Contain
Site
Site Information System

May
Contain
Wide Area Network (WAN)

May be
linked by
May Contain
Site Network (LAN)
Area
Area Information System

May
Contain
Line Information System
May Contain
May be
linked by
Lines, Units, Cells, Etc..
May Contain
May
Contain
Area Control Networks (ACN)

May be
linked by
Process Control Network (PCN)
Control Equipment
May Contain
May Contain
Field I/O Network

May Contain
May Contain
Sensors
Actuators
Figure 8 Manufacturing Hierarchy Model

Due to the important role that networks play in security, the model explicitly includes the network
elements typically present at each level of the hierarchy. At each level, the equipment (or facilities) are
linked together by the appropriate type of network. Although the networks themselves may be linked
together this model does not depict that linkage.
The model also depicts ancillary information systems that may be present at various levels of the
hierarchy. Theses systems do not directly control the process but do interact with the control equipment
by collecting data from it and sending down recipes and process instructions. Line, area and site
information systems also act as repositories to serve production information to users throughout the
enterprise and may interact with Enterprise Resource Planning (ERP) applications running in the
corporate data center.
October 2005
69
DRAFT dISA-99.00.01
6.2.1.1

Enterprise
An enterprise is a business entity that produces and transports products or operates and maintains
infrastructure services. Enterprises are often connected to the Internet to communicate to other
enterprises or to provide information and services (such as email) to their employees. Enterprises
typically operate one or more data centers to support their information processing requirements. Security
for these IT assets is outside the scope of this standard.
6.2.1.2
Site
A site is a subset of an enterprises physical, geographic or logical group of assets. It may contain areas,
manufacturing lines, process cells and process units. Sites may be connected to other sites by a wide
area network (WAN). A site may include information systems such as a Manufacturing Execution System
(MES) that coordinates production activities at the site.
6.2.1.3
Area
An area is a subset of a sites physical, geographic or logical group of assets. It may contain
manufacturing lines, process cells and production units. Areas may be connected to each other by a site
local area network (LAN) and may contain information systems related to the operations performed in that
area.
6.2.1.4
Lines, Units, Cells
Areas are made up of lower level elements that perform the manufacturing functions. The terminology
used corresponds to the type of manufacturing operation continuous, repetitive, or batch. Although
ANSI/ISA-95 separates out these model elements, this distinction is unnecessary for our purposes.
Entities at this level may be connected together by an area control network and may contain information
systems related to the operations performed in that entity.
6.2.1.5
Control Equipment
Control equipment includes distributed control systems (DCS), programmable logic controllers (PLC) and
associated operator interface consoles that are used to manage and control the manufacturing process. It
also includes field bus networks where control logic and algorithms are executed on intelligent field
devices that coordinate actions with each other.
6.2.1.6
Field I/O Network, Sensors and Actuators
Sensors and actuators are the end elements that are connected to process equipment. The field I/O
network is the communications link (wired or wireless) that connects these elements to the control
equipment.
70
October 2005

6.2.2
DRAFT dISA-99.00.01
SCADA Hierarchy Model.
Control systems used by infrastructure industries such as pipelines, power transmission companies and
electricity, water and gas distribution utilities have many similarities to manufacturing systems but also
have unique aspects because they must operate over a wide geographic area.
May be
linked by
May
Contain
Enterprise
Data Center
Internet
May be
linked by
May
Contain May Contain
Control Center
Information System
Control Center

May be
linked by
May Contain
Control Equipment
May Contain
May
Contain
May
coordinate
May be
linked by
Site Information System

Remote Sites
Supervisory Control Network
May Contain
May be
linked by
May Contain
Control Equipment
May Contain
May Contain
Field I/O Network

May Contain
May Contain
Sensors
Actuators
Figure 9 SCADA Physical Hierarchy Model

6.2.2.1
Control Center
Infrastructure industries typically utilize one or more control centers to supervise or coordinate their
operations. If the enterprise has multiple control centers (for example a back-up center at a separate site)
they are typically connected together via a wide area network. The control center contains the SCADA
host computers and associated operator display devices plus ancillary information systems such as a
historian.
October 2005
71
DRAFT dISA-99.00.01
6.2.2.2

Remote Site
The remote site contains equipment in the form of Programmable Logic Controllers (PLC), Remote
Terminal Units (RTU) or Intelligent Electronic Devices (IED) that is responsible for monitoring and
controlling operations local to the site. Remote sites are connected to the control center by a supervisory
control network (sometimes referred to as a telemetry network). Remote sites may also be connected to
each other (to facilitate functions such as protective relaying between substations in an electrical
transmission grid for example).
6.2.3
Vehicle Hierarchy Model
Automated vehicles, whether used in transportation, mining or manufacturing applications employ control
systems similar to those found in other industrial applications. Because the vehicles may act
autonomously and operate over a wide area the architecture of these systems is similar to that of a
SCADA system.
May be
linked by
May
Contain
Enterprise
Data Center
Internet
May be
linked by
May Contain
May
Contain
Control Center
Information System
Control Center

May be
linked by
May Contain
Control Equipment
May Contain
May
Contain
May
coordinate
Vehicle Information System
May be
linked by
Vehicle Communication Network
Vehicle
May Contain
May be
linked by
May Contain
Control Equipment
May Contain
May Contain
Field I/O Network

May Contain
May Contain
Sensors
Actuators
Figure 10 Vehicle Physical Hierarchy Model

6.2.3.1
Vehicle
A vehicle is a mobile device that includes a control system allowing it to operate either autonomously or
under remote control. Vehicles may be part of a transportation system or used within a manufacturing
operation. A Vehicle may be connected to a control center or to other vehicles by a vehicle
communication network.
72
October 2005

6.3
DRAFT dISA-99.00.01
Logical Models
Logical models present views of the relationships between systems and devices, or how different security
requirements and constraints apply for various portions of the overall environment.
6.3.1
Zone and Conduit Model
A Zone and Conduit Model is used to describe the logical groupings of assets within an Enterprise or a
subset of the enterprise. The assets are grouped into entities that can then be analyzed for security
policies and hence requirements. The model helps to assess common threats, vulnerabilities and the
corresponding security measures that may be needed to attain a given level of security deemed required
to protect the grouped assets.
6.3.1.1
Zone Definition
A Zone is a logical grouping of Physical, Informational and Application assets that share common security
requirements that is defined in a Zone Security Policy. The Zone is defined from the Physical and
Functional models that were developed according to the prior sections on Physical and Functional
models. By grouping assets in this manor, a security policy can be defined for all assets that are a
member of the Zone. This analysis can then be used to determine the appropriate protection that is
required based on the activities that are performed in the Zone.
6.3.1.1.1
Zone Characteristics
Zones can be a grouping of independent assets, a grouping of sub-Zones (a Zone defined within a Zone)
or a combination of both independent assets and assets that are also grouped into sub-Zones contained
within the major Zone. Zones have the characteristic of inheritance. That is a child-Zone (or sub-Zone)
must meet all of the requirements of the parent Zone. A simplified multi-plant corporation Zone model is
listed in the following figure. Here the Enterprise Zone is the parent, and each plant is a child or sub
Zone with a control sub-Zone contained within the plant sub-Zone.
October 2005
73
DRAFT dISA-99.00.01

Enterprise Zone
Laptop computer
Workstation
Mainframe
Plant A Zone
Server
Plant B Zone
Router
Plant C Zone
Router
Laptop computer Workstation
IBM AS/400
Server
Router
IBM AS/400
File/Print App.
Data
Server Server Server
Plant A Control Zone
IBM AS/400
File/Print App. Data

Plant B Cotrol Zone

Firewall
App ServerData Server

Maint. Server

Plant C Control Zone

Firewall
Firewall

Maint. Server

Maint. Server
Controller
Controller
Controller
Controller
Controller
Controller
I/O
I/O
I/O
I/O
I/O
I/O
Figure 11 Multi-plant Zone Model

The same corporate architecture could be grouped into separate Zones as in the following figure:
Enterprise Zone
Laptop computer
Workstation
Mainframe
Plant A Zone
Server
Plant B Zone
Router
IBM AS/400
Plant C Zone
Router
Router
IBM AS/400

IBM AS/400

Plant B Cotrol Zone

Firewall

Maint. Server
Server


Firewall

Maint. Server
Firewall

Maint. Server
Controller
Controller
Controller
Controller
Controller
Controller
I/O
I/O
I/O
I/O
I/O
I/O
Figure 12 Separate Zones

In the second model the Zone policies would be independent, and can have totally different security
policies for each Zone.
74
October 2005

6.3.1.1.2
DRAFT dISA-99.00.01
Zone Attributes
Each Zone has a set of characteristics and security requirements that are its attributes. These take the
form of:
a)
b)
c)
d)
e)
f)
Policies for the Zone

The inventory of the assets included in the Zone
The access requirements and how access is controlled
The threats and vulnerabilities of the Zone
The permitted (or actual) technology used to implement systems within the Zone
A change management process to maintain accuracy of the assets within a Zone
6.3.1.1.2.1
Zone Security Policy
Each Zone has a controlling document that describes the overall security goals and how to insure that
these goals are met. This includes:
a)
b)
c)
d)
e)
f)
g)
h)
The Zone scope

The organizational structure and responsibilities to enforce the security policy
The Risks associated with the Zone
The Security Strategy to meet the required goals
The security measures to be enforced
The types of activities that are permitted within the Zone
The types of communication allowed access to the Zone
Documentation of the Zone attributes
All of the above are documented and combined into the Zone Security Policy that is used to guide and
measure the construction and maintenance of the assets that are contained within the Zone.
6.3.1.1.2.2
Zone Asset Inventory
In order to maintain security within a Zone, a list of all of the assets (Physical, informational, applications
and security counter measures) needs to be maintained. This list is used to assess risk and
vulnerabilities and to determine and maintain the appropriate security measures required to meet the
goals of the security policy. Inventory accuracy is a key factor in meeting the security goals set forth in
the security policy. The list must be maintained through changes in assets within the Zone as well as
when new assets are added to the Zone in order to insure that the security goals are met.
October 2005
75
DRAFT dISA-99.00.01
6.3.1.1.2.2.1

Hardware Assets and Components (Physical)
This is the list of physical devices that are contained within the Zone. Some examples include:
a) Computer hardware (workstations, servers, instruments, controls, power supplies, disk drives, tape
backups)
b) Network equipment, such as routers, switches, hubs, firewalls, or physical cables
c) Communications links (buses, links, modems, and other network interfaces, antennas)
d) Access authentication and authorization equipment, such as domain controllers, radius servers,
readers, and scanners
e) Development system hardware
f) Simulation/training system hardware
g) External system hardware
h) Spare parts inventories
6.3.1.1.2.2.2
Informational and Application Assets
All of the software and data used in the Zone are contained within this asset category. Some examples
are as follows:
a) Computer system software (applications, operating systems, external application, communication
interfaces, configuration tables, development tools, analysis tools, and utilities)
b) Patches and upgrades for operating systems and application tool sets
c) Development system software
d) Simulation software
e) External system applications
f) Databases
g) Data archives
h) Network equipment configuration files
i) Access authentication and authorization control applications
j) Backup and recovery media (CDs, disks, tapes)
k) Design basis documentation (functional requirements including information/assets, security
classification, and levels of protection, physical and software design, vulnerability assessment,
security perimeter, benchmark tests, assembly/installation documents)
l) Supplier resources (product updates, patches, service packs, utilities, validation tests)
6.3.1.1.2.3
Zone Access Requirements and Control
By its nature, a Zone implies that access is restricted to a limited set of all the possible access that could
occur. A security policy for a Zone must then articulate what is the access that is required for the Zone to
meet its business objectives, and how this access is controlled.
6.3.1.1.2.4
Zone Threat and Vulnerability Assessment
Threats and corresponding vulnerabilities exist within a given Zone. These threats and vulnerabilities
need to be identified and evaluated as to their risk in causing failure of the assets within the Zone to meet
their business objectives. The process of documenting the threats and vulnerabilities is the Threat and
Vulnerability Assessment that is part of the Zone Security Policy.
6.3.1.1.2.5
76
Zone Vulnerability Counter Measures
October 2005

DRAFT dISA-99.00.01
Many possible countermeasures exist to reduce the risk of a threat exploiting a given vulnerability within a
Zone. The Security Policy should outline what types of countermeasures are appropriate to make the
cost versus risk trade-off.
6.3.1.1.2.6
Zone Authorized Technology
As manufacturing and control systems evolve to meet changing business needs the technology used to
implement the changes need to be controlled. Each of the technologies used in these systems brings
with it a set of vulnerabilities and corresponding risks. To minimize the risks to a given Zone, and
dynamic list of technologies allowed in the Zone needs to be maintained in the Zone security policy.
6.3.1.1.2.7
Zone Change Management Process
A formal and accurate process is required to maintain the accuracy of the asset inventory of a given Zone
and how changes to the Zone Security Policy are made. This is to insure that changes and or additions
to the Zone do not compromise the security goals. In addition, a way to adapt to changing security
threats and goals is also required. Threats and vulnerabilities, with their associated risks will change over
time.
6.3.1.1.3
Zone Determination
In building a security program Zones are one of the most important tools to insure program success. The
proper determination of the Zones is the most important aspect of the tool. When defining the Zones, it is
important that both the physical implementation (Physical Model) and the functions (Functional Model) be
used to develop the proper security Zones to meet the security goals established in the Manufacturing
And Control Systems Security Policy.
Zone determination starts with the physical model developed from section 6 and then overlays the
functions and activities from section 7. When different level activities are performed within a given
physical device, the choice must then be made to map the physical device to the more stringent security
requirements, or to create a separate Zone that has with it a separate Zone security policy that is a
blended policy between the two Zones. A typical example of this occurs in process historian servers. To
be effective the server needs access to the critical control devices that are the source of the data to be
collected, but to meet the business need of presenting that data to supervisors and process optimization
teams a more liberal access to the device is required than a typical control system security requirements
would allow. In this case a separate Process Historian or De-Militarized Zone (DMZ) may be required.
6.3.1.2
Conduit Definition
Conduits are security Zones that apply to specific communications processes. Like security Zones they
are a logical grouping of assets (communication assets in this case). A security conduit protects the
security of the channels that it contains in the same way that the physical conduit protects the cables from
physical damage. Conduits can be thought of as Pipes that connect Zones or used for communication
within a Zone. Internal (within the Zone) and external (outside the Zone) conduits enclose or protect the
communications channels (conceptually wires) that provide the links between assets. Most often in a
Manufacturing Environment the conduit is the same as the network. That is the conduit is the wiring,
routers, switches and network management devices that makeup the communications under study.
Conduits can be groupings of dissimilar networking technologies, as well as the communications
channels that can occur within a single computer. Conduits are used to analyze the communication
threats and vulnerabilities that can exist in the communications within and between Zones.
6.3.1.2.1
Conduit characteristics
October 2005
77
DRAFT dISA-99.00.01

Conduits, unlike Zones do not have an inheritance property. That is, a conduit is not made up of other
sub-conduits. Conduits are defined by the list of all Zones that share the given communication channels.
Both physical devices and applications that utilize the channels contained in a conduit define the Conduit
end points. The following drawing shows the Enterprise conduit in red:
Enterprise Zone
Laptop computer
Workstation
Mainframe
Plant A Zone
Server
Plant B Zone
Router
IBM AS/400
Server
Plant C Zone
Router
IBM AS/400

Router
IBM AS/400

Plant B Cotrol Zone

Firewall

Maint. Server


Firewall

Maint. Server
Firewall

Maint. Server
Controller
Controller
Controller
Controller
Controller
Controller
I/O
I/O
I/O
I/O
I/O
I/O
Figure 13 Enterprise Conduit

6.3.1.2.2
Conduit Attributes
Like a Zone, each Conduit has a set of characteristics and security requirements that are its attributes.
These take the form of:
a)
b)
c)
d)
e)
f)
Policies for the Conduit

The inventory of the assets included in the conduit
The access requirements and how access is controlled
The threats and vulnerabilities of the conduit
The permitted (or actual) technology used to implement the conduit
A change management process to maintain accuracy of the assets within a conduit
g) Zones connected
6.3.1.2.2.1
78
Conduit Policy
October 2005

DRAFT dISA-99.00.01
Each Conduit has a controlling document that describes the overall security goals and how to insure that
these goals are met. This includes:
a) The Conduit scope
b) The organizational structure and responsibilities to enforce the conduit security policy
c) The Risks associated with the Conduit
d) The Security Strategy to meet the required goals
e) The security measures to be enforced
f) The types of channels that are permitted within the conduit
g) Documentation of the Conduit attributes
All of the above are documented and combined into the Conduit Security Policy that is used to guide and
measure the construction and maintenance of the assets that are contained within the Conduit.
6.3.1.2.2.2
Asset Inventory
As with the Zone inventory, an accurate list of the communications assets is required.
6.3.1.2.2.3
Access Requirements and Control
By its nature, a Conduit implies that access is restricted to a limited set of all the possible access that
could occur. A security policy for a Conduit must then articulate what is the access that is required for the
Conduit to meet its business objectives, and how this access is controlled.
6.3.1.2.2.4
Threat and Vulnerability Assessment
Threats and corresponding vulnerabilities exist for a given Conduit. These threats and vulnerabilities
need to be identified and evaluated as to their risk in causing failure of the assets within the Zone to meet
their business objectives. The process of documenting the threats and vulnerabilities is the Threat and
Vulnerability Assessment that is part of the Zone Security Policy.
6.3.1.2.2.5
Vulnerability Counter Measures
Many possible countermeasures exist to reduce the risk of a threat exploiting a given vulnerability within a
conduit. The Security Policy should outline what types of countermeasures are appropriate to make the
cost versus risk trade-off.
6.3.1.2.2.6
Authorized Technology
As manufacturing and control systems evolve to meet changing business needs the technology used to
implement the changes need to be controlled. Each of the technologies used in these systems brings
with it a set of vulnerabilities and corresponding risks. To minimize the risks to a given Conduit a
dynamic list of technologies allowed in the Conduit needs to be maintained in the Conduit Security Policy.
6.3.1.2.2.7
Change Management Process
A formal and accurate process is required to maintain the accuracy of the asset inventory of a given
Conduit and how changes to the Conduit Security Policy are made. This is to insure that changes and or
additions to the Conduit do not compromise the security goals. In addition, a way to adapt to changing
security threats and goals is also required. Threats and vulnerabilities, with their associated risks will
change over time.
6.3.1.2.3
Conduit Determination
October 2005
79
DRAFT dISA-99.00.01


6.3.1.2.4
Communication Channels
80
October 2005

6.4
DRAFT dISA-99.00.01
Functional Models
Functional models are used to describe the functions and activities associated with Manufacturing and
Control Systems. They are used in conjunction with other models to assess threats, vulnerabilities and
corresponding security measures that are required to reach a certain level of security.
6.4.1
Functional Hierarchy Model
The functional hierarchy model shown in the following figure identifies the hierarchy of functions
associated with process control, coordination, operation, and maintenance of manufacturing and control
systems.
Business Planning & Logistics
Level 4
Level 3
(Plant Production Scheduling, Operational Management, etc.)
Manufacturing Operations & Control

(Dispatching Production, Detailed Production Scheduling, Reliabi lity Assurance, etc.
)
Engineering
Data
Collection
Operations
Level 2
Coordination
Level 1
Level 0
Maintenance
Control
Measurement
Safety
Actuation
Figure 14 Functional Hierarchy Model

6.4.1.1
Measurement
The measurement function involves determination of the existence or magnitude of a process variable.
The measured process variable is used for monitoring or control. If the integrity of the measured signal is
violated due to a security breach, the resulting control action is affected. The control action, either manual
or automatic, based on incorrect measurement can lead to undesirable consequences.
Example: The false detection of a hazardous chemical leak may trigger drastic control measures such as
aborting the batch or flooding the reactor with an inert chemical.
October 2005
81
DRAFT dISA-99.00.01

A typical measurement system consists of a sensor, transducer and transmitter. In most applications, the
transmitter is located close to the sensor and transducer. The transmitter is connected to the controller
using different types of physical media and software protocols. The integrity of the measured signal may
be compromised in the following manner:
Physical access to sensor, transducer or transmitter The parameters of the measuring system may
be modified by means of keypad, switches or jumpers on the instrument.
Access to the transmission link between measurement system and controller Typical methods of
transmission of a measured signal include 4 20 mA signal over a pair of wires, digital signal over a
fieldbus or wireless transmission. The measured signal may be altered by tapping into the
transmission link. Additionally, the signal could be electronically intercepted if the sensor utilizes
remote access from a dial-up or Internet access.
6.4.1.2
Actuation
The actuation function involves controlling the process by means of a final control element. The actions of
the final control element are based on a decision by a manual or automatic controller. The output of a
controller actuates real world devices, equipment and processes thereby making actuation one of the
most critical functions from a manufacturing and control systems security perspective.
Example 1: The setting or resetting of a bit in the controller determines whether a pump should be
started or stopped.
Example 2: Changing the parameters of a valve positioner using a handheld device or a remote system
can lead to undesirable consequences.
Typical final control elements include control valves, dampers, motors, pumps, variable speed drives,
relays, and breakers. The final control element is connected to the controller using different types of
physical media and software protocols. The integrity of the signal to the final control element may be
compromised in the following manner:
Physical access to final control element The parameters of the final control may be modified by
means of a keypad, switches or jumpers on the device.
Access to the link between the controller and final control element Typical methods of transmission
of a control signal include 4 20 mA signal over a pair of wires, digital signal over a fieldbus or
wireless transmission. The control signal may be altered by tapping into the transmission link.
Additionally, the signal could be electronically intercepted if the controller utilizes remote access from
a dial-up or Internet access.
6.4.1.3
Control
The control function involves achieving the setpoint or control objective by using measured variables and
manipulating final control elements based on a control algorithm. The control function depends on other
lower and higher level functions as listed below:
Measured signal(s) These are made available by the measurement function
Setpoint or control objective The setpoint or control objective is set by the operator as part of the
operations function
Control algorithm The control algorithm is established by the engineering function
Control signal(s) These are signal(s) to the final control element(s) for actuation or alarms to
operators
The control function is also influenced by maintenance and coordination functions.
82
October 2005

DRAFT dISA-99.00.01
The integrity of signals to and from the controller may be compromised in different ways depending on
how the control function is physically implemented. This may include physical access to the controller or
access to links between the controller and other functions. The controller is connected to other control
system components using either physical, wireless or software links.
Example: When the control and analog output function blocks are executed in a Foundation Fieldbus
valve positioner, the connection between the control function and actuation function is a software link.
6.4.1.4
Safety
Material for this section is not yet available.

6.4.1.5
Coordination
This function involves coordination of various control functions between different controllers and
productions units or cells. The coordination function helps in process optimization by higher level decision
making systems.
The coordination function is implemented either in the controller or software running on commercially
available off the shelf (COTS) components. These systems are connected to other control system
components using physical, wireless or software links. Remote access to these systems, using dial up
modem or via business networks, is being increasingly used for monitoring. The integrity of the
information to and from these systems may be compromised by unauthorized access of these systems or
access to links connecting other systems.
6.4.1.6
Engineering
The engineering function includes development, simulation and testing of control strategies. This function
may also include process simulation for purpose of training and data reconciliation. Data from
controller(s) can be used to develop process models, which are then used to develop control strategies.
Control strategies are tested using simulation and testing software, which may be a part of the control
systems configuration software or a separate software package. Control strategies are then downloaded
to the controller for execution.
Control strategies are developed using control systems configuration software provided by the vendor.
Control systems software is being increasingly implemented using commercially available off the shelf
(COTS) components. Control systems engineering stations are connected to the controller and other
control system components using physical, wireless or software links. Remote access to these systems,
using dial up modem or via business networks, is being increasingly used to make configuration changes
and trouble shooting. The integrity of the information to and from engineering station(s) may be
compromised by unauthorized access to the engineering station(s) or access to links connecting other
systems.
6.4.1.7
Operation
The operating function uses a window to monitor and control the process. This function involves adjusting
setpoints and control objectives. It also allows the operator to take over control of devices and equipment
instead of using automatic control algorithms.
This window is typically in the form of a human machine interface. Increasingly this interface is being
implemented using commercially available off the shelf (COTS) components. This interface is
connected to the controller and other control system components using a physical, wireless or software
link. Remote access to these systems, using dial up modem or via business networks, is being
increasingly used. The integrity of the information to and from this interface may be compromised by
unauthorized access to the interface or access to links connecting other systems.
October 2005
83
DRAFT dISA-99.00.01
6.4.1.8

Maintenance
The maintenance function involves monitoring of diagnostic information, and retention of calibration and
maintenance records for devices and equipment. This function also includes maintenance and backup of
control system databases. The information from maintenance systems influences control and operation
strategies. This information is also used for decision making by higher level manufacturing and enterprise
systems.
Maintenance systems are being implemented using commercially available off the shelf (COTS)
components. These systems are connected to other control system components using physical or
software links. Remote access to these systems, using dial up modem or via business networks, is being
increasingly used. The integrity of the information to and from these systems may be compromised by
unauthorized access to the interface or access to links connecting other systems.
6.4.1.9
Data Collection
The data collection function involves collection of process data for monitoring and analysis. The
information is used to develop and modify control strategies, process optimization and decision making
by higher level manufacturing and enterprise systems.
Data collection systems are being implemented using software running on commercially available off the
shelf (COTS) components. These systems are connected to other control system components using
physical or software links. Remote access to these systems, using dial up modem or via business
networks, is being increasingly used for monitoring. The integrity of the information to and from these
systems may be compromised by unauthorized access to the interface or access to links connecting
other systems.
84
October 2005

6.4.2
DRAFT dISA-99.00.01
Activity Model
The activity model shown in the following figure shows the activities associated with process control,
operation, coordination and maintenance of manufacturing and control systems.
Level 3
Level 3:
Manufacturing Operations
Operator
Actions
Inter-Controller
Communication
Addressed by
ANSI/ISA-95
Data
Reporting
Levels 0-2
Control
Strategy
Development
Control
Strategy
Execution
Field Network
Communication
Control
Strategy
Simulation
Control System
Maintenance &
Health
Monitoring
Safety Level
Safety Strategy
Execution
Safety Network
Communication
Figure 15 Activity Model
October 2005
85
DRAFT dISA-99.00.01
6.4.2.1

Field Network Communication
This activity involves communication between the controller, measurement systems and final control
elements. Communication networks use physical, wireless or software links for connection.
Field network communication is implemented using different types of physical, wireless or software links.
This may be in the form of wires or fiber optic cables, input-output bus, fieldbus, or wireless network. This
is a real time activity that has a direct influence on the process being monitored and controlled. It is
critical to maintain data integrity as well as speed of response.
6.4.2.2
Safety Network Communication

6.4.2.3
Control Strategy Execution
This activity involves executing the control strategy that was developed as part of control strategy
development activity. Control strategy execution is the focal point of all activities associated with process
control, operation, coordination and maintenance of manufacturing and control systems. This activity
uses the field network communication to monitor and control the process, incorporates operator actions
such as adjusting operator setpoints and control objectives, inter-controller communication for
coordinating control activities, provides information to the data collection system, and communicates with
maintenance and health monitoring systems.
Control strategies are executed in the controller which may implemented at the device level or in a
dedicated single loop or a multi-loop microprocessor based controller. This is a real time activity that has
a direct influence on the process being monitored and controlled. It is critical to maintain data integrity as
well as speed of response.
6.4.2.4
Safety Strategy Execution

6.4.2.5
Inter-Controller Communication
This activity involves communicating with other controllers within the system for coordination. Intercontroller communication facilitates process optimization by higher level decision making systems.
Inter-controller communication is implemented over a control network using different types of physical,
wireless or software links. This may be in the form of wires or fiber optic cables, input-output bus,
fieldbus, or wireless network. This is a real time activity which has a direct influence on the process being
monitored and controlled. It is critical to maintain data integrity as well as speed of response.
6.4.2.6
Operator Actions
This activity allows the operator to control the process by providing input to the controller(s) in the form of
setpoints and control activities. The amount of interaction between the operator and the controller is
determined by the level of automation implemented in the control system.
Operator actions are communicated to the controller(s) over a control network using different types of
physical, wireless or software links. This may be in the form of wires, fiber optic or wireless
communication. This is a real time activity which has a direct influence on the process being monitored
and controlled. It is critical to maintain data integrity as well as speed of response.
86
October 2005

6.4.2.7
DRAFT dISA-99.00.01
Control System Maintenance and Health Monitoring
This activity involves monitoring of diagnostic information and retention of calibration and maintenance
records for devices and equipment. This activity also includes maintenance and backup of control system
databases.
Maintenance and health monitoring system is connected to the controller and control strategy
development systems over a network using different types of physical, wireless or software links. This
may be in the form of wires, fiber optic or wireless communication. This may be an online activity or an
offline that indirectly influences the process being monitored and controlled.
6.4.2.8
Control Strategy Development
This is an activity that is influenced by historical data, maintenance and diagnostics data, and process
simulations.
The developed control strategy is downloaded to the controller(s) over a network using different types of
communication. This is an offline activity that indirectly influences the process being monitored and
controlled.
6.4.2.9
Control Strategy Simulation
This activity helps in the development and verification of control strategies. This may be as simple as
creating a process tie back or may involve the development of dynamic process models. Control strategy
simulation is also used for operator training.
Simulation of control strategies is implemented on hardware and software connected to the engineering
station, data collection system, maintenance and health monitoring system using different types of
communication. This is an offline activity that indirectly influences the process being monitored and
controlled.
6.4.2.10
Data Reporting
This activity involves collection of process data and reporting the data to different system for analysis and
decisions making. This data is used by operators to take control actions, by engineers to develop control
strategies, and by higher level manufacturing and enterprise systems for decision making.
Data collection is implemented on hardware and software connected to the other systems associated with
process control, operation, coordination and maintenance of manufacturing and control systems using
different types of physical, wireless or software links. This may be in the form of wires, fiber optic or
wireless communication. This is an offline activity that indirectly influences the process being monitored
and controlled.
6.4.3
Security Activity Model
Consider the below figure showing activities involved in defining and implementing security in M&CS.
Threats are assumed to continuously changing as well as clients, suppliers and assets may change from
time to time for the enterprise. Countermeasures for security concerns will also grow and be utilized in
the mitigation efforts within M&CS security.
October 2005
87
DRAFT dISA-99.00.01
6.5

Conceptual Models
Conceptual models are used to describe or illustrate a more abstract view of a system or its
characteristics.
6.5.1
Maturity Model
The Maturity Model is a conceptual model that provides a framework for assessing the relativity maturity
of a particular manufacturing and control systems security program.
6.5.1.1
Regions of Security Maturity
A general level of maturity of Manufacturing and Control System security can be assessed against
developmental regions of security maturity as described below. More detailed evaluation of security
maturity can be achieved by comparing achievements within portions of the Manufacturing and Control
System with the phases of maturity described in the following section.
Concept Region
Identification Phase
Concept Phase
Functional Analysis Region
Definition Phase
Implementation Region
Functional Design Phase

Detailed Design Phase
Construction Phase
Operations Region
Operations Phase
Recycle & Disposal Region
Disposal Phase
Dissolution Phase
6.5.1.2
Phases of Security Maturity
It is perfectly conceivable that portions of the enterprise, plant or control zones are at different phases of
maturity. There could be several reasons, among others: budgetary constraints, vulnerability/threat
assessments, schedules placed against risk analysis results, automation upgrades, plans for dissolution
or replacement, plans to sell a segment of the enterprise, or availability of other resources to complete
the security systems to a more mature phase.
88
October 2005

Phase
Identification Phase
DRAFT dISA-99.00.01
Description
Recognition of a need for protection of property, assets, services or
personnel
Security Master Planning is started
Concept Phase
Continuing Security Master Planning

Document assets, services and personnel needing some level of
protection
Document potential internal and external threats to the enterprise
Security mission, visions and values are established
Security Policies are developed for manufacturing process systems
and equipment, information systems, control systems and
personnel
Definition Phase
Continuing Security Master Planning

Security functional requirements are established for manufacturing
process systems and equipment, production systems, control
systems, information systems and personnel
Perform vulnerability assessment of facilities and associated
services against the list of potential threats
Legal requirements are discovered and determined for M&CS
Perform a risk analysis of potential vulnerabilities and threats
Categorize risks, potential impacts to the enterprise and potential
mitigations
Security work is segmented into controllable tasks and modules for
development of functional designs
Network functional definitions are established for security portions
of M&CS
Functional Design Phase
Security Master Planning is completed in this phase

Define manufacturing functional security requirements for
enterprise zones, plant zones, and control zones. Potential
activities and events are defined and documented to perform the
functional requirements and implement plans for a secured
enterprise.
Functional security organization and structure is defined.
Functions required in the implementation plan are defined.
Security zones, borders and access control portals are defined and
published.
Security Plans, Policies, Procedures are completed and issued.
Detailed Design Phase
Physical and logical systems are designed to perform the functional

requirements previously defined for security.
Training programs are in progress.
Implementation Plan is fully developed.
Asset management and change management programs are
initiated.
Borders and access control portals are designed for protected
zones.
October 2005
89
DRAFT dISA-99.00.01

Description
Phase
Construction Phase
Implementation Plan is executed: physical security equipment,

logical applications, configurations, personnel procedures are
installed to complete the secured zones and borders within the
enterprise.
Access control portal attributes are activated and maintained.
Training programs are completed.
Asset management and change management programs are
functional and operating.
Security system turnover packages are completed and ready for
acceptance by operations and maintenance personnel.
Operations Phase
Security equipment, services, applications and configurations are

completed and accepted by operations and maintenance.
Personnel are trained and continued training is provided on
security matters.
Maintenance monitors security portions of enterprise, plant or
control zones and keeps them functioning properly.
Asset management and change management is operational and
maintained.
Renovation or Disposal
Phase
Obsolete security systems are properly disassembled and

disposed.
Security borders are updated or recreated for zone protection.
Access control portals are created, redefined, reconfigured or
closed.
Personnel are briefed about changes in the security systems and
items along with the impact to associated security systems.
Dissolution Phase
Intellectual property is properly collected, documented and securely

archived or destroyed.
Access control portals and respective links are closed.
Personnel are briefed about dissolution of the security systems and
items along with the impact to remaining security systems.
6.5.2
Security Integrity Model
The Security Integrity Level Model is a Conceptual model that describes a method of differentiating parts
of a manufacturing and control system according to the level of security integrity required.
6.5.2.1
Security Information Classification Levels
Unclassified general information about assets, programs, production capacity, process capabilities
and products which are already available to public entities in magazines, reports, sales brochures or
product literature.
Internal Use plant or enterprise specific information about production, processes, product capabilities,
supply chain structures, shift schedules, material handling, security policies, security procedures and
such which are needed to maintain efficient production operations but is not intended for use outside the
enterprise, plant or control zone.
90
October 2005

DRAFT dISA-99.00.01
Confidential plant or enterprise specific information which may include competitive advantage
processes, intellectual property, product methodologies, scheduling forecasts, product production mixes
between plants, security programs, security schedules, security breaches or other information which
could have impacts on employee pools, security risk mitigations, marketing programs or sales.
Secret/Proprietary protected and guarded information necessary to only a few enterprise personnel
and restricted storage areas, which could jeopardize market share, competitive advantage, product
pricing, supply costs, lead to security disasters or other financial or economic concerns. Such information
and instructions are often encrypted in transactions and messages between assets.
6.5.2.2
Security Access and Control Levels
Unrestricted Control an asset, database, function can be manipulated from anywhere within its
physical and logical limitations
Intermediate Control an asset, database, function or portion of each can be manipulated from limited
sources
Global Control assets, databases and functions can be controlled throughout the enterprise regardless
of plant zone or control zone location.
Local Control assets, databases and functions can be controlled only within a specific plant zone or
control zone.
Restricted Control limited control is available for assets, databases or functions or a limited number of
assets, databases or functions can be controlled from specific control sources.
No Access an asset, database or function cannot be accessed by a source seeking information or
control.
Inquiry Access the asset, database or function can be assessed for information but not for changes or
control.
Modify Access an asset, database or function can be assessed by an authorized source for changes,
updates, reconfigurations or other such modifications except direct control of a process.
Extended Access an asset, database or function can be assessed by an authorized source for
changes, updates, reconfigurations or other such modifications including direct control and manipulation
of a process.
6.5.2.3
Security Integrity Attributes
Security integrity shall be defined in terms of a series of attributes that describe various types of integrity.
These attributes are listed in the following sections.
6.5.2.3.1
General Integrity Attributes
Threat assessments are maintained.
Vulnerability assessments are updated on a regular basis or when assets change.
Risk analysis of all vulnerability/threat assessment results has been completed.
Risk mitigations are installed and operating.
October 2005
91
DRAFT dISA-99.00.01

Security functionality addresses the results of the risk analysis and mitigations.
Residual risks are monitored for potential concerns.
Personnel are trained and can operate and maintain security systems.
Changes in assets, zones, borders, access control portals and conduits are managed.
Security systems perform as designed and security operations are repeatable.
Reliability, Availability and Maintainability are within acceptable levels for zones, borders, conduits
and access control portals
A backup operation is available for highest risk zones.
Recovery plans are available in case of intrusion damages or disasters.
6.5.2.3.2
Zone Integrity Attributes
Authorized personnel have access and unauthorized personnel do not have access.
Assets within the zone are identified along with potential vulnerabilities.
Threats against the zone are known and documented.
Risk analysis for the zone is maintained and protection requirement are active.
Security policies and procedures exist and are followed for each zone.
6.5.2.3.3
Border Integrity Attributes
Protection requirements on each side of the border are defined.
Access control portal locations and functionality are defined for the entire border.
Protection measures are activated to prevent unauthorized crossings of the border.
Attempted intrusions are detected and potential intruders are prevented from entering a protected
zone.
Protected information is kept from crossing the border into a lesser protected zone.
Intrusions, attempted intrusions and false intrusion alarms are measured, categorized and met with
an appropriate response.
6.5.2.3.4
Access Control Integrity Attributes
Information, device and personnel access/egress constraints are defined and operational.
Access control portals, including routers, switches and firewalls, are properly installed and
configured.
Acceptable information, devices and personnel can pass the access control portal,
92
October 2005

DRAFT dISA-99.00.01
Unacceptable information, devices or personnel cannot pass the access control portal and are
redirected to safe areas/zones or eliminated.
The portal(s) can handle the expected traffic traveling across the border.
The portal monitors for residual risk items along with mitigated risk items.
Unauthorized events at the portal can trigger additional security controls.
6.5.2.3.5
Conduit Integrity Attributes
Legitimate signals and transactions can occur throughout the M&CS
Encryption and decryption results in original transaction information.
Each penetration of a border occurs at an access control portal.
Unnecessary access control portals are closed or locked out.
Access control portals have zone protection measures activated.
Access control portals throughout the conduit can handle expected traffic.
Conduit branches can handle expected traffic on each branch.
Conduit zones are documented and protected against potential unauthorized access points.
October 2005
93
DRAFT dISA-99.00.01

Annex A - Application Case Studies

This section will be used to present case studies that illustrate various aspects of the standard. The exact
format of these studies has not yet been determined.
94
October 2005

DRAFT dISA-99.00.01
This page intentionally left blank
October 2005
95
DRAFT dISA-99.00.01

Update Record
This section is a record of the major changes to the working document. It is included for information
purposes and is not part of ISA 99.00.01.
Draft No.
Edit No.
Date
July 2004
August 2, 2004
In the conference call of July 28 the group revised the

outline (organization) of the document and made
writing assignments. This edit was created solely to
make the document structure consistent with the
revised outline.
October 5, 2004
This edit was compiled for review during the meeting

in Houston on October 5.
October 21, 2004
Incorporated the remainder of the material contributed

as part of the October 5 meeting.
December 2004
Updated several sections based on feedback received

on Edit 4.
January 2005

on Edit 5.
February 2005
Minor updates
April 2005
10
June 2005
August 2005
October 2005
96
Description
This is the first draft of the document. It was created
by compiling all available material and creating a
basic outline for review and discussion at the July 6,
2004 meeting in Redmond.
No formal edit 6 was issued.

on Edits 6, 7 and 8.
No formal edit 10 was created.
Restructured several sections to aid clarity.
Continued restructuring of content to prepare for
detailed review.

October 2005

DRAFT dISA-99.00.01
Developing and promulgating technically sound consensus standards and recommended

practices is one of ISA's primary goals. To achieve this goal the Standards and Practices
Department relies on the technical expertise and efforts of volunteer committee members,
chairmen, and reviewers.
ISA is an American National Standards Institute (ANSI) accredited organization. ISA

administers United States Technical Advisory Groups (USTAGs) and provides secretariat
support for International Electrotechnical Commission (IEC) and International Organization
for Standardization (ISO) committees that develop process measurement and control
standards. To obtain additional information on the Society's standards program, please write:
ISA
Attn: Standards Department
67 Alexander Drive
P.O. Box 12277
Research Triangle Park, NC 27709
ISBN
October 2005
97

dISA-99 00 01

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

dISA-99 00 01

Uploaded by

Copyright:

Available Formats

DRAFT dISA-99.00.

THIS DRAFT VERSION IS STRICTLY FOR REVIEW BY

Review of and comment on the draft standard;

Provide to others for review and comment;

Promotion of the standard; or

Informing and educating others about the standard.

In addition, all copies must reproduce a copyright notice as follows:

dISA-99.00.01 (Draft 2, Edit 3)

dISA-99.00.01 (Draft 2, Edit 3)

dISA-99.00.01 (Draft 2, Edit 3)

Eric Cosman ***

The Dow Chemical Company

Aspen Technology Inc.

Idaho National Laboratories

Procter & Gamble

Novo Nordisk A/S

dISA-99.00.01 (Draft 2, Edit 3)

Manufacturing and Control Systems Security

Common Terms and Definitions

Manufacturing and Control Systems Security Overview

Manufacturing and Control Systems Concepts

Conduits (Information Flows)

dISA-99.00.01 (Draft 2, Edit 3)

Manufacturing and Control Systems Security

dISA-99.00.01 (Draft 2, Edit 3)

Manufacturing and Control Systems Security

dISA-99.00.01 (Draft 2, Edit 3)

Manufacturing and Control Systems Security

ISA-99.00.01 (Draft 2, Edit 3)

Manufacturing and Control Systems Security

ISA 99.00.02 Establishing a Manufacturing and Control Systems Security Program

ISA 99.00.03 Operating a Manufacturing and Control Systems Security Program

ISA-99.00.01 (Draft 2, Edit 3)

Manufacturing and Control Systems Security

associated information systems such as advanced or multi-variable control, online optimizers,

ISA-99.00.01 (Draft 2, Edit 3)

Operational & Production

Direct Digital Control

Purdue reference Model Levels

Mfg Security Policies

Manufacturing and Control Systems Security

Figure 1 Functional Scope

The activity performed is critical to process safety;

ISA-99.00.01 (Draft 2, Edit 3)

Manufacturing and Control Systems Security

ISA-99.00.01 (Draft 2, Edit 3)

Manufacturing and Control Systems Security

The following documents contain material referenced in this standard.

dISA-99.00.01 (Draft 2, Edit 3)

Manufacturing and Control Systems Security

Common Terms and Definitions

The following terms have been identified.

access control center (ACC)

dISA-99.00.01 (Draft 2, Edit 3)

Manufacturing and Control Systems Security

access control list (ACL)

management procedures and constraints to prevent unauthorized access to a system [3]

an entity that attacks, or is a threat to, a system [3]

There are different commonly-recognized classes of attack:

dISA-99.00.01 (Draft 2, Edit 3)

Manufacturing and Control Systems Security

dISA-99.00.01 (Draft 2, Edit 3)

Manufacturing and Control Systems Security