s_990001_part_1_draft

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

Editor’s 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 Manufacturing and Control Systems Security 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

dISA-99.00.01 (Draft 2, Edit 3) 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: [email protected].

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 10-97, 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 user’s 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 user’s 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 dISA-99.00.01 (Draft 2, Edit 3)

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 Contributor Reviewer 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 √ Bob Webb √ Joe Weiss KEMA Consulting √

* Chairman ** Vice Chairman *** Editor **** Secretary

dISA-99.00.01 (Draft 2, Edit 3) October 2005

Manufacturing and Control Systems Security DRAFT dISA-99.00.01 Part 1: Concepts, Models and Terminology

Contents

1 Scope 10

1.1 Functional Elements 10 1.2 Activity-Based Criteria 11 1.3 Asset-Based Criteria 12

2 Normative References 13

2.1 Other References 13 3 Definitions 14

3.1 Common Terms and Definitions 14 3.2 Abbreviations 38

4 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

5 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

6 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 dISA-99.00.01 (Draft 2, Edit 3) 5

DRAFT dISA-99.00.01 Manufacturing and Control Systems Security Part 1: Concepts, Models and Terminology

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

6 dISA-99.00.01 (Draft 2, Edit 3) October 2005


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.



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.

1 The term “Manufacturing and Control Systems” is described in more detail in the Scope section.

8 ISA-99.00.01 (Draft 2, Edit 3) October 2005 Last saved 10/12/2005 4:02:00 PM by isa; Printed 10/12/2005 4:03:00 PM

Eric Cosman

We should try to be more clear that the purpose of Part 1 is to get everyone using the same terms for the same things. This points to the need for the glossary. Add more emphasis on this point.

Eric Cosman

Other questions: How do I define the needs and requirements of security system using consistent language.

Manufacturing and Control Systems Security ISA-99.00.01 Part 1: Concepts, Models and Terminology

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 ISA-99.00.01 (Draft 2, Edit 3) 9 Last saved 10/12/2005 4:02:00 PM by isa; Printed 10/12/2005 4:03:00 PM

Eric Cosman

Keep the models that define the problem in Part 1, and the models related to the business process in Part 2.

Eric Cosman

We have to make sure that the models and concepts introduced in Part 1 set the appropriate basis for Part 2. The process model (Plan/Do/Check/Act is a prominent feature and could be mentioned in the description.

Eric Cosman

How about metrics, and how to measure improvements? The original intent was to include measures and metrics. Let’s not lose this.

Eric Cosman

This part of the standard may be more normative than parts 1 and 2.


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 Manufacturing”2. 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.

2 Purdue Research Foundation, A Reference Model for Computer Integrated Manufacturing, 1989, ISBN 1-55617-225-7

3 ISO/IEC 17799, Information technology — Code of practice for information security management, 2000


Eric Cosman

Vulnerabilities exist if it is a cyber-based system, regardless of whether the network is automatic or “Manual”. We can define “cyber” in terms of some simple criteria like programmability, configurability, etc.

Eric Cosman

Is it our intent to apply this standard to thinks that are not network connected? Specifically, would we apply this to a standalone system?

Eric Cosman

The focus of SP-99 is the MES and layers below. We only address business networks in the context of their connection to control systems.

Manufacturing and Control Systems Security ISA-99.00.01 Part 1: Concepts, Models and Terminology

Com

mon

tech

nolo

gies

, pol

icie

s an

d pr

actic

es

Company Management Data Presentation

Company Management Information

Company Production Assignment Scheduling

Supervision

Company Production Scheduling Assignment

Operational & Production Supervision

Production Scheduling & Operational Management

Supervisor’s Console Inter-Area Coordination

Supervisor’s Console Supervisory Control

Operator’s Console Direct Digital Control

Level 5

Level 4

Level 3

Level 2

Level 1

Controllers

Process

IT S

ecur

ity P

olic

ies

and

Prac

tices

(ISO

177

99)

Mfg

Sec

urity

Pol

icie

san

d Pr

actic

es(IS

A 9

9)

Proc

ess

Safe

ty(IS

A 84

, IE

C 6

1508

, IE

C 6

1511

)

Purd

ue re

feren

ce M

odel

Leve

ls

Com

mon

tech

nolo

gies

, pol

icie

s an

d pr

actic

es




Supervision







Level 5

Level 4

Level 3

Level 2

Level 1

Controllers

Process

IT S

ecur

ity P

olic

ies

and

Prac

tices

(ISO

177

99)

Mfg

Sec

urity

Pol

icie

san

d Pr

actic

es(IS

A 9

9)

Proc

ess

Safe

ty(IS

A 84

, IE

C 6

1508

, IE

C 6

1511

)

Purd

ue re

feren

ce M

odel

Leve

ls

Com

mon

tech

nolo

gies

, pol

icie

s an

d pr

actic

es




Supervision







Level 5

Level 4

Level 3

Level 2

Level 1

Controllers

Process

IT S

ecur

ity P

olic

ies

and

Prac

tices

(ISO

177

99)

Mfg

Sec

urity

Pol

icie

san

d Pr

actic

es(IS

A 9

9)

Proc

ess

Safe

ty(IS

A 84

, IE

C 6

1508

, IE

C 6

1511

)

Purd

ue re

feren

ce M

odel

Leve

ls

Com

mon

tech

nolo

gies

, pol

icie

s an

d pr

actic

es




Supervision







Level 5

Level 4

Level 3

Level 2

Level 1

Controllers

Process

IT S

ecur

ity P

olic

ies

and

Prac

tices

(ISO

177

99)

Mfg

Sec

urity

Pol

icie

san

d Pr

actic

es(IS

A 9

9)

Proc

ess

Safe

ty(IS

A 84

, IE

C 6

1508

, IE

C 6

1511

)

Purd

ue re

feren

ce M

odel

Leve

ls

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) The activity performed is critical to process safety; b) The activity performed is critical to process reliability or availability; c) The activity performed is critical to process efficiency; d) The activity performed is critical to product quality; e) The activity performed is critical to maintaining regulatory compliance.

October 2005 ISA-99.00.01 (Draft 2, Edit 3) 11 Last saved 10/12/2005 4:02:00 PM by isa; Printed 10/12/2005 4:03:00 PM


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) The asset has significant economic value to the manufacturing or operating process; b) The asset performs a function critical to operation of the manufacturing or operating process; c) The asset, in sufficient quantity, is a significant portion of inventory; d) The asset is necessary as a material for product manufacturing; e) The asset represents intellectual property of the manufacturing or operating process; f) The asset is necessary to operate and maintain security for the manufacturing or operating process; g) The asset is necessary to protect personnel, contractors and visitors; h) The asset is a legal requirement, especially for security purposes; i) 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



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



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, http://www.cnss.gov/Assets/pdf/cnssi_4009.pdf

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


http://www.cnss.gov/Assets/pdf/cnssi_4009.pdf

http://www.sans.org/resources/glossary.php


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



− 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]



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



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]



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 user’s 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]



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]



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 network’s 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 data’s 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]



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 data’s 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]



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 variable-length; 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.



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]



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]



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



− 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]



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



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 entity’s 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]



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]



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



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]



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 program’s 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.



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.



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 product-specific 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]



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]



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.



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



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



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



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 non- manufacturing 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 dISA-99.00.01 (Draft 2, Edit 3) 41 Last saved 10/12/2005 4:02:00 PM by isa; Printed 10/12/2005 4:03:00 PM

DRAFT dISA-99.00.01 Manufacturing and Control Systems Security Part 1: Concepts, Models and Terminology 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/ISA-91.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 dISA-99.00.01 (Draft 2, Edit 3) October 2005 Last saved 10/12/2005 4:02:00 PM by isa; Printed 10/12/2005 4:03:00 PM

http://www.isa.org/standards/


4.3 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 nation’s 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 dISA-99.00.01 (Draft 2, Edit 3) 43 Last saved 10/12/2005 4:02:00 PM by isa; Printed 10/12/2005 4:03:00 PM

DRAFT dISA-99.00.01 Manufacturing and Control Systems Security Part 1: Concepts, Models and Terminology 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.

Priority

Manufacturing & Control Systems Traditional Information Technology

Availability

Integrity

Confidentiality

Confidentiality

Integrity

Availability

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 dISA-99.00.01 (Draft 2, Edit 3) October 2005 Last saved 10/12/2005 4:02:00 PM by isa; Printed 10/12/2005 4:03:00 PM

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.

Owners

Countermeasures

Vulnerabilities

Risk

AssetsThreats

Threat Agents

value

wish to minimize

to reduce

that maypossess

may be aware of

impose

that may bereduced by

to

to

that increasegive rise to

wish to abuse and/or may damage

thatexploit

leadingto

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.

4 ISO/IEC 15408 (provide detailed reference)


DRAFT dISA-99.00.01 Manufacturing and Control Systems Security Part 1: Concepts, Models and Terminology 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 organization’s 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.


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, re-engineering, 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


DRAFT dISA-99.00.01 Manufacturing and Control Systems Security Part 1: Concepts, Models and Terminology 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.

5 These risk factors were developed by Jonathan Pollett (PlantData) and presented at the UTC TELECOM 2005 conference.


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



Source: CNSS Instruction No. 4009, National Information Assurance Glossary, May 2003, http://www.cnss.gov/Assets/pdf/cnssi_4009.pdf

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.


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 organization’s 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 enterprise’s network.


DRAFT dISA-99.00.01 Manufacturing and Control Systems Security Part 1: Concepts, Models and Terminology 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 –


6 Reference Webopedia.com web page


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.


Matthew Franz

System Access is tied to the threats and the assumptions of about threats as well as the ability to exploit vulnerabilities and conduct attacks

DRAFT dISA-99.00.01 Manufacturing and Control Systems Security Part 1: Concepts, Models and Terminology 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 made-up 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.


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.


DRAFT dISA-99.00.01 Manufacturing and Control Systems Security Part 1: Concepts, Models and Terminology 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.


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.


DRAFT dISA-99.00.01 Manufacturing and Control Systems Security Part 1: Concepts, Models and Terminology 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.


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) Recommended network architectures b) Recommended firewall configuration c) User authorization and authentication d) Interconnecting different process control networks e) Domains and trust relationships f) Anti-virus management g) 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.


DRAFT dISA-99.00.01 Manufacturing and Control Systems Security Part 1: Concepts, Models and Terminology 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.



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

7 NASA/Science Office of Standards and Technology (NOST), http://ssdoo.gsfc.nasa.gov/nost/isoas/us04/defn.html


http://ssdoo.gsfc.nasa.gov/nost/isoas/us04/defn.html


Enterprise

Site Business Planning and Logistics

Site Manufacturing Operations and Control

Area Supervisory Control

Basic ControlSafety-

Critical

Process

Level 5

Level 4

Level 3

Level 2

Level 1

Level 0

Enterprise

Manufacturing

Control

Safety

Enterprise



Area Supervisory Control

Basic ControlSafety-

Critical

Process

Level 5

Level 4

Level 3

Level 2

Level 1

Level 0

Enterprise

Manufacturing

Control

Safety

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) enterprise accounting b) business to business interactions c) business to customer interactions d) 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,



c) overall goods in process and production inventory, d) quality control information, e) machinery and equipment use and life history, f) manpower use data, g) basic plant production schedule, h) preventive maintenance schedules i) optimum inventory levels of raw materials, energy sources, spare parts, and goods in progress j) 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) reporting on production b) data on production, inventory, manpower, raw materials, spare parts, and energy usage c) data collection and offline analysis to support engineering functions d) personnel functions such as work period statistics e) detailed production schedule f) 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) operator human-machine interface b) operator alarms and alerts c) supervisory control functions d) 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:



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.



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

Safety-Critical• Protective Systems• Safety Instrumented Systems

Level 0 - Field Instrumentation• Sensors, Transmitters, Control Valves• Field Networks (e.g. Foundation Fieldbus, Profibus)

Level 1 - Basic Process Control• Batch Controllers• Continuous Controllers• Discrete Controllers• Process Monitoring

Level 2 - Area Supervisory Control• Supervisory Controllers• Primary Operator Interface

Level 3 - Site Manufacturing Operations• Production Control• Optimizing Control• Process History• Windows Domains

Level 4 - Site Business Planning• Site Production Scheduling• Site AccountingSite Business Network

Process

ProtectiveSystem

ProtectiveSystem

ProductionControl

ProcessHistory

BatchControl

DiscreteControl

SupervisoryControl

Operator Interface

BatchControl

DiscreteControl

SupervisoryControl

Operator Interface

Process Control Network

WANRouter

Level 5 - Enterprise• Enterprise Financial Systems

ContinuousControl

ProcessMonitoring

SupervisoryControl

Operator Interface

Enterprise Network

OptimizingControl

Figure 5 – DCS Example using the General Reference Model



Enterprise



Area Control

Basic Control

Process

Safety-Critical

Level 5

Level 4

Level 3

Level 2

Level 1

Level 0

Area Control

Basic Control

Process

Safety-Critical

Enterprise Security Zone

Manufacturing Security Zone

Area Security Zone

Safety Security Zone

EnterpriseEnterprise





Area Control

Area Control

Basic ControlBasic

Control

ProcessProcess

Safety-CriticalSafety-Critical

Level 5

Level 4

Level 3

Level 2

Level 1

Level 0

Area Control

Area Control

Basic ControlBasic

Control

ProcessProcess

Safety-CriticalSafety-Critical

Enterprise Security Zone

Manufacturing Security Zone

Area Security Zone

Safety Security Zone

Figure 6 – Example Reference Model with Security Zones



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



Figure 7 – Process Manufacturing Control System Example

Operator

Technician Supervisor

Engineer

HMI

Field Device

Controller

Engineering Station

Plant Manager

PIMS

Recipe Manager

AMS Recipe Manager

Sales Finance Business Systems

Personnel Components



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

Wide Area Network (WAN)

Enterprise

Site

Control Equipment

May Contain

Site Network (LAN)Area

Area Control Networks (ACN)

May belinked by

Field I/O Network

May Contain

Lines, Units, Cells, Etc..

May belinked byMay Contain

May Contain May belinked by

MayContain

May belinked by

Process Control Network (PCN)

May Contain

May Contain

Internet

May belinked by

Site Information System

Area Information System

Data Center

Line Information System

MayContain

MayContain

MayContain

MayContain

Sensors Actuators

May Contain May Contain

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.



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 enterprise’s 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 site’s 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.



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


Enterprise

Control Center

May ContainMay belinked by

Field I/O Network

May Contain

May belinked byMay Contain

Process Control Network (PCN)May Contain

Remote Sites

May belinked by


May Contain

Maycoordinate

Supervisory Control Network

May belinked by

May belinked by

Control CenterInformation System

Data Center

MayContain

MayContain

May Contain

Site Information System

MayContain

Internet

Sensors Actuators


Control Equipment

Control Equipment

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.



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 belinked by

Control Equipment

Vehicle Communication Network

May Contain

Sensors Actuators

Vehicle


Process Control Network (PCN)

May Contain

May Contain

Vehicle Information System


Enterprise

Control Center

Control Equipment


May belinked by

May Contain


May belinked by

Data Center

MayContain

MayContain

MaycoordinateMay

Contain

Internet


Field I/O Network

Control CenterInformation System

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.



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



MainframeWorkstationLaptop computer Server Server

IBM AS/400Data

ServerFile/PrintServer

App.Server

WorkstationLaptop computer

Controller Controller

I/O I/O

App ServerData ServerMaint. Server

Firewall

Router

IBM AS/400Data


App.Server



I/O I/O


Firewall

Router

IBM AS/400Data


App.Server



I/O I/O


Firewall

Router

Enterprise Zone

Plant A Zone Plant B Zone Plant C Zone

Plant A Control Zone Plant B Cotrol Zone Plant C Control Zone

Figure 11 – Multi-plant Zone Model

The same corporate architecture could be grouped into separate Zones as in the following figure:


IBM AS/400Data


App.Server



I/O I/O


Firewall

Router

IBM AS/400Data


App.Server



I/O I/O


Firewall

Router

IBM AS/400Data


App.Server



I/O I/O


Firewall

Router

Enterprise Zone



Figure 12 – Separate Zones

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



6.3.1.1.2 Zone Attributes

Each Zone has a set of characteristics and security requirements that are its attributes. These take the form of:

a) Policies for the Zone b) The inventory of the assets included in the Zone c) The access requirements and how access is controlled d) The threats and vulnerabilities of the Zone e) The permitted (or actual) technology used to implement systems within the Zone f) 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) The Zone scope b) The organizational structure and responsibilities to enforce the security policy c) The Risks associated with the Zone d) The Security Strategy to meet the required goals e) The security measures to be enforced f) The types of activities that are permitted within the Zone g) The types of communication allowed access to the Zone h) 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.



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 Zone Vulnerability Counter Measures



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



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:


IBM AS/400Data


App.Server



I/O I/O


Firewall

Router

IBM AS/400Data


App.Server



I/O I/O


Firewall

Router

IBM AS/400Data


App.Server



I/O I/O


Firewall

Router

Enterprise Zone



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) Policies for the Conduit b) The inventory of the assets included in the conduit c) The access requirements and how access is controlled d) The threats and vulnerabilities of the conduit e) The permitted (or actual) technology used to implement the conduit f) A change management process to maintain accuracy of the assets within a conduit

g) Zones connected

6.3.1.2.2.1 Conduit Policy



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




6.3.1.2.4 Communication Channels




6.4 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 & LogisticsLevel 4 (Plant Production Scheduling, Operational Management, etc.)

Manufacturing Operations & Control

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.

(Dispatching Production, Detailed Production Scheduling, Reliabi lity Assurance, etc.)

Engineering Operations DataCollection

Control

Coordination Maintenance

Safety

Level 3

Level 2

Level 1

Level 0 Measurement Actuation



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.



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.



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.



6.4.2 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:Manufacturing Operations

Addressed byANSI/ISA-95

Data Reporting

Operator Actions

Control Strategy

ExecutionInter-ControllerCommunication

Control Strategy

Development

Field Network Communication

Control System Maintenance &

Health Monitoring

Control Strategy

Simulation

Safety Strategy Execution

Safety Network Communication

Safety Level

Levels 0-2

Level 3

Figure 15 – Activity Model



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



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



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.

Identification Phase Concept Region

Concept Phase

Functional Analysis Region Definition Phase

Functional Design Phase

Detailed Design Phase

Implementation Region

Construction Phase

Operations Region Operations Phase

Disposal Phase Recycle & Disposal Region

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.



Phase Description Identification Phase 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.



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



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.



− 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,



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



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.



This page intentionally left blank



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 Description 1 1 July 2004 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.

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

1 3 October 5, 2004 This edit was compiled for review during the meeting in Houston on October 5.

1 4 October 21, 2004 Incorporated the remainder of the material contributed as part of the October 5 meeting.

1 5 December 2004 Updated several sections based on feedback received on Edit 4.

1 6 No formal edit 6 was issued. 1 7 January 2005 Updated several sections based on feedback received

on Edit 5. 1 8 February 2005 Minor updates 1 9 April 2005 Updated several sections based on feedback received

on Edits 6, 7 and 8. 1 10 No formal edit 10 was created. 2 1 June 2005 Restructured several sections to aid clarity. 2 2 August 2005 Continued restructuring of content to prepare for

detailed review. 2 3 October 2005



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


s_990001_part_1_draft

Documents