SlideShare a Scribd company logo
Using The Isaiec 62443 Standard To Secure Your
Control Systems Course Ic32e Online Version 21
Participant Noteset Volume Ii Wally Magda
download
https://ebookbell.com/product/using-the-isaiec-62443-standard-to-
secure-your-control-systems-course-ic32e-online-
version-21-participant-noteset-volume-ii-wally-magda-10666946
Explore and download more ebooks at ebookbell.com
Here are some recommended products that we believe you will be
interested in. You can click the link to download.
Using The Isaiec 62443 Standard To Secure Your Control Systems Course
Ic32e Online Version 21 Participant Noteset Volume I Wally Magda
https://ebookbell.com/product/using-the-isaiec-62443-standard-to-
secure-your-control-systems-course-ic32e-online-
version-21-participant-noteset-volume-i-wally-magda-10666948
Using The Iso 56002 Innovation Management System A Practical Guide For
Implementation And Building A Culture Of Innovation H James Harrington
Sid Benraouane
https://ebookbell.com/product/using-the-iso-56002-innovation-
management-system-a-practical-guide-for-implementation-and-building-a-
culture-of-innovation-h-james-harrington-sid-benraouane-46774092
Using The Socratic Method In Counseling A Guide To Channeling Inborn
Knowledge 1st Edition Katarzyna Peoples
https://ebookbell.com/product/using-the-socratic-method-in-counseling-
a-guide-to-channeling-inborn-knowledge-1st-edition-katarzyna-
peoples-50472516
Using The Results Of A National Assessment Of Educational Achievement
National Assessments Of Educational Achievement Thomas Kellaghan
https://ebookbell.com/product/using-the-results-of-a-national-
assessment-of-educational-achievement-national-assessments-of-
educational-achievement-thomas-kellaghan-2002708
Using The Internet For Active Teaching And Learning 1st Edition Steven
C Mills
https://ebookbell.com/product/using-the-internet-for-active-teaching-
and-learning-1st-edition-steven-c-mills-2193298
Using The Agricultural Environmental And Food Literature Books In
Library And Information Science 1st Edition Barbara S Hutchinson
https://ebookbell.com/product/using-the-agricultural-environmental-
and-food-literature-books-in-library-and-information-science-1st-
edition-barbara-s-hutchinson-2196744
Using The Microsoft Office Web Apps Mcfedries Paul
https://ebookbell.com/product/using-the-microsoft-office-web-apps-
mcfedries-paul-21983910
Using The Asus Eee Pc Lawrence Bill
https://ebookbell.com/product/using-the-asus-eee-pc-lawrence-
bill-22136892
Using The Iphone Covers Iphone 3g 3gs And 4 Running Ios 4 Mcfedries
https://ebookbell.com/product/using-the-iphone-covers-iphone-3g-3gs-
and-4-running-ios-4-mcfedries-22136894
Using The Isaiec 62443 Standard To Secure Your Control Systems Course Ic32e Online Version 21 Participant Noteset Volume Ii Wally Magda
Using the ISA/IEC 62443 Standard to
Secure Your Control Systems
Course IC32E (Online), Version 2.1
Participant Noteset
Volume II
Copyright © 2017, ISA
67 T.W. Alexander Drive
Research Triangle Park, NC 27709 USA
All rights reserved. This book or any portion thereof
may not be reproduced or used in any manner whatsoever
without the express written permission of the publisher.
The unauthorized reproduction or distribution of a copyrighted work is illegal. Criminal copyright
infringement, including infringement without monetary gain, is investigated by the FBI and is punishable
by fines and federal imprisonment.
ISA Cyber Instruction – IC32E
Online Instructor-Led Course
Cyber Security for Automation, Control and SCADA Systems
This online/self-study course focuses on the issues involved in developing a cyber security program for
industrial automation and control systems including risk assessment, awareness of cyber threats and
exploits and the use of ‘countermeasures’ to reduce risk and/or mitigate the consequences of a
successful cyber-attack. This course will aid engineering personnel with responsibility for plant/process
automation systems in identifying potential vulnerabilities and implementing changes to improve the
cyber security of their critical process automation systems.
The course is divided into twelve (12) separate modules, with a recommended one module or two module
per week for completion. However, students may work at their own pace, as long as they cover the
material by the indicated review dates.
Various learning techniques will be provided to cover the weekly course areas including: pre-recorded
instructor presentations, additional resources, homework assignments, reading assignments, as well as
live Q&A debrief instructor sessions. Refer to your detailed course syllabus, which is provided with your
course materials, for further information/instructions.
Course Schedule
Pre-Survey
Students will be asked to take a pre-survey, which includes questions related to the subject matter areas.
Answers will be provided for students to assess their knowledge, prior to beginning the course materials.
Module 1: Introduction to Control Systems Security and the ISA/IEC 62443
Standards
Provides a basic introduction to control system cyber security and the ISA/IEC 62443 standards. Discussion
of trends, regulations, industry standards and best practices, common myths, the ISA 99 committee, and the
structure of the ISA 62443 standard. Topics include: Self-assessment of your Control Systems Security
knowledge, Trends in control system cybersecurity, Potential Impacts, Five common myths regarding IACS
Security, Regulations and Standards, ISA99 committee work
Module 2: Terminology, Concepts, Models and Metrics
Covers the material in ISA 62443-1-1 (published as ISA-99.00.01:2007) that forms the basis for the ISA
62443 series of standards. Topics include: Difference between IT and IACS, Security Objectives, Defense-
in-Depth, Risk Assessment, Policies, Zones & Conduits, Security Levels and the Security Lifecycle Models
Module 3: Industrial Networking Basics L1-L3
Provides a basic introduction to networking with a focus on the application of Ethernet in the industrial
environment. Topics include: Types of networks, OSI reference model, Network Devices, Network
Protocols, Network Tools built into Operating Systems.
Module 4: Industrial Networking Basics L4-L7
Builds on the previous module and covers networking with a focus on the upper layers of the OSI reference
model, problems with the OSI model, network discovery, and security auditing tools in the industrial
environment. Topics include: Encapsulating data, OSI reference model, Network Devices, Network
Protocols.
Module 5: Network Security Basics 101
Provides a basic introduction to network security. Topics include: Security Appliances, Network
Segmentation, Encryption, Secure Protocols and Intrusion Detection. Topics include: Why address
security? Firewalls, Network Segmentation Architectures, Encryption, Intrusion Detection, Monitoring
Network Traffic.
Module 6: Industrial Protocols
Covers at a high level the structure and application of common industrial protocols such as MODBUS,
PROFIBUS, OPC and CIP (EtherNet/IP). Topics include: What is a protocol? Multitude of Industrial
Protocols, Ports in use.
Module 7: Establishing an Industrial Automation and Control Systems Security Program
Covers the material in ISA 62443-2-1 (published as ISA-99.02.01:2009) that specifies the elements and
requirements of an IACS Cyber Security Management System (CSMS). Topics include: Six top level
activities, Common pitfalls, Risk Analysis, Security Policy, Organization and Awareness, Personnel
security, Physical & Environmental Security, Network Segmentation, Access Control, Change
Management, Patch and Anti-virus management, Information management, Incident Response and
Disaster Recover Planning, Compliance Monitoring, and Program Maintenance.
Module 8: Security Risk Assessment and System Design
Covers Security Level definitions and Foundational Requirements that establish a basis for the
requirements in scoping an IACS assessment, establishing zones & conduits, analyzing the security risk for
each zone, assigning a security level target to each zone and verifying the design satisfies the security
level target. Topics include: Definitions, Risk Equation, Cyber Risk Reduction Factor, Basic Security
analysis tools, Identification of Zones and Conduits
Module 9: Intro to the IACS Cybersecurity Lifecycle
Short jaunt into the Assess, Develop & Implement and Maintain phases of the IACS Cybersecurity
Lifecycle. These phases are covered more in depth in ISA’s IC33, IC34 & IC37 courses. Topics include:
Cyber Security Life Cycle diagram, Phases, Continuous processes
Module 10: Security Risk Assessment and System Design
Creating a secure product out of the box is only a small piece of the security puzzle. Asset Owners,
Integrators and Suppliers all have a role. This module covers how IEC 62443-2-4 specifies requirements
IACS service providers can offer to the asset owner during integration and maintenance activities of an
Automation Solution. Topics include: IACS Patching, Asset Owner Requirements, Product
Supplier/Service Provider Requirements, Malicious Code Protection
Module 11: Developing Secure Products and Systems
Overview of component tier Product Development Requirements and Technical Security Requirements for
IACS that are Product supplier centric. Topics include: Component tier standards ISA-62443-4-1 & ISA-
62443-4-2, Primary & Secondary goals, ISA 62443 relationships, ISA Security Compliance Institute (ISCI),
ISASecure™
Module 12: Evolving Security Standards and Practices
Standards are voluntary documents unless there is a requirement to use them. In this module, we look at
the continuously evolving industrial security regulatory landscape. The only constant is change! Topics
include: Normative and Informative elements, NIST Cyber Security Framework, ISA-62443-2-1
requirement to monitor and evaluate applicable legislation relevant to cyber security, Standards
Development Organizations (SDOs)
Post-Survey
Students will be asked to take a post-survey, which includes questions related to the subject matter
areas. Answers will be provided for students to assess their knowledge, prior to beginning the course
materials.
Final Examination
Learn more with ISA’s hands-on
Portable Training Labs!
Our hands-on labs are ready to ship to your facility.
Offering state-of-the-art equipment and expert
instruction, ISA Onsite Training brings
automation training directly to you.
Learn more at
www.isa.org/OnsiteTraining.
Emerson Process
Management-
Rosemount Measurement
Wade
Associates, Inc.
ISA Training Equipment Donors
ISA would like to thank the following companies for donating equipment for use in our hands-on training labs.
By donating equipment, these companies have increased their name recognition within the industry while
helping ISA continue its efforts to offer superior automation and control training.
EP30-6408-0516
Standards
Standards
Standards
Standards
Standards
Standards
AMERICAN NATIONAL STANDARD
ANSI/ISA–62443-1-1 (99.01.01)–2007
(formerly designated as ANSI/ISA-99.00.01-2007)
Security for Industrial Automation
and Control Systems
Part 1-1: Terminology, Concepts, and Models
Approved 29 October 2007
ANSI/ISA–62443-1-1 (99.01.01)–2007
(formerly designated as ANSI/ISA-99.00.01-2007)
Security for Industrial Automation and Control Systems
Part 1-1: Terminology, Concepts, and Models
ISBN: 978-1-934394-37-3
Copyright © 2007 by ISA. All rights reserved. Not for resale. Printed in the United States of America. No
part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by
any means (electronic mechanical, photocopying, recording, or otherwise), without the prior written
permission of the Publisher.
ISA
67 Alexander Drive
P. O. Box 12277
Research Triangle Park, NC 27709 USA
– 3 – ANSI/ISA–62443-1-1 (99.01.01)–2007
Copyright 2007 ISA. All rights reserved.
Preface
This preface, as well as all footnotes and annexes, is included for information purposes and is not part of
ANSI/ISA–62443-1-1 (99.01.01)–2007.
This document has been prepared as part of the service of ISA, toward a goal of uniformity in the field of
instrumentation. To be of real value, this document should not be static but should be subject to periodic
review. Toward this end, the Society welcomes all comments and criticisms and asks that they be
addressed to the Secretary, Standards and Practices Board; ISA; 67 Alexander Drive; P. O. Box 12277;
Research Triangle Park, NC 27709; Telephone (919) 549-8411; Fax (919) 549-8288; E-mail:
standards@isa.org.
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.
ANSI/ISA–62443-1-1 (99.01.01)–2007 – 4 –
Copyright 2007 ISA. All rights reserved.
The following participated as voting members of ISA99 in the development of this standard:
NAME COMPANY
B. Singer, Chair Fluid IQs
R. Webb, Managing Director Consultant
E. Cosman, Lead Editor The Dow Chemical Co.
R. Bhojani Bayer Technology Services
M. Braendle ABB
D. Brandl BR&L Consulting, Inc.
E. Byres Byres Security, Inc.
R. Clark Invensys Systems, Inc. / Wonderware
A. Cobbett BP Process Control Digital Protection
J. Dalzon ISA France
T. Davis Citect
R. Derynck Verano, Inc.
R. Evans Idaho National Laboratory
R. Forrest The Ohio State University
J. Gilsinn NIST/MEL
T. Glenn Yokogawa
T. Good E I DuPont De Nemours & Co.
E. Hand Sara Lee Food & Beverage
M. Heard Eastman Chemical Co.
D. Holstein OPUS Publishing
C. Hoover Rockwell Automation
B. Huba Emerson Processing Management
M. Lees Schering-Plough Corp.
C. Mastromonico Westinghouse Savannah River Co.
D. Mills Procter & Gamble Co.
G. Morningstar Cedar Rapids Water Dept.
A. Nangia 3M
J. Nye ExxonMobil Research and Engineering
T. Phinney Honeywell ACS Adv Tech Lab
E. Rakaczky Invensys Systems Canada Inc.
C. Sossman WGI-W Safety Management Solutions LLC
L. Steinocher Fluor Enterprises, Inc.
I. Susanto Chevron Information Technology Co.
B. Taylor The George Washington University
D. Teumim Teumim Technical LLC
D. Tindill Matrikon Inc.
L. Uden Lyondell Chemical Co.
J. Weiss Applied Control Solutions, LLC
M. Widmeyer Consultant
L. Winkel Siemens SG
The following served as active members of ISA99 Working Group 3 in the preparation of this standard:
Name Company Contributor Reviewer
E. Cosman, Lead Editor The Dow Chemical Co. 
J. Bauhs Cargill 
R. Bhojani Bayer 
M. Braendle ABB 
D. Brandl BR&L Consulting, Inc. 
– 5 – ANSI/ISA–62443-1-1 (99.01.01)–2007
Copyright 2007 ISA. All rights reserved.
M. Bush Rockwell Automation 
E. Byres Byres Security, Inc. 
A. Capel Comgate Engineering Ltd. 
L. Capuder Aramco 
R. Clark Invensys Wonderware 
A. Cobbett BP 
J. Dalzon ISA France 
H. Daniel Consultant 
A. Daraiseh Saudi Aramco 
R. Derynck Verano, Inc. 
G. Dimowo Shell 
D. Elley Aspen Technology, Inc. 
R. Evans Idaho National Laboratories 
J. Gilsinn NIST/MEL 
T. Glenn Yokogawa 
T. Good DuPont 
R. Greenthaler TXU Energy 
E. Hand Sara Lee Food & Beverage 
D. Holstein OPUS Publishing 
C. Hoover Rockwell Automation 
M. Jansons Siemens 
R. Lara Invensys 
J. Lellis Aspen Technology, Inc. 
D. Mills Procter & Gamble Co. 
C. Muehrcke Cyber Defense Agency 
M. Naedele ABB 
J. Nye ExxonMobil 
R. Oyen Consultant  
D. Peterson Digital Bond 
T. Phinney Honeywell 
J. Potter Emerson 
E. Rakaczky Invensys 
J. Seest Novo Nordisk A/S 
B. Singer, ISA99 Chair Fluid IQs 
L. Steinocher Fluor Enterprises, Inc. 
I. Susanto Chevron 
E. Tieghi ServiTecno SRL 
R. Webb Consultant 
ANSI/ISA–62443-1-1 (99.01.01)–2007 – 6 –
Copyright 2007 ISA. All rights reserved.
J. Weiss Applied Control Solutions LLC 
L. Winkel Siemens SG 
The ISA Standards and Practices Board approved the first edition of this standard for publication on 27
September 2007:
NAME COMPANY
T. McAvinew, Chair Jacobs Engineering Group
M. Coppler Ametek, Inc.
E. Cosman The Dow Chemical Co.
B. Dumortier Schneider Electric
D. Dunn Aramco Services Co.
J. Gilsinn NIST/MEL
W. Holland Consultant
E. Icayan ACES, Inc.
J. Jamison Consultant
K. Lindner Endress & Hauser Process Solutions AG
V. Maggioli Feltronics Corp.
A. McCauley, Jr. Chagrin Valley Controls, Inc.
G. McFarland Emerson Process Management
R. Reimer Rockwell Automation
N. Sands E I du Pont
H. Sasajima Yamatake Corp.
T. Schnaare Rosemount, Inc.
J. Tatera Consultant
I. Verhappen MTL Instrument Group
R. Webb Consultant
W. Weidman Parsons Energy & Chemicals Group
J. Weiss Applied Control Solutions LLC
M. Widmeyer Consultant
M. Zielinski Emerson Process Management
– 7 – ANSI/ISA–62443-1-1 (99.01.01)–2007
Copyright 2007 ISA. All rights reserved.
Table of Contents
Foreword...................................................................................................................... 11
Introduction ................................................................................................................. 13
1 Scope ..................................................................................................................... 15
2 Normative References .......................................................................................... 18
3 Definitions.............................................................................................................. 19
3.1 Introduction...................................................................................................................................19
3.2 Terms ...........................................................................................................................................19
3.3 Abbreviations ................................................................................................................................32
4 The Situation ......................................................................................................... 33
4.1 General.........................................................................................................................................33
4.2 Current Systems...........................................................................................................................33
4.3 Current Trends .............................................................................................................................34
4.4 Potential Impact............................................................................................................................34
5 Concepts................................................................................................................ 36
5.1 General.........................................................................................................................................36
5.2 Security Objectives .......................................................................................................................36
5.3 Defense in Depth..........................................................................................................................37
5.4 Security Context ...........................................................................................................................37
5.5 Threat-Risk Assessment ..............................................................................................................39
5.6 Security Program Maturity ............................................................................................................46
5.7 Policies .........................................................................................................................................52
5.8 Security Zones..............................................................................................................................57
5.9 Conduits........................................................................................................................................58
5.10 Security Levels ..........................................................................................................................60
5.11 Security Level Lifecycle.............................................................................................................64
6 Models.................................................................................................................... 69
6.1 General.........................................................................................................................................69
6.2 Reference Models.........................................................................................................................69
ANSI/ISA–62443-1-1 (99.01.01)–2007 – 8 –
Copyright 2007 ISA. All rights reserved.
6.3 Asset Models ................................................................................................................................73
6.4 Reference Architecture.................................................................................................................78
6.5 Zone and Conduit Model ..............................................................................................................78
6.6 Model Relationships .....................................................................................................................89
– 9 – ANSI/ISA–62443-1-1 (99.01.01)–2007
Copyright 2007 ISA. All rights reserved.
Figures
Figure 1 – Comparison of Objectives..........................................................................................................36
Figure 2 – Context Element Relationships..................................................................................................38
Figure 3 – Context Model............................................................................................................................38
Figure 4 – Integration of Business and IACS Cyber Security......................................................................47
Figure 5 – Cyber Security Level over Time .................................................................................................48
Figure 6 – Integration of Resources to Develop the CSMS ........................................................................49
Figure 7 – Conduit Example........................................................................................................................59
Figure 8 – Security Level Lifecycle..............................................................................................................65
Figure 9 – Security Level Lifecycle – Assess Phase...................................................................................66
Figure 10 – Security Level Lifecycle – Implement Phase............................................................................67
Figure 11 – Security Level Lifecycle – Maintain Phase...............................................................................68
Figure 12 – Reference Model for ISA99 Standards ....................................................................................70
Figure 13 – SCADA Reference Model ........................................................................................................70
Figure 14 – Process Manufacturing Asset Model Example ........................................................................74
Figure 15 – SCADA System Asset Model Example....................................................................................75
Figure 16 – Reference Architecture Example .............................................................................................78
Figure 17 – Multiplant Zone Example..........................................................................................................80
Figure 18 – Separate Zones Example ........................................................................................................81
Figure 19 – SCADA Zone Example.............................................................................................................82
Figure 20 – SCADA Separate Zones Example ...........................................................................................83
Figure 21 – Enterprise Conduit ...................................................................................................................86
Figure 22 – SCADA Conduit Example ........................................................................................................87
Figure 23 – Model Relationships.................................................................................................................89
ANSI/ISA–62443-1-1 (99.01.01)–2007 – 10 –
Copyright 2007 ISA. All rights reserved.
Tables
Table 1 – Types of Loss by Asset Type ......................................................................................................41
Table 2 – Security Maturity Phases.............................................................................................................49
Table 3 – Concept Phase............................................................................................................................50
Table 4 – Functional Analysis Phase ..........................................................................................................50
Table 5 – Implementation Phase ................................................................................................................51
Table 6 – Operations Phase........................................................................................................................51
Table 7 – Recycle and Disposal Phase.......................................................................................................52
Table 8 – Security Levels ............................................................................................................................60
– 11 – ANSI/ISA–62443-1-1 (99.01.01)–2007
Copyright 2007 ISA. All rights reserved.
Foreword
This is the first in a series of ISA standards that addresses the subject of security for industrial automation
and control systems. The focus is on the electronic security of these systems, commonly referred to as
cyber security. This Part 1 standard describes the basic concepts and models related to cyber security.
This standard is structured to follow ISO/IEC directives part 2 for standards development as closely as
possible. An introduction before the first numbered clause describes the range of coverage of the entire
series of standards. It defines industrial automation and control systems and provides various criteria to
determine whether a particular item is included within the scope of the standards.
Clause 1 defines the scope of this standard.
Clause 2 lists normative references that are indispensable for the application of this document.
Clause 3 is a list of terms and definitions used in this standard. Most are drawn from established
references, but some are derived for the purpose of this standard.
Clause 4 provides an overview of the current situation with respect to the security of industrial automation
and control systems, including trends and their potential impact.
Clause 5 contains a broad description of the subject and the basic concepts that establish the scope of
industrial automation and control systems security. Many of these concepts are well established within the
security discipline, but their applicability to industrial control systems may not have been clearly described.
In some cases the nature of industrial control systems leads to an interpretation that may be different from
that used for more general information technology applications.
Clause 6 describes a series of models that are used to apply the basic concepts of security for industrial
automation 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 control system applications.
The ISA99 Series
Standards in the ISA99 series address the application of these concepts and models in areas such as
security program definition and minimum security requirements. The series includes the following
standards.
1. ISA99.00.01 – Part 1: Terminology, Concepts and Models
Part 1 (this standard) establishes the context for all of the remaining standards in the series by
defining a common set of terminology, concepts and models for electronic security in the industrial
automation and control systems environment.
2. ISA99.00.02 – Part 2: Establishing an Industrial Automation and Control System Security
Program
Part 2 will describe the elements of a cyber security management system and provide guidance for
their application to industrial automation and control systems.
3. ISA99.00.03 – Part 3: Operating an Industrial Automation and Control System Security Program
Part 3 will address how to operate a security program after it is designed and implemented. This
includes definition and application of metrics to measure program effectiveness.
4. ISA99.00.04 – Part 4: Technical Security Requirements for Industrial Automation and Control
Systems
ANSI/ISA–62443-1-1 (99.01.01)–2007 – 12 –
Copyright 2007 ISA. All rights reserved.
Part 4 will define the characteristics of industrial automation and control systems that differentiate
them from other information technology systems from a security point of view. Based on these
characteristics, the standard will establish the security requirements that are unique to this class of
systems.
The relationship between the standards in this series is shown in the following diagram:
Relationships of the ISA99 Standards
In addition, the ISA99 committee has produced two technical reports on the subject of electronic security
within the industrial automation and control systems environment.
1. ANSI/ISA-TR99.00.01-2007 – Technologies for Protecting Manufacturing and Control Systems
Technical Report 1, updated from the original 2004 version, describes various security technologies in
terms of their applicability for use with industrial automation and control systems. This technical report
will be updated periodically to reflect changes in technology.
2. ANSI/ISA-TR99.00.02-2004 – Integrating Electronic Security into the Manufacturing and Control
Systems Environment
Technical Report 2 describes how electronic security can be integrated into industrial automation and
control systems. The contents of this technical report will be superseded with the completion of the
Part 2 standard.
ISA99.00.02 – Part 2:
. .
Establishing an Industrial Automation and Control
System Security Program
ISA99.00.03 – Part 3:
Operating an Industrial Automation and Control
System Security Program
ISA99.00.04 – Part 4:
Technical Security Requirements for Industrial
Automation and Control Systems
ISA99.00.01– Part 1:
. .
Terminology, Concepts and Models
– 13 – ANSI/ISA–62443-1-1 (99.01.01)–2007
Copyright 2007 ISA. All rights reserved.
Introduction
The subject of this standard is security for industrial automation and control systems. In order to address a
range of applications (i.e., industry types), each of the terms in this description have been interpreted very
broadly.
The term industrial automation and control systems (IACS) includes control systems used in
manufacturing and processing plants and facilities, building environmental control systems, geographically
dispersed operations such as utilities (i.e., electricity, gas, and water), pipelines and petroleum production
and distribution facilities, and other industries and applications such as transportation networks, that use
automated or remotely controlled or monitored assets.
The term security is considered here to mean the prevention of illegal or unwanted penetration, intentional
or unintentional interference with the proper and intended operation, or inappropriate access to
confidential information in industrial automation and control systems. Electronic security, the particular
focus of this standard, includes computers, networks, operating systems, applications and other
programmable configurable components of the system.
The audience for this standard includes all users of industrial automation and control systems (including
facility operations, maintenance, engineering, and corporate components of user organizations),
manufacturers, suppliers, government organizations involved with, or affected by, control system cyber
security, control system practitioners, and security practitioners. Because mutual understanding and
cooperation between information technology (IT) and operations, engineering, and manufacturing
organizations is important for the overall success of any security initiative, this standard is also a reference
for those responsible for the integration of industrial automation and control systems and enterprise
networks.
Typical questions addressed by this Part 1 standard include:
a) What is the general scope of application for “industrial automation and control systems security”?
b) How can the needs and requirements of a security system be defined using consistent
terminology?
c) What are 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?
d) How can the components of an industrial automation and control system be grouped or classified
for the purpose of defining and managing security?
e) What are the different electronic security objectives for control system applications?
f) How can these objectives be established and codified?
Each of these questions is addressed in detail in subsequent clauses of this standard.
Copyright 2007 ISA. All rights reserved.
This page intentionally left blank.
– 15 – ANSI/ISA–62443-1-1 (99.01.01)–2007
Copyright 2007 ISA. All rights reserved.
1 Scope
This standard defines the terminology, concepts and models for industrial automation and control systems
(IACS) security. It establishes the basis for the remaining standards in the ISA99 series.
To fully articulate the systems and components the ISA99 standards address, the range of coverage may
be defined and understood from several perspectives, including:
a) range of functionality included
b) specific systems and interfaces
c) criteria for selecting included activities
d) criteria for selecting included assets
Each of these is described in the following paragraphs.
Functionality Included
The scope of this standard can be described in terms of the range of functionality within an organization’s
information and automation systems. This functionality is typically described in terms of one or more
models.
This standard is focused primarily on industrial automation and control, as described in a reference model
(see clause 6). Business planning and logistics systems are not explicitly addressed within the scope of
this standard, although the integrity of data exchanged between business and industrial systems is
considered.
Industrial automation and control includes the supervisory control components typically found in process
industries. It also includes SCADA (supervisory control and data acquisition) systems that are commonly
used by organizations that operate in critical infrastructure industries. These include:
a) electricity transmission and distribution
b) gas and water distribution networks
c) oil and gas production operations
d) gas and liquid transmission pipelines
This is not an exclusive list. SCADA systems may also be found in other critical and non-critical
infrastructure industries.
ANSI/ISA–62443-1-1 (99.01.01)–2007 – 16 –
Copyright 2007 ISA. All rights reserved.
Systems and interfaces
In encompassing all industrial automation and control systems, this standard covers systems that can
affect or influence the safe, secure, and reliable operation of industrial processes. They include, but are
not limited to:
a) Industrial control systems and their associated communications networks
1
, including distributed
control systems (DCSs), programmable logic controllers (PLCs), remote terminal units (RTUs),
intelligent electronic devices, SCADA systems, networked electronic sensing and control,
metering and custody transfer systems, and monitoring and diagnostic systems. (In this context,
industrial control systems include basic process control system and safety-instrumented system
[SIS] functions, whether they are physically separate or integrated.)
b) Associated systems at level 3 or below of the reference model described in clause 6. Examples
include advanced or multivariable control, online optimizers, dedicated equipment monitors,
graphical interfaces, process historians, manufacturing execution systems, pipeline leak detection
systems, work management, outage management, and electricity energy management systems.
c) Associated internal, human, network, software, machine or device interfaces used to provide
control, safety, manufacturing, or remote operations functionality to continuous, batch, discrete,
and other processes.
Activity-based criteria
ANSI/ISA-95.00.03 [5, Annex A] defines a set of criteria for defining activities associated with
manufacturing operations. A similar list has been developed for determining the scope of this standard. A
system should be considered to be within the range of coverage of these standards if the activity it
performs is necessary for any of the following:
a) predictable operation of the process
b) process or personnel safety
c) process reliability or availability
d) process efficiency
e) process operability
f) product quality
g) environmental protection
h) regulatory compliance
i) product sales or custody transfer.
1
The term “communications networks” includes all types of communications media, including various
types of wireless communications. A detailed description of the use of wireless communications in
industrial automation systems is beyond the scope of this standard. Wireless communication techniques
are specifically mentioned only in situations where their use or application may change the nature of the
security applied or required.
– 17 – ANSI/ISA–62443-1-1 (99.01.01)–2007
Copyright 2007 ISA. All rights reserved.
Asset-based criteria
The coverage of this standard includes those systems in assets that meet any of the following criteria, or
whose security is essential to the protection of other assets that meet these criteria:
a) The asset has economic value to a manufacturing or operating process.
b) The asset performs a function necessary to operation of a manufacturing or operating process.
c) The asset represents intellectual property of a manufacturing or operating process.
d) The asset is necessary to operate and maintain security for a manufacturing or operating process.
e) The asset is necessary to protect personnel, contractors, and visitors involved in a manufacturing
or operating process.
f) The asset is necessary to protect the environment.
g) The asset is necessary to protect the public from events caused by a manufacturing or operating
process.
h) The asset is a legal requirement, especially for security purposes of a manufacturing or operating
process.
i) The asset is needed for disaster recovery.
j) The asset is needed for logging security events.
This range of coverage 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, environmental contamination, and/or economic loss
or impact on an entity or on local or national security.
ANSI/ISA–62443-1-1 (99.01.01)–2007 – 18 –
Copyright 2007 ISA. All rights reserved.
2 Normative References
The following referenced documents are indispensable for the application of this standard. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
ANSI/ISA-95.00.01-2000, Enterprise-Control System Integration Part 1: Models and Terminology,
Clause 5 (Hierarchy Models)
ISA-88.01-1995 (R 2006), Batch Control Part 1: Models and Terminology, Clause 4.2 (Physical Model)
ISO/IEC 15408-1: Information technology — Security techniques — Evaluation criteria for IT security –
Part 1: Introduction and General Model, Clause 4 (General Model)
– 19 – ANSI/ISA–62443-1-1 (99.01.01)–2007
Copyright 2007 ISA. All rights reserved.
3 Definitions
3.1 Introduction
This clause defines the terms and abbreviations used in this standard.
Wherever possible, definitions have been adapted from those used in established industry sources. Those
definitions are marked to indicate the reference listed in the bibliography.
Some definitions have been adapted from more generic definitions used in the IT industry.
3.2 Terms
The following terms are referenced in this standard.
3.2.1 access
ability and means to communicate with or otherwise interact with a system in order to use system
resources.
NOTE: Access may involve physical access (authorization to be allowed physically in an area, possession of a physical key lock,
PIN code, or access card or biometric attributes that allow access) or logical access (authorization to log in to a system
and application, through a combination of logical and physical means)
3.2.2 access control
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 [11].
3.2.3 accountability
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 [11].
3.2.4 application
software program that performs specific functions initiated by a user command or a process event and
that can be executed without access to system control, monitoring, or administrative privileges [9].
3.2.5 area
subset of a site’s physical, geographic, or logical group of assets.
NOTE: An area may contain manufacturing lines, process cells, and production units. Areas may be connected to each other by
a site local area network and may contain systems related to the operations performed in that area.
3.2.6 asset
physical or logical object owned by or under the custodial duties of an organization, having either a
perceived or actual value to the organization.
NOTE: In the case of industrial automation and control systems the physical assets that have the largest directly measurable
value may be the equipment under control.
3.2.7 association
cooperative relationship between system entities, usually for the purpose of transferring information
between them [11].
3.2.8 assurance
attribute of a system that provides grounds for having confidence that the system operates such that the
system security policy is enforced.
ANSI/ISA–62443-1-1 (99.01.01)–2007 – 20 –
Copyright 2007 ISA. All rights reserved.
3.2.9 attack
assault on a system 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 [11].
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 (including an
insider attacking from outside the security perimeter). Potential outside attackers range from amateur pranksters to
organized criminals, international terrorists, and hostile governments.
3.2.10 attack tree
formal, methodical way of finding ways to attack the security of a system.
3.2.11 audit
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 (See “security audit”) [9].
NOTE: There are three forms of audit. (1) External audits are conducted by parties who are not employees or contractors of the
organization. (2) Internal audit are conducted by a separate organizational unit dedicated to internal auditing. (3) Controls
self assessments are conducted by peer members of the process automation function.
3.2.12 authenticate
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 information system, or to establish the validity of a
transmission.
3.2.13 authentication
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 [9].
3.2.14 authorization
right or a permission that is granted to a system entity to access a system resource [11].
3.2.15 automated vehicle
mobile device that includes a control system allowing it to operate either autonomously or under remote
control.
3.2.16 availability
probability that an asset, under the combined influence of its reliability, maintainability, and security, will be
able to fulfill its required function over a stated period of time, or at a given point in time.
3.2.17 border
edge or boundary of a physical or logical security zone.
3.2.18 botnet
collection of software robots, or bots, which run autonomously.
NOTE: A botnet's originator can control the group remotely, possibly for nefarious purposes.
3.2.19 boundary
software, hardware, or other physical barrier that limits access to a system or part of a system [9].
– 21 – ANSI/ISA–62443-1-1 (99.01.01)–2007
Copyright 2007 ISA. All rights reserved.
3.2.20 channel
specific communication link established within a communication conduit (See “conduit”).
3.2.21 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.2.22 client
device or application receiving or requesting services or information from a server application [12].
3.2.23 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, and human interactions.
3.2.24 communication security
(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 [11].
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. However, cryptographic
algorithms and key management methods and processes may not be applicable to some control system applications.
3.2.25 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.2.26 compromise
unauthorized disclosure, modification, substitution, or use of information (including plaintext cryptographic
keys and other critical security parameters) [13].
3.2.27 conduit
logical grouping of communication assets that protects the security of the channels it contains.
NOTE: This is analogous to the way that a physical conduit protects cables from physical damage.
3.2.28 confidentiality
assurance that information is not disclosed to unauthorized individuals, processes, or devices [9].
3.2.29 control center
central location used to operate a set of assets.
NOTE: Infrastructure industries typically use one or more control centers to supervise or coordinate their operations. If there are
multiple control centers (for example, a backup 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.
NOTE: In some industries the term “control room” may be more commonly used.
3.2.30 control equipment
class that includes distributed control systems, programmable logic controllers, SCADA systems,
associated operator interface consoles, and field sensing and control devices used to manage and control
the process.
ANSI/ISA–62443-1-1 (99.01.01)–2007 – 22 –
Copyright 2007 ISA. All rights reserved.
NOTE: The term also includes field bus networks where control logic and algorithms are executed on intelligent electronic
devices that coordinate actions with each other, as well as systems used to monitor the process and the systems used to
maintain the process.
3.2.31 control network
time-critical network that is typically connected to equipment that controls physical processes (See “safety
network”).
NOTE: The control network can be subdivided into zones, and there can be multiple separate control networks within one
company or site.
3.2.32 cost
value of impact to an organization or person that can be measured.
3.2.33 countermeasure
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 [11].
NOTE: The term “Control” is also used to describe this concept in some contexts. The term countermeasure has been chosen
for this standard to avoid confusion with the word control in the context of “process control.”
3.2.34 cryptographic algorithm
algorithm based upon the science of cryptography, including encryption algorithms, cryptographic hash
algorithms, digital signature algorithms, and key agreement algorithms.
3.2.35 cryptographic key
input parameter that varies the transformation performed by a cryptographic algorithm [11].
NOTE: Usually shortened to just "key."
3.2.36 data confidentiality
property that information is not made available or disclosed to any unauthorized system entity, including
unauthorized individuals, entities, or processes [7].
3.2.37 data integrity
property that data has not been changed, destroyed, or lost in an unauthorized or accidental manner [11].
NOTE: This term deals with constancy of and confidence in data values, not with the information that the values represent or the
trustworthiness of the source of the values.
3.2.38 decryption
process of changing cipher text into plaintext using a cryptographic algorithm and key (See “encryption”)
[11].
3.2.39 defense in depth
provision of multiple security protections, especially in layers, with the intent to delay if not prevent an
attack.
NOTE: Defense in depth implies layers of security and detection, even on single systems, and provides the following features:
a. attackers are faced with breaking through or bypassing each layer without being detected
b. a flaw in one layer can be mitigated by capabilities in other layers
c. system security becomes a set of layers within the overall network security.
3.2.40 demilitarized zone
perimeter network segment that is logically between internal and external networks [9].
– 23 – ANSI/ISA–62443-1-1 (99.01.01)–2007
Copyright 2007 ISA. All rights reserved.
NOTE: The purpose of a demilitarized zone 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 network
from outside attacks.
NOTE: In the context of industrial automation and control systems, the term “internal network” is typically applied to the network
or segment that is the primary focus of protection. For example, a control network could be considered “internal” when
connected to an “external” business network.
3.2.41 denial of service
prevention or interruption of authorized access to a system resource or the delaying of system operations
and functions [11].
NOTE: In the context of industrial automation and control systems, denial of service can refer to loss of process function, not just
loss of data communications.
3.2.42 digital signature
result of a cryptographic transformation of data which, when properly implemented, provides the services
of origin authentication, data integrity, and signer non-repudiation [12].
3.2.43 distributed control system
type of control system in which the system elements are dispersed but operated in a coupled manner.
NOTE: Distributed control systems may have shorter coupling time constants than those typically found in SCADA systems.
NOTE: Distributed 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, and warehousing.
3.2.44 domain
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 [11].
3.2.45 eavesdropping
monitoring or recording of communicated information by unauthorized parties.
3.2.46 electronic security
actions required to preclude unauthorized use of, denial of service to, modifications to, disclosure of, loss
of revenue from, or destruction of critical systems or informational assets.
NOTE: The objective is to reduce the risk of causing personal injury or endangering public health, losing public or consumer
confidence, disclosing sensitive assets, failing to protect business assets or failing to comply with regulations. These
concepts are applied to any system in the production process and include both stand-alone 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. Electronic security includes the
concepts of identification, authentication, accountability, authorization, availability, and privacy.
3.2.47 encryption
cryptographic transformation of plaintext into ciphertext that conceals the data’s original meaning to
prevent it from being known or used (See “decryption”) [11].
NOTE: 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.2.48 enterprise
business entity that produces or transports products or operates and maintains infrastructure services.
3.2.49 enterprise system
collection of information technology elements (i.e., hardware, software and services) installed with the
intent to facilitate an organization’s business process or processes (administrative or project).
ANSI/ISA–62443-1-1 (99.01.01)–2007 – 24 –
Copyright 2007 ISA. All rights reserved.
3.2.50 equipment under control
equipment, machinery, apparatus or plant used for manufacturing, process, transportation, medical or
other activities [14].
3.2.51 field I/O network
communications link (wired or wireless) that connects sensors and actuators to the control equipment.
3.2.52 firewall
inter-network connection device that restricts data communication traffic between two connected networks
[11].
NOTE: A firewall may be either an application installed on a general-purpose computer or a dedicated platform (appliance) that
forwards or rejects/drops packets on a network. Typically firewalls are used to define zone borders. Firewalls generally
have rules restricting which ports are open.
3.2.53 gateway
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 [11].
NOTE: Also described as an intermediate system that is the translation interface between two computer networks.
3.2.54 geographic site
subset of an enterprise’s physical, geographic, or logical group of assets.
NOTE: A geographic site may contain areas, manufacturing lines, process cells, process units, control centers, and vehicles and
may be connected to other sites by a wide area network.
3.2.55 guard
gateway that is interposed between two networks (or computers or other information systems) operating at
different security levels (one network is usually more secure than the other) and is trusted to mediate all
information transfers between the two networks, either to ensure that no sensitive information from the
more secure network is disclosed to the less secure network, or to protect the integrity of data on the more
secure network [11].
3.2.56 host
computer that is attached to a communication subnetwork or inter-network and can use services provided
by the network to exchange data with other attached systems [11].
3.2.57 industrial automation and control systems
collection of personnel, hardware, and software that can affect or influence the safe, secure, and reliable
operation of an industrial process.
NOTE: These systems include, but are not limited to:
a. industrial control systems, including distributed control systems (DCSs), programmable logic controllers (PLCs),
remote terminal units (RTUs), intelligent electronic devices, 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 and safety-instrumented system [SIS] functions, whether they are
physically separate or integrated.)
b. associated information systems such as advanced or multivariable control, online optimizers, dedicated equipment
monitors, graphical interfaces, process historians, manufacturing execution systems, and plant information
management systems.
c. associated internal, human, network, or machine interfaces used to provide control, safety, and manufacturing
operations functionality to continuous, batch, discrete, and other processes.
3.2.58 initial risk
risk before controls or countermeasures have been applied (See “risk”).
– 25 – ANSI/ISA–62443-1-1 (99.01.01)–2007
Copyright 2007 ISA. All rights reserved.
3.2.59 insider
“trusted” person, employee, contractor, or supplier who has information that is not generally known to the
public (See “outsider”).
3.2.60 integrity
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 [9].
NOTE: In a formal security mode, integrity is often interpreted more narrowly to mean protection against unauthorized
modification or destruction of information.
3.2.61 interception
capture and disclosure of message contents 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.2.62 interface
logical entry or exit point that provides access to the module for logical information flows.
3.2.63 intrusion
unauthorized act of compromising a system (See “attack”).
3.2.64 intrusion detection
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.2.65 IP address
address of a computer or device that is assigned for identification and communication using the Internet
Protocol and other protocols.
3.2.66 ISO
International Organization for Standardization
1
.
3.2.67 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 [11].
3.2.68 lines, units, cells
lower-level elements that perform manufacturing, field device control, or vehicle functions.
NOTE: 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.
3.2.69 local area network
communications network designed to connect computers and other intelligent devices in a limited
geographic area (typically less than 10 kilometers) [10].
3.2.70 malicious code
programs or code written for the purpose of gathering information about systems or users, destroying
system data, providing a foothold for further intrusion into a system, falsifying system data and reports, or
providing time-consuming irritation to system operations and maintenance personnel.
1
ISO is not an acronym. The name derives from the Greek word iso, which means equal.
ANSI/ISA–62443-1-1 (99.01.01)–2007 – 26 –
Copyright 2007 ISA. All rights reserved.
NOTE: Malicious code attacks can take the form of viruses, worms, Trojan Horses, or other automated exploits.
NOTE: Malicious code is also often referred to as “malware.”
3.2.71 manufacturing operations
collection of production, maintenance, and quality assurance operations and their relationship to other
activities of a production facility.
NOTE: Manufacturing operations include:
a. manufacturing or processing facility activities that coordinate the personnel, equipment, and material involved in the
conversion of raw materials or parts into products.
b. functions that may be performed by physical equipment, human effort, and information systems.
c. managing information about the schedules, use, capability, definition, history, and status of all resources (personnel,
equipment, and material) within the manufacturing facility.
3.2.72 nonrepudiation
security service that provides protection against false denial of involvement in a communication [11].
3.2.73 OPC
set of specifications for the exchange of information in a process control environment.
NOTE: The abbreviation “OPC” originally came from “OLE for Process Control”, where “OLE” was short for “Object Linking and
Embedding.”
3.2.74 outsider
person or group not “trusted” with inside access, who may or may not be known to the targeted
organization (See “insider”).
NOTE: Outsiders may or may not have been insiders at one time.
3.2.75 penetration
successful unauthorized access to a protected system resource [11].
3.2.76 phishing
type of security attack that lures victims to reveal information, by presenting a forged email to lure the
recipient to a web site that looks like it is associated with a legitimate source.
3.2.77 plaintext
unencoded data that is input to and transformed by an encryption process, or that is output by a decryption
process [11].
3.2.78 privilege
authorization or set of authorizations to perform specific functions, especially in the context of a computer
operating system [11].
NOTE: Examples of functions that are controlled through the use of privilege include acknowledging alarms, changing setpoints,
modifying control algorithms.
3.2.79 process
series of operations performed in the making, treatment or transportation of a product or material.
NOTE: This standard makes extensive use of the term “process” to describe the equipment under control of the industrial
automation and control system.
3.2.80 protocol
set of rules (i.e., formats and procedures) to implement and control some type of association (e.g.,
communication) between systems [11].
– 27 – ANSI/ISA–62443-1-1 (99.01.01)–2007
Copyright 2007 ISA. All rights reserved.
3.2.81 reference model
structure that allows the modules and interfaces of a system to be described in a consistent manner.
3.2.82 reliability
ability of a system to perform a required function under stated conditions for a specified period of time.
3.2.83 remote access
use of systems that are inside the perimeter of the security zone being addressed from a different
geographical location with the same rights as when physically present at the location.
NOTE: The exact definition of “remote” can vary according to situation. For example, access may come from a location that is
remote to the specific zone, but still within the boundaries of a company or organization. This might represent a lower risk
than access that originates from a location that is remote and outside of a company’s boundaries.
3.2.84 remote client
asset outside the control network that is temporarily or permanently connected to a host inside the control
network via a communication link in order to directly or indirectly access parts of the control equipment on
the control network.
3.2.85 repudiation
denial by one of the entities involved in a communication of having participated in all or part of the
communication.
3.2.86 residual risk
the remaining risk after the security controls or countermeasures have been applied.
3.2.87 risk
expectation of loss expressed as the probability that a particular threat will exploit a particular vulnerability
with a particular consequence [11].
3.2.88 risk assessment
process that systematically identifies potential vulnerabilities to valuable system resources and threats to
those resources, quantifies loss exposures and consequences based on probability of occurrence, and
(optionally) recommends how to allocate resources to countermeasures to minimize total exposure.
NOTE: Types of resources include physical, logical and human.
NOTE: Risk assessments are often combined with vulnerability assessments to identify vulnerabilities and quantify the
associated risk. They are carried out initially and periodically to reflect changes in the organization's risk tolerance,
vulnerabilities, procedures, personnel and technological changes.
3.2.89 risk management
process of identifying and applying countermeasures commensurate with the value of the assets
protected based on a risk assessment [9].
3.2.90 risk mitigation controls
combination of countermeasures and business continuity plans.
3.2.91 role-based access control
form of identity-based access control where the system entities that are identified and controlled are
functional positions in an organization or process [11].
3.2.92 router
gateway between two networks at OSI layer 3 and that relays and directs data packets through that inter-
network. The most common form of router passes Internet Protocol (IP) packets [11].
ANSI/ISA–62443-1-1 (99.01.01)–2007 – 28 –
Copyright 2007 ISA. All rights reserved.
3.2.93 safety
freedom from unacceptable risk [2].
3.2.94 safety-instrumented system
system used to implement one or more safety-instrumented functions [2].
Note: A safety-instrumented system is composed of any combination of sensor(s), logic solver(s), and actuator(s).
3.2.95 safety integrity level
discrete level (one out of four) for specifying the safety integrity requirements of the safety-instrumented
functions to be allocated to the safety-instrumented systems [2].
NOTE: Safety integrity level 4 has the highest level of safety integrity; safety integrity level 1 has the lowest.
3.2.96 safety network
network that connects safety-instrumented systems for the communication of safety-related information.
3.2.97 secret
condition of information being protected from being known by any system entities except those intended to
know it [11].
3.2.98 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 [11].
4. capability of a computer-based system to provide adequate confidence that unauthorized persons and
systems can neither modify the software and its data nor gain access to the system functions, and yet
to ensure that this is not denied to authorized persons and systems [14].
5. prevention of illegal or unwanted penetration of or interference with the proper and intended operation
of an industrial automation and control system.
NOTE: Measures can be controls related to physical security (controlling physical access to computing assets) or logical security
(capability to login to a given system and application.)
3.2.99 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, the system elements required to implement the services, and the performance
levels required in the elements to deal with the threat environment [11].
NOTE: In this context, security architecture would be an architecture to protect the control network from intentional or
unintentional security events.
3.2.100 security audit
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 [7].
3.2.101 security components
assets such as firewalls, authentication modules, or encryption software used to improve the security
performance of an industrial automation and control system (See “countermeasure”).
3.2.102 security control
See “countermeasure.”
3.2.103 security event
occurrence in a system that is relevant to the security of the system [11].
– 29 – ANSI/ISA–62443-1-1 (99.01.01)–2007
Copyright 2007 ISA. All rights reserved.
3.2.104 security function
function of a zone or conduit to prevent unauthorized electronic intervention that can impact or influence
the normal functioning of devices and systems within the zone or conduit.
3.2.105 security incident
adverse event in a system or network or the threat of the occurrence of such an event [10].
NOTE: The term “near miss” is sometimes used to describe an event that could have been an incident under slightly different
circumstances.
3.2.106 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 [11].
3.2.107 security level
level corresponding to the required effectiveness of countermeasures and inherent security properties of
devices and systems for a zone or conduit based on assessment of risk for the zone or conduit [13].
3.2.108 security objective
aspect of security which to achieve is the purpose and objective of using certain mitigation measures,
such as confidentiality, integrity, availability, user authenticity, access authorization, accountability.
3.2.109 security perimeter
boundary (logical or physical) 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 [11].
3.2.110 security performance
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 security measures remain effective and appropriate.
NOTE: Tests, audits, tools, measures, or other methods are required to evaluate security practice performance.
3.2.111 security policy
set of rules that specify or regulate how a system or organization provides security services to protect its
assets [11].
3.2.112 security procedures
definitions of exactly how practices are implemented and executed.
NOTE: Security procedures are implemented through personnel training and actions using currently available and installed
technology.
3.2.113 security program
a combination of 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.2.114 security services
mechanisms used to provide confidentiality, data integrity, authentication, or no repudiation of information
[11].
3.2.115 security violation
act or event that disobeys or otherwise breaches security policy through an intrusion or the actions of a
well-meaning insider.
ANSI/ISA–62443-1-1 (99.01.01)–2007 – 30 –
Copyright 2007 ISA. All rights reserved.
3.2.116 security zone
grouping of logical or physical assets that share common security requirements.
NOTE: All unqualified uses of the word “zone” in this standard should be assumed to refer to a security zone.
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 in the sense that they can be
comprised of a collection of subzones.
3.2.117 sensors and actuators
measuring or actuating elements connected to process equipment and to the control system.
3.2.118 server
device or application that provides information or services to client applications and devices [11].
3.2.119 sniffing
See “interception.”
3.2.120 spoof
pretending to be an authorized user and performing an unauthorized action [11].
3.2.121 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.
NOTE: Supervisory control systems are also used within batch, continuous, and discrete manufacturing plants to centralize
monitoring and control activities for these sites.
3.2.122 system
interacting, interrelated, or interdependent elements forming a complex whole.
3.2.123 system software
special software 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 [12].
3.2.124 threat
potential for violation of security, which exists when there is a circumstance, capability, action, or event
that could breach security and cause harm [11].
3.2.125 threat action
assault on system security [11].
3.2.126 traffic analysis
inference of information from observable characteristics of data flow(s), even when the data are 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.2.127 trojan horse
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 [11].
3.2.128 use case
technique for capturing potential functional requirements that employs the use of one or more scenarios
that convey how the system should interact with the end user or another system to achieve a specific goal.
– 31 – ANSI/ISA–62443-1-1 (99.01.01)–2007
Copyright 2007 ISA. All rights reserved.
NOTE: Typically use cases treat the system as a black box, and the interactions with the system, including system responses,
are as perceived from outside of the system. Use cases are popular because they simplify the description of
requirements, and avoid the problem of making assumptions about how this functionality will be accomplished.
3.2.129 user
person, organization entity, or automated process that accesses a system, whether authorized to do so or
not [11].
3.2.130 virus
self-replicating or self-reproducing program that spreads by inserting copies of itself into other executable
code or documents.
3.2.131 vulnerability
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 [11].
3.2.132 wide area network
communications network designed to connect computers, networks and other devices over a large
distance, such as across the country or world [12].
3.2.133 wiretapping
attack that intercepts and accesses data and other information contained in a flow in a communication
system [11].
NOTE: 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
a gateway or subnetwork switch.
NOTE: "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.2.134 worm
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 [11].
3.2.135 zone
See “security zone.”
ANSI/ISA–62443-1-1 (99.01.01)–2007 – 32 –
Copyright 2007 ISA. All rights reserved.
3.3 Abbreviations
This subclause defines the abbreviations used in this standard.
ANSI American National Standards Institute
CIA Confidentiality, Integrity, and Availability
CN Control Network
COTS Commercial off the Shelf
CSMS Cyber Security Management System
DCS Distributed Control System
DDoS Distributed Denial of Service
DoS Denial of Service
DMZ Demilitarized Zone
FIPS U. S. Federal Information Processing Standards
IACS Industrial Automation and Control Systems
IEC International Electrotechnical Commission
IEEE Institute of Electrical and Electronics Engineers
I/O Input/Output
IP Internet Protocol
ISA The Instrumentation, Systems, and Automation Society
IT Information Technology
LAN Local Area Network
NASA U. S. National Aeronautics and Space Administration
NOST NASA Office of Standards and Technology
OSI Open Systems Interconnect
PLC Programmable Logic Controller
RTU Remote Terminal Unit
SCADA Supervisory Control and Data Acquisition
SIL Safety Integrity Level
SIS Safety-Instrumented System
WAN Wide Area Network
– 33 – ANSI/ISA–62443-1-1 (99.01.01)–2007
Copyright 2007 ISA. All rights reserved.
4 The Situation
4.1 General
Industrial automation and control systems operate within a complex environment. Organizations are
increasingly sharing information between business and industrial automation systems, and partners in one
business venture may be competitors in another. However, because industrial automation and control
systems equipment connects directly to a process, loss of trade secrets and interruption in the flow of
information are not the only consequences of a security breach. The potential loss of life or production,
environmental damage, regulatory violation, and compromise to operational safety are far more serious
consequences. These may have ramifications beyond the targeted organization; 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, industrial automation and control
systems are often integrated with other business systems. Modifying or testing operational systems has
led to unintended electronic effects on system operations. Personnel from outside the control systems
area increasingly perform security testing on the systems, exacerbating the number and consequence of
these effects. Combining all these factors, it is easy to see that the potential of someone gaining
unauthorized or damaging access to an industrial process is not trivial.
Although technology changes and partner relationships may be good for business, they increase the
potential risk of compromising security. As the threats to businesses increase, so does the need for
security.
4.2 Current Systems
Industrial automation and control systems have evolved from individual, isolated computers with
proprietary operating systems and networks to interconnected systems and applications employing
commercial off the shelf (COTS) technology (i.e., operating systems and protocols). These systems are
now being integrated with enterprise systems and other business applications through various
communication networks. This increased level of integration provides significant business benefits,
including:
a) increased visibility of industrial control system activities (work in process, equipment status,
production schedules) and integrated processing systems from the business level, contributing to
the improved ability to conduct analyses to drive down production costs and improve productivity
b) integrated manufacturing and production systems that have more direct access to business level
information, enabling a more responsive enterprise
c) common interfaces that reduce overall support costs and permit remote support of production
processes
d) remote monitoring of the process control systems that reduces support costs and allows problems
to be solved more quickly.
It is possible to define standards for models, terms, and information exchanges that allow the industrial
automation and control systems community to share information in a consistent way. However, this ability
to exchange information increases vulnerability to misuse and attack by individuals with malicious intent
and introduces potential risks to the enterprise using industrial automation and control systems.
ANSI/ISA–62443-1-1 (99.01.01)–2007 – 34 –
Copyright 2007 ISA. All rights reserved.
Industrial automation and control systems configurations can be very complex in terms of physical
hardware, programming, and communications. This complexity can often make it difficult to determine:
a) who is authorized to access electronic information
b) when a user can have access to the information
c) what data or functions a user should be able to access
d) where the access request originates
e) how the access is requested.
4.3 Current Trends
Several trends contribute to the increased emphasis on the security of industrial automation and control
systems:
a) In recent years there has been a marked increase in malicious code attacks on business and
personal computer systems. Businesses have reported more unauthorized attempts (either
intentional or unintentional) to access electronic information each year than in the previous year.
b) Industrial automation and control systems are moving toward COTS operating systems and
protocols and are interconnecting with business networks. This is making these systems
susceptible to the same software attacks as are present in business and desktop devices.
c) Tools to automate attacks are commonly available on the Internet. The external threat from the
use of these tools now includes cyber criminals and cyber terrorists who may have more
resources and knowledge to attack an industrial automation and control system.
d) The use of joint ventures, alliance partners, and outsourced services in the industrial sector has
led to a more complex situation with respect to the number of organizations and groups
contributing to security of the industrial automation and control system. These practices must be
taken into account when developing security for these systems.
e) The focus on unauthorized access has broadened from amateur attackers or disgruntled
employees to deliberate criminal or terrorist activities aimed at impacting large groups and
facilities.
f) The adoption of industry standard protocols such as Internet Protocol (IP) for communication
between industrial automation and control systems and field devices. Implementing IP exposes
these systems to the same vulnerabilities as business systems at the network layer.
These trends have combined to significantly increase organization’s risks associated with the design and
operation of their industrial automation and control systems. At the same time, electronic security of
industrial control systems has become a more significant and widely acknowledged concern. This shift
requires more structured guidelines and procedures to define electronic security applicable to industrial
automation and control systems, as well as the respective connectivity to other systems.
4.4 Potential Impact
People who know the features of open operating systems and networks could potentially intrude into
console devices, remote devices, databases, and, in some cases, control platforms. The effect of
intruders on industrial automation and control systems may include:
a) unauthorized access, theft, or misuse of confidential information
b) publication of information to unauthorized destinations
c) loss of integrity or reliability of process data and production information
– 35 – ANSI/ISA–62443-1-1 (99.01.01)–2007
Copyright 2007 ISA. All rights reserved.
d) loss of system availability
e) process upsets leading to compromised process functionality, inferior product quality, lost
production capacity, compromised process safety, or environmental releases
f) equipment damage
g) personal injury
h) violation of legal and regulatory requirements
i) risk to public health and confidence
j) threat to a nation’s security.
ANSI/ISA–62443-1-1 (99.01.01)–2007 – 36 –
Copyright 2007 ISA. All rights reserved.
5 Concepts
5.1 General
This clause describes several underlying concepts that form the basis for the following clauses and for
other standards in the ISA99 series. Specifically, it addresses questions such as:
a) What are the major concepts that are used to describe security?
b) What are the important concepts that form the basis for a comprehensive security program?
5.2 Security Objectives
Information security has traditionally focused on achieving three objectives, confidentiality, integrity, and
availability, which are often abbreviated by the acronym "CIA." An information technology security strategy
for typical “back office” or business systems may place the primary focus on confidentiality and the
necessary access controls needed to achieve it. Integrity might fall to the second priority, with availability
as the lowest.
In the industrial automation and control systems environment, the general priority of these objectives is
often different. Security in these 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 industrial automation and control systems. Therefore, integrity is often
second in importance. Usually confidentiality is of lesser importance, because often the data is raw in form
and must be analyzed within context to have any value.
The facet of time responsiveness is significant. Control systems can have requirements of system
responsiveness in the 1 millisecond range, whereas traditional business systems are able to successfully
operate with single or multiple second response times.
In some situations the priorities are completely inverted, as shown in Figure 1.
Priority
Availability
Integrity
Confidentiality
Confidentiality
Integrity
Availability
Industrial Automation
& Control Systems
General Purpose Information
Technology Systems
Figure 1 – Comparison of Objectives
– 37 – ANSI/ISA–62443-1-1 (99.01.01)–2007
Copyright 2007 ISA. All rights reserved.
Depending on the circumstances, the integrity of the system could also have the highest priority. Certain
operational requirements will cause individual components or the systems as a whole to have different
priorities for the objectives (i.e., integrity or availability concerns may outweigh confidentiality, or vice
versa). This may in turn lead an organization to deploy different countermeasures to achieve these
security objectives.
5.2.1 Foundational Requirements
The simple CIA model shown in Figure 1 is not adequate for a full understanding of the requirements for
security in industrial automation and control systems. Although it is beyond the scope of this standard to
describe an exhaustive list of detailed requirements, there are several basic or foundational requirements
that have been identified for industrial automation security. These are:
a) Access Control (AC) – Control access to selected devices, information or both to protect against
unauthorized interrogation of the device or information.
b) Use Control (UC) – Control use of selected devices, information or both to protect against
unauthorized operation of the device or use of information.
c) Data Integrity (DI) – Ensure the integrity of data on selected communication channels to protect
against unauthorized changes.
d) Data Confidentiality (DC) – Ensure the confidentiality of data on selected communication
channels to protect against eavesdropping.
e) Restrict Data Flow (RDF) – Restrict the flow of data on communication channels to protect
against the publication of information to unauthorized sources.
f) Timely Response to Event (TRE) – Respond to security violations by notifying the proper
authority, reporting needed forensic evidence of the violation, and automatically taking timely
corrective action in mission critical or safety critical situations.
g) Resource Availability (RA) - Ensure the availability of all network resources to protect against
denial of service attacks.
All of these requirements are within the scope of this standard, although in some cases more detailed
normative information will be provided by other standards in the ISA99 series. For example, technical
requirements such as Data Integrity and Data Confidentiality will be addressed in detail in the ISA99 Part 4
standard.
5.3 Defense in Depth
It is typically not possible to achieve the security objectives through the use of a single countermeasure or
technique. A superior approach is to use the concept of defense in depth, which involves applying multiple
countermeasures in a layered or stepwise manner. For example, intrusion detection systems can be used
to signal the penetration of a firewall.
5.4 Security Context
5.4.1 General
The security context forms the basis for the interpretation of terminology and concepts and shows how the
various elements of security relate to each other. The term security is considered here to mean the
prevention of illegal or unwanted penetration of or interference with the proper and intended operation of
an industrial automation and control system. Electronic security includes computer, network, or other
programmable components of the system.
ANSI/ISA–62443-1-1 (99.01.01)–2007 – 38 –
Copyright 2007 ISA. All rights reserved.
5.4.2 A Context Model
The context of security is based on the concepts of threats, risks, and countermeasures, as well as the
relationships between them. The relationship between these concepts can be shown in a simple model.
One such model is described in the international standard ISO/IEC 15408-1 (Common Criteria) [6]. It is
reproduced in Figure 2.
Owners
Countermeasures
Risk
Assets
Threats
Threat Agents
value
wish to minimize
impose
to
to
that increase
give rise to
wish to abuse and/or may damage
To
reduce
Figure 2 – Context Element Relationships
A different view of the relationship is shown in Figure 3. This model shows how an expanded set of
concepts are related within the two interconnected processes of information security assurance and
threat-risk assessment.
Assurance
Techniques
Assurance
Confidence
Countermeasures
Risk
Owners
produce
to minimize
require
in
Evaluation
gives evidence of
Vulnerabilities
Threats
Assets
require
using
to
Threat-Risk
Assessment
Information Security
Assurance
Figure 3 – Context Model
– 39 – ANSI/ISA–62443-1-1 (99.01.01)–2007
Copyright 2007 ISA. All rights reserved.
5.5 Threat-Risk Assessment
Within the threat-risk assessment process, assets are subject to risks. These risks are in turn minimized
through the use of countermeasures, which are applied to address vulnerabilities that are used or
exploited by various threats. Each of these elements is described in more detail in the following
paragraphs.
5.5.1 Assets
Assets are the focus of a security program. They are what are being protected. In order to fully understand
the risk to an IACS environment, it is first necessary to create an inventory of the assets that require
protection. Assets may be classified as physical, logical or human.
a) Physical Assets – Physical assets include any physical component or group of components
belonging to an organization. In the industrial environment, these may include control systems,
physical network components and transmission media, conveyance systems, walls, rooms,
buildings, material, or any other physical objects that are in any way involved with the control,
monitoring, or analysis of production processes or in support of the general business. The most
significant physical assets are those that make up the equipment that is under the control of the
automation system.
b) Logical Assets – Logical assets are of an informational nature. They 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, these types of
assets can include public reputation, buyer confidence, or other measures that if damaged directly
affect the business. Logical assets may be in the form of personal memory, documents,
information contained on physical media, or electronic storage records dealing with the
informational asset. Logical assets also can include test results, regulatory compliance data, or
any other information considered sensitive or proprietary, or that could either provide or yield a
competitive advantage. Loss of logical assets often causes very long lasting and damaging effects
to an organization.
Process automation assets are a special form of logical assets. They contain the automation logic
employed in executing the industrial process. These 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 nonphysical (e.g., unauthorized
modification) means, and result in some sort of loss of integrity or availability to the process itself.
c) Human Assets – Human assets include people and the knowledge and skills that they possess
associated with their production activities. They can include required certifications, equipment-
specific knowledge, or other activities not included in the automated production processes or
important skills needed during emergencies. Rarely are processing facilities completely
automated and disruption of the operations people could have a major impact on production
although the physical and logical systems remain relatively intact. For example, an erroneous
plant alarm could cause personnel to initiate shutdown and plant evacuation although nothing was
physically or logically disrupted in the industrial automation and control systems. Any accident or
attack that injures a person would be considered as impacting a human asset.
ANSI/ISA–62443-1-1 (99.01.01)–2007 – 40 –
Copyright 2007 ISA. All rights reserved.
5.5.1.1 Valuing Assets
To meet the qualification of either physical or logical asset, the object must be either owned by or under
the custodial duties of the organization. It also must have value to the organization. The value of the asset
may be expressed in either qualitative or quantitative terms. Some organizations will also consider
qualitative valuation to be adequate reasoning for expressing asset loss in the risk analysis process.
a) Quantitative Valuation of Assets – An asset given a quantitative valuation has a precise
monetary loss associated with it. This could be 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 the potential impact
from a loss.
b) Qualitative Valuation of Assets – Qualitative loss typically expresses a more abstract “level” of
loss such as a percentage or a relative value such as low impact, high impact, or no impact. Many
assets may only be analyzed in terms of qualitative loss. 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.
Value may be categorized by the type of loss incurred, either direct or indirect.
a) Direct Loss – Direct loss represents the cost of replacing the asset. For a physical asset, this
could include the replacement cost for the device itself. Logical assets have comparatively low
direct loss when compared with their utility value, because the medium used to store the asset is
typically low cost.
b) Indirect Loss – Indirect loss represents any loss caused by the loss of the asset that the
organization may realize. This could include losses related 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 logical assets are often
great. They include loss of public confidence, loss of license to operate because of regulatory
violation, and loss of competitive advantage from release of intellectual property (e.g., confidential
process technology).
– 41 – ANSI/ISA–62443-1-1 (99.01.01)–2007
Copyright 2007 ISA. All rights reserved.
5.5.1.2 Categorization of Loss
By combining the information on asset types and valuation, it is possible to show the types of losses for
each type of asset. This is summarized in Table 1.
Table 1 – Types of Loss by Asset Type
Asset Type Direct Loss Indirect Loss Qualitative or
Quantitative?
Physical Can be high direct loss,
represented by the
replacement cost for the
asset. 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.
Downstream effects as a result
of loss, including loss of
control, loss or damage to
other assets, and downtime
losses
Qualitative or quantitative,
may begin with qualitative
for high-level risks, and
later be quantitative for
greater precision
Logical Low direct loss, as the
storage media are often
cheap and easily replaceable
High indirect loss, often due to
loss of intellectual property,
compromise of proprietary
procedures, or violation of
regulatory compliance. Indirect
losses from equipment
damage or material release
can lead to downtime, rework,
reengineering, or other efforts
to restore control over the
industrial process.
Mostly qualitative, but
some downstream effects
may be quantitative
Human Low to medium direct loss
depending upon the extent of
the injury to the person.
Minor injuries with short
recovery times may have low
direct loss impact to the
company even though the
injury may have lasting
impact to the person who is
injured.
Low to high indirect loss
depending upon the extent of
the injury and the criticality of
the person to the process.
Overtime costs and temporary
replacement costs may vary
considerably depending upon
the recovery time of the
individual. Permanent disabling
injuries or death may have high
indirect loss costs when social
responsibility and potential
liltigation and awards are
factored into the assessment.
Immediate qualitative
impact on production
followed by quantitative
impact for recovery or
replacement
5.5.2 Vulnerabilities
In simple terms, vulnerabilities are inherent weaknesses in systems, components, or organizations.
Vulnerabilities may be the result of intentional design choices or may be accidental, resulting from the
failure to understand the operational environment. They may also emerge as equipment ages and
eventually becomes obsolete, which occurs in a shorter time than is typical for the underlying process or
equipment under control. Vulnerabilities are not limited to the electronic or network systems.
Understanding the interaction between physical (including human) and electronic vulnerabilities is critical
to establishing effective industrial automation and control system security.
ANSI/ISA–62443-1-1 (99.01.01)–2007 – 42 –
Copyright 2007 ISA. All rights reserved.
An industrial automation and control system that initially has limited vulnerability may become more
vulnerable with situations such as changing environment, changing technology, system component failure,
unavailability of component replacements, personnel turnover, and greater threat intelligence.
5.5.3 Risk
Risk is generally defined as an expectation of loss expressed as the probability that a particular threat will
exploit a particular vulnerability with a particular consequence. Risk is a function of threat, vulnerability,
and consequence, where consequence is the negative impact the organization experiences due to the
specific harm to the organization’s asset or assets by the specific threat or vulnerability. The threat and
vulnerability components can be expressed in terms of likelihood. Likelihood is the probability that a
specific action will occur.
Asset owners should rank and include the cost of mitigation or cost to repair in their estimate of risk. They
should also determine the appropriate countermeasures for mitigating the most security exposures for the
least financial exposure.
Any sound risk assessment methodology should analyze all involved systems in a layered approach,
starting with systems closest to the threat, and working inward. The basic risk assessment process
consists of three steps:
1. assess initial risk
2. implement risk mitigation countermeasures
3. assess residual risk.
Steps 2 and 3 of this process are repeated as required in order to reduce the residual risk to an
acceptable level. Specifically, the second step includes evaluating existing controls and implementing
plans to add remedial or additional countermeasures. A more detailed description of the process of
determining risk will be provided in the ISA99 Part 2 standard, ISA-99.00.02 [1].
Typical risks considered include:
a) personnel safety risks such as death or injury
b) process safety risks such as equipment damage or business interruption
c) information security risks such as cost, legal violations, or loss of brand image
d) environmental risk such as notice of violation, legal violations, or major impact
e) business continuity risks such as business interruption.
5.5.3.1 Risk Tolerance Level
The output of a qualitative risk analysis will consist of a list of assets or scenarios with an overall likelihood
and a consequence ranking. It is a management responsibility to determine the appropriate response to
items based on these rankings. Some organizations accept relatively high levels of risk (such as
aggressive growth companies), while some companies are inherently conservative in terms of being risk
adverse. Therefore, a certain level of residual risk may be acceptable to one organization and not to
another. Even within the same company, individual plants may exhibit different risk appetites or
tolerances. Management must explicitly define and understand what its risk appetite or tolerance is, so it
can better analyze its level of response to residual risks identified.
– 43 – ANSI/ISA–62443-1-1 (99.01.01)–2007
Copyright 2007 ISA. All rights reserved.
Addressing the security of industrial automation and control systems does not, in general, introduce new
risks, but it may contribute to a different perspective on the existing risks. For example, risks related to
safety are typically given more attention in an industrial automation context.
Industrial automation and control systems security does not need to reinvent a process for defining the
risk tolerance level; it is simply derived from other risk management practices in the organization.
5.5.3.2 Risk Response
There are several potential responses to risk. Organizations can take some combination of actions in
each situation, depending on the circumstances.
a) Design the risk out – One form of mitigation is to change the design of the system so the risk is
removed. Some risks exist simply because access is available to something to which no access is
ever needed. Completely disabling the unnecessary function or “welding” the function from access
can mitigate the risk. Organizations can make the appropriate business decisions so the risk is
not taken. This response may involve saying no to something, whether a new vendor product,
system, or relationship.
b) Reduce the risk – Risks can be decreased to an acceptable level through the implementation of
countermeasures that reduce the likelihood or consequence of an attack. The key here is to
achieve a level of “good enough” security, not to eliminate the risk.
c) Accept the risk – There is always an option to accept the risk, to see it as the cost of doing
business. Organizations must take some risks, and they cannot always be cost effectively
mitigated or transferred.
d) Transfer or share the risk – It may be possible to establish some sort of insurance or agreement
that transfers some or all of the risk to a third entity. A typical example of this is outsourcing of
specific functions or services. This approach cannot always be effective, because it may not
always cover all assets completely. An electronic security policy can recover certain damages, but
not logical assets such as loss of customer confidence.
e) Eliminate or redesign redundant or ineffective controls – A good risk assessment process will
identify these types of controls that need to be addressed so that more attention can be focused
on controls that are effective and efficient.
5.5.4 Threats
Threats describe the possible actions that can be taken against a system. They come in many different
forms, but two of the more common forms are:
a) Accidental – Someone unfamiliar with proper procedure and policy or an honest oversight
causes an accidental risk. It is also likely that an organization does not know all the risks and may
uncover them by accident as it operates complex industrial automation and control systems.
b) Nonvalidated changes – Updates, corrections, and other changes to operating systems,
application programs, configurations, connectivity, and equipment can provide an unexpected
security threat to the industrial automation and control systems or the respective production.
Threat agent is the term used to describe the entity that presents a threat. They are also known as
adversaries or attackers. Threat agents come in many different forms. Examples include:
a) Insider – An insider is a “trusted” person, employee, contractor, or supplier who has information
that is not generally known to the public. An insider can present a threat even if there is no intent
to do harm. For example, the threat may arise as a result of an insider bypassing security controls
“to get the job done.”
ANSI/ISA–62443-1-1 (99.01.01)–2007 – 44 –
Copyright 2007 ISA. All rights reserved.
b) Outsider – An outsider is a person or group not “trusted” with inside access, which may or may
not be known to the targeted organization. Outsiders may or may not have been insiders at one
time.
c) Natural – Natural events include storms, earthquakes, floods, and tornadoes, and are generally
considered a physical threat.
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
possible to model attacks in order to ensure that countermeasures are in place to identify and deter them.
Case modeling and attack trees are examples of methods that can be used.
Threats may be either passive or active. Each type is described in the following paragraphs.
5.5.4.1 Passive
Passive information gathering can provide a potential intruder with valuable information. Threat agents
usually gather passive information by casual verbal communications with employees and contractors.
However, persons inside or outside the facilities can also gather passive information with visual
observations. 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 their areas of
responsibility can help organizations recognize passive information gathering, especially when combined
with accurate background check information.
Sniffing is an example of a passive threat. It is the act of monitoring data in a communications stream.
Wiretapping, intercepting data contained in a flow of information, is the most widely known means of
sniffing. Sniffing can be very sophisticated. Tools are publicly available to sniff data on various
communication networks. Although these devices are commonly used for configuration management,
troubleshooting networks, and analyzing data traffic, they can also be used to gather specific data about
any transaction occurring across the network. For example, in packet sniffing and password sniffing, the
attacker secretly attaches to the network at a remote switch or computer. The sniffing tool then passively
monitors the information sent through the network and captures the information to a disk that can later be
downloaded and analyzed to obtain user identifications and passwords.
5.5.4.2 Active
Active threats come in various forms, as described in the following paragraphs.
Communication – The intent of a communication attack is to disrupt communications for an industrial
automation and control system. Communication attacks can occur in several forms. They may occur at
several levels within the system from the computer processor layer up and from outside the enterprise, as
in a “denial-of-service” attack on communications systems.
Database Injection – An injection is a form of attack on a database-driven web site in which the attacker
executes unauthorized commands by taking advantage of insecure code on a system connected to the
internet, bypassing the firewall. 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 industrial automation and control system.
Potential intruders can replay access control signals, biometric signals, and other system signals to gain
unauthorized access to secured areas or systems, hide illegitimate activities, or provide false distractions.
Other documents randomly have
different content
Using The Isaiec 62443 Standard To Secure Your Control Systems Course Ic32e Online Version 21 Participant Noteset Volume Ii Wally Magda
Using The Isaiec 62443 Standard To Secure Your Control Systems Course Ic32e Online Version 21 Participant Noteset Volume Ii Wally Magda
Using The Isaiec 62443 Standard To Secure Your Control Systems Course Ic32e Online Version 21 Participant Noteset Volume Ii Wally Magda
The Project Gutenberg eBook of The Literature
of the Old Testament
This ebook is for the use of anyone anywhere in the United
States and most other parts of the world at no cost and with
almost no restrictions whatsoever. You may copy it, give it away
or re-use it under the terms of the Project Gutenberg License
included with this ebook or online at www.gutenberg.org. If you
are not located in the United States, you will have to check the
laws of the country where you are located before using this
eBook.
Title: The Literature of the Old Testament
Author: George Foot Moore
Release date: July 8, 2012 [eBook #40173]
Most recently updated: October 23, 2024
Language: English
Credits: Produced by Delphine Lettau, Julia Neufeld and the
Online
Distributed Proofreading Team at http://www.pgdp.net
*** START OF THE PROJECT GUTENBERG EBOOK THE LITERATURE
OF THE OLD TESTAMENT ***
HOME UNIVERSITY LIBRARY
OF MODERN KNOWLEDGE
THE LITERATURE OF THE
OLD TESTAMENT
BY
GEORGE FOOT MOORE, M.A., D.D.,
LL.D.
London
WILLIAMS & NORGATE
HENRY HOLT & Co., New York
Canada: WM. BRIGGS, Toronto
India: R. & T. WASHBOURNE, Ltd.
Using The Isaiec 62443 Standard To Secure Your Control Systems Course Ic32e Online Version 21 Participant Noteset Volume Ii Wally Magda
The following volumes of kindred interest have already been
published in the Home University Library:—
Vol. 56.—THE MAKING OF THE NEW TESTAMENT. By Prof. B.
W. Bacon, LL.D., D.D.Vol.
Vol. 68.—COMPARATIVE RELIGION. By Principal J. Estlin
Carpenter, D.Litt.
Vol. 15.—MOHAMMEDANISM. By Prof. D. S. Margoliouth, M.A.,
D.Litt.
Vol. 47.—BUDDHISM. By Mrs. Rhys Davids, M.A.
Vol. 54.—ETHICS. By G. E. Moore, M.A.
CONTENTS
CHAPTER PAGE
I The Canon of the Old Testament 7
II The Old Testament as a National Literature 25
III The Pentateuch 29
IV Character of the Sources. Genesis 33
V Exodus, Leviticus, Numbers 47
VI Deuteronomy 58
VII
Age of the Sources. Composition of the
Pentateuch
65
VIII Joshua 73
IX Judges 81
X Samuel 91
XI Kings 100
XII Chronicles 118
XIII Ezra and Nehemiah 128
XIV Story Books: Esther, Ruth, Jonah 134
XV The Prophets 144
XVI Isaiah 147
XVII Jeremiah 164
XVIII Ezekiel 174
XIX Daniel 180
XX Minor Prophets 190
XXI Psalms. Lamentations 218
XXII Proverbs 231
XXIII Job 235
XXIV Ecclesiastes. Song of Songs 243
Bibliography 251
Index 253
Using The Isaiec 62443 Standard To Secure Your Control Systems Course Ic32e Online Version 21 Participant Noteset Volume Ii Wally Magda
THE LITERATURE
OF
OLD TESTAMENT
CHAPTER I
THE CANON OF THE OLD TESTAMENT
The early Christians received the Sacred Books of the Jews as
inspired Scripture containing a divine revelation and clothed with
divine authority, and till well on in the first century of the Christian
era the name Scriptures was applied exclusively to these books. In
time, as they came to attach the same authority to the Epistles and
Gospels, and to call them, too, Scriptures (2 Pet. iii. 16), they
distinguished the Christian writings as the Scriptures of the new
dispensation, or, as they called it, the "new covenant," from the
Scriptures of the "old covenant" (2 Cor. iii. 6, 14), the Bible of the
Jews. The Greek word for covenant (diathéké) was rendered in the
early Latin translation by testamentum, and the two bodies of
Scripture themselves were called the Old Testament and the New
Testament respectively.
The Scriptures of the Jews were written in Hebrew, the older
language of the people; but a few chapters in Ezra and Daniel are in
Aramaic, which gradually replaced Hebrew as the vernacular of
Palestine from the fifth century B.C. The Sacred Books comprise the
Law, that is, the Five Books of Moses; the Prophets, under which
name are included the older historical books (Joshua, Judges,
Samuel, Kings) as well as what we call the Prophets (Isaiah,
Jeremiah, Ezekiel, and the Twelve, i.e. Minor Prophets); a third
group, of less homogeneous character, had no more distinctive name
than the "Scriptures"; it included Ruth, Psalms, Job, Proverbs,
Ecclesiastes, Song of Songs, Lamentations, Daniel, Esther, Ezra-
Nehemiah, and Chronicles. The Minor Prophets counted as one
book; and the division of Samuel, Kings, Ezra-Nehemiah, and
Chronicles each into two books was made later, and perhaps only in
Christian copies of the Bible. There are, consequently, according to
the Jewish enumeration twenty-four books in the Bible, while in the
English Old Testament, by subdivision, we count the same books as
thirty-nine.
The order of the books in the Pentateuch and "Former Prophets"
(Joshua-Kings) is fixed by the historical sequence, and therefore
constant; among the "Latter Prophets" Jeremiah was sometimes put
first, immediately following the end of Kings, with which it was so
closely connected. In the third group there was no such obvious
principle of arrangement, and consequently there were different
opinions about the proper order; that which is given above follows
the oldest deliverance on the subject, and puts them in what the
rabbis doubtless supposed to be a chronological series. So long as
the books were written on separate rolls of papyrus, the question of
order was theoretical rather than practical; and even when
manuscripts were written in codex form (on folded leaves stitched
together like our books), no uniformity was attained.
At the beginning of the Christian era, lessons from the Law were
regularly read in the synagogues on the sabbath (the Pentateuch
being so divided that it was read through consecutively once in three
years), and a second lesson was chosen from the Prophets. The title
of these books to be regarded as Sacred Scripture was thus
established by long-standing liturgical use, and was, indeed, beyond
question. Nor was there any question about the inspiration of most
of the books in the third group, the "Scriptures." There was a
controversy, however, over Ecclesiastes and the Song of Songs;
some teachers of the strictest school denied that either of them was
inspired, while others accepted only one of them. The question was
voted on in a council of rabbis held at Jamnia about the beginning of
the second century of our era, and the majority decided for the
inspiration of both books. There were also, even down to the third
century, Jewish scholars who did not acknowledge Esther as Sacred
Scripture. On the other hand, some were inclined to include among
the Sacred Books the Proverbs of Ben Sira, which stand in the
English Bible among the Apocrypha under the title Ecclesiasticus.
It is thus evident that, while there was agreement in general, there
was, down to the second century A.D., no authoritative list of the
"Scriptures," and that about some of the books there were
conflicting opinions among the learned of the most orthodox stamp.
An interesting confirmation of this is the fact that in the first half of
that century it was thought necessary to make a formal deliverance
that the "Gospel and other writings of the heretics" are not Sacred
Scripture. There are other indications that in that generation Jewish
Christianity had a dangerous attraction for some even in rabbinical
circles, and there was evidently ground for apprehension that the
inspiration which the Christians claimed for the Scriptures of the New
Covenant might impose upon well-meaning but uninstructed Jews.
In the same connection it was decided, further, that Ben Sira
(Ecclesiasticus) was not Holy Scripture, and that no books written
from his time on (about 200 B.C.) were inspired, in accordance with
the theory, found also in Josephus, that inspiration ceased in the age
of Ezra and Nehemiah.
By such decisions, recognizing the inspiration of books that had been
challenged and excluding others for which inspiration had been
claimed, the canon of the Scriptures, that is, the authoritative list of
Sacred Books, was defined. The oldest catalogue we have,
containing the titles of all the books, dates probably from the latter
part of the second century, and is not concerned with the point of
canonicity—which it takes for granted—but with the proper order of
the Prophets and the Scriptures.
The Jews had for centuries been widely distributed through the
lands that had been included in the kingdoms of Alexander's
successors. There were large numbers in Babylonia and the
neighbouring provinces of the Parthian empire, and still more in the
countries around the eastern end of the Mediterranean, in Syria and
Asia Minor, in Egypt and Cyrene. In Alexandria the Jews had a whole
quarter of the city to themselves, and Philo estimates their numbers
in Egypt in his time (ca. A.D. 40) at a million.
In cities like Alexandria, where Greek was the common speech of a
population recruited from many races, the Jews soon exchanged
their mother tongue for the cosmopolitan language. The ancient
Hebrew of their Sacred Books was unintelligible, not only to the
masses, but even to most of the educated, who had learned in the
schools of Greek rhetoricians and philosophers rather than at the
feet of the rabbis. If the knowledge of the holy Law by which the
distinctive Jewish life was regulated was not to be lost altogether,
the Scriptures must be translated into Greek. The Pentateuch was
doubtless translated first—legend attributes the initiative to King
Ptolemy Philadelphus (285-246 B.C.); then other books, by different
hands and at different times and places. To some of the books, as to
Daniel and Esther, additions were made in the translation which
were not accepted by the Palestinian Jews.
Besides the books which were finally included in the Jewish canon,
there were various others, written in Hebrew or Aramaic after the
pattern of the several forms of Biblical literature. History, for
example, is represented by 1 Maccabees, relating the struggle of the
Jews in Palestine for religious liberty and national independence in
the second century B.C.; the Proverbs of Solomon have a counterpart
in the Proverbs of Ben Sira, already mentioned; the Psalter, in the
so-called Psalms of Solomon; the story of Judith may be compared
with Esther; the visions of Daniel have their parallel in popular
apocalypses bearing the names of Enoch, Noah, Ezra, Baruch, and
other ancient worthies. These writings were sooner or later
translated into Greek, and some of them attained a wide circulation.
The Greek-speaking Jews, also, produced a religious literature, in
part imitating the familiar Biblical forms, as in the Wisdom of
Solomon and 2 Maccabees, in part cast in Greek moulds, as when
prophecy disguised itself in Sibylline Oracles, or the supremacy of
reason over the emotions was made the subject of a discourse after
the pattern of a Stoic diatribe (4 Maccabees).
The influence of Greek culture on many of these writers was not
confined to language and literary form; they lived in an atmosphere
of Greek thought—the popular philosophy, in which Platonic and
Stoic elements were fused or confused—and a few had a more
academic acquaintance with the Greek thinkers. But, under all this,
they were Jews to the core, devoted to the religion of their fathers,
of the superiority of which they were the more convinced by the
spectacle of heathenism about them: Judaism was the only true
religion, its Scriptures the one divine revelation. The Law and the
Prophets had the same precedence as in the Palestinian synagogue.
Of the other Scriptures there was no authoritative and exclusive list,
and among books read solely for private edification it is not likely
that a very sharp line was drawn; but, on the whole, the practice of
the Greek-speaking Jews does not seem to have been materially
different from that of their countrymen in Palestine.
Outside of Palestine, Christianity was spread by Greek-speaking Jews
who had embraced the new Messianic faith, and their converts in the
fields of their missionary labours, both Jews and Gentiles, spoke
Greek, either as their mother tongue or as the language of common
intercourse. The church, therefore, took over the Jewish Scriptures
in the existing translations: the Christian Old Testament was from
the beginning the Greek Bible, not the Hebrew. They received also
from the Greek-speaking Jews the belief in the divine inspiration of
the translators, by virtue of which the same infallible authority
attached to the version of the Seventy which belonged to the
Hebrew original. In their desire to possess every word of God, they
gathered up the religious books which they found in the hands of
the Jews, without inquiring curiously whether the Jews included
them in the narrower category of Sacred Scriptures or not; and they
discovered no reason in the books themselves why Esther, for
example, should be inspired and Judith not; or why Ecclesiastes,
with its scepticism about the destiny of the soul, should be divinely
revealed, and the Wisdom of Solomon, with its eloquent defence of
immortality, a purely human production; or, again, why the Proverbs
of Solomon were Scripture, and the Proverbs of Ben Sira
(Ecclesiasticus) nothing but profane wisdom.
Controversies in the second century made the Christian apologists
aware that the Jews did not acknowledge the authority of some of
the books from which their opponents adduced proof-texts, and this
practical concern, rather than purely learned interest, led to the
drawing up of lists of books which were accepted by the Jews as
Sacred Scripture. The oldest of these lists which has come down to
us was made by Melito, Bishop of Sardes, about A.D. 170; it contains
the books of the Jewish canon enumerated above (p. 8), with the
noteworthy exception of Esther, about which, as we have seen,
Jewish opinion was divided. Christian catalogues of the Jewish Old
Testament long show an uncertainty about the right of this book to a
place in the canon.
Meanwhile the church had, in its worship and in religious instruction,
established a use and tradition of its own. The Wisdom of Jesus, son
of Sirach, was appropriated for the moral instruction of youth and of
converts, as is shown by the title it bears in the Greek Bible,
Ecclesiasticus, that is, "The Church Book," and other writings not
included in the Jewish canon were highly esteemed in the church.
About A.D. 240, Julius Africanus, Bishop of Emmaus in Palestine,
addressed a critical letter to Origen on the story of Susanna and the
Elders in the Book of Daniel. This story, he said, was not found in
the Hebrew Daniel, and was not acknowledged by the Jews. He
proved by internal evidence that it was not translated from the
Hebrew, the language in which the Scriptures of the Old Testament
were inspired, but originally composed in Greek, and he raised
various historical objections to the tale: it ought not, therefore, to be
quoted as Sacred Scripture. In his answer, Origen, the greatest
Biblical scholar of his age, argued that if the story of Susanna was to
be set aside on the ground that it was not accepted by the Jews,
other books, such as Judith and Tobit, would have to be rejected
also. He appeals to the prescriptive usage of the church itself, which
had always used these books and read them with edification. This
immemorial tradition was authority enough for Christians; there was
no reason why the church should prune its Bible to please the Jews
or adapt itself to their opinions about what was and what was not
inspired Scripture; he reminds his correspondent of the law, "Thou
shalt not remove the ancient landmarks which those before thee
have set."
This way of looking at the matter, as might be expected, prevailed in
the church. Lists of the books of the Jewish Bible were handed
down, and scholars were well aware that the Christian Old
Testament contained several books not received by the Jews. By the
more critical of the Greek Fathers these books are not cited with the
same authority for the establishment of doctrine as the books of the
Hebrew Bible. Thus, Athanasius, at the end of a list of the canonical
Scriptures of the Old and New Testaments (A.D. 365), adds: "There
are, besides these, other books, not, indeed, included in the canon,
but prescribed by the Fathers to be read by those who come to the
church and wish to be taught the doctrine of religion, namely, the
Wisdom of Solomon, and the Wisdom of Sirach, Esther, Judith, Tobit,
and the Teaching of the Twelve Apostles." But this learned reserve
had no effect on the liturgical or practical use of the church. The
question of the inspiration and authority of the supernumerary books
of the Old Testament was not decided by any council speaking in the
name of the catholic church; nor was it ever thus determined exactly
what these supernumerary books were, though several local synods
made lists of them.
The Latin Church received its Bible from the Greeks, and the Latin
translations of the Old Testament made from the Greek included, as
a matter of course, the books which the church accepted and the
synagogue rejected. About the beginning of the fifth century, Jerome
undertook a new Latin translation direct from the Hebrew. He lived
for many years at Bethlehem, and had learned Hebrew from Jewish
teachers, whose assistance he employed also in the work of
translation. In some of the prefaces to this translation (which was
published in parts), and in other places in his writings, Jerome gives
a catalogue of the books of the Hebrew Bible, corresponding to the
contents of our English Old Testament, and expressly excludes all
others from the class of canonical Scriptures: "Whatever is not
included in this list is to be classed as apocrypha. Therefore Wisdom
(commonly entitled 'of Solomon'), and the Book of Jesus son of
Sirach, and Judith and Tobit ... are not in the canon." The word
"apocrypha," literally "secret, or esoteric, writings," had been used
generally for the books of heretical sects, or suspected of being
such, and, more broadly, of writings which the church repudiated as
not only uninspired but harmful, the reading of which it often
forbade. It was, therefore, a very radical word that Jerome uttered
when he applied this name to books which the church had always
regarded as godly and edifying.
Jerome himself did not consistently maintain the position which
would make the Jewish Bible the canon of the Christian church. At
the request of certain bishops he translated Judith and Tobit, noting
in the prefaces that the Jews exclude these books from the canon
and put them among the apocrypha, but significantly adding in the
one case that he thinks it better to oppose the judgment of the
Pharisees and obey the commands of the bishops, in the other
pleading not only the demand of a bishop but the fact that the
Nicene Council had included Judith among the Sacred Books.[1] In
another preface he describes Ecclesiasticus and the Wisdom of
Solomon as books which the church reads "for the edification of the
people, not for proving the doctrines of the church"—a definition
which accords with the attitude of many of the Greek Fathers.
Jerome thus halts between two opinions: in relegating to the
apocrypha everything that is not in the Hebrew Bible he speaks as a
critic; in recognizing the books found in the Christian Old Testament,
but not in the Hebrew, as useful and edifying, though of inferior
authority for doctrinal purposes, he, like Origen, takes the ground of
the practical churchman. The mediating position is more clearly
defined by Rufinus, who, after giving a catalogue of the books of the
Hebrew Bible, adds: "There are other books, which older authors
called not 'canonical' but 'ecclesiastical,' such as the Wisdom of
Solomon, and the so-called Wisdom of the Son of Sirach, named by
the Latins Ecclesiasticus; to the same class belong Tobit, Judith and
the Books of the Maccabees."
The great influence of Augustine was thrown wholly on the side of
ecclesiastical tradition; he even remonstrated with Jerome for
translating the Old Testament from the Hebrew and thus disturbing
the minds of the faithful, instead of revising the Old Latin version
after the Greek. In his treatise on Christian Doctrine (ii. 8; written in
A.D. 397) he includes among the canonical books of the Old
Testament, Judith, Tobit, 1 and 2 Maccabees, Ecclesiasticus, and the
Wisdom of Solomon; African provincial synods at Hippo (A.D. 393)
and Carthage (A.D. 397) pronounced themselves in the same sense.
The Syriac-speaking churches, whose Old Testament was translated
from the Hebrew, originally recognized those books only which were
found in the Jewish Bible; it appears, indeed, that the earliest Syriac
version did not extend to Chronicles, Ezra, and Nehemiah, but did
include Sirach. Under the influence of the Greek Church, those
branches of the Syrian Church which remained in communion with it
gradually added to their Bible translations of the other books from
the Greek; but the Nestorians, in whose schools Biblical criticism
moved more freely than in the Catholic Church, continued to reject
them, or to accord them, together with several of the books
commonly reckoned canonical (Chronicles, Ezra, Nehemiah, Judith, 1
and 2 Maccabees, Job, Ecclesiasticus, Wisdom), only qualified
authority.
Throughout the Middle Ages learned authors repeated the conflicting
utterances of the Fathers concerning the canon, without being
disturbed by their inconsistency; in practice, the Old Testament
comprised all the books that were usually found in copies of the
Greek or Latin Bible, without regard to the fine distinctions of
"canonical" and "ecclesiastical." The immemorial usage of the church
had more weight than the opinions of scholars. With this concurred
the fact that from the fourth century on the Bible was copied in
collective codices, on folded sheets of parchment or vellum like our
books, not in separate rolls, and thus the canon of the Old
Testament became, not a mere list of Sacred Books, but a physical
unity, in which the books of the Jewish Bible were intermingled with
those which the Jews did not accept.
The question assumed a new significance at the Reformation. In
rejecting the authority of ecclesiastical tradition and the prescriptive
usage of the church and making the Scriptures the only rule of faith
and practice, the Reformers were under the necessity of deciding
what books were inspired Scripture, containing the Word of God
revealed to men, clothed with divine authority, demanding
unqualified faith, and a means of grace to believers. Obviously they
could not logically acknowledge books whose place in the Bible had
no other warrant than that the church had accepted them from very
early times; nothing short of the authority of the New Testament
itself would suffice, and they found in the New Testament no
quotations from these books. To the Jews, St. Paul said, were
committed the oracles of God; it was the Jewish Scriptures to which
Jesus and the Apostles appealed.
Naturally, therefore, Luther reverted to the position of Jerome: the
books found in the Hebrew Bible, and those only, were the
Scriptures of the Old Testament; whatever was more than these was
to be reckoned among the apocrypha. In the first complete printed
edition of his translation (1534), these books (Judith, Wisdom, Tobit,
Sirach, Baruch, 1 and 2 Maccabees, the Greek additions to Esther
and Daniel, the Prayer of Manasseh) stand between the Old
Testament and the New, with the title (after Jerome) "Apocrypha;
that is, books that are not equally esteemed with the Holy Scripture,
but nevertheless are profitable and good to read." The other
Protestant versions, on the Continent and in England, followed this
example.
The attitude of Luther toward the Old Testament Apocrypha was
maintained by the Lutheran Churches, whose Confessions do not,
however, attempt a more exact definition of the value and authority
of the Apocrypha. The earlier Reformed (Calvinistic) Confessions
take substantially the same ground: the Ecclesiastical Books, or
Apocrypha, are useful, especially for moral instruction, but they have
not the same authority as the canonical books, and doctrines may
not be deduced from them alone. The Articles of the Church of
England (1563; English translation, 1571) agree on this point with
the other Reformed Confessions: after enumerating the canonical
books "of whose authority there was never any doubt in the
Church," the Sixth Article continues: "And the other books (as
Hierome saith) the Church doth read for example of life, and
instruction of manners; but yet it doth not apply them to establish
any doctrine." A list of such books follows, comprising those
commonly printed in the English Bible under the title Apocrypha.
A more radical position was represented by the Synod of Dort (1618)
and by the Westminster Assembly (1643). The latter declares: "The
books commonly called Apocrypha, not being of divine inspiration,
are no part of the canon of Scripture; and therefore are of no
authority in the church of God, nor to be otherwise approved, or
made use of, than other human writings."
In opposition to the Protestant limitation of the canon of the Old
Testament to the books of the Hebrew Bible, the Roman Church
defined its attitude more sharply. In the Fourth Session of the
Council of Trent (1546) it framed a "Decree concerning the Canonical
Scripture," in which the books set apart by the Protestants as
Apocrypha are included with the rest. The complete contents of the
Old Testament in the Catholic Bible as thus defined are as follows:
The Five Books of Moses, that is, Genesis, Exodus, Leviticus,
Numbers, Deuteronomy; Joshua, Judges, Ruth, four Books of Kings
[Samuel, Kings], two Books of Chronicles, 1 and 2 Esdras [Ezra,
Nehemiah], Tobit, Judith, Esther, Job, the Psalter of David,
containing one hundred and fifty Psalms, Proverbs, Ecclesiastes,
Song of Songs, Wisdom, Ecclesiasticus, Isaiah, Jeremiah with
Baruch, Ezekiel, Daniel, the Twelve Minor Prophets, two Books of
Maccabees, namely, the First and Second.... "If any man does not
accept as sacred and canonical these books, entire, with all their
Welcome to our website – the perfect destination for book lovers and
knowledge seekers. We believe that every book holds a new world,
offering opportunities for learning, discovery, and personal growth.
That’s why we are dedicated to bringing you a diverse collection of
books, ranging from classic literature and specialized publications to
self-development guides and children's books.
More than just a book-buying platform, we strive to be a bridge
connecting you with timeless cultural and intellectual values. With an
elegant, user-friendly interface and a smart search system, you can
quickly find the books that best suit your interests. Additionally,
our special promotions and home delivery services help you save time
and fully enjoy the joy of reading.
Join us on a journey of knowledge exploration, passion nurturing, and
personal growth every day!
ebookbell.com

More Related Content

PDF
Snyk provides Compliance-Cheat-Sheet.pdf
PDF
Ccsk course content v1
PDF
A Deep Dive into Secure Product Development Frameworks.pdf
 
PDF
Cybersecurity for Automation Control and SCADA Systems
PDF
Cybersecurity Frameworks for DMZCON23 230905.pdf
PPT
Information Systems Security: Security Management, Metrics, Frameworks and Be...
PPTX
Network Security version1.0 - Module 3.pptx
PPTX
Network Security v1.0 - You have Module 3.pptx
Snyk provides Compliance-Cheat-Sheet.pdf
Ccsk course content v1
A Deep Dive into Secure Product Development Frameworks.pdf
 
Cybersecurity for Automation Control and SCADA Systems
Cybersecurity Frameworks for DMZCON23 230905.pdf
Information Systems Security: Security Management, Metrics, Frameworks and Be...
Network Security version1.0 - Module 3.pptx
Network Security v1.0 - You have Module 3.pptx

Similar to Using The Isaiec 62443 Standard To Secure Your Control Systems Course Ic32e Online Version 21 Participant Noteset Volume Ii Wally Magda (20)

PDF
Industrial_Cyber_Security
PDF
Scada implement secure - architecture
PPTX
Network Security_module1_informatin _sec
PDF
Requirements of ISO 26262
PPTX
Integrating of security activates in agile process
PDF
SCADA Cyber Sec | ISACA 2013 | Patricia Watson
PDF
Building a Product Security Practice in a DevOps World
PPTX
OT_Security.pptx
PDF
Information security management guidance for discrete automation
PDF
Contributing to the Development and Application of Cybersecurity Standards
PDF
Iio t security std
DOCX
Tonight, March 5th – Class 7 (last class) your test” on ICS.docx
PPTX
SCADA Security Training
PPTX
Secure Software Development Life Cycle
PPTX
Industrial IoT Security Standards & Frameworks
PPTX
SCADA Cybersecurity Training
PDF
Secure Systems Security and ISA99- IEC62443
PPTX
Cybersecurity Critical Infrastructure Framework Course Textbook and the class...
PDF
Secure-by-Design Using Hardware and Software Protection for FDA Compliance
 
PDF
Generic Security Framework for Multiple Heterogeneous Virtual Infrastructures
Industrial_Cyber_Security
Scada implement secure - architecture
Network Security_module1_informatin _sec
Requirements of ISO 26262
Integrating of security activates in agile process
SCADA Cyber Sec | ISACA 2013 | Patricia Watson
Building a Product Security Practice in a DevOps World
OT_Security.pptx
Information security management guidance for discrete automation
Contributing to the Development and Application of Cybersecurity Standards
Iio t security std
Tonight, March 5th – Class 7 (last class) your test” on ICS.docx
SCADA Security Training
Secure Software Development Life Cycle
Industrial IoT Security Standards & Frameworks
SCADA Cybersecurity Training
Secure Systems Security and ISA99- IEC62443
Cybersecurity Critical Infrastructure Framework Course Textbook and the class...
Secure-by-Design Using Hardware and Software Protection for FDA Compliance
 
Generic Security Framework for Multiple Heterogeneous Virtual Infrastructures
Ad

Recently uploaded (20)

PDF
O7-L3 Supply Chain Operations - ICLT Program
PDF
Module 4: Burden of Disease Tutorial Slides S2 2025
PPTX
human mycosis Human fungal infections are called human mycosis..pptx
PDF
Basic Mud Logging Guide for educational purpose
PPTX
Final Presentation General Medicine 03-08-2024.pptx
PDF
RMMM.pdf make it easy to upload and study
PDF
O5-L3 Freight Transport Ops (International) V1.pdf
PPTX
IMMUNITY IMMUNITY refers to protection against infection, and the immune syst...
PPTX
PPH.pptx obstetrics and gynecology in nursing
PDF
Saundersa Comprehensive Review for the NCLEX-RN Examination.pdf
PDF
Complications of Minimal Access Surgery at WLH
PDF
Pre independence Education in Inndia.pdf
PDF
Black Hat USA 2025 - Micro ICS Summit - ICS/OT Threat Landscape
PPTX
Cell Types and Its function , kingdom of life
PDF
01-Introduction-to-Information-Management.pdf
PDF
STATICS OF THE RIGID BODIES Hibbelers.pdf
PPTX
Institutional Correction lecture only . . .
PDF
Chapter 2 Heredity, Prenatal Development, and Birth.pdf
PPTX
Microbial diseases, their pathogenesis and prophylaxis
PDF
Microbial disease of the cardiovascular and lymphatic systems
O7-L3 Supply Chain Operations - ICLT Program
Module 4: Burden of Disease Tutorial Slides S2 2025
human mycosis Human fungal infections are called human mycosis..pptx
Basic Mud Logging Guide for educational purpose
Final Presentation General Medicine 03-08-2024.pptx
RMMM.pdf make it easy to upload and study
O5-L3 Freight Transport Ops (International) V1.pdf
IMMUNITY IMMUNITY refers to protection against infection, and the immune syst...
PPH.pptx obstetrics and gynecology in nursing
Saundersa Comprehensive Review for the NCLEX-RN Examination.pdf
Complications of Minimal Access Surgery at WLH
Pre independence Education in Inndia.pdf
Black Hat USA 2025 - Micro ICS Summit - ICS/OT Threat Landscape
Cell Types and Its function , kingdom of life
01-Introduction-to-Information-Management.pdf
STATICS OF THE RIGID BODIES Hibbelers.pdf
Institutional Correction lecture only . . .
Chapter 2 Heredity, Prenatal Development, and Birth.pdf
Microbial diseases, their pathogenesis and prophylaxis
Microbial disease of the cardiovascular and lymphatic systems
Ad

Using The Isaiec 62443 Standard To Secure Your Control Systems Course Ic32e Online Version 21 Participant Noteset Volume Ii Wally Magda

  • 1. Using The Isaiec 62443 Standard To Secure Your Control Systems Course Ic32e Online Version 21 Participant Noteset Volume Ii Wally Magda download https://ebookbell.com/product/using-the-isaiec-62443-standard-to- secure-your-control-systems-course-ic32e-online- version-21-participant-noteset-volume-ii-wally-magda-10666946 Explore and download more ebooks at ebookbell.com
  • 2. Here are some recommended products that we believe you will be interested in. You can click the link to download. Using The Isaiec 62443 Standard To Secure Your Control Systems Course Ic32e Online Version 21 Participant Noteset Volume I Wally Magda https://ebookbell.com/product/using-the-isaiec-62443-standard-to- secure-your-control-systems-course-ic32e-online- version-21-participant-noteset-volume-i-wally-magda-10666948 Using The Iso 56002 Innovation Management System A Practical Guide For Implementation And Building A Culture Of Innovation H James Harrington Sid Benraouane https://ebookbell.com/product/using-the-iso-56002-innovation- management-system-a-practical-guide-for-implementation-and-building-a- culture-of-innovation-h-james-harrington-sid-benraouane-46774092 Using The Socratic Method In Counseling A Guide To Channeling Inborn Knowledge 1st Edition Katarzyna Peoples https://ebookbell.com/product/using-the-socratic-method-in-counseling- a-guide-to-channeling-inborn-knowledge-1st-edition-katarzyna- peoples-50472516 Using The Results Of A National Assessment Of Educational Achievement National Assessments Of Educational Achievement Thomas Kellaghan https://ebookbell.com/product/using-the-results-of-a-national- assessment-of-educational-achievement-national-assessments-of- educational-achievement-thomas-kellaghan-2002708
  • 3. Using The Internet For Active Teaching And Learning 1st Edition Steven C Mills https://ebookbell.com/product/using-the-internet-for-active-teaching- and-learning-1st-edition-steven-c-mills-2193298 Using The Agricultural Environmental And Food Literature Books In Library And Information Science 1st Edition Barbara S Hutchinson https://ebookbell.com/product/using-the-agricultural-environmental- and-food-literature-books-in-library-and-information-science-1st- edition-barbara-s-hutchinson-2196744 Using The Microsoft Office Web Apps Mcfedries Paul https://ebookbell.com/product/using-the-microsoft-office-web-apps- mcfedries-paul-21983910 Using The Asus Eee Pc Lawrence Bill https://ebookbell.com/product/using-the-asus-eee-pc-lawrence- bill-22136892 Using The Iphone Covers Iphone 3g 3gs And 4 Running Ios 4 Mcfedries https://ebookbell.com/product/using-the-iphone-covers-iphone-3g-3gs- and-4-running-ios-4-mcfedries-22136894
  • 5. Using the ISA/IEC 62443 Standard to Secure Your Control Systems Course IC32E (Online), Version 2.1 Participant Noteset Volume II
  • 6. Copyright © 2017, ISA 67 T.W. Alexander Drive Research Triangle Park, NC 27709 USA All rights reserved. This book or any portion thereof may not be reproduced or used in any manner whatsoever without the express written permission of the publisher. The unauthorized reproduction or distribution of a copyrighted work is illegal. Criminal copyright infringement, including infringement without monetary gain, is investigated by the FBI and is punishable by fines and federal imprisonment.
  • 7. ISA Cyber Instruction – IC32E Online Instructor-Led Course Cyber Security for Automation, Control and SCADA Systems This online/self-study course focuses on the issues involved in developing a cyber security program for industrial automation and control systems including risk assessment, awareness of cyber threats and exploits and the use of ‘countermeasures’ to reduce risk and/or mitigate the consequences of a successful cyber-attack. This course will aid engineering personnel with responsibility for plant/process automation systems in identifying potential vulnerabilities and implementing changes to improve the cyber security of their critical process automation systems. The course is divided into twelve (12) separate modules, with a recommended one module or two module per week for completion. However, students may work at their own pace, as long as they cover the material by the indicated review dates. Various learning techniques will be provided to cover the weekly course areas including: pre-recorded instructor presentations, additional resources, homework assignments, reading assignments, as well as live Q&A debrief instructor sessions. Refer to your detailed course syllabus, which is provided with your course materials, for further information/instructions. Course Schedule Pre-Survey Students will be asked to take a pre-survey, which includes questions related to the subject matter areas. Answers will be provided for students to assess their knowledge, prior to beginning the course materials. Module 1: Introduction to Control Systems Security and the ISA/IEC 62443 Standards Provides a basic introduction to control system cyber security and the ISA/IEC 62443 standards. Discussion of trends, regulations, industry standards and best practices, common myths, the ISA 99 committee, and the structure of the ISA 62443 standard. Topics include: Self-assessment of your Control Systems Security knowledge, Trends in control system cybersecurity, Potential Impacts, Five common myths regarding IACS Security, Regulations and Standards, ISA99 committee work Module 2: Terminology, Concepts, Models and Metrics Covers the material in ISA 62443-1-1 (published as ISA-99.00.01:2007) that forms the basis for the ISA 62443 series of standards. Topics include: Difference between IT and IACS, Security Objectives, Defense- in-Depth, Risk Assessment, Policies, Zones & Conduits, Security Levels and the Security Lifecycle Models Module 3: Industrial Networking Basics L1-L3 Provides a basic introduction to networking with a focus on the application of Ethernet in the industrial environment. Topics include: Types of networks, OSI reference model, Network Devices, Network Protocols, Network Tools built into Operating Systems. Module 4: Industrial Networking Basics L4-L7 Builds on the previous module and covers networking with a focus on the upper layers of the OSI reference model, problems with the OSI model, network discovery, and security auditing tools in the industrial environment. Topics include: Encapsulating data, OSI reference model, Network Devices, Network Protocols.
  • 8. Module 5: Network Security Basics 101 Provides a basic introduction to network security. Topics include: Security Appliances, Network Segmentation, Encryption, Secure Protocols and Intrusion Detection. Topics include: Why address security? Firewalls, Network Segmentation Architectures, Encryption, Intrusion Detection, Monitoring Network Traffic. Module 6: Industrial Protocols Covers at a high level the structure and application of common industrial protocols such as MODBUS, PROFIBUS, OPC and CIP (EtherNet/IP). Topics include: What is a protocol? Multitude of Industrial Protocols, Ports in use. Module 7: Establishing an Industrial Automation and Control Systems Security Program Covers the material in ISA 62443-2-1 (published as ISA-99.02.01:2009) that specifies the elements and requirements of an IACS Cyber Security Management System (CSMS). Topics include: Six top level activities, Common pitfalls, Risk Analysis, Security Policy, Organization and Awareness, Personnel security, Physical & Environmental Security, Network Segmentation, Access Control, Change Management, Patch and Anti-virus management, Information management, Incident Response and Disaster Recover Planning, Compliance Monitoring, and Program Maintenance. Module 8: Security Risk Assessment and System Design Covers Security Level definitions and Foundational Requirements that establish a basis for the requirements in scoping an IACS assessment, establishing zones & conduits, analyzing the security risk for each zone, assigning a security level target to each zone and verifying the design satisfies the security level target. Topics include: Definitions, Risk Equation, Cyber Risk Reduction Factor, Basic Security analysis tools, Identification of Zones and Conduits Module 9: Intro to the IACS Cybersecurity Lifecycle Short jaunt into the Assess, Develop & Implement and Maintain phases of the IACS Cybersecurity Lifecycle. These phases are covered more in depth in ISA’s IC33, IC34 & IC37 courses. Topics include: Cyber Security Life Cycle diagram, Phases, Continuous processes Module 10: Security Risk Assessment and System Design Creating a secure product out of the box is only a small piece of the security puzzle. Asset Owners, Integrators and Suppliers all have a role. This module covers how IEC 62443-2-4 specifies requirements IACS service providers can offer to the asset owner during integration and maintenance activities of an Automation Solution. Topics include: IACS Patching, Asset Owner Requirements, Product Supplier/Service Provider Requirements, Malicious Code Protection Module 11: Developing Secure Products and Systems Overview of component tier Product Development Requirements and Technical Security Requirements for IACS that are Product supplier centric. Topics include: Component tier standards ISA-62443-4-1 & ISA- 62443-4-2, Primary & Secondary goals, ISA 62443 relationships, ISA Security Compliance Institute (ISCI), ISASecure™ Module 12: Evolving Security Standards and Practices Standards are voluntary documents unless there is a requirement to use them. In this module, we look at the continuously evolving industrial security regulatory landscape. The only constant is change! Topics include: Normative and Informative elements, NIST Cyber Security Framework, ISA-62443-2-1 requirement to monitor and evaluate applicable legislation relevant to cyber security, Standards Development Organizations (SDOs) Post-Survey Students will be asked to take a post-survey, which includes questions related to the subject matter areas. Answers will be provided for students to assess their knowledge, prior to beginning the course materials. Final Examination
  • 9. Learn more with ISA’s hands-on Portable Training Labs! Our hands-on labs are ready to ship to your facility. Offering state-of-the-art equipment and expert instruction, ISA Onsite Training brings automation training directly to you. Learn more at www.isa.org/OnsiteTraining. Emerson Process Management- Rosemount Measurement Wade Associates, Inc. ISA Training Equipment Donors ISA would like to thank the following companies for donating equipment for use in our hands-on training labs. By donating equipment, these companies have increased their name recognition within the industry while helping ISA continue its efforts to offer superior automation and control training. EP30-6408-0516
  • 11. AMERICAN NATIONAL STANDARD ANSI/ISA–62443-1-1 (99.01.01)–2007 (formerly designated as ANSI/ISA-99.00.01-2007) Security for Industrial Automation and Control Systems Part 1-1: Terminology, Concepts, and Models Approved 29 October 2007
  • 12. ANSI/ISA–62443-1-1 (99.01.01)–2007 (formerly designated as ANSI/ISA-99.00.01-2007) Security for Industrial Automation and Control Systems Part 1-1: Terminology, Concepts, and Models ISBN: 978-1-934394-37-3 Copyright © 2007 by ISA. All rights reserved. Not for resale. Printed in the United States of America. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means (electronic mechanical, photocopying, recording, or otherwise), without the prior written permission of the Publisher. ISA 67 Alexander Drive P. O. Box 12277 Research Triangle Park, NC 27709 USA
  • 13. – 3 – ANSI/ISA–62443-1-1 (99.01.01)–2007 Copyright 2007 ISA. All rights reserved. Preface This preface, as well as all footnotes and annexes, is included for information purposes and is not part of ANSI/ISA–62443-1-1 (99.01.01)–2007. This document has been prepared as part of the service of ISA, toward a goal of uniformity in the field of instrumentation. To be of real value, this document should not be static but should be subject to periodic review. Toward this end, the Society welcomes all comments and criticisms and asks that they be addressed to the Secretary, Standards and Practices Board; ISA; 67 Alexander Drive; P. O. Box 12277; Research Triangle Park, NC 27709; Telephone (919) 549-8411; Fax (919) 549-8288; E-mail: standards@isa.org. 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.
  • 14. ANSI/ISA–62443-1-1 (99.01.01)–2007 – 4 – Copyright 2007 ISA. All rights reserved. The following participated as voting members of ISA99 in the development of this standard: NAME COMPANY B. Singer, Chair Fluid IQs R. Webb, Managing Director Consultant E. Cosman, Lead Editor The Dow Chemical Co. R. Bhojani Bayer Technology Services M. Braendle ABB D. Brandl BR&L Consulting, Inc. E. Byres Byres Security, Inc. R. Clark Invensys Systems, Inc. / Wonderware A. Cobbett BP Process Control Digital Protection J. Dalzon ISA France T. Davis Citect R. Derynck Verano, Inc. R. Evans Idaho National Laboratory R. Forrest The Ohio State University J. Gilsinn NIST/MEL T. Glenn Yokogawa T. Good E I DuPont De Nemours & Co. E. Hand Sara Lee Food & Beverage M. Heard Eastman Chemical Co. D. Holstein OPUS Publishing C. Hoover Rockwell Automation B. Huba Emerson Processing Management M. Lees Schering-Plough Corp. C. Mastromonico Westinghouse Savannah River Co. D. Mills Procter & Gamble Co. G. Morningstar Cedar Rapids Water Dept. A. Nangia 3M J. Nye ExxonMobil Research and Engineering T. Phinney Honeywell ACS Adv Tech Lab E. Rakaczky Invensys Systems Canada Inc. C. Sossman WGI-W Safety Management Solutions LLC L. Steinocher Fluor Enterprises, Inc. I. Susanto Chevron Information Technology Co. B. Taylor The George Washington University D. Teumim Teumim Technical LLC D. Tindill Matrikon Inc. L. Uden Lyondell Chemical Co. J. Weiss Applied Control Solutions, LLC M. Widmeyer Consultant L. Winkel Siemens SG The following served as active members of ISA99 Working Group 3 in the preparation of this standard: Name Company Contributor Reviewer E. Cosman, Lead Editor The Dow Chemical Co.  J. Bauhs Cargill  R. Bhojani Bayer  M. Braendle ABB  D. Brandl BR&L Consulting, Inc. 
  • 15. – 5 – ANSI/ISA–62443-1-1 (99.01.01)–2007 Copyright 2007 ISA. All rights reserved. M. Bush Rockwell Automation  E. Byres Byres Security, Inc.  A. Capel Comgate Engineering Ltd.  L. Capuder Aramco  R. Clark Invensys Wonderware  A. Cobbett BP  J. Dalzon ISA France  H. Daniel Consultant  A. Daraiseh Saudi Aramco  R. Derynck Verano, Inc.  G. Dimowo Shell  D. Elley Aspen Technology, Inc.  R. Evans Idaho National Laboratories  J. Gilsinn NIST/MEL  T. Glenn Yokogawa  T. Good DuPont  R. Greenthaler TXU Energy  E. Hand Sara Lee Food & Beverage  D. Holstein OPUS Publishing  C. Hoover Rockwell Automation  M. Jansons Siemens  R. Lara Invensys  J. Lellis Aspen Technology, Inc.  D. Mills Procter & Gamble Co.  C. Muehrcke Cyber Defense Agency  M. Naedele ABB  J. Nye ExxonMobil  R. Oyen Consultant   D. Peterson Digital Bond  T. Phinney Honeywell  J. Potter Emerson  E. Rakaczky Invensys  J. Seest Novo Nordisk A/S  B. Singer, ISA99 Chair Fluid IQs  L. Steinocher Fluor Enterprises, Inc.  I. Susanto Chevron  E. Tieghi ServiTecno SRL  R. Webb Consultant 
  • 16. ANSI/ISA–62443-1-1 (99.01.01)–2007 – 6 – Copyright 2007 ISA. All rights reserved. J. Weiss Applied Control Solutions LLC  L. Winkel Siemens SG  The ISA Standards and Practices Board approved the first edition of this standard for publication on 27 September 2007: NAME COMPANY T. McAvinew, Chair Jacobs Engineering Group M. Coppler Ametek, Inc. E. Cosman The Dow Chemical Co. B. Dumortier Schneider Electric D. Dunn Aramco Services Co. J. Gilsinn NIST/MEL W. Holland Consultant E. Icayan ACES, Inc. J. Jamison Consultant K. Lindner Endress & Hauser Process Solutions AG V. Maggioli Feltronics Corp. A. McCauley, Jr. Chagrin Valley Controls, Inc. G. McFarland Emerson Process Management R. Reimer Rockwell Automation N. Sands E I du Pont H. Sasajima Yamatake Corp. T. Schnaare Rosemount, Inc. J. Tatera Consultant I. Verhappen MTL Instrument Group R. Webb Consultant W. Weidman Parsons Energy & Chemicals Group J. Weiss Applied Control Solutions LLC M. Widmeyer Consultant M. Zielinski Emerson Process Management
  • 17. – 7 – ANSI/ISA–62443-1-1 (99.01.01)–2007 Copyright 2007 ISA. All rights reserved. Table of Contents Foreword...................................................................................................................... 11 Introduction ................................................................................................................. 13 1 Scope ..................................................................................................................... 15 2 Normative References .......................................................................................... 18 3 Definitions.............................................................................................................. 19 3.1 Introduction...................................................................................................................................19 3.2 Terms ...........................................................................................................................................19 3.3 Abbreviations ................................................................................................................................32 4 The Situation ......................................................................................................... 33 4.1 General.........................................................................................................................................33 4.2 Current Systems...........................................................................................................................33 4.3 Current Trends .............................................................................................................................34 4.4 Potential Impact............................................................................................................................34 5 Concepts................................................................................................................ 36 5.1 General.........................................................................................................................................36 5.2 Security Objectives .......................................................................................................................36 5.3 Defense in Depth..........................................................................................................................37 5.4 Security Context ...........................................................................................................................37 5.5 Threat-Risk Assessment ..............................................................................................................39 5.6 Security Program Maturity ............................................................................................................46 5.7 Policies .........................................................................................................................................52 5.8 Security Zones..............................................................................................................................57 5.9 Conduits........................................................................................................................................58 5.10 Security Levels ..........................................................................................................................60 5.11 Security Level Lifecycle.............................................................................................................64 6 Models.................................................................................................................... 69 6.1 General.........................................................................................................................................69 6.2 Reference Models.........................................................................................................................69
  • 18. ANSI/ISA–62443-1-1 (99.01.01)–2007 – 8 – Copyright 2007 ISA. All rights reserved. 6.3 Asset Models ................................................................................................................................73 6.4 Reference Architecture.................................................................................................................78 6.5 Zone and Conduit Model ..............................................................................................................78 6.6 Model Relationships .....................................................................................................................89
  • 19. – 9 – ANSI/ISA–62443-1-1 (99.01.01)–2007 Copyright 2007 ISA. All rights reserved. Figures Figure 1 – Comparison of Objectives..........................................................................................................36 Figure 2 – Context Element Relationships..................................................................................................38 Figure 3 – Context Model............................................................................................................................38 Figure 4 – Integration of Business and IACS Cyber Security......................................................................47 Figure 5 – Cyber Security Level over Time .................................................................................................48 Figure 6 – Integration of Resources to Develop the CSMS ........................................................................49 Figure 7 – Conduit Example........................................................................................................................59 Figure 8 – Security Level Lifecycle..............................................................................................................65 Figure 9 – Security Level Lifecycle – Assess Phase...................................................................................66 Figure 10 – Security Level Lifecycle – Implement Phase............................................................................67 Figure 11 – Security Level Lifecycle – Maintain Phase...............................................................................68 Figure 12 – Reference Model for ISA99 Standards ....................................................................................70 Figure 13 – SCADA Reference Model ........................................................................................................70 Figure 14 – Process Manufacturing Asset Model Example ........................................................................74 Figure 15 – SCADA System Asset Model Example....................................................................................75 Figure 16 – Reference Architecture Example .............................................................................................78 Figure 17 – Multiplant Zone Example..........................................................................................................80 Figure 18 – Separate Zones Example ........................................................................................................81 Figure 19 – SCADA Zone Example.............................................................................................................82 Figure 20 – SCADA Separate Zones Example ...........................................................................................83 Figure 21 – Enterprise Conduit ...................................................................................................................86 Figure 22 – SCADA Conduit Example ........................................................................................................87 Figure 23 – Model Relationships.................................................................................................................89
  • 20. ANSI/ISA–62443-1-1 (99.01.01)–2007 – 10 – Copyright 2007 ISA. All rights reserved. Tables Table 1 – Types of Loss by Asset Type ......................................................................................................41 Table 2 – Security Maturity Phases.............................................................................................................49 Table 3 – Concept Phase............................................................................................................................50 Table 4 – Functional Analysis Phase ..........................................................................................................50 Table 5 – Implementation Phase ................................................................................................................51 Table 6 – Operations Phase........................................................................................................................51 Table 7 – Recycle and Disposal Phase.......................................................................................................52 Table 8 – Security Levels ............................................................................................................................60
  • 21. – 11 – ANSI/ISA–62443-1-1 (99.01.01)–2007 Copyright 2007 ISA. All rights reserved. Foreword This is the first in a series of ISA standards that addresses the subject of security for industrial automation and control systems. The focus is on the electronic security of these systems, commonly referred to as cyber security. This Part 1 standard describes the basic concepts and models related to cyber security. This standard is structured to follow ISO/IEC directives part 2 for standards development as closely as possible. An introduction before the first numbered clause describes the range of coverage of the entire series of standards. It defines industrial automation and control systems and provides various criteria to determine whether a particular item is included within the scope of the standards. Clause 1 defines the scope of this standard. Clause 2 lists normative references that are indispensable for the application of this document. Clause 3 is a list of terms and definitions used in this standard. Most are drawn from established references, but some are derived for the purpose of this standard. Clause 4 provides an overview of the current situation with respect to the security of industrial automation and control systems, including trends and their potential impact. Clause 5 contains a broad description of the subject and the basic concepts that establish the scope of industrial automation and control systems security. Many of these concepts are well established within the security discipline, but their applicability to industrial control systems may not have been clearly described. In some cases the nature of industrial control systems leads to an interpretation that may be different from that used for more general information technology applications. Clause 6 describes a series of models that are used to apply the basic concepts of security for industrial automation 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 control system applications. The ISA99 Series Standards in the ISA99 series address the application of these concepts and models in areas such as security program definition and minimum security requirements. The series includes the following standards. 1. ISA99.00.01 – Part 1: Terminology, Concepts and Models Part 1 (this standard) establishes the context for all of the remaining standards in the series by defining a common set of terminology, concepts and models for electronic security in the industrial automation and control systems environment. 2. ISA99.00.02 – Part 2: Establishing an Industrial Automation and Control System Security Program Part 2 will describe the elements of a cyber security management system and provide guidance for their application to industrial automation and control systems. 3. ISA99.00.03 – Part 3: Operating an Industrial Automation and Control System Security Program Part 3 will address how to operate a security program after it is designed and implemented. This includes definition and application of metrics to measure program effectiveness. 4. ISA99.00.04 – Part 4: Technical Security Requirements for Industrial Automation and Control Systems
  • 22. ANSI/ISA–62443-1-1 (99.01.01)–2007 – 12 – Copyright 2007 ISA. All rights reserved. Part 4 will define the characteristics of industrial automation and control systems that differentiate them from other information technology systems from a security point of view. Based on these characteristics, the standard will establish the security requirements that are unique to this class of systems. The relationship between the standards in this series is shown in the following diagram: Relationships of the ISA99 Standards In addition, the ISA99 committee has produced two technical reports on the subject of electronic security within the industrial automation and control systems environment. 1. ANSI/ISA-TR99.00.01-2007 – Technologies for Protecting Manufacturing and Control Systems Technical Report 1, updated from the original 2004 version, describes various security technologies in terms of their applicability for use with industrial automation and control systems. This technical report will be updated periodically to reflect changes in technology. 2. ANSI/ISA-TR99.00.02-2004 – Integrating Electronic Security into the Manufacturing and Control Systems Environment Technical Report 2 describes how electronic security can be integrated into industrial automation and control systems. The contents of this technical report will be superseded with the completion of the Part 2 standard. ISA99.00.02 – Part 2: . . Establishing an Industrial Automation and Control System Security Program ISA99.00.03 – Part 3: Operating an Industrial Automation and Control System Security Program ISA99.00.04 – Part 4: Technical Security Requirements for Industrial Automation and Control Systems ISA99.00.01– Part 1: . . Terminology, Concepts and Models
  • 23. – 13 – ANSI/ISA–62443-1-1 (99.01.01)–2007 Copyright 2007 ISA. All rights reserved. Introduction The subject of this standard is security for industrial automation and control systems. In order to address a range of applications (i.e., industry types), each of the terms in this description have been interpreted very broadly. The term industrial automation and control systems (IACS) includes control systems used in manufacturing and processing plants and facilities, building environmental control systems, geographically dispersed operations such as utilities (i.e., electricity, gas, and water), pipelines and petroleum production and distribution facilities, and other industries and applications such as transportation networks, that use automated or remotely controlled or monitored assets. The term security is considered here to mean the prevention of illegal or unwanted penetration, intentional or unintentional interference with the proper and intended operation, or inappropriate access to confidential information in industrial automation and control systems. Electronic security, the particular focus of this standard, includes computers, networks, operating systems, applications and other programmable configurable components of the system. The audience for this standard includes all users of industrial automation and control systems (including facility operations, maintenance, engineering, and corporate components of user organizations), manufacturers, suppliers, government organizations involved with, or affected by, control system cyber security, control system practitioners, and security practitioners. Because mutual understanding and cooperation between information technology (IT) and operations, engineering, and manufacturing organizations is important for the overall success of any security initiative, this standard is also a reference for those responsible for the integration of industrial automation and control systems and enterprise networks. Typical questions addressed by this Part 1 standard include: a) What is the general scope of application for “industrial automation and control systems security”? b) How can the needs and requirements of a security system be defined using consistent terminology? c) What are 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? d) How can the components of an industrial automation and control system be grouped or classified for the purpose of defining and managing security? e) What are the different electronic security objectives for control system applications? f) How can these objectives be established and codified? Each of these questions is addressed in detail in subsequent clauses of this standard.
  • 24. Copyright 2007 ISA. All rights reserved. This page intentionally left blank.
  • 25. – 15 – ANSI/ISA–62443-1-1 (99.01.01)–2007 Copyright 2007 ISA. All rights reserved. 1 Scope This standard defines the terminology, concepts and models for industrial automation and control systems (IACS) security. It establishes the basis for the remaining standards in the ISA99 series. To fully articulate the systems and components the ISA99 standards address, the range of coverage may be defined and understood from several perspectives, including: a) range of functionality included b) specific systems and interfaces c) criteria for selecting included activities d) criteria for selecting included assets Each of these is described in the following paragraphs. Functionality Included The scope of this standard can be described in terms of the range of functionality within an organization’s information and automation systems. This functionality is typically described in terms of one or more models. This standard is focused primarily on industrial automation and control, as described in a reference model (see clause 6). Business planning and logistics systems are not explicitly addressed within the scope of this standard, although the integrity of data exchanged between business and industrial systems is considered. Industrial automation and control includes the supervisory control components typically found in process industries. It also includes SCADA (supervisory control and data acquisition) systems that are commonly used by organizations that operate in critical infrastructure industries. These include: a) electricity transmission and distribution b) gas and water distribution networks c) oil and gas production operations d) gas and liquid transmission pipelines This is not an exclusive list. SCADA systems may also be found in other critical and non-critical infrastructure industries.
  • 26. ANSI/ISA–62443-1-1 (99.01.01)–2007 – 16 – Copyright 2007 ISA. All rights reserved. Systems and interfaces In encompassing all industrial automation and control systems, this standard covers systems that can affect or influence the safe, secure, and reliable operation of industrial processes. They include, but are not limited to: a) Industrial control systems and their associated communications networks 1 , including distributed control systems (DCSs), programmable logic controllers (PLCs), remote terminal units (RTUs), intelligent electronic devices, SCADA systems, networked electronic sensing and control, metering and custody transfer systems, and monitoring and diagnostic systems. (In this context, industrial control systems include basic process control system and safety-instrumented system [SIS] functions, whether they are physically separate or integrated.) b) Associated systems at level 3 or below of the reference model described in clause 6. Examples include advanced or multivariable control, online optimizers, dedicated equipment monitors, graphical interfaces, process historians, manufacturing execution systems, pipeline leak detection systems, work management, outage management, and electricity energy management systems. c) Associated internal, human, network, software, machine or device interfaces used to provide control, safety, manufacturing, or remote operations functionality to continuous, batch, discrete, and other processes. Activity-based criteria ANSI/ISA-95.00.03 [5, Annex A] defines a set of criteria for defining activities associated with manufacturing operations. A similar list has been developed for determining the scope of this standard. A system should be considered to be within the range of coverage of these standards if the activity it performs is necessary for any of the following: a) predictable operation of the process b) process or personnel safety c) process reliability or availability d) process efficiency e) process operability f) product quality g) environmental protection h) regulatory compliance i) product sales or custody transfer. 1 The term “communications networks” includes all types of communications media, including various types of wireless communications. A detailed description of the use of wireless communications in industrial automation systems is beyond the scope of this standard. Wireless communication techniques are specifically mentioned only in situations where their use or application may change the nature of the security applied or required.
  • 27. – 17 – ANSI/ISA–62443-1-1 (99.01.01)–2007 Copyright 2007 ISA. All rights reserved. Asset-based criteria The coverage of this standard includes those systems in assets that meet any of the following criteria, or whose security is essential to the protection of other assets that meet these criteria: a) The asset has economic value to a manufacturing or operating process. b) The asset performs a function necessary to operation of a manufacturing or operating process. c) The asset represents intellectual property of a manufacturing or operating process. d) The asset is necessary to operate and maintain security for a manufacturing or operating process. e) The asset is necessary to protect personnel, contractors, and visitors involved in a manufacturing or operating process. f) The asset is necessary to protect the environment. g) The asset is necessary to protect the public from events caused by a manufacturing or operating process. h) The asset is a legal requirement, especially for security purposes of a manufacturing or operating process. i) The asset is needed for disaster recovery. j) The asset is needed for logging security events. This range of coverage 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, environmental contamination, and/or economic loss or impact on an entity or on local or national security.
  • 28. ANSI/ISA–62443-1-1 (99.01.01)–2007 – 18 – Copyright 2007 ISA. All rights reserved. 2 Normative References The following referenced documents are indispensable for the application of this standard. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies. ANSI/ISA-95.00.01-2000, Enterprise-Control System Integration Part 1: Models and Terminology, Clause 5 (Hierarchy Models) ISA-88.01-1995 (R 2006), Batch Control Part 1: Models and Terminology, Clause 4.2 (Physical Model) ISO/IEC 15408-1: Information technology — Security techniques — Evaluation criteria for IT security – Part 1: Introduction and General Model, Clause 4 (General Model)
  • 29. – 19 – ANSI/ISA–62443-1-1 (99.01.01)–2007 Copyright 2007 ISA. All rights reserved. 3 Definitions 3.1 Introduction This clause defines the terms and abbreviations used in this standard. Wherever possible, definitions have been adapted from those used in established industry sources. Those definitions are marked to indicate the reference listed in the bibliography. Some definitions have been adapted from more generic definitions used in the IT industry. 3.2 Terms The following terms are referenced in this standard. 3.2.1 access ability and means to communicate with or otherwise interact with a system in order to use system resources. NOTE: Access may involve physical access (authorization to be allowed physically in an area, possession of a physical key lock, PIN code, or access card or biometric attributes that allow access) or logical access (authorization to log in to a system and application, through a combination of logical and physical means) 3.2.2 access control 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 [11]. 3.2.3 accountability 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 [11]. 3.2.4 application software program that performs specific functions initiated by a user command or a process event and that can be executed without access to system control, monitoring, or administrative privileges [9]. 3.2.5 area subset of a site’s physical, geographic, or logical group of assets. NOTE: An area may contain manufacturing lines, process cells, and production units. Areas may be connected to each other by a site local area network and may contain systems related to the operations performed in that area. 3.2.6 asset physical or logical object owned by or under the custodial duties of an organization, having either a perceived or actual value to the organization. NOTE: In the case of industrial automation and control systems the physical assets that have the largest directly measurable value may be the equipment under control. 3.2.7 association cooperative relationship between system entities, usually for the purpose of transferring information between them [11]. 3.2.8 assurance attribute of a system that provides grounds for having confidence that the system operates such that the system security policy is enforced.
  • 30. ANSI/ISA–62443-1-1 (99.01.01)–2007 – 20 – Copyright 2007 ISA. All rights reserved. 3.2.9 attack assault on a system 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 [11]. 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 (including an insider attacking from outside the security perimeter). Potential outside attackers range from amateur pranksters to organized criminals, international terrorists, and hostile governments. 3.2.10 attack tree formal, methodical way of finding ways to attack the security of a system. 3.2.11 audit 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 (See “security audit”) [9]. NOTE: There are three forms of audit. (1) External audits are conducted by parties who are not employees or contractors of the organization. (2) Internal audit are conducted by a separate organizational unit dedicated to internal auditing. (3) Controls self assessments are conducted by peer members of the process automation function. 3.2.12 authenticate 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 information system, or to establish the validity of a transmission. 3.2.13 authentication 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 [9]. 3.2.14 authorization right or a permission that is granted to a system entity to access a system resource [11]. 3.2.15 automated vehicle mobile device that includes a control system allowing it to operate either autonomously or under remote control. 3.2.16 availability probability that an asset, under the combined influence of its reliability, maintainability, and security, will be able to fulfill its required function over a stated period of time, or at a given point in time. 3.2.17 border edge or boundary of a physical or logical security zone. 3.2.18 botnet collection of software robots, or bots, which run autonomously. NOTE: A botnet's originator can control the group remotely, possibly for nefarious purposes. 3.2.19 boundary software, hardware, or other physical barrier that limits access to a system or part of a system [9].
  • 31. – 21 – ANSI/ISA–62443-1-1 (99.01.01)–2007 Copyright 2007 ISA. All rights reserved. 3.2.20 channel specific communication link established within a communication conduit (See “conduit”). 3.2.21 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.2.22 client device or application receiving or requesting services or information from a server application [12]. 3.2.23 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, and human interactions. 3.2.24 communication security (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 [11]. 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. However, cryptographic algorithms and key management methods and processes may not be applicable to some control system applications. 3.2.25 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.2.26 compromise unauthorized disclosure, modification, substitution, or use of information (including plaintext cryptographic keys and other critical security parameters) [13]. 3.2.27 conduit logical grouping of communication assets that protects the security of the channels it contains. NOTE: This is analogous to the way that a physical conduit protects cables from physical damage. 3.2.28 confidentiality assurance that information is not disclosed to unauthorized individuals, processes, or devices [9]. 3.2.29 control center central location used to operate a set of assets. NOTE: Infrastructure industries typically use one or more control centers to supervise or coordinate their operations. If there are multiple control centers (for example, a backup 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. NOTE: In some industries the term “control room” may be more commonly used. 3.2.30 control equipment class that includes distributed control systems, programmable logic controllers, SCADA systems, associated operator interface consoles, and field sensing and control devices used to manage and control the process.
  • 32. ANSI/ISA–62443-1-1 (99.01.01)–2007 – 22 – Copyright 2007 ISA. All rights reserved. NOTE: The term also includes field bus networks where control logic and algorithms are executed on intelligent electronic devices that coordinate actions with each other, as well as systems used to monitor the process and the systems used to maintain the process. 3.2.31 control network time-critical network that is typically connected to equipment that controls physical processes (See “safety network”). NOTE: The control network can be subdivided into zones, and there can be multiple separate control networks within one company or site. 3.2.32 cost value of impact to an organization or person that can be measured. 3.2.33 countermeasure 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 [11]. NOTE: The term “Control” is also used to describe this concept in some contexts. The term countermeasure has been chosen for this standard to avoid confusion with the word control in the context of “process control.” 3.2.34 cryptographic algorithm algorithm based upon the science of cryptography, including encryption algorithms, cryptographic hash algorithms, digital signature algorithms, and key agreement algorithms. 3.2.35 cryptographic key input parameter that varies the transformation performed by a cryptographic algorithm [11]. NOTE: Usually shortened to just "key." 3.2.36 data confidentiality property that information is not made available or disclosed to any unauthorized system entity, including unauthorized individuals, entities, or processes [7]. 3.2.37 data integrity property that data has not been changed, destroyed, or lost in an unauthorized or accidental manner [11]. NOTE: This term deals with constancy of and confidence in data values, not with the information that the values represent or the trustworthiness of the source of the values. 3.2.38 decryption process of changing cipher text into plaintext using a cryptographic algorithm and key (See “encryption”) [11]. 3.2.39 defense in depth provision of multiple security protections, especially in layers, with the intent to delay if not prevent an attack. NOTE: Defense in depth implies layers of security and detection, even on single systems, and provides the following features: a. attackers are faced with breaking through or bypassing each layer without being detected b. a flaw in one layer can be mitigated by capabilities in other layers c. system security becomes a set of layers within the overall network security. 3.2.40 demilitarized zone perimeter network segment that is logically between internal and external networks [9].
  • 33. – 23 – ANSI/ISA–62443-1-1 (99.01.01)–2007 Copyright 2007 ISA. All rights reserved. NOTE: The purpose of a demilitarized zone 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 network from outside attacks. NOTE: In the context of industrial automation and control systems, the term “internal network” is typically applied to the network or segment that is the primary focus of protection. For example, a control network could be considered “internal” when connected to an “external” business network. 3.2.41 denial of service prevention or interruption of authorized access to a system resource or the delaying of system operations and functions [11]. NOTE: In the context of industrial automation and control systems, denial of service can refer to loss of process function, not just loss of data communications. 3.2.42 digital signature result of a cryptographic transformation of data which, when properly implemented, provides the services of origin authentication, data integrity, and signer non-repudiation [12]. 3.2.43 distributed control system type of control system in which the system elements are dispersed but operated in a coupled manner. NOTE: Distributed control systems may have shorter coupling time constants than those typically found in SCADA systems. NOTE: Distributed 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, and warehousing. 3.2.44 domain 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 [11]. 3.2.45 eavesdropping monitoring or recording of communicated information by unauthorized parties. 3.2.46 electronic security actions required to preclude unauthorized use of, denial of service to, modifications to, disclosure of, loss of revenue from, or destruction of critical systems or informational assets. NOTE: The objective is to reduce the risk of causing personal injury or endangering public health, losing public or consumer confidence, disclosing sensitive assets, failing to protect business assets or failing to comply with regulations. These concepts are applied to any system in the production process and include both stand-alone 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. Electronic security includes the concepts of identification, authentication, accountability, authorization, availability, and privacy. 3.2.47 encryption cryptographic transformation of plaintext into ciphertext that conceals the data’s original meaning to prevent it from being known or used (See “decryption”) [11]. NOTE: 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.2.48 enterprise business entity that produces or transports products or operates and maintains infrastructure services. 3.2.49 enterprise system collection of information technology elements (i.e., hardware, software and services) installed with the intent to facilitate an organization’s business process or processes (administrative or project).
  • 34. ANSI/ISA–62443-1-1 (99.01.01)–2007 – 24 – Copyright 2007 ISA. All rights reserved. 3.2.50 equipment under control equipment, machinery, apparatus or plant used for manufacturing, process, transportation, medical or other activities [14]. 3.2.51 field I/O network communications link (wired or wireless) that connects sensors and actuators to the control equipment. 3.2.52 firewall inter-network connection device that restricts data communication traffic between two connected networks [11]. NOTE: A firewall may be either an application installed on a general-purpose computer or a dedicated platform (appliance) that forwards or rejects/drops packets on a network. Typically firewalls are used to define zone borders. Firewalls generally have rules restricting which ports are open. 3.2.53 gateway 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 [11]. NOTE: Also described as an intermediate system that is the translation interface between two computer networks. 3.2.54 geographic site subset of an enterprise’s physical, geographic, or logical group of assets. NOTE: A geographic site may contain areas, manufacturing lines, process cells, process units, control centers, and vehicles and may be connected to other sites by a wide area network. 3.2.55 guard gateway that is interposed between two networks (or computers or other information systems) operating at different security levels (one network is usually more secure than the other) and is trusted to mediate all information transfers between the two networks, either to ensure that no sensitive information from the more secure network is disclosed to the less secure network, or to protect the integrity of data on the more secure network [11]. 3.2.56 host computer that is attached to a communication subnetwork or inter-network and can use services provided by the network to exchange data with other attached systems [11]. 3.2.57 industrial automation and control systems collection of personnel, hardware, and software that can affect or influence the safe, secure, and reliable operation of an industrial process. NOTE: These systems include, but are not limited to: a. industrial control systems, including distributed control systems (DCSs), programmable logic controllers (PLCs), remote terminal units (RTUs), intelligent electronic devices, 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 and safety-instrumented system [SIS] functions, whether they are physically separate or integrated.) b. associated information systems such as advanced or multivariable control, online optimizers, dedicated equipment monitors, graphical interfaces, process historians, manufacturing execution systems, and plant information management systems. c. associated internal, human, network, or machine interfaces used to provide control, safety, and manufacturing operations functionality to continuous, batch, discrete, and other processes. 3.2.58 initial risk risk before controls or countermeasures have been applied (See “risk”).
  • 35. – 25 – ANSI/ISA–62443-1-1 (99.01.01)–2007 Copyright 2007 ISA. All rights reserved. 3.2.59 insider “trusted” person, employee, contractor, or supplier who has information that is not generally known to the public (See “outsider”). 3.2.60 integrity 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 [9]. NOTE: In a formal security mode, integrity is often interpreted more narrowly to mean protection against unauthorized modification or destruction of information. 3.2.61 interception capture and disclosure of message contents 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.2.62 interface logical entry or exit point that provides access to the module for logical information flows. 3.2.63 intrusion unauthorized act of compromising a system (See “attack”). 3.2.64 intrusion detection 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.2.65 IP address address of a computer or device that is assigned for identification and communication using the Internet Protocol and other protocols. 3.2.66 ISO International Organization for Standardization 1 . 3.2.67 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 [11]. 3.2.68 lines, units, cells lower-level elements that perform manufacturing, field device control, or vehicle functions. NOTE: 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. 3.2.69 local area network communications network designed to connect computers and other intelligent devices in a limited geographic area (typically less than 10 kilometers) [10]. 3.2.70 malicious code programs or code written for the purpose of gathering information about systems or users, destroying system data, providing a foothold for further intrusion into a system, falsifying system data and reports, or providing time-consuming irritation to system operations and maintenance personnel. 1 ISO is not an acronym. The name derives from the Greek word iso, which means equal.
  • 36. ANSI/ISA–62443-1-1 (99.01.01)–2007 – 26 – Copyright 2007 ISA. All rights reserved. NOTE: Malicious code attacks can take the form of viruses, worms, Trojan Horses, or other automated exploits. NOTE: Malicious code is also often referred to as “malware.” 3.2.71 manufacturing operations collection of production, maintenance, and quality assurance operations and their relationship to other activities of a production facility. NOTE: Manufacturing operations include: a. manufacturing or processing facility activities that coordinate the personnel, equipment, and material involved in the conversion of raw materials or parts into products. b. functions that may be performed by physical equipment, human effort, and information systems. c. managing information about the schedules, use, capability, definition, history, and status of all resources (personnel, equipment, and material) within the manufacturing facility. 3.2.72 nonrepudiation security service that provides protection against false denial of involvement in a communication [11]. 3.2.73 OPC set of specifications for the exchange of information in a process control environment. NOTE: The abbreviation “OPC” originally came from “OLE for Process Control”, where “OLE” was short for “Object Linking and Embedding.” 3.2.74 outsider person or group not “trusted” with inside access, who may or may not be known to the targeted organization (See “insider”). NOTE: Outsiders may or may not have been insiders at one time. 3.2.75 penetration successful unauthorized access to a protected system resource [11]. 3.2.76 phishing type of security attack that lures victims to reveal information, by presenting a forged email to lure the recipient to a web site that looks like it is associated with a legitimate source. 3.2.77 plaintext unencoded data that is input to and transformed by an encryption process, or that is output by a decryption process [11]. 3.2.78 privilege authorization or set of authorizations to perform specific functions, especially in the context of a computer operating system [11]. NOTE: Examples of functions that are controlled through the use of privilege include acknowledging alarms, changing setpoints, modifying control algorithms. 3.2.79 process series of operations performed in the making, treatment or transportation of a product or material. NOTE: This standard makes extensive use of the term “process” to describe the equipment under control of the industrial automation and control system. 3.2.80 protocol set of rules (i.e., formats and procedures) to implement and control some type of association (e.g., communication) between systems [11].
  • 37. – 27 – ANSI/ISA–62443-1-1 (99.01.01)–2007 Copyright 2007 ISA. All rights reserved. 3.2.81 reference model structure that allows the modules and interfaces of a system to be described in a consistent manner. 3.2.82 reliability ability of a system to perform a required function under stated conditions for a specified period of time. 3.2.83 remote access use of systems that are inside the perimeter of the security zone being addressed from a different geographical location with the same rights as when physically present at the location. NOTE: The exact definition of “remote” can vary according to situation. For example, access may come from a location that is remote to the specific zone, but still within the boundaries of a company or organization. This might represent a lower risk than access that originates from a location that is remote and outside of a company’s boundaries. 3.2.84 remote client asset outside the control network that is temporarily or permanently connected to a host inside the control network via a communication link in order to directly or indirectly access parts of the control equipment on the control network. 3.2.85 repudiation denial by one of the entities involved in a communication of having participated in all or part of the communication. 3.2.86 residual risk the remaining risk after the security controls or countermeasures have been applied. 3.2.87 risk expectation of loss expressed as the probability that a particular threat will exploit a particular vulnerability with a particular consequence [11]. 3.2.88 risk assessment process that systematically identifies potential vulnerabilities to valuable system resources and threats to those resources, quantifies loss exposures and consequences based on probability of occurrence, and (optionally) recommends how to allocate resources to countermeasures to minimize total exposure. NOTE: Types of resources include physical, logical and human. NOTE: Risk assessments are often combined with vulnerability assessments to identify vulnerabilities and quantify the associated risk. They are carried out initially and periodically to reflect changes in the organization's risk tolerance, vulnerabilities, procedures, personnel and technological changes. 3.2.89 risk management process of identifying and applying countermeasures commensurate with the value of the assets protected based on a risk assessment [9]. 3.2.90 risk mitigation controls combination of countermeasures and business continuity plans. 3.2.91 role-based access control form of identity-based access control where the system entities that are identified and controlled are functional positions in an organization or process [11]. 3.2.92 router gateway between two networks at OSI layer 3 and that relays and directs data packets through that inter- network. The most common form of router passes Internet Protocol (IP) packets [11].
  • 38. ANSI/ISA–62443-1-1 (99.01.01)–2007 – 28 – Copyright 2007 ISA. All rights reserved. 3.2.93 safety freedom from unacceptable risk [2]. 3.2.94 safety-instrumented system system used to implement one or more safety-instrumented functions [2]. Note: A safety-instrumented system is composed of any combination of sensor(s), logic solver(s), and actuator(s). 3.2.95 safety integrity level discrete level (one out of four) for specifying the safety integrity requirements of the safety-instrumented functions to be allocated to the safety-instrumented systems [2]. NOTE: Safety integrity level 4 has the highest level of safety integrity; safety integrity level 1 has the lowest. 3.2.96 safety network network that connects safety-instrumented systems for the communication of safety-related information. 3.2.97 secret condition of information being protected from being known by any system entities except those intended to know it [11]. 3.2.98 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 [11]. 4. capability of a computer-based system to provide adequate confidence that unauthorized persons and systems can neither modify the software and its data nor gain access to the system functions, and yet to ensure that this is not denied to authorized persons and systems [14]. 5. prevention of illegal or unwanted penetration of or interference with the proper and intended operation of an industrial automation and control system. NOTE: Measures can be controls related to physical security (controlling physical access to computing assets) or logical security (capability to login to a given system and application.) 3.2.99 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, the system elements required to implement the services, and the performance levels required in the elements to deal with the threat environment [11]. NOTE: In this context, security architecture would be an architecture to protect the control network from intentional or unintentional security events. 3.2.100 security audit 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 [7]. 3.2.101 security components assets such as firewalls, authentication modules, or encryption software used to improve the security performance of an industrial automation and control system (See “countermeasure”). 3.2.102 security control See “countermeasure.” 3.2.103 security event occurrence in a system that is relevant to the security of the system [11].
  • 39. – 29 – ANSI/ISA–62443-1-1 (99.01.01)–2007 Copyright 2007 ISA. All rights reserved. 3.2.104 security function function of a zone or conduit to prevent unauthorized electronic intervention that can impact or influence the normal functioning of devices and systems within the zone or conduit. 3.2.105 security incident adverse event in a system or network or the threat of the occurrence of such an event [10]. NOTE: The term “near miss” is sometimes used to describe an event that could have been an incident under slightly different circumstances. 3.2.106 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 [11]. 3.2.107 security level level corresponding to the required effectiveness of countermeasures and inherent security properties of devices and systems for a zone or conduit based on assessment of risk for the zone or conduit [13]. 3.2.108 security objective aspect of security which to achieve is the purpose and objective of using certain mitigation measures, such as confidentiality, integrity, availability, user authenticity, access authorization, accountability. 3.2.109 security perimeter boundary (logical or physical) 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 [11]. 3.2.110 security performance 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 security measures remain effective and appropriate. NOTE: Tests, audits, tools, measures, or other methods are required to evaluate security practice performance. 3.2.111 security policy set of rules that specify or regulate how a system or organization provides security services to protect its assets [11]. 3.2.112 security procedures definitions of exactly how practices are implemented and executed. NOTE: Security procedures are implemented through personnel training and actions using currently available and installed technology. 3.2.113 security program a combination of 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.2.114 security services mechanisms used to provide confidentiality, data integrity, authentication, or no repudiation of information [11]. 3.2.115 security violation act or event that disobeys or otherwise breaches security policy through an intrusion or the actions of a well-meaning insider.
  • 40. ANSI/ISA–62443-1-1 (99.01.01)–2007 – 30 – Copyright 2007 ISA. All rights reserved. 3.2.116 security zone grouping of logical or physical assets that share common security requirements. NOTE: All unqualified uses of the word “zone” in this standard should be assumed to refer to a security zone. 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 in the sense that they can be comprised of a collection of subzones. 3.2.117 sensors and actuators measuring or actuating elements connected to process equipment and to the control system. 3.2.118 server device or application that provides information or services to client applications and devices [11]. 3.2.119 sniffing See “interception.” 3.2.120 spoof pretending to be an authorized user and performing an unauthorized action [11]. 3.2.121 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. NOTE: Supervisory control systems are also used within batch, continuous, and discrete manufacturing plants to centralize monitoring and control activities for these sites. 3.2.122 system interacting, interrelated, or interdependent elements forming a complex whole. 3.2.123 system software special software 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 [12]. 3.2.124 threat potential for violation of security, which exists when there is a circumstance, capability, action, or event that could breach security and cause harm [11]. 3.2.125 threat action assault on system security [11]. 3.2.126 traffic analysis inference of information from observable characteristics of data flow(s), even when the data are 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.2.127 trojan horse 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 [11]. 3.2.128 use case technique for capturing potential functional requirements that employs the use of one or more scenarios that convey how the system should interact with the end user or another system to achieve a specific goal.
  • 41. – 31 – ANSI/ISA–62443-1-1 (99.01.01)–2007 Copyright 2007 ISA. All rights reserved. NOTE: Typically use cases treat the system as a black box, and the interactions with the system, including system responses, are as perceived from outside of the system. Use cases are popular because they simplify the description of requirements, and avoid the problem of making assumptions about how this functionality will be accomplished. 3.2.129 user person, organization entity, or automated process that accesses a system, whether authorized to do so or not [11]. 3.2.130 virus self-replicating or self-reproducing program that spreads by inserting copies of itself into other executable code or documents. 3.2.131 vulnerability 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 [11]. 3.2.132 wide area network communications network designed to connect computers, networks and other devices over a large distance, such as across the country or world [12]. 3.2.133 wiretapping attack that intercepts and accesses data and other information contained in a flow in a communication system [11]. NOTE: 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 a gateway or subnetwork switch. NOTE: "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.2.134 worm 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 [11]. 3.2.135 zone See “security zone.”
  • 42. ANSI/ISA–62443-1-1 (99.01.01)–2007 – 32 – Copyright 2007 ISA. All rights reserved. 3.3 Abbreviations This subclause defines the abbreviations used in this standard. ANSI American National Standards Institute CIA Confidentiality, Integrity, and Availability CN Control Network COTS Commercial off the Shelf CSMS Cyber Security Management System DCS Distributed Control System DDoS Distributed Denial of Service DoS Denial of Service DMZ Demilitarized Zone FIPS U. S. Federal Information Processing Standards IACS Industrial Automation and Control Systems IEC International Electrotechnical Commission IEEE Institute of Electrical and Electronics Engineers I/O Input/Output IP Internet Protocol ISA The Instrumentation, Systems, and Automation Society IT Information Technology LAN Local Area Network NASA U. S. National Aeronautics and Space Administration NOST NASA Office of Standards and Technology OSI Open Systems Interconnect PLC Programmable Logic Controller RTU Remote Terminal Unit SCADA Supervisory Control and Data Acquisition SIL Safety Integrity Level SIS Safety-Instrumented System WAN Wide Area Network
  • 43. – 33 – ANSI/ISA–62443-1-1 (99.01.01)–2007 Copyright 2007 ISA. All rights reserved. 4 The Situation 4.1 General Industrial automation and control systems operate within a complex environment. Organizations are increasingly sharing information between business and industrial automation systems, and partners in one business venture may be competitors in another. However, because industrial automation and control systems equipment connects directly to a process, loss of trade secrets and interruption in the flow of information are not the only consequences of a security breach. The potential loss of life or production, environmental damage, regulatory violation, and compromise to operational safety are far more serious consequences. These may have ramifications beyond the targeted organization; 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, industrial automation and control systems are often integrated with other business systems. Modifying or testing operational systems has led to unintended electronic effects on system operations. Personnel from outside the control systems area increasingly perform security testing on the systems, exacerbating the number and consequence of these effects. Combining all these factors, it is easy to see that the potential of someone gaining unauthorized or damaging access to an industrial process is not trivial. Although technology changes and partner relationships may be good for business, they increase the potential risk of compromising security. As the threats to businesses increase, so does the need for security. 4.2 Current Systems Industrial automation and control systems have evolved from individual, isolated computers with proprietary operating systems and networks to interconnected systems and applications employing commercial off the shelf (COTS) technology (i.e., operating systems and protocols). These systems are now being integrated with enterprise systems and other business applications through various communication networks. This increased level of integration provides significant business benefits, including: a) increased visibility of industrial control system activities (work in process, equipment status, production schedules) and integrated processing systems from the business level, contributing to the improved ability to conduct analyses to drive down production costs and improve productivity b) integrated manufacturing and production systems that have more direct access to business level information, enabling a more responsive enterprise c) common interfaces that reduce overall support costs and permit remote support of production processes d) remote monitoring of the process control systems that reduces support costs and allows problems to be solved more quickly. It is possible to define standards for models, terms, and information exchanges that allow the industrial automation and control systems community to share information in a consistent way. However, this ability to exchange information increases vulnerability to misuse and attack by individuals with malicious intent and introduces potential risks to the enterprise using industrial automation and control systems.
  • 44. ANSI/ISA–62443-1-1 (99.01.01)–2007 – 34 – Copyright 2007 ISA. All rights reserved. Industrial automation and control systems configurations can be very complex in terms of physical hardware, programming, and communications. This complexity can often make it difficult to determine: a) who is authorized to access electronic information b) when a user can have access to the information c) what data or functions a user should be able to access d) where the access request originates e) how the access is requested. 4.3 Current Trends Several trends contribute to the increased emphasis on the security of industrial automation and control systems: a) In recent years there has been a marked increase in malicious code attacks on business and personal computer systems. Businesses have reported more unauthorized attempts (either intentional or unintentional) to access electronic information each year than in the previous year. b) Industrial automation and control systems are moving toward COTS operating systems and protocols and are interconnecting with business networks. This is making these systems susceptible to the same software attacks as are present in business and desktop devices. c) Tools to automate attacks are commonly available on the Internet. The external threat from the use of these tools now includes cyber criminals and cyber terrorists who may have more resources and knowledge to attack an industrial automation and control system. d) The use of joint ventures, alliance partners, and outsourced services in the industrial sector has led to a more complex situation with respect to the number of organizations and groups contributing to security of the industrial automation and control system. These practices must be taken into account when developing security for these systems. e) The focus on unauthorized access has broadened from amateur attackers or disgruntled employees to deliberate criminal or terrorist activities aimed at impacting large groups and facilities. f) The adoption of industry standard protocols such as Internet Protocol (IP) for communication between industrial automation and control systems and field devices. Implementing IP exposes these systems to the same vulnerabilities as business systems at the network layer. These trends have combined to significantly increase organization’s risks associated with the design and operation of their industrial automation and control systems. At the same time, electronic security of industrial control systems has become a more significant and widely acknowledged concern. This shift requires more structured guidelines and procedures to define electronic security applicable to industrial automation and control systems, as well as the respective connectivity to other systems. 4.4 Potential Impact People who know the features of open operating systems and networks could potentially intrude into console devices, remote devices, databases, and, in some cases, control platforms. The effect of intruders on industrial automation and control systems may include: a) unauthorized access, theft, or misuse of confidential information b) publication of information to unauthorized destinations c) loss of integrity or reliability of process data and production information
  • 45. – 35 – ANSI/ISA–62443-1-1 (99.01.01)–2007 Copyright 2007 ISA. All rights reserved. d) loss of system availability e) process upsets leading to compromised process functionality, inferior product quality, lost production capacity, compromised process safety, or environmental releases f) equipment damage g) personal injury h) violation of legal and regulatory requirements i) risk to public health and confidence j) threat to a nation’s security.
  • 46. ANSI/ISA–62443-1-1 (99.01.01)–2007 – 36 – Copyright 2007 ISA. All rights reserved. 5 Concepts 5.1 General This clause describes several underlying concepts that form the basis for the following clauses and for other standards in the ISA99 series. Specifically, it addresses questions such as: a) What are the major concepts that are used to describe security? b) What are the important concepts that form the basis for a comprehensive security program? 5.2 Security Objectives Information security has traditionally focused on achieving three objectives, confidentiality, integrity, and availability, which are often abbreviated by the acronym "CIA." An information technology security strategy for typical “back office” or business systems may place the primary focus on confidentiality and the necessary access controls needed to achieve it. Integrity might fall to the second priority, with availability as the lowest. In the industrial automation and control systems environment, the general priority of these objectives is often different. Security in these 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 industrial automation and control systems. Therefore, integrity is often second in importance. Usually confidentiality is of lesser importance, because often the data is raw in form and must be analyzed within context to have any value. The facet of time responsiveness is significant. Control systems can have requirements of system responsiveness in the 1 millisecond range, whereas traditional business systems are able to successfully operate with single or multiple second response times. In some situations the priorities are completely inverted, as shown in Figure 1. Priority Availability Integrity Confidentiality Confidentiality Integrity Availability Industrial Automation & Control Systems General Purpose Information Technology Systems Figure 1 – Comparison of Objectives
  • 47. – 37 – ANSI/ISA–62443-1-1 (99.01.01)–2007 Copyright 2007 ISA. All rights reserved. Depending on the circumstances, the integrity of the system could also have the highest priority. Certain operational requirements will cause individual components or the systems as a whole to have different priorities for the objectives (i.e., integrity or availability concerns may outweigh confidentiality, or vice versa). This may in turn lead an organization to deploy different countermeasures to achieve these security objectives. 5.2.1 Foundational Requirements The simple CIA model shown in Figure 1 is not adequate for a full understanding of the requirements for security in industrial automation and control systems. Although it is beyond the scope of this standard to describe an exhaustive list of detailed requirements, there are several basic or foundational requirements that have been identified for industrial automation security. These are: a) Access Control (AC) – Control access to selected devices, information or both to protect against unauthorized interrogation of the device or information. b) Use Control (UC) – Control use of selected devices, information or both to protect against unauthorized operation of the device or use of information. c) Data Integrity (DI) – Ensure the integrity of data on selected communication channels to protect against unauthorized changes. d) Data Confidentiality (DC) – Ensure the confidentiality of data on selected communication channels to protect against eavesdropping. e) Restrict Data Flow (RDF) – Restrict the flow of data on communication channels to protect against the publication of information to unauthorized sources. f) Timely Response to Event (TRE) – Respond to security violations by notifying the proper authority, reporting needed forensic evidence of the violation, and automatically taking timely corrective action in mission critical or safety critical situations. g) Resource Availability (RA) - Ensure the availability of all network resources to protect against denial of service attacks. All of these requirements are within the scope of this standard, although in some cases more detailed normative information will be provided by other standards in the ISA99 series. For example, technical requirements such as Data Integrity and Data Confidentiality will be addressed in detail in the ISA99 Part 4 standard. 5.3 Defense in Depth It is typically not possible to achieve the security objectives through the use of a single countermeasure or technique. A superior approach is to use the concept of defense in depth, which involves applying multiple countermeasures in a layered or stepwise manner. For example, intrusion detection systems can be used to signal the penetration of a firewall. 5.4 Security Context 5.4.1 General The security context forms the basis for the interpretation of terminology and concepts and shows how the various elements of security relate to each other. The term security is considered here to mean the prevention of illegal or unwanted penetration of or interference with the proper and intended operation of an industrial automation and control system. Electronic security includes computer, network, or other programmable components of the system.
  • 48. ANSI/ISA–62443-1-1 (99.01.01)–2007 – 38 – Copyright 2007 ISA. All rights reserved. 5.4.2 A Context Model The context of security is based on the concepts of threats, risks, and countermeasures, as well as the relationships between them. The relationship between these concepts can be shown in a simple model. One such model is described in the international standard ISO/IEC 15408-1 (Common Criteria) [6]. It is reproduced in Figure 2. Owners Countermeasures Risk Assets Threats Threat Agents value wish to minimize impose to to that increase give rise to wish to abuse and/or may damage To reduce Figure 2 – Context Element Relationships A different view of the relationship is shown in Figure 3. This model shows how an expanded set of concepts are related within the two interconnected processes of information security assurance and threat-risk assessment. Assurance Techniques Assurance Confidence Countermeasures Risk Owners produce to minimize require in Evaluation gives evidence of Vulnerabilities Threats Assets require using to Threat-Risk Assessment Information Security Assurance Figure 3 – Context Model
  • 49. – 39 – ANSI/ISA–62443-1-1 (99.01.01)–2007 Copyright 2007 ISA. All rights reserved. 5.5 Threat-Risk Assessment Within the threat-risk assessment process, assets are subject to risks. These risks are in turn minimized through the use of countermeasures, which are applied to address vulnerabilities that are used or exploited by various threats. Each of these elements is described in more detail in the following paragraphs. 5.5.1 Assets Assets are the focus of a security program. They are what are being protected. In order to fully understand the risk to an IACS environment, it is first necessary to create an inventory of the assets that require protection. Assets may be classified as physical, logical or human. a) Physical Assets – Physical assets include any physical component or group of components belonging to an organization. In the industrial environment, these may include control systems, physical network components and transmission media, conveyance systems, walls, rooms, buildings, material, or any other physical objects that are in any way involved with the control, monitoring, or analysis of production processes or in support of the general business. The most significant physical assets are those that make up the equipment that is under the control of the automation system. b) Logical Assets – Logical assets are of an informational nature. They 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, these types of assets can include public reputation, buyer confidence, or other measures that if damaged directly affect the business. Logical assets may be in the form of personal memory, documents, information contained on physical media, or electronic storage records dealing with the informational asset. Logical assets also can include test results, regulatory compliance data, or any other information considered sensitive or proprietary, or that could either provide or yield a competitive advantage. Loss of logical assets often causes very long lasting and damaging effects to an organization. Process automation assets are a special form of logical assets. They contain the automation logic employed in executing the industrial process. These 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 nonphysical (e.g., unauthorized modification) means, and result in some sort of loss of integrity or availability to the process itself. c) Human Assets – Human assets include people and the knowledge and skills that they possess associated with their production activities. They can include required certifications, equipment- specific knowledge, or other activities not included in the automated production processes or important skills needed during emergencies. Rarely are processing facilities completely automated and disruption of the operations people could have a major impact on production although the physical and logical systems remain relatively intact. For example, an erroneous plant alarm could cause personnel to initiate shutdown and plant evacuation although nothing was physically or logically disrupted in the industrial automation and control systems. Any accident or attack that injures a person would be considered as impacting a human asset.
  • 50. ANSI/ISA–62443-1-1 (99.01.01)–2007 – 40 – Copyright 2007 ISA. All rights reserved. 5.5.1.1 Valuing Assets To meet the qualification of either physical or logical asset, the object must be either owned by or under the custodial duties of the organization. It also must have value to the organization. The value of the asset may be expressed in either qualitative or quantitative terms. Some organizations will also consider qualitative valuation to be adequate reasoning for expressing asset loss in the risk analysis process. a) Quantitative Valuation of Assets – An asset given a quantitative valuation has a precise monetary loss associated with it. This could be 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 the potential impact from a loss. b) Qualitative Valuation of Assets – Qualitative loss typically expresses a more abstract “level” of loss such as a percentage or a relative value such as low impact, high impact, or no impact. Many assets may only be analyzed in terms of qualitative loss. 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. Value may be categorized by the type of loss incurred, either direct or indirect. a) Direct Loss – Direct loss represents the cost of replacing the asset. For a physical asset, this could include the replacement cost for the device itself. Logical assets have comparatively low direct loss when compared with their utility value, because the medium used to store the asset is typically low cost. b) Indirect Loss – Indirect loss represents any loss caused by the loss of the asset that the organization may realize. This could include losses related 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 logical assets are often great. They include loss of public confidence, loss of license to operate because of regulatory violation, and loss of competitive advantage from release of intellectual property (e.g., confidential process technology).
  • 51. – 41 – ANSI/ISA–62443-1-1 (99.01.01)–2007 Copyright 2007 ISA. All rights reserved. 5.5.1.2 Categorization of Loss By combining the information on asset types and valuation, it is possible to show the types of losses for each type of asset. This is summarized in Table 1. Table 1 – Types of Loss by Asset Type Asset Type Direct Loss Indirect Loss Qualitative or Quantitative? Physical Can be high direct loss, represented by the replacement cost for the asset. 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. Downstream effects as a result of loss, including loss of control, loss or damage to other assets, and downtime losses Qualitative or quantitative, may begin with qualitative for high-level risks, and later be quantitative for greater precision Logical Low direct loss, as the storage media are often cheap and easily replaceable High indirect loss, often due to loss of intellectual property, compromise of proprietary procedures, or violation of regulatory compliance. Indirect losses from equipment damage or material release can lead to downtime, rework, reengineering, or other efforts to restore control over the industrial process. Mostly qualitative, but some downstream effects may be quantitative Human Low to medium direct loss depending upon the extent of the injury to the person. Minor injuries with short recovery times may have low direct loss impact to the company even though the injury may have lasting impact to the person who is injured. Low to high indirect loss depending upon the extent of the injury and the criticality of the person to the process. Overtime costs and temporary replacement costs may vary considerably depending upon the recovery time of the individual. Permanent disabling injuries or death may have high indirect loss costs when social responsibility and potential liltigation and awards are factored into the assessment. Immediate qualitative impact on production followed by quantitative impact for recovery or replacement 5.5.2 Vulnerabilities In simple terms, vulnerabilities are inherent weaknesses in systems, components, or organizations. Vulnerabilities may be the result of intentional design choices or may be accidental, resulting from the failure to understand the operational environment. They may also emerge as equipment ages and eventually becomes obsolete, which occurs in a shorter time than is typical for the underlying process or equipment under control. Vulnerabilities are not limited to the electronic or network systems. Understanding the interaction between physical (including human) and electronic vulnerabilities is critical to establishing effective industrial automation and control system security.
  • 52. ANSI/ISA–62443-1-1 (99.01.01)–2007 – 42 – Copyright 2007 ISA. All rights reserved. An industrial automation and control system that initially has limited vulnerability may become more vulnerable with situations such as changing environment, changing technology, system component failure, unavailability of component replacements, personnel turnover, and greater threat intelligence. 5.5.3 Risk Risk is generally defined as an expectation of loss expressed as the probability that a particular threat will exploit a particular vulnerability with a particular consequence. Risk is a function of threat, vulnerability, and consequence, where consequence is the negative impact the organization experiences due to the specific harm to the organization’s asset or assets by the specific threat or vulnerability. The threat and vulnerability components can be expressed in terms of likelihood. Likelihood is the probability that a specific action will occur. Asset owners should rank and include the cost of mitigation or cost to repair in their estimate of risk. They should also determine the appropriate countermeasures for mitigating the most security exposures for the least financial exposure. Any sound risk assessment methodology should analyze all involved systems in a layered approach, starting with systems closest to the threat, and working inward. The basic risk assessment process consists of three steps: 1. assess initial risk 2. implement risk mitigation countermeasures 3. assess residual risk. Steps 2 and 3 of this process are repeated as required in order to reduce the residual risk to an acceptable level. Specifically, the second step includes evaluating existing controls and implementing plans to add remedial or additional countermeasures. A more detailed description of the process of determining risk will be provided in the ISA99 Part 2 standard, ISA-99.00.02 [1]. Typical risks considered include: a) personnel safety risks such as death or injury b) process safety risks such as equipment damage or business interruption c) information security risks such as cost, legal violations, or loss of brand image d) environmental risk such as notice of violation, legal violations, or major impact e) business continuity risks such as business interruption. 5.5.3.1 Risk Tolerance Level The output of a qualitative risk analysis will consist of a list of assets or scenarios with an overall likelihood and a consequence ranking. It is a management responsibility to determine the appropriate response to items based on these rankings. Some organizations accept relatively high levels of risk (such as aggressive growth companies), while some companies are inherently conservative in terms of being risk adverse. Therefore, a certain level of residual risk may be acceptable to one organization and not to another. Even within the same company, individual plants may exhibit different risk appetites or tolerances. Management must explicitly define and understand what its risk appetite or tolerance is, so it can better analyze its level of response to residual risks identified.
  • 53. – 43 – ANSI/ISA–62443-1-1 (99.01.01)–2007 Copyright 2007 ISA. All rights reserved. Addressing the security of industrial automation and control systems does not, in general, introduce new risks, but it may contribute to a different perspective on the existing risks. For example, risks related to safety are typically given more attention in an industrial automation context. Industrial automation and control systems security does not need to reinvent a process for defining the risk tolerance level; it is simply derived from other risk management practices in the organization. 5.5.3.2 Risk Response There are several potential responses to risk. Organizations can take some combination of actions in each situation, depending on the circumstances. a) Design the risk out – One form of mitigation is to change the design of the system so the risk is removed. Some risks exist simply because access is available to something to which no access is ever needed. Completely disabling the unnecessary function or “welding” the function from access can mitigate the risk. Organizations can make the appropriate business decisions so the risk is not taken. This response may involve saying no to something, whether a new vendor product, system, or relationship. b) Reduce the risk – Risks can be decreased to an acceptable level through the implementation of countermeasures that reduce the likelihood or consequence of an attack. The key here is to achieve a level of “good enough” security, not to eliminate the risk. c) Accept the risk – There is always an option to accept the risk, to see it as the cost of doing business. Organizations must take some risks, and they cannot always be cost effectively mitigated or transferred. d) Transfer or share the risk – It may be possible to establish some sort of insurance or agreement that transfers some or all of the risk to a third entity. A typical example of this is outsourcing of specific functions or services. This approach cannot always be effective, because it may not always cover all assets completely. An electronic security policy can recover certain damages, but not logical assets such as loss of customer confidence. e) Eliminate or redesign redundant or ineffective controls – A good risk assessment process will identify these types of controls that need to be addressed so that more attention can be focused on controls that are effective and efficient. 5.5.4 Threats Threats describe the possible actions that can be taken against a system. They come in many different forms, but two of the more common forms are: a) Accidental – Someone unfamiliar with proper procedure and policy or an honest oversight causes an accidental risk. It is also likely that an organization does not know all the risks and may uncover them by accident as it operates complex industrial automation and control systems. b) Nonvalidated changes – Updates, corrections, and other changes to operating systems, application programs, configurations, connectivity, and equipment can provide an unexpected security threat to the industrial automation and control systems or the respective production. Threat agent is the term used to describe the entity that presents a threat. They are also known as adversaries or attackers. Threat agents come in many different forms. Examples include: a) Insider – An insider is a “trusted” person, employee, contractor, or supplier who has information that is not generally known to the public. An insider can present a threat even if there is no intent to do harm. For example, the threat may arise as a result of an insider bypassing security controls “to get the job done.”
  • 54. ANSI/ISA–62443-1-1 (99.01.01)–2007 – 44 – Copyright 2007 ISA. All rights reserved. b) Outsider – An outsider is a person or group not “trusted” with inside access, which may or may not be known to the targeted organization. Outsiders may or may not have been insiders at one time. c) Natural – Natural events include storms, earthquakes, floods, and tornadoes, and are generally considered a physical threat. 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 possible to model attacks in order to ensure that countermeasures are in place to identify and deter them. Case modeling and attack trees are examples of methods that can be used. Threats may be either passive or active. Each type is described in the following paragraphs. 5.5.4.1 Passive Passive information gathering can provide a potential intruder with valuable information. Threat agents usually gather passive information by casual verbal communications with employees and contractors. However, persons inside or outside the facilities can also gather passive information with visual observations. 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 their areas of responsibility can help organizations recognize passive information gathering, especially when combined with accurate background check information. Sniffing is an example of a passive threat. It is the act of monitoring data in a communications stream. Wiretapping, intercepting data contained in a flow of information, is the most widely known means of sniffing. Sniffing can be very sophisticated. Tools are publicly available to sniff data on various communication networks. Although these devices are commonly used for configuration management, troubleshooting networks, and analyzing data traffic, they can also be used to gather specific data about any transaction occurring across the network. For example, in packet sniffing and password sniffing, the attacker secretly attaches to the network at a remote switch or computer. The sniffing tool then passively monitors the information sent through the network and captures the information to a disk that can later be downloaded and analyzed to obtain user identifications and passwords. 5.5.4.2 Active Active threats come in various forms, as described in the following paragraphs. Communication – The intent of a communication attack is to disrupt communications for an industrial automation and control system. Communication attacks can occur in several forms. They may occur at several levels within the system from the computer processor layer up and from outside the enterprise, as in a “denial-of-service” attack on communications systems. Database Injection – An injection is a form of attack on a database-driven web site in which the attacker executes unauthorized commands by taking advantage of insecure code on a system connected to the internet, bypassing the firewall. 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 industrial automation and control system. Potential intruders can replay access control signals, biometric signals, and other system signals to gain unauthorized access to secured areas or systems, hide illegitimate activities, or provide false distractions.
  • 55. Other documents randomly have different content
  • 59. The Project Gutenberg eBook of The Literature of the Old Testament
  • 60. This ebook is for the use of anyone anywhere in the United States and most other parts of the world at no cost and with almost no restrictions whatsoever. You may copy it, give it away or re-use it under the terms of the Project Gutenberg License included with this ebook or online at www.gutenberg.org. If you are not located in the United States, you will have to check the laws of the country where you are located before using this eBook. Title: The Literature of the Old Testament Author: George Foot Moore Release date: July 8, 2012 [eBook #40173] Most recently updated: October 23, 2024 Language: English Credits: Produced by Delphine Lettau, Julia Neufeld and the Online Distributed Proofreading Team at http://www.pgdp.net *** START OF THE PROJECT GUTENBERG EBOOK THE LITERATURE OF THE OLD TESTAMENT ***
  • 61. HOME UNIVERSITY LIBRARY OF MODERN KNOWLEDGE THE LITERATURE OF THE OLD TESTAMENT BY
  • 62. GEORGE FOOT MOORE, M.A., D.D., LL.D. London WILLIAMS & NORGATE HENRY HOLT & Co., New York Canada: WM. BRIGGS, Toronto India: R. & T. WASHBOURNE, Ltd.
  • 64. The following volumes of kindred interest have already been published in the Home University Library:— Vol. 56.—THE MAKING OF THE NEW TESTAMENT. By Prof. B. W. Bacon, LL.D., D.D.Vol.
  • 65. Vol. 68.—COMPARATIVE RELIGION. By Principal J. Estlin Carpenter, D.Litt. Vol. 15.—MOHAMMEDANISM. By Prof. D. S. Margoliouth, M.A., D.Litt. Vol. 47.—BUDDHISM. By Mrs. Rhys Davids, M.A. Vol. 54.—ETHICS. By G. E. Moore, M.A.
  • 66. CONTENTS CHAPTER PAGE I The Canon of the Old Testament 7 II The Old Testament as a National Literature 25 III The Pentateuch 29 IV Character of the Sources. Genesis 33 V Exodus, Leviticus, Numbers 47 VI Deuteronomy 58 VII Age of the Sources. Composition of the Pentateuch 65 VIII Joshua 73 IX Judges 81 X Samuel 91 XI Kings 100 XII Chronicles 118 XIII Ezra and Nehemiah 128 XIV Story Books: Esther, Ruth, Jonah 134 XV The Prophets 144 XVI Isaiah 147 XVII Jeremiah 164 XVIII Ezekiel 174 XIX Daniel 180 XX Minor Prophets 190 XXI Psalms. Lamentations 218 XXII Proverbs 231 XXIII Job 235 XXIV Ecclesiastes. Song of Songs 243 Bibliography 251 Index 253
  • 69. CHAPTER I THE CANON OF THE OLD TESTAMENT The early Christians received the Sacred Books of the Jews as inspired Scripture containing a divine revelation and clothed with divine authority, and till well on in the first century of the Christian era the name Scriptures was applied exclusively to these books. In time, as they came to attach the same authority to the Epistles and Gospels, and to call them, too, Scriptures (2 Pet. iii. 16), they distinguished the Christian writings as the Scriptures of the new dispensation, or, as they called it, the "new covenant," from the Scriptures of the "old covenant" (2 Cor. iii. 6, 14), the Bible of the Jews. The Greek word for covenant (diathéké) was rendered in the early Latin translation by testamentum, and the two bodies of Scripture themselves were called the Old Testament and the New Testament respectively. The Scriptures of the Jews were written in Hebrew, the older language of the people; but a few chapters in Ezra and Daniel are in Aramaic, which gradually replaced Hebrew as the vernacular of Palestine from the fifth century B.C. The Sacred Books comprise the Law, that is, the Five Books of Moses; the Prophets, under which name are included the older historical books (Joshua, Judges, Samuel, Kings) as well as what we call the Prophets (Isaiah, Jeremiah, Ezekiel, and the Twelve, i.e. Minor Prophets); a third group, of less homogeneous character, had no more distinctive name than the "Scriptures"; it included Ruth, Psalms, Job, Proverbs, Ecclesiastes, Song of Songs, Lamentations, Daniel, Esther, Ezra- Nehemiah, and Chronicles. The Minor Prophets counted as one book; and the division of Samuel, Kings, Ezra-Nehemiah, and Chronicles each into two books was made later, and perhaps only in
  • 70. Christian copies of the Bible. There are, consequently, according to the Jewish enumeration twenty-four books in the Bible, while in the English Old Testament, by subdivision, we count the same books as thirty-nine. The order of the books in the Pentateuch and "Former Prophets" (Joshua-Kings) is fixed by the historical sequence, and therefore constant; among the "Latter Prophets" Jeremiah was sometimes put first, immediately following the end of Kings, with which it was so closely connected. In the third group there was no such obvious principle of arrangement, and consequently there were different opinions about the proper order; that which is given above follows the oldest deliverance on the subject, and puts them in what the rabbis doubtless supposed to be a chronological series. So long as the books were written on separate rolls of papyrus, the question of order was theoretical rather than practical; and even when manuscripts were written in codex form (on folded leaves stitched together like our books), no uniformity was attained. At the beginning of the Christian era, lessons from the Law were regularly read in the synagogues on the sabbath (the Pentateuch being so divided that it was read through consecutively once in three years), and a second lesson was chosen from the Prophets. The title of these books to be regarded as Sacred Scripture was thus established by long-standing liturgical use, and was, indeed, beyond question. Nor was there any question about the inspiration of most of the books in the third group, the "Scriptures." There was a controversy, however, over Ecclesiastes and the Song of Songs; some teachers of the strictest school denied that either of them was inspired, while others accepted only one of them. The question was voted on in a council of rabbis held at Jamnia about the beginning of the second century of our era, and the majority decided for the inspiration of both books. There were also, even down to the third century, Jewish scholars who did not acknowledge Esther as Sacred Scripture. On the other hand, some were inclined to include among
  • 71. the Sacred Books the Proverbs of Ben Sira, which stand in the English Bible among the Apocrypha under the title Ecclesiasticus. It is thus evident that, while there was agreement in general, there was, down to the second century A.D., no authoritative list of the "Scriptures," and that about some of the books there were conflicting opinions among the learned of the most orthodox stamp. An interesting confirmation of this is the fact that in the first half of that century it was thought necessary to make a formal deliverance that the "Gospel and other writings of the heretics" are not Sacred Scripture. There are other indications that in that generation Jewish Christianity had a dangerous attraction for some even in rabbinical circles, and there was evidently ground for apprehension that the inspiration which the Christians claimed for the Scriptures of the New Covenant might impose upon well-meaning but uninstructed Jews. In the same connection it was decided, further, that Ben Sira (Ecclesiasticus) was not Holy Scripture, and that no books written from his time on (about 200 B.C.) were inspired, in accordance with the theory, found also in Josephus, that inspiration ceased in the age of Ezra and Nehemiah. By such decisions, recognizing the inspiration of books that had been challenged and excluding others for which inspiration had been claimed, the canon of the Scriptures, that is, the authoritative list of Sacred Books, was defined. The oldest catalogue we have, containing the titles of all the books, dates probably from the latter part of the second century, and is not concerned with the point of canonicity—which it takes for granted—but with the proper order of the Prophets and the Scriptures. The Jews had for centuries been widely distributed through the lands that had been included in the kingdoms of Alexander's successors. There were large numbers in Babylonia and the neighbouring provinces of the Parthian empire, and still more in the countries around the eastern end of the Mediterranean, in Syria and Asia Minor, in Egypt and Cyrene. In Alexandria the Jews had a whole
  • 72. quarter of the city to themselves, and Philo estimates their numbers in Egypt in his time (ca. A.D. 40) at a million. In cities like Alexandria, where Greek was the common speech of a population recruited from many races, the Jews soon exchanged their mother tongue for the cosmopolitan language. The ancient Hebrew of their Sacred Books was unintelligible, not only to the masses, but even to most of the educated, who had learned in the schools of Greek rhetoricians and philosophers rather than at the feet of the rabbis. If the knowledge of the holy Law by which the distinctive Jewish life was regulated was not to be lost altogether, the Scriptures must be translated into Greek. The Pentateuch was doubtless translated first—legend attributes the initiative to King Ptolemy Philadelphus (285-246 B.C.); then other books, by different hands and at different times and places. To some of the books, as to Daniel and Esther, additions were made in the translation which were not accepted by the Palestinian Jews. Besides the books which were finally included in the Jewish canon, there were various others, written in Hebrew or Aramaic after the pattern of the several forms of Biblical literature. History, for example, is represented by 1 Maccabees, relating the struggle of the Jews in Palestine for religious liberty and national independence in the second century B.C.; the Proverbs of Solomon have a counterpart in the Proverbs of Ben Sira, already mentioned; the Psalter, in the so-called Psalms of Solomon; the story of Judith may be compared with Esther; the visions of Daniel have their parallel in popular apocalypses bearing the names of Enoch, Noah, Ezra, Baruch, and other ancient worthies. These writings were sooner or later translated into Greek, and some of them attained a wide circulation. The Greek-speaking Jews, also, produced a religious literature, in part imitating the familiar Biblical forms, as in the Wisdom of Solomon and 2 Maccabees, in part cast in Greek moulds, as when prophecy disguised itself in Sibylline Oracles, or the supremacy of reason over the emotions was made the subject of a discourse after the pattern of a Stoic diatribe (4 Maccabees).
  • 73. The influence of Greek culture on many of these writers was not confined to language and literary form; they lived in an atmosphere of Greek thought—the popular philosophy, in which Platonic and Stoic elements were fused or confused—and a few had a more academic acquaintance with the Greek thinkers. But, under all this, they were Jews to the core, devoted to the religion of their fathers, of the superiority of which they were the more convinced by the spectacle of heathenism about them: Judaism was the only true religion, its Scriptures the one divine revelation. The Law and the Prophets had the same precedence as in the Palestinian synagogue. Of the other Scriptures there was no authoritative and exclusive list, and among books read solely for private edification it is not likely that a very sharp line was drawn; but, on the whole, the practice of the Greek-speaking Jews does not seem to have been materially different from that of their countrymen in Palestine. Outside of Palestine, Christianity was spread by Greek-speaking Jews who had embraced the new Messianic faith, and their converts in the fields of their missionary labours, both Jews and Gentiles, spoke Greek, either as their mother tongue or as the language of common intercourse. The church, therefore, took over the Jewish Scriptures in the existing translations: the Christian Old Testament was from the beginning the Greek Bible, not the Hebrew. They received also from the Greek-speaking Jews the belief in the divine inspiration of the translators, by virtue of which the same infallible authority attached to the version of the Seventy which belonged to the Hebrew original. In their desire to possess every word of God, they gathered up the religious books which they found in the hands of the Jews, without inquiring curiously whether the Jews included them in the narrower category of Sacred Scriptures or not; and they discovered no reason in the books themselves why Esther, for example, should be inspired and Judith not; or why Ecclesiastes, with its scepticism about the destiny of the soul, should be divinely revealed, and the Wisdom of Solomon, with its eloquent defence of immortality, a purely human production; or, again, why the Proverbs
  • 74. of Solomon were Scripture, and the Proverbs of Ben Sira (Ecclesiasticus) nothing but profane wisdom. Controversies in the second century made the Christian apologists aware that the Jews did not acknowledge the authority of some of the books from which their opponents adduced proof-texts, and this practical concern, rather than purely learned interest, led to the drawing up of lists of books which were accepted by the Jews as Sacred Scripture. The oldest of these lists which has come down to us was made by Melito, Bishop of Sardes, about A.D. 170; it contains the books of the Jewish canon enumerated above (p. 8), with the noteworthy exception of Esther, about which, as we have seen, Jewish opinion was divided. Christian catalogues of the Jewish Old Testament long show an uncertainty about the right of this book to a place in the canon. Meanwhile the church had, in its worship and in religious instruction, established a use and tradition of its own. The Wisdom of Jesus, son of Sirach, was appropriated for the moral instruction of youth and of converts, as is shown by the title it bears in the Greek Bible, Ecclesiasticus, that is, "The Church Book," and other writings not included in the Jewish canon were highly esteemed in the church. About A.D. 240, Julius Africanus, Bishop of Emmaus in Palestine, addressed a critical letter to Origen on the story of Susanna and the Elders in the Book of Daniel. This story, he said, was not found in the Hebrew Daniel, and was not acknowledged by the Jews. He proved by internal evidence that it was not translated from the Hebrew, the language in which the Scriptures of the Old Testament were inspired, but originally composed in Greek, and he raised various historical objections to the tale: it ought not, therefore, to be quoted as Sacred Scripture. In his answer, Origen, the greatest Biblical scholar of his age, argued that if the story of Susanna was to be set aside on the ground that it was not accepted by the Jews, other books, such as Judith and Tobit, would have to be rejected also. He appeals to the prescriptive usage of the church itself, which had always used these books and read them with edification. This
  • 75. immemorial tradition was authority enough for Christians; there was no reason why the church should prune its Bible to please the Jews or adapt itself to their opinions about what was and what was not inspired Scripture; he reminds his correspondent of the law, "Thou shalt not remove the ancient landmarks which those before thee have set." This way of looking at the matter, as might be expected, prevailed in the church. Lists of the books of the Jewish Bible were handed down, and scholars were well aware that the Christian Old Testament contained several books not received by the Jews. By the more critical of the Greek Fathers these books are not cited with the same authority for the establishment of doctrine as the books of the Hebrew Bible. Thus, Athanasius, at the end of a list of the canonical Scriptures of the Old and New Testaments (A.D. 365), adds: "There are, besides these, other books, not, indeed, included in the canon, but prescribed by the Fathers to be read by those who come to the church and wish to be taught the doctrine of religion, namely, the Wisdom of Solomon, and the Wisdom of Sirach, Esther, Judith, Tobit, and the Teaching of the Twelve Apostles." But this learned reserve had no effect on the liturgical or practical use of the church. The question of the inspiration and authority of the supernumerary books of the Old Testament was not decided by any council speaking in the name of the catholic church; nor was it ever thus determined exactly what these supernumerary books were, though several local synods made lists of them. The Latin Church received its Bible from the Greeks, and the Latin translations of the Old Testament made from the Greek included, as a matter of course, the books which the church accepted and the synagogue rejected. About the beginning of the fifth century, Jerome undertook a new Latin translation direct from the Hebrew. He lived for many years at Bethlehem, and had learned Hebrew from Jewish teachers, whose assistance he employed also in the work of translation. In some of the prefaces to this translation (which was published in parts), and in other places in his writings, Jerome gives
  • 76. a catalogue of the books of the Hebrew Bible, corresponding to the contents of our English Old Testament, and expressly excludes all others from the class of canonical Scriptures: "Whatever is not included in this list is to be classed as apocrypha. Therefore Wisdom (commonly entitled 'of Solomon'), and the Book of Jesus son of Sirach, and Judith and Tobit ... are not in the canon." The word "apocrypha," literally "secret, or esoteric, writings," had been used generally for the books of heretical sects, or suspected of being such, and, more broadly, of writings which the church repudiated as not only uninspired but harmful, the reading of which it often forbade. It was, therefore, a very radical word that Jerome uttered when he applied this name to books which the church had always regarded as godly and edifying. Jerome himself did not consistently maintain the position which would make the Jewish Bible the canon of the Christian church. At the request of certain bishops he translated Judith and Tobit, noting in the prefaces that the Jews exclude these books from the canon and put them among the apocrypha, but significantly adding in the one case that he thinks it better to oppose the judgment of the Pharisees and obey the commands of the bishops, in the other pleading not only the demand of a bishop but the fact that the Nicene Council had included Judith among the Sacred Books.[1] In another preface he describes Ecclesiasticus and the Wisdom of Solomon as books which the church reads "for the edification of the people, not for proving the doctrines of the church"—a definition which accords with the attitude of many of the Greek Fathers. Jerome thus halts between two opinions: in relegating to the apocrypha everything that is not in the Hebrew Bible he speaks as a critic; in recognizing the books found in the Christian Old Testament, but not in the Hebrew, as useful and edifying, though of inferior authority for doctrinal purposes, he, like Origen, takes the ground of the practical churchman. The mediating position is more clearly defined by Rufinus, who, after giving a catalogue of the books of the Hebrew Bible, adds: "There are other books, which older authors called not 'canonical' but 'ecclesiastical,' such as the Wisdom of
  • 77. Solomon, and the so-called Wisdom of the Son of Sirach, named by the Latins Ecclesiasticus; to the same class belong Tobit, Judith and the Books of the Maccabees." The great influence of Augustine was thrown wholly on the side of ecclesiastical tradition; he even remonstrated with Jerome for translating the Old Testament from the Hebrew and thus disturbing the minds of the faithful, instead of revising the Old Latin version after the Greek. In his treatise on Christian Doctrine (ii. 8; written in A.D. 397) he includes among the canonical books of the Old Testament, Judith, Tobit, 1 and 2 Maccabees, Ecclesiasticus, and the Wisdom of Solomon; African provincial synods at Hippo (A.D. 393) and Carthage (A.D. 397) pronounced themselves in the same sense. The Syriac-speaking churches, whose Old Testament was translated from the Hebrew, originally recognized those books only which were found in the Jewish Bible; it appears, indeed, that the earliest Syriac version did not extend to Chronicles, Ezra, and Nehemiah, but did include Sirach. Under the influence of the Greek Church, those branches of the Syrian Church which remained in communion with it gradually added to their Bible translations of the other books from the Greek; but the Nestorians, in whose schools Biblical criticism moved more freely than in the Catholic Church, continued to reject them, or to accord them, together with several of the books commonly reckoned canonical (Chronicles, Ezra, Nehemiah, Judith, 1 and 2 Maccabees, Job, Ecclesiasticus, Wisdom), only qualified authority. Throughout the Middle Ages learned authors repeated the conflicting utterances of the Fathers concerning the canon, without being disturbed by their inconsistency; in practice, the Old Testament comprised all the books that were usually found in copies of the Greek or Latin Bible, without regard to the fine distinctions of "canonical" and "ecclesiastical." The immemorial usage of the church had more weight than the opinions of scholars. With this concurred the fact that from the fourth century on the Bible was copied in collective codices, on folded sheets of parchment or vellum like our
  • 78. books, not in separate rolls, and thus the canon of the Old Testament became, not a mere list of Sacred Books, but a physical unity, in which the books of the Jewish Bible were intermingled with those which the Jews did not accept. The question assumed a new significance at the Reformation. In rejecting the authority of ecclesiastical tradition and the prescriptive usage of the church and making the Scriptures the only rule of faith and practice, the Reformers were under the necessity of deciding what books were inspired Scripture, containing the Word of God revealed to men, clothed with divine authority, demanding unqualified faith, and a means of grace to believers. Obviously they could not logically acknowledge books whose place in the Bible had no other warrant than that the church had accepted them from very early times; nothing short of the authority of the New Testament itself would suffice, and they found in the New Testament no quotations from these books. To the Jews, St. Paul said, were committed the oracles of God; it was the Jewish Scriptures to which Jesus and the Apostles appealed. Naturally, therefore, Luther reverted to the position of Jerome: the books found in the Hebrew Bible, and those only, were the Scriptures of the Old Testament; whatever was more than these was to be reckoned among the apocrypha. In the first complete printed edition of his translation (1534), these books (Judith, Wisdom, Tobit, Sirach, Baruch, 1 and 2 Maccabees, the Greek additions to Esther and Daniel, the Prayer of Manasseh) stand between the Old Testament and the New, with the title (after Jerome) "Apocrypha; that is, books that are not equally esteemed with the Holy Scripture, but nevertheless are profitable and good to read." The other Protestant versions, on the Continent and in England, followed this example. The attitude of Luther toward the Old Testament Apocrypha was maintained by the Lutheran Churches, whose Confessions do not, however, attempt a more exact definition of the value and authority of the Apocrypha. The earlier Reformed (Calvinistic) Confessions
  • 79. take substantially the same ground: the Ecclesiastical Books, or Apocrypha, are useful, especially for moral instruction, but they have not the same authority as the canonical books, and doctrines may not be deduced from them alone. The Articles of the Church of England (1563; English translation, 1571) agree on this point with the other Reformed Confessions: after enumerating the canonical books "of whose authority there was never any doubt in the Church," the Sixth Article continues: "And the other books (as Hierome saith) the Church doth read for example of life, and instruction of manners; but yet it doth not apply them to establish any doctrine." A list of such books follows, comprising those commonly printed in the English Bible under the title Apocrypha. A more radical position was represented by the Synod of Dort (1618) and by the Westminster Assembly (1643). The latter declares: "The books commonly called Apocrypha, not being of divine inspiration, are no part of the canon of Scripture; and therefore are of no authority in the church of God, nor to be otherwise approved, or made use of, than other human writings." In opposition to the Protestant limitation of the canon of the Old Testament to the books of the Hebrew Bible, the Roman Church defined its attitude more sharply. In the Fourth Session of the Council of Trent (1546) it framed a "Decree concerning the Canonical Scripture," in which the books set apart by the Protestants as Apocrypha are included with the rest. The complete contents of the Old Testament in the Catholic Bible as thus defined are as follows: The Five Books of Moses, that is, Genesis, Exodus, Leviticus, Numbers, Deuteronomy; Joshua, Judges, Ruth, four Books of Kings [Samuel, Kings], two Books of Chronicles, 1 and 2 Esdras [Ezra, Nehemiah], Tobit, Judith, Esther, Job, the Psalter of David, containing one hundred and fifty Psalms, Proverbs, Ecclesiastes, Song of Songs, Wisdom, Ecclesiasticus, Isaiah, Jeremiah with Baruch, Ezekiel, Daniel, the Twelve Minor Prophets, two Books of Maccabees, namely, the First and Second.... "If any man does not accept as sacred and canonical these books, entire, with all their
  • 80. Welcome to our website – the perfect destination for book lovers and knowledge seekers. We believe that every book holds a new world, offering opportunities for learning, discovery, and personal growth. That’s why we are dedicated to bringing you a diverse collection of books, ranging from classic literature and specialized publications to self-development guides and children's books. More than just a book-buying platform, we strive to be a bridge connecting you with timeless cultural and intellectual values. With an elegant, user-friendly interface and a smart search system, you can quickly find the books that best suit your interests. Additionally, our special promotions and home delivery services help you save time and fully enjoy the joy of reading. Join us on a journey of knowledge exploration, passion nurturing, and personal growth every day! ebookbell.com