Isa 62443-2-1

--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
ANSI/ISA–62443-2-1 (99.02.01)–2009
(formerly designated as ANSI/ISA-99.02.01-2009)
Security for Industrial Automation

and Control Systems Part 2-1:
Establishing an Industrial Automation
and Control Systems Security Program
Approved 13 January 2009
Copyright International Society of Automation

Provided by S&P Global under license with ISA Licensee=PRICEWATERHOUSECOOPERS Pvt Ltd./8334314001, User=VR, Guruprakash
No reproduction or networking permitted without license from S&P Global Not for Resale, 01/24/2023 19:07:04 MST
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
ANSI/ISA–62443-2-1 (99.02.01)–2009 –2–
ANSI/ISA–62443-2-1 (99.02.01)–2009
(formerly designated as ANSI/ISA-99.02.01-2009)
Security for Industrial Automation and Control Systems Part 2-1: Establishing an Industrial
Automation and Control Systems Security Program
ISBN: 978-1-934394-93-9
Copyright © 2009 by ISA. All rights reserved. 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), w ithout the prior
written permission of the publisher.
ISA
67 Alexander Drive
P.O. Box 12277
Research Triangle Park, NC 27709
www.isa.org
Copyright 2009 ISA. All rights reserved.

–3– ANSI/ISA–62443-2-1 (99.02.01)–2009
Preface
This preface, as well as all footnotes and annexes, is included for information purposes and is
not part of ANSI/ISA–62443-2-1 (99.02.01)–2009.
This document has been prepared as part of the service of IS A, the Instrumentation, Systems
and Automation Society, toward a goal of uniformity in the field of instrumentation . To be of real
value, this document should not be static but should be subject to periodic review . Toward this
end, the Society welcomes all comments and criticisms and asks that they be addressed to the
Secretary, Standards and Practices Board; ISA; 67 Alexander Drive; P. O. Box 12277; Research
Triangle Park, NC 27709; Telephone (919) 549-8411; Fax (919) 549-8288; E-mail:
[email protected].
The ISA Standards and Practices Department is aware of the growing need for attention to the
metric system of units in general and the International System of Units (SI) in particular, in the
preparation of instrumentation standards . The Department is further aware of the benefits to USA
users of ISA standards of incorporating suitable references to the SI (and the metric system) in
their business and professional dealings with other countries . Toward this end, this Department
will endeavour to introduce SI-acceptable metric units in all new and revised standards,
recommended practices and technical reports to the greatest extent possible . Standard for Use
of the International System of Units (SI): The Modern Metric System, published by the American
Society for Testing and Materials as IEEE/ASTM SI 10-97, and future revisions, will be the
reference guide for definitions, symbols, abbreviations, and conversion factors.
It is the policy of ISA to encourage and welcome the participation of all concerned individu als
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 does not take any position with respect to the existence or validity of any
patent rights asserted in connection with this document, and ISA disclaims liability fo r the
infringement of any patent resulting from the use of this document. Users are advised that
determination of the validity of any patent rights, and the risk of infringement of such
rights, is entirely their own responsibility.
Pursuant to ISA’s Patent Policy, one or more patent holders or patent applicants may have
disclosed patents that could be infringed by use of this document and executed a Letter of
Assurance committing to the granting of a license on a worldwide, non -discriminatory
basis, with a fair and reasonable royalty rate and fair and reasonable terms and
conditions. For more information on such disclosures and Letters of Assurance, contact
ISA or visit www.isa.org/StandardsPatents.
Other patents or patent claims may exist for which a disclosure or Letter of Assurance has
not been received. ISA is not responsible for identifying patents or patent applications for
which a license may be required, for conducting inquiries into the legal validity or scope
of patents, or determining whether any licensing terms or conditions provided in
connection with submission of a Letter of Assurance, if any, or in any licensing
agreements are reasonable or non-discriminatory.
ISA requests that anyone reviewing this Document who is aware of any patents tha t may
impact implementation of the Document 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
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

ANSI/ISA-62443-2-1 (99.02.01)–2009 -4-
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.
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

–5– ANSI/ISA–62443-2-1 (99.02.01)–2009
The following people served as active members of ISA99 Working Group 2 in the preparation of
this standard:
Name Company Contributor Reviewer

Thomas Good, WG Leader DuPont X
James Gilsinn, Lead Editor NIST X
Soloman Almadi Saudi Aramco X
Ken Anderson MTS Allstream Inc. X
Rahul Bhojani Bayer Technology Services X
Dennis Brandl BR&L Consulting X
Eric Byres Byres Security Inc. X
Antony Capel Comgate Engineering Ltd. X
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
Richard Clark Invensys/Wonderware X

Eric Cosman, ISA99 Co-Chair The Dow Chemical Company X
Jean-Pierre Dalzon ISA France X
Ronald Derynck Verano X
Gabriel Dimowo Shell International X
Robert Evans Idaho National Laboratory X
Donna Guillen Idaho National Laboratory X
Evan Hand ConAgra Foods X
Mark Heard Eastman Chemical Co. X
Marnix Haije Shell Information Technology X
Dave Mills Proctor and Gamble Co. X
Carol Muehrcke Cyber Defense Agency LLC X
Tom Phinney Consultant X X
Jeff Potter Emerson X
Matt Rollinson Monsanto Co. X
Bryan Singer, ISA99 Co-Chair Kenexis Consulting Group X
Martin Solum Cyber Defense Agency LLC X
Leon Steinocher Fluor Enterprises X
Ivan Susanto Chevron Information Technology Co. X
Brad Taylor The George Washington University X
Loren Uden Lyondell Chemical Co. X
Bob Webb ICS Secure LLC X
Joe Weiss Applied Control Solutions, LLC X
Ludwig Winkel Siemens X

ANSI/ISA-62443-2-1 (99.02.01)–2009 -6-
Contents
1 Scope ............................................................................................................................ 13
2 Normative references ..................................................................................................... 14
3 Terms, definitions, abbreviated terms, acronyms, and conventions ................................ 15
3.1 Terms and definitions ............................................................................................ 15
3.2 Abbreviated terms and acronyms .......................................................................... 19
3.3 Conventions .......................................................................................................... 21
4 Elements of a cyber security management system ......................................................... 22
4.1
Overview ............................................................................................................... 22
4.2
Category: Risk analysis ......................................................................................... 24
4.2.1 Description of category ............................................................................. 24
4.2.2 Element: Business rationale ...................................................................... 24
4.2.3 Element: Risk identification, classification , and assessment ...................... 25
4.3 Category: Addressing risk with the CSMS ............................................................. 26
4.3.2 Element group: Security policy, organization , and awareness.................... 27
4.3.3 Element group: Selected security countermeasures .................................. 31
4.3.4 Element group: Implementation ................................................................. 39
4.4 Category: Monitoring and improving the CSMS ..................................................... 44
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
4.4.2 Element: Conformance .............................................................................. 44
4.4.3 Element: Review, improve, and maintain the CSMS .................................. 45
Annex A (informative) Guidance for developing the elements of a CSMS ............................. 47
A.1
Overview ............................................................................................................... 47
A.2
Category: Risk analysis ......................................................................................... 48
A.2.1 Description of category ............................................................................. 48
A.2.2 Element: Business rationale ...................................................................... 49
A.2.3 Element: Risk identification, classification , and assessment ...................... 54
A.3 Category: Addressing risk with the CSMS ............................................................. 77
A.3.1 Description of category ............................................................................. 77
A.3.2 Element group: Security policy, organization, and awareness.................... 77
A.3.3 Element group: Selected security countermeasures .................................. 94
A.3.4 Element group: Implementation ............................................................... 118
A.4 Category: Monitoring and improving the CSMS ................................................... 147
A.4.1 Description of category ........................................................................... 147
A.4.2 Element: Conformance ............................................................................ 147
A.4.3 Element: Review, improve, and maintain the CSMS ................................ 150
Annex B (informative) Process to develop a CSMS ............................................................ 155
B.1 Overview ............................................................................................................. 155
B.2 Description of the Process .................................................................................. 155
B.3 Activity: Initiate CSMS program ........................................................................... 157

–7– ANSI/ISA–62443-2-1 (99.02.01)–2009
B.4 Activity: High-level risk assessment .................................................................... 158

B.5 Activity: Detailed risk assessment ....................................................................... 158
B.6 Activity: Establishing Security Policy, Organization , and Awareness ................... 159
B.7 Activity: Select and implement countermeasures ................................................. 162
B.8 Activity: Maintain the CSMS ................................................................................ 162
Figure 1 – Graphical view of elements of a cyber security management system ................... 23

Figure 2 – Graphical view of category: Risk analysis ............................................................ 24
Figure 3 – Graphical view of element group: Security policy, organization , and awareness ... 27
Figure 4 – Graphical view of element group: Selected security countermeasures ................. 32
Figure 5 – Graphical view of element group: Implementation ................................................ 39
Figure 6 – Graphical view of category: Monitoring and improving the CSMS ......................... 44
Figure A.1 – Graphical view of elements of a cyber security management system ................ 48
Figure A.2 – Graphical view of category: Risk analysis ......................................................... 49
Figure A.3 – Reported attacks on computer systems through 2004 (source: CERT) .............. 53
Figure A.4 – Sample logical IACS data collection sheet ........................................................ 68
Figure A.5 – Example of a graphically rich logical network diagram ...................................... 70
Figure A.6 – Graphical view of element group: Security po licy, organization, and
awareness ............................................................................................................................ 77
Figure A.7 – Graphical view of element group: Selected security countermeasures .............. 94
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
Figure A.8 – Reference architecture alignment with an example segmented architecture .... 102
Figure A.9 – Reference SCADA architecture alignment with an example segmented
architecture ........................................................................................................................ 105
Figure A.10 – Access control: Account administration ......................................................... 107
Figure A.11 – Access control: Authentication ...................................................................... 110
Figure A.12 – Access control: Authorization ....................................................................... 116
Figure A.13 – Graphical view of element group: Implementation ......................................... 119
Figure A.14 – Security level lifecycle model: Assess phase ................................................ 122
Figure A.15 – Corporate security zone template architecture .............................................. 125
Figure A.16 – Security zones for an example IACS ............................................................. 126
Figure A.17 – Security level lifecycle model: Develop and implement phase ....................... 129
Figure A.18 – Security level lifecycle model: Maintain phase .............................................. 134
Figure A.19 – Graphical view of category: Monitoring and improving the CSMS .................. 147
Figure B.1 – Top level activities for establishing a CSMS ................................................... 155
Figure B.2 – Activities and dependencies for activity: Initiate CSMS program ..................... 157
Figure B.3 – Activities and dependencies for activity: High-level risk assessment ............... 158
Figure B.4 – Activities and dependencies for activity: Detai led risk assessment.................. 159
Figure B.5 – Activities and dependencies for activity: Establish policies and procedures .... 160
Figure B.6 – Training and assignment of organization responsibilities ................................ 161

ANSI/ISA-62443-2-1 (99.02.01)–2009 -8-
Figure B.7 – Activities and dependencies for activity: Select and implement
countermeasures ................................................................................................................ 162
Figure B.8 – Activities and dependencies for activity: Maintain the CSMS .......................... 163
Table A.1 – Typical likelihood scale ...................................................................................... 61

Table A.2 – Typical consequence scale ................................................................................ 63
Table A.3 – Typical risk level matrix ..................................................................................... 64
Table A.4 – Example countermeasures and practices based on IACS risk levels ................ 120
Table A.5 – Example IACS asset table with assessment results ......................................... 123
Table A.6 – Example IACS asset table with assessment results and risk levels .................. 124
Table A.7 – Target security levels for an example IACS...................................................... 126
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

–9– ANSI/ISA–62443-2-1 (99.02.01)–2009
Foreword
This standard is part of a multipart series that addresses the issue of security for industrial
automation and control systems. It has been developed by Working Group 2 of the ISA99
committee.
This standard describes the elements contained in a cyber security management system for use
in the industrial automation and control systems envir onment and provides guidance on how to
meet the requirements described for each element.
This standard has been developed in large part from a previous Technical Report produced by
the ISA99 committee, ANSI/ISA–TR99.00.02–2004, Integrating Electronic Security into the
Manufacturing and Control Systems Environment. The majority of the contents of this Technical
Report have been included in this standard and as such this standard supersedes the Technical
Report.
The ISA99 Series 1 and the IEC

The ISA99 series addresses electronic security within the industrial automation and control
systems environment. The series will serve as the foundation for the IEC 62443 series of the
same titles, as being developed by IEC TC65 W G10, “Security for industrial process
measurement and control - Network and system security.” For information, visit www.iec.ch,
Technical Committee 65.
The ISA99 series includes the following:
 ANSI/ISA–99.01.01–2007 – Terminology, concepts and models

ANSI/ISA–99.01.01 establishes the context for all of the remaining standards in the series by
defining the terminology, concepts and models to understand electronic security for the
industrial automation and control systems environment.
 ANSI/ISA–TR99.01.02–2007 – Security Technologies for Industrial Automation and
Control Systems
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
ANSI/ISA–TR99.01.02 describes various security technologies in terms of their applicability
for use with industrial automation and control systems. This report will be updated
periodically to reflect changes in technology.
 ANSI/ISA–99.02.01–2009 – Establishing an industrial automation and control system
security program
ANSI/ISA–99.02.01 describes the elements to establish a cyber security management system
and provides guidance on how to meet the requirements for each element.
 ISA–99.02.02 (in development at the time of publication of this standard) – Operating an
industrial automation and control system security progra m
ISA–99.02.02 will address how to operate a security program after it is designed and
implemented. This includes the definition and application of metrics to measure program
effectiveness.
 ISA–99.03.xx – Technical security requirements for industrial automation and control
systems (in development at the time of publication of this standard)
The ISA–99.03.xx standards will define the characteristics of industrial automation and
control systems that differentiate them from other information technology systems from a
1 For information about the status of the ISA99 series, visit http://www.isa.org/standards.

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 10 -
security point of view. Based on these characteristics, the standards will establish the
security requirements that are unique to this class of systems.
ISA values your input

Users of this standard and all ISA standards are asked to submit comments and suggestions for
consideration in future revisions. Please send your input to [email protected].
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

– 11 – ANSI/ISA–62443-2-1 (99.02.01)–2009
Introduction
NOTE The format of this document follows the ISO/IEC requirements discussed in ISO/IEC Directives, Part 2. [9] This
document specifies the format of the document as well as the use of terms like “shall”, “should”, and “may”. The
directives requirements specified in Clause 4 use the conventions discussed in Appendix H of the Directives document.
Overview
Cyber security is an increasingly important topic in modern organizations. Many organizations

involved in information technology (IT) and business have been concerned with cyber security for
many years and have well-established Cyber Security Management Systems (CSMS) in place as
defined by International Organization for Standardization (ISO) / International Electrotechnical
Commission (IEC) 17799 [14] and ISO/IEC 27001 [15]. These management systems give an
organization a well-established method for protecting its assets from cyber attacks.
Industrial Automation and Control System (IACS) organizations have begun using commercial -
off-the-shelf (COTS) technology developed for business systems in their everyday processes,
which has provided an increased opportunity for cyber attack against the IACS equipment. For
many reasons these systems are not usually as robust, in the IACS environment, as are systems
designed specifically as IACS at dealing with cyber attack for many reasons . This weakness may
lead to health, safety and environmental (HSE) consequences.
Organizations may try to use the pre-existing IT and business cyber security solutions to address
security for IACS without understanding the consequences. While many of these solutions can
be applied to IACS, they need to be applied in the correct way to eliminate inadvertent
consequences.
A cyber security management system for IACS
Management systems typically provide guidance on what should be included in a management

system, but do not provide guidance on how to go about developing the management system.
ANSI/ISA–99.02.01–2009 addresses the “what” aspect of a CSMS for IACS and also provides
guidance on how to go about developing the CSMS for IACS.
A common engineering approach when faced with a challenging problem is to break the problem
into smaller pieces and address each piece in a disciplined manner. This approach is a sound
one for addressing cyber security risks with IACS. However, a frequent mistake made in
addressing cyber security is to deal with cyber security one system at a time. Cyber secur ity is a
much larger challenge that must address the entire set of IACS as well as the policies,
procedures, practices and personnel that surround and utilize those IACS . Implementing such a
wide-ranging management system may require a cultural change with in an organization.
Addressing cyber security on an organization-wide basis can seem like a daunting task.
Unfortunately, there is no simple cookbook for security. There is good reason for this. There is
not a one-size-fits-all set of security practices. Absolute security may be achievable, but is
probably undesirable because of the loss of functionality that would be necessary to achieve this
near perfect state. Security is really a balance of risk versus cost. All situations will be different.
In some situations the risk may be related to HSE factors rather than purely economic impact.
The risk may have an unrecoverable consequence rather than a temporary financial setback.
Therefore, a cookbook set of mandatory security practices will either be overly res trictive and
likely quite costly to follow, or be insufficient to address the risk.
Relationship with ISO/IEC 17799 and ISO/IEC 27001
ISO/IEC 17799 [14] and ISO/IEC 27001 [15] are excellent standards that describe a cyber
security management system for business/information technology systems. Much of the content
in these standards is applicable to IACS as well. ANSI/ISA–99.02.01–2009 emphasizes the need

--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 12 -
for consistency between the practices to manage IACS cyber security with the practices to
manage business/information technology systems cyber security. Economies will be realized by
making these programs consistent. Users of this ISA document are encouraged to read
ISO/IEC 17799 and 27001 for additional supporting information. ANSI/ISA–99.02.01–2009 builds
on the guidance in these standards. It addresses some of the important differences between
IACS and general business/information technology systems. It introduces the important concept
that cyber security risks with IACS may have HSE implications and must be integrated with other
existing risk management practices addressing these risks.
Document outline
This standard is structured to follow the ISO/IEC and ISA guidelines for standards development
as closely as possible, per the following:.
 Clause 1 describes the scope of this standard.
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
 Clause 2 lists a number of normative references for this standard.
 Clause 3 defines a list of terms and abbreviations needed for this standard. This list is in
addition to the list of terms defined in ANSI/ISA–99.01.01–2007. [1]
 Clause 4 defines the elements of a cyber security management system for industrial
automation and control systems. Clause 4 is normative.
 Annex A provides guidance on how to develop the elements of the cyber security
management system for IACS.
 Annex B describes an example process that an organization could use to develop the
elements of the cyber security management system for IACS.
 The bibliography lists references to other sources used in the development of this standard or
with some relevance to the material presented here.

– 13 – ANSI/ISA–62443-2-1 (99.02.01)–2009
1 Scope
This standard defines the elements necessary to establish a cyber security management system
(CSMS) for industrial automation and control systems (IACS) and provides guidance on how to
develop those elements. This document uses the broad definition and scope of what constitutes
an IACS described in ANSI/ISA–99.01.01–2007. [1]
The elements of a CSMS described in this standard are mostly policy, procedure , practice and
personnel related, describing what shall or should be included in the final CSMS for the
organization.
NOTE Other documents in the ISA-99 series and in the Bibliography discuss specific technologies and/or solutions
for cyber security in more detail.
The guidance provided on how to develop a CSMS is an example . It represents the authors’
opinion on how an organization could go about developing the elements and may not work in all
situations. The user of this standard will have to read the requirements carefully and apply the
guidance appropriately in order to develop a fully functioning CSMS for their organization. The
policies and procedures discussed in this standard should be tailored to fit within the
organization.
NOTE There may be cases where a pre-existing CSMS is in place and the IACS portion is being added or there may
be some organizations that have never formally created a CSMS at all. The authors of this standard cannot anticipate
all cases where an organization will be establishing a CSMS for the IACS environment, so this standard does not
attempt to create a solution for all cases.

--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 14 -
2 Normative references
The following normative document contains provisions, which through reference in this text
constitute provisions of standard. At the time of publication, the edition indicated was valid. All
normative documents are subject to revision and parties to agreements based on standard are
encouraged to investigate the possibility of applying the most recent edition of the normative
document indicated below.
ANSI/ISA–99.01.01–2007 – Security for industrial automation and control systems: Terminology,

concepts and models [1]
As noted in the foreword to this standard, the ISA99 series will serve as the foundation for the
IEC 62443 series of the same titles, as being developed by IEC TC65 WG10, “ Security for
industrial process measurement and control - Network and system security.” For information,
visit www.iec.ch, Technical Committee 65.
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
– 15 – ANSI/ISA–62443-2-1 (99.02.01)–2009
3 Terms, definitions, abbreviated terms, acronyms, and conventions

3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in ANSI/ISA–99.01.01–2007
and the following apply. Wherever possible, the definitions presented in this sub-clause have
been taken from established industry sources. Others have been adapted from more gene ric
definitions used in the information technology industry. Definitions that do not list a specific
reference have been derived from sources in the public domain. All sources cited are listed in the
bibliography.
3.1.1
access account
access control function that allows the user access to a particular set of data or functions for
certain equipment
NOTE Many times accounts are linked to user identifications (IDs) and passwords. These user IDs and passwords
may be linked to an individual or group of individuals such as a control room work team performing the same set of
operating tasks.
3.1.2
administrative practices
defined and documented practices/procedures that individuals are personally accountable to
follow at all times
NOTE These are usually in the conditions of employment for the organization. In the IACS environment, these often
have HSE implications.
3.1.3
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 [1]
NOTE In this specific case, an asset is any item that should be protected as part of the cyber security management
system.
3.1.4
authentication
security measure designed to establish the validity of a transmission, message or orig inator or a
means of verifying an individual’s authorization to receive specific categories of information [1]
3.1.5
burner management system
system for the safe start-up, monitoring and shutdown of burner systems associated with boilers,
flares, incinerators, gas turbines, thermal oxidizers, and other fired equipment
3.1.6
business continuity plan
document with identified procedures for recovering from a significant disruption and restoring
business operations [43]
NOTE 1 This umbrella term also refers to other aspects of disaster recovery, such as emergency management,
human resources and media or press relations.
NOTE 2 A business continuity plan also identifies procedures for sustaining essential business operations while
recovering from a significant disruption.
3.1.7
business continuity planning
process to develop a business continuity plan

--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 16 -
3.1.8
change management
process of controlling and documenting any change in a system to maintain the proper operation
of the equipment under control
3.1.9
compliance
relation between two specifications, A and B, that holds when specification A makes
requirements which are all fulfilled by specification B (when B complies with A) [10]
3.1.10
conformance
relation between a specification and a real implementation, such as an example of a product [10]
NOTE It holds when specific requirements in the specification (the conformance requirements) are met by the
implementation. Conformance assessment is the process through which this relation is determined.
3.1.11
consequence
result that occurs from a particular incident
3.1.12
critical
very important device, computer system, process, and the like, that if compromised by an
incident could have high financial, health, safety or environmental impact to an organization
3.1.13
cyber security management system
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
program designed by an organization to maintain the cyber security of the entire organization’s
assets to an established level of confidentiality, integr ity and availability, whether they are on the
business side or the industrial automation and control systems side of the organization
3.1.14
gatekeeper
trusted individual that senior managers use to prioritize issues they need to address over the
remaining issues that others are more suited to address
3.1.15
health, safety, and environment
responsibility for protecting the health and safety of workers and the surrounding community and
maintaining high environmental stewardship
3.1.16
human-machine interface
aggregate of means by which people (the users) interact with a particular machine, device,
computer program or other complex tool (the system)
NOTE In many cases, these involve video screens or computer terminals, push buttons, auditory feedback, flashing
lights, and the like. The human-machine interface provides means of:
 Input, allowing the users to control the machine
 Output, allowing the machine to inform the users . [44]
3.1.17
incident
event that is not part of the expected operation of a system or service that causes or may cause,
an interruption to, or a reduction in, the quality of the service provided by the system

– 17 – ANSI/ISA–62443-2-1 (99.02.01)–2009
3.1.18
independent audit
review of an organization (policies, procedures, processes, equipment, personnel, and the like)
by an external group not affiliated with the organization
NOTE These may be required for public companies.
3.1.19
information technology
computer-related assets of an organization that represent nonphysical assets , such as software
applications, process programs and personnel files
NOTE 1 Throughout this document, this use of the term information technology is not abbreviated.
NOTE 2 Another use of information technology (IT) refers to the company’s internal organization ( for example, the IT
department) or the items traditionally maintained by this department (that is, the administrative computers, servers,
and network infrastructure). Throughout this document, this use of the term information technology is abbreviated as
IT.
3.1.20
legacy system
existing industrial automation and control system in a facility that may not be available as a
commercial off the shelf (COTS) item
NOTE A legacy system may have been COTS at one time, but it may be no longer available and/or supported.
3.1.21
likelihood
quantitative chance that an action, event or incident may occur
3.1.22
local user
user who is inside the perimeter of the security zone being addressed
NOTE A person in the immediate manufacturing area or control room is an example of a local user.
3.1.23
manufacturing execution system
production scheduling and tracking system used to analyze and report resource availability and
status, schedule and update orders, collect detailed execution data such as material usage, labor
usage, operating parameters, order and equipment status and oth er critical information
NOTE 1 It accesses bills of material, routing and other data from the base enterprise resource planning system and is
typically the system used for real-time shop floor reporting and monitoring that feeds activity data back to the base
system. [45]
NOTE 2 Refer to ANSI/ISA-95.00.01-2000, Enterprise-Control System Integration Part 1: Models and Terminology, [7]
for additional information.
3.1.24 --`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
MAC address
hardware address that differentiates one device on a network from another
NOTE For some networks, such as Ethernet, this address is typically encoded on a chip in the device, while in some
industrial networks, such as DeviceNet, these can be controlled in software or with a hardware switch.
3.1.25
operator
particular type of user that is usually responsible for the correct operation of the equipment
under control

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 18 -
3.1.26
patch management
area of systems management that involves acquiring, testing and installing multiple patches
(code changes) to an administered computer system
NOTE Patch management tasks include: maintaining current knowledge of available patches, deciding what patches
are appropriate for particular systems, ensuring that patches are installed properly, testing systems af ter installation
and documenting all associated procedures, such as specific configurations required remotely across heterogeneous
environments according to recognized best practices. [52]
3.1.27
process engineer
person typically responsible for the technical operation of the industrial operation and who uses
the IACS and other tools to oversee and manage the industrial automation in the facility
3.1.28
process information management system
set of systems that provides supporting information to assist with the operation of the facility
3.1.29
programmable logic controller
programmable microprocessor-based device that is used in industry to control assembly lines
and machinery on the shop floor as well as many other types of mechanical, electrical and
electronic equipment in a plant. [54]
NOTE Typically programmed in an IEC 61131 programming language, a PLC is designed for real time use in rugged,
industrial environments. Connected to sensors and actuators, PLCs are ca tegorized by the number and type of I/O
ports they provide and by their I/O scan rate.
3.1.30
process safety management
United States regulation intended to prevent a disaster in chemical and biotechnology systems
by addressing sound management and engineering d esign. [16]
3.1.31
remote access
communication with or use of assets or systems within a defined perimeter from any location
outside that perimeter
3.1.32
remote user
user who is outside the perimeter of the security zone being addressed
NOTE A person in an office in the same building, a person connecting over the corporate wide area network (WAN)
and a person connecting over public infrastructure networks are all examples of remote users.
3.1.33
risk assessment
process of identifying and evaluating risks to the organization’s operations (including mission,
functions, image, or reputation), the organization’s assets or individuals by determining the
likelihood of occurrence, the resulting impact, and additional countermeasures that would
mitigate this impact
NOTE Synonymous with risk analysis and incorporates threat and vulnerability analyses . [25]
3.1.34
risk mitigation
actions to reduce the likelihood and/or severity of an event

--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

– 19 – ANSI/ISA–62443-2-1 (99.02.01)–2009
3.1.35
risk tolerance
risk the organization is willing to accept
3.1.36
self assessment
review of an organization (that is, policies, procedures, operations, equipment, and personnel) by
a group inside the organization
NOTE This group may be either directly associated with the organization’s business proce ss or may be in another
part of the organization, but should be intimately familiar with the risks associated with that business process.
3.1.37
Six Sigma®
process-focused methodology designed to improve business performance through improving
specific areas of strategic business processes [46]
3.1.38
social engineering
practice of obtaining confidential information by manipulation of legitimate users [44]
3.1.39
system administrator
person(s) responsible for managing the security of the computer system
NOTE This may include operating system maintenance, network management, account administration and patch
management, in accordance with the change management process
3.1.40
stakeholder
individual or group with an interest in the success of an organization in delivering intended
results and maintaining the viability of the organization's products and services [50]
NOTE Stakeholders influence programs, products and services. In this particular case, stakeholders are personnel in
an organization responsible for promoting and overseeing the cyber security process. These personnel include the
manager of the cyber security program as well as the cross -functional team of individuals from all of the departments
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
affected by the cyber security program.
3.1.41
ushered access
procedure for monitoring the actions of a remotely connected user
NOTE This is also called shadowing.
3.1.42
vulnerability assessment
formal description and evaluation of the vulnerabilities in a system [25]
3.2 Abbreviated terms and acronyms

This sub-clause defines the abbreviated terms and acronyms used in this document.
ANSI American National Standards Institute
CFR U.S. Code of Federal Regulations
ChemITC Chemical Information Technology Center of the American Chemistry Council
COTS Commercial off the shelf
CPU Central processing unit

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 20 -
CSCSP Chemical Sector Cyber Security Program
CSMS Cyber security management system
CSVA Cyber security vulnerability assessment
DCS Distributed control system
DoS, DDoS Denial of service, Distributed denial of service
FDN Field device network
FTP File transfer protocol
HMI Human machine interface
HSE Health, safety, and environmental
HVAC Heating, ventilation, and air-conditioning
IACS Industrial automation and control system(s)
ID Identification
IEC International Electrotechnical Commission
IEEE The Institute of Electrical and Electronics Engineers
IP Internet protocol
ISA International Society of Automation
ISO International Organization for Standardization
IT Information technology
KPI Key performance indicator(s)
LAN Local area network
MAC Media access control
MES Manufacturing execution system
NERC North American Electric Reliability Council
NIST U.S. National Institute of Standards and Technology
OS Operating system
PC Personal computer
PCN Process control network
PCSRF Process Control Security Requirements Forum
PIM Process information management
PIN Personal identification number
PLC Programmable logic controller
PSM Process safety management
RAID Redundant array of independent disks
RCN Regulatory control network
SANS SysAdmin, Audit, Networking, and Security Institute
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
– 21 – ANSI/ISA–62443-2-1 (99.02.01)–2009
SCADA Supervisory control and data acquisition
SI International System of Units
SIS Safety instrumented system(s)
SoA Statement of applicability
SOC Standard operating condition
SOP Standard operating procedure
SP Special Publication (by NIST)
SSL Secure socket layer
TCP Transmission control protocol

--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
TR Technical report
VLAN Virtual local area network
VPN Virtual private network
WAN Wide area network
3.3 Conventions
The elements of a cyber security management system lists:
 the objective of the element

 a basic description of the element
 a rationale to explain why the element is included
 the requirements for that element
The requirements are presented as a table but not treated as tables in the sense of ISO/IEC
directives. The tables list the description and the requirements for these elements. These are
numbered similar to a sub-clause, so that they could be referenced, but the tables are not
numbered with table numbers. The reference is given by the heading number in the description
cell of the table.

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 22 -
4 Elements of a cyber security management system

4.1 Overview
This clause presents the elements that constitute a CSMS for IACS. These elements represent
what shall and should be included in the CSMS in order to protect IACS against cyber attacks.
The elements are presented in three main categories:
 Risk analysis
 Addressing risk with the CSMS
 Monitoring and improving the CSMS
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

– 23 – ANSI/ISA–62443-2-1 (99.02.01)–2009
Risk analysis
Risk identification,
Business rationale classification and
assessment
Addressing risk with the CSMS

Security policy, Selected security Implementation
organization and countermeasures
awareness
Risk
Personnel
CSMS scope management and
security
implementation
Physical and System

Organize for
environmental development and
security
security maintenance
Staff training and Information and

Network
security document
segmentation
awareness management
Access control:
Business Incident planning
Account
continuity plan and response
administration
Security policies Access control:

and procedures Authentication
Access control:
Authorization
Monitoring and improving the CSMS
Review, improve and

Conformance
maintain the CSMS
Figure 1 – Graphical view of elements of a cyber security management system
Each of these categories is further divided into element groups and/or elements. Figure 1 depicts
the relationship between the categories, element groups and elements.
Each element in this clause lists the objective of the element, a basic description of the element,
a rationale to explain why the element is included , and the requirements for that element.
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
Annex A follows the same basic structure of this clause with categories, element groups , and
elements. However, Annex A provides guidance on how to develop the elements of the CSMS.
The reader should read Annex A in order to understand the special needs and issues involved

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 24 -
with developing a CSMS for IACS. The guidance discussed in Annex A should be tailored to the
special requirements of each organization.
This standard specifies the elements required for a CSMS. It is not the intent of the standard to
specify a particular sequential process for identifying and addressing risk that i ncorporates these
elements. Thus, an organization will create such a process in accordance with its culture,
organization, and the current status of its cyber security activities. To assist organizations with
this aspect of applying the standard, Annex A.3.4.2 provides an example of a process for
identifying and addressing risk. In addition, Annex B offers insights on effective ordering for
activities related to all of the elements discussed in this standard.
While a CSMS is an excellent tool for managing risk within a large company, it is equally
applicable to small companies. The CSMS may be more formalized in a large company so it can
be used in many different situations and geographies. In a small company, similar CSMS
activities need to be conducted, but they may not be as formal. Clause 4 and Annex A provide
guidance to help the user better understand the elements and activities of a CSMS.
4.2 Category: Risk analysis

4.2.1 Description of category
The first main category of the CSMS is risk analysis. This category discusses much of the
background information that feeds into many of the other elements in the CSMS. Figure 2 shows
the two elements in this category:
 Business rationale
 Risk identification, classification, and assessment
Risk Analysis
assessment
Figure 2 – Graphical view of category: Risk analysis
4.2.2 Element: Business rationale

Objective:
Identify and document the unique needs of an organization to address cyber risk for IACS.
Description:
A business rationale is based on the nature and magnitude of financial, health, safety,
environmental, and other potential consequences should IACS cyber incidents occur.
Rationale:
Establishing a business rationale is essential for an o rganization to maintain management buy-in
to an appropriate level of investment for the IACS cyber security program.
Copyright 2009 ISA. All rights reserved. --`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

– 25 – ANSI/ISA–62443-2-1 (99.02.01)–2009
Requirements:
Description Requirement
4.2.2.1 Develop a business rationale The organization should develop a high-level

business rationale as a basis for its effort to
manage IACS cyber security, which addresses the
unique dependence of the organization on IACS.
4.2.3 Element: Risk identification, classification, and assessment

Objective:
Identify the set of IACS cyber risks that an organization faces a nd assess the likelihood and
severity of these risks.
Description:
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
Organizations protect their abilities to perform their missions by systematically identifying,

prioritizing and analyzing potential security threats, vulnerabilities, and consequences using
accepted methodologies. The first set of requirements presents the actions an organization takes
to carry out both a high level and a detailed risk assessment that incorporates vulnerability
assessment, in a typical chronological order. Among these requir ements, those related to
preparing for high level and detailed risk assessments are 4.2.3.1, 4.2.3.2 and 4.2.3.8. The last
few requirements (4.2.3.10 to 4.2.3.14) are general requirements that apply to the overall risk
assessment process. Section 4.3.4.2 covers the process of taking action based upon this
assessment.
Rationale:
Since the purpose of investing in cyber security is to lower risk, it is driven by an understanding
of level of risk and potential mitigations.
Requirements:
4.2.3.1 Select a risk assessment The organization shall select a particular risk
methodology assessment and analysis approach and
methodology that identifies and prioritizes risks
based upon security threats, vulnerabilities and
consequences related to its IACS assets.
4.2.3.2 Provide risk assessment background The organization should provide participants in the
information risk assessment activity with appropriate
information including methodology training, before
beginning to identify the risks.
4.2.3.3 Conduct a high-level risk A high-level system risk assessment shall be
assessment performed to understand the financial and HSE
consequences in the event that availability, integrity
or confidentiality of the IACS is compromised.
4.2.3.4 Identify the industrial automation The organization shall identify the various IACS,
and control systems gather data about the devices to characterize the
nature of the security risk, and group the devices
into logical systems.

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 26 -
4.2.3.5 Develop simple network diagrams The organization shall develop simple network
diagrams for each of the logically integrated
systems showing the major devices, network types,
and general locations of the equipment.
4.2.3.6 Prioritize systems The organization shall develop the criteria and
assign a priority rating for mitigating the risk of each
logical control system.
4.2.3.7 Perform a detailed vulnerability The organization shall perform a detailed
assessment vulnerability assessment of its individual logical
IACS, which may be scoped based on the high-level
risk assessment results and prioritization of IACS
subject to these risks.
4.2.3.8 Identify a detailed risk assessment The organization’s risk assessment methodology
methodology shall include methods for prioritizing detailed
vulnerabilities identified in the detailed vulnerability
assessment.
4.2.3.9 Conduct a detailed risk assessment The organization shall conduct a detailed risk
assessment incorporating the vulnerabilities
identified in the detailed vulnerability assessment.
4.2.3.10 Identify the reassessment frequency The organization shall identify the risk and
and triggering criteria vulnerability reassessment frequency as well as any
reassessment triggering criteria based on
technology, organization, or industrial operation
changes.
4.2.3.11 Integrate physical, HSE and cyber The results of physical, HSE and cyber security risk
security risk assessment results assessments shall be integrated to understand the
assets’ overall risk.
4.2.3.12 Conduct risk assessments Risk assessments shall be conducted through all
throughout the lifecycle of the IACS stages of the technology lifecycle including
development, implementation, changes, and
retirement.
4.2.3.13 Document the risk assessment The risk assessment methodology and the results of
the risk assessment shall be documented.
4.2.3.14 Maintain vulnerability assessment Up-to-date vulnerability assessment records should
records be maintained for all assets comprising the IACS.
4.3 Category: Addressing risk with the CSMS

The second main category of the CSMS is addressing risk with the CSMS. This category
contains the bulk of the requirements and information contained in the CSMS. It is divided into
three element groups:
 Security policy, organization and awareness

 Selected security countermeasures
 Implementation
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

– 27 – ANSI/ISA–62443-2-1 (99.02.01)–2009
4.3.2 Element group: Security policy, organization, and awareness

4.3.2.1 Description of element group
The first element group in this category discusses the develo pment of the basic cyber security
policies, the entities responsible for cyber security, and the awareness within the organization of
cyber security issues. Figure 3 depicts the five elements in the element group:
 CSMS scope
 Organizing for security
 Staff training and security awareness
 Business continuity plan
 Security policies and procedures
Security policy, organization and awareness
Staff training and

Organize for Business
CSMS scope security
security continuity plan
awareness
Security policies
and procedures
Figure 3 – Graphical view of element group: Security policy, organization, and awareness
4.3.2.2 Element: CSMS scope

Objective:
Identify, assess, and document the systems, processes, and organizations to which the CSMS
applies.
Description:
The scope includes all aspects of the IACS, including integration points with business partners,
customers, and suppliers.
Rationale:
Management should understand the boundaries where the CSMS appl ies to the organization as
well as establish a direction and focus for the CSMS. By developing a clearly defined scope, it is
easier for management to convey its goals and purpose for the CSMS.
Requirements:
4.3.2.2.1 Define the scope of the CSMS The organization shall develop a formal written
scope for the cyber security program.
4.3.2.2.2 Define the scope content The scope should explain the strategic goals,
process, and timing for the CSMS.

--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 28 -
4.3.2.3 Element: Organizing for security

Objective:
Establish the entities responsible for managing, conducting, and assessing the overall cyber
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
security of the organization’s IACS assets.
Description:
Senior leadership establishes an organization, structure or network of people to provide
oversight and direction for managing cyber security risks associated with IACS. They also
provide the personnel necessary to conduct and assess the cyber security programs throughout
the organization over the life of the CSMS. An organization at any level may implement this
standard, including a company or other overall enterprise, division, plant , or subset of a plant.
Rationale:
Commitment to a security program begins at the top of the organization . Because cyber security
of IACS involves several different skill sets not often found in any one particular section or
department of an organization, it is imperative that senior leadership formulate an approach to
managing security with clear identification of accountability and r esponsibility that makes good
use of skills and people resources. This may take several different forms from a single
organization to a network of people working together to address different security aspects . The
particular approach is highly dependent up on an organization’s operational culture.
Requirements:
4.3.2.3.1 Obtain senior management support The organization shall obtain senior management
support for a cyber security program.
4.3.2.3.2 Establish the security There shall be an organization, structure or network
organization(s) of stakeholders established (or chosen) under
management leadership, with the responsibility to
provide clear direction and oversight for the cyber
aspects of the IACS.
4.3.2.3.3 Define the organizational Organizational responsibilities shall be clearly
responsibilities defined for cyber security and related physical
security activities.
4.3.2.3.4 Define the stakeholder team makeup The core team of stakeholders should be cross-
functional in nature to bring together the skills
necessary to address security in all parts of the
IACS.
4.3.2.4 Element: Staff training and security awareness

Objective:
Provide all personnel (including employees, contract employees and third-party contractors) with
the information necessary to identify, review, address and ,where appropriate, remediate
vulnerabilities and threats to IACS and to help ensure their own work practices are using
effective countermeasures.
Description:
All personnel should receive adequate technical training associated with the known threats a nd
vulnerabilities of hardware, software, and social engineering.

– 29 – ANSI/ISA–62443-2-1 (99.02.01)–2009
Rationale:
In the area of industrial automation and control systems, the same emphasis should be placed
on cyber security as on safety and operational integrity, because the consequences can be just
as severe. Security awareness for all personnel is an essential tool for reducing cyber security
risks. Knowledgeable and vigilant staff are one of the most important lines of defense in securing
a system. It is therefore important for all personn el to understand the importance of security in
maintaining the safe operation of the system.
Requirements:
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
4.3.2.4.1 Develop a training program The organization shall design and implement a
cyber security training program.
4.3.2.4.2 Provide procedure and facility All personnel (including employees, contract
training employees, and third-party contractors) shall be
trained initially and periodically thereafter in the
correct security procedures and the correct use of
information processing facilities.
4.3.2.4.3 Provide training for support All personnel that perform risk management, IACS
personnel engineering, system administration/maintenance
and other tasks that impact the CSMS should be
trained on the security objectives and industrial
operations for these tasks.
4.3.2.4.4 Validate the training program The training program should be validated on an on -
going basis to ensure that personnel understand the
security program and that they are receiving the
proper training.
4.3.2.4.5 Revise the training program over The cyber security training program shall be
time revised, as necessary, to account for new or
changing threats and vulnerabilities.
4.3.2.4.6 Maintain employee training records Records of employee training and schedules for
training updates should be maintained and reviewed
on a regular basis.
4.3.2.5 Element: Business continuity plan

Objective:
Identify procedures for maintaining and/or re-establishing essential business operations while
recovering from a significant disruption.
Description:
A business continuity plan should address the recovery objectives for the various systems and
subsystems involved based on typical business needs , a list of potential interruptions and the
recovery procedures for each and a schedule to test part or all of the recovery procedures. One
of the primary recovery objectives should be to maintain maximum availability of the control
system.

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 30 -
Rationale:
No set of defenses can prevent all disruptions due to cyber security incidents. A detailed
Business Continuity Plan ensures that IACS information can be restored and utilized as soon as
possible after the occurrence of a significant disruption.
Requirements:
4.3.2.5.1 Specify recovery objectives Prior to creating a business continuity plan, the
organization shall specify recovery objectives for
the systems involved based on business needs.
4.3.2.5.2 Determine the impact and The organization should determine the impact to
consequences to each system each system due to a significant disruption and the
consequences associated with loss of one or more
of the systems.
4.3.2.5.3 Develop and implement business Continuity plans shall be developed and
continuity plans implemented to ensure that business processes can
be restored in accordance with recovery objectives.
4.3.2.5.4 Form a business continuity team A business continuity team should be formed
including IACS and other process owners. In the
event of a significant disruption, this team should
determine the priority of critical business and IACS
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
systems to re-establish operations.

4.3.2.5.5 Define and communicate specific The business continuity plan shall define and
roles and responsibilities communicate the specific roles and responsibilities
for each part of the plan.
4.3.2.5.6 Create backup procedures that The organization shall create backup and restore
support business continuity plan procedures (see 4.3.4.3.9) that support the
business continuity plan.
4.3.2.5.7 Test and update the business The business continuity plan shall be tested on a
continuity plan regular basis and updated as necessary.
4.3.2.6 Element: Security policies and procedures

Objective:
Address how an organization defines security, operates its security program, defines and
addresses its tolerance for risk, and reviews its program to make further improvements.
Description:
Cyber security policies for the IACS environment should be developed based on existing high -
level policies, characterized risks, and the risk tolerance levels identified by management. Cyber
security procedures are developed from the cyber security policies and identify how the p olicies
are to be implemented.
Rationale:
These written policies and procedures allow employees, contractors, third parties, and others to
clearly understand a company’s perspective of cyber security and their roles and responsibilities
in securing the company’s assets.

– 31 – ANSI/ISA–62443-2-1 (99.02.01)–2009
Requirements:
4.3.2.6.1 Develop security policies The organization shall develop high-level cyber
security policies for the IACS environment which
are approved by management.
4.3.2.6.2 Develop security procedures The organization shall develop and approve cyber
security procedures, based on the cyber security
policies, and provide guidance in how to meet the
policies.
4.3.2.6.3 Maintain consistency between risk Cyber security policies and procedures that deal
management systems with IACS risks should be consistent with or
extensions of policies created by other risk
management systems.
4.3.2.6.4 Define cyber security policy and Cyber security policies and procedures for the IACS
procedure compliance requirements environment shall include compliance requirements.
4.3.2.6.5 Determine the organization’s The organization shall determine and document its
tolerance for risk risk tolerance as a basis for creation of policy and
risk management activities.
4.3.2.6.6 Communicate the policies and Cyber security policies and procedures for the IACS
procedures to the organization environment shall be communicated to all
appropriate personnel.
4.3.2.6.7 Review and update the cyber The cyber security policies and procedures shall be
security policies and procedures reviewed regularly, validated to confirm that they
are up-to-date and being followed, and updated as
required to ensure that they remain appropriate.
4.3.2.6.8 Demonstrate senior leadership Senior leadership shall demonstrate commitment to
support for cyber security cyber security by endorsing the cyber security
policies.
4.3.3 Element group: Selected security countermeasures

The second element group within this category is selected security countermeasures. The
elements within this group discuss some of the main types of security controls that are part of a
well-designed CSMS. This document does not attempt to describe the full implementation of any
of these selected security countermeasures. It discusses many of the policy, procedure , and
practice issues related to these particular security countermeasures. Figure 4 shows a graphical --`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
representation of the six elements in the element group:
 Personnel security
 Physical and environmental security
 Network segmentation
 Access control: Account administration
 Access control: Authentication
 Access control: Authorization

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 32 -
Selected security countermeasures
Physical and Access control:

Personnel Network
environmental Account
security segmentation
security administration
Access control: Access control:

Authentication Authorization
Figure 4 – Graphical view of element group: Selected security countermeasures
These particular countermeasures were selected for inclusion because their broad impa ct on
policy and architecture makes it essential to consider them up front when constructing any
CSMS. It is not the intent of this standard to specify a complete and sufficient list of
countermeasures, since completeness is determined through the process of risk assessment and
management described in the standard.
4.3.3.2 Element: Personnel security

Objective:
Establish the policies and procedures to determine whether personnel will maintain the IACS
security of the organization throughout the lifecycle of their e mployment.
Description:
Personnel security involves looking at new and current personnel to determine if they will
maintain the IACS security for the organization . For new personnel, it evaluates them prior to
their entry into the organization making sure they demonstrate behaviors consistent with their
future security responsibility. For current personnel, it establishes that they continue to
demonstrate behavior consistent with their current security responsibilities.
Rationale:
In many organizations, personnel security requirements are driven by concerns about insider
threats and the possibility of accidents caused by inattention to detail or by personnel unfit for a
job due to lack of proper background or the use of substances that might cloud judgment. By
implementing personnel security policies, it may be possible to reduce these types of problems .
Requirements:
4.3.3.2.1 Establish a personnel security policy There shall be a personnel security policy
established, clearly stating the organization’s
commitment to security and the security
responsibilities of personnel. (Personnel include
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
employees, prospective employees, contract

employees, and third-party contractors.)

– 33 – ANSI/ISA–62443-2-1 (99.02.01)–2009
4.3.3.2.2 Screen personnel initially Unless government regulation prohibits it, all
personnel with access to the IACS (both physical
and cyber), including new hires and internal
transfers to sensitive positions, shall be screened,
including validation of their identity and background
checks, during the job application process.
4.3.3.2.3 Screen personnel on an ongoing Personnel should also be subject to ongoing
basis scrutiny for changes that might indicate a conflict of
interest or concern for performing the job in an
appropriate manner.
4.3.3.2.4 Address security responsibilities The personnel security policy should address
security responsibilities from recruitment through
the end of employment, especially for sensitive
positions.
4.3.3.2.5 Document and communicate security Security expectations and responsibilities shall be
expectations and responsibilities clearly documented and regularly communicated to
personnel.
4.3.3.2.6 State cyber security terms and Terms and conditions of employment shall clearly
conditions of employment clearly state an employee’s responsibility for cyber
security. These responsibilities shall extend for a
reasonable period of time after employment ceases .
4.3.3.2.7 Segregate duties to maintain Duties should be segregated among personnel to
appropriate checks and balances maintain appropriate checks and balances, so that
no single individual has total control over actions
that change the functional operation of the IACS.
4.3.3.3 Element: Physical and environmental security

Objective:
Create a secure environment for the protection of IACS assets. An asset is any physical or
logical object owned by or under the custodial duties of an organization, having either a
perceived or actual value to the organization (see ANSI/ISA–99.01.01–2007). IACS assets are
those assets that are a part of the IACS, either physical or cyber or that can affect the operation
of the IACS. Physical security measures ensure that all assets, specifically those related to the
IACS of an organization, are protected physically from unauthorized access, loss, damage,
misuse, and the like. Environmental security measures ensure that the assets of an organization
are protected against environmental conditions that would make them unusable or damage the
information they contain.
Description:
Physical and environmental security measures should be designed to complement the cyber
security measures taken to protect assets that are part of the IACS and coordinated with the
physical security of the remainder of the plant. When developing a program for physical security
of assets, it is important to include all systems in the scope and not just limit the ef fort to
traditional computer room facilities. Practical engineering judgment should be used to balance
the risks when determining physical security procedures. Physical segmentation is a key security
countermeasure designed to compartmentalize devices into security zones where identified
security practices are employed to achieve the desired target security level.

--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 34 -
Rationale:
Physical assets are a means to an end as well as an end in themselves. In modern control
systems the physical assets provide the means by which the cyber system operates. Therefore,
the assets have value in themselves, but also as integral parts of the control system. Since both
the assets and the control system require each other, both must be protected in order for the
system to be secure. The overriding security premise is that the use of security countermeasures
should be commensurate with the level of risk. While physical segmentation is an important
security countermeasure employed in conjunction with other layers of defense to redu ce the risk
that may be associated with IACS, it may not be necessary if the security risks are within
accepted limits.
Requirements:
4.3.3.3.1 Establish complementary physical Security policies and procedures shall be

and cyber security policies established that address both physical and cyber
security in the protection of assets.
4.3.3.3.2 Establish physical security One or more physical security perimeters shall be
perimeter(s) established to provide barriers to unauthorized
access to protected assets.
4.3.3.3.3 Provide entry controls Appropriate entry controls shall be provided at each
barrier or boundary.
4.3.3.3.4 Protect assets against environmental Assets shall be protected against environmental
damage damage from threats such as fire, water, smoke,
dust, radiation, corrosion, and impact.
4.3.3.3.5 Require employees to follow security Employees shall be required to follow and enforce
procedures the physical security procedures that have been
established.
4.3.3.3.6 Protect connections All connections under the control of the
organization shall be adequately protected from
tampering or damage.
4.3.3.3.7 Maintain equipment assets All equipment assets, including auxiliary
environmental equipment, shall be properly
maintained to ensure proper operation.
4.3.3.3.8 Establish procedures for monitoring Procedures shall be established for monitoring and
and alarming alarming when physical or environmental security is
compromised.
4.3.3.3.9 Establish procedures for the Procedures should be established and audited with
addition, removal, and disposal of respect to the addition, removal, and disposal of all
assets assets.
4.3.3.3.10 Establish procedures for the interim Procedures shall be established to ensure the
protection of critical assets protection of critical–components during the
interruption of operations, for example, due to fire,
water ingress, security breach, interruption, or
natural or any other type of disaster.
--`,`,`,,`,,`,````,`,,``,,,`,`,

– 35 – ANSI/ISA–62443-2-1 (99.02.01)–2009
4.3.3.4 Element: Network segmentation

Objective:
Group and separate key IACS devices into zones with common security levels in order to
manage security risks, and to achieve a desired target security level for each zone.
Description:
Network segmentation is a key security countermeasure designed to compartmentalize devices
into security zones where identified security practices are employed to achieve the desired target
security level. The zone may be an isolated standalone network segment or a network segment
separated from the organization’s network by some sort of a network barrier device. IACS should
be designed in a manner that filters/removes nonessential communication packets from reaching
the IACS devices.
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
For transmission control protocol / internet protocol (TCP/IP) based networks, the most common
barrier devices currently in use are firewalls, routers, and layer 3 switches. For non-TCP/IP type
networks, the barrier devices may be standalone gateways or integrated into the network
interface module of an IACS device.
Rationale:
The overriding security premise is that the use of security countermeasures should be
commensurate with the level of risk. While network segmentation is an important security
countermeasure employed in conjunction with other layers of defense to reduce the risk that may
be associated with IACS, it may not be necessary if the security risks are low.
Requirements:
4.3.3.4.1 Develop the network segmentation A network segmentation countermeasure strategy

architecture employing security zones shall be developed for
IACS devices based upon the risk level of the IACS.
4.3.3.4.2 Employ isolation or segmentation on High-risk IACS shall be isolated from or employ a
high-risk IACS barrier device to separate it from other zones with
different security levels or risks.
4.3.3.4.3 Block non-essential communications Barrier devices shall block all non-essential
with barrier devices communications in and out of the security zone
containing critical control equipment.
4.3.3.5 Element: Access control: Account administration

Objective:
Ensure, on an ongoing basis, that only appropriate entities have accounts that allow access and
that these accounts provide appropriate access privileges.
Description:
Access control is the method of controlling who or which entities can access premises and
systems and what type of access is permitted. There are three key aspects associated with
access control: account administration, authentication, and authorization. All three aspects must
work together to establish a sound and secure access control strategy.

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 36 -
Account administration is the method associated with granting and revoking access accounts and
maintaining the permissions and privileges provided under these accounts to access specific
resources and functions on the physical premises, network, or system. Access accounts should
be function or role-based and may be defined for individuals, groups of individuals functioning as
a crew, or devices providing a function.
Rationale:
The misuse of data and systems may have serious consequences, including harm to human life,
environmental damage, financial loss, and damaged corporate reputation. These risks are
increased when employees, contractors, or temporary personnel have unnecessary access to
data and systems.
Requirements:
4.3.3.5.1 Access accounts implement Access privileges implemented for access accounts
authorization security policy shall be established in accordance with the
organization’s authorization security policy (see
4.3.3.7.1).
4.3.3.5.2 Identify individuals As for all cyber security controls, the choice of
access accounts for individuals versus access
accounts for a crew shall be determined by
considering threats, risks, and vulnerabilities. In this
case, considerations include HSE risks of individual
controls, mitigation using complementary physical
security controls, requirement for accountability,
and administrative/operational need.
4.3.3.5.3 Authorize account access Access shall be granted, changed, or terminated on
the authority of an appropriate manager.
4.3.3.5.4 Record access accounts A record shall be maintained of all access accounts,
including details of the individual(s) and devices
authorized to use the account, their permissions,
and the authorizing manager.
4.3.3.5.5 Suspend or remove unneeded Access accounts shall be suspended or removed as
accounts soon as they are no longer needed (for example,
job change).
4.3.3.5.6 Review account permissions All established access accounts shall be reviewed
regularly to ensure that the individual(s) and
devices have only the minimum required
permissions.
4.3.3.5.7 Change default passwords Default passwords for access accounts shall be
changed before the IACS is put into service.
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
4.3.3.5.8 Audit account administration Periodic reviews of compliance to the account

administration policy should be performed.

– 37 – ANSI/ISA–62443-2-1 (99.02.01)–2009
4.3.3.6 Element: Access control: Authentication

Objective:
Positively identify network users, hosts, applications, services , and resources for computerized
transaction so that they can be given the rights and responsibilities associated with the accounts
they have been granted under account administration.
Description:
Access control is the method of controlling who or which resources can access premises and
systems and which type of access is permitted. There are three key aspects associated with
work together to establish a sound and secu re access control strategy.
There are several types of authentication strategies and each has varying degrees of strength.
Strong authentication methods are ones that are quite accurate in positively identifying the user.
Weak authentication methods are ones that can be easily defeated to provide unwanted access
to information. Physical location of the user may have a significant impact on the risk of
accessing the IACS.
Rationale:
Authentication requirements are more stringent for administration/configurat ion users and remote
users than for other users. This is because administration/configuration users have broader
privileges and their actions have potentially more impact than those of other users; and remote
users are typically not subject to complementar y physical access controls. Automatic account
lockout due to failed logins or periods of inactivity increases authentication strength, but is
considered carefully in the IACS environment, since failure to authenticate a valid user could
have HSE implications if the user is not able to perform tasks in a critical situation. In the IACS
environment, there typically is great emphasis on combining physical authentication measures
with electronic authentication practices.
Requirements:
4.3.3.6.1 Develop an authentication strategy Companies shall have an authentication strategy or

approach that defines the method(s) of
authentication to be used.
4.3.3.6.2 Authenticate all users before system All users shall be authenticated before using the
use requested application, unless there are
compensating combinations of entrance control
technologies and administrative practices.
4.3.3.6.3 Require strong authentication Strong authentication practices (such as requiring
methods for system administration strong passwords) shall be used on all system
and application configuration administrator and application configuration access
accounts.
4.3.3.6.4 Log and review all access attempts Log files should record all access attempts to
to critical systems critical systems and should be reviewed for
successful and failed access attempts.
4.3.3.6.5 Authenticate all remote users at the The organization shall employ an authentication
appropriate level scheme with an appropriate level of strength to
positively identify a remote interactive user.

--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 38 -
4.3.3.6.6 Develop a policy for remote login The organization shall develop a policy addressing
and connections remote login by a user and/or remote connections
(for example, task-to-task connections) to the
control system which defines appropriate system
responses to failed login attempts and periods of
inactivity.
4.3.3.6.7 Disable access account after failed After some number of failed login attempts by a
remote login attempts remote user, the system should disable the access
account for a certain amount of time.
4.3.3.6.8 Require re-authentication after After a defined period of inactivity, a remote user
remote system inactivity should be required to re-authenticate before he or
she can re-access the system.
4.3.3.6.9 Employ authentication for task-to- Systems should employ appropriate authentication
task communication schemes for task-to-task communication between
applications and devices.
4.3.3.7 Element: Access control: Authorization

Objective:
Grant access privileges to resources upon successful authentication of the user and
identification of his or her associated access account. The privileges granted are determined by
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
the account configuration set up during the account administration step in the business process.
Description:
Access control is the method of controlling who or which resources can access premises and
systems and which type of access is permitted. There are three key aspects associated with
work together to establish a sound and secure access cont rol strategy.
Authorization explores the controls aimed at protecting information and assets from deliberate
and inadvertent destruction, change, or disclosure. It focuses specifically on measures designed
to ensure that the authenticated agents have acces s to required information assets. As with
authentication, authorization is dependent upon the location of the user.
Rationale:
It is important in the IACS environment to make sure that the right people have access to the
correct information and systems and are not prevented from doing their jobs due to lack of
authorization. Authorization to perform specific job functions is provided by the application .
Safety implications must be considered when developing the authorization strategy.
Requirements:
4.3.3.7.1 Define an authorization security Rules that define the privileges authorized under
policy access accounts for personnel in various job roles
shall be defined in an authorization security policy
that is clearly documented and applied to all
personnel upon authentication.

– 39 – ANSI/ISA–62443-2-1 (99.02.01)–2009
4.3.3.7.2 Establish appropriate logical and The permission to access IACS devices shall be
physical permission methods to logical (rules that grant or deny access to known
access IACS devices users based on their roles), physical (locks,
cameras, and other controls that restrict access to
an active computer console), or both.
4.3.3.7.3 Control access to information or Access accounts should be role based to manage
systems via role-based access access to appropriate information or systems for
accounts that user’s role. Safety implications shall be
considered when defining roles.
4.3.3.7.4 Employ multiple authorization In critical control environments, multiple
methods for critical IACS authorization methods should be employed to limit
access to the IACS.
4.3.4 Element group: Implementation

The third element group in this category is implementation. This element within this group
discusses issues related to implementing the CSMS. Figure 5 depicts the four elements in the
element group:
 Risk management and implementation

 System development and maintenance
 Information and document management
 Incident planning and response
Implementation
Risk System Information and

Incident planning
management and development and document
and response
implementation maintenance management
Figure 5 – Graphical view of element group: Implementation
4.3.4.2 Element: Risk management and implementation

Objective:
Reduce risk to and maintain risk at an acceptable level in the IACS based upon the
organization’s tolerance for risk.
Description:
Risk management and implementation addresses the selection, development and implementation
of countermeasures that are commensurate with risks. The countermeasures may take into
account use of products with strong inherent security capabilities, manual and procedural
security controls, and technology-based controls to prevent or reduce security incidents.

--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 40 -
Rationale:
For the results from the risk identification classification and assessment element of this standard
to be useful, they must be effectively turned into concrete actions under the risk management
and implementation element. Although never totally eliminated, risk can be managed in a manner
that balances the cost of risk avoidance to the potential cost of the incident .
Requirements:
4.3.4.2.1 Manage IACS risk on an ongoing The organization shall adopt a risk management
basis framework that includes selection and
implementation of IACS devices and
countermeasures to manage risk to an acceptable
level over the life of the facility.
4.3.4.2.2 Employ a common set of A common defined set of countermeasures
countermeasures (technical and administrative) to address both
physical and cyber security risks should be defined
and applied across the organization wherever a
specific risk is identified.
4.3.4.3 Element: System development and maintenance

Objective:
Ensure that the organization’s desired risk tolerance level is maintained as its IACS assets
evolve through the maintenance of existing systems and development and procurement of new
systems.
Description:
This element addresses designing cyber security into systems from the ea rliest development
stages. It also involves the maintenance of those cyber security policies and procedures as the
system changes throughout its lifecycle.
Rationale:
Organizations have found maintenance of the CSMS is more challenging than establishing it. For
this reason, procedures that proactively address cyber security as part of the natural evolution of
the IACS systems are critical.
Requirements:
4.3.4.3.1 Define and test security functions The security functions and capabilities of each new
and capabilities component of the IACS shall be defined up front,
developed or achieved via procurement, and tested
together with other components so that the entire
system meets the desired security profile.
4.3.4.3.2 Develop and implement a change A change management system for the IACS
management system environment shall be developed and implemented.
The change management process shall follow
separation of duty principles to avoid conflicts of
interest.
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

– 41 – ANSI/ISA–62443-2-1 (99.02.01)–2009
4.3.4.3.3 Assess all the risks of changing the Using clearly defined criteria, proposed changes to
IACS the IACS shall be reviewed for their potential impact
to HSE risks and cyber security risks by individuals
technically knowledgeable about the industrial
operation and the IACS system.
4.3.4.3.4 Require security policies for system The security requirements of a new system being
development or maintenance installed in the IACS environment in an existing
changes zone shall meet the security policies and
procedures required for that zone/environment.
Similarly, maintenance upgrades or changes shall
meet the security requirements for the zone.
4.3.4.3.5 Integrate cyber security and process Cyber security change management procedures
safety management (PSM) change should be integrated with existing PSM procedures.
management procedures
4.3.4.3.6 Review and maintain policies and The operations and change management policies
procedures and procedures shall be reviewed and kept current
to ensure that security changes do not increase
risks to safety or business continuity.
4.3.4.3.7 Establish and document a patch A procedure for patch management shall be
management procedure established, documented, and followed.
4.3.4.3.8 Establish and document A procedure for antivirus/malware management
antivirus/malware management shall be established, documented, and follo wed.
procedure
4.3.4.3.9 Establish backup and restoration A procedure for backing up and restoring computer
procedure systems and protecting backup copies shall be
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
established, used, and verified by appropriate

testing.
4.3.4.4 Element: Information and document management

Objective:
Classify, manage, safeguard, and present the information associated with the IACS and CSMS at
the appropriate time to authorized personnel.
Description:
Organizations should employ comprehensive information and document management policies for
information assets within the scope of their IACS and CSMS. Care should be given to protect this
information and verify that the appropriate versions are retained. Information classification
systems that allow information assets to receive the appropriate level of protection are the key to
meeting this objective.
Rationale:
Much of the information about the IACS may be stored electronically or in hardcopy outside the
IACS and is not protected by IACS authorization controls. Unauthorized access and use of this
information is a threat to IACS security. This information needs to be appropriately controlled
and managed.

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 42 -
Requirements:
4.3.4.4.1 Develop lifecycle management A lifecycle document management process shall be

processes for IACS information developed and maintained for IACS information.
4.3.4.4.2 Define information classification Information classification levels (for example,
levels company confidential, restricted, or public) shall be
defined for access and control, including sharing,
copying, transmitting, and distributing appropriate
for the level of protection required.
4.3.4.4.3 Classify all CSMS information assets All logical assets within the scope of the CSMS
(that is, control system design information,
vulnerability assessments, network diagrams, and
industrial operations programs) shall be classified
to indicate the protection required commensurate
with the consequences of unauthorized disclosure
or modification.
4.3.4.4.4 Ensure appropriate records control Policies and procedures should be developed
detailing retention, physical and integrity protection,
destruction, and disposal of all assets based on
their classifications, including written and electronic
records, equipment and other media containing
information, with consideration for legal or
regulatory requirements.
4.3.4.4.5 Ensure long-term records retrieval Appropriate measures should be employed to
ensure long-term records can be retrieved (that is,
converting the data to a newer format or retaining
older equipment that can read the data).
4.3.4.4.6 Maintain information classifications Information that requires special control or handling
should be reviewed on a periodic basis to validate
that special handling is still required.
4.3.4.4.7 Audit the information and document Periodic reviews of compliance to the information
management process and document management policy should be
performed.
4.3.4.5 Element: Incident planning and response

Objective:
Predefine how the organization will detect and react to cyber security incidents .
Description:
When developing a program for incident planning a nd response, it is important to include all
systems in scope and not just limit the effort to traditional computer room facilities. Part of the
incident response plan should include procedures for how the organization will respond to
incidents, including notification and documentation methods, investigations, recoveries, and
subsequent follow-up practices.
Rationale:
Identifying an incident early and responding appropriately can limit the consequence s of the
event. Incident planning and response provides the organization the opportunity to plan for
security incidents and then to respond per the established company practice . No matter how
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`

– 43 – ANSI/ISA–62443-2-1 (99.02.01)–2009
much care is taken in protecting a system, it is always possible that unwanted intrusions might
compromise the system. Technology vulnerabilities continue to exist and external threats are
increasing in number and sophistication, therefore requiring a robust strategy for determining the
appropriate planning and response. Insight gained from actual incidents is captured becaus e it is
critical for evaluating and improving the CSMS.
Requirements:
4.3.4.5.1 Implement an incident response plan The organization shall implement an incident
response plan that identifies responsible personnel
and defines actions to be performed by designated
individuals.
4.3.4.5.2 Communicate the incident response The incident response plan shall be communicated
plan to all appropriate organizations.
4.3.4.5.3 Establish a reporting procedure for The organization should establish a reporting
unusual activities and events procedure to communicate unusual activities and
events that may actually be cyber security
incidents.
4.3.4.5.4 Educate employees on reporting Employees should be educated on their
cyber security incidents responsibility to report cyber security incidents and
the methods of reporting these incidents.
4.3.4.5.5 Report cyber security incidents in a The organization should report cyber security
timely manner incidents in a timely manner.
4.3.4.5.6 Identify and respond to incidents If an incident is identified, the organization shall
promptly respond in accordance with the
established procedures.
4.3.4.5.7 Identify failed and successful cyber The organization should have procedures in place
security breaches to identify failed and successful cyber security
breaches.
4.3.4.5.8 Document the details of incidents The details of an identified incident shall be
documented to record the incident, the response,
the lessons learned, and any actions taken to
modify the CSMS in light of this incident.
4.3.4.5.9 Communicate the incident details The documented details of an incident shall be
communicated to all appropriate organizations (that
is, management, IT, process safety, automation and
control engineering, security and manufacturing) in
a timely manner.
4.3.4.5.10 Address and correct issues The organization shall have a business
discovered methodology in place to address issues discovered
and ensure they are corrected.
4.3.4.5.11 Conduct drills Drills should be conducted to test the incident
response program on a routine basis.
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 44 -
4.4 Category: Monitoring and improving the CSMS

The third main category of the CSMS is monitoring and improving the CSMS. It involves both
ensuring that the CSMS is being used, and reviewing the CSMS itself for effectiveness. Figure 6
depicts a graphical representation of the two elements in the category:
 Conformance
 Review, improve, and maintain the CSMS
Review, improve and

Conformance
maintain the CSMS
Figure 6 – Graphical view of category: Monitoring and improving the CSMS
4.4.2 Element: Conformance

Objective:
Ensure that the CSMS developed for an organization is followed.
Description:
Conformance with a CSMS means the organization is adhering to its stated policies, executing
the procedures at the correct time, and producing the appropriate reports to allow for future
review.
Rationale:
Regardless of the quality of a CSMS, if it is not used it does not add any value to the
organization and does not help reduce risk .
Requirements:
4.4.2.1 Specify the methodology of the audit The audit program shall specify the methodology of
process the audit process.
4.4.2.2 Conduct periodic IACS audits Validate that the IACS conforms to the CSMS. The
CSMS shall include periodic audits of the IACS to
validate that the security policies and procedures
are performing as intended and meet the security
objectives for the zone.
4.4.2.3 Establish conformance metrics The organization should define performance
indicators and success criteria to monitor
conformance to the CSMS. The results from each
periodic audit should be expressed in the form of
performance against these metrics to display
security performance and security trends.
4.4.2.4 Establish a document audit trail A list of documents and reports required to
establish an audit trail shall be developed.

--`,`,`,,`,,`,````

– 45 – ANSI/ISA–62443-2-1 (99.02.01)–2009
4.4.2.5 Define punitive measures for non- The organization shall state what non-conformance
conformance with the CSMS means, and any related punitive
measures shall also be defined.
4.4.2.6 Ensure auditors’ competence The required competency for auditing the specific
systems that are in scope should be specified. The
level of independence required should be
determined as part of the governance.
4.4.3 Element: Review, improve, and maintain the CSMS

Objective:
Ensure that the CSMS continues to meet its goals over time.
Description:
Reviewing, improving, and maintaining the CSMS establishes a continuing oversight of the
CSMS to check that it functions effectively and to manage required changes to the CSMS over
time.
Rationale:
Review and monitoring are required for the CSMS to remain effective, since the CSMS must
respond to changes in internal and external threats, vulnerabilities , and consequences, as well
as changes in risk tolerance, legal requirements, and evolving technical and non-technical
approaches to risk mitigation.
Requirements:
4.4.3.1 Assign an organization to manage An organization shall be assigned to manage and

and implement changes to the CSMS coordinate the refinement and implementation of
the CSMS changes and use a defined method in
making and implementing changes.
4.4.3.2 Evaluate the CSMS periodically The managing organization shall periodically
evaluate the overall CSMS to ensure the security
objectives are being met.
4.4.3.3 Establish triggers to evaluate CSMS The organization should establish a list of triggers
with set thresholds, which would result in a review
of related elements of the CSMS and perhaps a
change. These triggers include at a minimum:
occurrence of serious security incidents, legal and
regulatory changes, changes in risk, and major
changes to the IACS. The thresholds should be
based on the organization’s risk tolerance.
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
4.4.3.4 Identify and implement corrective The organization shall identify and implement
and preventive actions appropriate corrective and preventive actions that
modify the CSMS to meet security objectives.
4.4.3.5 Review risk tolerance A review of the organization’s tolerance for risk
should be initiated when there are major changes to
the organization, technology, business objectives,
internal business, and external events, including
identified threats and changes in social climate.

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 46 -
4.4.3.6 Monitor and evaluate industry CSMS Management system owners should monitor the
strategies industry for CSMS best practices for risk
assessment and risk mitigation and evaluate their
applicability.
4.4.3.7 Monitor and evaluate applicable The organization shall identify applicable and
legislation relevant to cyber security changing legislation relevant to cyber security.
4.4.3.8 Request and report employee Employee feedback on security suggestions should
feedback on security suggestions be actively sought and reported back to senior
management as appropriate on performance
shortcomings and opportunities.
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

– 47 – ANSI/ISA–62443-2-1 (99.02.01)–2009
Annex A
(informative)
Guidance for developing the elements of a CSMS

A.1 Overview
This annex provides informative guidance on how to develop a CSMS that meets the
requirements specified in Clause 4. The guidance presented here provides an overall
management system framework that allows organizations adopting the CSMS to tailor it to their
own specific needs. It should be thought of as a starting point or baseline for a cyber security
management system. Not all guidance may be applicable and depending on the application, the
organization may require more security than what is presented. The guidance is not meant to be
a step-by-step process.
The annex is organized with the same categories, element groups, and elements listed in Clause
4 as seen in Figure A.1. Each element in this annex uses the following organization:
 Description of element – a basic description of the topic.

 Element-specific information – one or more sections providing detailed guidance
regarding this element. Their structure and content is element-specific.
 Supporting practices
 Baseline practices – recommendations for organizations to achieve a baseline level
of cyber security. These practices become the building blocks of the requirements for
each element.
 Additional practices – innovative security practices used by some organizations to
further enhance cyber security.
 Resources used – sources for additional information as well as documents referenced .
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
ANSI/ISA-62443-2-1 (99.02.01)–2009 - 48 -
Risk analysis
assessment

Security policy, Selected security Implementation
organization and countermeasures
awareness
Risk
Personnel
CSMS scope management and
security
implementation
Physical and System

Organize for
environmental development and
security
security maintenance
Staff training and Information and

Network
security document
segmentation
awareness management
Access control:
Business Incident planning
Account
continuity plan and response
administration
Security policies Access control:

and procedures Authentication
Access control:
Authorization
Review, improve and

Conformance
maintain the CSMS
Figure A.1 – Graphical view of elements of a cyber security management system
A.2 Category: Risk analysis

A.2.1 Description of category
The first main category of the CSMS is risk analysis. This category discusses much of the
background information that feeds into many of the other elements in the CSMS. Figure A.2
shows the two elements that are part of the category:
 Business rationale
 Risk identification, classification, and assessment

--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

– 49 – ANSI/ISA–62443-2-1 (99.02.01)–2009
Risk Analysis
assessment
Figure A.2 – Graphical view of category: Risk analysis

A.2.2 Element: Business rationale
A.2.2.1 Description of element
This element establishes that the organization is aware of and understands the importance of
cyber security for information technology as used in IACS. This understanding is based upon an
understanding of the roles that information technology plays in the mission of the organization,
associated risks to this mission and the cost, and other business impacts of mitigating this risk .
A.2.2.2 Cyber security risk, business rationale, and business case

The first step to implementing a cyber security program for industrial automation and control
systems is to develop a compelling business rationale for the unique needs of the organization to
address cyber risk. An organization may derive the rationale for its IACS cyber security
management system and related individual projects from existing policies related to safety,
general risk management, or compliance with regulatory requirements. Other organizations may
require that the business rationale take the form of a formal or informal business case for cyber
security management activities in order to establish that the cost of mitigating cyber risk is
justified by its financial benefit. A business rationale or business case for taking the first steps to
build a CSMS will depend upon an assessment of risk, generally at a high level . Once risk is
acknowledged, an organization is ready to take appropriate steps to mitigate it . An effort to
perform more systematic and detailed risk assessment (as described l ater in this document), and
individual decisions about countermeasures , may themselves require a business rationale in the
form of a business case.
A business rationale captures the business concerns of senior management while being founded
in the experience of those already dealing with many of the same risks. This section deals with
the key components of the resulting business rationale and key resources to help you identify
those components. A business rationale may have as its scope the justification of a high-level or
detailed risk assessment, other specific aspects of a full cyber security management system as
described herein, or implementation of a single countermeasure.
Experience has shown that embarking on a cyber security program without an agreed business
rationale often results in eventual loss of program resources in favor of other business
requirements. Typically these other business requirements have a direct business benefit and
easily understood rationale.
A.2.2.3 Key components of business rationale

There are four key components of a business rationale: prioritized business consequences,
prioritized threats, estimated annual business impact, and cost of countermeasures.
a) Prioritized business consequences – The list of potential business consequences needs to

be distilled to the particular business consequences that senior management will find the
most compelling. For instance, a food and beverage company that does not handle toxic or
flammable materials, and typically processes its product at relatively low temperatures and
pressures, might not be concerned about equipment damage or environmental impact , but
might be more concerned about loss of production availability and degradation of product
quality. The insight here is based on histories of past incidents and knowledge of how

--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 50 -
industrial automation and control systems are actually used in the business , and the potential
business impact that unauthorized technical changes could cause. Regulatory compliance
might also be a concern.
b) Prioritized threats – The list of potential threats needs to be refined, if possible, to those
threats that are deemed credible. For instance, a f ood and beverage company might not find
terrorism a credible threat, but might be more concerned with viruses and worms and
disgruntled employees. The insight here is primarily based on histories of past incidents.
c) Estimated annual business impact – The highest priority items shown in the list of
prioritized business consequences should be scrutinized to obtain an estimate of the annual
business impact preferably, but not necessarily, in financial terms. For the food and beverage
company example, it may have experienced a virus incident within its internal network that
the information security organization resulting in a specific financial cost. Because the
internal network and the controls network are interconnected, it is conceivable that a virus
originating from the controls network could cause the same amount of business impact. The
insight here is primarily based on histories of past incidents. Regulatory compliance may
entail specific financial or business penalties for non-compliance.
d) Cost – The estimated cost of the human effort and technical countermeasures that this
business rationale intends to justify.
NOTE A business impact estimate in financial terms and cost estimates for countermeasures are required to create a
business case, but a successful business rationale may not always include this information.
There are a number of resources for information to help form this business rationale: external
resources in trade organizations and internal resources in related risk management programs or
engineering and operations.
External resources in trade organizations often provide useful tips about factors that most
strongly influenced their management to support their efforts and what resources within their
organizations proved most helpful. For different industries, these factors may be different but
there may be similarities in the roles that other risk management specialists can play.
Internal resources associated with related risk management efforts ( that is, information security,
HSE risk, physical security, and business continuity) can provide tremendous assistance based
on their experience with related incidents in the organization. This information is helpful from the
standpoint of prioritizing threats and estimating business impact. These resource s can also
provide insight into which managers are focused on dealing with which risks and, thus, which
managers might prove the most appropriate or receptive to serving as a champion.
Internal resources associated with control systems engineering and oper ations can provide
insight into the details of how control systems are actually used within the organization. How are
networks typically segregated? How are high-risk combustion systems or safety-instrumented
systems typically designed? What security count ermeasures are already commonly used?
Keeping in mind the organization’s history with mergers and acquisitions, it’s also important to
understand how representative any particular site might be of the entire business unit, region , or
overall organization.
Remember that in the early stages of the industrial operation, the primary focus will be on
identifying one or two high-priority issues that justify continued effort. As the IACS cyber security
program develops further, other items may appear on the list a nd priorities may shift, as the
organization applies a more rigorous risk analysis methodology. However, these changes should
not detract from the result of this original effort to justify initiating the program.
A.2.2.4 Content suggestions for IACS business rationale

Within each organization, the journey to develop an effective cyber security program for IACS
starts with individuals who recognize the risks the organization is taking and begin to articulate

--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

– 51 – ANSI/ISA–62443-2-1 (99.02.01)–2009
these risks internally, not just in technical terms, but i n business terms that resonate with upper
management. A business rationale is not a detailed risk assessment; it is rather a high level
description of risks sufficient to justify the next planned steps in building a CSMS. It may be as
brief or detailed as required to support the decision processes in the particular organization.
The negative business consequences of cyber attacks against IACS can include the following:
 Reduction or loss of production at one site or multiple sites simultaneously

 Injury or death of employees
 Injury or death of persons in the community
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
 Damage to equipment
 Environmental damage
 Violation of regulatory requirements
 Product contamination
 Criminal or civil legal liabilities
 Loss of proprietary or confidential information
 Loss of brand image or customer confidence
 Economic loss
In prioritizing the risk of these consequences occurring , it is also important to consider the
potential source or threat that initiates a cyber attack , and the likelihood that such an event
would occur. Cyber threats could arise from sources inside or outside an organization; threats
could be the result of either intentional or unintentional actions; and threats could either be
directed at a specific target or undirected. Cyber security incidents can result fro m many different
types of threat agents such as the following:
 Thrill-seeking, hobbyist, or alienated individuals who gain a sense of power, control, self -
importance, and pleasure through successful penetration of computer systems either via
undirected attacks (viruses and worms), or directed attacks (hacking) to steal or destroy
information or disrupt an organization’s activities.
 Disgruntled employees or contractors who damage systems or steal information for
revenge or profit.
 Well-intentioned employees who inadvertently make changes to the wrong controller or
operating equipment.
 Employees who break quality, safety, or security policies or procedures to meet other
urgent needs (for example, production goals).
 Terrorists typically motivated by political b eliefs for which cyber attacks offer the potential
for low-cost, low-risk, but high-gain attacks especially when linked with coordinated
physical attacks.
 Professional thieves (including organized crime) who steal information for sale.
 Adversary nations or groups who use the Internet as a military weapon for cyber warfare
to disrupt the command, control, and communication capabilities of a foe.
Documented cases provide insight into how and how often one of these threat agents succeeds
in inflicting negative business consequences. The rapid adoption of new network technologies
has led to the development of new tools to enable cyber attacks. With the lack of a recognized
publicly accessible incident reporting system, it will be extremely difficult in the near future to
determine a quantitative likelihood of any specific type of event occurring. Likelihood will need to

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 52 -
be evaluated qualitatively based on an organization’s own internal incident history and on the
few cases that have been publicly documented. Several of these cases are described in the
following bullets:
 In January 2003, the SQL Slammer Worm rapidly spread from one computer to another
across the Internet and within private networks. It penetrated a computer network at
Ohio’s Davis-Besse nuclear power plant and disabled a monitoring system for nearly five
hours, despite a belief by plant personnel that the network was protected by a firewall. It
occurred due to an unprotected interconnection between plant and corporate networks.
The SQL Slammer Worm downed one utility’s critical SCADA network after moving from a
corporate network to the control center local area network (LAN). Another utility lost its
Frame Relay Network used for communications , and some petrochemical plants lost
human-machine interfaces (HMIs) and data historians. A 911 call center was taken offline,
airline flights were delayed and canceled, and bank ATMs were disabled.
 Over several months in 2001, a series of cyber attacks were conducted on a
computerized waste water treatment system by a disgruntled contractor in Queensland,
Australia. One of these attacks caused the diversion of millions of gallons of raw sewage
into a local river and park. There were 46 intrusions before the perpetrator was arrested.
 In September 2001, a teenager allegedly hacked into a computer server at the Port of
Houston to target a female chat room user following an argument. It was claimed that the
teenager intended to take the woman’s computer offline by bombarding it with a huge
amount of useless data, and he needed to use a number of other servers to be able to do
so. The attack bombarded scheduling computer systems at the world’s eighth largest port
with thousands of electronic messages. The port’s web service, which contained crucial
data for shipping pilots, mooring companies, and support firms responsible for helping
ships navigate in and out of the harbor, was left inaccessible.
 The CERT organization has been monitoring and tracking the number of attacks occurring
on Internet-connected systems since 1988. None of the reported incidents were for
control systems. As of 2004, they have stopped tracking the number of attacks, because
the prevalence of automated attack tools has led to attacks becoming so commonplace
that the number of incidents reported provides little information with regard to assessing
the scope and impact of attacks. A graph of their incident data is shown in Figure A.3 to
demonstrate the dramatic increase that has occurred over the last 15 years.

--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

– 53 – ANSI/ISA–62443-2-1 (99.02.01)–2009
140
Number Reported to CERT (Thousands)

120
In 2004, CERT stopped reporting data

100
since attacks were too frequent.
80
60
40
20
88 989 990 991 992 993 994 995 996 997 998 999 000 001 002 003 004
19 1 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2
Year
Figure A.3 – Reported attacks on computer systems through 2004 (source: CERT)
A.2.2.5 Supporting practices
A.2.2.5.1 Baseline practices
a) Identifying and documenting the business objectives, critical business processes , and critical
information technology processes. Include industrial automation and control systems and
interfaces with value chain partners where sensitive information is transferred, stored, or
processed.
b) Identifying the dependence of the business on information technology systems. Categorize
the business dependence low, medium, high, or an alternate ranking system.
c) Identifying various damage scenarios by the loss of confidentiality, integrity or availability of
information. Include the manipulation of IACS and the consequences of such actions for
those businesses which use these systems. Include HSE and operational integrity and
reliability for drivers of industrial automation and control systems. Capture risks associated
with value chain, and other third-party business partners. These risks often include the loss
or alteration of sensitive information. An example is the interception of information associated
with manufacturing products shipments, including types of materials, quantities, shipping
routes, mode of transportation, and the like.
d) Developing business impact analyses for IACS security.
e) Developing business impact analyses for value chain or other third -party business partner.
f) Determining the organization’s risk tolerance profile defined in terms of:
1) Safety of personnel (serious injury or fatality)
2) Financial loss or impact including provisions in the Sarbanes-Oxley Act
3) Environmental/regulatory consequence
4) Damage to company image
5) Impact to investment community
6) Loss of customer base or confidence
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 54 -
7) Impact on infrastructure
NOTE Risk tolerance varies depending on the business. Simply put, the organization’s risk tolerance is its threshold
of pain. The risk tolerance may be very low (for example, a single serious injury may not be acceptable and must be
addressed immediately) when it comes to safety in plant manufacturing or may be very high ( for example, in terms of
production loss) if the organization has multiple production sites of a commodity product. The financial impact for one
business may not be appropriate for othe r businesses. Organizations with multiple businesses should look at the
interdependencies of one business upon another when determining risk tolerance.
IT security managers will typically be familiar with the organization’s risk tolerance profile for
some, but not all of these consequences. Other managers who are responsible for managing the
risks associated with HSE consequences will be familiar with the organization’s risk tolerance
profile in these areas. The overall risk tolerance profile needs to be de termined by integrating
information from these sources as well as those from the IACS environment.
A.2.2.5.2 Additional practices

a) Identifying and documenting the business objectives, critical business processes, and critical
IT processes. This process is best performed with a cross section of the organization
representing the functional areas, as well as the business units of the company. This group is
chartered by a senior executive typically responsible for the IT organization or a leadership
team that includes other senior executives from throughout the organization. This charter
specifically includes the risk associated with industrial automation and control systems.
b) Developing a business impact analyses that describes the issues and consequences of
inaction and benefits of action. Where practical, these actions are quantified in terms of
financial impacts (that is, lost sales or fines), market impacts (that is, loss of confidence or
public image), as well as HSE impacts (that is, environmental release, equipment damage
and loss of life). Especially when considering consequences like public image, it is important
to understand that an incident due to one particular business unit can affect the organization
as a whole.
c) Documenting and approving (by the appropriate le vel of management) the risks outside the
scope of the CSMS.
A.2.2.6 Resources used
 ISO/IEC 27001, Clauses 0.2 and 4.2 [15]
 ChemITC Guidance for Cyber Security [17]
 ChemITC Report on CSVA [18]
 U.S. Chemical Sector Cyber Security Strategy [21]
 Sarbanes-Oxley Act [33]
A.2.3 Element: Risk identification, classification, and assessment
Organizations protect their ability to perform their mission by systematically identifying,
prioritizing, and analyzing potential security threats, vulnerabilities, and consequences using
accepted methodologies. Risk is formally defined as an expectation of loss expressed as the
probability that a particular threat will exploit a particular vulnerability with a particular
consequence (see ANSI/ISA–99.01.01–2007). As described under the related element risk
management and implementation (see A.3.4.2), an organization defines its risk tolerance in
terms of the characteristics of threats, vulnerabilities , and potential consequences it identifies.
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
The organization then implements this risk tolerance decision by taking action where indicated to
reduce the likelihood of a security threat occurring by mitigating vulnerabilities and/or reducing
the consequences in case the security threat is realized.

– 55 – ANSI/ISA–62443-2-1 (99.02.01)–2009
A.2.3.2 Cyber risk for IACS

The risk management approach outlined in A.2.2 applies in general for all types of cyber risk as
well as other types of risks. Here we discuss the unique aspects of the analysis of cyber risk for
IACS.
Although various industries may find certain types of business impact of more concern, and may
feel that certain types of threats are more likely, all industries that use IACS should be
concerned that they are entering a new risk environment. At the same time that industrial
automation and control systems have adopted commercial IT operating systems and network
technologies, and users have interconnected their private networks with their IACS networks, the
number of threats has also increased greatly. There are risks associated with traditional
information (electronic or paper), classical IT systems and applications, industrial automation
and control systems, business partners, joint ventures, outsourcing partners, and the like.
Risks for traditional IT assets focus on the confidentiality, integrity, and availa bility of
information. Risks in industrial automation and control systems are different as the drivers focus
more on HSE factors and operational reliability in addition to the traditional protection of
information confidentiality, integrity, and availability. In IACS the priorities are generally reversed
with focus on availability, integrity, and confidentiality, in that order. This means that cyber risk
assessment for IACS should be coordinated with physical security and HSE, wherever practical.
Some organizations fully integrate risk assessment efforts related to all of these areas. Risks
using outsourcing, third-party contractors, or other partners in the manufacturing value chain
include sensitive information transmitted, stored, or processed. The integration of these business
partners into an organization’s operations potentially permits unintentional access into the
company’s systems.
In virtually all of these cases, the security-related industrial operations and technologies
developed for classical IT applications have not been deployed for IACS partly due to ignorance,
but partly due to valid constraints that don’t exist in classical IT applications. The objective of this
standard is to address both issues.
A.2.3.3 Risk assessment process

An overview of risk is required to establish the business rationale for a cyber security
management system. The more detailed priorities addressed by this system are determined
based upon a methodology that systematically considers risk at a greater level of granularity
than typically assessed to establish an initial business rationale.
A.2.3.3.1 Risk assessment and vulnerability assessment

In the general literature, the terms vulnerability assessment and risk assessment are sometimes
used interchangeably. We distinguish these two kinds of analyses in accordance with the
definitions of vulnerability and risk in this standard. Recall that a vulnerability is defined as a flaw
or weakness in a system's design, implementation, or operation and management that could be
exploited to violate the system's integrity or security policy (see ANSI/ISA–99.01.01–2007). As
an example, the observation that passwords in a control center are seldom changed is an
example of a vulnerability that would be identified in a vulnerability assessment. There may be
several risks associated with this vulnerability, for example:
 A low likelihood that the password becomes well known in the plant over time and that a
legitimate employee not trained for control system operations uses the password while
pitching in to solve a problem and causes a loss of production for several hours due to
input errors.

--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 56 -
 A low likelihood that a disgruntled former employee successfully breaks though corporate
firewall defenses to access the control system network remotely, logs in to an HMI a nd
deliberately takes actions that can cause a loss of production for several days.
Thus as these terms are used in this standard, risk assessment has as its output a set of risks
and a vulnerability assessment has as its output a set of vulnerabilities, w hich have not yet been
analyzed in terms of the risks they create. In this way, a vulnerability assessment is an input to a
risk assessment. Note some existing methodologies titled vulnerability assessment methods
include risk concepts and others do not.
Returning to the above example of the control room password, it is clear that there are also risks
involved in changing the control system password periodically – for example a low likelihood that
an operator may not remember a new password in an emergency situation and is unable to login
to resolve the situation, resulting in serious collateral environmental damage. The tradeoff
between the risk addressed by a countermeasure and the risk introduced by a countermeasure
such as in this case, is discussed under the Risk Management and Implementation element of
this standard (see A.3.4.2).
A.2.3.3.2 High-level and detailed risk assessment

Risk assessment can be carried out at several levels. This standard requires risk assessment at
two levels of detail, called high-level risk assessment and detailed risk assessment .
High-level risk assessment examines what might be the impact of general types of cyber security
vulnerabilities and the likelihood that a threat might exercise these vulnerabilitie s, but does not
consider particular instances of these vulnerabilities or related countermeasures already in
place. Thus examples of risks identified in a high-level risk assessment might be:
 A medium likelihood that a malware infestation occurs and causes control network
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
congestion, and thus, a lack of visibility to the status of the industrial process in the
control room resulting in potential emergency shutdown and resulting costs .
 A low likelihood that a contractor with criminal connections and with physical access to
the control system network media taps this media and successfully modifies control
commands in a way that causes damage to the facility.
High-level assessment is required because experience has shown that if organizations start out
by looking at detailed vulnerabilities, they miss the big picture of cyber risk and find it difficult to
determine where to focus their cyber security efforts. Examination of risks at a high level can
help to focus effort in detailed vulnerability assessment s. The high-level assessment can
typically cover all control networks owned by an organization, possibly by dividing them into
groups that share common characteristics. Resources may not be available to cover all IACS at
the detailed level.
A detailed risk assessment, as defined for this standard, is supported by a detailed vulnerability
assessment that includes examining details such as existing technical countermeasures,
adherence to account management procedures, patch and open port status by individual host o n
a specific control system network, and network connectivity characteristics such as firewall
separation and configuration. Thus, an example output from a detailed risk assessment might be:
 Direct connection of process engineering workstations to both the corporate network and
the control system network in the South facility, bypassing the control network internal
firewall, contribute to risk of malware infection on the control network. In combination with
lack of antivirus protection on 50% of the hosts o n the South facility control network, this
results in a medium likelihood of a virus-triggered network congestion incident causing a
lack of visibility to the status of the industrial operation in the control room, and resulting
in potential emergency shutdown and resulting costs.

– 57 – ANSI/ISA–62443-2-1 (99.02.01)–2009
 All control system network media (for example, addresses 192.168.3.x) and connections
to other networks are either physically protected by walls, ceilings or floors, or in locked
rooms accessible to three authorized control system network administrators. Therefore
the risk of a successful attempt at tapping this media is low.
These detailed risk assessment results support related results from a high-level assessment per
the related examples above. However, the detailed risk assessm ent may in many cases
determine that risks are lower or higher than suspected in the high-level assessment. The
detailed risk assessment may also uncover risks not considered in the high-level assessment.
Finally, since the detailed assessment identifies s pecific vulnerabilities, it provides direction for
how an organization might address risks deemed unacceptable.
A.2.3.3.3 Types of risk assessment methodologies

There are a variety of risk assessment methods that have been developed and marketed by
different organizations. In general, these can be classified according to two factors: how they
characterize the individual risks (qualitatively versus quantitatively) and how they structure the
risk identification exercise (scenario-based versus asset-based).
Qualitative versus quantitative

Qualitative risk assessment typically relies on the input of experienced employees and/or experts
to provide information regarding likelihood and severity of specific threats impacting specific
assets. In addition, different levels of likelihood and severity are identified by general classes
such as high, medium, and low rather than specific probabilities or economic impacts. Qualitative
risk assessment is preferred when there is a lack of reliable information regarding the likelihood
of specific threats affecting specific assets, or estimating the overall impact of damage to specific
assets.
Quantitative risk assessment typically relies on extensive data sets that document the rate at
which damage occurs to assets based on exposure to de fined combinations of threats and
vulnerabilities. If this information is available, it can provide more precise risk estimates than
qualitative risk assessment methods. Due to the recent exposure of IACS to cyber security
threats, the relative infrequency at which incidents occur and the rapidly evolving nature of the
threats, extensive data sets do not yet exist to aid in the assessment of cyber security threats to
IACS. At this stage, qualitative risk assessment is the preferred method for evaluating the se
risks.
Scenario-based versus asset-based

In conducting a risk assessment, it is usually helpful to focus the participant’s thoughts along one
of two lines: the scenarios by which threats take advantage of vulnerabilities to impact assets or
the assets themselves. The scenario-based approach tends to take advantage of experience with
actual incidents or near-incidents. However, the approach may not penetrate to discover threats
or vulnerabilities to sensitive assets that have not been previously threatene d. The asset-based
approach tends to take advantage of knowledge of an organization’s systems and work methods
and particular assets whose compromise would lead to high economic impact. However, this
approach may not penetrate to discover types of threats or vulnerabilities that would place these
assets in jeopardy, or scenarios that involve more than one asset. Whichever general approach
is used, it is recommended that some aspect of the other approach be included to provide a
more thorough risk assessment.
As an example that integrates scenario and asset -based methods, consider an organization that
has identified assets as devices, applications, and data. In the next step, the organization lists
possible scenarios related to these assets and determines con sequences as follows. Application
scenarios are very similar to the device scenarios shown.
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 58 -
a) Device scenarios
1) Scenario: Unauthorized user locally accessing an IACS device
What is the consequence of someone walking up to the device and performing the tasks
allowed at this device?
2) Scenario: Remote access of an IACS device by an unauthorized user
What is the consequence of an unauthorized user gaining remote access to this device
and performing any of the tasks allowed by this device?
3) Scenario: IACS device disabled or destroyed
What is the consequence of a cyber incident that blocks the device from performing all or
a subset of its normal functions?
b) Data scenarios
1) Scenario: IACS data theft
What is the consequence of someone stealing this data set?
 Does the data set have high intellectual property value?
 Is the data set of business value to a competitor?
 If publicly released, would the data set be an embarrassment to the organization?
 Is the data set required for regulatory compliance?
 Is the data set under a litigation hold order?
2) Scenario: IACS data corruption
What is the potential consequence if:
 The data set were intercepted and changed between the source and destination?
 The data set were corrupted at the source?
 Is the data set required for regulatory compliance?
 Is the data set under a litigation hold order?
3) Scenario: IACS data denial of service
What is the consequence if the user of the data was not able to access the IACS data
set?
NOTE A group might carry out scenario based risk assessment by starting from descriptions of incident scenarios and
then determining consequences of the scenario, as shown in this example or start by creating a list of undesirable
consequences first, and then work backwards to develop possible incident scenarios that might creat e these
consequences. A combination of these approaches may also be used.
A.2.3.3.4 Select the risk assessment methodology
Selecting the right risk assessment methodology for your organization is very subjective, based
upon a number of issues. Many of these methodol ogies are commercially available. Some of
these are available at no charge, while others require a license for use. Assessing these
methodologies to find the one most useable for your organization can be a challenging task.
Common to most methodologies is the premise that risk is a combination of the likelihood of an
event occurring and consequences of that event.
The complication is how you assign quantitative numbers to likelihood , which is typically
expressed as a probability. Industry experience with process safety and accidents has a large
amount of historical quantitative measures on which to base probability values. But, identifying
the appropriate numbers for the probability of a specific cyber incident happening is not easy, not
only because of a lack of historical data, but also because the past may not resemble the future

--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

– 59 – ANSI/ISA–62443-2-1 (99.02.01)–2009
once a vulnerability becomes known. Because of this complication, many companies and trade
associations have chosen to develop their own methodology to address the threat and
vulnerability concerns of specific importance to their company in a manner consistent with their
corporate culture. Also for this reason, in this standard we have used the term likelihood instead
of the more formal term probability.
Some methodologies support high-level risk assessment well. Some support detailed risk
assessment well by allowing input of vulnerability assessment results , and they may also directly
provide guidance for the associated detailed vulnerability assessment. An organization will find i t
effective to use a methodology that coherently supports both high-level and detailed risk
assessment.
NOTE An example of a trade association helping with the task of selecting the right methodology, the American
Chemistry Council’s Chemical Information Technology Center (ChemITC) has published a document titled, “Report on
Cyber Security Vulnerability Assessment Methodologies Version 2.0.” [18] This document examines various elements
of eleven different methodologies and com pares them to a set of criteria important in a general -purpose cyber security
risk methodology for assessing business IT systems, industrial automation and control systems , and value chain
systems. The report offers some sound advice for selecting a method ology. A portion of the guidance is included in the
following with permission from CSCSP.
Step 1 – Filter
The first step is to review the overview of the selected methodologies. The purpose of
this step is to filter the methodologies of interest based on c riteria such as ease of use,
complexity, scope, resource requirements and type of methodology. ( [18] – Appendix IV,
“Summary Primary Decision Criteria for Selecting a Cybersecurity Methodology”)
Step 2 – Select
After identifying the methodologies, select the methodologies that might fit your
company’s needs. ([18] – Attachment II, “CSVA Technical Criteria”) Attachment II
identifies the particular criteria that were used to assess the methodology. The criteria
listed there address a much larger IT space beyond IACS. You may find you are looking
for a methodology to address only a subset of the criteria used in the ChemITC study.
Understanding the difference between your company needs and the evaluation criteria
will be helpful as you review the synopses for the different methodologies. Then review
the corresponding synopses to obtain more detailed information for assistance in making
an informed methodology choice. ([18] – Appendix V, “Evaluation Synopses”)
The synopsis for each methodology addresses the following topics:
 Cyber security vulnerability assessment methodology

 Reviewers
 Date
 Web address
 General observations
 Strengths compared to the common evaluation criteria
 Gaps compared to the common evaluation criteria
 How this methodology could be used
 Limitations on methodology use
 Suggested revisions
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 60 -
Step 3 – Validate (optional)

If there is any uncertainty or difficulty choosing the methodology, review the technical
criteria spreadsheets shown in the reference document for the methodology to validate
your choice(s). ([18] – Attachment II, “CSVA Technical Criteria”) The technical criteria
spreadsheet exists for each methodology. This step is optio nal because it simply provides
even more specific evaluation data.
Step 4 – Acquire the selected methodology

After narrowing down the methodology selection to one, obtain the methodology from the
provider. The web addresses supplied in the bibliography are a good starting point.
A.2.3.3.5 High-level risk assessment

A.2.3.3.5.1 Identify risks
Once a set of key stakeholders has been identified and provided with some training regarding
the nature of IACS, they will perform a high-level risk assessment following the organization’s
selected methodology. This assessment process clarifies the nature of the individual risks to the
organization that arise from the use of IACS. This clarity is needed to ultimately select the most
cost-effective countermeasures to be designed or deployed an d to help justify the costs of their
deployment. While this task is the first step of a risk assessment, it is NOT a detailed
vulnerability or threat assessment. It typically involves a risk analysis session to gather input
from all stakeholders and takes advantage of high-level business consequences that may have
been identified in the business rationale.
The deliverable document from the risk analysis session is a list of scenarios that describe how a
particular threat could take advantage of a particular type of vulnerability and damage particular
assets resulting in identified negative business consequence. The same session may also
address calibration of consequence level and prioritization by risk tolerance level.
Stakeholders, who have experience with IACS applications in the business units and those
responsible for the management of related risks, need to participate in the risk assessment effort
to leverage their expertise and experience.
In order to make the most efficient use of participant’s time, it is normally necessary to schedule
somewhere between a half and a full day to conduct the risk analysis session with all the
stakeholder participants in attendance. There are two phases of this risk analysis session:
background information and risk identification.
Regardless of which risk assessment method is ultimately used, it is also important to provide
the participants in the risk analysis session with appropriate background information before
beginning to identify the risks. Typical background info rmation includes an overview of the
business rationale and charter, an overview of IACS architectures and functions and an overview
of specific types of incidents that occurred within the organization or publicized incidents that
occurred in other organizations.
For the session to be successful, it is also important that participants understand the working
definitions for risks and vulnerabilities; otherwise, the session is likely to identify vulnerabilities
but may not succeed in identifying risks. Examples are useful for this purpose. Thus, as an
example, vulnerability might be weak authentication on the control system HMI . The related
threat might be that an employee with insufficient experience is able to operate the HMI without
supervision and sets unsafe parameters. The consequence might be a stoppage of production
due to safety controls being exercised. It is a common pitfall that an organization will list cyber
vulnerabilities and then proceed to mitigate them.
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`

– 61 – ANSI/ISA–62443-2-1 (99.02.01)–2009
A.2.3.3.5.2 Classify risks

The list of scenarios produced as an output of the risk analysis session describes a number of
different risks posed to organizations by threats to industrial automation and control systems.
One of the duties of corporate management is to manage all the risks to their organization s. To
facilitate this effort, risks need to be identified and prioritized. This section describes the steps
required to develop a framework to prioritize individual risks so the appropriate corrective actions
can be justified.
The risk equation

Before describing the framework for risk prioritization and calibration, it’s important to understand
a basic concept of risk analysis (for example, the risk equation).
The likelihood of an event occurring takes into account both the likelihood that a threat that cou ld
cause an action will be realized and the likelihood that a vulnerability that allows the action will in
fact be exploited by the threat. For example, for a virus to cripple a network, it needs to first
reach the network and then needs to defeat antiviru s controls on the network. If likelihood is
expressed as a probability, then we have:
(Eq. A.1) Likelihood Event_Occurring = Likelihood Threat_Realized × Likelihood Vulnerability_Exploited
As discussed above, risk is made up of both likelihood and consequence, where con sequence is
the negative impact the organization experiences due to the specific harm to the organization’s
asset(s) by the specific threat or vulnerability.
(Eq. A.2) Risk = Likelihood Event_Occurring × Consequence
Calibrating likelihood and consequence scales

Risk management systems have been developed within most organizations to deal with a wide
variety of risks. In some cases the use of such systems has been mandated by regulatory
requirements. These risk management systems make use of the same risk equation to p rioritize
the risks to the organization by the same type of threats to different assets ( for example,
information security), or by different threats to the same assets (that is, business continuity,
industrial operation safety, environmental safety, and physical security). In most organizations,
these risk management systems will already have developed scales for likelihood and
consequence.
A typical likelihood scale is shown in Table A.1. This scale is only an example; the organization
will need to determine the actual values used in this scale for themselves.
Table A.1 – Typical likelihood scale

Likelihood
Category Description
High A threat/vulnerability whose occurrence is likely in the next year.
Medium A threat/vulnerability whose occurrence is likely in the next 10 years.
A threat/vulnerability for which there is no history of occurrence and for which the
Low
likelihood of occurrence is deemed unlikely.
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
Most organizations find it difficult to agree on likelihood, and little information is currently
available to help. It is clear that differing opinions about this factor can radically change the
investments made by the CSMS. Even though all may not agree with the final assessment on

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 62 -
likelihood, the benefit of using it is that the assumptions being used to drive CSMS investment
are clear for all to see. Since likelihood is the major factor of risk about which an organization
has the least information and control, it is important to track improvements in industry data
available to help make this factor more accurate.
To address the issue of lack of agreement, some organizations use the following methods:
 Use a probability of 1 for likelihood and thus consider only consequences, or do this for
certain types of consequences such as HSE
 Agree on a range of probabilities or likelihood categories and then work their prioritization
process based on ranges
 Attempt more precision by consulting industry data that is available on attacks to IACS
 Attempt more precision by collecting internal incident data
 Separate likelihood into two factors – the likelihood that an adversary will attempt an
attack and the likelihood that they will succeed. Separating these factors can help to
clarify the real source of disagreement. If it can be agreed by all that an attempt will
succeed, and the argument for low risk relies on hoping no attempt happens, that can
change the tenor of the discussion.
Consequence is usually measured in different terms for different types of risks. A typi cal
consequence scale is shown in Table A.2. This example illustrates how cyber risk assessment
can take process safety and other organizational risks into account. As above, this scale is only
an example and will need to be calibrated for the organization.
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

– 63 – ANSI/ISA–62443-2-1 (99.02.01)–2009
Table A.2 – Typical consequence scale
Consequence
Risk area
Business continuity planning Information security Industrial operation Environmental National
safety safety impact
Category Manufacturing Manufacturing Cost Legal Public People – People – Environment Infrastructure
outage at one outage at (million confidence on-site off-site and services
site multiple sites USD)
A > 7 days > 1 day > 500 Felony Loss of Fatality Fatality or Citation by Impacts multiple
(high) criminal brand image major regional or business
offense community national agency sectors or
incident or long-term disrupts
significant community
damage over services in a
large area major way
B > 2 days > 1 hour >5 Misdemeanor Loss of Loss of Complaints Citation by local Potential to
(medium) criminal customer workday or or local agency impact a
offense confidence major community business sector
injury impact at a level
beyond that of a
single company.
Potential to
impact services
of a community
C < 1 day < 1 hour <5 None None First aid or No Small, contained Little to no
(low) recordable complaints release below impact to
injury reportable limits business
sectors beyond
the individual
company. Little
to no impact on
community
services

--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 64 -
It is important to follow a high level of intellectual honesty when assessing the consequence.
During the assessment, identify assumptions that impact the level of consequence. For example,
one might reasonably assume all the safety interlocks and s hutdown systems are in place to
minimize the impact of an event, since the likelihood of a cyber event in conjunction with an
unrelated accident that disables safety systems is very small. However, in making this
assumption, one must also consider whether there is a risk of an intentional cyber attack taking
advantage of an accidental malfunction of safety systems or a coordinated physical or cyber
attack causing such a malfunction. Other possible assumptions that may be called out are that
operating practices are being followed to the extent typical of normal operation and fundamental
lockout procedures are being followed. It is important for sites to honestly assess the risk,
keeping in mind the sophistication and state of the control system and related op erations and the
dependency upon that system to operate the facility.
Calibrating consequences is necessarily performed with respect to the interests and policies of
the organization performing the risk assessment. Although the risk of the IACS may be very
much impacted by the hazards associated with the industrial operations being controlled by the
IACS, it is important to not confuse the risk to the organization with the risk to society . The
industrial operations may not employ any hazardous materials but produce a very valuable in-
demand product generating high revenues for the company. An IACS security incident resulting
in an industrial operations upset, causing several days of off-specification product that cannot be
sold, could have very high financial impact to the company. To this company, the IACS has a
High-risk level even though society may view this as a low-risk because there is no health, safety
or environmental impact to the general public. Likewise, the same organization might also
consider an industrial operations upset on a production facility using hazardous materials as a
high-risk consequence even if it did not impact production, due to internal policies and/or
external regulations concerning public safety.
Prior to convening a group to calibrate individual risks, clarify the likelihood and consequence
scales to provide guidance to the team performing the risk assessment.
Risk level
The output of a qualitative risk assessment will consist of a list of assets or scenarios with an
overall risk level ranking. This is typically developing in a matrix similar to the one shown in
Table A.3, which defines three risk levels based upon three levels of likelihood and
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
consequence. Thus each risk identified in the risk assessm ent is assigned a risk level. Again,
this is meant as an example and will require further review by the organization.
Table A.3 – Typical risk level matrix

Consequence category
A B C
High High-risk High-risk Medium-risk
Likelihood Medium High-risk Medium-risk Low-risk
Low Medium-risk Low-risk Low-risk
The risk levels in each block (High, Medium, and Low) correspond to a particular combination of
likelihood and consequence. An organization will define a risk tolerance policy related to each
risk level, which will correspond to a particular level of corporate response. The actual approach
to resolve the risk may be through the use of identified countermeasures . An initial version of this
matrix should be prepared by responsible corporate management before the risk analysis
process. This is the recommended method to insure that the risk assessment effort provides
results that directly assist in decision making and are actionable by the organization.

– 65 – ANSI/ISA–62443-2-1 (99.02.01)–2009
See A.3.4.2 for further information about defining a risk tolerance policy and how the risk
tolerance policy and risk assessment results are used to manage risks.
A.2.3.3.6 Detailed risk assessment

A.2.3.3.6.1 General
A detailed risk assessment focuses on individual IACS network s and devices, and takes into
account a detailed technical vulnerability assessment of these assets and the effectiveness of
existing countermeasures. It may not be practical for all organizations to perform detailed risk
assessment for all their IACS assets at once – in this case an organization will gather enough
information about their IACS to allow them to prioritize these systems to determine those to be
analyzed first by the detailed vulnerability and risk assessment effort.
A detailed risk assessment identifies risks and then prioritizes them. Risks should be identified
for each IACS. After identifying the risks, an organization may choose to prioritize all the risks
found across all of these systems, prioritize the risks individually for each system, or prioritize
risks found in subsets of the IACS studied, such as all IACS at a specific site. Since prioritization
ultimately drives decisions on what actions will be taken and investments made to improve cyber
security, the scope of the prioritization should align with the scope of the budget and the decision
authority in place in the organization to make these investments. For example, if all IACS
supporting a specific product line are managed and budgeted as a group, risks across those
IACS would be prioritized together to support that manager’s decision process.
A.2.3.3.6.2 Characterize key IACS

Identifying and prioritizing IACS risks requires that an organization locate and identify key
industrial automation and control systems and devices, and the characteristics of these systems
that drive risk. Without an inventory of the IACS devices and networks, it is difficult to assess
and prioritize where security measures are required and where they will have the most impact.
The team must meet with IACS personnel to identify the different IACS used throughout the site
and that control remote sites. The focus should be on systems rather than just devices including
but not limited to, control systems, measurement systems and monitoring systems that use a
central HMI device. Include industrial operations areas, as well as utility areas such as
powerhouses and waste-treatment facilities.
As was noted above, the objective is to identify the major devices and kinds of devices that are
in use and function collectively to operate the equipment under control. At this point in
developing the security program, it is not important to develop a comprehensive inventory of
every device in the IACS because the inventory will be used to make judgmental decisions about
the relative risk the control devices introduce to the industrial operation. As examples, it is
important to understand:
 Whether the field instrumentation and communication from the field transmitter to the
controllers is analog-based or digital-based.
 Whether devices/systems are connected to each other and the types of networks used.
 Whether the devices are located within a secured area such as a building or fenced
facility, or whether the devices are located remotely.
 Whether the control devices are subject to regulatory cont rol.
 Whether the loss or malfunction of the device/system is significant in terms of their impact
on the equipment under control, both in business/financial and HSE terms.
The resulting identification of devices /systems should show the scope of impact on the
equipment under control if the devices lose control of the industrial operations they are applied
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 66 -
to and their relative security vulnerability (from physical, network, or other factors). This kind of
information can be used to understand the relative risk to the industrial operation. Conducting a
comprehensive inventory to identify exact quantities of each kind of device is not necessary at
this stage.
A.2.3.3.6.3 Group the devices and systems and develop an inventory

As the team identifies the individual devices/systems, it may be helpful to put the items into a
logical grouping of equipment. In modern IACS facilities, this collection of equipment functions as
an integrated system to control the various activities of the industrial operation. The number of
logical control systems in a company will vary widely. In a medium to large organization, there
may be several hundred logical IACS comprised of thousands of individual devices and low -level
systems.
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

– 67 – ANSI/ISA–62443-2-1 (99.02.01)–2009
Industrial automation and control system network characterization
Business
Site
Operating unit
Site IT contact Phone #
Site process control contact Phone #
Last updated
PLEASE ANSWER THE FOLLOWING QUESTIONS :

Are manufacturing and control systems currently interfaced to site or corporate LANs?
Are manufacturing and control systems remotely accessed from outside the IACS domain?
Process control domain

Total number of IP addressable nodes
Number of IP addressable nodes to be accessed from outside process control domain
Number of concurrent users inside IACS domain
Number of concurrent users inside IACS domain requiring access to external resources
Number of total users outside IACS domain requiring access to process control resources
Number of concurrent users outside IACS domain requiring access to process control resources
IP addressing (check all that apply)
DHCP Public addresses used (i.e. x.x.x.x)
Static Private addresses used (192.168.x.x)
Control platforms
Number of control platforms
Control platform type (PLC, DCS, PC)
Control platform vendor(s)
Control platform model(s)
Operator consoles and HMI devices

Number of operator consoles
Operator console vendor(s)
Operator console model(s)
Operator console operating system(s)
Application nodes (check all that apply)

Proccess management and control server
SCADA
OPC server
Engineering workstation
Batch server
Other
Network security barriers in-use

Type (firewalls, routers, VLANS, etc.)
Anticipated network security support (check all that apply)

Site resources
External (3rd party)
Site network (answer yes / no)

Current site network topology diagrams available and up-to-date?
Are process control nodes on isolated LAN segment?
Site information security policy in place?
Security office audit completed (if yes, date completed _________ )
Does site use two-factor authentication?
Security office risk assessment completed (if yes, date completed ________ )
Remote access requirements (check all that apply)

Via site / corporate LAN
Via dial-up modem
Via internet
Via local dial-up modem directly tied to manufacturing and control node(s)
Local egress requirements (check all that apply)

To site applications and resources (document management systems, quality systems, business systems)
To corporate applications and resources (document management systems, quality systems, business systems)
To internet sites

--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 68 -
Figure A.4 – Sample logical IACS data collection sheet

For medium to large organizations addressing cyber security on a company-wide basis, it may be
helpful to record the list of logical systems in a searchable database. DCS may be organized by
line, unit, cell, or vehicle within local or remote geographical site. SCADA systems may be
organized by control center, remote site, and associated control equipment. The database will be
more effective if the data are collected in a standard format to facilitate comparison of one
system to another. Figure A.4 is an example of a standard format that can be easily created in
the form of a spreadsheet or database. It has been included to spur thinking about the kind of
information that may be of use later in the system prioritization and detailed risk assessment
activities.
Care should be taken when identifying industrial automation control devices/systems , and focus
attention beyond the devices that perform direct control. The system or network may be mor e
than the PLC or DCS. In an integrated manufacturing or production facility, the IACS network is
comprised of devices that are directly used to manufacture, inspect, manage , and ship product
and may include, in addition to others, the following components:
 DCSs and associated devices

 SCADA systems and associated devices
 PLCs and associated devices
 HMI stations
 Safety Instrumented Systems (SIS)
 Shop floor (special purpose) computers
 Process information management (PIM) systems and manufacturing execution sy stems
(MES)
 Industrial automation control modeling systems
 Expert systems
 Inspection systems
 Material handling and tracking systems
 Analyzers
 Gauging systems
 Batch systems
 Electrical power monitoring and/or management systems
 Remote telemetry systems
 Communication systems used for communication with remote devices
 Standard operating condition (SOC) and standard operating procedure (SOP) systems
 Document management systems
 Program development computers
 HVAC control systems
 Network communication gateways (that is, switches, hubs and routers)
 Network protection devices (that is, firewalls and intrusion detection systems)

--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

– 69 – ANSI/ISA–62443-2-1 (99.02.01)–2009
Consider including all CPU-based networked devices that are critical to sustaining production.
The objective of this inventory step is to discover devices that are vulnerable to network -based
attacks so they can be included in the detailed risk assessment.
NOTE This time is not the decision point for deciding which devices should be isolated or separated from the LAN.
Err on the side of including more devices rather than fewer. After perform ing the risk assessment and having a better
understanding of the overall vulnerabilities, the assessment team should decide if risk mitigation solutions are truly
necessary and where the various devices should be located.
There are several enterprise-wide inventory tools commercially available that will work across
networks to identify and document all hardware, systems , and software resident on the network.
Care must be taken before using this type of application to identify IACS. Conduct an
assessment of how these tools work and what impact they might have on the connected control
equipment before using any of them.
Tool evaluation may include testing in similar, off -line, non-production control system
environments to ensure the tool does not adversely affect the operation of the control system
and interrupt production. While non-production devices may have no impact on production
systems, they may send information that could (and has in the past) caused co ntrol systems
failures or impairment. Impact could be due to the nature of the information and/or the system
traffic and loading. Although this impact may be acceptable in IT systems, it is not acceptable in
industrial automation and control systems.
A.2.3.3.6.4 Develop simple network diagrams

A simple network diagram will be beneficial in grouping the various industrial automation and
control devices and systems into an identifiable logical control system. It should include the
devices identified with the Logical IACS Data Collection Sheet discussed in A.2.3.3.6.2. The
diagram should attempt to capture the basic logical network architecture, such as connectivity
approaches, combined with some of the physical network architecture basics like location of
devices.
Before conducting prioritization of IACS or a detailed risk assessment, it is important that the
team has a clear understanding of the scope/boundaries of the system to be assessed. A
network diagram is a tool to help visualize the network and aid in performing the risk
assessment. It can be a very simple block diagram showing devices, systems, and interface
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
connections, or more detailed like the one shown in Figure A.5. Either approach will be beneficial
to meeting the objectives. If zones and conduits have been established, simple network diagrams
should depict these elements. (More explanation on developing zones and conduits can be found
in Annex A.3.3.4.)

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 70 -
Figure A.5 – Example of a graphically rich logical network diagram

Simple network diagrams are a starting point and represent a snapshot at one point in time.
Experience in detailed vulnerability assessment shows that virtually every assessment turns up
connections not identified in the initial diagramming process. Therefore , these diagrams should
not form the sole basis for assessing connectivity without more detailed physical validation. They
are valuable for scoping the risk assessment effort and fo r defining zones and conduits as
described in ANSI/ISA–99.01.01–2007.
A.2.3.3.6.5 Preliminary assessment of overall risk for each identified system

Once the list of IACS devices, assets, and networks has been completed, a preliminary
assessment needs to be made as to the relative level of risk associated with the systems , so
they can be prioritized for detailed risk assessment. If a detailed risk assessment is to be carried
out on all IACS or if the high-level risk assessment has provided sufficient insight to prioriti ze
individual IACS by risk, then this step will not be required.
Each individual system must be assessed to understand the financial and HSE consequences as
identified in the high-level risk assessment, in the event that the availability, integrity, or
confidentiality of the system is compromised. Also, some measure of scale needs to be assigned
to the assessment.
The screening assessment activity must be conducted by the personnel familiar with the IACS.
The IACS and IT personnel typically bring knowledge of the devices and systems in use, while
the operations personnel typically bring an understanding of the consequences of a security
incident. This team of resources must work together to accomplish the screening assessment.

--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

– 71 – ANSI/ISA–62443-2-1 (99.02.01)–2009
The team will develop a high-level scale to quantitatively rate the overall risk associated with
each system. The scale could be as simple as high, medium, and low, or 1 to 10 and must
establish the criteria for each gradation on the risk scale.
The team will make a judgment decision on the level of risk associated with each system by
examining the financial and HSE consequences in the event that the availability, integrity, or
confidentiality of the system is compromised. The team should record the high-level risk
assessment for the logical system in the inventory list developed earlier. Establishing risk
tolerance levels helps to prioritize the actual assets in the IACS environment.
The results of this preliminary assessment will be an important input to the decision to perform
detailed vulnerability assessment for a particular IACS. Plan to conduct a full vulnerability
assessment if you:
 Determine the IACS is presently connected to the corporate network or to outside

networks (for example, Internet, modems). A detailed risk assessment will help you better
understand the vulnerabilities and the appropriate mitigation strategy to reduce risk.
 Determine the system is currently supported remotely.
 Anticipate meeting either of the two criteria above in the near future. Perform the
vulnerability assessment before taking steps that place you into this high-risk position.
A.2.3.3.6.6 Prioritize the systems
The previous section suggested assigning a vulnerability/risk rating to each logical IACS
identified. This rating scale is a good place to start the prior itization process. However, there are
several additional things to consider when deciding where to begin to focus detailed risk
assessment efforts.
 Risk to the company (for example, HSE or financial)

 Places where assessment process is likely to be most successful
 Cost of the potential countermeasures required
 Capital versus non-capital costs
 Skilled support staff available for the particular system
 Geographic region
 Member trade association directives or sensitivities
 Country or local political requirements
 Outsourced or in-house support staff
 Site support to undertake the effort
 History of known cyber security problems
There is no right or wrong approach. The values will be different for each company. What is
important is to use the same prioritization principles across all the sites. Record the prioritization
decisions made and the basis for making them.
A.2.3.3.6.7 Identify vulnerabilities and prioritize risks

The next step in the risk assessment process is actually conducting the detailed risk assessment
on the prioritized systems. Most methodologies employ an approach to break the system down
into smaller pieces and examine the risks associated with these smaller elements comprising the
overall system.

--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 72 -
A detailed risk assessment should address physical and cyber security threats, internal and
external threats, and consider hardware, software, and information as sources for vulnerabilities.
It is imperative that a team of people performs the assessment to bring a well rounded
perspective to the assessment. The team should be comprised of, at a minimum, a lead site
operations person, site IACS person, site IT person, and site network person. Others to be
considered include experts in physical security, information system security, legal, business
(operations, maintenance, engineering, and the like), human resources, HSE, and hardware
vendors. These people are in the best position to recognize vulnerabilities and the consequence
of risk for their specific areas.
Although the goal is to understand the threats and consequences associated with a particular
system, it is quite likely that a key objective is to be able to compare the assessment results from
one system/site to another across the organization. The ability to do this will depend on how
consistently the methodology is applied. Some proven approaches include:
 Using a key person to lead the assessment process at each site

 Using a small team of people to lead the assessments based upon geography, business
unit, and the like, who have participated with each other in other assessments
 Using good training materials with procedure and exercises to level -set the team of
individuals who will conduct the assessments at each site
 Using a common form or database to record assessment results
 Centrally reviewing all the assessment results to check if the results seem realistic and
comparable to other similar systems.
When conducting the assessment, consider all aspects of the IACS, including unintended
changes in system configuration brought about by maintenance, temporary supplier connections
to the system for support, and even subtle changes in supplier design that could introduce new
vulnerabilities through spare parts or upgrades, which should be considered and/or tested in the
same manner as the original system components.
The assessment needs to address systems that interface with the IACS as well to ensure that
they cannot compromise the IACS security or vice versa. Examples include development
systems that provide online development capabilities and environmental and power sys tems
whose compromise could create unacceptable risks.
In some cases, the vulnerability may lie with the vendor. Vendor quality assurance and design
control may require a vulnerability assessment. This step is particularly important when ordering
spare parts or upgrades.
At this point in the assessment process, a detailed examination of the network from a physical
and operational viewpoint should be carried out in order to uncover any connections not shown
in the initial simple network diagrams. Many assessments will find such connections.
The following potential sources for vulnerabilities rela ted to network connectivity have been
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
previously identified as weaknesses in certain systems and should be identified and examined:
 Wireless access points, particularly poorly secured technologies such as early versions of
IEEE 802.11
 Modem connections, particularly those that do not dial back and do not provide encryption
 Remote access software (for example, pcAnywhere® and Timbuktu®) programs that are
typically used for access by experts within or outside the entity to support systems or

– 73 – ANSI/ISA–62443-2-1 (99.02.01)–2009
operations. These applications can provide significant control and configuration access to
an unauthorized individual.
 Remote windowing technologies such as X Windows®
 Intranet connections
 Internet connections
 Telemetry networks
 Any network connection to systems that are not a direct part of the IACS
 Any network connections used to couple parts of the SCADA or control system together
that are not part of a physically secure, dedicated IACS network. In other words, any
network that extends beyond the boundary of a single security zone or across insecure
zones or is used for both IACS and other functions at the same time. Equipment included
in network connections includes radio telemetry and outsourced services such as frame
relay used to communicate between geographically separated areas.
A number of industry resources cover control system security and provide lists of typical
vulnerabilities to look for in a detailed vulnerability assess ment. (See references in the
Bibliography.)
The team’s ultimate output is a list of vulnerabilities prioritized by their impact on risk. After
vulnerabilities have been identified, the team then associates these vulnerabilities with threats,
consequences, and associated likelihoods for realization of the threat and exercise of the
vulnerability. This analysis takes into account potential mitigation due to physical security
measures. Those vulnerabilities that contribute to the highest level risks are typica lly easy to
agree upon. To complete the vulnerability assessment process, the team’s methodology should
include an agreed method to determine how to prioritize vulnerabilities that contribute to a large
number of medium and low-level risks.
Detailed risk assessment results should be documented and action taken on recommendations
resulting from them. (See Annex A.3.4.2)
Documentation of the detailed vulnerabilities found during the detailed risk assessment typically
includes for each vulnerability found, the date of assessment, identification of assets involved,
description of the vulnerability, name of an individual who observed the vulnerability, and any
tools or methods they used in order to do so. In addition to vulnerabilitie s found, the
documentation of the detailed vulnerability assessment should include vulnerabilities checked for
but not found to be present and how this was verified for each asset assessed. This may take the
form of a simple checklist. Documentation of vulnerabilities provides great leverage when
updating the risk assessment, and when specific questions about assets are raised. Prior
vulnerability checklists and results form a baseline from which to improve vulnerability
assessments in the future, and a basis for consistency across an organization. An organization
should view them in this light and avoid viewing them as a static definition of the contents of
such an assessment.
Tasks and documentation related to the high-level and detailed risk assessment pr ocesses
described in this section, and the risk management process in Annex A.3.4.2, can be integrated
for efficiency to suit the needs of a particular organization.
The detailed risk assessment results should be updated and revalidated on a periodic basis. In
addition, since a detailed risk assessment can become out of date due to changes in the
environment of a control system, triggers for an updated risk assessment effort should be
incorporated into the management of change program. This is a critical point, since most
organizations find it easier to establish a cyber security baseline than to maintain it over time.
(See Annex A.4.3)

--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 74 -
A.2.3.3.6.8 Pitfalls to avoid

During the assessment, look for common pitfalls that can derail the risk assessment process.
Designing the solution during the assessment

The purpose of the assessment is to learn what risks exist, not to design the solution as a
team. A lot of time can be wasted by trying to solve the problem and deba ting one
approach versus another while assessing one particular asset. Focus on understanding
the risks and consequences that currently exist or may occur in the foreseeable future,
such as a project currently underway to add a new model device with a netw ork interface.
Minimizing or overstating the consequence

Provide an honest assessment of the consequence of an incident affecting a particular
hardware, software, or information asset. If you don’t want to take any action, don’t
minimize the consequence to avoid taking proper security risk mitigation actions to
reduce the risk. What may be very important to one particular person because it directly
impacts his or her job, may have a very different level of consequence to the organization
as a whole.
Failing to gain consensus on the risk assessment results

Reaching agreement on the risks and consequences is extremely important. It will be
much harder to reach agreement on the countermeasures if the team does not have a
common understanding of the risk and agreement on the importance.
Assessing the system without considering the assessment results from other
similar systems
It is important to validate that the results are appropriate and consistent with those of
similar assessment processes at other sites. The conclusions from previous similar
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
system assessments and the vulnerabilities identified can be very beneficial to the
assessment of the system at hand.
A.2.3.3.6.9 Interrelationship with physical security measures

Cyber security and physical security may be closely re lated. In some situations they may function
as independent layers of protection and in other situations they are highly dependent upon each
other. The loss of one may represent a loss of both layers of protection. During the detailed risk
assessment for a system, keep in mind the potential interaction and how it may affect the
consequences.
In some industries, it is common practice to have a SIS in addition to the industrial automation
control system. If the SIS is relay based, the likelihood of it being af fected by a cyber event that
impacts the IACS is small. The SIS can be counted upon to perform its safety function and the
consequence of a cyber event may be contained and reduced. However, if the SIS is
electronically based and tied to the same network as the IACS (some industries do not
recommend this practice), the likelihood of a cyber incident impacting both systems is much
higher and the consequence could be greater.
Another example might be a badge access system to a locked control room. Under norma l
situations, the access control system provides additional security to the control systems.
However, in the event of a denial of service (DoS) flood of the network, the door access control
system could fail to function and impede the operator’s ability to gain access to the control room
operator console. The same DoS network overload could be affecting the operator console as
well. In this situation, the single cyber incident serves as a double impediment to responding to
the control device and could increase the consequence of the incident.

– 75 – ANSI/ISA–62443-2-1 (99.02.01)–2009
Eventually, cyber security risk assessment methodologies should be incorporated into physical
and site risk assessment methodologies.
A.2.3.3.6.10 Risk assessment and the IACS lifecycle

The previous sections describe how the process of risk assessment can be carried out on
existing IACS when first establishing a CSMS and periodically thereafter. Risk assessment is
most effective and least disruptive when applied in a similar fashion during the lifecycle of the
IACS before it is running in production mode.
During development of a new or updated IACS

Cyber risk should be considered in advance before implementing a new or modified
IACS, since experience has shown it will always be easier and less expensive to consider
security during the design phase than to add it later. The process for high-level risk
assessment proceeds in the same way for a future system as described above for an
existing system. The assessment is ideally performed in parallel with high-level design
and the results of the proposed design and risk assessment are reviewed together. A
detailed risk assessment can also be carried out in parallel with detailed design, though
vulnerabilities identified are hypothetical and will not in all cases be as specific as for an
already implemented system. In this way, risk assessment during development can drive
decisions about what countermeasures should be put in place along with the desired
IACS improvements, to minimize surprises after implementation.
During implementation of a new or updated IACS

Even with attention to risk during the development phase, implementation details may
introduce unexpected vulnerabilities. In the best case, part of the acceptance process for
a new or updated IACS includes not only testing, but also a detailed vulnerability analysis
as previously described. Thus, for example, an organization may need to determine
whether to turn on a new or updated system before a patch to a recently discovered
vulnerability is available for the underlying operating syste m.
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
During retirement of an IACS
The decision to retire or retain an IACS, or components of an IACS, is based upon many
factors including cost, desire for new functionality or capacity, ongoing reliability , and
availability of vendor support. Impact on cybe r security is also a factor to be weighed in
this decision. New components and architectures may improve security functionality
and/or introduce new vulnerabilities that need to be addressed. Hence a cyber risk
assessment that analyzes a retirement decisio n examines both the scenario in which the
old system is replaced and the scenario in which the old system is retained for some
period of time.
High-level and detail risk assessments are updated upon the retirement of an IACS for
two reasons: 1) the removal of the IACS may impact the vulnerability of some IACS that
remain in place, and 2) if the IACS is replaced by a new system, new vulnerabilities may
be introduced as discussed earlier. An example of this is that network connectivity to an
IACS that remains in place may have always taken place through the IACS being
removed. This means that a new connectivity design is put in place for the remaining
IACS and this configuration should be assessed for vulnerabilities and associated risks.

a) Establishing the criteria for identifying which devices comprise the IACS.

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 76 -
b) Identifying devices that support critical business processes and IACS operations including
the IT systems that support these business processes and IACS operations.
c) Classifying the logical assets and components based on availability, integrity, and
confidentiality, as well as HSE impact.
d) Prioritizing risk assessment activities based on consequence ( for example, industrial
operations with known high hazards are addressed with a high priority).
e) Scoping the boundaries of the system to be assessed, identifying all assets and critical
components.
f) Developing a network diagram of the IACS. (See Annex A.2.3.3.6.4)
g) Understanding that risks, risk tolerance and acceptability of countermeasures may vary by
geographic region or business organization.
h) Maintaining an up-to-date record of all devices comprising the IACS for future assessments.
i) Conducting a risk assessment through all stages of the technology lifecycle (development,
implementation, updating, and retirement).
j) Identifying reassessment frequency or triggering criteria based on technology, organization ,
or industrial operation changes.
a) Identifying and classifying assets to aid in defining the company’s risk. Important focus areas
should be people involved and technologies used. The creation of a checklist helps group the
assets into categories. (See Annex A.2.3.3.6.3)
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
b) Classifying individual assets based on the safety implications of availability, integrity, and
confidentiality. An asset could have different levels of classification for each of the
categories. The following is an example of classification for a specific type of data:
 Availability: low, the system is not required 24x7x52 on line. The system is not part of a
hazardous operation. A delay of up to one or two days would be acceptable.
 Integrity: medium, the data is verified at various stages and changes t o it would be
detected.
 Confidentiality: very high, the business critical data should be maintained at the highest
confidential level.
c) Establishing the likelihood (that is, probability or estimated frequency) that a particular threat
will be successful, in view of the current level of controls. It is important to look at other
typical controls that may be in place in manufacturing/operations that would supplement
cyber security controls to reduce the likelihood of the consequence occurring. These include
independent SIS and other PSM techniques such as passive, auxiliary, independent back -up
devices. The estimated frequency is directly related to the overall vulnerability and threats
and could be expressed quantitatively as a percentage or more subjectively as high, medium
or low.
d) Defining the consequences or impact of a successful threat attempt based on the business or
IACS risk evaluation.
 ISO/IEC 27001, Clauses 0.2, 4.2 and Annex B [15]
 ChemITC reference model [19]

– 77 – ANSI/ISA–62443-2-1 (99.02.01)–2009
 ChemITC Report on Self-assessment [20]

 U.S. Chemical Sector Cyber Security Strategy, Section 4.5.3 [21]
 NIST SP 800-30, Section 3 [24]
 Sarbanes-Oxley [33]
A.3 Category: Addressing risk with the CSMS

The second main category of the CSMS is Addressing Risk with the CSMS. This category
contains the bulk of the requirements and information contained in the CSMS. It is divided into
three element groups:
 Security policy, organization and awareness

 Selected security countermeasures
 Implementation
A.3.2 Element group: Security policy, organization, and awareness
A.3.2.1 Description of element group
The first element group in this category discusses the development of the basic cyber security
policies, the organizations responsible for cyber security, and the awareness within the
organization of cyber security issues. Figure A.6 shows a graphical representation of the five
elements contained in the element group:
 CSMS scope
 Organizing for security
 Staff training and security awareness
 Business continuity plan
 Security policies and procedures
Security policy, organization and awareness
Staff training and

Organize for Business
CSMS scope security
security continuity plan
awareness
Security policies
and procedures
Figure A.6 – Graphical view of element group: Security policy, organization, and
awareness

--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 78 -
A.3.2.2 Element: CSMS scope

A.3.2.2.1 Description of the element
With the business rationale established and management support obtained, the next step is to
develop a formal scope or charter for the effort. This scope shou ld explain what is to be
accomplished (in business terms) and when. It defines the specific entity of focus.
This scope statement should be owned by a senior executive program champion or management
team who will be responsible for guiding the team during program development. The champion
will ultimately be responsible for making sure that the program is executed, including
communications, funding, enforcement, and auditing.
Ultimately, the CSMS must encompass all business units and all geographic sections of the
organization. If leadership commitment cannot be obtained initially for this scope of work, define
a smaller scope of work and use this as an opportunity to build credibility and demonstrate the
value of the CSMS.
A.3.2.2.2 Developing the CSMS scope

Management needs to understand the boundaries where the CSMS apply to the organization as
well as establish a direction and focus for the CSMS. By developing a clearly defined scope, it is
easier for management to convey its goals and purpose for the CSMS.
The scope should include all aspects of the IACS, integration points with business partners,
customers and suppliers. A management framework ( for example, organization) should be
established to initiate and control the implementation and ongoing operations of cybe r security
within the company.
An organization responsible for determining and communicating corporate policies as they relate
to cyber security is important to protect corporate assets from a cyber security perspective.
Companies need to recognize that in today’s Internet-driven business world, electronic
information connectivity is an integral part of doing business and thus cyber security is essential.
Business transactions are not only contained within the organization’s Internet firewall, but are
extended to customers, vendors, third-party contractors, and outsourcing partners.
The overall scope of work needs to be clarified from three different perspectives: business,
architectural. and functional.
From a business perspective the scope of work needs to answer questions similar to:
 Which corporations are included?

--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
 Which business units are included?

 Which geographical regions are included?
 Which specific sites are included?
From an architectural standpoint, the scope of work needs to answer questions similar to:
 Which computer systems and networks will be addressed?

 Will SCADA and distribution monitoring systems be included?
 Will non production-related computer systems (both those supported and unsupported by
the IT organization) in manufacturing be included?
 Will manufacturing execution systems (MES) be included?
 Will burner management systems and SIS be included?

– 79 – ANSI/ISA–62443-2-1 (99.02.01)–2009
 Will robotic systems be included?

 Will connections to suppliers or customers be included?
From the functional standpoint, the scope of work can be divided into two categories:
Direct risk management activities

These are activities that involve the evaluation, communication , and prioritization of risk.
Examples include designation of local cyber security owners, collecting and maintaining
an asset inventory, developing and maintaining the network architecture, completing
internal or external audits, and reporting these results on a business unit or corporate
basis.
Risk management related projects
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
These are activities funded on the basis of reducing the risks identified by the risk
management activities. These indirect risk management solutions take the form of
projects that are bounded in time and the development and deployment of ongoing
services.
In clarifying the functional scope consider questions similar to:
 How does the scope of this work relate to existing risk management systems?
 How does the scope of this work relate to information security policies that already apply
to these systems and organizations?
 How does the scope of this work relate to technical standards and procedures that
already apply to specific architectural components ( that is, basic process control systems,
SCADA systems, SIS, burner management systems, and robotic systems)?
 How does the scope of this work relate to projects that are already funded?
 How does the scope of this work relate to existing services?
Leadership support provides the endorsement of the effort by managers who are responsible for
assigning resources to manage and implement the tasks to reduce risks to the IACS.
The scope should be owned by a senior executive program champion who will be responsible for
guiding the team during program development. The champion will ultimately be responsible for
making sure that the program is executed, including communicati ons, funding, enforcement and
auditing.
With support and commitment from senior leadership, identify the stakeholders and secure their
time to work on improving security. The stakeholders are responsible for moving the security
initiative forward. With support from senior leadership the stakeholders initiate the next activities
and engage the right resources to accomplish the tasks. Form an integrated team that involves
traditional desktop and business computing systems, IACS and systems that interact with
customers, suppliers and transportation providers. The charter and scope mentioned earlier
bring focus on who needs to be involved to meet the objectives of the initiative.
It is likely that senior leadership may identify a project leader whose job it is t o round up the right
people to work on the security effort. This person must have a high level understanding of the
current state of cyber security procedures in the company. Assuming that the goal is to improve
the cyber security policies and procedures for IACS, the project leader should look for the areas
that could be affected by IACS cyber security incidents and identify the key people that are
recognized as responsible/accountable for these areas. The focus should be on identifying
people in the right role, independent of the organization to which they are assigned .

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 80 -
It is important to note that different company organizational structures may have these people in
different organizations. The goal is to develop a cost-effective CSMS that leverages existing
business processes and organizations rather than create a whole new organization. Look for
people in the right role and with the right experience. Breaking down turf issues may be an
important activity of this stakeholder team .
The core team of stakeholders should be cross-functional in nature and bring together skills not
typically found in any single person. The team should include people with the following roles:
 IACS person(s) who may be implementing and supporting the IACS devices
 Operations person(s) responsible for making the product and meeting customer orders
 Process safety management person(s) whose job it is to ensure that no HSE incidents
occur
 IT person(s) who may be responsible for network design and operation, support of
desktops and servers, and the like.
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
 Security person(s) associated with physical and IT security at the site

 Additional resources who may be in the legal, human resources and customer
support/order fulfillment roles
The set of stakeholders may change over time or specific ind ividuals may take on higher-profile
roles during different phases or activities while developing the CSMS. It is not important which
organization leads the effort, but rather that the leader exhibits the right set of behaviors that
foster working together as a team with a unified purpose. The parent organizations to which the
above individuals are aligned each have something to offer and have a stake in decisions and
outcome of the CSMS.
A.3.2.2.3 Suggested practices

A.3.2.2.3.1 Baseline practices
a) Describing the organization(s) responsible for establishing, communicating, and monitoring
cyber security within the company.
b) Stating the scope of the CSMS, including:
 Information systems – including all operating systems, databases, applications, joint
ventures, and third-party business activities
 Industrial automation and control systems – including all process control systems, SCADA
systems, PLCs, DCSs, configuration workstations , and plant or lab information systems
for both real-time and historical data
 Networks, local area networks (LANs), wide area networks (WANs) – including hardware,
applications, firewalls, intrusion detection systems , and the like.
 Integration points with support and service providers
 User responsibilities – including policies to address authentication and auditability
 Information protection – including access requirements and individual accountability
 Risk management – including processes to identify and mitigate risks and document
residual risk
 Disaster recovery – including identification of critical software/services
 Training requirements
 Conformance, compliance, and audit

– 81 – ANSI/ISA–62443-2-1 (99.02.01)–2009
 Asset identification.
c) Characterizing the organization responsible for the CSMS, including:
 Organization structure
 Location
 Budget
 Roles and responsibilities associated with the CSMS processes.
A.3.2.2.3.2 Additional practices
a) Having management endorse the scope and responsibilities of the CSMS
b) Having a clear understanding of the roles and responsibilities associated with the
organization(s) responsible for some aspect of the CSMS
c) Documenting the scope of the CSMS with separate sections addressing specific components
d) Addressing business, legal (for example, Data Privacy), and regulatory requirements and
responsibilities
e) Identifying and documenting the dependency of process safety on cyber security and physical
security practices and procedures including a framework for organizational interaction.
A.3.2.2.4 Resources used
 Sub-clause 0 and Annex A.3.2.3 Organizing for security
 ISO/IEC 27001, Clause 4 and Annex A [15]
A.3.2.3 Element: Organizing for security
A.3.2.3.1 Description of element
Companies should establish an organization, structure, or netwo rk of people with responsibility
for overall security recognizing there are physical as well as cyber components that should be
addressed.
It is important to establish accountability to provide direction and oversight to a n organization’s

cyber security. Cyber security in the broadest sense covers not only data, but also the systems
(hardware and software) that generate or store this information and includes elements of
physical security as well. IACS, value-chain partners, third-party contractors, joint venture
partners, outsourcing partners, and physical security specialists should be considered by the
organization as part of the overall security structure and hence included in the scope of
responsibility.
A.3.2.3.2 Building an organizational framework for security

The commitment to a security program begins at the top. Senior management must demonstrate
a clear commitment to cyber security. Cyber security is a business responsibility shared by all
members of the enterprise and especially by leading members of the bu siness, manufacturing, IT
and risk management teams. Cyber security programs with visible, top -level support and buy-in
from organization leaders are more likely to gain conformance, function more effectively and
have earlier success.
A management framework should be established to initiate and control the implementation of an

overall security program. The scope and responsibilities of cyber security for organizations
should include physical security and cyber security for IT systems, IACS suppliers, third party
contractors, outsourcing partners and the value-chain components of the organization. An overall
security program should be extended to include joint venture operations.
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 82 -
Organizations should establish a framework with management leadership to approve the cyber
security policy, assign security roles and coordinate the implementation of cyber security across
the organization. The framework may face some interesting organizational challenges . Many
companies are organized in a three-dimensional matrix where one dimension is by business line,
a second dimension is by function or discipline and a third dimension is by geographical region.
Individual managers typically have responsibilities for some subsection of this overall
organization. Because a system is only as secure as its weakest link, a cyber security system
will ultimately need to be developed that spans the entire geographical reach of the organization.
Cyber security deals with a number of different risks that can generally be classified into
concerns about availability, integrity or confidentiality. Concerns about availability would typically
be managed by a business continuity planning program or network security program. Concerns
about integrity in a manufacturing context are typically managed b y a process safety or quality
assurance program. Concerns about confidentiality are typically managed by an information
security program. Because cyber security affects so many different risk areas, it is likely that no
one single manager will have the nec essary scope of responsibility to authorize a cyber security
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
program for all IACS. It will often be necessary to convene and convince a small group of senior
managers who, quite possibly, have never had to work closely together before to make a
consensual decision.
Either an overall enterprise (for example, a corporation) or individual sub-organizations within the
enterprise may work toward conformance with this standard. If the overall enterprise is to
conform, risk is assessed across the total enterprise. In this case, for example, individual plants
within the corporation may carry out risk assessments, but will use a common risk assessment
methodology that allows compilation of these assessments at the corporate level. Thus if an
overall enterprise has a goal to achieve conformance, it will find it necessary to set guidelines to
support this, even if individual sub-organizations such as plants do much of the work.
Other possibilities are that the overall enterprise is not attempting to meet the standard, b ut is
requesting its sub-organizations at some level to do so individually or that some
sub-organizations are attempting to meet the standard on their own initiative. In either of these
cases the enterprise will still need to support these sub -organizations in meeting any specific
requirements in the standard that are handled at the enterprise level, such as securing
corporately provided architectures, employee screening and wording of contracts with service
suppliers. Under these scenarios, for example, an individual plant site could have its own risk
assessment methodology, determine its own mitigation priorities and have plant level senior
management supporting the effort. And in these cases the enterprise is not evaluating its own
overall conformance with the standard, although it potentially might evaluate conformance of
individual plants. This strategy would make the most sense for a highly decentralized diverse
corporation or other enterprise.
A.3.2.3.3 Getting started and gaining support

For senior managers to effectively champion a cyber security program they must be convinced
that the costs of the program they will pay out of their budgets will be less than the impact of the
threat on their areas of responsibility. It may be necessary to develop a business rat ionale or a
business case for managing cyber security risks to convince leadership to support the program .
Budgetary responsibilities and scopes of responsibility will need to be clarified amongst the
senior leadership.
Due to the constraints of time, many senior managers have trusted advisers they use to filter the
important issues they need to address from the issues that others are more suited to address.
These individuals are gatekeepers. In large organizations, there are frequently staff
organizations that senior managers use to generate recommendations for technically complex
issues. It may be necessary to work with these staff organizations initially to collect sufficient

– 83 – ANSI/ISA–62443-2-1 (99.02.01)–2009
information to make the business case. These organizations may also be able to p rovide insight
into which senior managers typically handle specific types o f risks.
It is likely that senior leadership may identify a project leader whose job it is to round up the right
people to work on the security effort. This person must have a high level understanding of the
current state of cyber security procedures in the company. It is important to recognize that a truly
integrated cyber security management system involves traditional desktop and business
computing systems, industrial automation and control systems and value chain systems that
interact with customers, suppliers and transportation providers. The charter and scope
mentioned earlier bring focus on who needs to be involved to meet the objectives of the initiative.
The project leader should look for the areas that could be affected by IACS cyber security
incidents and identify the key people that are recognized as responsible/accountable for these
areas. The focus should be on identifying people in the right role, independent of the
organization to which they are assigned.
It is important to note that different company organizational structures may have these people in
different organizations. The goal is to develop a cost -effective cyber security management
system that leverage existing business processes and organizations rather than create a whole
new organization. Look for people in the right role and with the right experience. Breaking down
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
turf issues may be an important activity of this stakeholder team.
The core team of stakeholders should be cross-functional in nature and bring together skills not
typically found in any single person. The team should include people with the following roles:
 IACS person(s) who may be implementing and supporting the IACS devices
 Operations person(s) responsible for making the product and meeting customer orders
 Process safety management person(s) whose job it is to ensure that no health, safety ,
and environmental incidents occur
 IT person(s) who may be responsible for network design and operation, sup port of
desktops and servers, and the like.
 Security person(s) associated with physical and IT security at the site
 Additional resources who may be in the legal, human resources , and customer
support/order fulfillment roles
The set of stakeholders may change over time or specific individuals may take on higher profile
roles during different phases or activities in the life of developing the CSMS. It is not important
which company organization leads the effort, but rather that the leader exhibits the right set of
behaviors that foster working together as a team with a unified purpose. The parent
organizations to which the above individuals are aligned each have something to offer and have
a stake in decisions and outcome of the cyber security management syst em.
One common practice to convince senior manager is to test new programs in a small geographic
region or at a particular site to prove that new procedures/programs work prior to devoting a
large amount of resources. This can be another effective approach to either get access to senior
managers or actually make the business case to senior managers.
Once the appropriate senior managers have been identified, it’s important to decide whether to
present the CSMS to them all as a group or to approach them seque ntially. It’s more efficient to
convince them all simultaneously, but they may not all be receptive to the discussion
simultaneously. If you need to persuade a leadership team, it’s helpful to identify an ally on the
leadership team to review the presentation and offer input before making the presentation to the

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 84 -
whole team. Due to the number of different risk areas that are affected by cyber security, it is not
uncommon to require persuasion of more than one leadership team.
If the costs of the cyber security program cannot be determined initially due to lack of a computer
inventory or lack of standard countermeasures, a second round of presentations may be required
once these costs are determined more precisely. The emphasis at this early stage needs to be
on putting a system in place to balance the costs of the countermeasures with the costs of the
risks. Usually there is inadequate information at this stage to request a specific budget for
implementing countermeasures.
A.3.2.3.4 Supporting practices

a) Obtaining executive management commitment for setting up an organizational framework to
address security.
b) Assigning responsibility for cyber and physical security to personnel with an appropriate level
of funding to implement security policies.
c) Initiating a company-wide security team (or organization) to provide clear direction,
commitment, and oversight. The team can be an informal network, organizational or
hierarchical structure spanning different company departments or organizations. This team
assigns responsibilities and confirms that business processes are in place to protect
company assets and information.
d) Establishing or modifying contracts to address cyber and physical security policies and
procedures of business partners, third-party contractors, outsourcing partners, and the like.
where the security policies and procedures of those external partners affect the security of
the IACS.
e) Coordinating or integrating the physical security organization where an overlap and/or
synergy between physical and cyber security risks.
a) Establishing the responsibility for IACS cyber security.
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
 A single individual from any of several functions is responsible for cyber security for the
entire organization. This individual chairs a cross -functional team representing the various
business units and functional departments . The team demonstrates a commitment to
cyber security and sets a clear direction for the organization. This includes asset and
industrial operation ownership as well as providing the appropriate resources for
addressing security issues.
 A separate team is responsible for the security of IACS under either a manufacturing or
engineering organization. While this approach has the advantage of having leadership
knowledgeable of the risks associated with IACS, the benefits of such an approach can be
lost if this team does not coordinate closely with those responsible for traditional IT assets
and physical security.
 An overall security team is responsible for both physical and logical assets. In this
hierarchical structure, security is under a single organization with separate teams
responsible for physical and information systems. This approach is useful in smaller
organizations where resources may be limited.
b) Coordinating efforts with law enforcement agencies, regulators, and Internet service
providers along with other relevant organizations, as it relates to terrorist or other external
threats. Organizations that have established relationships with local emergency response
personnel expand these relationships to include information sharing as well as responding to
cyber security incidents.

– 85 – ANSI/ISA–62443-2-1 (99.02.01)–2009
c) Holding external suppliers that have an impact on the security of the organization to the same
security policies and procedures to maintain the overall level of IACS security. Security
policies and procedures of second and third-tier suppliers should also be in compliance with
corporate cyber security policies and procedures if they will impact IACS security.
 Companies should consider the increased security risk associated with outsourcing as
part of the decision making process to determine what to outsource and outsourcing
partner selection.
 Contracts with external suppliers govern physical, as well as logical access.
 Confidentiality or nondisclosure expectations and intellectual property rights should be
clearly defined.
 Change management procedures should be clearly defined.
d) Removing external supplier access at the conclusion/termination of the contract. The
timeliness of this is critical and is clearly detai led in the contract.
 ISO/IEC 17799, Clause 4 [14]
 SANS [34]
A.3.2.4 Element: Staff training and security awareness
Security awareness for all personnel is an essential tool for reducing cyber security risks.
Knowledgeable and vigilant staff is one of the most important lines of defense in securing any
system. In the area of industrial automation and control systems, the same emphasis must be
placed on cyber security as on safety and operational integrity, because the consequ ences can
be just as severe. It is therefore important for all personnel (employee, contract, or third-party) to
understand the importance of security in maintaining the operation of the system. Staff training
and security awareness programs provide all personnel (employees, contractors, and the like.)
with the information necessary to identify, review, address , and where appropriate, remediate
vulnerabilities and threats to IACS and to help ensure their own work practices include effective
countermeasures. All personnel should receive adequate technical training associated with the
known threats and vulnerabilities of hardware, software and social engineering. Cyber security
training and security awareness programs are most effective if they are tailored to the audience,
consistent with company policy and communicated regularly. Training provides a means to
communicate key messages to personnel in a timely fashion. An effective training program can
help employees understand why new or updated security contro ls are required and generate
ideas they can use to reduce risks and the impact on the organization if control methods are not
incorporated.
A.3.2.4.2 Developing a staff training program and building security awa reness
Training of one sort or another is an activity that spans almost the entire period during which a
CSMS is developed and implemented. It begins after the scope of the effort is clarified and the
team of stakeholders is identified. The objective of the training program is to provide all
personnel with the information they need so that they will be aware of any possible threats to the
system and their responsibilities for the safe and secure operation of the production facilities .
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
The organization should design and develop a cyber security training program in conjunction with
the organization’s overall training program . Training should be in two phases: 1) general training
for all personnel and 2) role-based training aimed at specific duties and responsibilities . Before

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 86 -
beginning the development of the training program it is important to identify the scope and
boundaries for the training and to identify and define the various roles within the organization.
The general training program should be developed for all personnel. Users should be trained in
the correct security procedures, the correct use of information processing facilities and the
correct handling of information in order to minimize risks . Training should also include legal
responsibilities, business controls and individual security responsibilities .
Role-based training should focus on the security risks and responsibilities associated with the
specific role a person fills within the organization. These individuals will need more specific and
intensive training. Subject matter experts should be emplo yed to contribute to this training. Role-
base training may be conducted in the classroom, may be web-based or hands-on. This training
may also leverage training provided by vendors for in-depth discussion of tools and associated
exposures.
The program should include a means to review and revise the program, as required and a means
to evaluate the effectiveness of the program . Also, there should be a time defined for periodic
retraining.
Management’s commitment to training and ensuring adequate cyber securit y awareness is

critical to providing a stable and secure computing environment for both IT and IACS. In
particular for the IACS environment, a stable and secure computing environment aids in
maintaining the safe operation of the equipment under control and reducing HSE incidents. This
should be in the form of resources for developing and organizing the training and making staff
available to attend.
Following the development of a cyber security training program, the organization should provide
the appropriate training for all personnel. Training programs should be provided in a place and at
times that allow personnel to be trained without adversely affecting their other responsibilities.
General training should be provided as part of a new employee’s orientat ion and as a part of the
orientation for contract, temporary or third-party personnel. The training required should be
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
appropriate for the level of contact which they will have with the organization . Specialized
training may be provided as follows:
Training for stakeholders

Training is appropriate for the team of stakeholders as well as the community of
individuals in the IACS community who will ultimately be impacted. The team of
stakeholders will need specific training on the type of risks that are being considered, the
scope and charter of work that management has approved, any background information
on incidents that have occurred to these systems either within the organization or within
the industry in general and on the types of architectures and syste ms that are in use
within the organization. Formal classroom training is not necessary to share this
information. Presentations at business meetings , communication sessions and e-mail
announcements are examples of ways to share the information.
Training employees preparing for new roles

Training will be needed for employees as they prepare to assume new roles either within
the direct risk management system or within the risk management related projects.
Virtually all members of the IACS community will recei ve a certain amount of training
during this phase. Some of the direct risk management roles will include responsibilities
for self-assessments or internal audits.

– 87 – ANSI/ISA–62443-2-1 (99.02.01)–2009
Training of auditors
Training will be needed for auditors to help them understand the nature of the systems
and networks they will be auditing as well as the specific policies that have been created.
Ongoing training
There will be an ongoing need for training at all levels due to the addition of new
employees and third-party personnel, the need to provide updates as policies and
services are modified over time and to provide refresher training to ensure that personnel
remain competent in their roles and responsibilities.
It is important to validate that personnel are aware of their roles and respon sibilities as part of
the training program. Validation of security awareness provides two functions : 1) it helps identify
how well the personnel understand the organization’s cyber security program and 2) it helps to
evaluate the effectiveness of the training program. Validation can come through several means
including written testing on the content of the training, course evaluations, monitored job
performance or documented changes in security behavior. A method of validation should be
agreed upon during the development of the training program and communicated to the
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
personnel.
Records of employee training and schedules for training updates should be maintained and
reviewed on a regular basis. Documenting training can assist the organization to ensure that all
personnel have the required training for their particular roles and responsibilities . It can also help
identify if additional training is needed and when periodic retraining is required.
Over time, the vulnerabilities, threats and associated security m easures will change. These
changes will necessitate changes to the content of the training program . The training program
should be reviewed periodically (for example, annually) for its effectiveness, applicability, content
and consistency with tools currently used and corporate practices and laws and revised as
needed. Subscriptions to security alert services may help ensure up -to-date knowledge of
recently identified vulnerabilities and exposures.

a) Addressing the various roles associated with maintaining a secure systems environment
within the cyber security training curriculums.
b) Having classroom courses or on-the-job training to address the requirements for each role.
c) Validating a user’s understanding via course evaluations and/or examinations.
d) Having subject matter experts for each course who can provide additional information and
consulting.
e) Reviewing and validating the training curriculum periodically and evaluating its effectiveness.
f) Communicating key messages to all personnel in a timely fashion via a security awareness
communication program.
g) Training all personnel initially and periodically thereafter (for example, annually).
While none of these baseline practices are specific to IACS security training, the emphas is and
content for the training programs needs to show the relationship between IACS security and HSE
consequences.

a) Establishing cyber security training as a component of the company’s overall training
organization for all employees.

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 88 -
b) Tailoring the cyber security training curriculums with a progression of material for a given role
in the organization.
c) Maintaining and reviewing records of employee training and schedules for training updates on
a regular basis depending on their position/role.
d) Leveraging cyber security training provided by vendors.
e) Establishing the timing, frequency and content of the security awareness communication
program in a document to enhance the organizations’ understanding of cyber security
controls.
f) Including an overview of the security awareness communication program for all personnel to
ensure they are aware of the security practices on their first day.
g) Reviewing the training and the security awareness program annually for its effectiveness,
applicability, content and consistency with tools currently used and corporate practices.
 ISA–TR99.01.02, 10.2 [2]
 ISO/IEC 27001, Clause 5.2.2, Annex A.8.2.2 and Annex C.5.2.2 [15]
A.3.2.5 Element: Business continuity plan
A business continuity plan identifies procedures for maintaining or re-establishing essential
business operations while recovering from a significant disruption . The purpose of the business
continuity plan is to provide a course of action to respond to the consequences of disasters,
security failures and loss of service to a business. A detailed business continuity plan ensures
that business critical IACS systems can be restored and utilized as soon as possible after the
occurrence of a significant disruption.
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
A.3.2.5.2 Scope of the business continuity plan

Before developing the business continuity plan, it is important to understand when the plan
should be used and what kinds of situations apply. Unplanned interruptions may take the form of
a natural disaster (that is, hurricane, tornado, earthquake, or flood), an unintentional man-made
event (that is, accidental equipment damage, fire, or explosion, or operator error), an intentional
man-made event (that is, attack by bomb, firearm, vandalism, hacker, or virus) or an equipment
failure. From a potential outage perspective, this may involve typical time spa ns of minutes or
hours to recover from many mechanical failures to days, weeks or months to recover from a
natural disaster. Because there is often a separate discipline that deals with reliability and
electrical/mechanical maintenance, some organizations choose to define business continuity in a
way that excludes these sources of failure. Since business continuity also deals primarily with
the long-term implications of production outages, some organizations also choose to place a
minimum interruption limit on the risks to be considered. For the purposes of IACS cyber
security, it is recommended that neither of these constraints be made. Long -term outages
(disaster recovery) and short-term outages (operational recovery) should both be considered.
The plan also includes other aspects of disaster recovery, such as emergency management,
human resources, and media or press relations.
Because some of these potential interruptions involve man -made events, it is also important to
work collaboratively with the physical security organization to understand the relative risks of
these events and the physical security countermeasures in place to prevent them. It is also

– 89 – ANSI/ISA–62443-2-1 (99.02.01)–2009
important for the physical security organization to understand which areas of a production site
house IACS that might pose higher-level risks.
A.3.2.5.3 The business continuity planning process

Prior to creating a plan to deal with potential outages, it is important to specify the recovery
objectives for the various systems and subsystems involved based on typical bu siness needs.
System recovery involves the recovery of all communication links and IACS capabilities and is
usually specified in terms of a recovery time objective or the time to recover these links and
capabilities. Data recovery involves the recovery of data describing production or product
conditions in the past and is usually specified in terms of a recovery point objective or the
longest period of time for which an absence of data can be tolerated.
Once the recovery objectives are defined, a list of po tential interruptions should be created and
the recovery procedure developed and documented. For most of the smaller scale interruptions,
repair and replace activities based on a critical-spares inventory may prove adequate to meet the
recovery objectives. In other cases, contingency plans need to be developed. Due to the
potential cost of these contingency plans, these should be reviewed with the managers
responsible for business continuity planning to verify they are justified.
The requirements for a business continuity team should be identified and a team should be
formed. The team should include IACS and other industrial operations owners. In the event of a
significant disruption, this team should determine the priority of critical business and IACS
systems to re-establish operations.
A schedule to test all or part of the recovery procedures should be developed. Often the
procedures for a specific subsystem are tested annually and the specific subsystem is rotated so
the overall system procedures are eventually tested over a 5-10 year period. These frequencies
are only examples and must be determined by your organization as part of the planning process.
Pay particular attention to verifying backups for system configuration data and product or
production data. Not only should these be tested when they are produced, the procedures
followed for their storage should also be reviewed on some frequency to verify that the backups
and the supporting data are usable and accurate. These backups should be kept under
environmental conditions that will not render them unusable and in a secure location where they
can be quickly obtained by authorized individuals when needed.
In the event that an incident occurs, the organization may be required to provide forensic data
about the incident to investigators, whether inside or outside the organization.
Over time, the business continuity plan will need to be reviewed and revised to reflect changes in
the management structure, organization, business model, industry, and the like.

--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

a) Forming a business continuity team involving the key stakeholders in the organization ( that
is, business owners, IT personnel, and IACS personnel) to develop the plan.
b) Determining the priority of critical business and IACS based on the nature of the system and
the time required for restoration. This depends on the organization’s risk tolerance and
recovery objectives.
c) Determining the amount of time/resources required for system restoration, location of backup
files, hardware, frequency of backups, need for hot spares, and the like., to ensure critical
systems can be restored in the event of a disaster situation.

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 90 -
d) Requiring that the records related to the document management and backup/recovery
procedures be readily available in multiple ways from multiple locations (that is, electronic
copies stored in a vault and paper copies on-site and in a protected facility) so that there is
no single point of failure.
e) Considering the possible impact on third parties such as joint ventures and supply chains.
f) Determining the need for additional business insurance.
g) Defining the specific roles and responsibilities for each part of the plan. Some organizations
divide the team into sub-teams reporting to a coordinating committee. Examples of sub-teams
include damage assessment, restoration and recovery, communications (internal and
external), and emergency response.
h) Assigning the responsibility for initiating the business conti nuity plan and clearly define the
circumstances under which to activate the plan.
i) Detailing under what circumstances to take specific emergency measures. The choice of
measures varies according to the specific scenario. Consider the consequences of an IT or
IACS disaster having physical impact to production faciliti es.
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
j) Defining the type, number and identity of the resources needed and their assignments.
k) Detailing the communications methods for the team members along with contingencies for
loss of email, phone disruption, and the like, in the event of a large-scale disaster.
l) Defining the frequency and method to test, validate and assess the continuity plan. Use these
results to improve and update the plan for increased effectiveness.
m) Detailing the risks associated with operating under the continuity plan and how they a re going
to be addressed and/or mitigated.
n) Identifying data that requires special handling and protection, as well as the information that
is critical to continued operation.
o) Establishing interim procedures to continue minimum business operations. A reduce d product
slate may be appropriate during this interim period.
p) Identifying and storing backup systems (hardware, software, and documentation) in a safe
location.
q) Testing backup systems on a predefined schedule for proper operation of the system and
correct restoration of the data.
r) Identifying and/or storing supplies to support the emergency response team and aid in
restoring business operations (for example, bottled water, detoxification showers, and
emergency air packs or respirators).
s) Defining the process for resuming normal operations.
a) Prioritizing IT systems and IACS by their consequence to the business or operation based on
the organization’s risk tolerance. The IACS may have impact on the business IT systems that
might be overlooked without collectively examining and prioritizing the systems as a whole.
Disaster planning and recovery plans should address the interrelationship of these systems.
b) Locating critical system backups in different geographic areas. If this is not feasible, s toring
backup data and equipment in an area not subject to the same physical disaster as the
primary system (that is, high ground for floods or concrete bunker for tornadoes).
c) Testing and updating business continuity plans periodically or as needed.
d) Tying business continuity plans to a management of change system ensuring an update to
the business continuity plan in the event of significant changes in system or business
consequence.

– 91 – ANSI/ISA–62443-2-1 (99.02.01)–2009
e) Testing communications plans periodically or as needed and assign responsibility to keep call
lists up-to-date.
f) Providing critical contact information to the core team ( a card carried by each team member).
g) Having each person of the team keep written copies of the plan at home.
h) Having procedures and/or contracts in place to purchase additional hardware, software and
supplies if needed. It is important that the continuity plan balances the replacement times for
IACS with the replacement times for the equipment being controlled. In some cases, this
equipment may have long lead times for repair/replacement that greatly exceed the
replacement time of the control systems.
i) Establishing service level agreements with providers of your disaster recovery service in
advance.
 ISO/IEC 17799 [14]
 NIST SP 800-82 [28]
 ANSI Standards [39]
 Corporate Governance Task Force “Information Security Governance – A call to action” [42]
A.3.2.6 Element: Security policies and procedures
Within each management system, there are sets of overall requirements to be met by the system
and lists of the organizations that are subject to these requirements. In this standard, those
requirements are referred to as policies. There are also descriptions of how individuals and
organizations meet the requirements in the management system. In this standard, these
descriptions are referred to as procedures.
For a cyber security management system, policies provide high -level guidance on requirements
for cyber security within the organization. They contain directives that address how an
organization defines cyber security, operates its cyber security program and addresses its
tolerance for risk. The policies for the CSMS are created from higher-level corporate policies
from which they derive their authority. Policies carry with them negative consequences for lack of
compliance, possibly including termination of employment or even criminal prosecution.
Procedures provide the detail on how the CSMS policies are implemented within the
organization. They may not be as strict as policies and may include provisions to obtain
exceptions since it is very difficult to craft procedures to deal appropriately with every possible
situation or contingency.
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
The CSMS policies and procedures written by the organization should give personnel a clear
understanding of their roles and responsibilities in securi ng the organization’s assets.
A.3.2.6.2 Developing security policies

Developing security policies for the organiza tion should not be approached as a linear task. After
the initial stages of policy development have been completed, it is necessary for the organization
to review and analyze the effectiveness of those policies, then refine them as necessary. These
policies should not be developed in isolation from other risk management systems in the
organization.
Developing and implementing security policies involves senior leadership commitment from all
areas of the organization with responsibility for these types of systems. By defining and
endorsing a security policy, senior leadership can demonstrate a commitment to continuous

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 92 -
improvement. Leadership commitment relating to security policies involves organization

leadership recognizing security policy as a business resp onsibility shared by all members of the
management team and as a policy that includes physical and cyber components. The security
procedures need to be incorporated into the overall business strategies and have management
support.
Many IACS organizations have existing policies in place for systems such as safety, physical
security, IT and employee behavior. When beginning the process of developing a cyber security
management system, it is important to try and integrate the cyber security policies in that sy stem
with existing policies and procedures. This may and often does, require the modification of
policies within those other risk management systems. For example, existing risk management
systems may have already characterized the risks or established risk tolerance levels that need
to be understood when developing the new CSMS. An explanation of combining policies and risk
management systems can be found in ANSI/ISA–99.01.01–2007 in the section on the Maturity
Model. [1] Security policies that deal with IACS risks will also deal with a wide range of issues
from organizational leadership requirements to technically detailed system configuration
requirements. It is recommended that these policies be separated into appropriate subgroups to
make them more accessible to readers who may only be interested in specific topics.
In many circumstances the security policies and procedures can be thought of as

countermeasures to address risk. These can take several forms from administrative procedures
to automated security tools. The objective is to make the overall cost of the countermeasures
less than the overall impact of the risk. Reducing the cost to implement the countermeasures
while still achieving the same level of risk reduction prov ides more value to the organization. In
cases where this economy of scale exists, the IT discipline will manage the technologies where
the scale can be leveraged. Thus, the detailed security policies of the IT discipline must be
examined for potential reapplication in the IACS space.
When developing cyber security policies, it is important to consider the conformance and
compliance requirements and the audit process as well. Since the IACS will need to be evaluated
for its compliance with the security policies, it is necessary to make sure that the policies defined
do not conflict with other, possibly more important risk management policies . For example, a
security policy is created requiring all desktop computers to be password protected at a certain
nuclear facility. This blanket policy also requires all operator stations in the control room to be
password protected, but these operator stations are required to be open due to safety
regulations. The password policy for desktop computers would cause the system to be out of
conformance to HSE policies. The cyber security policy should have originally been written
considering the effect it would have on all the different systems at a particular facility. A better
approach would be to define a policy that states that desktop computers to be protected from
unauthorized use and then have procedures that may require password protection in some
instances while providing physical isolation in other situations.
A.3.2.6.3 Determine the organization’s tolerance for risk

An organization should define a Risk Tolerance policy related to risk levels, corresponding to a
particular combination of likelihood and consequence . This policy can be based on a qualitative
risk assessment consisting of a list of assets or scenarios with an overal l likelihood and a
consequence ranking, which are defined and assigned as part of the organization’s risk
assessment process. (See Annex A.2.3)
In the typical risk level matrix example shown in Table A.3, likelihood and consequence have
both been broken down into three levels. The risk level has also been broken down into three
levels. The risk levels in each block (High, Medium , and Low) correspond to a particular
combination of likelihood and consequence. An organization defines a Risk Tolerance policy
related to each level, which will correspond to a particular level of corporate response to the risk.
For example, risks that merit a High might be resolved within 6 months; risks that only merit a

– 93 – ANSI/ISA–62443-2-1 (99.02.01)–2009
Low will not have any effort devoted to them; and Medium Risk Level items will deserve
intermediate effort. In other words, the organization has stated it can tolerate a High -level risk for
6 months and no longer.
A.3.2.6.4 Review and revise cyber security policies

The cyber security policies should be reviewed regularly, validated to confirm that they are up-to-
date and being followed and revised as required to ensure that they remain appropriate. Where
the cyber security policies are at a higher level, they should not n eed to be updated as often
since they describe what instead of how. While the how of the procedure may change with new
threats or techniques, the reason for protecting the system will remain relatively constant.
A.3.2.6.5 Deploying cyber security policies

During the creation of cyber security policies, the method for deploying them should be defined.
For example, security policies could be published on the corporate Intranet and users could be
trained on how the policy affects them. The policies are the bedrock of the CSMS, so the system
for deployment should be consistent with the implementation of the management system .

a) Establishing management commitment, involvement, and support while creating and
enforcing cyber security policies.
b) Requiring review and approval by all affected business units and departments, including
operations management.
c) Publishing written documents that describe the cyber security policies.
d) Reviewing, validating, and revising the policies regularly to conf irm that they are up-to-date
and being followed.
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
e) Communicating and disseminating cyber security policies to all personnel.
a) Creating consistent policies with an organization-determined lifecycle. The policies are
neither changed constantly, nor are they changed in reaction to hot topics.
b) Creating supporting policies that pertain to specific roles or groups that define how the
higher-level policy is implemented for each of these groups . For example, physical access
control and password restrictions may not be appropriate in certain industrial control
situations. Exceptional procedural safeguards may be required to compensate.
c) Creating security policies to address a number of security concerns, including the mitigation
of risks and the changing of staff attitudes towards cyber security.
d) Aligning the security policies with overall organizational policies and strategies.
e) Integrating the cyber security policies with or as a part of an overall security policy that
addresses physical elements too.
f) Identifying how the policies are enforced and by whom.
g) Identifying how users need to conform to the provisions of the policies.
h) Providing a consistent policy management framework.
i) Establishing which policies apply to specific users or user groups.
j) Identifying how to measure conformance requirements for the policies.

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 94 -

 SANS, for cyber security policy primer and samples [34]
A.3.3 Element group: Selected security countermeasures
The second element group within this category is Selected Secur ity Countermeasures. The
elements within this group discuss some of the main types of security controls that are part of a
well designed CSMS. This document does not attempt to describe the full implementation of any
of these selected security countermeasures. It discusses many of the policy, procedure and
practice issues related to these particular security countermeasures. Figure A.7 shows a
graphical representation of the six elements in the element group:
 Personnel security,
 Physical and environmental security,
 Network segmentation,
 Access control: Account administration,
 Access control: Authentication, and
 Access control: Authorization.
Selected security countermeasures
Physical and Access control:

Personnel Network
environmental Account
security segmentation
security administration
Access control: Access control:

Authentication Authorization
Figure A.7 – Graphical view of element group: Selected security countermeasures

A CSMS is the system via which an organization’s security countermeasures are selected and
maintained. Therefore particular countermeasures are considered a result of this system rather
than as a part of the CSMS itself. However, the counte rmeasures discussed in this section have
been included in this standard because their application is fundamental to the formulation of
security policy and architecture. For this reason, they should be considered up front during the
creation of a CSMS.
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
A.3.3.2 Element: Personnel security

Personnel security involves looking at potential and current personnel to determine if they will
carry out their responsibilities for IACS security in the organization and establishing and
communicating their responsibilities to do so. Employees, contractors or temporary personnel
that have access to industrial operation sensitive information or the IACS networks, hardware,

– 95 – ANSI/ISA–62443-2-1 (99.02.01)–2009
and software create a potential exposure if sensitive information is revealed, modified or if

unauthorized access to IT systems or IACS is granted.
A.3.3.2.2 Requirements for personnel security

In many organizations, the personnel security requirements have been driven by concerns about
insider threats and the possibility of accidents caused by inatten tion to detail or by personnel
unfit for a job due to lack of proper background or use of substances that might cloud judgment.
By implementing personnel security policies it may be possible to reduce these types of
problems.
When developing a program for personnel security, it is important to include personnel that can
access all systems in scope and not just limit the effort to personnel using traditional computer
room facilities.
Computers in IACS operations are tools used to operate the facility product ively and safely. It is
the personnel that operate the systems that are the heart of the operations and every care
should be taken to ensure that these people are qualified and fit for these positions . This process
begins at the recruitment phase and continues through termination. It requires constant attention
by management and co-workers to ensure that the system is operated in a secure manner .
A personnel security policy should clearly state the organization’s commitment to security and
the security responsibilities of personnel. It should address security responsibilities of all
personnel (both individual employees and the organization) from recruitment through the end of
employment, especially for sensitive positions. (This includes employees, prospecti ve
employees, contract employees, third-party contractors, and company organizations such as
human relations.)
All personnel, including new hires and internal transfers to sensitive positions ( for example,
those requiring privileged access) should be screened during the job application process. This
screening should include identity, personal and employment references, and academic
credentials. Background screenings may also include credit history, criminal activity , and drug
screening as this information may be useful in determining the applicants’ suitability (subject to
local Privacy Laws). Third-parties, contractors, and the like, are subject to background screening
at least as rigorous as employees in comparable positions. Employees and contractors may also
be subject to ongoing scrutiny, such as for financial, criminal, and drug activities. Due to the
amount of industrial operation sensitive data and potential HSE risks in some IACS
environments, it may be necessary to screen a wide group of employees w ho have access to the
IACS. Plant-floor employees may need the same level of background checks and scrutiny as a
typical IT system administrator. The terms “screening” and “background checks” are left
intentionally vague so that the organization can determine the level of screening to be performed
on personnel. “Sensitive positions” is also left to be defined by the organization because it is
realized that some positions can have little or no affect on the security of the system.
During the hiring process, the terms and conditions of employment should clearly state the
employees’ responsibility for cyber security. These responsibilities should extend for a
reasonable period of time after employment ceases. While hiring contractors or working with
third-party personnel, their security responsibilities should be document ed and included in any
agreements. Where possible, the responsibilities should be specific and measurable.
Personnel should be made aware of the organization’s security expectations and their
responsibilities through clearly documented and communicated statements by the organization.
Personnel must accept their mutual responsibility to ensure safe and secure operation of the
organization. Organizations may consider having all personnel of information processing facilities
sign a confidentiality or nondisclosure agreement. Any confidentiality agreements should be
reviewed with and signed by employees as part of the initial employment process. Third -party
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 96 -
contractors, casual staff or temporary emplo yees not covered by a formal nondisclosure
agreement should also sign a confidentiality agreement prior to beginning work.
Organizations should create job roles based on the segregation of duties to assure that access
to information is on a need-to-know basis and high-risk operating steps require more than one
person to complete. These duties should be segregated amongst personnel to maintain the
appropriate checks and balances, so that no single individual has total control over actions that
change the functional operation of the IACS. The security roles and responsibilities for a given
job should be periodically reviewed and revised to meet the changing needs of the company.
All personnel should be expected to remain vigilant for situations that may lead t o safety or
security incidents. Companies need to train managers to observe personnel behavior that may
lead to theft, fraud, error, or other security implications. A disciplinary process for cyber security
violations should be established and communicated to personnel. This should be tied to the legal
and punitive measures against such crimes in the country.

a) Screening personnel during the recruitment phase , such as background checks prior to hiring
or movement to sensitive jobs, especially for sensitive positions .
b) Scrutinizing personnel, especially those in sensitive positions, on a regular basis to look for
financial problems, criminal activity or drug problems.
c) Communicating the terms and conditions of employment or contract to all personnel stating
the individual’s responsibility for cyber security.
d) Documenting and communicating the organization’s s ecurity expectations and personnel
responsibilities on a regular basis.
e) Requiring personnel to accept their mutual responsibility to ensure safe and secure operation
of the organization.
f) Segregating duties amongst personnel to maintain the appropriate checks and balances.
g) Requiring all personnel to sign a confidentiality or nondisclosure agreement.
h) Establishing a disciplinary process for personnel who have violated the security policies of
the organization.
a) Creating job roles based on the segregation of duties to assure that access to information is
on a need-to-know basis and high-risk processing steps require more than one person to
complete.
b) Documenting the security responsibilities and including them in job descriptions, contracts or
other third party agreements.
 ISA–TR99.01.02, 10.2 [2]
 US Chemical Sector Cyber Security Strategy [21]
 SANS [34]
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`-

– 97 – ANSI/ISA–62443-2-1 (99.02.01)–2009
A.3.3.3 Element: Physical and environmental security

Physical and environmental security relates to creating a secure environment for the protection
of tangible or physical assets (that is, computers, networks, information, and operations
equipment) from damage, loss, unauthorized access or misuse. Physical and environmental
security of information systems is a well-established discipline that draws knowledge and
experience from other areas of physical or facilities security. Physical and environmental security
measures should be designed to complement the cyber security measures taken to protect these
assets.
Physical and environmental security measures are different, but linked since they both try to
protect the assets of an organization from threats . Physical security measures ensure that the
assets of an organization are protected physically from unauthorized access, loss, damage,
misuse, and the like. Environmental security measures ensure that the assets of an organization
are protected against environmental conditions that would make them unusable or damage the
information they contain.
Although cyber security policies and procedures are important for the proper protection of
information and control systems, in order to have truly effective protection, they should be
complemented by the appropriate level of physical security. For example, maintaining tight
controls such as authentication and access control does little to protect system integrity if it is
possible to enter a facility and physically remove or damage e lectronic media.
A.3.3.3.2 Considerations for physical and environmental security

In many organizations, the environmental and physical perimeter security requirements have
been driven by concerns about only the physical assets of the organization and may not fulfill the
cyber security requirements. Due to the integration of multiple organizations within specific sites
(that is, business partners, contractors, and third-parties), additional physical security protection
for IACS assets may be required. In IACS facilities, physical security is focused more at
protecting IACS assets than it is to the operations information itself . The concern is not so much
the actual theft or corruption of the computing and control devices, but rather the impact this
would have on the ability to sustain production in a safe manner.
When developing a program for physical security of assets, it is important to include all systems
in scope and not just limit the effort to traditional computer room facilities. ANSI/ISA–99.01.01–
2007 [1] discusses criteria that can be used to determine which physical assets should be
considered in the scope of the CSMS.
Computers comprising the IACS are tools used to operate the facility productively and safely.
They are a means to the end as well as the asset that must be protected. In some cases, safety
and/or productivity is threatened by locking equipment behind doors because the response time
to access the equipment may be increased.
Practical engineering judgment balancing all risks should be used to determine the physical
security procedures for the assets to be protected. Although it is common practice to locate
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
routers and other network equipment in locked environments, it may be of limited value to
expand this practice much beyond this level. Field devices (that is, valve actuators, motor
starters, and relays) are usually given the ability to be actuated directly in the field without
control signals over the IACS network. It can be cost -prohibitive to protect each field device
individually, so strong physical perimeter access procedures are usually needed in facilities that
involve a high risk.

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 98 -
The following list contains items that should be considered when creating a secure environment
for the protection of tangible assets from physical damage due to physical intrusion or
environmental conditions.
Security policy
A written security policy contains directives that define how an organization defines
security, operates its security program and reviews its program to make furthe r
improvements. These written policies allow personnel to clearly understand their roles
and responsibilities in securing the companies assets . The organization needs to
establish a physical and environmental security policy that is complimentary to both t he
organization’s cyber security policy and its physical security policy . The primary objective
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
is to bridge any gaps that might exist between these two policies . The physical and
environmental security policy should be consistent with and follow the same policies, as
discussed earlier, as other security policies dealing with the security of the control
system. A physical security detailed risk assessment is used to determine the appropriate
physical security procedures to be implemented.
Security perimeter
Critical information or assets should be placed in a secure area protected by security
perimeters and entry controls. These physical security controls work in conjunction with
cyber security measures to protect information. One or more physical security p erimeters
should be established to provide barriers for unauthorized access to facilities. Multiple
perimeters may be nested to provide successively tighter controls. An example may be
locked cabinet inside a control room with key card access within a faci lity with a guarded
perimeter fence.
Entry controls
At each barrier or boundary, appropriate entry controls should be provided. These entry
controls may be things like locked gates, doors with appropriate locks or guards . The
entry controls should be appropriate to the level of security required in the area secured
by the entry controls and relative for the need for quick access .
Environmental damage protection

Assets need to be protected against environmental damage from threats such as fire,
water, smoke, dust, radiation, and impact. Special consideration should be given to fire
protection systems used in areas affecting the IACS to make sure that the systems
responsible for protecting the facility offer protection to the IACS devices without
introducing additional risk to the industrial operation.
Security procedures
Personnel need to be required to follow and enforce the physical security procedures that
have been established to reinforce the entry and other physical controls. Personnel
should not circumvent any of the automated entry and other physical controls. An
example of an employee circumventing a physical control would be to have an entry door
to a protected control room propped open with a chair.
Single points-of-failure
Single points-of-failure should be avoided when possible. Redundant systems provide a
more robust system that is capable of handling small incidents from affecting the plant or
organization, for example, using a redundant power supply in a critical system to ensure
that if one power supply is damaged, the critical system will remain functioning.

– 99 – ANSI/ISA–62443-2-1 (99.02.01)–2009
Connections
All connections (that is, power and communications, including I/O field wiring, I/O bus
wiring, network cables, inter-controller connection cables, modems, and the like) under
the control of the organization should be adequately protected from tampering or
damage. This may include putting connections in locked cabinets or within fenced
enclosures. The level of physical security for these connections should be commensurate
with the level of security for the systems to which they connect . In considering physical
security, the consequences of environmental damage should also be considered. These
connections should also be protected against natural factors such as heat, fire, dust, and
the like, that could cause failures.
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
Equipment maintenance
All equipment, including auxiliary environmental equipment, should be properly
maintained to assure proper operation. Maintenance schedules should be established
and preventive maintenance perform ed. Equipment maintenance should be tracked and
trends noted to determine if maintenance schedules should be adjusted.
Alarms
Proper procedures should be established for monitoring and alarming when physical and
environmental security is compromised. Personnel should be required to respond to all
alarms with the appropriate response measures. All facilities, commensurate with their
security level, should be alarmed for both physical and environmental intrusions . These
may include motion detectors, cameras or door alarms for physical intrusions and fire
alarms, water detectors or temperature sensors for environmental concerns.
Equipment lifecycle
Proper procedures should be established and audited with respect to the addition,
removal and disposal of all equipment. Proper asset tracking is a good pract ice. These
procedures would include workstation disposal, format, clean drive, and the like. The
procurement of hardware would also take into account how the equipment can be tracked
and how it can be sanitized and disposed when the time comes that it is no longer
needed.
Physical information
All information, expressed in a physical form ( that is, written or printed documents,
magnetic storage media, and compact disks), needs to be adequately protected against
physical threats. This may include placing these items in locked rooms or cabinets to
prevent unauthorized access. Consideration should also be given to protecting the
information from environmental damage such as magnetic fields, high humidity, heat , or
direct sunlight, and the like, that could damage the information. Like those for equipment,
procedures should be in place to securely dispose of physical media when no longer
needed.
Use of assets outside controlled environments

Special care should be taken when using assets that affect the IACS outside of the IACS
network. This includes staging the assets at a system integrator facility prior to
installation. Also, assets like laptop computers with access to the IACS network used off -
site should be handled as an extension of the IACS network with all of the appropriate
physical and environmental security procedures being followed. Consideration should be
given to using the same level of security for assets that are temporarily outside of the
normal security boundaries. This may require special planning or facilities to protect
these assets against unauthorized access or use or from environmental damage.

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 100 -
Interim protection of critical assets

During and following either a physical or environmental event, power or other service may
be lost to critical systems. Provisions should be made to protect these critical systems.
This could include such things as supplying backup power, covering or damming to
prevent water damage, and the like.

a) Establishing physical security perimeters to provide barriers for unauthorized access to
facilities. At each barrier or boundary, appropriate entry controls are provided.
b) Protecting assets against environmental damage from threats such as fire, wa ter, smoke,
dust, radiation, and impact.
c) Requiring personnel to follow and enforce the physical security procedures that have been
established to reinforce the entry and other physical controls.
d) Requiring redundant sources of power to prevent single points -of-failure.
e) Protecting all external connections from tampering or damage.
f) Maintaining all equipment, including auxiliary environmental equipment, to assure proper
operation.
g) Establishing procedures for monitoring and alarming when the physical and/or environmental
security is compromised.
h) Establishing and auditing procedures with respect to the addition, removal , and disposal of all
assets.
i) Using special procedures to secure assets that affect the IACS outside of the IACS network.
a) Using security cables, locked cabinets, protected entrances at the home office, keeping
equipment out of sight and labeling and tagging assets.
b) Using password settings for boot and login commands on computers not in the control room,
encrypted file system, laptops using thin-client techniques, and the like.
c) Protecting computer equipment not in control rooms such as routers or a firewall by placing
them in a locked environment.
d) Having control rooms staffed 24x7x52. This can often be the first line of defense in physical
protection. Use control rooms to house information and technology assets.
e) Requiring personnel who are leaving the organization to return the equipment in good
working order.
f) Using an equipment tracking system to determine where equipment is locate d and who has
responsibility for the equipment.
g) Requiring environmental protection for assets including proper housing for equipment that is
located where it may be subjected to dust, temperature extremes, moisture, and the like.
 ISA–TR99.01.02, 10 [2]
 Understanding ISO 17799 [22]
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`--

– 101 – ANSI/ISA–62443-2-1 (99.02.01)–2009
A.3.3.4 Element – Network segmentation

Network segmentation involves separating key IACS assets into zones with common security
levels in order to manage security risks to achieve a desired target security level for the zone.
Network segmentation is an important security countermeasure employed in conjunction with
other layers of defense to reduce the risk that may be associated with IACS.
Today’s IACS are connected to and integrated with business system s both within and between
partner companies. Despite the need for connectivity and tight integration, IACS do not need to
utilize the vast majority of the data traversing corporate networks . Exposing the IACS devices to
all this traffic increases the likelihood of a security incident with in the IACS. In keeping with the
principle of least privilege and need to know, IACS should be architected in a manner that
filters/removes unnecessary communication packets from reaching the IACS devices . Network
segmentation is designed to compartmentalize devices into common security zones where
identified security practices are employed to achieve the desired target security level. The goal is
to minimize the likelihood of a security incident compromising the functional operation of the
IACS. Compartmentalizing devices into zones does not necessarily mean isolating them .
Conduits connect the security zones and facilitate the transport of necessary communications
between the segmented security zones.
The overriding security premise is that the use of secu rity countermeasures should be
commensurate with the level of risk. Network segmentation of an IACS may not be necessary if
the security risks are low. The risk management and implementation element provides additional
information on the subject of managing risk. It should be reviewed prior to implementing a
network segmentation countermeasure strategy discussed in this element of the CSMS .
A.3.3.4.2 Network segments and zones

The models section in ANSI/ISA–99.01.01–2007 [1] introduces reference models and provides
the context for discussing this countermeasure. Networks are segmented through the use of
some sort of a barrier device that has the ability to control what passes through the device . On
Ethernet based networks running TCP/IP, the most common barrier devices in use are firewalls,
routers and layer 3 switches. Frequently, IACS are comprised of several different networks
employing different physical and application layer technologies. These non-TCP/IP networks also
employ barrier devices to separate and segment communications. The barrier devices may be
standalone gateways or integrated into the network interface module of an IACS device .
While a security zone may be created by a placing a barrier device into the network thereby
creating a new network segment, a security zone may encompass multiple network segments .
Figure A.8 illustrates a possible segmented architecture for a generic IACS. This figure attempts
to depict how functional equipment levels may translate into the physical world of an IACS and
the logical world of a zone. (The figure is fairly high level and does not include all the network
devices required in an actual installation.)
It is important to not confuse the functional levels of t he reference model with security levels
associated with security zones. While it is generally true that the lower level equipment plays a
greater role in the safe operation of the automated industrial operation, it may not be practical or
possible to employ a segmentation strategy aligned one-for-one with the equipment levels.
In this figure, the control zone contains equipment with a common target security level. The
figure depicts a TCP/IP-based process control network (PCN) segment, a proprietary regulatory
control network (RCN) segment and a proprietary field device network (FDN) segment. These
networks link the Level 0, 1, 2 and 3 equipment shown in the ISA99 reference model. The barrier
devices for each of these network segments regulate the communication en tering and leaving
their segment.

--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 102 -
Segmentation architecture
ISA-99 reference architecture
(logical/physical)
Business/enterprise zone Business/enterprise zone
Business Corporate
Enterprise Corporate
resource Office di gi t a l
di gi t a l
patch
anti-virus
di gi t a l
domain
di gi t a l
planning work- management

Level 4 controller server
Enterprise systems system stations server
(business planning and logistics) WAN
Site router
Site
3Com
d i gi t a l
resource
di gi t a l
Manufacturing
Office
domain application
workstations
controllers server Site
LAN
DMZ DMZ
di gi t a l d i gi t a l
Patch
PCN Application Support management
firewall server workstation server for PCN
and DMZ devices
DMZ
Site manufacturing operations and control
Level 3
di gi t a l d i gi t a l
Domain Application Operator

Area and supervisory control controller server consoles
Level 2
PCN
Gateway
3Com
Basic control Controllers

Safety Field device
devices Mo dem Bank
Mo dem Bank
Level 1 instrumented gateway

systems RCN 3Com
FDN
Field I/O devices

Level 0 Process I/O devices Field I/O devices
Mo dem Bank
SIS
Field I/O devices

Control zone Control zone
Safety system zone
Figure A.8 – Reference architecture alignment with an example segmented architecture

Control zone – For low-risk IACS, it may not be necessary to employ a network segmentation
countermeasure and create a control zone. However for medium- to high-risk IACS, network
segmentation is a countermeasure providing very significant risk reduction .
The generally accepted good practice is to use a barrier device such as a firewall to manage the
communication across the conduit that links the control zone to the business zone, as shown in
Figure A.8.
Common filtering strategies at the barrier device include:
 The base configuration of the barrier device should be to deny all communication by
default and only allow communication by exception to meet a critical business need . This
applies to both intermittent, interactive user communication across the conduit and
continuous, task-to-task communication between devices in these two zones . Whenever
possible, communications should be filtered by ports and services between matched IP
pairs for the devices communicating over the conduit .
 Ports and services frequently used as attack vectors should not be opened through the
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
barrier device. When the service is required due to business justification, extra
countermeasures should be employed to compensate for the risk . As an example,
inbound http, which is a common attack vector, may be necessary to support an important
business function. Additional compensating countermeasures such as blocking inbound
scripts and the use of an http proxy server would help lessen the risk of opening this high
risk port and service.

– 103 – ANSI/ISA–62443-2-1 (99.02.01)–2009
 The fewer the number of ports and services open through the barrier device the better .
Communication technologies that require a large number of ports to be open should be
avoided.
The barrier device can serve as a good automated tool to enforce that security practices be
followed in the control zone, such as not allowing inbound email or communications to/from the
Internet.
Demilitarized zone (DMZ) – For high risk IACS, the use of a DMZ in conjunction with a Cont rol
zone offers additional risk reduction opportunities between the low-security level Business zone
and the high-security level control zone. The security level for the DMZ is higher than the
Business zone but less than the control zone. The function of this zone is to eliminate or greatly
reduce all direct communication between t he control zone and the business zone.
Devices should be located in the DMZ that function as a bridge or buffer between devices in th e
business zone and control zone. Communication is setup between a device in the business zone
and the DMZ. The device in the DMZ then passes along the information to the recipie nt device in
the control zone. Ideally the ports and services employed between the device in the business
zone and the DMZ are different from the ports and services used between the DMZ device and
the destination control zone device. This reduces the likelihood that malicious code or an
intruder would be able to negotiate the combined conduits connecting the business zone to the
control zone.
The filtering strategies listed above for the control zone are also applicable for the DMZ.
However, some riskier protocols like telnet may be allowed to facilitate management of devices
in the DMZ and control zones.
There are several use cases where a DMZ can be of benefit . These are included here to
illustrate the security concepts. They are not meant to be an exhaustive or detailed list of how to
implement a DMZ.
Minimize the number of people directly accessing control zone devices.

Historian servers are often accessed by people located on the site LAN in the business
zone. Rather than locating the historian server in the control zone and allowing direct
access to this device from the business zone by a large number of users, the security
level of the control zone can be maintained at a higher level if the historian server is
located in the DMZ.
Provide greater security for important IACS devices.

In the case of the historian server mentioned above, an option would be to locate the
historian on the site LAN where the majority of the users are located. This would reduce
the number of people needing to access the PCN . However, since the business zone is a
low-security level zone, the historian server would be subjected to a less secure
environment. The potential for compromise of the server would be greater.
Compensate for patching delays.

--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
The DMZ offers additional security protection to important IACS devices that cannot be
patched as quickly while waiting for patch compatibility testing results from the
application vendor.
Provide improved security for the control zone by moving management devices to a
higher security level.
The DMZ is a good place to locate devices like anti-virus servers and patch management
servers. These devices can be used to manage deployment of security modules to the

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 104 -
control zone and DMZ devices in a more controlled manner without subjecting the high-
security level control zone to direct connection to servers that may be communicating to
hundreds of devices.
Safety system zone – Some IACS may employ a set of safety interlocks that are relay-based or
microprocessor-based. A microprocessor-based logic solver SIS may require a slightly different
set of security practices from that employed in the control zone. The target security level for this
zone should be determined and appropriate actions take n to ensure appropriate
countermeasures are employed to meet the target security level.
Isolated IACS – The risk associated with the IACS may be too great to allow any opportunity for
compromise by an external agent. A facility may choose to disconnect all conduits between the
control zone and any other zone. This is a very valid network segmentation strategy for
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
consideration.
Facilities choosing to adopt this isolation approach are not automatically eliminating all risk .
There may still be much vulnerability that could be exploited locally. Appropriate layers of cyber
and physical protection should be employed to address the residual risk remaining after isolation
of the IACS from the business zone.
A.3.3.4.3 SCADA segmentation architecture

The above discussion described a segmented architecture for an IACS typically found in a single
operating facility. Segmentation is a countermeasure that has equal applicability for a SCADA-
type IACS. Figure A.9 illustrates one possible segmentation approach for this type of
architecture. Although not shown due to space constraints, the DMZ and safety system zone
described in the single operating facility IACS can also be employed in a SCADA architecture.

– 105 – ANSI/ISA–62443-2-1 (99.02.01)–2009
Figure A.9 – Reference SCADA architecture alignment with an example segmented

architecture
A.3.3.4.4 Suggested practices
a) Employing barrier devices such as firewalls to segment high -risk IACS devices into control
zones.
b) Employing gateways or internal barrier devices within the IACS device to separate regul atory
control networks from the PCN.
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
c) Employing sound change management practices on the barrier device configuration.

d) Disconnecting high-risk IACS from the business zone.
a) Employing add-on, supplemental barrier devices within the control zone to further segment
the network.
b) Employing a common and centrally managed security profile on a ll control zone barrier
devices.
c) Employing a DMZ segmentation architecture.

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 106 -
d) Performing automated assessment tests to verify that the barrier device configuration has
been correctly implemented per the design specification.
 ANSI/ISA–99.01.01–2007 [1]
A.3.3.5 Element: Access control: Account administration
A.3.3.5.1 General description of access control
Access control is the method of controlling who or what resources can access premises and
systems and what type of access is permitted . The misuse of data and systems may have
serious consequences, including harm to human life, environmental damage, financial loss , and
damage to the corporate reputation. These risks are increased when personnel have
unnecessary access to data and systems. It is very important that the security policy that defines
the access control rules and procedures is clearly documented and communicated to all
personnel (that is, employees, joint ventures, third-party contractors, and temporary employees).
One of the most important security elements for any computer system is having a sound and
appropriate set of access control procedures. There are three key aspects associated with
access control: Account administration; Authentication; and Authorization . Each of these is
described separately in their own element section of this document . However, all three aspects
must work together to establish a sound and secure access control strategy .
Within each of the three aspects of access control, rules should be established to confirm that a
user’s access to systems and data is controlled. The rules generally should be applied to roles or
groups of users. They should have access to systems and d ata that are required to meet defined
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
business requirements but should not have access if there is no defined business purpose for it.
There are rules that are enforced administratively and those that are enforced automatically
through the use of technology. Both kinds of rules need to be addressed as part of the overall
access control strategy. An example of an administrative rule that a n organization might have is
the removal of employee’s or contractor’s account after their separation from the organizati on.
An example of a technology enforced rule is requiring remote users connecting to the corporate
network to utilize a VPN.
In addition to rules, there are both physical security procedures and cyber security procedures
that work together to establish the overall security framework for the system. Physical security
procedures include such measures as locking rooms where user interface equipment is located.
This standard provides a basic description of the parts of physical security that relate to cyber
security in Annex A.3.3.3.
There is both a real-time aspect to access control and an off -line aspect. Quite often, insufficient
attention is paid to the off-line activities of access control for IACS. The off-line activity, here
described as Account administration, is the first step in the process and includes defining the
user privileges and resource needs for the user. These are based upon the role of the user and
the job to be performed. The off-line method also includes an approval step by a responsible
party before the access account is configured to provide the proper access.

– 107 – ANSI/ISA–62443-2-1 (99.02.01)–2009
Figure A.10 – Access control: Account administration

Account administration, one of the three legs of access control as shown in Figure A.10, is the
method associated with initially setting up permission and privileges to access specific resources
on the network or system and to review those permissions and privileges on a periodic basis. It
may be linked in some way to the physical access to resources. Account administration in the
IACS environment goes beyond the traditional IT definition of operating system account access
for a particular user. In the IACS environment, access accounts are more role-based for the
functions they can perform on a particular machine rather than the data they can access. A
user’s role may change in an organization over time, so the administration process may be used
more frequently on IACS accounts. Privileges often include access to file directories, hours of
access and amount of allocated storage space. The role assigned at the application level for the
access account must be identified and understood during the administration phase. Several
steps are involved that include identification of the resources needed to perform that person’s job
function, independent approval by a trusted person and setup/configuration of the computer
account that automatically assigns the resources when requested.
In addition to the task of creating access accounts and assigning users to roles at the operating
system level, many manufacturing applications require additional role assignments. System
administrators for IACS must be skilled and trusted to perform these account administrative
functions on live equipment control applications. The change management process for making
these account changes should clearly identify any timing constraints that must be followed due to
the safety risks during certain sequences of the con trol operation.
A.3.3.5.3 Considerations for account administration

When developing a program for account administration, it is important to include all systems in
scope and not just limit the effort to traditional computer room facilities.
Rules to control a user’s access to systems, data, and specific functions

Each organization should establish rules to control a user’s access to the systems , data
and functions. These rules should be based on the risk to the system and the value of the
information. These rules should be conveyed to all personnel.
Standard administration process

A standard administrative process should be followed for the creation of access accounts.
Although it may be more cost efficient for a single organization to provide the account
administration function for all computer systems in a company, IACS and IT systems may
have different sets of people providing administrative control of the account creation and
maintenance process. This is often due to the different set of risks associated with these
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
ANSI/ISA-62443-2-1 (99.02.01)–2009 - 108 -
systems. Account approvals may also require approval by a supervisor familiar with the
IACS tasks and operations.
Role based access accounts

A standard administrative process should be followed for the creation of access accounts.
The accounts should be role based and grant the user only those privileges and access
to resources that are needed to perform their particular job function.
Minimum privileges
Users should be assigned the minimum privileges and authorizations necessary to
perform their tasks. Access should be granted based on the need to support a particular
job function. The role-based privileges should consider special requirements for installing
software, requirements for configuring services, file-sharing needs, and remote access
needs.
Separation of duties
The account administration process includes principles of separation of duties with
separate approvers and implementers of account configuration. This principle provides an
additional layer of protection so that one person can not compromise a system alone.
Identify individuals
Every user should be identifiable with separate access accounts unless there are HSE
risks for such accounts. In such cases, other physical security controls should be
employed to limit access. Access needs to be controlled by an appropriate method of
authentication (that is, user ID and password, personal identification numbers [PINs], or
tokens). These personal credentials should not be shared except in certain special
situations. One special case is in a control room where the operators function as a single
work team or crew. In this situation, everyone on the work team may use the same
credentials. (Additional discussion is provided on this subject in Annex A.3.3.6.). An
alternate identification process should exist in the event of a forgotten password.
Authorization
Access should be granted on the authority of an appropriate manager (either from your
company or a partner organization). Approvals should be made by supervisors familiar
with the manufacturing/operations tasks and the specific training a person has had for
that role.
Unneeded access accounts

Access accounts are the means of controlling access to the system , therefore, it is
important that these accounts be inactivated, suspend ed or removed and access
permissions revoked as soon as they are no longer needed ( for example, job change,
termination, and the like). This action should be taken by the appropriate manager as
soon as possible after the access account is no longer needed.
Review access account permissions

The need for access to critical systems is explicitly reconfirmed on a regular basis. All
established access accounts should be reviewed periodically to ensure that the account
is still in use, their role and access needs are still correct, the user is still authorized and
only has the minimum required permissions. Inactive or unneeded accounts should be
removed. If an access account remains unused for an extended period, the need for it is
explicitly confirmed by the account owner and account sponsor.

--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

– 109 – ANSI/ISA–62443-2-1 (99.02.01)–2009
Record access accounts

One of the primary functions of account administration is the recording of the individual
access accounts. Records should be maintained of all access accounts, including details
of the individual, their permissions and the authorizing manager.
Change management
The change management process for account administration should clearly identify any
timing constraints that must be followed due to the safety risks of making changes during
certain industrial operation sequences. These changes are treated with as much
importance as are process, software, and equipment changes. The access account
administration process should integrate with standard process safety management (PSM)
procedures and include approval and documentation steps. The approvers of access
accounts for manufacturing/operations functions may be a different set of people than are
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
approving users for the IT systems. Approvals should be made by supervisors familiar
with the manufacturing/operations tasks and the specific training a person has had for
that role.
Default passwords
Many control systems come with default passwords that are used in getting the system
set up and ready for operation. These access account passwords are often widely known
or easily determined from published literature or other sources . These default passwords
should be changed immediately upon setup and before connection to the system.
Audit account administration

Periodic reviews for compliance of access account administration information should be
conducted. This ensures that the owners of the information or documents are compliant
with the appropriate policies, standards or other requirements set down by the
organization.

a) Assigning the minimum privileges and authorizations to users necessary to perform their
tasks. Access should be granted on the basis of the need to perform a particular job function.
b) Controlling identification and access for each individual user by an appropriate meth od of
authentication (for example, user ID and password). These personal credentials ( that is,
passwords, PINs, and/or tokens) are not shared except in certain special situations.
c) Establishing an alternate identification process in the event of lost credentials or a forgotten
password.
d) Granting, changing, or terminating access on the authority of an appropriate manager (from
the organization, contracting organization, or third -party). A record is maintained of all access
accounts, including details of the individual, their permissions, and the authorizing manager.
e) Suspending or removing all access accounts and revoking permissions as soon as they are
no longer needed (for example, job change).
f) Reviewing all established access accounts on a regular basis to ensure that they are still in
use and they still require access to critical systems.
g) Reconfirming the need for access accounts with the appropriate manager if the accounts are
unused for an extended period of time.
h) Requiring default passwords to be changed immediately.

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 110 -
i) Requiring all personnel (that is, employees, joint ventures, third-party contractors, and
temporary employees) to agree in writing to conform to the security policy, including access
control policies.
a) Using tools (that is, provisioning and identity management) to manage the process of access
account creation, suspension, and deletion. A provisioning system also manages the
approval workflow by which the business owner approves access, including logging. It may
also automate the process of account creation/suspension on the target systems.
b) Linking the account administration process to the human resources process so that employee
changes trigger reviews and updates to access accounts.
c) Defining and documenting the application roles/user privileges (that is, job functions mapped
to application roles and access entitlements for each role) by the application information
owner or delegate.
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
d) Paying special attention to users with privileged access ( that is, more frequent reviews and
background checks).
e) Allowing users to have more than one access account, based on their particular job-role at
that particular time. A person would use a system administrator access account to perform an
application update on a particular machine but would also need an operator access account
to run and test the application.
 ISA–TR99.01.02, 5 [2]
A.3.3.6 Element: Access control: Authentication
For additional information about the overall topic of Ac cess control, see the introductory material
in Annex A.3.3.5.1.
Figure A.11 – Access control: Authentication

Authentication, another of the three legs of access control as shown in Figure A.11, is the
method of positively identifying network users, hosts, applications, services, and resources for
some sort of computerized transaction so that they can be given the correct authorized rights
and responsibilities. The method uses a combination of identification factors or credentials.
Authentication is the prerequisite to allowing access to resources in a system.
Authentication in the IACS environment has several challenges not typically found in normal IT
situations. Current IT authentication technologies have several limitations that are not well suited

– 111 – ANSI/ISA–62443-2-1 (99.02.01)–2009
for the IACS environment and could actually result in increased HSE risks at the expense of
decreased cyber security risks.
It is important in the IACS environment to make sure that the right people have access to the
correct information and systems and are not prevented from doing their job via authentication.
Failure to authenticate a valid user could have HSE implications if the user is not able to perform
tasks in a critical situation. In the IACS environment, there is a great emphasis on combining
physical authentication measures with electronic authentication practices.
The physical location of the user may have a significant impact on the risk level of the access.
For example, the user connecting to a system from inside a building that employs a guard and
badge-reader system at the door is less of a risk than a user connecting from some other region
in the world. The authentication strategy addresses the combined physical and c yber security
controls to be used to control overall risk. The strategy clearly defines the authentication
requirements for special situations.
There are several types of authentication strategies and each has varying degrees of strength.
Strong authentication methods are ones that are quite accurate in positively identifying the user.
Weak authentication methods are ones that can be easily defeated to provide unwanted access
to information.
The physical location of the user may have a significant impact on the risk of accessing the
IACS. Authentication for these cases will be discussed in the following sections.
Authentication for local users

It is very important that only trained and designated resources take actions on industrial control
HMI stations, such as operator control stations. Many industries control their equipment from
control rooms staffed by several operators. These operators often function as a team and
perform actions on multiple HMI stations as part of their normal job function. Common access
accounts shared by the team of operators are frequently employed. Until cost-effective, robust,
strong authentication schemes are available on the HMI stations, the recommended practice is to
use physical controls to ensure that only designated individu als are performing actions on control
room HMI stations. Access to control rooms should be managed by appropriate combinations of
entrance control technologies and administrative procedures. Consider the HSE implications
when developing the access control procedures.
Authentication for remote users

Remote users are anyone who is outside the perimeter of the security zone being addressed . A
person in an office in the same building, a person connecting over the corporate wide area
network (WAN) and a person connecting over public infrastructure networks are all examples of
remote users.
Physical and administrative controls that rely on visual authentication do not work for remote
interactive users. However, there are numerous technology-based authentication schemes that
can be used. It is important to employ an authentication scheme with an appropriate level of
strength to positively identify the remote interactive user. Industrial operations with a low
potential to create HSE incidents and that have low financial impact may be protected using
weak authentication methods such as a simple user ID and password. However, industrial
operations where there is a large financial or HSE stake should be protected using strong
authentication technologies. For these types of operations, it is recommended that the system be
designed in a way that the remote access user is not allowed to perform control functions, only
monitoring functions.

--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 112 -
Authentication for task-to-task communication

The discussion above focused on interactive users. It is just as important to employ appropriate
authentication schemes for task-to-task communication between application servers or between
servers and controlled devices. The communications interface should employ methods to verify
that the requesting device is indeed the correct device to perform the task. Some ways in which
critical interfaces could authenticate task -to-task communications between devices are checking
the internet protocol (IP) address, checking the media access control (MAC) address, using a
secret code or using a cryptographic key to verify that the request is coming from the expected
device. Interfaces with low risk may use less secure methods for authentication. An example of
insecure communications is an anonymous file transfer protocol (FTP) for program
upload/download/compare between the control HMI and a data repository.
A.3.3.6.2 Considerations for authentication

When developing a program for access control, it is important to include all systems in scope,
and not just limit the effort to traditional computer room facilities.
Authentication strategy
Companies should have an authentication strategy or approach that defines the method
of authentication to be used.
Authenticate all users before system use

All users should be authenticated before using the requested application. This
authentication may be a combination of physical and cyber authentication practices.
Require strong secure accounts for system administration and/or application

configuration
Strong account user ID and password practices should be used on all system
administrator and application configuration access accounts. The system administrator
does not typically need quick access to perform system -level tasks on the computers. It is
more important that untrained users be prevented from performing system -level functions
than it is to provide quick access.
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
Local administration
On highly critical systems, it is a good practice to perform all system administrator or
application configuration functions locally at the device to reduce the potential for a
network interruption causing a problem with the control of the equipment. The system
administrator or application manager should coordinate all changes with the operator for
the area so that production is not impacted during a configuration change.
Authentication for local users

If a practice introduces the potential to delay an operator’s ability to locally make quick corrective
action to the industrial operation from the HMI control station, normal IT authentication practices
may not be appropriate. To achieve security in control system operation while still providing for
rapid response, a combination of physical and cyber controls have been found to produce the
best results. Some of these controls include but are not limited to:
 Manual locks (for example, key and combination) on doors to rooms or cabinets
containing control system components
 Automated locks (for example, badge and card readers)
 Control rooms staffed 24x7x52

– 113 – ANSI/ISA–62443-2-1 (99.02.01)–2009
 Individual accountability by control room personnel t o keep access limited to designated

personnel and ensure that only trained personnel perform actions on operator control
stations.
Some examples of common IT practices that may not be applicable in an IACS environment are:
Individual user IDs and passwords for each operator for work-team environments
Many industries control their operations from control rooms staffed by several operators.
These operators often function as a team and perform actions on multiple HMI stations as
part of their normal job function. Requiring each operator to log in and be authenticated
and authorized each time they use a new HMI could compromise quick response to an
operation event.
Access to non-local domain controllers and active directory servers for access
account authentication
Network issues may interfere with timely login under this architecture.
Automatic access account lockout after some number of failed login attempts
Under some conditions that require rapid response by an operator, the operator may
become flustered and enter the wrong password. If the operator is then locked out, it
could compromise the operator’s ability to resolve the situation.
Robust long passwords that contain a mix of alpha, numeric , and special
characters
Although robust passwords provide an increased measure of security, in the control room
environment, the requirement to enter such passwords could slow response time for an
operator. A similar level of security could be achieved by physical means such as locked
doors or 24x7x52 staffing of the control room by those that know cleared operators.
Password changes after a specified number of days

The impact of changing passwords is much like that of robust passwords, it may slow
response to a situation when a quick response is needed . Passwords should be changed
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
when there is a change in personnel, but changing after a set number of days may not be
productive.
Screen savers with password protection

Many HMI stations are designed to report by exception. The operator may not need to
take any action on the operator station until an alert occurs. Screen savers have the
potential to interfere with the operator by blocking the view to the operation under control
and delaying response to an emergency situation.
Authentication for remote users

Remote users do not normally need to rapidly respond to situations common to operators . In
addition, for remote users, accountability becomes more important than availability. Therefore,
some of the practices common to IT security are also of benefit for remote users . These include:
Authenticate all remote users at the appropriate level

The organization should employ an authentication scheme with an appropriate level of
strength to positively identify a remote interactive user.

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 114 -
Log and review all access attempts to critical systems

The system should log all access attempts to critical systems and the organization should
review these attempts whether they were successful or failed.
Disable access account after failed remote login attempts

After some number of failed login attempts by a remote user, the system should disable
the user’s access account for a certain amount of time. This helps deter brute force
password cracking attacks on the system. Although remote users do not normally need to
respond rapidly to operation situations, there may be instances, such as unmanned
control rooms or remote facilities (for example, SCADA systems controlling an electrical
distribution system) where rapid access is required from a remote location. In these
cases, disabling the access account may not be appropriate. Each organization should
address authentication of remote users in a manner appropriate to their situation and
tolerance for risk.
Require re-authentication after remote system inactivity

After a defined period of inactivity, a remote user should be required to re-authenticate
before the system can be accessed again. This makes sure that the access account is
not left open and accessible from the remote device. Although remote users do not
normally need to connect to the control system for long periods of time, there may be
instances, such as unmanned control rooms or remote facilities ( for example, SCADA
systems on an electrical distribution system) where a remote operator may need to
monitor the system over an extended period of time. In these cases, requiring re-
authentication may not be appropriate. Each organization should address authentication
of remote users in a manner appropriate to their situation and tolerance for risk.
For remote users, the level of authentication require d should be proportional to the risk to the
system being accessed. Weak authentication may be appropriate if the system does not have
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
control over operations with a high HSE risk. For systems with HSE risks, strong authentication
may be more appropriate.
Examples of weak authentication include:
 Connecting modems directly to industrial operation control devices or networks that

employ simple user ID and password authentication
 Connecting industrial operation control devices or networks from the corporate LAN or
WAN that employ simple user ID and password authentication
 Using Microsoft Windows® user ID and password authentication at the application level
on industrial operation control devices
Examples of strong authentication include:
 Using Physical token or smart card two factor authentication that requires both a physical
device and unique knowledge (for example, a Personal Identifier Number, PIN) in the
possession of the user. Security is enhanced by using secure PIN entry, for example
when the PIN is entered using a secure reader to prevent keylogging.
 Authenticating using smartcards or biometrics
 Authenticating users based on their location
 Connecting modems to industrial operation control devices or networks that employ a
dial-back feature to a predefined phone number.

– 115 – ANSI/ISA–62443-2-1 (99.02.01)–2009
 Connecting industrial operation control devices or networks to the corporate LAN or WAN
and using smartcards or biometric authentication.
 Connecting home computers to industrial operation control devices or networks using a
VPN connection and two-factor authentication with a token and PIN.
ISA–TR99.01.02 [2] provides an explanation of these technologies and others. It also discusses
their strengths and weaknesses and applicability to the IACS environment.
Authentication for task-to-task communication

Task-to-task communications will not usually be monitored directly like user interactive sessions.
Authentication of task-to-task communications will typically happen at the startup of an industrial
operation and at regular intervals afterwards. Systems should employ some technical solution to
authenticate each device or network.

a) Establishing a strategy or approach that defines the method of authentication to be used. The
method may vary depending on the risks, the consequences associated with the business
process and the sensitivity of the data.
b) Employing different strategies for users connecting from different geographical locations
(including remote facilities) or for devices with special security requirements. This issue takes
into account the physical security characteristics that interact with the cyber security
characteristics to establish the overall security level for the user.
c) Authenticating all users prior to being allowed use of a particular application. This
requirement may be waived when there are compensating physical controls.
d) Requiring at least a manually entered user ID and password as the minimum level of
electronic authentication.
e) Authenticating task-to-task communication by knowing the MAC and/or IP address for the
device, a specific electronic key, the device name, and the like.
a) Authorizing users inside a locked facility that employs guards and badge -readers to access
systems having a greater level of risk than a remote user would be allowed.
 ISA–TR99.01.02, 5 [2]
 ISO/IEC 17799, Clauses 7 and 9 [14]
A.3.3.7 ELEMENT – Access Control: Authorization
For additional information about the overall topic of Access control, see the introductory material
in Annex A.3.3.5.1.
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 116 -
Figure A.12 – Access control: Authorization

Authorization, the third leg of access control is shown in Figure A.12, is the automated procedure
performed by the computer system to grant access to resources upon successful authentication
of the user and identification of their associated access account. The privileges granted are
determined by the access account configuration set up during the account administration step in
the procedure.
Some standard authorization procedures employed in the general IT work space may be
inappropriate or inadequate for IACS. For example, access accounts in a typical IT system are
primarily user-based with a limited number of roles assigned (that is, standard user or system
administrator). Each user is usually only assigned one role. Access accounts in a typical IACS
system will primarily be role-based with a greater granularity of roles (that is, operator, engineer,
application specialist, vendor, and system administrator). Users may be assigned multiple roles
based on a particular job function they need to perform at a particular time. The user may have
to login to a particular device and separately into an application to be authorized to make
changes to industrial automation control variables. Or, a user may have to log off a system and
re-login to perform system administration tasks on that same device.
This section explores the controls aimed at protecting information and assets from deliberate and
inadvertent destruction, change or disclosure. It focuses specifically on measures designed to
ensure that the authenticated agents (that is, personnel, applications, services, and devices)
have access to required information assets.
Information that is sensitive to disclosure needs to be properly protected both to maintain

competitive advantage and to protect employee privacy.
The authorization rules desired by an organization will determine how it assigns roles to specific
users or groups of users and how privileges for these access accounts are configured. The
capability to implement a desired authorization policy depends upon features in underlying
systems to distinguish the functions and data required for different job roles. Thus the definition
of an authorization policy is an iterative procedure where the organization defines an ideal policy
and then determines how closely that can be implemented using the capabilities of their systems
and network. If procuring a new system, support for a desired authorization policy can be an
element of the procurement specification. When designing a new network configuration,
technologies like firewalls for remote users can be added to create an additional layer of
authorization for critical devices, as described in the following paragraphs.
A.3.3.7.1 Considerations for authorization

When developing a program for access control, it is important to include all systems in scope,
and not just limit the effort to traditional computer room facilities.
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

– 117 – ANSI/ISA–62443-2-1 (99.02.01)–2009
Authorization security policy

Rules that define the privileges authorized under access accounts for personnel in
various job roles need to be defined in an authorization security policy that is cl early
documented and applied to all personnel upon authentication.
Logical and physical permission methods to access IACS devices

The permission to access IACS devices should be logical (rules that grant or deny access
to known users based on their roles), physical (locks, cameras and other controls that
restrict access to an active computer console) or both.
Access to information or systems via role-based accounts

Access accounts should be role based to manage access to appropriate information or
systems for that user’s role. Safety implications are a critical component of role definition.
Authorization for local users

Many process industries control their operations from control rooms staffed by several operators.
These operators often function as a team and perform actions on multiple HMI stations as part of
their normal job function. Authorization to perform specific job functions is provided by the
application. The local user is granted access to certain devices or operational displays based
upon a role-based access account. The actual login user ID and password are typically common
for everyone in the job role. This work-team approach to control room operation may conflict with
standard IT authorization policy and practice.
Safety implications must be considered when developing the authorization strategy. For high -
vulnerability industrial operations, authorization privileges should be set at the local process
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
control device level and should not require access to devices at the LAN or WAN level to assign
privileges. This supports the basic control principle of minimizing the potential points of failure.
Access accounts should be configured to grant the minimum privileges required for the job role.
Training needs to be employed to establish common levels of skills for each of the job roles.
Customizing individual access accounts to match skill levels of personnel should be avoided. All
users in the same job function should utilize access accounts configured for the same role.
Authorization for remote users

The authorization process discussed thus far places the authorization function at the end -node
device and application level. In critical control environments, an additional destination
authorization strategy should be employed at a barrier device (firewall o r router) for the IACS
network. Once a user is authenticated at the barrier device, role -based destination access rights
should be assigned to the user so that the user can only attempt to connect to pre -assigned
devices on the IACS network. The end-node login should establish the user’s final privileges for
performing functions on the device. Facilities with high -vulnerabilities should take advantage of
this additional level of destination authorization.
Role-based access accounts should take into account geographic location. A person may utilize
one access account when working on-site and a different one when dialing in from home to
assist local personnel. This practice should be clearly defined in the administrative procedures.
Compliance with administrative procedures should be based on individual accountability.

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 118 -

a) Permitting access to IACS devices with logical controls (rules that grant or deny access to
known users based on their roles), physical controls (locks, ca meras, and other controls that
restrict access to an active computer console) or both.
b) Logging and reviewing all access attempts to critical computer systems, both successful and
failed.
a) Protecting network connections between your organization and other organizations with a
managed firewall.
b) Using an authenticating proxy server for all outbound access to the Internet.
c) Granting access to a remote user by enabling a modem on an industrial operations control
device only when need.
d) Using ushered access when high-risk tasks are performed (for example, industrial operations
that have HSE consequences or critical business risks).
e) Segregating data with high sensitivity and/or business consequence from other internal
information so that existing authorization controls can restrict access to that information.
f) Separating the business network from the IACS network with an access control device and
limiting user access to critical assets on both sides.
 ISA–TR99.01.02, Clause 5 [2]
 SANS [34]
A.3.4 Element group: Implementation
The third element group in this category is Implementation. This element within this group
discusses issues related to implementing the CSMS. Figure A.13 shows a graphical
representation of the four elements in the element group:
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
 Risk management and implementation,
 System development and maintenance,
 Information and document management, and
 Incident planning and response.

– 119 – ANSI/ISA–62443-2-1 (99.02.01)–2009
Implementation
Risk System Information and

Incident planning
management and development and document
and response
implementation maintenance management
Figure A.13 – Graphical view of element group: Implementation

A.3.4.2 Element: Risk management and implementation
The foundation of any CSMS or security program is to maintain risk at an acceptable level. Risk
management and implementation addresses the selection, development and implementation of
security measures that are commensurate with the risks. The security measures may take into
account inherently safer industrial operation design, use of products with strong inherent security
capabilities, manual and procedural security countermeasures, and technology based
countermeasures to prevent or reduce security incidents .
Although risk will never be totally eliminated, it can be managed . This section describes a
framework to measure risk and then manage it through the implementation of various security
countermeasures to reduce the likelihood of an incident occurring or reduce the consequence of
the resulting event.
In most cases risk is measured in terms of cost and or social conscience. While it may be easy to
put a price on a production outage due to a cyber security incident, it is not possible to assign a n
exact cost to an event resulting in the injury or death of a person . Companies must determine
their risk tolerance to certain kinds of events and use this to drive the strategy for managing risk.
A.3.4.2.2 Building a risk management and implementation fram ework

Because the elimination of all risk is usually impractical or impossible, organizations should
focus on the most critical applications and infrastructures to decrease risk to an acceptable level .
Deciding what cyber security countermeasures to implement is a matter of balancing risk and
cost. Decisions should be based on a risk assessment and be documented to serve as a basis
for future planning and action.
Organizations should analyze the detailed risk assessment, identify the cost of mitigation for
each risk, compare the cost with the risk of occurrence and select those countermeasures where
cost is less than the potential risk. Because it may be impractical or impossible to eliminate all
risks, focus on mitigating the risk for the most critical applications and infrastructures first . The
same risks are often found at more than one location. It makes se nse to consider selecting a
standard set of countermeasures that may be applicable in more than one instance and then
defining when to use them. This approach will allow the organization to leverage common
solutions and reduce the design and implementation costs to improve the security posture of the
organization. One possible way to approach this is to develop an overall framework for
implementation that incorporates risk assessment, the organization’s tolerance for risk,
countermeasure assessment and selection and the strategy for implementing risk reduction
activities.
Each organization will likely have a different risk tolerance that will be influenced by regulations,
business drivers and core values. The organization’s risk tolerance for IACS incidents
determines the amount of effort an organization is willing to spend to reduce the level of risk to
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 120 -
an acceptable level. If the organization has a low risk tolerance it may be willing to commit a
greater amount of financial and/or personnel resources to the task of improving the security level
of the IACS.
Table A.2 identifies the organization’s sensitivity to different types of risk and aggregates the
various consequences into categories of high, medium, or low . When these categories of
consequences are combined with the likelihood of an incident occurring, as in Table A.1, the
result is a matrix of consequence category versus likelihood. In the absence of an analytical
method to quantitatively measure likelihood and consequence, it may be practical to simply
assign qualitative risk levels of low, medium and high to the points of intersection in the matrix .
These risk levels reflect the organization’s sensitivity to risk, as shown in Table A.3. These risk
levels imply thresholds of tolerance which will drive the risk reduction implementation strategy.
This is a clear way to communicate the organization’s position on risk .
The risk reduction strategy may employ different countermeasures, architecture practices, IACS
device selection and the decisions of when and where to employ them based upon the risk level
shown in Table A.3. Systems with a high risk warrant employing more extensive
countermeasures to achieve a higher level of security.
One way to capture the organization’s decisions on countermeasure selection is to develop a

chart listing specific countermeasures to be used for IACS devices based upon the risk -level of
the IACS. An example of a possible countermeasure chart is show in Table A.4.
The table defines the common solution set of countermeasures to be employed to try to reach
the target security level. These countermeasures are to be employed unless there is some
unique constraint that makes this solution undesirable for a given IACS. The organization’s risk
reduction strategy may also use the risk -level ratings to establish priorities and timing for
implementing the identified countermeasures shown in Table A.4. IACS with high-risk ratings
should probably be addressed with greater urgency than lower risk IACS.
The countermeasures to address a specific risk may be different for different kinds of systems.
For example, user authentication controls fo r an advanced application control server associated
with a DCS may be different than the authentication controls for the HMI on the packaging line.
Formally documenting and communicating the selected countermeasures, along with the
application guidance for using the countermeasures, is a good strategy to follow.
Table A.4 – Example countermeasures and practices based on IACS risk levels
Countermeasure and architecture practices High-risk IACS Medium-risk IACS Low-risk IACS
Two-factor authentication to control access to Required Required Optional
the device
Hardening of the operating system Required Recommended Optional
Employ network segmentation Required Required Optional
Employ antivirus application Required Required Required
Use of WLAN Not allowed May be allowed Allowed
Strong password authentication at the Required Recommended Recommended
application level
Other countermeasures, etc. Etc. Etc. Etc.
There are many different information technology risk mitigation countermeas ures that can and
should be applied to IACS devices. Guidance on specific countermeasures is addressed in other
documents, like ISA–d99.03.01 [4] and ANSI/ISA–99.01.01-2007 [5], which provide a much more
in depth look at different countermeasures available and their application to the IACS
environment.
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

– 121 – ANSI/ISA–62443-2-1 (99.02.01)–2009
Most organizations will have a limited set of financial and personnel resources to apply to CSMS
activities. As a result, it is important to use these resources in a manner that yields the greatest
returns. A risk management framework begins with understanding vulnerabilities that exist within
the IACS and the potential consequence that could occur should that vulnerability be exploited .
Once risks are understood, the company needs to develop an implementation framework to
reduce risk or keep it at an acceptable level. Several of the security models discussed in
ANSI/ISA–99.01.01–2007 [1] will be used in creating the implementation framework. The models
include the Security Level Model along with the Zone and Conduit Model.
NOTE This section of the document will discuss one possible way to approach this key CSMS element using the
ANSI/ISA–99.01.01–2007 [1] security models. There is no one right approach to this element. Alternate approaches
can result in a very functional framework to manage risk .
The detailed discussion and example that follows on the topic of Risk Management and Implementation will describe
the framework process as it is applied to reduce cyber security risks to an existing system in a single industrial
operating area. The framework is equally applicable to many new IACS in multiple locations around the world.
No matter what detailed risk management and implementation approach is employed, a good
quality framework must address four main sets of tasks over the life of an IACS. They are
covered in detail in Annex A.3.4.2.3 through Annex A.3.4.2.5.
 Assess the risk of the IACS.

 Develop and implement countermeasures.
 Document countermeasures and residual risk.
 Manage residual risk over the life of the IACS.
These tasks are graphically represented in the security lifecycle models discussed in ANSI/ISA–
99.01.01–2007 [1].
A.3.4.2.3 Assess the risk of the IACS to determine the IACS cyber security risk level
The zone and conduit model, security level lifecycle model, and reference mod el are described in
detail in ANSI/ISA–99.01.01–2007 [1]. The use and integration of these models will be discussed
in this section of the document.
A.2.3 provides guidance on a procedure to follow to analyze the risk of the IACS. This is one of
the earliest activities in the assess phase of the security level lifecycle model. An organization
needs to develop and document a risk analysis process so that it can be used on multiple IACS
at different locations throughout the organization with repeatable results.
This section explains how the assess phase fits into the overall risk management strategy. This
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
is illustrated by walking through the scenario of examining an existing IACS and improving the
cyber security position of this system to reduce risk. Figure A.14 shows the Assess phase of the
Security level lifecycle model.

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 122 -
Address security
of IACS
Are zones
No established for the
IACS?
Yes
Assess Is SL(target)
consequence/risk known for the zone Yes
of the process and conduit?
No
Establish IACS Select appropriate

Assess company’s
zones and SL(target) for the
risk tolerance
conduits zone and conduit
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
Review the degree SL(target) goal for

Reassess SL(target) of security zone and conduit
of IACS protection offered
by each SL
To develop and
From maintain phase
implement phase
Vendor and
Vendor task User task
user task
Legend
Figure A.14 – Security level lifecycle model: Assess phase

For an existing IACS that has never undergone a risk assessment and has not yet employed the
Zone model, the activity begins with the box labeled “Assess consequence/risk of the process.”
The purpose of the assessment is to understand the risk impact to the business in the event the
IACS is compromised by a cyber incident and is not able to perform its intended control functions
or performs unintended functions. Once the risk associated with the IACS has been documented
the activities associated with managing and mitigating the risk should be performed.

– 123 – ANSI/ISA–62443-2-1 (99.02.01)–2009
The output of the risk analysis will be a table listing th e consequence rating and likelihood rating
for each IACS asset or some collection of assets. Table A.5 is an example output of a detailed
risk assessment and results from combining Table A.1, Table A.2, and Table A.3. The likelihood
rating is assigned based upon the detailed vulnerability assessment of each of the assets listed,
and the likelihood of related threats being realized.
Table A.5 – Example IACS asset table with assessment results

IACS device asset Consequence Likelihood rating
rating
Operator control room console A Medium
Remote operator console C High
Engineering configuration station A High
Historian server B Medium
Controller A Medium
Gateway B Medium
Other devices, etc. C Low
A.3.4.2.3.1 Determine the IACS risk level

Table A.3 is a simplified example model for translating a c ompany’s sensitivity to risk into
qualitative levels of risk for the IACS. It should be prepared by the organization’s responsible
leadership before the risk analysis is conducted.
The intersection of the Consequence and the Likelihood ratings yields the R isk Level. For
example an IACS device with a Consequence rating of B and a Likelihood of High would
represent a High-risk device.
The risk postures in Table A.3 can be applied to the IACS device assets in Table A.5 resulting in
an overall rating for the IACS as shown in Table A.6. This table provides a priority ordering for
particular vulnerabilities.
Each device has a cyber security risk level associated with it. In a tightly integrated IACS, the
control functions provided by each device are highly dependent upon the integrity of the other
devices in the IACS. The functional integrity of the control system will be impacted by the
integrity of the weakest device.
A simplifying security assumption is that the device with the highest IACS risk level establishes
the inherent risk level for the entire IACS. In the example IACS listed in Table A.6, the inherent
risk level for the IACS is High-risk because several of the IACS devices have a risk level
identified as High-risk.
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 124 -
Table A.6 – Example IACS asset table with assessment results and risk levels
IACS device asset Consequence rating Likelihood rating IACS device risk
level
Operator control room console A Medium High-risk
Remote operator console C High Medium-risk
Engineering configuration station A High High-risk
Historian server B Medium Medium-risk
Controller A Medium High-risk
Gateway B Medium Medium-risk
Other devices, etc. C Low Low-risk
Understanding this base inherent risk level is a key to carrying out a risk management plan. It
establishes the target security level needed to reduce risk. This establishes the justification for
implementing a risk reduction and management plan, if the IACS is not already operating at that
target level. Various security countermeasures will be employed to reduce the risk to the IACS to
a tolerable level. However, a failure of these countermeasures to mitigate the risk could result in
an incident with a consequence of the magnitude identified during the risk analysis task.
A.3.4.2.3.2 Establish security zones and associate IACS devices to the zones
The reference model, discussed in ANSI/ISA–99.01.01–2007 [1], identifies several different
operational/equipment levels of an IACS. Although there may be different operational levels
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
within an IACS, the cyber security requirements may be similar for several of these
operational/equipment levels. It may be possible to incorporate several operational/equipment
levels into a single logical security zone.
The security level model introduces the concept of employing zones assigned to one of three or
more security levels. For illustration purposes in this example, assume there are three security
levels qualitatively described as Low, Medium , and High. The task at hand is to examine the
security needs of the various IACS device assets and assign them to these different zones.
Table A.6 lists the IACS cyber security risk level for each of the assets. Assets with a High-risk
level share a need for a high level of cyber protection to reduce risk. These assets should be
assigned to a common security zone. Assets with lower risk levels should be assigned to a lower
security zone. At this point in the risk management process , it is appropriate to superimpose the
identified security zones onto the system physical network diagram developed for conducting the
risk analysis.
Given today’s security countermeasure technologies, security zones will typically align with
physical network segments. An IACS device may not be currently located on the proper network
segment based upon the risk analysis results for that device. If this is the case, the device may
need to be relocated to a different network segment. An asset with a Low-risk level may be
assigned to a higher risk security zone, but assets with a High-risk level should not be placed
into a lower risk security zone. To do so would raise the risk of an unacceptable conse quence in
the event of a cyber security incident.
During the implementation phase of the security level lifecycle model, the devices with security
needs that do not match with the zone the devices are physically located in should be relocated
to the appropriate network segments to meet the security requirements .

– 125 – ANSI/ISA–62443-2-1 (99.02.01)–2009
Figure A.15 – Corporate security zone template architecture

An organization may choose to establish a common approach to security zones in an effort to
improve the efficiency of managing risk. One way to do this is to adopt a corporate template
architecture incorporating network segmentation strategies and security zones for the various
kinds of devices and systems employed in the enterprise . Figure A.15 shows an example of a
security zone template architecture for an organization. Figure A.16 shows how the IACS assets
in the example are mapped to the zones in the template architecture that employs a three tier
zone approach.
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 126 -
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
Figure A.16 – Security zones for an example IACS

Table A.7 – Target security levels for an example IACS
Zone Target security level = SL(target)
Plant A control zone High
Plant A DMZ Medium
Plant A LAN zone Low
Enterprise zone Low

– 127 – ANSI/ISA–62443-2-1 (99.02.01)–2009
A.3.4.2.3.3 Determine the target security level

The security level model introduces the concept of assigning a security level to the zone. In the
example shown in Figure A.16, the inherent risk level of the IACS was determined to be High-risk
based upon the detailed risk assessment of each IACS device . Extra security countermeasures
need to be employed to protect the devices falling within the Plant A control zone. Using the
security levels listed in Table 8 of ANSI/ISA–99.01.01–2007, it is appropriate to assign a target
security level to each of the zones, as seen in Table A.7.
A.3.4.2.3.4 Selecting devices and a system design based upon SL(capability)

The security level capability of each device must be examined to understand the security
strengths and vulnerabilities it introduces to the zone . Although the SL(capability) cannot be
quantitatively measured at this point in time, there are some more qualitative means to assess
the relative SL(capability) of the devices comprising the IACS. These assessment items are
typically covered as part of a detailed vulnerability assessment. For example:
 If the device is a web server, run an assessment tool to identify weaknesses of web
server applications and determine if the weaknesses can be remediated
 Run an assessment tool to identify the number of services and ports required for the
application to function on the device
 Examine the required ports and services to determine if these have been historically us ed
by attackers to exploit system vulnerabilities
 Examine the operating system of the device and determine if security patches and
upgrades are still being supplied for the version in use
 Run an assessment tool to subject the application to unusual inputs to determine if the
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
device and application will continue to function under abnormal communication streams
 Examine the exploit history of the underlying technologies used in the device to ascertain
the likelihood for future exploits
The organization should have some acceptance criteria for a device to be used in a particular
target security level based upon the results of these assessment tools and identified
weaknesses. If the SL(capability) of the device is simply too low to achieve the SL( target) for the
zone, an alternate device may need to be selected. For an existing IACS comprised of older
generation devices, it may be necessary to replace the device with a newer generation device
with improved SL(capability). An example of this might be a PC-based operator control station
running on Microsoft Windows® NT as its operating system. The detailed vulnerability
assessment results for this device and application may show significant vulnerabilities. The
security features built into this older operating system are less than in many of the newer
generation operating systems and security patches to address these vulnerabilities are no longer
being supplied by the vendor. This leaves the device in a relatively weak position with respect to
its SL(capability).
The SL(capability) of each new IACS device should be examined to ensure that it supports the
goal SL(target) for the zone. Although quantitative measurements of SL(capability) may not be
available and/or published, vendors may be able to provide some more qual itative measures
based upon assessments they or third-parties have conducted using standard security tools and
field trials. These detailed vulnerability assessment results should be considered and used in the
decision process for selecting IACS devices.
The preliminary design identifying IACS devices and zone assignments must be transformed into
a detailed design identifying all equipment and network segments to be employed in the IACS.
This is the time to relocate devices whose security risk needs do not align with the SL(target) for

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 128 -
the zone. The output of this step should be a detailed network diagram locating all IACS and
network devices that will be a part of the overall IACS.
A.3.4.2.4 Develop and implement the selected countermeasures for each zone
The Security level lifecycle model – Develop and implement phase addresses the steps and
tasks to reduce risk. The overall concept of this phase is to employ countermeasures to an IACS
to achieve the target security level for the zone established during the assess phase. Figure A.17
addresses several different starting points . It applies to implementing a brand new IACS, making
changes to an existing IACS in the form of new equipment, and improving the security of existing
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
IACS. The figure is a frame of reference to guide thinking rather than a detailed flow diagram or
checklist of steps that must be followed.

– 129 – ANSI/ISA–62443-2-1 (99.02.01)–2009
New IACS
From assess phase
Change to IACS
Change to SL(target)
Is this a new
or existing Existing
Design IACS to IACS?
meet SL(target)
New
Factory
acceptance test
Select devices
IACS using the
based on
security assurance
SL(capability)
properties for the
SL level
Develop integrated Validate system Install new IACS

design SL(capability) devices in the field
Test integrated
Install IACS in the IACS for the
field security assurance
properties
Factor in the
SL(achieved)t0 for security assurance
the zone and implications
Is SL(achieved)
To maintain phase conduit Yes associated with
acceptable?
the security
measures in place
in the field
Note: t0 = at time 0
No
Implement
additional
Determine the
compensating
SL(achieved)
Vendor and security measures
Vendor task User task or accept risk
user task
Legend
Figure A.17 – Security level lifecycle model: Develop and implement phase
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 130 -
The beginning point of this phase is the security goal to be achieved. This is expressed as the
security level target for each zone of the IACS. Under the Assess phase these targets were
established and preliminary zone assignments made for each of the IACS devices . The task at
hand is to take this preliminary approach and create a detailed design for implementation .
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
A.3.4.2.4.1 Offline security testing
Just as functional testing of an IACS is critical to implementing an IACS so that it will meet the
needs of the operating facility, security testing of the devices is also important to mak e sure the
operational integrity and robustness will be achieved . A.3.4.3 provides more detailed information
on performing security testing.
If the IACS is a new system, security testing should be conducted while the system is in an
offline environment. This could be a factory acceptance test at the vendor ’s location or an offline
staging step at the final field location. The location is not as important as making sure the
security testing steps are undertaken. While it would be very valuable to security test all devices
and countermeasures employed in the final installed state, this may not be affordable and
practical. So the testing design should focus more on the SL( capability) of the IACS devices and
the countermeasures that are not specific to the installed field location.
The preceding section noted several tools and items for consideration for testing SL( capability).
These items are typically covered as part of a detailed vulnerability assessment. Security testing
should include not only tests to assess the ability to resist typical security threats encountered
under operating conditions, but should also include the measures that will be part of ongoing
system security support. These include but are not limited to:
 Testing the patching process for operating system patches and upgrades
 Testing the patching and upgrade process for IACS vendor updates
 Testing the offline system development environment
 Testing deployment of antivirus software and malware signature updates
The overall goal of the security testing activities shown in the middle of Figure A.17 is to validate
that the SL(capability) of the devices aligns with the design basis.
A.3.4.2.4.2 Field security testing

The items shown on the right side of Figure A.17 identify the testing activities associated with the
final destination environment. This is the point where all the employed countermeasures are
tested and/or examined to determine if the achieved security level equals or exceeds the target
security level design basis for the zone.
If this is a new IACS being installed it is probably possible to conduct these tests before the
IACS is placed online. If the activity is to retrofit and replace an existing IACS device or
implement some new security countermeasures to the IACS, it may not be possible to obtain a
window of opportunity to do full offline field security testing . Instead the challenge is often
implementing the new device or countermeasure and field testing that the basic operating
function of the IACS has not been unacceptably impacted by the security measures.
It is important to keep in mind that system performance testing should include system response
to normal and abnormal industrial operating type events as well as normal and abnormal security
incident type events. These combine to yield an overall measure of the robustness and integrity
of the system.
Because each industrial operation is slightly different, it is not possible to identify a cookbook
type procedure for this testing. It will require considerable design work to determine the best way

– 131 – ANSI/ISA–62443-2-1 (99.02.01)–2009
to assurance test that the security functions are meeting the security objectives to achieve the
Target Security Level.
A.3.4.2.4.3 Meeting the target security level

Achievement of the target security level in the field may require some degree of iteration. The
field is not a perfect world. Typically it is appropriate to try to apply a common set of
countermeasures to all the devices within the zone t o achieve the desired security level. A
selected countermeasure identified for implementation on all devices may not be useable on a
particular device because of an operational or physical constraint not initially recognized during
system security design. Therefore it is important to recognize that real world situations may
require the elimination of, as well as the addition of, countermeasures for individual devices
within a zone to achieve the proper balance of security benefit versus risk so that all par ties
involved with the decision process are satisfied.
A.3.4.2.4.4 Illustrating the design process using the IACS example

The previous sections discussed the principles regarding implementing security
countermeasures to meet the SL(target) for the zone. This subsection will describe the design
process of applying these principles to a real world example.
Table A.6 identified a historian server with a device risk level of Medium . Using the corporate
template security architecture, this device was identified as needing to be located in a security
zone with a SL(target) of medium or higher. The Plant A DMZ was identified as the appropriate
zone for this device even though the device is currently located on the Plant A LAN zone.
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
In preparation for physical implementation of the Plant A DMZ, the SL( capability) of the historian
server is examined to determine if it meets the SL( target). Examination of the vulnerabilities from
performing a detailed vulnerability assessment reveals that:
 The operating system for the server is Microsoft Windows® NT for which security updates
is not available
 No antivirus application is running on the server . The vendor of the historian application
has not qualified any antivirus software products as compatible with the h istorian
application
 The majority of the users of the historian application are located in office areas with PC
connections to the lower security Plant A LAN zone
 Efforts to harden the server by shutting down non -needed tasks were not successful
because the historian application vendor would not certify that the application would run
properly if the services were shutdown
The conclusion is that the inherent SL(capability) of the historian server is inconsistent with the
SL(target) for the Plant A DMZ.
Since the inherent SL(capability) is too low, the use of additional supplementary
countermeasures are examined to determine if they can successfully reduce risk to meet the
SL(target). Additional countermeasures such as eliminating Internet access, eliminating email,
disabling media ports on the server, employing strong passwords are examined . Although these
can contribute to risk reduction, it is felt that employment of these additional security practices
would not compensate for the low inherent SL(capability) of the historian server.
Since the historian server directly interfaces to the IACS gateway of the regulatory control
network, the security weaknesses of this device also lowers the SL( achieved) of the Plant A
control zone. The conclusion is that the best way to address these unacceptable SL( achieved)
states of both the Plant A DMZ and the Plant A control zone is to replace the present historian

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 132 -
server with a newer historian software application running on a currently supported operating
system. After examining the SL(capability) of the newer server and historian application to
ensure it aligns with the SL(target), the server and application are tested and implemented in the
Plant A DMZ during an industrial operation shutdown.
There are a couple of important points worth highlighting in association with this example . The
SL(achieved) of a zone is dependent on the SL(capability) of the devices in the zone but also the
connectivity within and between zones . A vulnerability analysis for a device considers not o nly
inherent properties of the device considered in isolation, but also the connectivity of this device
in the network. This is important because an IACS that uses only devices that have High
SL(capability) when considered in isolation, may not together ne cessarily achieve the desired
high SL(target) for a zone. For example a new IACS device employing a new operating system,
even if fully patched and running antivirus software, has a lower SL( achieved) when directly
connected to the corporate IT network . Conversely, if one limits physical access and network
connectivity to a zone, devices of lower SL( capability) might together achieve a higher
SL(achieved) for the zone.
The security of the conduit between zones can also impact the SL( achieved) of the zone. For
example, a conduit using a wireless communications link rather than a physical cable may have
a different SL(achieved) for the conduit and have an impact on the SL( achieved) of the zones
joined by the conduit.
Similarly the SL(achieved) of the zone in consideration may be impacted by the security level of
the zone connecting to the zone in consideration. In the example, the users of the historian
application are in a zone with a lower security level than the historian server. Even if the
SL(achieved) of the conduit between these zones is High, the lower SL(achieved) of the Plant A
LAN zone can potentially negatively impact the SL(achieved) of the Plant A DMZ.
A.3.4.2.5 Maintain the security levels for each zone

The level of security of a device is constantly eroding. New security vulnerabilities are
discovered nearly every week. During the period of time that vulnerability exploits are known and
unmitigated, the IACS may be at risk and the SL( achieved) of the zone is potentially lower than
the SL(target). This real-world situation must be addressed with a plan to maintain the security
level of the zone to an acceptable security level.
The Security lifecycle model – Maintain phase, shown in Figure A.18, depicts the cyclical set of
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
activities that are critical to sustaining the security of the zone . The triggers to initiating the
reassessment of risk include but are not limited to:
 A change to the physical industrial operation or changes to the IACS which could
introduce new risks
 A new vulnerability discovered in a software module used in the IACS
 The release of a new operating system or application patch which triggers the deployment
of exploit code to the Internet
 Scheduled periodic security audits and reviews
A.3.4.2.5.1 Patching IACS Devices
Figure A.18 offers a high-level overview of how patching fits into the maintain phase of the
security level lifecycle model. This section is not meant to be a comprehensive discussion of all
the aspects associated with patching. The goal is to depict the iterative aspect of examining the
SL(achieved) state of the zone and the need to make solid decisions about what patches to
apply and when to apply them.

– 133 – ANSI/ISA–62443-2-1 (99.02.01)–2009
Vendors of IACS devices and applications share responsibility with users for addressing security
risks. Users count on the vendors to understand the inner workings of their IACS applications, to
determine the applicability of the patch and to perform thorough automated regression testing for
compatibility of the IACS application with operating system patches and major revision updates.
Since installing patches has the potential to interfere with the normal operation of the IACS
software application, users need as much assurance as possible that the installation of the
revised software will not result in a failure of the control device.
As Figure A.18 indicates, vendor compatibility testing is the first step in a multiphase testing plan
before widespread patching is conducted on the running IACS . Additional testing should be
conducted with the target environment of the device . Ideally this would be performed on an
offline device identical to the live IACS. If this is not possible, alternate approaches should be
considered which could include testing in a virtual enviro nment or in a very controlled
deployment to the live IACS.
Armed with vulnerability information from the operating system vendor, patch applicability
information from the IACS vendor, compatibility information from the IACS vendor, knowledge of
the use of the IACS device and finally user testing, the user must make a decision on field
deployment of the patch.
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 134 -
From develop and

implement phase
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
Process change Conduct
Examine impact, Is actual Record
security review
determine SL(achieved) Yes SL(achieved)tn
to assess
SL(achieved)tn+1 acceptable? +1
New vulnerability vulnerabilities
detected Note: tn = at some No
later time other
Scheduled periodic than at time 0.
security review Is there a patch
addressing the No
vulnerability?
MS issues OS
patches and
updates
Yes
Review vendor
assessment of Deploy patches
and updates in New
OS patches
Vendor tests controlled manner SL(achieved)tn
and updates
OS patches to minimize for the zone
and updates potential of and conduit
Vendor
for functional Test OS common mode
publishes
compatibility patches and failure
results
and security updates and
assurance application
properties fixes in off-line
Determine
environment
SL(achieved)tn
Vendor Compatibility +1
develops and
application SL(capability)
fixes as impact
necessary Implement
Is actual
additional
No SL(achieved) No
security
acceptable?
measures
Vendor
application Yes
Accept the risk
fixes
and document
SL(achieved)tn
Vendor To assess phase

Vendor
and user User task
task
task
Legend
Figure A.18 – Security level lifecycle model: Maintain phase

A.3.4.2.5.2 Employing additional countermeasures
It may be necessary to employ additional countermeasures to address unmitigated vulnerabilities
from patches or vulnerabilities introduced by changes to the industrial operation. This is
determined by assessing the SL(achieved) and comparing this to the SL(target) for the zone. As
was noted in earlier discussions, this is rather subjective rather than being easily measured in
good quantitative terms.

– 135 – ANSI/ISA–62443-2-1 (99.02.01)–2009
In some cases the business risk of taking action to raise SL( achieved) may be cost prohibitive in
the short or long term. In this case, the technical decision makers should document:
 The risks
 The countermeasures employed
 The countermeasures considered, rejected, and reasons why
 The recommendation to business leaders to accept the risk for some period of time until a
more acceptable countermeasure or security solution can be identified, tested , and
implemented
Business leaders should formally signoff to document acceptance of this strategy .
A.3.4.2.5.3 Scheduled security reviews

A comprehensive CSMS includes a conformance element that should include a periodic
assessment that the security practices and countermeasures as identified in the corporate
security policy and standards are being employed and are effective in reducing risk to achieve
the SL(target) level. This is another trigger to the Security level lifecycle model – Maintain phase.
A security audit may measure the degree of conformance to the defined policies and standards
and result in metrics that are valuable to sustaining security. However, in addition to verifying
alignment with the required practices, an organization should periodically (and based on triggers
as shown in Figure A.18), assess whether the SL(achieved) meets or exceeds the SL(target) in
its IACS zones

a) Defining and validating security policies. Detailed security policy statements define the
operational level commitment to mitigate each of the security risks during the risk
assessment.
b) Developing procedures that provide details, like actions to take for preve nting, detecting, and
responding to threats.
c) Adapting standards from international organizations in the area of cyber security for use in
the organization’s IACS environment.
d) Developing services such as secure OS images and common applications for secure IACS
use.
e) Identifying security tools and products to implement parts of the security policy. While
security tools and products, like firewalls and VPNs, may be used in the IT and IACS
environments, the rule sets and application of these types of tools and products may be
significantly different due to the different risks associated with the environments.
f) Establishing a formal methodology for accepting risk, including the appropriate management
level approval based on scope and documentation.
g) Implementing policies, procedures, tools, and the like, in a manner that minimizes
administrative overhead and burden on the end-user without compromising effectiveness.
Well-designed controls often leave behind their own audit trail that can be used for
verification later.
h) Documenting the reasons for selecting or not selecting certain security countermeasures and
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
the risks they address in a Statement of Applicability (SoA). Good documentation on security
mitigation controls aids in the decision making process, facilitate s the communication of the

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 136 -
decisions, provides a basis for training people to respond to incidents and threats and
provides a basis for self-assessments or audits of the conformance to the countermeasures.
See ISA–d99.03.01 [4] and ISA–TR99.01.02 [2] for related practices.
NOTE The authors of this standard realize that there are many different types of countermeasures available. They
also realize that to include a list of different types of countermeasures here would either provide the reader with too
much information to digest or not provide enough detail for the reader to accurately apply the controls to IACS. The
authors therefore have chosen to defer the discussion of additi onal IACS security practices related to countermeasures
to other documents, which can provide the reader with a much more in-depth look at the different types of
countermeasures available and how to apply them correctly to the IACS environment.

 ISO/IEC 17799 [14]
 ISO/IEC 27001, Clause 4.2.2 [15]
 ChemITC Reference Model [19]
 ChemITC Report on Self-Assessment [20]
 U.S. Chemical Sector Cyber Security Strategy, 4.5.3 [21]
 Understanding ISO 17799 [22]
 NIST SP 800-30, Section 4 [24]
A.3.4.3 Element: System development and maintenance
This element addresses supporting methods necessary to develop and maintain the IACS
information technology systems that impact and are impacted by the CSMS. It discusses the
cyber security aspects of: requirements documentation, design, procurement, testing, change
management, patch management, and backup and recovery processes.
The key point of this element is to give insight about how to implement these methods in a cyber
security aware manner. The approaches aim is not to reproduce documentation describing the
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
fundamentals of these methods but to explain how security issues are inherent in system
development and maintenance processes. Security issues must be addressed throughout the
normal course of all System Development and Maintenance processes.
A.3.4.3.2 Requirements documentation

Annex A.3.4.2 introduces the concept of a target security level. The term ‘requirements’ refers to
capabilities and/or characteristics of a given sys tem or device. Requirements may refer to many
characteristics in many contexts: systems or software, product or industrial operation, functional
or non-functional requirements. However, for the purpose of this element, we need to define
‘System requirements’ as the attributes of the target security level and ‘Device requirements’ as
the countermeasure characteristics necessary for the devices within the zone to achieve the
desired target security level. Because the system requirements define the target security level,
they must be determined in the Risk management and implementation phase. These system
requirements are often referred to as high-level requirements. The device requirements may
change depending on the results of the design phase.
For example, a system requirement for the control zone might be to limit all network traffic to
authentic control and automation traffic. A device requirement for a control operator console
might be to disable all unused networking and communications protocols . In this case, that

– 137 – ANSI/ISA–62443-2-1 (99.02.01)–2009
device requirement might only partially achieve the system level requirement. It may be
necessary to have multiple device requirements to meet the system requireme nts.
The detailed, verifiable, set of system and device requirements is the foundation for the testing
methods and for the verification and validation design, procurement, change management and
patch management processes. It is extremely difficult to tell if design, procurement, system
changes, or patches violate the Target Security Lev el if the specific capabilities necessary to
achieve at that level are not defined.
A.3.4.3.3 Design
Cyber security should be built into the IACS during the design process. This objective should be
considered during system procurement and development as well as duri ng maintenance of the
system. Numerous documents exist that discuss sound system design processes. This standard
does not attempt to cover this subject. But it is worth emphasizing that a critical aspect of the
design process is that specific countermeasur es should be mapped to each of the system
requirements in order to verify that the devices and the system as a whole satisfies the target
security level.
The design process not only covers the preparation of the project specification but also planning
the verification approach and initial verification that the project meets the stated requirements.
The initial verification may be performed through a paper analysis. The final verification is
performed through testing of the system.
It is important to realize that new projects are continually being initiated and executed. To avoid
the potential for rework when these projects are installed and go on -line, the operations and
engineering groups responsible for executing projects need to be aware of any applicable
industry-specific cyber security standards and corporate cyber security policies and procedures .
A.3.4.3.4 Procurement
The procurement process is particularly important in attaining the des ired target security level.
While specifying new or updated equipment to a vendor, it is important to include requirements
for cyber security. If there are specific device requirements that are required to meet the system
requirements, then these need to be explicitly declared in the procurement process for those
devices. It may also be necessary to specify any device requirements for things that the vendor
or integrator should not do. There are some practices that are common for device vendors or
integrators to do on their devices that may lead to unnecessary security holes that w ould prevent
the system from reaching the target security level. For example, vendors historically placed
back-doors into their products in order to facilitate trouble-shooting and improve customer
service response times. These back-doors are a vulnerability that an attacker could exploit. A
sales representative may not even be aware of these back-doors and such trouble-shooting
points should not be allowed unless they are explicitly included in the procurement requirements.
The topic of procurement language for cyber security is too large for this standard. Other groups
have been developing this language and may be able to provide more information. [49]
A.3.4.3.5 Testing
The purpose of a testing program is to assure that the system meets the stated requirements for
the project. For a well-designed system, it should be designed to meet both the operational and
security requirements. One of the earlier decisions to be made when developing a testing
program is what level of assurance the organization requires from its vendors and integrators
about the cyber security of the devices or systems. The level of assurance required for a
particular device or system will determine the type of testing required. A vendor may have a
recommended testing strategy for a particular device or system, but the user will need to
determine whether that testing strategy is sufficient to validate their security requirements.

--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 138 -
Ideally, a system would be tested under all possible states to ensure that every security
contingency is met or at least so that the residual risk is known. While complete system testing is
theoretically possible, it is unobtainable for most specifications given financial and personnel
constraints. Therefore, the challenge is to determine an accep table level of risk and then perform
a sufficient level of testing commensurate with the acceptable risk.
After the initial test planning, written test plans and procedures should be prepared for each
testing stage. These should define the tests to be performed and the expected results. They
should include system configuration, system inputs and outputs and tolerable error bands.
During testing, it is important to at least do a cursory check of the results to verify that they are
as expected or determine if corrective action needs to be taken. After each stage of the testing is
completed, the results should be evaluated. Following the system validation test, a final report
should be prepared reviewing the results of all of the testing and summarizing the con clusions.
A.3.4.3.5.1 Types of testing

Cyber security testing, like other testing in other domains, includes verification and validation
testing. According to the Capability Maturity Model [30], “Verification confirms that work products
properly reflect the requirements specified for them. In other words, verification ensures that ‘you
built it right‘. Validation confirms that the product, as provided, will fulfill its intended use. In other
words, validation ensures that ‘you built the ri ght thing’”. To summarize this, verification
determines if the implementation satisfies the specification, while validation determines if the
specification satisfies the requirement.
The specific testing performed will depend on the level of testing requir ed, the component or
system being tested and the type of testing required for the system or component. Cyber security
testing is typically performed in three stages: component testing, integration testing, and system
testing. Verification testing must be implemented during the component and integration stages ,
although validation testing may also be useful. Both verification and validation testing must be
implemented at the system testing stage.
A.3.4.3.5.2 Component testing

Component testing should be performed by the vendor and verified by the system owner. The
component may be software, hardware, firmware or a ny combination of these. The component
needs to be tested to verify that it meets the specific operational and security requirements.
Component testing is normally workbench testing and is necessary to ensure that, when the
components are combined into a system, there is confidence that each individual component
performs as intended.
A.3.4.3.5.3 Integration testing

Integration testing should be performed by the integrator an d verified by the system owner. Such
testing involves operational and security testing of the various components perhaps from
different vendors, that are connected together on a workbench or in an auxiliary test bed in an
effort to see if all of the components will work together correctly before being placed in the IACS
environment. Integration testing may involve using additional test tools, like network
management and administration tools, which were not necessary during the component testing
phase.
Rarely will a test bed have the exact configuration of the control system that exists in the
operating facility. Often a simplified or replica system in a development or laboratory setup is
best suited for the component and integration test phases. The integrat ion tests should be
designed around this testbed facility. Care should be taken to note differences between the
integration test setup and the IACS environment as well as any additional tools needed so that
items that could not be fully tested during integration testing are tested during system testing.
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

– 139 – ANSI/ISA–62443-2-1 (99.02.01)–2009
For this reason, it may be helpful, especially during the integration test phase, to locate the
simplified or replica system near the site of a n operational system.
In some instances, it is possible to perform a non-production integration test to see how security
countermeasures will work together and how they will interface with the operational features. For
example, security countermeasures that consist of discrete hardware/software may be connected
via a laboratory test bed network. In other cases, this integration may not be possible. The
integration test plan should take advantage of any test bed scheme that can be configured to test
combinations of operating conditions that may be present in the operational system.
A.3.4.3.5.4 System testing

System testing should be verified and validated by the owner. The objective of validation testing
is to demonstrate through appropriate techniques, procedures, and procedure refinements (as
needed) that the management, operational and technical countermeasures for the IACS are
implemented correctly, are effective in their application, and ensure that the new security
countermeasures, as procured and installed, meet the requirements.
System testing may include penetration testing of the system to ensure that the security
components are capable of protecting the system from various threats as necessary to satisfy
the security level for each zone. Penetration testing is where a known person tries to penetrate
the security defenses in a system, looking for weaknesses and vulnerabilities that can be
exploited to gain either access or control over that system. Many companies specialize in
penetration testing for traditional IT systems. It may be more difficult to find a group that
understands the special requirements of IACS.
A variety of testing tools such as test scripts, databases of variables, baseline configuration s
with an assumed start state, metrics and calibration tools are available to assist with the actual
testing. Commercial and freeware tools that are preconfigured to perform diagnostic routines and
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
simulate gateways and connected devices are also available.
If any penetration tests are conducted, the performance of the system during the tests needs to
be noted in addition to the penetration testing results. There will most likely be some
performance degradation in the system or components due to the penetration testing. These
performance degradations should be noted for future use.
It is important to emphasize that security c ountermeasures may also involve people operating
through policies and procedures, as well as manual checks of security. A countermeasure, for
instance, may consist of a control engineer installing a security patch issued for hardware or
software. The test plan might go through the sequence of a dry-run of the patch installation,
noting other factors it influences.
A.3.4.3.5.5 Separation of development and test environments

Development and test activities can cause serious problems, such as unwanted modification of
files or system environment or even system failure. It is important to conduct cyber security
testing on systems that are not operational because of this, thus reducing the risk of accidental
change or unauthorized access to operational software and business d ata through inappropriate
developer access. If the development and test staff have access to the operational system and
its information, they may be able to introduce unauthorized and untested code or alter
operational data. Developers and testers also pos e a threat to the confidentiality of operational
information. Development and testing activities may cause unintended changes to software and
information if they share the same computing environment.
The preferred method of eliminating these problems is to use a system that is separate from the
operational system to perform the initial development and testing. If this is not possible, care

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 140 -
must be taken to ensure that the system uses a properly defined change management system to
document, and provide the capability to back-out from, any changes that are made to the system .
A.3.4.3.6 Change management

Change management systems for SIS are used in some industries based on regulatory
requirements. For a complete CSMS, change management systems should be used for all IAC S.
The change management process should follow separation of duty principles to avoid conflicts of
interest. This means that the same individual cannot both approve a change and implement the
change. A technically knowledgeable individual should review pro posed changes to IACS for
their potential impact to HSE risks and cyber security risks based on clearly defined policies. If
one of the policies is violated by the change, then the proposed change may need to be reviewed
by other knowledgeable personnel to verify that it is valid or disapprove the change.
For change management to be effective, there should be a detailed record of what is installed
and this should form the basis for change proposals. The change management system must be
supported by a documented and proven backup and restoration procedure. It is critical that all
system upgrades, patches and policy changes are implemented in accordance with the change
management system procedures.
A.3.4.3.7 Patch management

Installing patches, upgrades, and policy changes, which seem innocuous in isolation, may have
serious cyber security ramifications. Failure to install these can also present serious hazards. A
method must be developed to determine the relevance and criticality of the vulnerabilities new
patches are intended to mitigate. Such a method must determine the impact on the ability to
maintain the Target Security Level if the patch is applied AND if it is not applied. At the writing of
this standard, ISA99 was developing a technical report on Patch Management .
A.3.4.3.8 Backup and recovery

Special care should be taken to verify that that the backup and recovery processes are
compatible with the Target Security Level for the system . Generally, the backup and recovery
process should ensure that backup copies are protected to the same extent as the originals. This
may require special procedures to verify that backups have not been corrupted and that
mechanisms that flag a successful backup or restoration have not been compromised . The
stability of backups should be verified on a regular basis to make sure that the media containing
the files has not degraded and also that the data contained on the media is still capable of being
read and used. It may be necessary to keep legacy equipment in instances where older backup s
cannot be read by newer equipment.

a) Documenting security requirements (threats/countermeasures/testing plans)
b) Mapping security countermeasures to security requirements
c) Defining expected failure response behavior
d) Defining, developing, and testing component functionality so that the entire system meets t he
target security level
e) Verifying and validating cyber security during c omponent, integration, and system testing
f) Including an authorization trail, a backup and restoration s ystem, a patch management
system, and an antivirus/malware procedure into the c hange management system
a) Implementing separate development, test, and operational environments
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

– 141 – ANSI/ISA–62443-2-1 (99.02.01)–2009
b) Employing independent component verification and validation pr ocedures

c) Employing independent integration verification and validation procedures
d) Employing independent system verification and validation procedures
e) Integrating IACS change management procedures with existing PSM procedures.
 ISO/IEC 17799, Clause 10 [14]
 PCSRF ICS-SPP [29]
 CMMI-SW v1.1 [30]
A.3.4.4 Element: Information and document management
Information and document management is the pr ocess for classifying all data, safeguarding the
information, managing the documents and making appropriately available the information
associated with the IACS and CSMS. IACS document management may be included in the
organization’s general records retention and document management system. Information and
document management ensures that data is available for the required length of time based on
internal (for example, organization policies and device maintenance) or external ( for example,
legal, regulatory, and political) requirements.
A.3.4.4.2 Considerations for information and document management

Information associated with an organization’s CSMS is important, often sensitive and needs to
be appropriately controlled and managed. Organizations therefore should employ comprehensive
information and document management policies for their CSMS . Information associated with the
development and execution of a CSMS, risk analyses, business impact studies, risk tolerance
profiles, and the like, may be organization sensitive and may need to be protected, as are
countermeasures, philosophy and implementation strategies. Additionally, business conditions
change and require updated analyses and studies. Care should be given to protect this
information and verify that the appropriate versions are retained. Inherent in this is an
information classification system that allows information assets to receive the appropriate level of
protection.
One of the first steps to creating an IACS information and document management system is to
define information classification levels. Information (for example, confidential, restricted, and
public) should be defined for managing access and control of information assets. The levels and
associated practices should address sharing, copying, transmitting and distributing information
assets appropriate for the level of protection required .
After the basic levels have been defined, the information associated with the IACS ( for example,
control system design information, vulnerability assessments, network diagrams and industrial
operation control programs) needs to be classified to indicate the level of protection required.
This level of protection should be determined based on the sensitivity of the information and the
potential consequences if the inform ation was released. The classification level should indicate
the need and priority of the information, as well as the sensitivity of the information . Policies and
procedures for access to the information or documents need to be linked to t he access control
procedures as defined in Annex A.3.3.5, Annex A.3.3.6, and Annex A.3.3.7.
A lifecycle document management process should be developed and maintained for this
purpose. This process should confirm the security, availability and usability of the control system
configuration. This includes the logic used in developing the configuration or programming for the
life of the industrial automation and control system. This process should also include a
mechanism for updates when changes occur.
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 142 -
Policies and procedures should be developed detailing retention, protection, destruction , and
disposal of company information including written and electronic records, equipment and other
media containing information, with consideration for legal or regulatory requirements . The
policies and procedures developed for the IACS information and document management system
should be consistent with and feed into any corporate information and document management
system. Legal reviews of the retention policies should be performed to ensure compliance with
any laws or regulations. Documents requiring retention should be identified and a retention
period should be documented.
It is also necessary to ensure that appropriate measures are employed to ensure that long-term
records can be retrieved (that is, converting the data to a newer format, retaining older
equipment that can read the data). Methods and procedures should be developed to prevent
corruption of backup data. Backup copies should be made on a regular basis . These backups
should be tested to verify that they are still viable . Restoration procedures should also be
regularly checked and tested.
Periodic reviews of the classification levels of inform ation and documents should be conducted.
The need to treat some information or documents with special control or handling needs to be
evaluated during these reviews. A method to increase or decrease the classification level of a
particular piece of information or document will also need to be developed.
Periodic review of the information and document management system, as a whole, should also
be conducted. This ensures that the owners of the information or documents conform to the
appropriate policies, standards or other requirements set down by the organization.

a) Defining information classification levels (that is, confidential, restricted, and public) for
access and control to include sharing, copying, transmitting an d distributing appropriate for
the level of protection required.
b) Classifying all information (for example, control system design information, vulnerability
assessment results, network diagrams, and industrial operation control programs) to indicate
the need, priority and level of protection required commensurate with its sensitivity and
consequence.
c) Reviewing information that requires special control or handling on a periodic basis to validate
whether special handling is still required.
d) Developing and including policies and procedures detailing the record update, retention,
destruction, and disposal of information including written and electronic records, equipment
and other media containing information. Any legal or regulatory requirements should be
considered when developing these policies and procedures.
e) Developing and employing methods to prevent data-corruption around backup processes and
logging.
f) Confirming the security, availability, and usability of the control system configuration. This
includes the logic used in developing the configuration or programming for the life of the
industrial automation and control system.
a) Employing the appropriate measures to ensure long-term records information can be
retrieved (that is, converting the data to a newer format or retaining older equipment that can
read the data). An example of this would be emissions data recorded over a decade ago on a
system that does not currently exist or is in a proprietary format.
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

– 143 – ANSI/ISA–62443-2-1 (99.02.01)–2009
b) Performing periodic reviews of conformance to the information and document management

policy.
c) Performing legal reviews of the retention policies to ensure conformance to any laws or
regulations.
d) Encrypting all communications over the Internet involving private information wit h secure
socket layer (SSL) or equivalent strength encryption.
 ISA–TR99.01.02, 10.2 [2]
 ISO/IEC 17799, Clause 5.2 [14]
 ISO/IEC 27001, Clause 4.3 and Annex A.7.2 [15]
A.3.4.5 Element: Incident planning and response
Incident planning and response addresses the need to be vigilant in efforts to detect cyber
security incidents and to promptly identify and respond to these incidents. No matter how much
care is taken in protecting a system, it is always possible that unwanted intrusions might
compromise the system. Technology vulnerabilities continue to exist and external threats are
increasing in number and sophistication, thereby requiring a robust strategy for determining the
appropriate planning and response. Incident planning and response allows an organization to
predefine how it will detect and react to cyber security incidents. Thi s allows the organization to
be proactive with its cyber security program instead of reactive .
Incident planning and response provides the organization the opportunity to plan for security
incidents and then to respond per the established practices. The goals of incident planning and
response are very similar to those from business continuity plan ning, but usually relate to
smaller-scale and possibly more real-time, incidents. Part of the incident plan should include
procedures for how the organization will respond to incidents, including notification processes,
documentation processes, investigation, and subsequent follow-up practices. Responding to
emergencies, ensuring personnel safety and getting systems back online are part of incident
response. Identifying an incident early and responding appropriately can limit the
damage/consequence of the event.
Incident planning and response is a key element of the management system for any type of risk
to an organization, including cyber security risks. Sound infor mation management practices
recognize the need to have a formal incident planning and response system in place.
There are three main phases that are part of incident planning and response: planning,
response, and recovery. The planning phase includes the initial system program development
and the specific contingency planning efforts. The response phase involves the ability to respond
to actual incidents. The recovery phase restores IACS to their previous operational states.
A.3.4.5.2 Planning phase

A program should be established to recognize and respond to incidents within the IACS
environment. This program needs to include a written plan, documenting the types of incidents
that will be dealt with and the expected response to each of those incidents.
The incident plan should include the types of incidents that may occur and the expected
response to those incidents. The various types of incidents that a system intrusion might cause
should be identified and classified as to the effects and likelihood, so that a proper response can
be formulated for each potential incident . This plan should include step-by-step actions the
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 144 -
various organizations should take. If there are reporting requirements, these should be noted , as
well as where the report should be made and phone nu mbers in order to reduce reporting
confusion. During the preparation of the incident response plan, input should be obtained from
the various stakeholders including operations, management, legal , and safety. These
stakeholders should also sign-off and approve the plan.
The incident plan should include contingency plans covering the full range of consequences that
may occur due to failures in the IACS cyber security program. These contingency plans should
include procedures for separating the IACS from all n onessential conduits that may provide
attack vectors, protecting essential conduits from further attacks and restoring the IACS to a
previously known state in the event of an incident. They should also be tested periodically to
ensure that they continue to meet their objectives.
Another important piece of information that needs to be included in the incident plan is the
contact information for all the personnel responsible for responding to incidents within the
organization. It may be difficult to locate th is information in the event of an incident occurring.
After the incident plan is complete, the organization needs to distribute copies to all appropriate
personnel groups within the organization, as well as any appropriate outside organizations. All
associated personnel and organizations need to be made aware of their responsibilities before,
during and after an incident.
In addition to just distributing the plan to all appropriate organization, the plan should be tested
periodically to ensure that it is still relevant. The organization should conduct drills of the incident
response plan and analyze the results of those drills. Any problems found during the drills should
be addressed and the plan should be updated.
A.3.4.5.3 Response phase

There are several responses that can be taken in the event of a security incident. These range
from doing nothing to having a full system shutdown. The particular response taken will depend
on the type of incident and its effect on the system. A written plan should have been prepared
during the Planning Phase that clearly documents the types of incidents that may occur and the
expected response to those incidents. This will provide guidance during times when there might
be confusion or stress due to the incident.
The organization needs to have procedures in place to identify and report incidents. These
procedures should establish guidelines to determine what might constitute an incident and how
potential incidents should be reported and classified. These guidelines should include
information about recognizing and reporting unusual experiences that may actually be cyber
security incidents. The procedures should also include any special responsibilities ( for example,
identification methods, reporting requirements, and specific actions) that personnel need to be
aware of when dealing with a cyber security incident.
If an incident is detected, the details of that incident should be documented to record the incident
itself, the response(s) taken, the lessons learned and any actions to be taken to modify the
CSMS in light of this incident. The details of the incident need to be communicat ed to all
appropriate groups within the organization (for example, management, IT, process safety,
automation, and control engineering and manufacturing) and any outside organizations affected
by the incident. It is important that these details be communicated in a timely manner to help the
organization prevent further incidents.
Since every incident may not be initially recognized or detected, the organization should have
procedures in place to identify failed and successful cyber security breaches. Depending upon
the magnitude of the damage inflicted by a particular incident, cyber security forensic specialists
may need to be consulted to determine the root cause of the incident, to evaluate the
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

– 145 – ANSI/ISA–62443-2-1 (99.02.01)–2009
effectiveness of the response(s) taken and, in the case of an intentional loss, to preserve the
chain of evidence to support efforts to prosecute the perpetrator. If the incident occurs on a
critical IACS system resulting in a business continuity interruption, the goal will likely be to get
the facility back to running as quickly as possible . This may involve reformatting hard disks and a
complete reload of the operating system and applications which probably removes all forensics
data. Establishing incident response priorities and practices prior to an incident is important so
that everyone understands the goals and methods.
A.3.4.5.4 Recovery phase

The results of the incident might be minor or could cause many problems in the syst em. Step-by-
step recovery actions should be documented so that the system can be returned to normal
operations as quickly and safely as possible.
An important component of the recovery phase is the restoration of systems and information
(that is, data, programs and recipes) to operational states. This requires a sufficient backup and
recovery system capable of handling the entire IACS. It may be made up of one or multiple
physical backup and recovery devices, but they should all work together to aid in the recovery of
the IACS.
The organization should have an incident analysis process in place to address issues that are
discovered and ensure they are corrected. The findings from the analysis process need to be
incorporated into the appropriate cyber security policies and procedures, technical
countermeasures and incident response plans. Cyber security-related incidents can be divided
into three categories:
 Malicious code such as viruses, worms, bots, rootkits , and Trojan horses
 Accidental loss of availability, integrity, or confidentiality (including production availability)
 Unauthorized intrusion that extends to physical assets
Incidents in the first two categories are typically managed within the IT security incident
response process. The third category would typically be managed in collaboration with HSE
specialists and site leadership.

a) Establishing procedures for the overall organization to recognize and report unusual
experiences that may actually be cyber security incidents.
b) Establishing incident planning and response procedures which include:
 Naming the responsible person for executing the plan when the need arises
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
 Structuring an incident response team that can be called in, including contributors from IT
security and IACS and additional personnel
 Establishing the responsibility for coordinating defense and response to an incident
 Handling the incident from initiation through final review
 Creating procedures for identifying, categorizing and prioritizing incidents
 Creating procedures for different types of incidents like DoS attacks, system hacking,
malicious code, unauthorized access, and inappropriate usage
c) Identifying proactive measurements to automatically identify incidents during their early
stage.
d) Preplanning responses to threat scenarios identified from vulnerability and risk assessment s.

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 146 -
e) Communicating IACS incidents to all appropriate organizations including the IT, industrial
operations safety, automation, and control engineering and operations organizations for
awareness building.
f) Communicating metrics and incidents to executive management.
g) Carrying out regular reviews of past incidents, to improve the CSMS
h) Documenting the details of the incident, the lessons learned and any actions to be taken to
modify the CSMS in light of this incident.
i) Conducting drills to test the plan. Holding lessons learned meetings following the drills to
identify areas for improvement.
A.3.4.5.5.2 Additional Practices
a) Developing forensic investigation capabilities for IACS systems either intern ally or externally
b) Developing a process for immediately reporting cyber security incidents. Ensur ing that the
process has links to the organization’s crisis management team. Educating personnel with
examples of reportable incidents so they can better compl y with reporting requirements.
c) Understanding any potential links between IT, safety, and IACS and incorporating this
understanding into integrated security incident response procedures.
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
d) Developing, testing, deploying, and documenting the incident investigation process.

e) Developing corporate policies for reporting cyber security incidents and sharing incident
information with industry-wide groups and government agencies where corporate polic ies
allow.
f) Specifying roles and responsibilities with respect to loca l law enforcement and/or other
critical stakeholders in an internal and shared incident investigation program.
g) Expanding the investigation of incidents based on the potential outcome that could have
occurred rather than the actual outcome, recognizing that the cyber incident may include
malicious intent. The level of incident investigation may need to be upgraded depending on
the potential seriousness of the incident.
h) Developing methodologies and mechanisms to ensure that corrective actions identified as th e
result of a cyber security incident or a drill are fully implemented.
i) Providing security incident response training to organizational cross-functional training
teams.
j) Reviewing final incident investigation results with all personnel whose job tasks are r elevant
to the findings. Reviewing the incident in light of trends and record ing it so it can be used for
subsequent trend analyses.
k) Promoting peer-to-peer and cross-industry mutual assistance activities in order to learn from
others’ experiences regarding cyber security incident evaluation, response, investigation,
communication, and correction.
l) Identifying previously unforeseen consequences, especially those that may affect future
application of the plan. Incidents may include risk events, near misses and malfunctions. Also
included are any observed or suspected weaknesses in the system or risks that may not have
been previously recognized.
m) Incorporating emergency response planning into incident response planning.
 NIST SP 800-61 [27]

– 147 – ANSI/ISA–62443-2-1 (99.02.01)–2009
A.4 Category: Monitoring and improving the CSMS

A cyber security management system includes all the measures necessary to create and
maintain a cyber security program. The scope and level of this effort are dependent on the
organization’s objectives, tolerance for risk and cyber security program maturity. This
management system should address the requirements, methods, devices, interfaces, and
personnel necessary to implement the cyber security program.
Monitoring and improving the CSMS involves both ensuring that the CSMS is being used and
also reviewing the CSMS itself for effectiveness. Figure A.19 shows the two broad elements
outlined in this section:
 Conformance – Ensures that the CSMS as defined by an organization is followed

 Review, improve, and maintain the CSMS – Ensures that the CSMS, as defined, meets the
current objectives of the organization
Review, improve and

Conformance
maintain the CSMS
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
Figure A.19 – Graphical view of category: Monitoring and improving the CSMS
A.4.2 Element: Conformance
Conformance is the process of validating that the organization is following the cyber security
program that was developed. The CSMS is only as good as an organization’s ability to follow it.
The organization must be held accountable to the policies and procedures set down as part of
the CSMS or the management system will be ineffective. By validating its conformance with the
CSMS, the organization can use the built-in processes of the CSMS to improve the overall
system in the future.
As part of validating conformance with the CSMS, there are scheduled and unscheduled
activities. Periodic reviews of the CSMS would be considered scheduled, but responding to a
cyber security incident would most likely be considered unscheduled.
Establishing key performance indicators (KPI) will give the organization a way to measure the
performance of the CSMS. Using KPI that are consist ent with best-in-class solutions from
industry groups or other organization will allow for benchmarking of the CSMS.
A.4.2.2 Scheduled versus unscheduled activities

Many sections of the CSMS include the idea of periodic reviews of some item in order to monitor
or improve the CSMS over time. These reviews are all part of the Maturity Model of a security
program as discussed in ANSI/ISA–99.01.01–2007 [1]. The reviews conducted as a standard
part of a CSMS keep the system from degrading over time due to new threats, vulnerabilities or
situations that did not exist when the system was first developed.
There may also be critical threats, vulnerabilities or situations that arise that need to be dealt
with before the next scheduled review perio d. These would constitute unscheduled activities and
may require a re-evaluation of the CSMS in order to ensure effectiveness.

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 148 -
Periodic reviews and audits of the CSMS determine if the desired policies, procedures and
countermeasures have been implemented properly and that they are performing as intended. In
the IACS environment, auditors must fully understand the corporate cyber security policies and
procedures and the specific HSE risks associated with a particular facility and/or industrial
operation. Care must be taken to ensure that the audits don’t interfere with the control functions
provided by the IACS equipment. It may be necessary to take a system off -line before the audit
can be conducted. The audit should verify that:
 The policies, procedures, and countermeasures present during system validation testing
are still installed and operating correctly in the operational system
 The operational system is free from security compromises. Should an incident occur, logs
and records will be generated capturing information on the nature and extent of the
incident
 The management of change program is being rigorously followed with an audit trail of
reviews and approvals for all changes
A particular unscheduled activity that may trigger a review of the CSMS may be the addition or
removal of assets from the IACS. A common practice during system maintenance or retooling
may be to add, upgrade or remove equipment or software from the IACS. A well defined and
followed change management process will catch this, which ma y trigger a review or audit of the
CSMS. This review or audit would ensure that the change did not adversely affect the cyber
security of the IACS. Another example of an unscheduled activity would be a response to a virus
outbreak at a facility. After the CSMS system has been used to respond and recover from the
incident, a review or audit of the CSMS should be conducted to determine where the failure
occurred that allowed the virus to spread.
Any cyber security reviews or audits (internal or external) will provide the organization with
valuable data in order to improve the CSMS. The results of these reviews or audits should
include as much detailed information as necessary to both ensure that any legal or regulatory
requirements are satisfied and that any m odifications indicated by the review or audit can be
made. The results should be sent to all of the appropriate personnel ( that is, stakeholders,
managers, and security personnel).
A.4.2.3 Key performance indicators

KPI allow the organization to determine how well the CSMS in performing and helps it direct any
resources towards areas that may need improvement. KPI should, as much as possible, be
quantitative values (that is, numbers or percentages) indicating how a particular part of the
CSMS performs with respect to expected conditions.
Since any reviews or audits or the CSMS should be expressed using these KPI, it is important to
pick indicators that are relevant, meaningful, and consistent with the CSMS and other
requirements on the organization. The results of p eriodic scheduled activities may be expressed
as the performance against a set of predefined metrics to indicate security performance and
security trends. The results of unscheduled activities may be expressed as the effectiveness of
the CSMS to deal with the unscheduled event or incident.
Organizational capability data should be a part of the performance indicators . Companies should
track the percentage of personnel assigned to IACS roles and the percentage of those personnel
who have passed the training and qualification requirements for their roles. While th ese data may
seem esoteric, systemic problems can be indicated here before being noticed in poor audit
results.
Benchmarking the KPI and the results of reviews or audits against other organizations or
requirements is a good method for validating the CSMS. If benchmarking data are collected over

--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

– 149 – ANSI/ISA–62443-2-1 (99.02.01)–2009
a period of time, it may be possible for the organization to determine trends in either threats or
countermeasures. These may indicate places where the CSMS requ irements may have to be
reviewed as part of the review, improve and maintain section of the CSMS.

a) Providing assurance that the appropriateness of the control environment and compliance with
the overall cyber security objectives are being met. Detecting if additions, upgrades, or
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
removals (that is, software patches, application upgrades, and equipment changes) have
introduced security exposures.
b) Confirming that, over a specified regular audit period all aspects of the CSMS are functioning
as intended. A sufficient number of audits should be planned so that the audit task is spread
uniformly over the chosen period. Management should ensure periodic audits are conducted.
Management should ensure that there is evidence to:
 verify that documented procedures are being followed and are m eeting their desired
objectives
 validate that technical controls (that is, firewalls and access controls) are in place and are
working as intended both consistently and continuously
a) Requiring that the cyber security metrics program is built upon the seven key steps listed as
follows:
1) Defining the metrics program goal(s) and objectives.
2) Deciding what metrics to generate in order to measure the degree of adoption and
conformance to the policies and procedures defined in the CSMS.
 Proactively assess any potential security vulnerabilities ( for example, % of security
audit weaknesses fixed by the agreed date)
 Track implementation and usage of security and preventive measures ( for
example, % of conformance with security standards)
3) Developing strategies for generating the metrics.
4) Establishing benchmarks and targets.
5) Determining how the metrics will be reported and to whom.
6) Creating an action plan and acting on it.
7) Establishing a formal program review/refinement cycle.
b) Reviewing the results of audits, self-assessments, cyber security incident reports, and
feedback provided by key stakeholders regularly to understand the effectiveness of the
CSMS.
c) Conducting operational security reviews on the industrial automation and control systems by
security trained IACS engineers. In addition, security issues are frequently reviewed at a
broader level by a governance body.
 ISO/IEC 27001, 4.2.3, 4.2.4, Clause 7, and Clause 8 [15]
 NIST SP 800-55 [26]
 IDEAL model [40]

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 150 -
 COBIT website [41]

A.4.3 Element: Review, improve, and maintain the CSMS
The process of continuously monitoring and reviewing the CSMS allows an organization to
establish, with evidence, that it is meeting the goals, policies, and procedures laid out in the
CSMS. The KPI defined while developing the CSMS are used to evaluate the performance of the
CSMS during the conformance review process. The Conformance element verifies that the
CSMS is operating as defined, while this element verifies that the requirements used to develop
the CSMS meet the organization’s cyber security goals.
Internal checking methods, such as conformance audits and incident investigations , allow the
organization to determine the effectiveness of the management system and whether it is
operating according to expectations. It is also important to establish that the management
system still meets the goals, targets and objectives set out during the planning process. If there
are deviations from the original goals, targets, or objectives, systematic changes to the
management system may be required.
Because both threats and technologies for addressing security are evolving, it is anticipated that
the organization’s cyber security program will evolve, reflecting new threats and capabilities that
are available. Organizations should be tracking, measuring and improving security efforts to keep
people, property, products, industrial operations, data, and information systems secure.
The overall objective is to ensure that the CSMS remains effective by incorporating
improvements made based on new threats, new capabilities and regular reviews. Continual
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
attention to security provides an indicator to personnel that cyber security is a core company
value.
A.4.3.2 Review of conformance to the CSMS

Conformance to the CSMS has been discussed in an earlier element. It verifies that the
organization is following the policies and procedures expressed in the CSMS. As part of the
conformance process, key performance indicators have been defined to measure the
performance of the organization’s CSMS. Poor marks in these KPI in one review cycle may
indicate a singular problem that can be remedied by simple solutions. Poor marks in many of the
KPI or in the same KPI over repeated reviews may indicate systemic problems with the CSMS. It
may indicate that training or enforcement needs to be improved, resources are inadequate or
that the implemented procedures are impractical. Managing the CSMS involves making these
judgments. Whether the KPI are evaluated through independent or self-audits, it is useful to
consult with the organization whose actions are being measured, to help make this
determination.
It is important that the CSMS include requirements for improving conformance results. The
responsible individual(s) should also be chartered to develop a long -term strategy for the
improvement to assure a consistent cost-effective improvement path over time.
A.4.3.3 Measure and review the effectiveness of the CSMS

Measuring the effectiveness of the CSMS at a minimum involves reviewing incident data. The
greater an organization’s capability to detect failed and successful cyber security breaches and
record these as incidents, the greater its capability to measure effectiveness of th e CSMS in
lowering risk. Incident data include the number of incidents, the type or class of incidents and the
economic impact of the incidents. These data are extremely important both to understand the
current economic impact of cyber security threats and to assess the effectiveness of specific
countermeasures employed.

– 151 – ANSI/ISA–62443-2-1 (99.02.01)–2009
While analysis of incident data can measure effectiveness of the CSMS in the past, CSMS
management is also charged with maintaining the effectiveness of the CSMS into the future. To
accomplish this, it is necessary to monitor for changes to factors that might increase or decrease
its effectiveness going forward. Key factors to monitor are:
 Level of risk, which may change due to a change in threat, vulnerability, consequence , or
likelihood
 Organization’s risk tolerance
 Implementation of new or changed systems or industrial operations
 Industry practices
 Available technical and non-technical countermeasures
 Legal and regulatory requirements
An organization’s CSMS needs to be reviewed at regular intervals, to assess both its past
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
effectiveness and the view going forward. This review should include a periodic assessment of
cyber security policies and procedures to affirm that those policies and procedures are in place
and working and meet the legal, regulatory and internal security requirements. In appropriate
circumstances, assessments also apply to the policies and procedures of the organization’s
business partners, such as suppliers, support providers, joint ventures or customers.
In addition to regular reviews, major changes to the factors listed above should also trigger
review of related aspects of the CSMS. An organization should determine a set of change
triggers and thresholds, which would trigger such a review. These triggers should include :
 Internal factors: Based on the performance of the CSMS and the results of KPI and other
suitable internal indicators (for example, risk tolerance, management changes, and the
like)
 External factors: Changes in the threat environment, industry best practi ces, available
solutions and legal requirements may indicate a need or opportunity for improvement of
the CSMS
The organization assigned to manage changes to the CSMS should also be responsible for
reviewing the triggers and thresholds for changes and for using them to kick off the review
process.
A.4.3.4 Legal and regulatory implications for the CSMS

The legal and regulatory environment that the organization is subject to may change over time.
The organization may still be compliant with the CSMS as it was origina lly defined, but that
CSMS may no longer satisfy the legal and regulatory requirements that apply.
The organization should periodically review its applicable legal and regulatory requirements and
identify any areas where they may affect the CSMS. Also, any major changes to the legal and
regulatory requirements, such as major new or updated requirements, should trigger a review of
the CSMS to ensure it meets the new requirements.
A.4.3.5 Manage CSMS change

To have a coordinated system, an organization/team should be assigned to manage and
coordinate the refinement and implementation of the CSMS changes. This organization/team is
likely to be a matrix type organization drawing on key people from different business
organizations. This team should use a defined method for making and implementing changes.

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 152 -
A number of internal and external factors will necessitate changes to the CSMS. The
management of these changes requires coordination with the various stakeholders. When
implementing changes to the management system, it is important to examine possible side
effects relating to system operation or safety. IACS security also needs to take into account the
different organizations, practices, and response requirements when incorporating improvements.
Written procedures should be developed to manage changes to the CSMS. This process might
include:
Defining the current management system

Before the CSMS can be refined, it is necessary to know and understand the current
management system. All the policies relating to cyber securit y should be reviewed so all
the stakeholders clearly understand the current policy and how it is being implemented.
In addition, all assets and procedures related to the CSMS should be identified.
Defining the procedures for proposing and assessing changes to the CSMS
Once the current management system is understood, it should be reviewed for
compliance and effectiveness, as described previously. Weaknesses or gaps in the
management system should be identified and corrections proposed. The evaluation of the
management system should identify areas where changes might be required. In addition,
industry best practices and requirements outlined in this standard might be considered in
defining changes that would strengthen the CSMS. Selection of new countermeasures
will follow the principles outlined in the Risk Management and Implementation element of
this standard (Section A.3.4.2). Once defined, the proposed changes to the CSMS should
be documented in a concise manner so that they c an be consistently presented to other
stakeholders.
Proposing and evaluating changes to the CSMS

With the changes identified and documented, they should be presented to the
stakeholders. The proposed changes should be reviewed to determine if they will pro duce
any negative or unforeseen side effects. They should also be evaluated to determine if
any changes need to be made to the CSMS against the original requirements and testing
suites. As new capabilities are developed, the reaction of many organizations is to
incorporate the newest technology into the system. In the IACS environment, it is
important to validate any new cyber security technology or solution before incorporating
it.
Implementing CSMS changes

After the stakeholders agree on the change, the changes to the CSMS should be
implemented. Changes to the policy should follow company procedures for policy
changes and at a minimum these changes should be documented and written approval
should be obtained from key stakeholders. Special attention to syst ems testing, validation
and control vendor involvement is required.
Monitoring CSMS changes

With the new or revised CSMS in place, it is important to monitor and evaluate its
performance. A review of the management system should be performed on a regular
basis and whenever there are changes to the CSMS.

--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

– 153 – ANSI/ISA–62443-2-1 (99.02.01)–2009

a) Using a method to trigger a review of the level of residual risk and risk tolerance when there
are changes to the organization, technology, business objectives, industrial operation, or
external events including identified threats and changes in social climate.
b) Analyzing, recording, and reporting operational data to assess the effectiveness or
performance of the CSMS.
c) Analyzing the results from the periodic reviews and audits of the CSMS to determine if a
change is needed.
d) Investigating ineffective CSMS policies and procedures to determine any root causes where
there are systemic problems. Actions are identified not only to resolve the issue, but also to
minimize and prevent reoccurrences.
e) Reviewing potential threats and conducting an impact analysis on a regular basis to
determine if countermeasures are required.
f) Identifying applicable and changing regulations and legislation (that is, Sarbanes-Oxley,
NERC cyber security standards, and CFR 11) and contractual cyber security obligations and
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
requirements.
g) Involving the key stakeholders in the organization for confirmation on areas for further
investigation and planning. The key stakeholders should include personnel from all of the
different groups affected by the CSMS ( that is, IT, IACS, and safety)
h) Identifying appropriate corrective and preventive actions to further improve the performance
process.
i) Prioritizing improvements in the CSMS and putting plans in place to implemen t them (that is,
budgets and project planning).
j) Implementing all changes using the management of change processes within the
organization. Special attention to systems testing, validation and control vendor involvement
is required due to the HSE implications of the IACS environment.
k) Validating that agreed actions from previous audits and reviews have been implemented
l) Communicating action plans and areas of improvement to all the stakeholders and the
affected personnel.
m) Requiring that the cyber security metrics program is built upon the seven key steps listed as
follows:
1) defining the metrics program goal(s) and objectives;
2) deciding what metrics to generate to measure the effectiveness of the CSMS to meet the
organization’s security goals;
NOTE It may be good to provide a retrospective view of security preparedness by tracking the number and
severity of past security incidents, including patterned small events.
3) developing strategies for generating the metrics ;

4) establishing benchmarks and targets;
5) determining how the metrics will be reported and to whom ;
6) creating an action plan and acting on it; and
7) establishing a formal program review/refinement cycle.

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 154 -
n) Undertaking many different strategies to drive continuous improvement in cyber security

activities. The strategies are commensurate with risk and dependent upon corporate culture,
existing systems, and size or complexity of digital systems. Some potential strategies are:
 conducting benchmarking security activities both within and outside of the industry.
External validation can be used to help validate improvements
 seeking employee feedback on security suggestions actively and reporting back to senior
management as appropriate on performance shortcomings and opportunities
 using standard corporate business methodologies, such as Six Sigma, for measuring,
analyzing, improving, and sustaining cyber security improvements
 ISO/IEC 27001, Clauses 4.2.3, 4.2.4, 7 and 8 [15]
 NIST SP 800-55 [26]
 IDEAL model [40]

--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

– 155 – ANSI/ISA–62443-2-1 (99.02.01)–2009
Annex B
(informative)
Process to develop a CSMS

B.1 Overview
Clause 4 and Annex A detail the individual elements associated with a comprehensive,
integrated CSMS. Developing a functioning CSMS is a journey that may take months or years to
achieve. This Annex focuses on the ordering and iterative nature of the activities associated with
developing the elements of the CSMS. The objectives of this Annex are:
 to provide key insights about how successful organizations have sequenced theses
activities, and point out common pitfalls related to the order in which elements of a CSMS
are addressed;
 to provide a step-by-step guide that an organization may reference as they begin the
process of establishing a CSMS; and
 to provide a step-by-step guide on how to use this standard.
B.2 Description of the Process

Figure B.1 shows the six top level CSMS activities and their relationships. Later figures of this
Annex break each of these down in further detail. While Figure B.1 shows interrelationships
between all of the activities, not all of these interrelationships are shown in detail later in this
Annex. This has been done to balance the concise representation with the completeness of the
topics being discussed.
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
Establish policy,
Initiate CSMS High-level risk
organization and
program assessment
awareness
Maintain the
CSMS
Select and
Detailed risk
implement
assessment
countermeasures
Figure B.1 – Top level activities for establishing a CSMS

The initiate CSMS program activity puts the program on solid footing by establishing the
purpose, organizational support, resources, and scope for the CSMS. Starting with this activity
will maximize the effectiveness of the effort, as is the case for any program with broad impact.
The initial scope may be smaller than desired, but can grow as the program succeeds.
Risk assessment drives the content of the CSMS. The high-level risk assessment activity lays
out threats, likelihood of their realization, general types of vulnerabilities , and consequences.

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 156 -
The detailed risk assessment activity adds a detailed technical assessment of vulnerabilities to
this risk picture. It is important to address risk assessment first at a high level. A common pitfall
is to expend resources early on to perform detailed vulnerability assessment and then
experience an apathetic response to these technical results, because the overall higher level risk
context has not been established.
The establish policy, organization and awareness , and select and implement countermeasures
activities directly lower risk to the organization. These activities will implement both high-level
and low-level decisions, driven by both the high-level and detailed risk assessments. The
establish policy and organization and awareness activity covers creation of policies and
procedures, assignment of organizational responsibilities , and planning and execution of training.
The select and implement countermeasures activity defines and implements the organization’s
technical and non-technical cyber security defenses. These two main activities must take place
in a coordinated fashion. This is because in most cases related policies and proce dures, training
and assignment of responsibility are essential in order to make a countermeasure effective.
The maintain the CSMS activity includes tasks to determine whether the organization conforms
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
to its CSMS policies and procedures, whether the CSMS i s effective in meeting the
organization’s cyber security goals, and whether these goals need to change in light of internal
or external events. This activity defines when revision of its high -level or detailed risk
assessments is required or may precipitate a change to the initial program parameters. It may
also provide input for improvement of policies, procedures, organizational decisions , or training
in order to maximize effectiveness of countermeasures or point out weaknesses to be corrected
in implementation of selected countermeasures. Organizations report that the maintain the
CSMS activity is very difficult since initial enthusiasm for the program may have died down and
other priorities emerge. However, without adequate attention to this activity, po sitive results from
the program will ultimately be lost because the environment in which the program will operate is
not static.
The remainder of this Annex gives the reader a better understanding of the six top level CSMS
activities. The element or sub-element number has been referenced to aid the reader of this
standard in finding more information about that particular topic.

– 157 – ANSI/ISA–62443-2-1 (99.02.01)–2009
B.3 Activity: Initiate CSMS program
Initiate CSMS program
Develop a business
rationale
(A.2.1)
Obtain leadership
Develop the CSMS
commitment, support
scope
and funding
(A.3.1.1)
(A.3.1.2.2)
Involve stakeholder(s)
(A.3.1.2.2)
Figure B.2 – Activities and dependencies for activity: Initiate CSMS pro gram
The desired outcome of the initiate CSMS program activity is to obtain leadership commitment,
support, and funding for the CSMS. In order to achieve this, the first steps as shown in Figure
B.2, are to develop a business rationale that will justify the program to management and a
proposed scope for the program. In conjunction with these steps, individuals who are
stakeholders, based upon this rationale and scope are identified and involved. It is most effective
to identify these stakeholders up front, wherever possible, and make them a part of the effort to
engage management for a commitment to the program. An effective organizational framework for
security can then be built, starting at the top. A common pitfall is to attempt to initiate a CSMS
program without at least a high-level rationale that relates cyber security to the specific
organization and its mission. Cyber security activities require resources from the organization ,
and although a program may start under the gener al consensus that cyber security is good,
momentum will quickly be lost to competing demands if a business rationale has not been
established.

--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 158 -
B.4 Activity: High-level risk assessment
High-level risk assessment
Define the
Define the
Identify risks methodology for
methodology for
(A.2.2.2, A.2.2.3.1-2, assessing the priority
identifying risks
A.2.2.3.5.1) of risks
(A.2.2.3.3-4)
(A.2.2.3.5.2)
Assess the priority of Document the results

risks and rationale
(A.2.2.3.5.2) (A.2.2.3.5.1)
Involve stakeholder(s)
(A.3.1.2.2)
Figure B.3 – Activities and dependencies for activity: High-level risk assessment
The high-level risk assessment activity involves selecting methodologies for identifying and
prioritizing risks, and then executing those methodologies. It is important to define these
methodologies up front so that they will provide structure for the rest of the risk assessment.
Figure B.3 shows that it is important to involve the stakeholders, identified during the Initiate
CSMS Program activity, in the process of identifying and assessing the pri ority of risks. The final
step to document the results and rationale is important because this record will be found
invaluable when the risk assessment needs to be confirmed or updated in the future.
B.5 Activity: Detailed risk assessment

As shown in Figure B.4, the detailed risk assessment activity provides greater detail to the risk
assessment by first taking an inventory of specific IACS systems, networks , and devices.
Resource or time constraints may not allow detailed examination of all of these assets. In this
case, the threats, consequences, and types of vulnerabilities identified in the high -level risk
assessment are used to assist in setting priorities for those particular systems, networks , and
devices on which to focus. Other factors such as local support or history of problems will also
contribute to determining the focus for detailed risk assessment. The identification of detailed
vulnerabilities is guided by the vulnerability types from the high -level risk assessment, but is not
limited to those types. Thus, a detailed vulnerability assessment may uncover not only new types
of vulnerabilities, but also potentially new threats and associated consequences that had not
been identified during the high-level risk assessment – in other words, new risks. In this case,
the high-level assessment should be updated to include these. All vulnerabilities found are
associated with a specific risk (that is, threat, likelihood, and consequence) and prioritized in a
manner consistent with the method used during the high-level risk assessment.
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

– 159 – ANSI/ISA–62443-2-1 (99.02.01)–2009
Detailed risk assessment
Inventory IACS
Identify detailed Identify and prioritize
systems, networks Screen and prioritize
vulnerabilities associated risks
and devices (A.2.2.3.6.4-5)
(A.2.2.3.6.6-7) (A.2.2.3.6.6)
(A.2.2.3.6.1-3)
Update high level risk

High-level risk
assessment
assessment
(A.2.2.3.2)
Figure B.4 – Activities and dependencies for activity: Detailed risk assessment
B.6 Activity: Establishing Security Policy, Organization, and Awareness

The appropriate policies for the organization are an operational interpretation of the
organization’s risk tolerance. An organization that creates policy before understanding its risk or
risk tolerance may expend unnecessary effort following and enforcing inappropriate policy , or
likewise find its policies do not support the level of risk reduction required.
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
ANSI/ISA-62443-2-1 (99.02.01)–2009 - 160 -
Establish security policy, organization and awareness
Establish the risk

Communicate policies
tolerance
(A.3.1.5)
(A.3.3.1.2)
Create policies and Implement policies Develop training

procedures and procedures activities
(A.3.1.5) (A.3.1.5) (A.3.1.3)
Assess the priority of Assign organizational

risks responsibilities
(A.2.2.3.5.2) (A.3.1.2)
Audit compliance to
Refine the CSMS
the CSMS
(A.4.2.6)
(A.4.1)
Figure B.5 – Activities and dependencies for activity: Establish policies and procedures
Implementation of policy involves communicating the policy to the organization, training
personnel in the organization, and assigning responsibility for adherence to the policy. Policies
and procedures can impact any activity in the CSMS. For example, there may be policies
regarding common countermeasures to be used requiring specific system development and
maintenance processes, or determining when risk is to be re-assessed. Thus, Figure B.5 does
not attempt to depict all potential impacts of policies and procedures on the CSMS.
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

– 161 – ANSI/ISA–62443-2-1 (99.02.01)–2009
Training activities Obtain leadership Organizational

(A.3.1.3) commitment, support responsibilities
and funding (A3.1.2.2)
(A.3.1.2.2)
End-user
responsibilities by job
role
Direct mission-related
job activities
General awareness of
business impact
High-level and detailed Risk assessment

risk assessments team
Risk assessment
methods
Select
Risk management countermeasures Risk management
methods (A.3.3.1.4.1, team
A.3.3.1.4.4)
Administration of Implement Administrative tasks –

countermeasures and countermeasures software and
related procedures (A.3.3.1.4.2-3) procedures
Update business
Business continuity Roles in business
continuity and incident
and incident response continuity and incident
response plans
procedures response execution
(A.3.1.4, A3.3.4)
Develop new or Advance risk

System development
modify existing assessment for new
process
systems or modified systems
Audit compliance to
CSMS audit
the CSMS CSMS management
procedures
(A.4.1)
CSMS change Refine the CSMS

CSMS support
process (A.4.2.6)
Figure B.6 – Training and assignment of organization responsibilities

--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 162 -
Figure B.6 further breaks down the activities develop training and assign organization
responsibilities. It shows many of the different training ac tivities that make up a training program,
the organizational responsibilities associated with those training activities , and the associated
activities related parts of the CSMS program. This figure does not show all organizational
responsibilities or training topics that might be related to the CSMS, but tries to show the main
points that should be considered.
B.7 Activity: Select and implement countermeasures
Select and implement countermeasures
Select
Establish the risk Implement Develop new or
countermeasures
tolerance countermeasures modify existing
(A.3.3.1.4.1,
(A.3.3.1.2) (A.3.3.1.4.2-3) systems
A.3.3.1.4.4)
Select common
countermeasures
(A.3.3.1.2)
Update business
Update high-level and
continuity and incident
detailed risk analysis
response plans
(A.2.2.3.6.9, A4.2.4)
(A.3.1.4, A3.3.4)
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
Figure B.7 – Activities and dependencies for activity: Select and implement
countermeasures
As shown in Figure B.7, the selection of countermeasures is the technical process of risk
management. The organization’s risk tolerance, pre-selected common countermeasures, and the
results of high-level and detailed level risk assessment, drive the risk management approach for
selecting countermeasures. If the organization is implementing a new system or modifying an
existing system, this drives an update to high-level and detailed risk assessments for the
scenario in which this new system is implemented. Countermeasures selection related to the new
or modified system then proceeds based upon this updated risk information. Development or
modification of systems requires an update to business continuity and incident response plans.
B.8 Activity: Maintain the CSMS

As shown in Figure B.8, maintenance of the CSMS over time requires review and refinement of
the CSMS based on review results. Major inputs to this review are results from effectiveness
measures and audits of conformance from internal monitoring of the CSMS itself. Other inputs to
this review are external information about available countermeasures, evolving industry
practices, and new or changed laws or regulations.
A review of the CSMS identifies deficiencies and proposes improvements, which in turn creates
refinements to the CSMS. Some of these refinements may take the form of new
countermeasures or improvements in countermeasure implementation. Other refinements may

– 163 – ANSI/ISA–62443-2-1 (99.02.01)–2009
modify policies and procedures or improve their implementation. Review of poor conformance
results may point out the need for improvements in training or assignment of organizational
responsibilities.
Maintain the CSMS
Initiate CSMS
Monitor legal and program
regulatory constraints
(A.4.2.4)
Monitor industry High-level risk

practices assessment
(A.4.2.4)
Monitor available
Review the CSMS Refine the CSMS Detailed risk
countermeasures
(A.4.2.4) (A.4.2.6) assessment
(A.4.2.4)
Measure the
effectiveness of the Establish policy,
CSMS organization and
(A.4.2.4) awareness
Audit compliance to
the CSMS
(A.4.1) Select and implement
countermeasures
Figure B.8 – Activities and dependencies for activity: Maintain the CSMS

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 164 -
Bibliography
NOTE This bibliography includes references to sources used in the creation of this standard as well as references to
sources that may aid the reader in developing a greater understanding of cyber security as a wh ole and developing a
management system. Not all references in this bibliography are referred to throughout the text of this standard. The
references have been broken down into different categories depending on the type of source they are.
Standards references:
[1] ANSI/ISA–99.01.01–2007, Security for industrial automation and control syst ems:
Terminology, concepts and models”
[2] ANSI/ISA–TR99.01.02–2007, Security for Industrial Automation and Control Systems,

Technical Report 1: Security Technologies for Industrial Automation and Control Systems
– Referred to throughout this document as “ISA –TR99.01.02.”
[3] ANSI/ISA–99.02.02, Security for industrial automation and control syst ems: Operating an
industrial automation and control system security pro gram – Referred to throughout this
document as “ISA–99.02.02.”
[4] ISA–d99.03.01, Security for industrial automation and control systems: Technical security
requirements for industrial automation and control syst ems: Target security levels –
Referred to throughout this document as “ISA–d99.03.01.”
[5] ISA–d99.03.02, Security for industrial automation and control syst ems: Technical security
requirements for industrial automation and control sys tems: System security compliance
metrics – Referred to throughout this document as “ISA –d99.03.02.”
[6] ISA–d99.03.03, Security for industrial automation and control systems: Technical security
requirements for industrial automation and control syste ms: Allocation to subsystems and
components – Referred to throughout this document as “ISA –d99.03.03.”
[7] ANSI/ISA–95.00.01–2000, Enterprise-Control System Integration, Part 1: Models and

Terminology
[8] ISA–88.01–1995, Batch Control, Part 1: Models and Terminology
[9] ISO/IEC Directives, Part 2: 2004, Rules for the structure and drafting of International
Standards
[10] ISO/IEC 10746-1:1998, Information technology – Open Distributed Processing –

Reference model: Overview
[11] ISO/IEC 15408-1:2005, Information technology – Security techniques – Evaluation

criteria for IT security – Part 1: Introduction and general model

criteria for IT security – Part 2: Security functional requirements

criteria for IT security – Part 3: Security assurance requirements
[14] ISO/IEC 17799:2005, Information technology – Security techniques – Code of practice for
information security management – Referred to throughout this document as
“ISO/IEC 17799.”

--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

– 165 – ANSI/ISA–62443-2-1 (99.02.01)–2009
[15] ISO/IEC 27001:2005, Information technology – Security techniques – Information security

management systems – Requirements – Referred to throughout this document as
“ISO/IEC 27001.”
[16] 29 CFR 1910.119 – U.S. Occupational Safety and Health Standards – Hazardous
Materials – Process safety management of highly hazardous chemicals
Industry-specific and sector-specific references:
[17] Guidance for Addressing Cyber Security in the Chemical Sector, Version 3.0, May 2006,
American Chemistry Council’s Chemical Information Technology Center (ChemITC),
http://chemicalcybersecurity.com/cybersecurity_tools/guidance_docs.cfm – Referred
throughout this document as “ChemITC Guidance for Cyber Security.”
[18] Report on Cyber Security Vulnerability Assessments Methodologies, Version 2.0,

November 2004, ChemITC,
http://chemicalcybersecurity.com/cybersecurity_tools/guidance_docs.cfm – Referred to
throughout this document as “ChemITC Report on CSVA.”
[19] Cyber Security Architecture Reference Model, Version 1.0, August 2004, ChemITC,
http://chemicalcybersecurity.com/cybersecurity_tools/guid ance_docs.cfm – Referred to
throughout this document as “ChemITC Reference Model.”
[20] Report on the Evaluation of Cybersecurity Self -assessment Tools and Methods,
November 2004, ChemITC,
http://chemicalcybersecurity.com/cybersecurity_tools/guidance_docs.cfm – Referred to
throughout this document as “ChemITC Report on Self-assessment.”
[21] U.S. Chemicals Sector Cyber Security Strategy, September 2006,

http://chemicalcybersecurity.com/strategy/strategy.cfm
Other documents and published resources:
[22] Carlson, Tom, Information Security Management: Understanding ISO 17799, 2001,
http://www.responsiblecaretoolkit.com/pdfs/Cybersecurity_att3.pdf – Referred to
throughout this document as “Understanding ISO 17799.”
[23] Purdue Research Foundation, A Reference Model for Computer Integrated

Manufacturing, 1989, ISBN 1-55617-225-7
[24] NIST Special Publication 800-30, Risk Management Guide for Information Technology
Systems, July 2002 – Referred to throughout this document as “ NIST SP 800-30.”
[25] NIST Special Publication 800-37, Guide for the Security Certification and Accreditation of
Federal Information Systems, May 2004
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
[26] NIST Special Publication 800-55, Security Metrics Guide for Information Technology
Systems, July 2003 – Referred to throughout this document as “ NIST SP 800-55.”
[27] NIST Special Publication 800-61, Computer Security Incident Handling Guide , January
2004 – Referred to throughout this document as “ NIST SP 800-61.”
[28] NIST Special Publication 800-82, Guide to Supervisory Control and Data Acquisition
(SCADA) and Industrial Control System Security, March 2006, Draft – Referred to
throughout this document as “NIST SP 800-82.”
Copyright 2009 ISA. All rights reserved

ANSI/ISA-62443-2-1 (99.02.01)–2009 - 166 -
[29] NIST Process Control Security Requirements Forum (PCSRF), Industrial Control System
– System Protection Profile (ICS-SPP) – Referred to throughout this document as
“PCSRF ICS-SPP.”
[30] Carnegie Mellon Software Engineering Institute, Capability Maturity Model Integration
(CMMI) for Software Engineering, v1.1, August 2002 – Referred to throughout this
document as “CMMI-SW v1.1.”
Websites:
[31] NASA/Science Office of Standards and Technology (NOST),

http://ssdoo.gsfc.nasa.gov/nost/isoas/us04/defn.html
[32] Zachmann Enterprise Reference Model, http://www.zifa.com/
[33] Sarbanes – Oxley Web site, http://www.sarbanes-oxley.com/
[34] Sans Web site, http://www.sans.org/
[35] MIS Training Institute, http://www.misti.com/
[36] U.S. National Institute of Standards & Technology, http://www.nist.gov/
[37] Information Systems Technology Audit Programs, http://www.auditnet.org/asapind.htm
[38] NIST eScan Security Assessment, http://www.escan.nist.gov/sat/index.htm
[39] American National Standards Institute, http://www.ansi.org/
[40] IDEAL Model, http://www.sei.cmu.edu/ideal/ideal.html
[41] Control Objectives for Information and Related Technology (COBIT),

http://www.isaca.org/
[42] Corporate Governance Task Force “Information Security Governance - A call to action”
http://www.cyberpartnership.org/InfoSecGov4_04.pdf
[43] Michigan State Cybersecurity Definitions,

http://www.michigan.gov/cybersecurity/0,1607,7-217-34415---,00.html
[44] The Free Internet Encyclopedia – Wikipedia, http://www.wikipedia.org/
[45] Bridgefield Group Glossary, http://www.bridgefieldgroup.com/

--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---
[46] Six Sigma Information, http://www.onesixsigma.com/
[47] Carnegie Mellon Software Engineering Institute, http://www.sei.cmu.edu/
[48] Carnegie Mellon Software Engineering Institute, Computer Emergency Response Team
(CERT), http://www.cert.org/
[49] SCADA and Control Systems Procurement Project, http://www.msisac.org/scada/
[50] Interoperability Clearinghouse, http://www.ichnet.org/
[51] New York State Financial Terminology,

http://www.budget.state.ny.us/citizen/financial/audit.html

– 167 – ANSI/ISA–62443-2-1 (99.02.01)–2009
[52] Search Windows Security, http://www.searchwindowssecurity.com/
[53] Chemical Sector Cyber Security Program, http://chemicalcybersecurity.com/
[54] TechEncyclopedia, http://www.techweb.com/encyclopedia/
Copyright 2009 ISA. All rights reserved

--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

This page intentionally left blank.
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

Developing and promulgating technically sound consensus standards and recommended
practice is one of ISA’s primary goals. To achieve this goal the Standards and Practices
Department relies on the technical expertise and efforts of volunteer committee members,
chairmen and reviewers.
ISA is an American National Standards Institute (ANSI) accredited organization. ISA

administers United States technical Advisory Groups (USTAGs) and provides secretariat
support for International Electrotechnical Commission (IEC) and International
Organization for Standardization (ISO) committees that develop process measurement and
control standards. To obtain information on the Society’s standards program, please
write:
ISA
Attn: Standards Department
67 Alexander Drive
P.O. Box 12277
Research Triangle Park, NC 27709
ISBN: 978-1-934394-93-9
--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---


Isa 62443-2-1

Uploaded by

Copyright:

Available Formats

Isa 62443-2-1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Isa 62443-2-1

Uploaded by

Copyright:

Available Formats

--`,`,`,,`,,`,````,`,,``,,,`,`,,-`-`,,`,,`,`,,`---

Security for Industrial Automation

Copyright International Society of Automation

Copyright 2009 ISA. All rights reserved.

Copyright 2009 ISA. All rights reserved.

Copyright 2009 ISA. All rights reserved.

Name Company Contributor Reviewer

Richard Clark Invensys/Wonderware X

Copyright 2009 ISA. All rights reserved.

Copyright 2009 ISA. All rights reserved.

B.4 Activity: High-level risk assessment .................................................................... 158

Figure 1 – Graphical view of elements of a cyber security management system ................... 23

Copyright 2009 ISA. All rights reserved.

Table A.1 – Typical likelihood scale ...................................................................................... 61

Copyright 2009 ISA. All rights reserved.

The ISA99 Series 1 and the IEC

The ISA99 series includes the following:

 ANSI/ISA–99.01.01–2007 – Terminology, concepts and models

Copyright 2009 ISA. All rights reserved.

ISA values your input

Copyright 2009 ISA. All rights reserved.

Cyber security is an increasingly important topic in modern organizations. Many organizations

A cyber security management system for IACS

Management systems typically provide guidance on what should be included in a management

Relationship with ISO/IEC 17799 and ISO/IEC 27001

Copyright 2009 ISA. All rights reserved.

Copyright International Society of Automation

 Clause 1 describes the scope of this standard.

Copyright 2009 ISA. All rights reserved.

Copyright 2009 ISA. All rights reserved.

Copyright International Society of Automation

ANSI/ISA–99.01.01–2007 – Security for industrial automation and control systems: Terminology,

3 Terms, definitions, abbreviated terms, acronyms, and conventions

Copyright 2009 ISA. All rights reserved.

Copyright International Society of Automation

Copyright 2009 ISA. All rights reserved.

Copyright 2009 ISA. All rights reserved.

Copyright 2009 ISA. All rights reserved.

Copyright International Society of Automation

3.2 Abbreviated terms and acronyms

ANSI American National Standards Institute

CFR U.S. Code of Federal Regulations

ChemITC Chemical Information Technology Center of the American Chemistry Council

COTS Commercial off the shelf

CPU Central processing unit

Copyright 2009 ISA. All rights reserved.

CSCSP Chemical Sector Cyber Security Program

CSMS Cyber security management system

CSVA Cyber security vulnerability assessment

DCS Distributed control system

DoS, DDoS Denial of service, Distributed denial of service

FDN Field device network

FTP File transfer protocol

HMI Human machine interface

HSE Health, safety, and environmental

HVAC Heating, ventilation, and air-conditioning

IACS Industrial automation and control system(s)

IEC International Electrotechnical Commission

IEEE The Institute of Electrical and Electronics Engineers