1
2
3
4
5
6
7
8
9
TECHNICAL REPORT
ISA-TR84.00.09-2023 Part 1
Cyber Security Related to the
Safety Lifecycle
Master Review Copy Rev 5.4, 3 rd Edition
22 December 2022
10
11
ISA-TR84.00.09-2023 Part 1, Cyber Security Related to the Safety Lifecycle
ISBN: 978-1-945541-49-0
Copyright © 2020 by ISA. All rights reserved. Not for resale. Printed in the United States of
America.
ISA
67 Alexander Drive
P. O. Box 12277
Research Triangle Park, NC 27709 USA
ISA-TR84.00.09-2023
-2-
PREFACE
This preface, as well as all footnotes and annexes, is included for information purposes and is not
part of ISA-TR84.00.09-2023 Part 1.
This document has been prepared as part of the service of ISA, the International Society of
Automation, 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 addr essed to the Secretary,
Standards and Practices Board; ISA; 67 Alexander Drive; P. O. Box 12277; Research Triangle
Park, NC 27709; Telephone (919) 549-8411; Fax (919) 549-8288; E-mail: standards@isa.org.
It is the policy of ISA to encourage and welcome the participation of all concerned individuals and
interests in the development of ISA standards, recommended practices and technical reports.
Participation in the ISA standards-making process by an individual in no way constitutes
endorsement by the employer of that individual, of ISA or of any of the standards, recommended
practices and technical reports that ISA develops.
CAUTION — ISA 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 FOR 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, NONDISCRIMINATORY 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 THAT MAY IMPACT IMPLEMENTATION OF THE DOCUMENT NOTIFY THE ISA
STANDARDS AND PRACTICES DEPARTMENT OF THE PATENT AND ITS OWNER .
ADDITIONALLY, THE USE OF THIS DOCUMENT MAY INVOLVE HAZARDOUS MATERIALS,
OPERATIONS OR PROCESS EQUIPMENT. THE DOCUMENT CANNOT ANTICIPATE ALL
POSSIBLE APPLICATIONS OR ADDRESS ALL POSSIBLE SAFETY ISSUES ASSOCIATED
WITH USE IN HAZARDOUS CONDITIONS. THE USER OF THIS TECHNICAL REPORT SHOULD
EXERCISE SOUND PROFESSIONAL JUDGMENT CONCERNING ITS USE AND
APPLICABILITY UNDER THE USER’S PARTICULAR CIRCUMSTANCES. THE USER SHOULD
ALSO CONSIDER THE APPLICABILITY OF ANY GOVERNMENTAL REGULATORY
LIMITATIONS AND ESTABLISHED SAFETY AND HEALTH PRACTICES BEFORE
IMPLEMENTING THIS TECHNICAL REPORT.
ISA (www.isa.org) is a nonprofit professional association that sets the standard for those who apply
engineering and technology to improve the management, safety, and cyber security of modern
ISA-TR84.00.09-2023
-3-
automation and control systems used across industry and critical infrastructure. Founded in 1945,
ISA develops widely used global standards; certifies industry professionals; prov ides education
and training; publishes books and technical articles; hosts conferences and exhibits; and provides
networking and career development programs for its 40,000 members and 400,000 customers
around the world.
ISA owns Automation.com, a leading online publisher of automation-related content, and is the
founding sponsor of The Automation Federation ( www.automationfederation.org), an association
of non-profit organizations serving as "The Voice of Automation." Through a wholly owned
subsidiary, ISA bridges the gap between standards and their implementation with the ISA Security
Compliance Institute (www.isasecure.org) and the ISA Wireless Compliance Institute
(www.isa100wci.org).
The following people served as active members of ISA84, Working Group 09 during the preparation
of this document:
Name
Company
Contributor
Reviewer
Adam Hahn
Mitre
X
Aditya Srivastava
X
Alireza Sahraei
Ernst & Young Global Consulting
Services
Safety & Analytics Consulting Inc.
Andy Bhojani
BP
Andy Bochman
INL
Arnaud Soullie
Wavestone
X
Brad Bonnette
Wood PLC
X
Bryan Clemenz
Jacobs
X
Camilo Gomez
Yokogawa
X
Cory Myer
Aker BioMarine
X
Dan Ehrenreich
X
David Deibert
Secure Communications and Control
Experts
Air Products
X
Dominic De-kerf
Cargill
X
Dustin Bryant
Sensia
Ed Marszal
Kenexis
Eric Jandik
Chevron
Ernie Hayden
Jacobs
X
Estevez-Reyes Leoncio
Honeywell
X
Farshad Hendi
Schneider Electric
Gabriel Faifman
Schneider Electric
Gary Rathwell
Glenn Merrell
Enterprise Consultants International
Freelance Consulting
Greg Hudson
Metcalf
Hal Thomas
HWT Consulting LLC
X
Hanan Husain
Engro
X
Herman Storey
Herman Storey Consulting LLC
X
Holger Laible
Siemens
X
Isiah Jones
Applied Integrated Technologies (AIT)
X
Jana Kallambettu
Bechtel
X
X
X
X
X
X
X
X
X
X
X
X
ISA-TR84.00.09-2023
-4-
Jawahar Kumar Murugiah
Petroleum Development Oman
Jens Braband
Siemens
Jim Gilsinn
Dragos
X
Jim McGlone
Kenexis
X
Joe Weiss
Applied Control Solutions, LLC
X
Johan Nye
ICS Guru LLC
X
John Cusimano
AESolutions
John Day
Air Products
Kamil Arshad
Petronas
Ken Masica
INL
Kishor Senjaliya
SIS Consultant
X
Marcelo Mollicone
Sym PCS Consultoria LTDA
X
Matt Vickers
Consultarc
Michael Thompson
Mitre
Mike Engineer
X
X
X
X
X
X
X
X
Mazda Engineered Solutions
X
Monica Hochleitner
SISsilverstone
X
Murli Balsubramanian
ExxonMobil
Omar Al-Asam
Saudi Aramco
Otis Alexander
Mitre
X
Palaniappan Kannan
R and R Consultant
X
Peter Kaloroumakis
Mitre
X
Prasad Goteti
Honeywell Process Solutions
X
Rajiv Jain
ExxonMobil
X
Sami Elmurr
Hunter Strategy LLC
Sanjay Chhillar
Air Products
Sarah Fluchs
admeritia
X
Sarah Freeman
INL
X
Simon Clarke
Costain Upstream Ltd.
X
Sinclair Koelemij
Honeywell Connected Enterprise
X
Stephanie Saravia
ExxonMobil
X
Tadaaki Ando
Yokogawa
X
Todd Brent Davis
Vestas
X
Tom Cottle
Mitre
Vytautas Butrimas
NATO Energy
Excellence
Yahya Nazer
Control Designer LLC
Zhengren Zhou
Shell
X
X
X
X
X
Security
Centre
of
X
X
X
The following served as members of the Standards and Practices Board and approved the
document on dd mmm yyyy:
NAME
AFFILIATION
ISA-TR84.00.09-2023
-5-
ISA-TR84.00.09-2023
-6-
CONTENTS
FOREWORD ........................................................................................................................ 12
0
Introduction .................................................................................................................... 13
1
0.1 Executive summary ............................................................................................... 13
0.2 Integrated lifecycle ................................................................................................ 13
0.3 Safety versus cyber security considerations .......................................................... 16
Scope ............................................................................................................................ 18
2
References .................................................................................................................... 19
3
Terms, definitions, abbreviated terms, acronyms, and conventions ................................ 20
4
3.1 Terms and definitions ............................................................................................ 20
3.2 Security Levels and Security Protection Ratings ................................................... 26
3.3 Abbreviated terms and acronyms .......................................................................... 27
Management of PSCAI cyber security in the process sector ........................................... 29
5.
4.1 Objective .............................................................................................................. 29
4.2 Guidelines ............................................................................................................. 29
Project Scope Development ........................................................................................... 43
6
5.1. Specification and System under Consideration (SuC) ............................................ 43
5.1.1. Purpose ................................................................................................................ 44
5.1.2. Input and Guidance ............................................................................................... 44
5.1.2.1.
Specification ............................................................................................. 44
5.1.2.2.
System under Consideration (SuC) ........................................................... 45
5.1.2.3.
Supplier Qualification ................................................................................ 45
5.1.3. Output ................................................................................................................... 46
Hazard and Risk Analysis .............................................................................................. 47
7
6.1 Safety Hazard and Risk Assessment ..................................................................... 47
6.2 Allocation of Safety Functions to Protection Layers ............................................... 47
6.3 Initial Cybersecurity Risk Assessment ................................................................... 48
6.4 Partition the SuC into Zones and Conduits ............................................................ 50
6.5 Initial Safety Requirements Specification (SRS) .................................................... 51
6.6 Detailed Cybersecurity Risk Assessment .............................................................. 54
Requirements Specification ............................................................................................ 63
7.1
8
Cybersecurity Requirements Specification (CRS) and consolidation with Safety
Requirements Specification (SRS) ........................................................................ 63
Stage 1 Preliminary Design Assessment ........................................................................ 63
9
Detailed Design & Procedure Development .................................................................... 64
9.1
9.2
9.3
9.4
9.5
9.6
Inputs ................................................................................................................... 65
Roles / Training / Competence .............................................................................. 66
Detailed Engineering ............................................................................................. 74
9.3.1 Sizing and Selection of Equipment ............................................................... 74
Procedure Development ........................................................................................ 83
Security Protection Rating (SPR) Verification ........................................................ 89
Design Documentation (Outputs/Deliverables) ...................................................... 90
ISA-TR84.00.09-2023
-7-
10 Stage 2 Detailed Design Assessment ............................................................................. 91
11 Implementation .............................................................................................................. 92
11.1 Inputs ................................................................................................................... 93
11.2 Roles / Training / Competence .............................................................................. 93
11.3 Contract Execution ................................................................................................ 96
11.4 System Integration – Planning .............................................................................. 97
11.5 Construction ......................................................................................................... 98
11.6 Factory Acceptance Test (FAT) ............................................................................. 98
11.7 Installation and Commissioning ............................................................................. 99
11.8 Site Acceptance Test (SAT) ................................................................................ 102
11.9 Initial Validation of Security Measures ................................................................. 103
11.10 Deliverables ........................................................................................................ 104
12 Stage 3 Assessment - Pre-Startup Safety Review (PSSR) ............................................ 105
13 Operation and Maintenance ......................................................................................... 106
13.1 Operation ............................................................................................................ 107
13.2 Maintenance ....................................................................................................... 110
13.3 Audits and Assessments ..................................................................................... 115
13.4 Security Monitoring and Performance Measurement ............................................ 117
13.5 Incident Management .......................................................................................... 119
14 Stage 4 Assessment - Periodic assessments ............................................................... 119
15 Stage 5 Assessments: Management of Change / Decommissioning ............................. 121
15.1
15.2
15.3
Annex A
Management of Change ...................................................................................... 122
Decommissioning ................................................................................................ 126
Assessing the Stage 5 Work Process .................................................................. 128
- Maturity Level Assessment ................................................................................. 130
Introduction .................................................................................................................. 130
Overall Assessment Work Process ............................................................................... 130
Maturity Level Assessment Procedure .......................................................................... 131
Security Program Maturity Level Assessment Attributes ............................................... 134
ML Assessment Documentation ................................................................................... 137
Annex B - Cyber security Assessment Stage Check List Templates .................................... 139
Cybersecurity Assessment (CSSA) 1 Check List .......................................................... 140
Cybersecurity Stage Assessment (CSSA) 2 Check List ................................................ 142
Cybersecurity Stage Assessment (CSSA) 3 Check List ................................................ 145
Cybersecurity Stage Assessment (CSSA) 4 Check List ................................................ 148
Cybersecurity Stage Assessment (CSSA) 5 Check List ................................................ 151
Annex C – Vulnerability Identification Methodologies .......................................................... 153
Vulnerability Identification Methods Overview............................................................... 154
C.1 Device technical capability gap analysis ................................................................ 156
Summary ............................................................................................................ 156
Methodology description / procedure ................................................................... 156
C.2 Device vulnerability (Software and firmware flaw) identification ............................. 158
Summary ............................................................................................................ 158
ISA-TR84.00.09-2023
-8-
Methodology description / procedure ................................................................... 158
C.3 System technical capability gap analysis ............................................................... 159
Summary ............................................................................................................ 159
Methodology description / procedure ................................................................... 159
C.4 Procedural capability gap analysis ......................................................................... 161
Summary ............................................................................................................ 161
Methodology description / procedure ................................................................... 161
C.5 IACS architecture vulnerability identification .......................................................... 163
Summary ............................................................................................................ 163
Methodology description / procedure ................................................................... 163
C.6 System integration vulnerability identification ......................................................... 164
Summary ............................................................................................................ 164
Methodology description / procedure ................................................................... 164
Annex D – Risk Assessment Methodologies ....................................................................... 165
Introduction .................................................................................................................. 165
Risk Assessment Methodologies Overview ................................................................... 167
D.1 Asset Focused Cyber Risk Assessment ................................................................. 172
Summary ............................................................................................................ 172
Methodology description / procedures ................................................................. 172
D.2 Function Focused Cyber Risk Assessment ............................................................ 173
Summary ............................................................................................................ 173
Methodology description / procedure ................................................................... 173
D.3 Quantitative Function Based Cyber Risk Assessment ............................................ 176
Summary ............................................................................................................ 176
Methodology description ..................................................................................... 176
D.4 CFATS Site Vulnerability Assessment .................................................................... 188
Summary ............................................................................................................ 188
Methodology description / procedure ................................................................... 188
D.5 Consequence-driven, cyber-informed Engineering (CCE) ...................................... 189
Summary ............................................................................................................ 189
Methodology description / procedure ................................................................... 189
D.6 Security PHA Review for Consequence Based Cybersecurity ................................ 193
Summary ............................................................................................................ 193
Methodology description / procedure ................................................................... 193
Example Security PHA Review for Consequence Based Cybersecurity Study ..... 195
D.7 Cyber PHA Risk Assessment ................................................................................. 197
Summary ............................................................................................................ 197
Methodology description / procedure ................................................................... 198
D.8 CHAZOP (Integrated safety / security) ................................................................... 202
Summary ............................................................................................................ 202
Methodology description / procedure ................................................................... 203
D.9 Cyber Kill Chain ..................................................................................................... 206
Summary ............................................................................................................ 206
Methodology description / procedure ................................................................... 206
ISA-TR84.00.09-2023
-9-
D.10 Sneak Path Analysis ............................................................................................ 207
Summary ............................................................................................................ 207
Methodology description / procedure ................................................................... 207
D.11 Cyber Event Tree ................................................................................................. 208
Summary ............................................................................................................ 208
Methodology description / procedure ................................................................... 208
D.12 Cyber-attack Tree ................................................................................................ 209
Summary ............................................................................................................ 209
Methodology description / procedure ................................................................... 209
D.13 Check Lists .......................................................................................................... 211
Summary ............................................................................................................ 211
Methodology description / procedure ................................................................... 211
Annex E – Defense in Depth / Security Measures ............................................................... 214
Cyber Kill Chain / Defense in Depth ............................................................................. 214
Example Security Measures ......................................................................................... 215
Security Measures as a Function of Kill Chain Phases ................................................. 221
MITRE ATT&CK ® for ICS Framework Description / Procedure ............................. 223
Annex F – Data Flow Analysis ............................................................................................ 227
Analysis of Data Flow Methodology .............................................................................. 227
Data Exchange Worksheet Template ............................................................................ 227
Data Exchange Worksheet Table Input Descriptions .................................................... 228
Electrical Connection Type Security Capability Estimates ............................................ 230
Communication Protocol Security Capability Estimates ................................................ 230
Data Flow Summary Documentation Template ............................................................. 242
Annex G - Cybersecurity Requirements Specification (CRS) Template ............................... 244
General Security Requirements .................................................................................... 244
System under consideration (SUC) description ................................................... 244
Asset Inventory ................................................................................................... 245
Regulatory requirements ..................................................................................... 246
Adopted industry standards ................................................................................. 247
Organizational security policies ........................................................................... 248
Security measures .............................................................................................. 250
Human Resources............................................................................................... 251
Supply Chain ...................................................................................................... 251
Corporate risk criteria ......................................................................................... 252
Zone and conduit drawings ................................................................................. 252
Threat environment ............................................................................................. 252
Testing 253
Zone Specific Requirements......................................................................................... 254
Zone and conduit characteristics ......................................................................... 254
Annex H − Manufacturer Security Manuals ......................................................................... 257
Recommended Architectures ........................................................................................ 257
Compatibility / Supportability ........................................................................................ 257
Suppliers Recommended Hardening practices ............................................................. 258
ISA-TR84.00.09-2023
- 10 -
Security Level Capability .............................................................................................. 258
Required / Recommended diagnostics ......................................................................... 261
Recommended Testing Procedures .............................................................................. 261
Support end of life ........................................................................................................ 261
Annex I − Security Protection Rating (SPR) Verification ...................................................... 262
Purpose ....................................................................................................................... 262
Overview ...................................................................................................................... 262
Procedure .................................................................................................................... 262
Annex J – Testing ............................................................................................................... 264
Introduction .................................................................................................................. 264
Work Process ............................................................................................................... 264
Identification of Tests ................................................................................................... 265
D3FEND ............................................................................................................. 265
Other Test Selection Guidance ........................................................................... 270
Test Descriptions ................................................................................................ 271
Example Check List ..................................................................................................... 277
Sample Issue/Defect/Anomaly Form ............................................................................. 283
Annex K – Example Audit Form(s) ...................................................................................... 284
Annex L - Cybersecurity KPIs and Metrics .......................................................................... 286
Introduction .................................................................................................................. 286
Sample Performance KPIs and Metrics ........................................................................ 287
Organizational security measures ....................................................................... 288
ORG 2 - Security assessments and reviews ........................................................ 291
ORG 3 - Security of physical access ................................................................... 294
Org 4 – Supply Chain .......................................................................................... 295
Configuration management ................................................................................. 296
NET 1 - System segmentation ............................................................................. 297
NET 2 - Secure wireless access .......................................................................... 298
NET 3 - Secure remote access ............................................................................ 299
COMP 1 - Devices and media ............................................................................. 300
COMP 2 - Malware protection ............................................................................. 302
COMP 3 - Patch management ............................................................................. 304
DATA – Data protection ...................................................................................... 305
USER 1 - Identification and authentication .......................................................... 306
USER 2 - Authorization and access control ......................................................... 307
Event and incident management ......................................................................... 311
AVAIL 1 - System availability and intended functionality ...................................... 314
AVAIL 2 - Backup / restore / archive ................................................................... 317
Annex M - Job Cyber Assessment ...................................................................................... 319
Annex N – Security of Field Devices and Their Interface within the IACS ............................ 322
Introduction .................................................................................................................. 322
Block diagrams ................................................................................................... 323
Current Status Including Deficiencies ........................................................................... 323
General Protocol and device deficiencies ............................................................ 323
ISA-TR84.00.09-2023
- 11 -
Present Network Types and Protections .............................................................. 324
Safety Protocols .................................................................................................. 326
Legacy Digital Including Routable Legacy Digital Protocols ................................. 327
Certification.................................................................................................................. 329
Types of certifications ......................................................................................... 330
Certification supplements and effects .................................................................. 330
Summary of Certifications ................................................................................... 331
Mitigation and Management (Compensating Security measures) .................................. 331
Isolation or “Air Gapping” .................................................................................... 331
Continuous Monitoring ........................................................................................ 332
Configuration management ................................................................................. 332
Administrative procedures ................................................................................... 333
Long Term Solutions .................................................................................................... 333
Network Management ......................................................................................... 333
Configuration Management ................................................................................. 334
Internal (Device) Security / Perimeter Security .................................................... 335
History and perimeter security ............................................................................. 335
Internal device and protocol security ................................................................... 336
New and improved internal security tools ............................................................ 336
Summary ..................................................................................................................... 337
Bibliography ....................................................................................................................... 338
ISA-TR84.00.09-2023
- 12 -
FOREWORD
This technical report is part of a series of standards and technical reports that address the issue
of safety instrumented system security. It has been developed by Working Group 9 of the ISA84
committee in cooperation with the ISA99 committee.
This technical report provides guidance on how to implement cyber security within the IEC-61511
and ISA-84.00.01-2004 lifecycle. This is the third issue of this technical report. Members of the
ISA84 and ISA99 committees contributed to this effort.
Readers of this technical report are asked to send comments on the content and suggestions for
coverage in future revisions to the following email address:
standards@isa.org
ISA-TR84.00.09-2023
- 13 -
1
2
0
Introduction
3
0.1
Executive summary
4
5
6
7
8
9
10
11
12
13
14
15
Safety Instrumented Systems (SIS) represent one layer of protection that may be implemented to
protect against hazards and reduce risk within the process industry. Other layers of protection may
consist of instrumented systems performing alarms, interlocks, permissive functions, or controls
using devices within the basic process control system (BPCS), as well as non-instrumented
systems such as relief devices, check valves, etc. Traditional process hazard analysis (PHA), in
the past, has generally excluded the potential for cyber related attacks to cause process safety
incidents. Given that targeted attacks on industrial automation and control systems (IACS),
including the systems executing Process Safety Controls, Alarms, and Interlocks (PSCAI), have
occurred and these systems are increasingly being connected to other business systems, cyber
vulnerabilities represent a significant potential for common cause failure (CCF) as well as other
process system failures that can lead to process safety events. As a result, it is necessary to
include cyber risk as part of the overall PHA considerations.
16
17
18
It is not possible to understand the relative independence and integrity of the various layers of
protection that involve instrumented systems, including the SIS, without addressing cyber security
throughout the entire safety lifecycle.
19
20
21
22
23
24
25
The underlying premise of this document is to help the reader understand the value and means to
integrate cyber security into the overall safety lifecycle. Guidance is provided on how to specify,
implement, operate, and maintain PSCAI in a secure manner. As part of this integration, it should
also be understood that achieving higher security protection ratings (SPR) may result in less
convenience to the end user. Addressing cyber security and safety of the PSCAI systems within
the IACS means considering both the ISA 84 and ISA 62443 series of standards, which is the
intent of this document.
26
0.2
27
28
29
30
The work process to ensure security of the IACS should account for the entire lifecycle involving
both safety and security. According to ANSI/ISA-61511-1-2018, it is necessary to address all
lifecycle phases from initial concept, design, implementation, operation, and maintenance to
decommissioning.
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
Figure 0.1 seeks to show, at a high level, an example of how safety and cyber security can integrate
within the overall safety lifecycle. Although the NIST (National Institute of Standards and
Technology) framework is not the only one that can be selected, it was us ed as a quality assurance
tool when developing this technical report to help ensure any potential gaps were minimized. The
overall result is an example of a single process safety management process, incorporating IEC 61511, ANSI/ISA-61511-1-2018, ANSI/ISA-84.91.01, and applicable ANSI/ISA-62443 series of
standards. Additional lifecycle details are provided throughout this technical report. The lifecycle
figures in this technical report are an interpretation and there may be other appropriate means to
address the ANSI/ISA-61511-1-2018 lifecycle with respect to safety and cyber security. It should
also be recognized that different functional disciplines based on necessity be responsible for
various aspects of the lifecycle. This technical report is mainly targeted at the asset owner’s
management and operational technology (OT) personnel, e.g., process control, process safety,
operations, electrical, and control network engineers, so that the impact of cyber security with
regards to process safety can be better understood as well as to help understand the necessary
relationship with information technology (IT) personnel. While not directly targeted at IT personnel,
they may find this document useful regards the relationship between safety and cyber security
within the process industry.
Integrated lifecycle
The Management of Process Safety & Cybersecurity
ISA-TR84.00.09-2023
- 14 -
Conceptual Design & Scope
Process Safety
Cybersecurity
Assessment
(PHA)
Assessment
(CyberPHA)
Design &
Implement
Design &
Implement
Operate &
Maintain
Operate &
Maintain
NIST Framework
Recover
Respond
Identify
Industry Stds
Regulatory Req
Supplier Capabilities
IACS Capabilities
IT/OT Capabilities
Monitoring Capability
Tools Capabilities(O&M)
Useful Life
Protect
Detect
48
49
50
Figure 0.1
Cyber security lifecycle integrated with process safety management
51
52
53
54
55
In Figure 0.2 below, integration of cyber security with the safety li fecycle is shown with relevant
references to applicable industry standards. The lifecycle in this technical report used the
ANSI/ISA-61511-part 1 lifecycle as a foundation and then integrated some key cyber security
concepts. Many of the major boxes represent the aggregation of sub work processes that have
been expanded within their respective sections of this technical report.
ISA-TR84.00.09-2023
- 15 -
Define Project Scope
Hazard and Risk Assessment
Allocation of safety and security
protection functions
ISA 62443-2-1
ISA 61511-1, ISA 62443-2-1, ISA 62443-3-2
ISA 61511-1, ISA 62443-3-2
Tolerable Risk?
Document requirements
Stage 1 Assessment
Quality control check of work process
Management System
ISA 61511-1, ISA 62443-2-1
Preliminary Design Verification
Detailed Design & Procedure
Development
Stage 2 Assessment
Quality control check of work process
Stage 3 Assessment (PSSR)
Startup
57
58
59
ISA 61511-1
ISA 61511-1, ISA 62443-2-2
Tolerable Risk?
System Implementation
(buy/build/configure)
56
ISA 61511-1, ISA 62443-2-1, ISA 62443-3-2
ISA 61511-1, ISA 62443-2-1, ISA 62443-2-4, ISA 62443-3-3,
ISA 62443-4-2
ISA 61511-1
ISA 61511-1, ISA 62443-2-1, ISA 62443-2-3, ISA 62443-2-4,
ISA 62443-3-3, ISA 62443-4-2
Process Safety Management Regulations, ISA 61511-1
ISA 61511-1
Operation / Maintenance
ISA 61511-1, ISA 62443-2-1, ISA 62443-2-3, ISA 62443-2-4,
ISA 62443-3-3
Stage 4 Assessment
PHA Revalidation
ISA 61511-1, ISA 62443-2-1, ISA 62443-2-2,ISA 62443-2-4,
ISA 62443-3-2, ISA 62443-3-3, ISA 62443-4-2
Stage 5 Assessment
Management of Change Including
Decommissioning
ISA 61511-1, ISA 62443-2-1, ISA 62443-2-2, ISA 62443-2-3,
ISA 62443-2-4, ISA 62443-3-2, ISA 62443-3-3, ISA 62443-4-2
Figure 0.2
Generalized Integration of Safety / Security Lifecycle
ISA-TR84.00.09-2023
- 16 -
60
0.3
61
62
63
64
65
66
67
68
69
70
71
Traditionally, different disciplines have dealt with safety and cyber security with not much overlap.
It should be recognized that neither safety nor information technology are independent of one
another. It is important for Asset Owner management, as well as OT personnel such as process
control engineers, electrical engineers, IACS network engineers, operations, maintenance,
process engineering, and process safety understand the differences as well as the overlaps with
IT personnel so that jointly, appropriate best practices can be employed and any culture of “Us
versus Them” can evolve into” We”. Asset Owner management being the relevant decision-makers
should emphasize (i.e., lead) the "We" work culture. Security is a team effort as is safety, therefore,
like safety each discipline must understand how their contributions improve the overall security of
IACS. As such, it is important to understand the typical differences in how the IT professional tends
to view their requirements versus how OT engineers view theirs.
72
73
74
Successful cyber security programs consider the differences and overlaps between traditional
roles and the additional IACS cyber security roles to develop a cohesive integrated program that
delivers on all the needs.
75
76
Table 0.1 below contrasts IACS cyber security versus some elements of process safety as a
function of some elements of the safety lifecycle.
77
Safety versus cyber security considerations
ISA-TR84.00.09-2023
78
79
- 17 -
Table 0.1
Comparison of safety and IT cyber security in IACS using a lifecycle approach
Lifecycle Phase
Hazard & Risk
Analysis
IACS Cyber security
Target of
evaluation
Equipment under control
System under Consideration (SuC) using
Zones and Conduits based on logical
grouping of assets and data flows
Failure Likelihood
•
Random failures due to operational
and environmental stresses
Threats: Internal, external or a combination
taking advantage of vulnerabilities due to
•
Systematic failures due to errors
during safety life cycle
•
Component, system, or network design
flaws
•
Making non-validated changes
•
Not following security practices and
procedures
•
Failures caused by threats exploiting
vulnerabilities
Consequence
Severity
Impact on environment, health and safety
of personnel, the public, financial loss, and
loss of production availability
Impact on environment, health and safety of
personnel, the public, financial loss, loss of
production availability and/or loss of data
integrity
Risk
Categorization
•
Based on likelihood and severity; risk
may be quantified
•
•
Risk tolerance based on
corporate risk criteria
Based on likelihood and severity of
multiple threats and vectors; risk may be
quantified, but currently is generally
qualitative
•
SL targets are assigned to zones
and should be based on corporate
risk criteria
•
Relies on security measures within
Zone, within Conduits connected to the
Zone, and defense in depth concept
•
Security measures reduce likelihood of
consequence(s) evaluated
•
Identifies requirements for security
measures to meet the Zone Target SL
and SPR
Risk Mitigation
Measures
Implementation of Measures
Operation and Maintenance
Management System
80
Process Safety
•
Relies on independent protection
layers concept
•
Safeguards reduce likelihood of
consequence evaluated
•
Identifies integrity requirements for
safeguards; for a safety
instrumented function (SIF) assigns
target safety integrity level (SIL)
•
Safety manual for components
•
Security manual for components
•
Quantitative SIL verification for SIF
•
Zone security level capability
verification of zone SL targets by
demonstrated compliance with
foundational requirements and
physical access control as well as
personnel security measures
commensurate with zone SL target
•
Restrict access to IACS components
to competent personnel with
necessary access privileges
•
Restrict access to IACS components to
competent personnel with necessary
access privileges
•
Periodic testing of safeguards
•
Periodic testing of security measures
•
Demand rate and component failures
to be monitored
•
•
Awareness and training
Frequent reviews to identify new
vulnerabilities and take appropriate
action, if necessary
•
Management of change
•
Awareness and training
•
Periodic process hazard analysis
revalidation
•
Management of change
•
Periodic cyber risk reassessment
Defines requirements for competency,
training, verification, testing, audit, MOC
(including patch management), and
documentation
Defines requirements for competency,
training, verification, testing, audit, MOC
(including patch management), and
documentation
ISA-TR84.00.09-2023
- 18 -
81
1
Scope
82
83
84
85
86
The intent of this document is to address and provide guidance for the integration of cyber security
into the safety lifecycle as they relate to PSCAI, inclusive of Safety Instrumented Systems (SIS).
This scope includes the work processes and security measures used throughout the life of a facility
from conceptual design to decommissioning to reduce the risk from cyber security threats to the
Industrial Automation and Control System (IACS) to levels deemed tolerable by the Asset Owner .
87
88
From an IACS perspective, the scope includes a reference model the includes levels 0 through 3.5
as shown in Figure 0.3.
Responsibility
IT
Joint IT/OT
Level 4
Business Enterprise System
Level 3.5
Demilitarized Zone or Interface between
IT & OT networks
Industrial Automation and Control System
Level 3
Operations / Systems Management
IIOT/Cloud
IIOT/Cloud
Cloud
Supervisory
Control
Site Monitoring &
Display
IIOT/Cloud
Safety & Protection
(e.g. SIS, HIPPS, etc.)
IIOT/Cloud
Level 2
OT/
Engineering
Level 1
Level 0
Basic Process
Control
Process Equipment Under Control (Field
Equipment)
IIOT/Cloud
89
90
91
Figure 1.0
Reference Model
92
93
94
95
96
97
98
99
This scope provides recommendations to ensure PSCAI are adequately secure due to the potential
for cyber-attacks. These can act like common cause failures that initiate hazardous scenarios while
also preventing instrumented protection functions, including the SIS, from performing their
intended purpose. The scope intends to address cyber security from both external and internal
threats. Although not directly within the scope, enterprise networks/business networks that
interface with the IACS network represent a threat vector to the PSCAI systems or contain security
measures that reduce the risk to the PSCAI systems from external cyber threats. As such, the
interface or the portion that overlaps between operational technology (OT) responsible for the
ISA-TR84.00.09-2023
- 19 -
100
101
102
design, operation, maintenance of the facility and informat ion technology (IT) responsible for
corporate enterprise IT functions is included in the scope and can be considered a joint
responsibility.
103
104
Whenever remote activities or cloud applications perform functions at any level from 0 through 3.5
are performed, they are part of the scope.
105
106
107
108
The scope does not address non-cyber related physical plant protection (for example, fences,
bollards, and grounding) that has the intent of preventing unauthorized entry into the plant to
prevent theft, vandalism, or physical damage, but does address physical access issues related to
cyber security of the IACS.
109
2
110
111
112
113
The following documents are important for understanding this technical report. For dated
references, only the edition cited applies. For undated references, the latest edition of the
referenced document (including any amendments) applies. For information on obtaining ISA
standards and technical reports, visit: www.isa.org/findstandards
114
115
116
In addition, readers should be aware of the ongoing development of additional standards in the
ISA-62443 series, Security for Industrial Automation and Control Systems , listed in the
Bibliography. For an update on the status of these standards, visit https://www.isa.org/isa99/.
117
118
•
ANSI/ISA-61511-1, Functional Safety: Safety Instrumented Systems for the Process Industry
Sector – Part 1: Framework, Definitions, System, Hardware, and Software Requirements.
119
120
•
ANSI/ISA-84.91.01, Identification and Mechanical Integrity of Safety Controls, Alarms, and
Interlocks in the Process Industry.
121
122
•
ANSI/ISA 62443-2-1, Security for industrial automation and control systems – Part 2-1:
Establishing an Industrial and automation control system security program.
123
124
•
ANSI/ISA-62443-2-4, Security for industrial automation and control systems, Part 2 -4:
Security program requirements for IACS service providers.
125
126
•
ANSI/ISA 62443-3-2, Security for industrial automation and control systems: Security risk
assessment for system design.
127
128
•
ANSI/ISA 62443-3-3, Security for industrial automation and control systems: System security
requirements and security levels.
129
130
•
ANSI/ISA-62443-4-2, Security for industrial automation and control systems, Part 4 -2:
Technical security requirements for IACS c omponents.
131
References
ISA-TR84.00.09-2023
- 20 -
132
3
Terms, definitions, abbreviated terms, acronyms, and conventions
133
3.1
Terms and definitions
air gap
Absence of a direct or indirect connection between a computer and the internet.
Note 1 to entry: An air gap is not an inherently secure technical solution
Note 2 to entry: Inherently more secure air gap solutions would include:
•
Not allowing installation of any software or firmware that had been downloaded from the internet or from
portable media
•
Using firmware that cannot be configured, i. e., non-flashable firmware.
[Source: ISA-TR84.00.09, 3 rd edition]
alarm
Audible and/or visible means of indicating to the operator an equipment malfunction, process
deviation, or abnormal condition requiring a timely response
[Source: ANSI/ISA-18.2: 2016]
alert
Audible and/or visible means of indicating to the operator an equipment or process condition
that requires awareness, and which does not meet the criteria for an alarm
[Source: ANSI/ISA-18.2-2016]
asset
Physical or logical object owned by or under the custodial duties of an organization, having
either a perceived or actual value to the organization.
Note 1 to entry: In the case of industrial automation and control systems the physical assets that have the largest
directly measurable value may be the equipment under control.
Note 2 to entry: assets may be digital assets, physical and virtual endpoints, associated operating systems,
software applications, services, microservices, and orchestration of any of those assets.
[Source: ANSI/ISA-62443-1-1]
backdoor
Means to access system or device software bypassing the installed security mechanism(s).
Note 1 to entry: A developer may create a backdoor so that an application or operating system can be accessed for
troubleshooting or other purposes.
Note 2 to entry: A person, organization or state may create a backdoor so that an application or operating system
can be accessed for malicious purposes.
[Source: ISA-TR84.00.09, 3 rd edition]
boundary
See zone boundary
boundary (edge) device
See zone boundary (edge) device
basic process control system (BPCS)
System which responds to input signals from the process, its associated equipment, other
programmable systems and/or operators and generates output signals causing the process
and its associated equipment to operate in the desired manner but which does not perform any
SIF with a claimed SIL ≥ 1
Note 1 to entry: A BPCS includes all the devices necessary to ensure that the process operates in the desired
manner.
Note 2 to entry: A BPCS typically may implement various functions such as process control functi ons, monitoring,
and alarms.
[Source: ANSI/ISA-61511-1:2018]
common cause failure
Failure of multiple devices, functions, or systems due to the same cause during design,
manufacture, or use.
ISA-TR84.00.09-2023
- 21 -
Note 1 to entry: Cause includes both non-malicious and malicious intent.
[Source: ISA-TR84.00.09, 3 rd edition]
common mode failure
Failure of multiple devices, functions, or systems in the same observed manner, causing the
same loss of required system function(s).
[Source: ISA-TR84.00.09, 3 rd edition]
conduit
Logical or physical grouping of communication channels that share common security
requirements connecting two or more zones.
[Source: ISA-WG05TG3 Ontology Release 1]
countermeasure
see “security measure”
cyber security
Measures taken to protect a computer or computer system against unauthorized access,
unintentional or intentional misuse, or attack . Actions required to preclude unauthorized use of
denial of service to, modifications to, disclosure of, loss of revenue from, or destruction of
critical systems or informational assets
Note 1 to entry: The objective is to reduce the risk of causing personnel injury or endangering public health, losing
public or consumer confidence, disclosing sensitive assets, failing to protect business assets, or failing to comply
with regulations. These concepts are applied to any system in the production process and include both stand0-alone
and networked components. Communications between systems may be either through internal messaging or by any
human or machine interfaces that authenticate, operate, control, or exchange data with any of these control
systems. Cybersecurity includes the concepts of identification, authentication, accountability, authorization,
availability, and privacy
[Source: ANSI/ISA-62443-1-1]
cyber security management system (CSMS)
A set of policies, processes, and systems to manage risk within the organization, with the
objective of ensuring tolerable levels of risk potentially caused by security being compromised.
[Source: ISA-TR84.00.09, 3 rd edition]
cyber security resiliency test
Test designed to determine the ability to anticipate, withstand, r ecover from, and adapt to
adverse conditions, stresses, attacks, or compromises on cyber resources.
[Source: ISA-TR84.00.09, 3 rd edition]
cyber security risk assessment
The process of determining the likelihood of whether an adversary can successfully exploit
device or network vulnerabilities and the resulting degree of consequence(s).
[Source: ISA-TR84.00.09, 3 rd edition]
essential function
Function or capability that is required to maintain health, safety, the environment, and availability
for the equipment under control
Note 1 to entry: Essential functions include, but are not limited to, the safety instrumented function (SIF), the
control function and the ability of the operator to view and manipulate the equipment under control. The loss of
essential functions is commonly termed loss of protection, loss of control and loss of view, respectively. In some
industries additional functions such as history may be considered essential.
[Source: ANSI/ISA-62443-1-1]
failure
The termination of the ability of an item or system to perform a required function.
[Source: CCPS Guidelines for Improving Plant Reliability through Data Collection and Analys is]
failure Cause
ISA-TR84.00.09-2023
- 22 -
The circumstances during design, manufacturer, or use (including cyber -attack) which have led
to a failure.
[Source: CCPS Guidelines for Improving Plant Reliability through Data Collection and Analysis]
failure Mode
The observed manner of failure. The failure modes describe the loss of required system
function(s) that result from failures.
[Source: CCPS Guidelines for Improving Plant Reliability through Data Collection and Analysis]
field device
A piece of technical equipment in the field of measuring and control technology and an umbrella
term for sensors and actuators in the field of automation technology.
[Source: ISA-TR84.00.09, 3 rd edition]
functional safety
Part of the overall safety relating to the process and the BPCS which depends on the correct
functioning of the SIS and other protection layers.
[Source: ANSI/ISA-61511-1:2018]
hazard
A potential source of harm.
Note 1 to entry: This harm could be immediate or long term
[Source: ANSI/ISA-61511-1:2018]
industrial automation and control system
Collection of personnel, hardware, software, procedures, processes, and policies involved in the
operation of the industrial process and that can affect or influence its safe, secure, and reliable
operation
Note 1 to entry: These systems include, but are not limited to:
•
industrial control systems, including distributed control systems (DCSs), programmable logic controllers
(PLCs), remote terminal units (RTUs), intelligent electronic devices, supervisory control, and data acquisition
(SCADA), networked electronic sensing and control, and monitoring and diagnostic systems. (In this context,
process control systems include basic process control system and safety -instrumented system [SIS]
functions, whether they are physically separate or integrated.)
•
associated information systems such as advanced or multivariable control, online optimizers, dedicated
equipment monitors, graphical interfaces, process historians, manufacturing execution systems, and plant
information management systems.
•
associated internal, human, network, or machine interfaces used to provide control, safety, and
manufacturing operations functionality to continuous, batch, discrete, and other processes.
Note 2 to entry: In the context of ISA-62443 series, the concept of IACS refers to an installation in operation in a
given environment, including policies and procedures associated with the Automation Solution.
[Source: ANSI/ISA-62443-1-1]
internet
Global system of connected computer networks
[Source: ISA-TR84.00.09, 3 rd edition]
key performance Indicator
A measurable value that demonstrates how effectively a company is achieving key business
objectives.
Note 1 to entry: Organizations use KPIs to evaluate their success at reaching targets.
[Source: ISA-TR84.00.09, 3 rd edition]
lagging indicator
A retrospective set of metrics that are based on incidents, events or data measurements that
meet the threshold of severity used by organizations as an input to improve their performance.
[Source: ISA-TR84.00.09, 3 rd edition]
leading indicator
ISA-TR84.00.09-2023
- 23 -
A forward-looking set of metrics which indicate the performance of the key work processes,
operating discipline, or layers of protection that are used by organizations as an input to help
prevent incidents.
[Source: ISA-TR84.00.09, 3 rd edition]
least privilege
Basic principle that holds that users (humans, software processes or devices) should be
assigned the fewest privileges consistent with their assigned duties and functions.
Note 1 to entry: Least privilege is commonly implemented as a set of roles in an IACS.
[Source: ISA-TR84.00.09, 3 rd edition]
management system
A set of policies, processes and procedures used by an organization to ensure that it can fulfill
the tasks required to achieve its objectives.
[Source: ISA-TR84.00.09, 3 rd edition]
metric
A measurement of performance or the results obtained from the measurement.
Note 1 to entry: KPI’s may be created by combining metrics within mathematical expressions
[Source: ISA-TR84.00.09, 3 rd edition]
operational technology (OT)
Hardware and software that detects or causes a change through the monitoring and/or control
of physical devices, processes and events and the applicable procedures performed by
personnel (e.g., engineering, operations, maintenance) to operate and maintain with the purp ose
of safe and secure operation.
Note 1 to entry: In the context of facilities, this represents the IACS control system devices, including IACS network
and networking devices (e.g., firewalls, switches, routers, etc.), all controls and smart instrumentation, analyzers, etc.
down to level 0 in the reference architecture and those responsible for its management, operation, engineering support
and maintenance.
[Source: ISA-TR84.00.09, 3 rd edition]
process safety controls, alarms, and interlocks
Process safety safeguards implemented with instrumentation and controls, used to achieve, or
maintain a safe state for a process, and required to provide risk reduction with respect to a
specific hazardous event.
Note 1 to entry: There are many types of safety controls, alarms, and interlocks, for example: safety alarm, safety
interlock, safety permissive, detection or suppression, emergency shutdown, safety critical control, and safety
instrumented system. The terms listed in the illustration are not intended to be construed as the only terms applied
to safety controls, alarms, and interlocks; neither should it be assumed that each type is necessarily separate and
independent.
Note 2 to entry: Examples of non-instrumented safeguards include rupture disks, relief valves, dikes, etc.
[Source: ISA-TR84.00.09, 3 rd edition]
risk
A measure of human injury, environmental damage, economic loss, loss of intellectual property
or loss of privacy in terms of both the incident likelihood and the magnitude of the loss or injury.
A simplified version of this relationship expresses risk as the product of the likelihood and the
consequences (i.e., risk = consequence x likelihood) of an incident.
[Source: CCPS, Guidelines for Developing Quantitative Safety Risk Criteria, 2009 , Modified to
reflect additional information risk concerns]
Risk Assessment
The process by which the results of an analysis are used to make decisions, either through
relative ranking of risk reduction strategies or through comparison with risk targets.
[Source: CCPS Concept Book, Layer of Protection Analysis Simplified Process Risk
Assessment]
risk tolerance
ISA-TR84.00.09-2023
- 24 -
An organization's or stakeholder's readiness to bear the risk after risk consideration of
consequences and likelihood in order to achieve its objectives.
Note 1 to entry: Risk tolerance can be influenced by legal or regulatory requirements.
[Source: Based on ISO Guide 73:2009(en)]
risk tolerance criteria
A predetermined measure of risk used to aid decisions about whether further efforts to reduce
risk are warranted.
[Source: CCPS, Guidelines for Developing Quantitative Safety Risk Criteria, 2009]
safety
Freedom from unacceptable risk.
[Source: ANSI/ISA-62443-1-1 (99.01.01):2007]
safety instrumented system (SIS)
Instrumented system used to implement one or more SIFs.
Note 1 to entry: A SIS is composed of any combination of sensor (s), logic solver(s), and final elements(s). It also
includes communication and ancillary equipment (e.g., cables, tubing, power supply, impulse lines, heat tracing).
Note 2 to entry: A SIS may include software.
Note 3 to entry: A SIS may include human action as part of a SIF.
[Source: ANSI/ISA-61511-1:2018]
security
Condition of system resources being free from unauthorized access and from unauthorized or
accidental change, destruction, or loss.
[Source: ISA-WG05TG3 Ontology Release 1]
security incident
Security compromise that is of some significance to the asset ow ner or failed attempt to
compromise the system whose result could have been of some significance to the asset owner .
Note 1 to entry: The term “near miss” is sometimes used to describe an event that could have been an incident under
slightly different circumstances.
[Source: ANSI/ISA-62443-1-1]
security level
Set of security measures that support a degree of risk reduction
Note 1 to entry: Security levels (SL) are SL -1 – Low, SL-2 – Medium, SL-3 – High, SL-4 – Very High.
Note 2 to entry: Security level types are: capability security level (SL-C), target security level (SL-T), deployed security
level (SL-D), and operational security level (SL-O)
[Source: ISA-WG05TG3 Ontology Release 1]
security level capability (SL-C)
security level built into a product or technology
Note 1 to entry: capability security level is determined during the product development phase of the security
lifecycle
[Source: ISA-WG05TG3 Ontology Release 1]
security level implemented (SL-I)
security level of an automation solution that is designed and implemented based on the
security requirements specification
Note 1 to entry: implemented security level is determined during the integration phase of the security lifecycle
[Source: ISA-WG05TG3 Ontology Release 1]
security level operational (SL-O)
security level of an IACS that is operated and maintained based on the security requirements
specification
Note 1 to entry: achieved security level is determined during the operation and maintenance p hases of the security
lifecycle
[Source: ISA-WG05TG3 Ontology Release 1]
security level target (SL-T)
desired security level based on a risk assessment
ISA-TR84.00.09-2023
- 25 -
Note 1 to entry: target security level is determined during the design phase of the security lifecycle
[Source: ISA-WG05TG3 Ontology Release 1]
security measure
Measure that fulfills part or all of one or more security requirements
Note 1 to entry: security measures can include process security measures or technical security measures
Note 2 to entry: technical security measures can include physical security measures
[Source: ISA-WG05TG3 Ontology Release 1]
security protection rating achieved (SPR-I)
Indicates predicted compliance with applicable requirements of 62443 -3-3 mapped to Level x
and below which can be fulfilled during operation by
• technical security measures of a zone of the Automation Solution
including compensating technical security measures
• and reliably performed and sustained operational process measures:
• Process security measures to fulfill applicable requirements of ISA/IEC 62443 -2-1
• and process measures to fulfill applicable requirements of ISA/IEC 62443 -3-3
• Process security measures associated with the technical security measures
• and compensating process security measures
[Source: ISA-TR84.00.09, 3 rd edition]
security protection rating operation (SPR-O)
Indicates current measured compliance with applicable requirements of 62443 -3-3 mapped to
Level x and below which are fulfilled during operation by
• technical security measures of a zone of the Automation Solution
including compensating technical security measures
• and reliably performed and sustained operational process measures:
• Process security measures to fulfill applicable requirements of ISA/IEC 62443 -2-1
• and process measures to fulfill applicable requirements of ISA/IEC 62443 -3-3
• Process security measures associated with the technical security measures
• and compensating process security measures
[Source: ISA-TR84.00.09, 3 rd edition]
security protection rating target (SPR-T)
Identifies applicable requirements of 62443-3-3 mapped to Level x and below
which must be fulfilled during operation by
• technical security measures of a zone of the Automation Solution
including compensating technical security measur es
• and reliably performed and sustained operational process measures:
• Process security measures to fulfill applicable requirements of ISA/IEC 62443 -2-1
• and process measures to fulfill applicable requirements of ISA/IEC 62443 -3-3
• Process security measures associated with the technical security measures
• and compensating process security measures
[Source: ISA-TR84.00.09, 3 rd edition]
security protection scheme
Collection of technical and organizational measures to ensure the cybersecurity of an IACS in
operation.
[Source: ISA-TR84.00.09, 3 rd edition]
threat
Circumstance or event with the potential to adversely affect operations (including mission,
functions, image, or reputation), assets, control systems or individuals via unauthorized
access, destruction, disclosure, modification of data and/or denial of service
ISA-TR84.00.09-2023
- 26 -
[Source: ANSI/ISA-62443-1-1]
threat agent
Method(s), individual(s) or organization(s) that could bring about unacceptable consequences
through cyber attacks
[Source: ISA-TR84.00.09, 3 rd edition]
threat source
Intent and method targeted at the intentional exploitation of a vulnerability, or a situation and
method that may accidentally trigger a vulnerability
[Source: ANSI/ISA-62443-3-2:2020]
threat vector
Path or means by which a threat source can gain access to an organizational asset
[Source: ANSI/ISA-62443-3-2:2020]
unmitigated cyber security risk
Level of risk that is present in a system before any cyber security measures are considered
[Source: ANSI/ISA-62443-3-2:2020]
vulnerability
Flaw or weakness in a system's design, implementation, or operation and management that
could be exploited to violate the system's integrity or security policy
[Source: ANSI/ISA-62443-1-1]
vulnerability assessment
Process of identifying, quantifying, and prioritizing (or ranking) the vulnerabilities in a system.
Note 1 to entry: Vulnerability from the perspective of disaster management means assessing the threats from potential
hazards to the population and to infrastructure.
[Source: ISA-TR84.00.09, 3 rd edition]
Zone
Grouping of logical or physical assets based upon risk or other criteria, such as criticality of
assets, operational function, physical or logical location, required access (e.g., least privilege
principles) or responsible organization.
[Source: ISA-WG05TG3 Ontology Release 1]
zone access point
Interface between a zone and a conduit that enforces access control
[Source: ISA-WG05TG3 Ontology Release 1]
zone boundary
Edge or perimeter of a logical or physical zone
[Source: ISA-WG05TG3 Ontology Release 1]
zone boundary edge device
Communication asset, within a zone or conduit, which provides an interface between a zone
and a conduit, e.g., firewall, switch, router, field sensor, final element, etc.
[Source: 62443-1-2 Workbench: modified to add examples]
134
For additional definitions, see ANSI/ISA-61511, ANSI/ISA-84.00.01, and ANSI/ISA-62443-1-1
135
3.2 Security Levels and Security Protection Ratings
136
137
138
139
140
Both security levels (SL) and Security Protection Ratings (SPR) range from zero to four, with 0
representing no security and 4 representing the highest degree of security. Security Protection
Ratings were first introduced during ISA-62443-2-2 development. An SPR is a holistic rating of the
protection afforded a zone or conduit based on the evaluation of its security protection scheme. It
is comprised of:
ISA-TR84.00.09-2023
- 27 -
141
142
•
The technical security level capabilities of the security measures applied to the automation
solution; and
143
144
•
The maturity to practice the organizational security measures for operation necessary to
ensure the effectiveness of the technical security measures .
145
146
147
148
149
150
The technical capabilities of security measures are expressed as security level capability, (SL -C)
for either a product in accordance with ISA 62443-4-2 or a zone in accordance with ISA 62443-33. The SL-C relies on the successful implementation and on-going management support for any
technical capabilities that are not inherently secure. When used in an automation solution, these
levels state that a component or zone can meet the desired SL natively without compensating
security measures when properly configured, implemented, and managed.
151
152
153
154
155
For the technical capabilities to be realized, organizational security measures for operation and
maintenance should be sufficient as measured by the maturity level of the applicable organizations.
The level of on-going compliance with ISA 62443-2-1, ISA 62443-2-3, and ISA 62443-2-4 provides
the evidence needed to determine maturity level for a particular application. Section 4 covers the
concept of maturity levels more fully.
156
157
158
159
160
During the cyber risk assessment, security level targets (SL -T) for devices as well as SPR targets
(SPR-T) for each zone are determined. As provided by manufacturers, devices will have a certain
level of security capability (SL-C), assuming it is installed, configured, and managed correctly and
in a secure manner. For each increase in the SL value, there is an expectation on the part of the
asset owner that the device can support a nominal order o f magnitude risk reduction.
161
162
163
164
165
166
It is important to note that product SL-C does not automatically translate into actual risk reduction
that can be expected. Just as products may be certified to safety integrity levels, products may be
certified to security levels. Also, just as certification of a component alone does not represent the
safety instrumented functions integrity level for a safety instrumented function (SIF), it is equally
true that the SL-C of a product does not represent the SPR for a zone, even if it purports to have
the same SL-C as the SPR-T for the zone.
167
168
169
170
171
172
The evaluation of a SPR can be considered analogous to doing a SIL verification for a SIF, however,
an individual SPR applies to a specifically defined zone. When evaluating a SPR, there is an
expectation on the part of the asset owner that a nominal order of magnitude risk reduction is
possible with each increase in the SPR value. It is possible that some of the SL -C products are
not sufficient relative to the SPR-T. In these cases, compensating security measures can be
implemented to account for the deficiency.
173
174
175
176
177
178
The actual security protection rating can only be determined by measured performance while in
actual operation. Prior to operation, it is possible to estimate a security protection rating
implemented (SPR-I). Of necessity this includes assumptions that may be either optimistic or
overly conservative. In addition, new vulnerabilities can render past assumptions invalid.
Measurement of performance is the best way to determine if one’s securi ty continues to be
adequate.
179
3.3
180
The abbreviated terms and acronyms used in this document are defined as follows:
Abbreviated terms and acronyms
ALARP
As Low as Reasonably Practicable
ANSI
American National Standards Institute
BPCS
Basic Process Control System
CCPS
Center for Chemical Process Safety
CFATS
Chemical Facility Anti-Terrorism Standards
ISA-TR84.00.09-2023
- 28 -
COTS
Commercial off the Shelf
CRS
Cyber security Requirements Specification
CSSA
Cyber security Stage Assessment
DoS
Denial of Service
DNP
Distributed Network Protocol
FAT
Factory Acceptance Testing
HAZID
Hazard Identification Assessment
HAZOP
Hazard and Operability Method
HMI
Human Machine Interface
HSE
Health and Safety Executive
HTTPS
Hypertext Transfer Protocol Secure
IACS
Industrial Automation and Control Systems
IAMS
Instrument Asset Management System
IEC
International Electrotechnical Commission
IP
Internet Protocol
IPSEC
Internet Protocol Security
ISA
International Society of Automation
ISO
International Organization for Standardization
IT
Information Technology
LOPA
Layer of Protection Analysis
MOC
Management of Change
NIST
National Institute of Standards and Technology
OPC
Open Platform Communications
OS
Operating System
PCN
Process Control Network
PE
Programmable Equipment
PES
Programmable Electronic System
PHA
Process Hazard Analysis
PKI
Public Key Infrastructure
PSCAI
Process Safety Controls, Alarms, and Interlocks
PSSR
Pre-startup Safety Review
RA
Resource Availability
RASCI
Responsible, Accountable, Supporting, Consulted and Informed
RAGAGEP
Recognized and Generally Accepted Good Engineering Practices
SAT
Site Acceptance Testing
SIF
Safety Instrumented Function
ISA-TR84.00.09-2023
- 29 -
SIL
Safety Integrity Level
SIS
Safety Instrumented System
SL
Security Level
SL-C
Security Level Capability
SL-I
Security Level Implemented
SL-O
Security Level Operational
SL-T
Security Level Target
SLC
Safety Lifecycle
SPR
Security Protection Rating
SPR-I
Security Protection Rating Implemented
SPR-O
Security Protection Rating Operational
SPR-T
Security Protection Rating Target
SRS
Safety Requirements Specification
SSL
Secure Socket Layer
SSH
Secure Shell Protocol
STIG
Secure Technical Implementation Guide
SuC
System under Consideration
USB
Universal Serial Bus
VPN
Virtual Private Network
181
4
Management of PSCAI cyber security in the process sector
182
4.1
Objective
183
184
185
186
187
Successful management of process safety includes consideration of management activities
intended to meet the objectives of both safety and cyber security. The management system is an
essential foundation for achieving PSCAI integrity and functional performance. ISA 62443 -2-1
documents requirements for a cyber security ma nagement system (CSMS) applicable throughout
the entire lifecycle of the facility.
188
4.2
Guidelines
189
4.2.1
General
190
191
192
193
An organization’s safety policy and strategy underpin an organizational cyber security strategy. To
support these, robust performance measurement procedu res provide a means to assess
conformance to ISA 62443-2-1 requirements. The 62443 series of standards are beginning to adopt
requirements as a function of the following security objectives:
194
195
196
197
198
199
200
201
•
•
•
•
•
•
•
•
Security Lifecycle
Risk Management
Access Control
System Integrity
Resource Availability
Data Confidentiality
Asset Management
Incident Management
ISA-TR84.00.09-2023
- 30 -
202
203
Security objectives when applicable also have sub-objectives allowing a map to previous 62443
editions where other means to organize requirements were used, e.g. , foundational requirements.
204
4.2.2
205
206
207
208
209
Senior management is a key resource, and without their
management systems will suffer. It should be recognized that
has a real potential to impact Process Safety Risk and that
implementing operational technology (OT) is to integrate OT
owner work processes.
210
211
212
213
214
215
216
Those responsible for the execution and/or measurement of th e performance during each of the
lifecycle phases should be clearly identified. Communication to applicable personnel, documenting
their accountabilities and responsibilities helps to ensure appropriate implementation and
management throughout the lifecycle. These roles and responsibilities extend beyond the
organization itself, including product suppliers and third-party service providers as well. The roles
and responsibilities associated with cyber security of the OT scope should align with both internal
roles as well as with external partners.
217
218
219
220
Potential shortfalls in individual, organizational, product supplier, and third -party service provider
competencies are complex. To maintain cyber security and safety within the industrial automation
control system (IACS), a sustainable, auditable program of training, familiarization and assessment
is recommended.
221
222
223
224
A successful cyber security program assembles the right mix of people, processes and technology for
activities that occur throughout the life cycle. Table 4.1 (Resources and functions) illustrates a typical range
of functional disciplines and some available resources for those who create, implement, operate, and
manage sound policies and procedures intended to lead to a mature cyber security program.
225
226
Table 4.1
Resources and Functions
Organization and resources
Service
Provider
Asset Owner
Product
Supplier
support, overall effectiveness of
failure of cyber security protection
the most cost-effective means of
cyber security with existing asset
Resources
IT
I&E
Devices
Information Sources (NIST, DHS, etc.)
OT Network
Architecture
Engineer
Industrial Control System-Cyber Emergency
Response Team (ICS-CERT)
Control Engineer
Engineering
Integrated
Systems
Integrated
Packages
Process Safety
Maintenance
Operation
HR
Management
Auditor
Purchasing
System
Integrator
Maintenance
Operation
Consultant
Assessor
Control Platform
Sub Supplier
Auditor
227
228
In assignment of roles and responsibilities, level of personal staffing and competency is a
consideration so to minimize the probabilities of human errors due to a high level of stress.
229
230
231
232
233
Table 4.2 below illustrates a generic RASCI (Responsible, Accountable, Supporting, Consulted
and Informed) chart for role categories contained within ISA 62443 documents as a function of
safety and security lifecycle activities. It should be noted that there may be multiple service
providers and that they may be employed by the asset owner, or their services may be contracted.
It is recommended that asset owners create their own RA SCI charts that reflect their own
ISA-TR84.00.09-2023
234
235
236
- 31 -
organization functional roles and relationships with third party service providers and product
suppliers as the example provided is too generic for specific use and only illustrates the starting
point concept.
ISA-TR84.00.09-2023
- 32 -
237
238
Table 4.2
Generic RASCI Chart
Safety and Security
Lifecycle Activities
Define Project Scope
Sub Activities
Asset
Owner
Service
Provider
Operation
Maintenance
Service
Provider
Product
Supplier
Business Area
Requirements
A, R
Front End Engineering
A
R, S
C
Identify the SuC
A
R
C
Safety PHA
A
R, C
S
S
Initial cyber security
risk assessment
A
R, C
S
C
C
Partitioning SuC into
zones and conduits.
A
R, C
C
C
C
Vulnerability
Assessment
A
R, C
C
C
S, C
Detailed cyber security
risk assessment
A
R, C
C
C
S, C
Allocation of Safety and
Security protection functions
Allocation of Safety
and Security
protection functions
A
R, C
C
C
Document Requirements
Document initial
Safety requirements
specification (SRS)
A
R, C
C
C
C
Document cyber
security requirement
specification (CRS)
A
R, C
S
C
C
Stage 1 Assessment
A
R, C
Preliminary Design
verification
A
R, C
Hazard and Risk
Assessment
C
C
S, C
C
ISA-TR84.00.09-2023
Safety and Security
Lifecycle Activities
239
- 33 -
Sub Activities
Asset
Owner
Service
Provider
Operation
Maintenance
Service
Provider
Detailed Design &
Procedure Development
A
R, C
S
Stage 2 Assessment
A
R, C
C
System integration phase
(buy/build/configure)
A
R, S
C
C
S, C
Stage 3 Assessment PreStartup Safety Review
(PSSR)
A
R, S
S
S
S, C
Startup
A
R, S
S
S
S, C
Operation
A
S, C
R
S, C
S, C
Maintenance
A
S, C
S, C
R
S, C
Stage 4 Assessment
A
R, S
S
S
S, C
Stage 5 Assessment
Management of Change
Including Decommissioning
A
S, C
R
Note: A = Accountable, R = Responsible, S = Supporting, C = Consulted, I = Informed
C
Product
Supplier
S, C
C
S, C
ISA-TR84.00.09-2023
- 34 -
240
4.2.3
241
242
243
244
The achievement of process safety and cyber security requires the implementation of an integrated
lifecycle while ensuring that persons who are responsible for any lifecycle activities also have the
appropriate competencies in cyber security and process / functional safety to understand each
other's discipline.
245
246
247
248
Having qualified personnel perform their security related tasks is a requirement of ISA62443 -2-1.
ISA62443-2-4 also includes requirements for service providers that complement the requirements
in ISA62443-2-1. In addition to individual competencies, to achieve higher maturity levels, there
needs to be organizational competence.
249
250
251
252
253
254
255
256
Individual Competence starts with cyber security awareness regarding cyber hygiene and applies
to all employees, contractors, subcontractors, and other 3rd parties who work with the company.
Additional expectations apply to those parties intended to have access to any portion of the IACS
and associated networks. Personnel with specific roles with certain responsibilities should have
the required competence as defined by the asset owner. Training followed by actual experience
while under the guidance of someone with proven competence and experience over time producing
a proven record of accomplishment provides the basis for level of competence achieved. Some
companies may also add a certification requirement at their discretion.
257
258
Listed below are some factors for consideration depending upon the specific role and
responsibilities:
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Competency
Demonstrated training for specific responsibilities
Experience appropriate to the application area
Experience appropriate to the information technology and can demonstrate knowledge
Experience appropriate to the IACS technology and can demonstrate knowledge
Safety engineering experience appropriate to the technology
Knowledge of the legal and safety regulatory framework
Knowledge of company policies and practices, as well as industry standards adopted by
the company, e.g., ISA 61511, ISA 62443 standards, etc.
Adherence to cyber security policies
The consequences of failure of PSCAI due to a cyber incident
The safety requirements of the IACS and associated networks
The novelty of the network design, design procedures and/or application
Proper handling of equipment and software intended to be secure
Procedures for response and recovery
Use of Logging and monitoring information
Past examples of enforcement / improvement of cyber security rules / metrics
Previous experience and its relevance to the specific duties to be performed and the
technology being employed
The ability to recognize when specialist advice or assistance is needed
Personnel capable of performing the work should be identified through a documented competency
assessment process. Aspects of this may include:
•
•
•
•
•
Attended appropriate level of training for duties to be performed
Requirements for requalification
Auditable records of training and qualification assessments
External cyber security accreditation by a recognized professional body
Witness of suitable performance by competent person
Organizational competence relies on several functional disciplines, each being competent unto
themselves working together as a team. To improve organizational integrity, it is necessary to
ensure the various functional disciplines made up of competent personnel with an appropriate level
ISA-TR84.00.09-2023
of overlap at all the interfaces. This includes the interface between OT and IT personnel. Increasing
organizational competence is an essential input to increasing organizational maturity. This is
illustrated in Figure 4.1.
Maturity Level
290
291
292
- 35 -
Asset Owner Management
Operations & Maintenance
Process Safety
Organizational
Competence
Control Engineer
Organizational Competence
OT Network Engineer
IT Security
Product Supplier
System Integrator
Service Provider
293
294
295
Figure 4.1
Organizational Competence vs Maturity
296
297
298
299
300
301
302
A range of requirements generally applies to address a breadth of applicable engineering
competencies such as process engineering, instrumentation and controls, cyber security, physical
security, legal and regulatory knowledge, safety engineering, etc. Whe n blended within a
management system, it represents the foundation for organizational competence. To build, sustain,
and continuously improve the organizations maturity level, it is useful to employ management
systems to build and sustain functional compet encies. These may include but are not necessarily
limited:
303
304
305
306
307
308
309
310
311
•
•
•
•
•
•
312
4.2.4
313
314
315
316
Consideration of process safety risk should occur throughout the lifecycle. This generally involves
a combination of hazard reviews and vulnerability assessments during capital projects,
management of change activities, j ob cyber security analyses, as well as periodic revalidation of
the hazard reviews after gaining experience during operation.
317
318
319
320
321
322
To assist risk decisions, asset owners typically develop tolerable risk criteria. This allows a more
consistent basis and helps to define boundaries of empowerment at lower levels within the
organization. The recommended risk criteria for cyber security risk assessment are the tolerable
risk criteria developed for safety, environmental and financial risk. The basis for this is that cyber
security with respect to process plants is only important as it relates to safety, environmental or
financial risk.
•
Training and education
Establishment of appropriate policies and procedures
Clear definition of cyber sensitive positions
Clear scope boundary with appropriate overlap between OT and IT
Monitoring and auditing
Management of changes, e.g., access control management, proactively manage
vulnerabilities, patch management, management of change (MOC) job cyber assessments,
asset inventory, key configuration settings, version control
Risk assessment revalidations
Risk management
ISA-TR84.00.09-2023
- 36 -
323
324
325
326
327
328
329
330
331
332
Risk criteria can be qualitative, semi-quantitative or fully quantitative. Although possible,
determination of likelihood frequencies in some instances is viewed by some to be currently more
difficult to determine than more traditional process safety initiating event. Some companies use
their pre-existing risk criteria, while others have amended their tolerable risk criteria to directly
document expected Security Levels and Security Protection Rating targets based upon the
unmitigated risk. Within the continuum between fully qualitative and fully quantitative, NIST has
provided guidance to consider for the development of semi -quantitative risk assessments. While
not as well known within the cyber security community, the concept of as low as reasonably
practicable (ALARP) established within the process safety community may be helpful for
management to make some risk-based decisions involving cyber security.
333
334
335
336
337
338
ISA 61511, clause 8.2.4 requires security risk assessment to be carried out to identify the security
vulnerabilities of the SIS. The requirement acknowledges the potential for common cause issues
relating to the basic process control system (BPCS), therefore the assessment is not solely
focused on the SIS. It further requires assessment of unintended events resulting from human
error in addition to intentional attacks, all of which can occur during various phases such as design,
implementation, commissioning, operation, and maintenance.
339
340
341
342
343
344
345
346
ISA 62443-2-1 requires that IACS security risks to be identified, documented, and mitigated or
otherwise managed. It further requires existing and newly identified IACS vulnerabilities to be
addressed and resolved. ISA 62443-3-2 provides requirements for a cyber security risk
assessment work process. This includes an initial cyber security risk assessment and a detailed
cyber security risk assessment that includes the identification of threats, vulnerabiliti es,
consequences and impacts, unmitigated likelihood, unmitigated cyber security risk, determination
of zone risk targets as well as documentation of security measures necessary to reduce the risk
to a tolerable level.
347
4.2.5
348
349
350
Asset Owners should define and communicate policies for classification and protection of
documents, data, and information for PSCAI design, implementation, maintenance and operation
from unauthorized access and disclosure.
351
352
353
All other stake holders in the lifecycle (Service Providers, Suppliers) should be made aware about
data classifications and protection. Contracts with service providers should contain requirements
to follow asset owner data confidentiality requirements.
354
355
Data confidentiality policies are applicable for th e static information (e.g., documents) and dynamic
information (Audit result, Test record, Operation logs, Network communications).
356
357
358
359
360
361
362
Example classifications:
• General purpose
• Internal use only (e.g., Policies and Procedures, Training materials, Incident Response
Plan)
• Confidential (e.g., PFDs, P&IDs, Network Diagrams, Data Flow diagrams, PHA reports
Device Configurations)
• Highly confidential (e.g., IP Addresses, Access control list, SIS Configuration)
363
364
365
366
367
Within each organization, a chain of command should be established so that appropriate levels of
authority have access, allowing use of the information necessary to maintain a safe and cyber
secure plant environment. For example, the plant manager should not be the only person with
access to the implementation plan, however, it should also not be publicly available to those
without a clear need to know.
368
4.2.6
369
370
A safety plan is required per ISA 61511 that is intended to document all activities, work processes
and resources necessary to implement, sustain and secure the IACS, including the PSCAI systems,
Data confidentiality
Safety / Cyber security planning
ISA-TR84.00.09-2023
- 37 -
371
372
373
374
375
throughout the entire integrated lifecycle. This plan should include an appro priate level of detail
regarding cyber security and be maintained, facilitating the tracking of the activities throughout the
lifecycle. Documentation of the plan should account for the data confidentiality classification
defined by the asset owner. The plan should be updated as part of Management of Change and
maintained current during the integrated lifecycle.
376
4.2.7
377
378
379
Organizations have multiple policies and procedures in place. Where applicable, these policies
and procedures should be updated to address cyber security considerations, including but not
limited to:
380
381
382
383
•
•
•
•
Organization Policies and procedures
Data confidentiality policies
Risk management processes
Management of change
Emergency response procedures
384
Activities and methodologies may be different but should be part of the integrated processes.
385
Refer to ANSI/ISA 62443-2-1 for further guidance.
386
4.2.8
387
388
389
390
391
The first principle in access management is to implement and enforce the concept of least privilege.
This means that access is unauthorized unless there is a demonstrated need for the access.
Limiting access to those formally authorized provides a smaller footprint for things to go wrong.
This concept applies to logical, physical, and remote access. The degree of security with respect
to access management should be based on the level of risk should unauthorized access occur.
392
393
394
ISA 62443-2-1 contains specific access management requirements that should be part of the
overall CSMS. ISA 62443-3-3 contains specific access management technical requir ements that
are a function of SL-C.
395
4.2.9
396
397
398
399
400
401
To gain insight into the level of security capability implemented and potentially achieved,
management can implement procedures that measure the performance of the cyber security
measures against the cyber security requirements specification (CRS). Means to accomplish this
includes, but not limited to key performance indicators (KPI), incident investigation, audits, testing,
and inspection that measure reliability, identify, and prevent systematic failures or vulnerabilities,
and address failures and/or demand rates where they exceed acceptable limits.
402
403
404
405
Tables included in Annex L, Cyber security KPI’s and Metrics, detail measurements for use by
asset owners to measure their performanc e and to help assist continuous improvement. Which
KPI’s are relevant is a decision an asset owner makes based upon their relative maturity level and
their perceived needs.
406
4.2.10 Human resources
407
408
409
410
411
412
413
When hiring personnel who will have potential logical or physical a ccess to the IT network or IACS
and its associated networks, it is important to screen prospective applicants to ensure a low
likelihood of malicious motive or intent to execute cyber -attacks as well as to evaluate that they
have sufficient technical skills for the intended job function. It should be recognized that certain
job functions may require a higher level of screening as determined by the asset owner. Screening
should not be a single exercise, as a person may change over time. As such, consideratio n should
be given to periodic background checks.
414
415
416
There should be a close working relationship between OT supervision and HR with respect to
management of authorized access, e.g., system access, information access, etc. Changes to
authorized access can occur due to three different circumstances as follows:
Cyber Security Access Management
Organizational performance measurement
ISA-TR84.00.09-2023
- 38 -
417
418
•
New hire – Person should be granted access only to the extent needed to perform their job
function
419
420
•
Change of Position – Access should be modified according to requirements of new job
function. Any access no longer part of job function should be disabled in a timely manner.
421
422
•
Termination, leave for another company, or retirement – In all cases, access should be
disabled immediately upon no longer being an active employee or contractor.
423
424
425
426
In addition, HR should work with OT and IT to ensure adequate training is available addressing
both cyber hygiene awareness and company expectations as well as specialist training as a
function of job descriptions or roles. HR is generally responsible for maintaining comp liance
records with respect to required initial and refresher training of personnel.
427
4.2.11 Supply chain cyber security
428
429
430
431
432
433
434
435
Clause 5.2.5.2 with ANSI/ISA 61511 Part 1 states, “Any supplier, providing products or services to
an organization that has overall responsibility for one or more phases of the SIS safety life cycle,
shall deliver products or services as specified by that organization and shall have a quality
management system. Procedures shall be in place to demonstrate the adequacy of the quality
management system.” With respect to cyber security, ISA 62443 4-1, Product security lifecycle
development requirements, ISA 62443-4-2, Technical Security Requirements for IACS
Components, and ISA 62443 2-4, Security program requirements for IACS service providers
provide applicable requirements.
436
437
438
439
440
441
442
443
ISA 62443 4-1 provides compliance requirements for product suppliers. Asset owners, as part of
any supplier approval process, are encouraged to audit the supplier for compliance. The supplier
should be able to provide documented evidence of their compliance. This may be an activity strictly
between the supplier and asset owner, or it may be assisted with some level of certification(s).
Certification alone is generally not adequate. Actual products used within the IACS, and its
associated networks should comply with ISA 62443-4-2. If the product is not able to comply with a
SL-T, the product supplier should be expected to provide input and guidance as to what
compensating measures the asset owner should consider making up the differ ence.
444
445
446
447
Likewise, service providers should be expected to follow ISA 62443 2-4. As their practices may
not fully mesh with asset owner policies and practices, the differences should be addressed as
part of any contract. Asset owners should evaluate service p roviders for their compliance with ISA
62443 2-4 and service providers should be prepared to provide the necessary evidence.
448
4.2.12 Cyber security management maturity
449
450
451
452
453
454
455
ANSI/ISA-62443-1-1 introduces the concept of maturity models relative to the lifecycle and its
respective activities. While the specific definition of maturity levels (ML) for measuring and
reporting cyber security maturity may change slightly based upon what model is being used, the
overarching theme of the models is generally the same. Cyber secur ity maturity levels (MLs) define
qualitative measures with respect to cyber security based upon factors that can be shown to reflect
the maturity of an organization’s personnel, processes, and technology, such as how well they
have:
456
457
458
459
460
461
462
463
464
•
•
Developed, documented, and implemented cyber security policies and procedures.
Designed and implemented technical solutions to assist the cyber security policies and
procedures.
• Applied policies, procedures, and technical solutions across their entire organization.
• Trained personnel on the policies, procedures, and technical solutions .
• Ensured the quality and sustainability of technical and organization measures by managing
and measuring their performance in a manner that supports continuous improvement.
In general, companies should strive to achieve and maintain the maturity level that is most
appropriate for the specific situation. Of particular importance is the ML of those organizational
ISA-TR84.00.09-2023
- 39 -
465
466
467
468
procedures necessary for technical measures to be effective. When the technical measures a re
evaluated for their SL-C and the supporting procedures are evaluated for ML, they can be
combined to determine the SPR-C. This SPR-C can then be compared to the SPR-T defined by
asset owners.
469
470
An example of the MLs that apply during assessment and during design/roadmap efforts is
shown in Table 4.3.
Table 4.3 – Example of Applicable MLs for Assessment and Design/Roadmap Efforts
471
Assessment MLs
ML 0 – Incomplete /
Unaware
ML 1 – Initial
ML 2 – Managed
ML 3 – Defined / Practiced
Design/Roadmap MLs
ML 4 – Improving
ML 4 – Improving
ML 1 – Initial
ML 2 – Managed
ML 3 – Defined / Practiced
472
Additional guidance is provided in Annex A, Maturity Level Assessment
473
4.2.13 Cyber Security Stage Assessments (CSSA)
474
475
476
477
478
479
480
481
482
483
484
ISA 61511 requires five functional safety assessment activities be performed during the lifecycle
to ensure that the management programs, e.g. , safety and security are sufficient to support
conformance to the companies’ risk criteria. Since cyber -attacks on the IACS represent a potential
process safety threat, these assessments should include cyber security considerations. Doing this
as a contribution to a functional safety assessment or as a separate activity are alternate means
to accomplish. This section focuses on cyber security only, providing guidance irrespective of how
an end user wishes to implement. The general work process for all these assessments is to review
information documents and records to determine whether the functional safety/security
management systems are in place, up to date, and followed. Identification of gaps should result in
recommendations for improvements. How well a company consistently performs in these
assessments is an important input when estimating a company’s maturity level.
485
486
The number, size, and scope of CSSA activities can depend upon the specific circumstances. The
factors in this decision are likely to include:
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
•
•
•
•
•
•
•
•
•
Size of project.
Degree of complexity.
Duration of project.
Consequence in the event of failure.
Degree of standardization of design features.
Safety regulatory requirements.
Security regulatory requirements.
Previous experience with a similar design.
Considering relevant factors such as:
o Time in operation.
o Number and scope of changes in operation.
o Revalidation testing frequency.
The following considerations apply when planning an assessment at any stage:
•
•
•
The scope of the assessment stage.
Who is to participate in the assessment.
The skills, responsibilities, and authorities of the team.
ISA-TR84.00.09-2023
504
505
506
507
508
509
510
511
512
513
•
•
•
•
•
The
The
The
The
The
- 40 -
information that will be generated resulting from any assessment stage activity.
identity of any other safety or security bodies involved in the assessment stage.
resources required to complete the assessment stage activity.
level of independence of the assessment stage team.
revalidation methods used after modifications.
Membership of the CSSA team should include at least one senior competent person not involved
in the project design team (for stages 1, 2 and 3) or not involved in the operation and maintenance
of the SIS (for stages 4 and 5). This person may be an employee or independent third party. The
competence of those to be involved in the assessments should consider:
•
•
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
Development, production, and maintenance tools used to develop, support, or maintain the
systems to safeguard against negative impact on the PSCAI through the use, or misuse, should
be considered during stage assessments.
529
530
Specific checklists for the five assessment stages documented below are included in Annex B,
Cyber security Assessment Stage Check List Templates.
531
Stage 1
532
533
Timing – After completion of the detailed cyber risk assessment, identification of required security
measures and finalization of the SRS / CRS information.
534
535
536
537
Intent - Ensure that the conceptual design is complete and consistent with the intent of the risk
assessment. Ensure an orderly transfer of information prior to the detailed design engineering
commencing. Reduce costs by reducing chance of future rework/scope changes during detailed
design and beyond.
538
Method - Independent check by competent personnel
539
Stage 2
540
Timing – After detailed design & before execution of integrator/construction contracts.
541
542
543
Intent – ensure that the detailed design engineering is complete and consistent with the intent of
the conceptual design prior to issuing contracts for construction. Manage costs, e.g. , reduce
chance of future rework/scope changes during detailed construction & integration of equipment.
544
Method – Independent check by competent personnel
545
Stage 3
546
547
Timing – After the installation, pre-commissioning, and completion of the final validation of the
IACS cyber security measures, as well as development of operation, maintenance, and emergency
•
•
•
•
•
•
•
Engineering knowledge, training, and experience appropriate to the process application.
Engineering knowledge, training, and experience appropriate to the applicable technology
used (e.g., network, electrical, electronic, programmable electronic ).
Engineering knowledge, training, and experience appropriate to the sensors and final
elements.
Safety engineering knowledge (e.g., process safety analysis ).
Cyber security knowledge (IT / OT as applicable)
Knowledge of the legal and regulatory functional safety requirements.
Adequate management and leadership skills appropriate to their role.
Understanding of the potential consequence of an event.
The novelty and complexity of the application and the technology.
ISA-TR84.00.09-2023
- 41 -
548
549
response procedures. Conducting the stage 3 assessment should be part of the pre-startup safety
review (PSSR).
550
Intent – Ensure the plant is safe and secure prior to beginning operation.
551
Method – Independent check by competent personnel
552
Stage 4
553
554
555
Timing – After gaining experience in operating and maintenance. Typically perform ed as part of
process safety management regulation requirements for revalidation of PHA, e.g. , every five years
or less.
556
557
Intent – Revalidate process hazards analysis (PHA) assumptions made and to correct and or
update as applicable.
558
Method – Risk review team should:
•
•
•
•
•
•
559
560
561
562
563
564
565
566
Review cyber security incidents since last revalidation
Review cyber security related management of changes since last revalidation
Review current vulnerability assessment
Review detailed level cyber security risk assessment and update as applic able
Review of KPIs that result from audit program
Address all recommendations resulting from revalidation
Stage 5
567
Timing – Part of the MOC process prior to startup with the implemented changes.
568
569
Intent – Ensure a robust management of change program with r espect to cyber security and
validation of assumptions made in the risk assessment are still applicable.
570
571
Method – Review proposed change versus risk assessment to ensure continued conformance with
risk criteria. Periodically assess the MOC work process.
572
573
574
575
576
577
578
579
580
4.2.14 Cyber security audits
To validate the performance of the cyber security management system, periodic audits should be
part of the security management system as required by ISA 62443 -2-1. It is recommended that
audits consist of weekly, monthly, and quarterly checks, depending upon the activities being
audited. Consideration should be given to when to make use of personnel or 3rd parties that are
independent of the activity being audited in the performance of audits. For the more frequent audits,
use of independent 3 rd party is not generally practical. The audit work process should be
implemented to evaluate compliance and ensure that any identified gaps are reviewed and, where
appropriate, rectified.
581
4.2.15 Cyber security configuration and change management
582
583
584
585
586
587
588
Configuration management includes current documentation of the architecture, hardware, and
software inventories, as well as configuration settings. ISA 62443 -2-1 contains specific
requirements regarding configuration management. All changes should be par t of the asset
owner’s change management policy. This should include changes that can be anticipated ( e.g.,
personnel changes, anti-malware updates, patching) as well as changes that are not anticipated
(e.g., MOC involving permanent or temporary changes). Chapter 15 provides more detailed
information regarding change management programs.
589
4.2.16 Business Continuity and Emergency Response
590
591
Companies should have Business continuity & emergency response plans that address cyber
events and be integrated with existing systems. Companies generally have emergency response
ISA-TR84.00.09-2023
- 42 -
592
593
594
595
plans in place to deal with things like loss of containment. These plans typically define a response
team and their expectations as a function of incident type. In addition, they document the
circumstances that require escalation, including notification of the community and regulatory
agencies as well as any additional response team members needed.
596
597
598
599
600
In addition, many companies have near miss databases to track leading indicators of more
significant events and incidents. These plans and programs have various levels of responses
defined depending upon the scale of the incident. Integrating cyber security into these plans and
programs can be useful as cyber events and incidents can have a direct impact on saf ety within
the plant.
601
602
The emergency response plans should document strategies for how they plan to deal with cyber
events such as:
603
604
605
606
607
608
609
610
611
612
613
•
•
•
•
•
•
•
•
•
Manipulation of Process and Equipment
Loss of Control
Loss of View
Denial of service attacks
Broadcast storms
Ransomware attacks
Detection of malicious software within IACS and associated networks
Discovery of vulnerabilities due to newly discovered zero-day exploits on other companies
Loss of Enterprise IT data and information (billing, accounting, dispatching)
Prepared responses can range from low to high impact responses as the examples listed below:
•
•
614
615
616
617
618
619
620
621
622
623
624
625
626
With plans in place, conducting periodic drills helps to ensure that the personnel will execute the
intended response as expected.
627
628
629
630
631
632
633
634
Should an attack be successful, it is important to have a business continuity plan. Business
continuity plans already exist in many companies and should address how to transition from an
incident back to full operation as normal. It is important to determine if they adequately address
potential cyber security incidents and upgraded as needed. At a minimum, a robust backup and
restore work process should be in place or implemented. Once implemented, verification of data
following the backup should be performed and periodically t hereafter. In addition, it should
periodically be verified that restoration from backup data to a stable state be ensured in a timely
manner.
635
636
637
638
639
640
ISA62443-2-1 provides specific management system requirements that should be included for
event and incident management as well as backup and restoration. ISA 62443 -2-4 provides
specific requirements for service providers with respect to event management and
backup/restoration. Service providers may be employees, contractors, subcontractors, or supplier.
Following an incident, companies should seek to learn the lessons that enable them to mitigate or
prevent potential future incidents. This may include techniques like Root Cause Analysis where
•
•
•
•
•
Continue to operate while monitoring the situation
Isolate a compromised portion of the IACS and associated network while operation
continues elsewhere
Airgap between BPCS and Safety system network
Complete isolation of the IACS and associated networks from all remote access, including
company enterprise networks
Shutdown portion(s) of the process and isolate relevant portions of the IACS and
associated network(s)
Shutdown the facility and disconnect all remote access connections
Documented recovery plan
ISA-TR84.00.09-2023
- 43 -
641
642
applicable. Companies are encouraged to share these lessons with their indu stry peers so that
overall industry improvement may occur.
643
5. Project Scope Development
644
5.1.
645
646
647
648
649
650
Chapters 5, 6, and 7 provide guidance for the initial design and that also includes the risk analysis
phase of the integrated safety and security lifecycle. Figure 5 .1 provides an overview of the
process steps. Chapter 5 addresses the preliminary engineering necessary to support schedule
and budgeting as well as risk assessment. The figure 5.1 flowchart is an expanded version of the
integrated security and safety lifecycle flowchart figure 0.2 introduced in section 0.2. Figure 5.2
provides additional details regards inputs and outputs for the specification phase.
Specification and System under Consideration (SuC)
Key
Expanded Lifecycle for Risk Analysis Phase
Project Scope Definition (Ch. 5)
Process Step
Adapted from
Safety Lifecycle
(IEC 61511)
Specification
Business area definition of requirements
Process Step
Adapted from
Security Risk
Assessments
(ISA/IEC 62443-3-2)
Front end engineering
Process Step
where co-engineering
is recommended
System under Consideration (SuC) defined
Supplier qualifications
Hazard and Risk Analysis (Ch. 6)
Safety Hazard and Risk Assessment
Allocation of Safety Functions to Protection
Layers
Initial Cybersecurity Risk Assessment
Partition the SuC into zones and conduits
Initial Safety Requirements Specification
(SRS)
Initial Risk >
Tolerable Risk?
no
yes
Detailed Cybersecurity Risk
Assessment (DCRA)
yes
Residual Risk >
Tolerable Risk?
no
Cybersecurity Requirements
Specification (CRS)
and consolidation with SRS (Ch. 7)
Stage 1 Assessment
651
652
Figure 5.1: Expanded flowchart for the Risk Analysis phase
ISA-TR84.00.09-2023
- 44 -
Expanded Lifecycle for Risk Analysis Phase
Inputs
Outputs
Project Scope Definition (Ch. 5)
•
•
Functional requirements
Existing policies and procedures
Specification
Business area definition of requirements
Front end engineering
•
•
•
•
•
•
•
•
Supplier qualifications
•
Project scope document
Definition of the SuC and ist intended use
Risk criteria to be considered & tolerable risk
criteria
Preliminary asset inventory
Preliminary system diagrams
Responsibilities for IT/OT
Initial safeguards to the extent known
Initial cybersecurity measures to the extent
known
Qualified suppliers
System under Consideration (SuC) defined
Hazard and Risk Analysis (Ch. 6)
653
654
Figure 5.2: Expanded flowchart for the Specification phase with inputs and outputs
655
5.1.1.
Purpose
656
657
658
Definition of scope is a part of any project. To facilitate the safety and security workflow, the scope
definition should include the description of the System under Consideration (SuC) and its intended
use. This is necessary to support Process Hazards Ana lysis (PHA) work process.
659
5.1.2.
660
As a basis for defining a project scope, the following inputs need to be present:
Input and Guidance
661
•
Functional business requirements for the project
662
663
•
Existing policies and procedures: Corporate and / or site policies, regulations, and
industry standards.
664
5.1.2.1.
665
666
During the specification, performance of several activities take place that should include, but are
not necessarily limited to:
Specification
667
668
669
•
Documentation defining what to build and its expected return on investment plus any
contract requirements, considering both capital and operational expenses, e.g., staffing
and maintenance strategies.
670
671
672
•
Definition of existing policies and procedures that will govern the project, e.g.,
corporate/site policies and procedures, regulatory requirements, supplier (control platform,
packaged equipment) security requirements, etc.
673
•
Documentation of expected functional requirements.
674
675
•
Initial process engineering, including development of process flow diagrams a s well as
piping and instrumentation diagrams suitable to support cost estimation.
676
677
678
•
Documentation of process safety information that includes the hazards of the process,
process technology and process equipment, including controls network and system
protection.
679
680
681
682
683
•
Development of preliminary control system and associated network architectures that may
affect the SIS, including interfaces to BPCS, packaged equipment control systems,
equipment monitoring systems that may be required to interface to the SIS. The SuC
definition should clearly delineate which subsystems or interfaces to other zones are to be
included in risk assessment and design of the SIS.
ISA-TR84.00.09-2023
- 45 -
684
685
•
Documentation of initial security measure strategy for protection against cybersecurity
attacks.
686
687
•
Execution strategy decisions (e.g., what distribution of work performed in house, by a single
engineering contractor, multiple engineering contractors, etc.).
688
689
690
•
Documentation to support all budget estimates ( e.g., major equipment, Instruments and
Controls etc.). This would include initial hardware and software functional components
forming an asset inventory for instruments, controls, and network devices.
691
692
693
•
Determination of risk criteria to be considered, for example health and safety,
environmental, financial, reputation etc. in accordance with all relevant policies and
regulations.
694
•
Determination of tolerable risk, in accordance with all relevant policies and regulations.
695
5.1.2.2.
696
697
As part of this work process, development of information should occur that also supports
cybersecurity risk assessments that are part of the overall PHA work process.
698
Specific to this, an automation picture is created consisting of:
System under Consideration (SuC)
699
•
Asset inventory (Hardware & software)
700
•
System diagrams (e.g., preliminary architecture drawings, prelim zone & conduit, etc.)
701
•
Data flow requirements
702
•
Initial safeguards (e.g., SIS and SIFs, fire and gas systems, etc.) – to the extent known
703
•
Initial security measures that document – to the extent known.
704
o
Technical security measures and their required organizational support
705
o
Other stand-alone organizational security measures
706
o
Compensating security measures
707
o
Initial definition of least privilege
708
709
•
Description for how IT and OT interact, i.e., who is responsible for what. Refer to figure 1.0
in section 1 that shows a typical interface between IT and OT.
710
711
712
713
714
•
Development of preliminary control network architecture that may interface to the SIS,
including interfaces to BPCS, packaged equipment control systems, equipment monitoring
systems that may be required to interface to the SIS. The SuC definition should clearly
delineate which subsystems or interfaces to other zones are to be included in risk
assessment and design of the SIS.
715
5.1.2.3.
716
717
718
719
720
721
Oftentimes an asset owner will maintain a managed list of approved vendors to make the
procurement process more efficient. Even with such a list, there are times when the project
requirements make it useful to perform a compatibility evaluation to determin e the most costeffective solution as well as when additional measures are needed to comply with their project
requirements. Table 5.1 provides an example template where c ost penalty considerations (OPEX
vs CAPEX) can be considered that address issues such as:
722
723
724
•
•
Supplier Qualification
Cost of compatibility workarounds
Cost of support, less than scope stated life of facility (e.g., 15 years)
ISA-TR84.00.09-2023
725
726
- 46 -
Table 5.1
Example Bidder Compatibility Comparison Template
Existing Technology
Stack
Supply Bidder 1
Cost
Yes /No
Penalty
Supply Bidder 2
Cost
Yes /No
Penalty
Supply Bidder n
Cost
Yes /No
Penalty
Control platform XYZ
Control platform ABC
Backup solution TYX
Whitelisting ABC
Antivirus OXY
GPS Clocks
Etc.
727
728
729
730
731
732
733
734
735
736
737
738
All requests for proposals and contracts involving any equipment or systems that will contain
programmable or configurable devices should have contract language stipulating security
performance requirements and capabilities such as:
•
•
•
•
•
•
•
Applicable regulatory requirements
Applicable asset owner security standards and procedures
Expected conformance to industry standards, e.g., ISA 61511, ISA 62443 specific
standards, etc.
Specific security requirements unique to the project or site, e.g., compatibility with existing
systems, patch management work process expectations
Duration of expected support with identified work process to mitigate obsolescence
Availability of security manual for product(s) to be provided
Availability of technical / maintenance support
739
5.1.3.
Output
740
These are the outputs required from scope definition for the following workflow:
741
742
•
Project scope document containing expected functional requirements, expected return
on invest, policies and procedures that will govern the project.
743
•
Definition of the System under Consideration and its intended use.
744
745
•
Risk criteria to be considered, for example health and safety, environmental, financial,
reputation etc. in accordance with all relevant policies and regulations.
746
747
•
Tolerable risk criteria, including risk criteria to be considered in both security and safety
risk analyses
748
749
•
Preliminary asset inventory containing process equipment and instrumentation and
hardware and software as far as already known
750
751
752
•
Preliminary system diagrams: Piping and Instrumentation diagram (P&ID), preliminary
control system architecture and network architecture concepts covering Purdue model
Layers L0 – L3.5 including data flow requirements
753
•
Information on responsibilities for IT and OT respectively .
754
•
Initial safeguards – to the extent known.
755
•
Initial cybersecurity measures – to the extent known.
ISA-TR84.00.09-2023
- 47 -
756
6
Hazard and Risk Analysis
757
6.1
Safety Hazard and Risk Assessment
758
6.1.1
Purpose
759
760
761
762
Due to the potential safety risks associated with process facilities, industry standards and practices
have been established to identify potential risks, rank them by likelihood and consequence, specify
mitigations for the identified risks, and implement the mitigations determined to be needed in the
design and operation of the facility .
763
6.1.2
764
765
766
767
768
769
The use of Electrical/Electronic/Programmable Electronic Safety-related Systems (E/E/PE, or
E/E/PES) for mitigation of process risks has been in practice since the advent of such technology .
Process Safety Controls, Alarms, and Interlocks (PSCAI) commonly employ digital technologies .
However, it must be recognized that the use of digital technology also includes inherent risks that
may impact the availability or integrity of those systems, and those risks must also be consid ered
in the design of process control systems and their safety and security functions .
770
771
772
773
774
775
776
ANSI/ISA 61511-1 requires the performance of a Hazard and Risk assessment to identify
hazardous events and the associated risk based on likelihood of the event and seve rity of the
consequences. The assessment takes into consideration different modes of process operation
such as normal operation, start-up, process upsets, turnaround, and emergency shutdown. This
activity establishes the risk to people, property, and the e nvironment. Both ANSI/ISA 61511-1 and
ISA 62443-2-1 require cyber security to be included as part of the overall risk assessment work
process.
777
778
Required inputs for the Safety Hazard and Risk Assessment are mainly knowledge on risk metrics
and existing systems, as far as already defined:
Input and Guidance
779
780
•
Tolerable risk criteria, including risk criteria to be considered in both security and safety
risk analyses
781
782
783
•
System diagrams: Process & Instrumentation Diagrams (P&IDs), control system
architecture and network architecture concepts for Purdue model layers L0 – L3.5 as far
as already defined.
784
785
•
Asset groups and inventory: Process equipment and instrumentation, hardware and
software assets as far as already defined.
786
•
Initial safeguards – to the extent known.
787
6.1.3
788
Typical outputs useful for the following safety and cybersecurity workflow are
Output
789
790
•
Hazards and hazardous events including initiating events and consequences , including
severity. These play an important role during cybersecurity risk assessments.
791
792
•
SIFs and safeguards: SIFs, alarms, non-SIF interlocks and non-instrumented protections.
These impact cybersecurity risk.
793
6.2
Allocation of Safety Functions to Protection Layers
794
6.2.1
Purpose
795
796
797
In the ideal world, processes should be designed to be inherently safe and certainly be as
inherently safe as practical. However, when complete inherent safety is not practical, protection
layers are applied, intending to reduce the safety risk to a tolerable level of risk.
ISA-TR84.00.09-2023
- 48 -
798
6.2.2
Input and Guidance
799
800
801
802
803
804
805
Risk reduction requirements are allocated to protection layers using methods such Layers of
Protection Analysis (LOPA). Multiple independent protection layers may be required based on risk
reduction requirements for the hazardous event. Safety functions are implemented within systems,
e.g., SIS, burner management, emergency shutdown, etc . For example, an emergency shutdown
(ESD) function, a preventive protection layer can be implemented by a SIS, or a fire and gas (F&G)
mitigation function can be implemented by a SIS. Protection layers are supposed to be independent,
so an ESD function should be independent of a F&G function.
806
807
808
809
810
811
The potential exists for the integrity and availability of process safety controls, alarms, and
interlocks to be degraded by a cyber-attack, effectively reducing the capacity to provide the
specified protection. Because of this potential risk, the system providing the protective functions
should be included as part of the security risk assessment. From a process safety risk perspective,
protection layers vulnerable to common cause events, e.g., by cyber security attacks intended to
create the hazardous demand and to compromise the protection layers should be considered .
812
813
As inputs, LOPA mainly takes outputs from the safety hazard identification (HAZID), IEF tables,
PFDavg tables, and estimates the residual risk for each process hazard :
814
•
Hazards and hazardous events
815
•
SIFs and safeguards.
816
817
818
•
System diagrams: Process & Instrumentation Diagrams (P&IDs), Process Flow Diagrams
(PFD), control system architecture and network architecture concepts for Purdue model
layers L0 – L3.5 as far as already defined.
819
820
•
Asset groups and inventory: Process equipment and instrumentation, hardware and
software assets as far as already defined.
821
6.2.3
822
823
824
The results of the safety hazard and risk assessment and the allocation of safety functions to
protection layers are valuable inputs for the following cybersecurity risk assessment, especially
the following:
Output
825
826
•
Asset groups and inventory updated with safety controllers and potentially other assets
assigned to safety functions
827
828
•
System diagrams updated with placement of the safety controllers and other safety related assets in the network
829
830
•
Safety concept for the SuC including SIFs and safeguards assigned to layers of
protection
831
832
•
Hazards and hazardous events including likelihood and consequences, including the
severity of consequences (updated after LOPA)
833
6.3
Initial Cybersecurity Risk Assessment
834
6.3.1
Purpose
835
836
837
838
The Initial Cyber Security Risk Assessment, a requirement of ISA 62443 -3-2, is the first step into
the risk analysis from a security point of view. Its purpose is to define the scope’s essential
functions and gain an initial understanding of the unmitigate d risk the system under consideration
presents to the organization should it be compromised.
ISA-TR84.00.09-2023
- 49 -
839
840
841
842
843
At this early stage, consequence plays a bigger role than likelihood because only worst-case
scenarios of system failure or manipulation are assessed – regardless of their likelihood. During
this risk assessment, the process consequences of interest can be identified and potentially what
process deviations can be caused by a cyber -attack, as well as identification of protection that
could be impacted. This supports the determination of essential functions.
844
845
846
847
848
The result of the Initial Cybersecurity Risk Assessment represents the organization’s unmitigated
risk, represented by the highest severity consequence resulting from interference with, breach or
disruption of, or disablement of the functions an organization needs to succeed (be it basic control
functions and complementary functions, or safety functions, both of which can be essential
functions).
849
850
All functions for which interference can lead to intolerable risks should be regarded as essential
functions.
851
852
853
Figure 6.1: Essential functions can be found both among safety functions and
basic control functions (IEC TR 63069)
854
6.3.2
Input and Guidance
855
856
857
858
859
The initial cybersecurity risk assessment can usually be performed at a corporate level to
determine in general what worst-case risks exist for their processes that are similar in nature,
having the same severity of consequences. The potential highest -severity consequences are a
function of the process design (e.g., chemical, means of electrical generation, etc.) and are
determined during the hazard review work process.
860
To assess the highest severity consequence, the following inputs are helpful:
861
862
•
Risk criteria to be considered, for example health and safety, environmental, financial,
reputation etc. in accordance with all relevant policies and regulations.
863
864
865
866
867
•
Tolerable risk criteria and the asset owner’s risk policies and metrics : The risk criteria
previously adopted by an organization for process hazard analyses should serve as the
basis for cyber security risk analysis as well. Criteria for consequence and likelihood need
to be defined, but since the initial risk assessment is essentially a worst -case screening
activity, likelihood is not assessed or defaults to the highest possible value.
868
869
870
871
872
873
•
Information on purpose and functionality of the SuC (intended use): The types of
assets and knowledge of their purpose should be available to conduct the initial cyber
security risk assessment of the SuC. For identifying asset types, usually system diagrams
and asset inventories are helpful. For identifying the systems’ purpose with regards to
critical processes, the functions it fulfills need to be documented. How functions are
fulfilled may be part of high-level communication diagrams. In addition, understanding the
ISA-TR84.00.09-2023
874
875
- 50 -
planned location (e.g., physical, logical, zone, sub-zone, etc.) of the assets is also useful
later when it comes to partitioning the SuC.
•
876
877
878
879
880
881
Major hazards: Knowledge of the severity of consequences is essential since this risk
assessment uses consequences as the main basis of assessment. This information can
be gleaned from the PHA, typically a hazard and operability assessment (HAZOP) and/or
layer of protection analysis (LOPA). This is the reason why a process safety hazard and
risk assessments are recommended to be carried out before the initial cybersecurity risk
assessment.
882
883
884
885
886
Using this information, the worst-case consequence can be assessed systematically by asking for
each operational function respectively asset type under consideration: What is the biggest
consequence a system failure or manipulation could have? Could one of the major hazards, leading
to the risks determined relevant during scope definition, be induced? All functions which could
induce such a major hazard are defined as essential functions.
887
888
889
890
Based on the answer, the unmitigated risk can be determined and compared to the tolerable risk
criteria. Optionally, results may also be used for in an initial SL-T / SPR-T recommendation for
each unit operation, or for each essential function or asset type as a function of unit operation
because SL-Ts are useful inputs for partitioning of the SuC into zones and conduits.
891
892
893
During the initial cybersecurity risk assessment, no detailed cybersecurity risk scenarios are
developed – this is done during the detailed cybersecurity risk assessment. The initial
cybersecurity risk assessment checks WHAT hazardous events could be induced, not HOW exa ctly.
894
Refer to Annex D, Risk Assessment Methodologies for example methodologies.
895
6.3.3
896
The output is an initial risk evaluation, containing the following information at a minimum:
Output
897
•
List of essential functions and associated asset groups
898
899
•
Initial system diagrams containing overall architecture, geographical location, and high level functional communication diagrams.
900
901
•
Initial risk evaluation: Worst-case unmitigated risk per essential function or asset
group as a function of process unit operation
902
903
•
Recommended SPR-T for each essential function or asset group as a function of process
unit operation (optional)
904
6.4
Partition the SuC into Zones and Conduits
905
6.4.1
Purpose
906
907
908
Zones are groups of assets or functions sharing common security requirements. A conduit is a
logical grouping of communication channels that share common security requirements connecting
two or more zones.
909
910
911
Partitioning the SuC into zones and conduits is a requirement of ISA 62443 -3-2 and uses the
results of the initial cyber security risk assessment to group assets or functions according to their
risk.
912
913
914
915
Zones and conduits lay the foundation for designing an architecture with respect to security, as
they can be used as a basis for network segmentation. In addition, when the unmitigated risk does
not satisfy the asset owner’s tolerable risk criteria, they help form a basis for further assessment
via the detailed level risk assessment.
ISA-TR84.00.09-2023
- 51 -
916
6.4.2
Input and Guidance
917
918
The most important inputs for defining zones and conduits are the results from the initial
cybersecurity risk assessment:
919
920
921
922
923
•
Information on purpose and functionality of the system under consideration. Here,
the information already gathered during the initial cybersecurity risk assessment can be
used and extended. The high-level use case or data flow diagrams c an now be detailed
so they include transmitted data and protocols. Using this guidance helps to propose zones
and associated conduits that minimize unnecessary data flow.
924
925
926
927
•
Location of assets. Different installed locations will generally require different ph ysical
access controls, so even if logically the assets would make sense in one zone, it may be
necessary to create two zones or consider the concept of sub zones within a logical zone
to account for this type of situation.
928
929
930
931
932
933
•
The initial risk evaluation, containing the worst-case unmitigated consequence per
essential function or asset group as a function of process unit operation provides another
basis for the creation of zones and conduits, because it makes sense for zones to have a
homogenous risk. As a rule of thumb, asset groups with similar worst-case unmitigated
risks, or systems that fulfill functions with similar worst -case consequences, can be
grouped together.
934
935
936
937
However, there are more criteria than risk that come into play for defining zones. ISA 6244 3-3-2
gives a non-exhaustive list of criteria to group assets into zones. One of these criteria is to separate
safety-related assets into zones logically or physically separated from zones with non -safety
related assets (or identify the entire zone as safe ty-related if it cannot be separated).
938
939
Security zones are not necessarily identical to safety instrumented functions (SIFs). Both can be
regarded as different perspectives on the same system under consideration.
940
941
Reference ISA84 TR84.00.09 Part 2, Cyber Security Case Study/Use Cases Related to the
Safety Lifecycle, to see an example of zone partitioning within the overall lifecycle.
942
6.4.3
943
The output following partitioning into zones and conduits typically is
Output
944
•
a revised asset inventory with assets assigned to zones
945
946
•
Zone and conduit diagrams: revised system diagrams with systems grouped into zones
and connected via conduits including criteria for how these zones were defined.
947
948
•
Data flow diagrams: refined system / communication flow diagrams detailing required data
and protocols between assets for fulfilling functions.
949
6.5 Initial Safety Requirements Specification (SRS)
950
6.5.1
951
952
953
954
955
956
Following the completion of the Safety Risk Assessment and allocation of identified Safety
Functions to protection layers as discussed in sections 6.1 and 6.2, ANSI/ISA 61511-1 requires
development of a Safety Requirements Specification (SRS). It is recommended from work process
perspective to begin work on the SRS as relevant information becomes available. The initial SRS
should be finalized in the requirements specification and consolidation with the cybersecurity
requirements specification after the detailed cybersecurity risk assessment.
957
958
The SRS defines the general requirements of the Safety Instrumented System (SIS) and spec ific
requirements of each Safety Instrumented Function (SIF) to be implemented in the SIS protection
Purpose
ISA-TR84.00.09-2023
- 52 -
959
960
961
layer. Following the connected workflows of ANSI/ISA 61511 -1 and ISA 62443-2-1, the initial SRS
should include consideration of risks and required mitigati ons from both the Safety Hazard and
Risk Assessment and initial Security Risk Assessment.
962
963
964
The initial SRS is to be used as an input in a detailed Cybersecurity Risk Assessment, therefore it
makes sense to carry it out before. The detailed Cybersecurity Ri sk Assessment may identify
additional measures required to ensure the SIS meets availability and integrity requirements.
965
6.5.2
966
The following inputs should be considered for inclusion in the safety requirements specification:
Input and Guidance
967
968
969
970
•
System diagrams including zones and conduits. These are created as an output of the
portioning into zones and conduits within the cybersecurity risk assessment. Although this
is not a requirement of ANSI/ISA 61511-1 as of today, zones and conduits diagrams can
serve as a basis for SIS segregation requirements now.
971
972
973
974
975
976
977
978
•
SIFs and safeguards assigned to layers of protection. These SIS general requirements
and SIF specific requirements help identify interfaces to SIS sub -systems, (e.g., Windows
based operation stations and engineering stations) as well as to other systems. These
include but are not necessarily limited to BPCS, process data historians, alarm and event
systems, intelligent device management systems, packaged equipment systems. The SRS
also help identify data flow required with these systems for SIF bypass enable, SIF reset,
SIF input/output status, SIF first out display, diagnostic alerts from field devices etc. that
need to be considered during the detailed cybersecurity assessment.
979
980
981
In addition to the primary requirements of ANSI/ISA 61511-1, the SRS should include functional
requirements to mitigate safety and security risks that were identified. At a minimum, the following
security considerations should be included in the SRS:
982
983
•
Requirements for isolation, segregation, and protection of the SIS from other connected
systems (reference system Zones and Conduits model).
984
•
Integrity requirements of the SIS to meet SIL targets.
985
986
•
Potential process safety consequence(s) of a security compromise of the SIS (general and
specific to SIFs where no other layers of protection exist for the hazard).
987
988
•
Other layer of protection dependencies on SIS and data interfaces to the SIS (e.g. , PSCAI
requiring data communicated to/from to the SIS).
989
990
•
Prescriptive security measures that can be defined pr ior to a detailed cybersecurity risk
assessment:
991
992
o
Specific software or hardware protection methods to be included in the SIS as
identified prior to or during the initial risk assessments.
993
994
o
User account security measures to be employed in the SIS that vary fr om other
components of the control system.
995
996
997
o
Requirements and restrictions for elevated account access to the SIS, including
engineering access, remote access, additional authentication methods or factors,
account authorization.
998
999
o
Security testing and verification requirements to validate the security and integrity
of the system.
ISA-TR84.00.09-2023
1000
6.5.3
1001
The initial SRS results in
- 53 -
Output
1002
•
Updated system diagrams, now including SIFs / SIS, and required data flow.
1003
•
A list of initial safety requirements containing the above security considerations.
ISA-TR84.00.09-2023
- 54 -
1004
6.6
Detailed Cybersecurity Risk Assessment
1005
1006
1007
In the event the high-level cyber security assessment indicates that the unmitigated risk does not
satisfy the asset owner’s tolerable risk criteria, ISA 62443 -3-2 requires the performance of a
detailed cyber security risk assessment.
1008
1009
1010
The purpose of the Detailed Cybersecurity Risk Assessment is to evaluate the consequence and
likelihood of concrete cybersecurity risk scenarios to prioritize which risks require mitigation as
well as what cyber security measures are necessary to reduce the risk to tolerable levels.
1011
1012
1013
1014
1015
1016
1017
1018
1019
For purposes of this technical report, risk has been defined as, “ a measure of human injury,
environmental damage, economic loss, loss of intellectual property or loss of privacy in terms of
both the incident likelihood and the magnitude of the loss or injury.” A simplified version of this
relationship expresses risk as the product of the likelihood and the consequences (i.e., risk =
consequence x likelihood) of an incident. For the cyber security contribution to safety, health and
environmental risk, consequences remain the same. Likelihood, however, can be thought of as a
combination of vulnerabilities and the likelihood that a threat agent or source has the requisite
skills, resources, and motivation to exploit the potential vulnerabilities or that vulnerabilities are
unknowingly exploited by non-malicious human error.
1020
1021
1022
As the most valuable knowledge needed for the Detailed Cybersecurity Risk Assessment is
technical and operational system knowledge (including functional knowledge of expected control
and safety functions), typical team membership of the detailed risk assessment would include:
1023
•
Facilitator / Team Leader knowledgeable in methodology
1024
•
Process Control Engineer
1025
•
OT knowledgeable Network Engineer
1026
•
Operations
1027
•
Process Safety Engineer
1028
•
Plant Security
1029
•
Process Engineer
1030
1031
Annex D, Risk Assessment Methodologies, provides example(s) of methodologies that may be
considered when performing a detailed level cyber security risk assessment.
1032
1033
1034
Figure 6.2 summarizes the three main steps of the Detailed Cybersecurity Risk Assessment along
with mappings to the detailed cybersecurity risk assessment workflow as defined in ISA-62443-32.
1035
1036
1037
Vulnerability identification should be performed prior to the detailed level cyber security
assessment workshop and is covered in the next sub-section. The subsequent three sub-sections
that follow provide guidance for each of the three major steps shown in figure 6 -2.
ISA-TR84.00.09-2023
- 55 -
Initial Risk > Tolerable Risk
Detailed Cybersecurity Risk Assessment (DCRA)
•
•
Risk Identification
Vulnerability identification
Identification of Cybersecurity Threat/
Vulnerability Scenarios
Mapping to detailed cybersecurity risk
assessment workflow in ISA-62443-3-2
ZCR 5.1: Identify threats
ZCR 5.2: Identify vulnerabilities
Risk Evaluation
ZCR 5.3: Determine consequences and impact
ZCR 5.4: Determine unmitigated likelihood
ZCR 5.5: Determine unmitigated cyber security risk
ZCR 5.6: Determine SL-T
ZCR 5.9: Reevaluate likelihood and impact
ZCR 5.10: Determine residual risk
Risk Resolution
ZCR 5.7: Unimitigated risk exceeds tolerable risk?
ZCR 5.8: Identify and evaluate existing countermeasures
ZCR 5.11: Are all residual risks at or below tolerable risk?
ZCR 5.12: Identify additional cyber security countermeasures
ZCR 5.13: Document and communicate results
yes
Residual Risk >
Tolerable Risk?
no
1038
1039
1040
Figure 6.2: Flowchart for the Detailed Cybersecurity Risk Assessment with mapping to ISA -62443-3-2
detailed cybersecurity risk assessment workflow
1041
6.6.1
Vulnerability identification
1042
1043
1044
1045
1046
1047
Understanding what vulnerabilities exist is an important input to the performance of a detailed
cybersecurity risk analysis. This allows for the identification of threat scenarios that can exploit
these vulnerabilities. The linkage of vulnerabilities to threat scenarios is performed later in the
work process and guidance is provided in the next sub -section. Vulnerability identification is best
performed prior to convening the risk assessment team to perform their assessment as it does not
require the full team and thus acts as an input to the risk assessment.
1048
1049
1050
1051
1052
1053
It should be acknowledged that even when vulnerability identification is performed prior to the risk
assessment, which does not preclude other vulnerabilities being identified during the risk
assessment, and even after the risk assessment, e.g., Factory Acceptance Test (FAT), Site
Acceptance Test (SAT), initial validation, revalidation. Even though this section covers vulnerabil ity
identification prior to a risk assessment, the types of vulnerabilities and methodologies to identify
them remain the same in other lifecycle phases.
1054
1055
1056
ANSI/ISA-61511-1:2016 requires a security risk assessment with respect to security vulnerabilities.
ANSI/ISA 62443-3-2:2020 includes the identification of vulnerabilities as an integral part of a
detailed level cyber risk assessment.
ISA-TR84.00.09-2023
- 56 -
1057
6.6.1.1 Purpose
1058
1059
For a hazard to be activated, it is necessary that there are one or more threats that exploit one or
more vulnerabilities.
1060
1061
1062
Therefore, the purpose of this step in the risk assessment work process is to identify vulnerabilities
associated with the assets and measures currently planned or already implemented to better
understand potential threat vectors and their impact on risk reduction capability.
1063
6.6.1.2 Input and Guidance
1064
From an assessment perspective, it is convenient to group vulnerabilities into categories as follows:
1065
1. Device vulnerabilities
1066
1067
a. Device hardware, firmware, and software vulnerabilities: These are device
vulnerabilities that have been published by the vendor or security researchers.
1068
1069
1070
b. Gaps in device technical capabilities: These are deficiencies in device
capabilities when comparing device security level capabilities provided by
manufacturer versus security level target values determined by asset owner.
1071
1072
1073
2. Network vulnerabilities: As part of the development of architecture drawings, it is
generally accepted good practice to conduct an architecture drawing review. During this
review meeting, vulnerabilities due to potential segmentation issues are documented.
1074
1075
1076
3. Gaps in procedural capabilities: Gaps in procedural capabilities can be known failures
to meet organizational security requirements, e.g. , change management or backup
procedures.
1077
4. System vulnerabilities
1078
1079
1080
a. System software vulnerabilities: These are known or unknown vulnerabilities in
a system composed of more than one device . Known vulnerabilities are published
by the vendor or security researchers.
1081
1082
1083
b.
Gaps in general / zone technical capabilities: Gaps in technical capabilities for
devices can be known failures to meet security requirements, e.g. , authentication
or encryption capabilities.
1084
1085
1086
1087
5. System integration vulnerabilities: At this stage of the lifecycle, it is possible to identify
vulnerabilities associated with some of the major categories. Since the system has not yet
been constructed, identification of system integration vulnerabilities is not possible at this
stage.
1088
1089
Inputs for the vulnerability assessment that can be performed at this stage are include d in table
6.1.
Vulnerability Type
1.a Device hardware,
firmware, and software
vulnerabilities
Inputs and Guidance
•
Asset inventory
•
Vulnerability databases or tools: For device vulnerabilities,
matching of the system information from the asset
inventory with vulnerability database information is
required.
•
Asset inventory
•
Recommended SPR-T / SL-T (if already defined) for each
essential function or asset group, which can be used to
yield a list of SL-C requirements in ISA 62443-4-2 that
And
4.a System software
vulnerabilities
1.b Gaps in device
technical capabilities
ISA-TR84.00.09-2023
- 57 -
Vulnerability Type
Inputs and Guidance
devices are expected to meet, if compliance with ISA 62443-4-2 is a known requirement at this point. This list
can also be handed to manufacturers to clarify security
expectations.
2. Network
vulnerabilities
•
System diagrams
3. Gaps in procedural
capabilities
•
Policies, procedures, and work practices
•
Documentation to support whether requirements in ISA
62443-2-1 have been or will be implemented or not, if
compliance with ISA-62443-2-1 is a known requirement at
this point
Note: Documentation should explicitly confirm whether technical
requirements that have or will be implemented are supported by
those organizational measures necessary for the technical
measures to be effective.
4.b Gaps in general /
zone technical
capabilities
•
Zone and conduit diagrams
•
Initial cybersecurity measures to the extent known
•
Documentation to support whether requirements in ISA
62443-3-3 have been or will be implemented or not, if
compliance with ISA-62443-3-3 is a known requirement at
this point
1090
Table 6.1
1091
Device vulnerabilities
1092
1093
1094
1095
1096
1097
1098
There may be known or unknown vulnerabilities in specific hardware, firmware, or software . Known
vulnerabilities are published by the vendor or security researchers. There are numerous sources
of information and tools regarding known and common vulnerabilities in IACS, such as the
industrial control system computer emergency response team (ICS -CERT) database or CVE
databases, which can be used to look up and document existing vulnerabilities for the proposed
asset inventory. Reference Annex C, Vulnerability Assessment Methodologies , for additional
guidance for the performance of the device (hardware/software) vulnerability assessment.
1099
Gaps in technical capabilities for devices
1100
1101
1102
1103
1104
1105
Such gaps can be known failures to meet security requirements, e.g. , authentication, encryption
capabilities, etc. If preliminary SL-Ts have already been identified, gaps in technical capabilities
can be identified by comparing a devices capability to its SL-T requirements. This is done by
comparing requirements in ISA 62443-4-2 to the capabilities of a specific manufacturer and model
number. Reference Annex C, Vulnerability Assessment Methodologies, for additional guidance for
the performance of the device technical capability vulnerability assessment.
1106
IACS Network Vulnerability Assessment
1107
1108
1109
1110
1111
As part of the initial design to support scope and budget development, architectures drawings will
be created. As part of this development process, there should be an architecture drawing review
meeting where segmentation is reviewed with respect to recognized and generally acce pted good
engineering work practices (RAGAGEP). During this review, which can be considered an IACS
Network Vulnerability Assessment, any potential vulnerabilities identified should be documented
ISA-TR84.00.09-2023
- 58 -
1112
1113
and recommendations made as applicable. This information is valuable input to the detailed level
cyber risk assessment.
1114
Gaps in general / zone technical capabilities.
1115
1116
1117
The technical capability can be determined as a function of what ANSI/ISA 62443 -3-3 technical
requirements are (if compliance to ANSI/ISA 62443-3-3 is a known requirement at this point)
provided by the device from the manufacturer.
1118
1119
1120
1121
1122
If zones have been established based upon the initial risk assessment with a SPR -T initially
proposed for each zone, a gap assessment of ANSI/ISA 62443-3-3 technical requirements can be
performed to establish what security measures are included in the design for each zone as wel l as
from a general overall perspective that would apply to all zones. This activity would provide the
SL-C for each zone that is the technical contribution to the SPR -C.
1123
1124
Reference Annex C, Vulnerability Assessment Methodologies, for additional guidance for the
performance of the general/zone technical capability vulnerability assessment.
1125
Gaps in procedural capabilities
1126
1127
1128
1129
1130
1131
Organizational procedures are necessary to support the technical measures, otherwise, the
technical measures will not be effective. If compliance to a standard including organizational
measures like ISA 62443-2-1 is pursued, the organizational measures in place or included within
the scope can be compared to ISA 62443-2-1 to determine any gaps. Reference Annex C,
Vulnerability Assessment Methodologies, for additional guidance for the performance of procedural
capability vulnerability assessments.
1132
1133
1134
1135
1136
1137
1138
The maturity level of the procedural measures needed to support the technical measures should
be determined by performing a maturity level assessme nt of those organizational measures. This
is the second input for determining an assumed SPR -C. Any deficiencies relative to what is
required to assume conformance to the SPR-T would be considered a gap and should be
addressed with the detailed level cyber risk assessment team during the subsequent step.
Reference Annex A, Maturity Level Assessment and Annex I, Security Protection Rating
Verification, for additional guidance.
1139
System integration vulnerabilities
1140
1141
1142
1143
1144
1145
At this stage of the lifecycle, system integration vulnerabilities can only provide a review of the
conceptual design as it relates to the architecture, zone, and conduit diagrams as well as the data
flow documentation. Configuration vulnerabilities also considered part of the system integration
vulnerabilities is more appropriately dealt with during design and implementation, e.g. , FAT, SAT,
initial validation. It also comes into play during the stage 4 assessment that occurs during operation
and maintenance phases of the lifecycle.
1146
6.6.1.3 Output
1147
1148
Documentation of the following should be available to the detailed level cyber security risk
assessment team to conduct their workshop.
1149
•
List of vulnerabilities for SuC
1150
o
Device vulnerabilities (hardware, firmware, and software)
1151
o
System vulnerabilities
1152
o
Gaps in technical capabilities compared to a target standard
1153
1154
o
Gaps in procedural capabilities needed to make technical capabilities effective
compared to a target standard
ISA-TR84.00.09-2023
- 59 -
1155
6.6.2
1156
6.6.2.1 Purpose
1157
1158
1159
The purpose of this first step of the Detailed Cybersecurity Risk Assessment is the identification
of cybersecurity risk scenarios in sufficient detail to assess their likelihood and consequence later
in the process as well as derive security requirements that would prevent them.
1160
6.6.2.2 Input and Guidance
1161
1162
1163
A cybersecurity risk scenario is a combination of a vulnerability and a threat exploiting it. During
the cybersecurity risk scenario identification, the previously identified cybersecurity vulnerabilities
are combined with threats to identify risk scenarios for further analysis.
1164
1165
In summary, the following inputs are necessary for the identification of cybersecurity risk
scenarios:
1166
1167
1168
•
Identification of Cybersecurity Risk Scenarios
Information on purpose and functionality of the system under consideration: The
information already gathered during the initial cybersecurity risk assessment and
partitioning into zones and conduits can be used further:
1169
a. Data flow diagrams / high-level use case diagrams
1170
b. Architectural diagrams
1171
c. Zone and conduit diagrams
1172
1173
1174
•
Identified hazards and potential consequences as derived from process hazard
analysis. Cybersecurity threats differ from hazardous events in that they always have an
origin in using or abusing an IACS, but ultimately, they may result in a hazardous even t.
1175
1176
•
List of vulnerabilities for SuC as found during vulnerability identification in the previous
phase.
1177
1178
1179
1180
•
Common threats for the SuC. This can be self-identified scenarios or those created with
the help of threat modeling and intelligence information, information from threat modeling
frameworks like MITRE ATT&CK, from threat catalogues like NIST SP 800 -30, from past
penetration tests, or from past public or private incidents.
1181
1182
•
The risk criteria to be considered and tolerable risk criteria as determined during
scope definition
1183
1184
1185
1186
The vulnerability and threats information can be considered analogous to the process safety
information used for PHA. Some of the cyber security information should be contained as part of
the process safety information, e.g., information pertaining to the technology of the process,
information pertaining to the equipment in the process.
1187
1188
1189
1190
1191
The Initial Cybersecurity Risk Assessment already built upon the hazardous events and checked
WHICH of them could be induced by the systems and functions u nder consideration. The detailed
cybersecurity risk assessment now takes these results to analyze HOW these hazardous events
could be induced by stopping, using, or abusing one of the controls and / or safety functions defined
as essential functions.
1192
1193
1194
1195
More specifically, the existing safety analysis can assist in identifying cybersecurity risk scenarios
as follows: Safety functions, layers of protection or initiating events can be analyzed for possibly
being susceptible to security threats, and cybersecurity vulnerabilities and cybersecurity threats
can be analyzed for possibly leading to known hazardous events.
ISA-TR84.00.09-2023
- 60 -
1196
1197
It must be noted that while using safety analyses as a basis for identifying cybersecurity risk
scenarios, not all security threats may be identifie d this way.
1198
1199
1200
1201
1202
1203
1204
A weakness of traditional Hazard Identification methods such as HAZOP and FEMA is that they
only consider one cause-consequence pair at a time, therefore, scenarios of very low frequency
and high consequence can be undefined. Therefore, there c ould be cybersecurity risk scenarios
leading to consequences that were not identified in the safety hazard and risk assessment. For
the same reason, it can be insufficient to only focus on the protection of systems fulfilling safety
functions, but on all systems that could lead to relevant cybersecurity risk scenarios ( i.e., essential
functions).
1205
1206
1207
1208
1209
Also, the cybersecurity risk scenario identification needs to account for scenarios that might
overwhelm typical plant safeguards normally resilient to cyber -attack such as relief valves due to
demands on the relief valve created by a cyber-attack for which the relief valve was not designed.
It is therefore essential that the ability to make practical recommendations for implementation
consider existing process safety information and how it is impacted by new potential realities.
1210
1211
The more detailed the scenarios for each of these cybersecurity threats can be described, the
better they facilitate deriving security measures preventing or mitigating them.
1212
6.6.2.3 Output
1213
1214
The output of the identification provides the input for subsequent analysis of unmitigated as well
mitigated risk:
1215
1216
1217
•
Cybersecurity risk scenarios including naming of the threats and vulnerabilities
potentially leading to hazardous events as well as detailed descriptions of their
combination in concrete risk scenarios for the specific SuC and plant.
1218
1219
Reference worksheets in Annex D, Risk Assessment Methodologies, for example worksheets that
represent identification.
1220
6.6.3
1221
6.6.3.1 Purpose
1222
1223
1224
1225
During the evaluation of risk, the previously defined cybersecurity risk scenarios are assessed
based on consequence, likelihood, and security measures available. The purpose of the risk
evaluation is to prioritize risks and to provide a basis for determining if the resulting risks are
tolerable as compared to the asset owner’s tolerable risk criteria.
1226
6.6.3.2 Input and Guidance
1227
1228
The risk, consisting of consequence and likelihood, should be evaluated for each risk scenario
using the asset owner’s tolerable risk criteria and risk metrics.
1229
1230
1231
This is done twice: First without considering security measures (“unmitigated risk”) and then aga in
after assignment of the target security level (SL-T), this time considering security measures that
are part of the design (“residual risk”).
1232
Risk Evaluation
a. Security Protection Rating (SPR)
1233
1234
1235
1236
The concept of SPR has been developed as a methodology for a structured evaluation of the
technical and related organizational security measures included in a holistic protection scheme for
an IACS in operation. While security levels (SL) pertain only to technical measures, SPR also
include organizational measures.
1237
1238
The method for defining SPRs may vary and is the responsibility of the asset owner. It is
recommended to define SPR metrics and expectations for target SPRs (SPR -T) alongside the
ISA-TR84.00.09-2023
- 61 -
1239
1240
asset owner’s tolerable risk criteria for consequence and likelihood. For fur ther guidance on
defining and assigning SPRs, see ISA 62443 -2-2 and ISA 62443-3-2.
1241
1242
1243
1244
Note: SPR-T (or target security level SL-T) are not to be confused with the Safety Integrity Level
(SIL). The SIL and SPR-T / SL-T of a system may differ and are not correlated. Also, in contrast
to SIL values, there is no direct correlation between the amount of risk reduction and the SPR
values.
1245
1246
1247
1248
1249
1250
The recommended SPR-T or SL-T for each asset group or each asset group as a function of
process unit operation provides another basis for the creation of zones and conduits. The SPR -T
dictates the technical requirements that apply in accordance with ISA 62443 -3-3. When creating
zones this is helpful as zones are supposed to have the same security measures. The SL -T for the
zone can then be used to define the SPR-T for the zone so that organizational measures defined
by ISA 62443-2-1 necessary to support the technical measures are identified for implementation.
1251
1252
b. Unmitigated risk
In summary, the following inputs are valuable for the eval uation of unmitigated risk:
1253
1254
•
The risk criteria to be considered, tolerable risk criteria and risk metrics including a
method for determining SPR-T.
1255
1256
•
The initial risk evaluation containing the worst-case unmitigated risk per essential
function or asset group
1257
•
The cybersecurity risk scenarios previously identified
1258
1259
1260
1261
1262
Note on risk assessment: Safety risk assessments are, in general, more quantitative in nature than
those currently performed for cybersecurity , however, within cyber security risk assessments there
is a mix between qualitative and quantitative methods used . Reasons for that include differences
in potential threat sources (human, dynamic, hard to predict in security opposed to technical, static,
and better predictable in safety) and the lack of adequate security threat scenario statistics.
1263
1264
1265
Based on the evaluation of unmitigated risk, a target Security Protection Rating (SPR-T) is
assigned at least for each zone and conduit, but potentially on a more granular level e.g. , per
function or per system (representing a subzone).
1266
c. Residual risk
1267
1268
1269
1270
1271
1272
Safety protection layers can significantly change the likelihood and consequences of cybersecurity
risk scenarios (as well as potentially introduce new possibilities for risk scenarios). This is the
reason why it is recommended to have the safety requirements already specified when beginning
the Detailed Cybersecurity Risk Assessment (see Figure 6.2). In some cases, it may be appropriate
to consider safeguards not impacted by cyber security events in addit ion to security measures in
the determination of residual risk.
1273
1274
For the residual risk assessment, SPRs – being a structured evaluation of applied technical and
organizational security measures – can be used as an indicator for risk reduction.
1275
1276
1277
For the residual risk evaluation, the following inputs are needed in addition to those for the
unmitigated risk evaluation:
1278
1279
1280
•
Information on existing security measures for each zone and conduit. If security
measures affect architecture and / or data flow, these may also be documented in system
diagrams.
ISA-TR84.00.09-2023
1281
1282
1283
•
- 62 -
Existing protection layers and initial safety requirements and – including – protection
not impacted by cyber security risk scenarios. These affect likelihood and / or
consequence of security risk scenarios.
1284
6.6.3.3 Output
1285
The outputs of the evaluation of risk are
1286
•
Unmitigated risk for each cybersecurity risk scenario, leading to
1287
1288
•
The target security protection rating (SPR-T) for each zone or conduit, function, or
system.
1289
1290
•
A rating of existing security measures against the target Security Protection Rating,
leading to
1291
•
Residual risk for each cybersecurity risk scenario
1292
6.6.4
1293
6.6.4.1 Purpose
1294
1295
During the resolution of risk, it is ensured that the residual risk is sufficiently low to satisfy the
asset owner’s tolerable risk criteria.
1296
6.6.4.2 Input and Guidance
1297
1298
1299
1300
The residual risk is sufficiently low if the residual risk evaluation for each cybersecurity threat
scenario is lower than the asset owner’s tolerable risk and the assigned SPR -T for each zone,
conduit, function, or system, is met to an extent that fits in with the asset owner’s tolerable risk
criteria.
1301
Consequently, required inputs for risk resolution are
Risk Resolution
1302
1303
•
The asset owner’s tolerable risk criteria and risk metrics including a method for
determining SPR-T.
1304
•
The residual risk for each cybersecurity risk scenario
1305
1306
•
The target security protection rating (SPR-T) for each zone or conduit, function, or
system
1307
6.6.4.3 Output
1308
The output of the risk resolution is
1309
1310
•
either an approval that the design has the capability to satisfy an asset owner’s tolerable
risk criteria (and the associated SPR-T)
1311
1312
•
or recommendations to further reduce risk by additional cybersecurity requirements and
re-iterate risk evaluation and resolution.
1313
1314
Reference Annex D, Risk Assessment Methodologies, for an example of a completed worksheet
that covers identification, evaluation, and resolution.
ISA-TR84.00.09-2023
- 63 -
1315
7
Requirements Specification
1316
1317
7.1
Cybersecurity Requirements Specification (CRS) and consolidation with Safety
Requirements Specification (SRS)
1318
7.1.1
1319
1320
1321
The Cybersecurity Requirements Specification (CRS) provides an orderly transfer of information
from the cybersecurity risk assessment into the design phase, reducing the potential for cost
overruns due to the need for future rework/scope changes during detailed design a nd beyond.
1322
1323
Documentation of a CRS is a requirement of ISA 62443 -3-2, just as a safety requirements
specification (SRS) is a requirement of ISA 61511 Part 1.
1324
7.1.2
1325
1326
1327
1328
1329
During the scope definition or specification phase of a capital project, performance of initial design
work assists determination of project cost. Initial development of the CRS should begin to
document best estimates of requirements. Following completion of the detailed cyber risk
assessment and identification of required security measures, finalization of the CRS reflecting the
design basis, allows commencement of detailed design work.
1330
1331
1332
1333
1334
The CRS can be a separate document or additional information included as part of the safety
requirements specification. It should consolidate all cybersecurity requirements information. Also,
at this point in the combined safety and security workflow, cybersecurity requirements are
reconciled with safety requirements. Potential contradictions between cybersecurity and safety
requirements should be resolved.
1335
Therefore, the requirement specification considers the following inputs:
1336
1337
1338
•
All cybersecurity requirements from initial scope definition including relevant policies and
regulations, partitioning into zones and conduits and the detailed cybersecurity risk
assessment.
1339
•
Safety requirements from the initial safety requirements specification (SRS).
1340
•
Potential contradictions between safety and cybersecurity requirements.
1341
7.1.3
1342
1343
The result of the requirements specification represents the interface to the design phase. Therefore,
it should be
Purpose
Input and Guidance
Output
1344
•
a consolidated version of all outputs of the hazard and risk analysis phase,
1345
•
a full list of safety requirements from policies, regulations, and risk assessments
1346
1347
1348
•
a full list of cybersecurity requirements for each zone and conduit, including all
cybersecurity requirements from policies, regulations, and risk assessments and
consolidated with above safety requirements.
1349
1350
1351
An example Cybersecurity Requirements Specification (CRS) Template with recommended
information to include is provided in Annex G, Cybersecurity Requirements Specification (CRS)
Template.
1352
8
Stage 1 Preliminary Design Assessment
1353
8.1.1
Purpose
1354
1355
The intent of the stage 1 project assessment is to ensure that the project specification is complete
and consistent with the intent of the risk assessment.
ISA-TR84.00.09-2023
- 64 -
1356
1357
1358
The purpose is to ensure an orderly transfer of information prior to commencement of the detailed
design engineering, thereby reducing the potential for cost overruns due to the need for future
rework/scope changes during detailed design and beyond.
1359
8.1.2
1360
1361
1362
1363
1364
Performance of a stage 1 cybersecurity assessment should occur following completion of the
detailed cyber risk assessment, identification of required security measures and finalization of the
SRS / CRS information. Competent personnel should complete performance of this assessment
via an independent check. These persons should have both the knowledge and experience to
judge both the completion of expected work and when applicable, the quality of such work.
1365
The input for the stage 1 project assessment is
Input and Guidance
1366
1367
1368
•
1369
8.1.3
1370
The result of stage 1 assessment is
The consolidated information from the safety and cybersecurity requirements specification
containing all results from the project scope definition and the hazard and risk analysis
phases.
Output
1371
•
Either an approval to enter design phase OR
1372
•
A requirement to resolve hazard and risk analysis phase action items
1373
1374
An example checklist template to aid in this assessment is included in Annex B, Cyber security
Assessment Stage Check List Templates .
1375
9
1376
1377
1378
1379
The detailed design is a continuation of the preliminary design work covered in chapter 5 and
incorporates the action items that are derived from risk assessment(s) that culminate in a cyber
security requirements specification. This phase has several activities that are encompassed within
the expanded design and procedure development work process shown in figure 9.1 below.
Detailed Design & Procedure Development
Training / Competence
Detailed Engineering
Procedure Development
SPR-C Verification
SPR-C > or = SPR-T
Design Documentation
(Outputs)
1380
1381
Figure 9.1 ̶ Expanded Design and Procedure Development Work Process
1382
1383
1384
Once the cyber requirements specification is available, an iterative design process involving
network, IACS control engineers, and process safety personnel with input from operations and
maintenance should take place to ensure that the expected performance requirements, e.g.,
ISA-TR84.00.09-2023
- 65 -
1385
1386
1387
1388
identified security measures, including policies, operating and maintenance procedures,
emergency response procedures, equipment, software capabilities, training and level of rigor are
appropriate. These activities culminate in the documentation needed for implem entation, and
ultimately operation and maintenance.
1389
9.1
1390
The following are typical inputs to begin detailed engineering:
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
Inputs
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Regulatory requirements
Adopted industry standards
Corporate policies and procedures
Business enterprise requirements
SuC Description (inclusive of field devices to interface overlap with IT)
Controls Philosophy
Maintenance philosophy
Reliability requirements
Availability requirements
SuC asset inventory (hardware and software)
Process Safety Information
P&ID’s
Architectural Drawings
Zone & Conduit Drawings
IFs and safeguards assigned to layers of protection
HAZOP worksheets / report
LOPA worksheets / report
Data flow requirements and rationale
Vulnerability assessment(s)
Detailed level cyber risk assessment report
Safety Requirements Specification (SRS)
Cybersecurity Requirements Specification (CRS)
Manufacturer cybersecurity manuals
Access requirements based on least privilege
Approved vendor list
Stage 1 assessment/audit findings
ISA-TR84.00.09-2023
- 66 -
1418
1419
9.2
Roles / Training / Competence
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
ISA 62443-1-1 refers to three principal roles, i.e., asset owner, service provider, and product
supplier as well as some other roles that have some level of involvement or interest in securing
the SuC, e.g., regulatory bodies, insurers, and training and certification bodies. Within the principal
roles, there can be a multitude of disciplines or professional roles, whose names may be quite
different for various Asset Owners, Integration Service Providers, or Product Suppliers. In additi on,
the skills and responsibilities of each Professional Role may vary considerably during different
phases of the lifecycle. It is quite possible that some of the professional roles are performed by
the same person, especially as the organization’s size varies. Table 9.1 below lists various generic
professional design roles and provides a description of what is generally expected as part of that
function.
1430
Table 9.1 Notes
1431
1432
1. All personnel should undergo basic cyber hygiene training. This may include but not
necessarily limited to:
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
• Selection and maintenance of high-quality passwords
• Installation and maintenance of security software on digital devices
• Keeping virus definitions up to date
• Running regular security scans on their digital devices
• Adherence to cyber security policies
• Protection of one’s personal data
• Avoiding potential sources of infection
Implementation of key security settings
Compliance with configuration management program
• Recognition and compliance with cyber security management of change policies, e.g.,
configuration changes
• Respond as needed whenever cyber security is found out of compliance
• Compliance with access control policies
1446
1447
1448
1449
•
•
•
Protection of one’s personal account credentials
2. Each role should be assessed for what specific training should be provided as a function
of the skills required to perform the functions expected by the specific role.
ISA-TR84.00.09-2023
Design Role
Plant Manager (Area
Supervisor)
- 67 -
Description
Competency
Person that owner/operator
designates as having approval
authority. Manages the operational
resources, budget and planning
related to SIS.
Awareness training with PSCAI and cybersecurity lifecycle and
understands personal role and responsibility including local
Functional Safety and Security Management Plan,
Project Manager
Coordinates activities. Manages the
project resources, budget and
schedule related to PSCAI.
Awareness training with PSCAI and cybersecurity lifecycle and
understands personal role and responsibility with respect to
company risk management, including training, documentation,
cybersecurity management system and proof test plans.
SIS Specialist
Assigned competent and qualified
keeper of SIS - technology and
lifecycle processes. The SIS specialist
should understand the process, the
equipment, the operation, basic
process control system design,
protection layer design, safety
instrumented system design, human
ergonomics, consequence modelling,
and hazard and risk analysis. Focus
can be as well project- as operational
related. (Can be 3rd party)
Demonstrated knowledge of ANSI/ISA 61511-1 and ISA 62443,
especially 2-1, 2-4 and 3-3, 4-2 and company standards and
procedures.
Product supplier/integrator subject
matter expert,
Demonstrated knowledge of ANSI/ISA 61511-1 Ed2 and IEC
62443, especially 2-1, 2-4, 3-3, 4-1 and 4-2,
Ensures that security guidance from
the vendor is provided and explained
as needed.
Understands the risk criteria to be applied by the client during the
design and the roles and responsibilities of the other parties in
projects and the entire lifecycle,
SIS Vendor Specialist
Knowledgeable concerning the physical process hazards and its
relation of company risk criteria.
Understands the risk criteria to be applied by the company during
the design and the roles and responsibilities of the other parties in
projects and the entire lifecycle,
Demonstrated experience and training on hazard and risk analysis
methodology and training in cybersecurity impact of device
selection and design,
Demonstrated knowledge in device common mode/common cause
failures, the work process for selection of devices, the design,
selection of safety integrity and reliability data, installation, and
management of PSCAI and methods for SIL verification.
Demonstrated experience and training on hazard and risk analysis
methodology, the cybersecurity lifecycle with respect to the applied
vendor SIS platform,
Demonstrated knowledge in device common mode/common cause
failures, the work process for selection of devices, the design,
ISA-TR84.00.09-2023
- 68 -
Design Role
Description
Competency
selection of safety integrity and reliability data, installation and
management of SIS and methods of SIL verification.
SIS System Engineer
Competent and qualified person
developing and implementing the SISLogic Solver application program.
(Can be 3 rd party)
Demonstrated knowledge of ANSI/ISA 61511-1 and ISA 62443,
especially 2-1, 2-4, 3-3 and 4-2,
Understands the company risk criteria to be applied during the
design,
Demonstrated experience and training in cybersecurity impact of
device selection, design, installation, and management of SIS
application programming.
SIS Instrument
Engineer
Competent Control and
Instrumentation Project Lead for
Designing & Specification, verifying
Purchasing and Construction (Can be
3rd party)
Demonstrated knowledge of ANSI/ISA 61511-1 and ISA 62443,
especially 2-1, 2-4, 3-3 and 4-2,
Understands the company risk criteria to be applied during the
design,
Demonstrated knowledge in device common mode/common cause
failures, the work process for selection of devices, the design,
selection of safety integrity and reliability data, installation and
management of SIS and methods of SIL verification.
Project SIS Team
Member
Preparing and Managing Control and
Instrumentation Construction and precommissioning. Under supervision of
a SIS System / Instrument Engineer or
Specialist.
Awareness training with PSCAI and cybersecurity lifecycle and
understands personal role and responsibility
BPCS Engineer
Developing and implementing the
BPCS application program. (Can be
3 rd party)
Demonstrated knowledge of ISA 62443, especially 2-1, 2-4 3-3 and
4-2,
Awareness training with PSCAI and cybersecurity lifecycle and
understands personal role and responsibility ,
Demonstrated knowledge, experience, and training with selected
BPCS environment.
BPCS team member
Preparing and Managing Control and
Instrumentation Construction and precommissioning. Under supervision of
an IACS Engineer (Can be 3 rd party)
Awareness training with PSCAI and cybersecurity lifecycle and
understands personal role and responsibility ,
ISA-TR84.00.09-2023
Design Role
OT cybersecurity
vendor specialist
- 69 -
Description
Product suppliers, integrators
(including system integrators as well
as architectural and engineering
contractors.
Ensures that security guidance from
the vendor is provided and explained
as needed.
Competency
Demonstrated experience or training with selected BPCS
environment.
Demonstrated knowledge, training and experience with ANSI/ISA
61511-1 and ISA 62443, especially 2-1, 2-3, 2-4, 3-2, 3-3, 4-1 and
4-2,
Demonstrated knowledge, experience and training with
cybersecurity design and implementation for selected BPCS / SIS
integration.
Industrial
cybersecurity
engineer
OT cyber competent and
knowledgeable person that ensures
security requirements are
implemented in design phase.
Demonstrated knowledge and training of ANSI/ISA 61511-1 and
62443, especially 2-1, 2-4, 3-2, 3-3 and 4-2,
Industrial network
engineer
Competent and knowledgeable person
that is responsible for networks that
are focused on OT, e.g., the IACS and
associated networks.
Demonstrated knowledge and training of ANSI/ISA 61511-1 and
62443, especially 2-1, 2-4, 3-2, 3-3 and 4-2,
Competent and knowledgeable person
that is responsible for the IT portion of
the IT/OT overlap and who is
responsible for communication of
corporate cyber policies and
practices.
Demonstrated knowledge or training of secure 62443, especially 21, 2-4, 3-2 and 3-3.
Competent and knowledgeable Plant
Health, Safety and Environment
Representative responsible for
specification of requirements for
hazard and risk assessments resulting
in safety requirements specification.
Demonstrated knowledge of IEC 62443, especially 3-2,
IT Representative
Process Safety
Engineer
Demonstrated knowledge and experience in designing and setting
up secure OT systems.
Demonstrated knowledge and experience in designing and setting
up secure OT systems.
Awareness training with PSCAI and cybersecurity lifecycle and
understands personal role and responsibility .
Demonstrated software knowledge for design of secure systems.
Demonstrated experience and training with PSCAI lifecycle and
understands personal role and responsibility,
Demonstrated knowledge in the risk criteria to be applied during
the design,
Demonstrated knowledge in hazards and risk analysis
methodologies as applicable,
ISA-TR84.00.09-2023
Design Role
Operations
Representative
- 70 -
Description
Coordinates operational input. For
example, graphics design and location
of manual shutdown pushbuttons,
operator training and proof testing
Competency
Demonstrated experience/training in equipment design limitations,
process hazards and interactions with other process units.
Awareness of IEC 62443, especially 2-1, 2-4 and 3-2,
Awareness training with cybersecurity and PSCAI lifecycle and
understands personal role and responsibility,
Knowledgeable/experienced in operating procedures including
response to diagnostic and critical alarms,
Experience or training on process hazards, on the impact of proof
testing on plant operation, on the impact of alarm response and
operational activities on safe operation,
Awareness in the risk criteria to be applied during the design,
Awareness training in cybersecurity risks, cybersecurity lifecycle
and in hazards and risk analysis.
Demonstrated knowledge regards the impact of key safety/security
decisions on lifecycle costs of operating contract
Procurement
representative
Responsible for coordinating
procurement specifications for
purchase and contract terms.
Awareness of IEC 62443, especially 2-1, 2-4, 3-3, 4-1 and 4-2,
Awareness training with PSCAI and cybersecurity lifecycle and
understands personal role and responsibility,
Demonstrated experience or knowledge with cybersecurity related
OT as well as IT contract language.
Human Resource
representative
Responsible for
• Coordination of hiring based upon
criteria such as job competence
and experience, ethical character
(e.g., background checks), etc.
• Ongoing monitoring of employees
fit for service (periodic background
checks etc.),
• Development of job descriptions
• Modifications to access privileges
based on job function and whether
retired or terminated
Awareness of IEC 62443, especially 2-1 and 2-4,
Awareness training with PSCAI and cybersecurity lifecycle and
understands personal role and responsibility,
Demonstrated knowledge of requirements as a function of roles,
Demonstrated knowledge with access control, least privileg e and
change management with respect to new hires, change of position,
leaving the company, e.g., retirement, voluntary leave, end of
contract, terminations.
ISA-TR84.00.09-2023
Design Role
Process engineer
- 71 -
Description
Coordinates process input, e.g., what
are the trip set point values and
justification.
Competency
Awareness of IEC 62443, especially 3-2,
Awareness training with cybersecurity and PSCAI lifecycle and
understands personal role and responsibility,
Knowledgeable in the process under evaluation and/or design and
its control dynamics,
Awareness training in hazards and risk analysis and in the risk
criteria to be applied during the design,
Understands equipment design limitations, process hazards,
interactions with other process units and operating proced ures for
various modes of operation,
Awareness of input information required by those executing the
PSCAI design.
Other functional
disciplines/non-cyber
engineers (e.g., civil,
machinery,
mechanical, etc.)
Coordinated technical input for their
area of expertise, e.g., trip set points,
safeguards required, etc. and their
justification.
Awareness training with cybersecurity and PSCAI lifecycle and
understands personal role and responsibility,
Other functional
disciplines/cyber
engineers (e.g.,
electrical)
Coordinated technical input for their
area of expertise, e.g., trip set points,
safeguards required, etc. and their
justification.
Demonstrated knowledge of IEC 62443, especially 2-1, 2-4 and 33, 4-2,
Knowledgeable in their area of expertise.
Awareness training with cybersecurity and PSCAI lifecycle and
understands personal role and responsibility,
Knowledgeable in their area of expertise.
Construction
Managing and coordinating
construction activities, including (sub)
contractors.
Awareness training with cybersecurity and PSCAI lifecycle and
understands personal role and responsibility,
Knowledgeable in and experience with constructability
assessments,
Awareness of qualification requirements of (sub) contractors,
concerning maintenance training, responsibilities, and capability
and/or the impact (e.g., proof test coverage / test interval) of
testing on PSCAI performance and on cyber hygiene requirements
specific to construction.
ISA-TR84.00.09-2023
- 72 -
Design Role
Description
Non-cyber
maintenance
representative(s),
e.g., mechanical, civil
etc.
Coordinates maintenance input.
Works with the functional engineering
disciplines, e.g., SIS, BPCS,
electrical, machinery, etc. to develop
appropriate cyber inspection,
maintenance, and test activities.
Competency
Awareness training with cybersecurity and PSCAI li fecycle and
understands personal role and responsibility,
Knowledgeable in maintenance and testing practices and
procedures and concerning equipment (including fixed equipment
and instrumentation) failure history and causes,
Experience or training on process hazards, on safety
integrity/reliability data and on the impact (e.g., proof test coverage
/ test interval) of testing on SIS performance,
Awareness in the risk criteria to be applied during the design,
Awareness training in cybersecurity risks, cybersecurity lifecycle
and in hazards and risk analysis.
Cyber maintenance
representative(s),
e.g., electrical, I&C,
etc.
Coordinates maintenance input.
Works with the functional engineering
disciplines, e.g., SIS, BPCS,
electrical, machinery, etc. to develop
appropriate cyber inspection,
maintenance, and test activities.
Demonstrated knowledge of IEC 62443, especially 2-1, 2-4 and 33, 4-2
Awareness training with cybersecurity and PSCAI lifecycle and
understands personal role and responsibility,
Knowledgeable in maintenance and testing practices and
procedures and concerning equipment (including fixed equipment,
electrical and instrumentation) failure history and causes,
Experience or training on process hazards, on safety
integrity/reliability data and on the impact (e.g., proof test coverage
/ test interval) of testing on PSCAI performance,
Awareness in the risk criteria to be applied during the design,
Awareness training in cybersecurity risks, cybersecurity lifecycle
and in hazards and risk analysis.
Auditor
Independent and competent person
performing audits associated with the
IACS and associated network with
respect to design and activities.
Responsible to record gaps when
discovered.
Demonstrated knowledge with IEC 61511-1 ED2 and IEC 62443 as
applicable,
Understands the risk criteria to be applied during the design,
Awareness of hazard and risk analysis methodology,
Knowledgeable in the applicable work processes being audited
ISA-TR84.00.09-2023
Design Role
Assessor
- 73 -
Description
This person should not be part of the
project team, report to project team
management, or plant operations
Competency
Understands the roles and responsibilities of the other parties in
the project.
Independent and competent person
performing stage assessment(s). This
person should understand:
• The process hazards
• The full lifecycle involving
essential functions
• The fundamentals of appropriate
design, installation, operation,
maintenance, testing, and
reliability.
• Purpose and content associated
with specific stage assessment
being performed
Demonstrated knowledge with IEC 61511-1 ED2 and IEC 62443 as
applicable,
Understands the risk criteria to be applied during the design,
Experience/training on hazard and risk analysis methodology,
Demonstrated knowledge in device common mode/common cause
failures,
Knowledgeable in the work process for selection of devices, in the
design, installation, management of PSCAI and on the methods for
verifying SIL,
Demonstrated knowledge in the appropriate selection of safety
integrity and reliability data,
Knowledgeable in the work processes to provide secure defense in
depth and methods of verifying SPR.
Understands the roles and responsibilities of the other parties in
the project
Table 9.1
Cyber Training/Competence as a Function of Generic Design Related Roles
ISA-TR84.00.09-2023
- 74 -
1450
9.3
1451
1452
1453
1454
Detailed System Engineering should be the responsibility of the assigned Service Provider(s). Integration
Service Providers should be selected by the asset owner as applicable to provide the various systems
design and implementation of the systems within their scope of work and should report to the asset
owner.
1455
1456
1457
1458
1459
An Execution Plan / Strategy should be sufficiently detailed to demonstrate that the Integration Service
Provider is able to execute their work in an efficient manner ensuring the required level of quality while
providing other applicable design service providers with the data required to correctly procure and
construct the Control/Automation/Safety/Cybersecurity Systems. The contents of the Execution Plan /
Strategy should ensure that the design and implementation deliverables are accounted for.
1460
1461
1462
1463
The detailed engineering should include Control/Automation/Safety/Cybersecurity design reviews with the
relevant Vendors and Manufacturers to ensure that the provided systems will meet the asset owner’s
requirements. The asset owner or an asset owner representative may attend these design reviews. The
asset owner should approve all final designs.
1464
1465
1466
1467
The following sections describe various activities that should be accomplished during the design phase as
well as design deliverables. As part of this it is important in the design process to identify the recovery
time and the recovery point objectives that is consistent with the maximum tolerable process downtime.
This is intended to help ensure that recovery is possible for the different cyber-attack scenarios.
1468
9.3.1 Sizing and Selection of Equipment
1469
1470
1471
1472
1473
1474
Prior to specification and procurement, equipment needs to be sized and selected. Sizing ranges
from determining the number of controllers, I/O, sensors, positioners, workstations, backup power
needs, analyzers, etc. For each of the different product and s ystem types, the installed
environment, process environment, functional and cybersecurity requirements should be
considered when selecting the equipment. As part of the selection process, compatibility conflicts
between different manufacturers should be co nsidered and suitably resolved.
1475
1476
When selecting equipment, consideration should be given to whether certificates are needed. This
may be determined via:
1477
1478
1479
Detailed Engineering
•
•
•
ISA 62443-3-3 requirement for conformance to a defined SL-T
Manufacturer recommendation or requirement
Determined via risk assessment
1480
1481
1482
When certificates are used, it is good practice to utilize a local dedicated OT server due to security
risks associated with downloading certificates from the internet. As the OT server represents a
single point of failure, redundancy should be considered.
1483
9.3.2
1484
1485
Procurement of the IACS Systems should be the responsibility of the Service Provider selected by
the asset owner with recommendations and approval from the asset owner.
1486
1487
1488
1489
1490
Specifications should document requirements that address the installed environment, process
environment, functional and cybersecurity requirements. Vendor recommendations and limitations
should be considered as well, documenting those that become requirements as well as the
rationale in the event some are rejected or modified. More specific specification guidance is
provided for products, systems, and service providers in sections below.
1491
9.3.2.1 Equipment Specification Guidance
1492
9.3.2.1.1
1493
1494
1495
Device specifications for equipment that is configurable or programmable (e.g., field devices, I/O,
controllers, workstations, field configuration / calibration / troubleshooting tools, switches, routers,
firewalls, etc.) should define cybersecurity requirements. These should consider:
1496
•
Specification and Procurement
Products
Applicable requirements within the CRS.
ISA-TR84.00.09-2023
- 75 -
1497
1498
1499
•
Minimum required SL-C in accordance with ISA 62443-4-2. (Should include requirement in
FAT/SAT to confirm that the device is setup per the manufacturer’s security manual &
customer requirement/CRS/Functional design spec)
1500
1501
•
Requirement to provide manufacturer security manual or equivalent that matches the
product revision. See Annex H, Manufacturer Security Manuals, for additional information.
1502
1503
1504
1505
1506
•
SL-C information for every requirement that would apply to the asset owner’s zone SL -T
where the device is to be located. This is intended to allow the asset owner to determine
what capability the device can provide, as well as where it is deficient, requiring
compensating security measure(s) within the overall solution. See Annex H, Manufacturer
Security Manuals, for additional information.
1507
1508
•
Requirements for product supplier to verify that its suppliers are in conformance with
ISA62443-2-4, ISA62443-4-1, and ISA62443-4-2 as applicable.
1509
•
Product patching requirements to address known vulnerabilities prior to shipment.
1510
1511
•
Manufacturer notification whenever a new vulnerability is discovered, and a fix is
available. As part of this, the minimum time until end of support should be specified.
1512
1513
•
Minimum required patching support for product as stated by the asset owner. See
ISA62443-2-3.
1514
1515
•
Requirement to support resolution of potential compatibility conflicts with other defined
products that are or will be in use.
1516
1517
•
Documented means to resolve warranty issues given the defined interfaces and interactions
with other products.
1518
•
Payment criteria based on defined deliverables and / or milestones.
1519
9.3.2.1.2
1520
1521
1522
1523
System specifications (e.g., control platforms, packaged equipment such as boilers, rotating
machinery, water treatment, analyzers, fire & gas, life safety detection systems, power monitoring
and control, etc.) for equipment that includes configurable or programmable devices and
communication protocols should define cybersecurity requirements. These should consider:
Systems
1524
•
Applicable requirements within the CRS.
1525
•
SL-C that complies with ISA 62443-3-3 for the SL-T defined by the asset owner.
1526
•
Requirement that system supplier conform with ISA 62443 -2-4 for services provided.
1527
1528
•
Compatibility requirements with other manufacturers used by the asset ow ner in the overall
solution.
1529
1530
•
Requirements for system supplier to verify that its suppliers are in conformance with
ISA62443-2-4, ISA62443-4-1, and ISA62443-4-2 as applicable.
1531
1532
1533
1534
1535
1536
1537
1538
•
Requirements for the system supplier to provide security manuals or equivalents for the
configurable and/or programmable devices used in its solution. See Annex H, Manufacturer
Security Manuals, for additional information. It should be expected that SL -C information
for every requirement for each device used in the system solution be provided that would
apply to the asset owner’s defined SL-T for the solution. This is intended to allow the asset
owner to determine what capability the devices can provide, as well as where they are
deficient, requiring compensating security measure (s) within the overall solution. See
Annex H, Manufacturer Security Manuals, for additional information.
1539
1540
•
Requirement for all devices within the system solution to be patched for known
vulnerabilities as well as firmware updates prior to testing activities, e.g., FAT, SAT.
ISA-TR84.00.09-2023
- 76 -
1541
1542
1543
•
Requirement for notification whenever a new vulnerability is discovered, and a fix is
available for all configurable and/or programmable devices within the system . As part of
this, the minimum time until end of support should be specified for each device.
1544
1545
•
Minimum required patching support for product post startup. Reference ISA TR62443-2-3
for assistance in developing patching requirements as part of the specification.
1546
1547
•
Requirement to support resolution of potential compatibility conflicts with other defined
products that are or will be in use.
1548
1549
•
Documented means to resolve warranty issues given the defined interfaces and interactions with
other products.
1550
1551
1552
•
Temporary system Integration requirements during construction /commissioning. Note:
Examples include management of laptops, other connected equipment, 3 rd party remote
access, 3 rd party tools for FAT/commissioning/SAT, etc.
1553
1554
•
Testing requirements prior to shipping as well as testing requirements following
installation and integration on site, e.g., FAT, SAT, etc.
1555
1556
•
Expectation of how backups are to be managed when under the control of the system
supplier
1557
•
Identification of cyber security diagnostics/alerts/alarms and expected response(s)
1558
•
Requirement that only asset owner approved features be enabled.
1559
•
Documentation of all temporary passwords that need to be changed.
1560
•
Documentation of all required configuration settings
1561
•
Payment criteria based on defined deliverables and / or milestones.
1562
9.3.2.1.3
1563
1564
Service provider specifications for the services provided throughout the lifecycle of project should
define cybersecurity requirements. These should consider:
Service Provider Specification Guidance
1565
•
Applicable requirements within the CRS.
1566
1567
•
Requirements for minimum cybersecurity and functional safety qualifications of the
personnel
1568
1569
1570
•
Requirement that activities conform to asset owner’s applicable policies and procedures
intended for conformance to ISA 62443-2-1. Note: This may require a reconciliation with
service provider practices in accordance with ISA 62443 -2-4.
1571
1572
•
Specification of changes to the system that requires a defined Management of Change
procedure
1573
1574
1575
1576
•
Procedures for providing access to the system including mechanisms for remote
connectivity (in case required), use of temporary accounts, sharing of passwords, us e of
portable media and laptops, allowing wireless connections and interfacing with external
systems (including BPCS etc.)
1577
•
Requirements for secure configurations and settings
1578
1579
•
Requirements for malware protection of the devices in the system and tools utiliz ed for
engineering
1580
1581
•
Specification of necessary hold and witness points at different stages for quality assurance
and compliance to cybersecurity requirements
ISA-TR84.00.09-2023
- 77 -
1582
•
Criterion for selection, validation and application of patches and firmware upgrades
1583
1584
•
Reporting of any significant incidents/events during project execution and requirements for
handling such events
1585
1586
•
Maintaining the confidentiality of the project files, restricting access to the back -ups with
retention policy and having written agreements for non -disclosure of sensitive information
1587
1588
•
Testing requirements for devices and system during FAT/SAT, and approved tools/software
(network scan tools, active/passive VA etc.) to be utilized during testing
1589
•
Document deliverables at the end of the project including but not limited to:
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
o
o
o
o
o
o
o
•
configuration records
change management register
application and event logs
Validation and acceptance results
testing records
back-ups
history of any malware etc. detected, misconfigurations, and software bugs
identified
o alarms and alerts configured specific to cybersecurity
o system/software patch levels
o enabled ports and services
o approved list of software inventory
o check lists indicating compliance to Asset Owner’s requirements, CRS, and
recommendations from risk assessments, with documented ev idence
Payment criteria based on defined deliverables (e.g., final acceptance criteria covering safety,
performance, and cybersecurity domains) and / or milestones.
1606
9.3.3
1607
1608
The purpose of a Network Topology is to provide protection against security compromises. This
starts with the use of a Purdue Model concept design.
1609
1610
1611
1612
1613
1614
1615
1616
The topology should indicate the (a) connectivity of devices within different physical levels of the
architecture design, (b) physical device locations, (c) communication protocols utilized, (d)
physical media between devices and (e) the interface between IT equipment on the business
network and the OT equipment (DCS/SCADA/ etc.). As indicated in ISA-62443-3-2:
1617
1618
1619
1620
1621
The accompanying documents should define the segregation and segmentation boundaries of the
Business and Plant networks (IT network) with respect to securing the IACS/Operational network
(OT network). They should show the different devices used on the OT network, such as, but not
limited to, routers, switches, data diodes, firewalls, intrusion detection systems (IDS), servers,
controllers, human machine interface (HMI), etc.
1622
1623
1624
1625
1626
1627
1628
1629
1630
These documents should also address the following non -exhaustive list, as applicable
• Wireless on the OT side should define the use of 802.11xx connectivity versus OT & IIoT
protocols that utilize 802.15. IIoT devices for greatest security would ideally communicate
through managed single direction outbound data diodes or gateways. When bidirectional
communication is necessary, the IIOT design functions, operation and maintenance should
be fully compliant with ISA62443 requirements.
• The model should address the issue of remote access to the OT network: this could be
done via a DMZ between the IT and OT networks, along with di fferent Multi-Factor
Authentications (MFA) utilized between the two networks. Other means, which ensure the
•
•
Network Topology
The network topology is reviewed and updated with the Data Flow study.
The Configuration Management should address the unique Network’s configuration and
security requirements of the architecture under review.
ISA-TR84.00.09-2023
1631
1632
1633
1634
1635
1636
1637
1638
1639
•
•
•
•
- 78 -
OT system’s safety, availability and integrity can be used for secure connections and
should be detailed in the network topology if selected.
The IACS/OT network should be documented using engineering drawings and detailed
accompanying texts.
The network topology should show and emphasize the segregation of the IACS/OT network
from the IT network and other networks.
The topology for physical disconnection (as a last resort mitigating action) of the two
networks (IT versus OT) should be clearly defined.
Data transfer to/from the SIS should be detailed.
1640
1641
For additional guidance regarding integration of an IACS to an enterprise system, refer to ISA95 ,
Enterprise-Control System Integration - Part 1: Models and Terminology.
1642
1643
1644
1645
1646
IACS Safety typically contains a separate “protection” system such as Safety Instrumented System
(SIS) that brings the controlled process to a safe condition when needed. It is the last instrumented
protection measure and sometimes the last protection measure to avoid a catastrophic event. The
delineation of the SIS and the Control system with emphas is on the segregation and interactions
of both should be thoroughly documented.
1647
1648
1649
1650
1651
Special security attention should be given to any SIS external connectivity, where the SIS remote
connectivity should be treated as part of the SIS Safety Engineering Design se ction and apply
security techniques such as the use of Multi-Factor Authentication (MFA) with segmentation.
Remote access to the SIS should be controlled from the SIS zone and not external to the SIS zone.
Due to the Safety criticality of the SIS, there sh ould be technical and procedural controls in place.
1652
9.3.4
1653
1654
1655
1656
1657
Zero trust can be thought of as a set of guiding principles for workflow, system design, operations ,
and maintenance whose objective is to achieve inherently more secure solutions. It should be
recognized that no single architecture or technology represents zero trust. The purpose of zero
trust is to prevent unauthorized access via access control enforcement being as granular as
possible.
1658
1659
1660
As part of the conceptual design, risk assessment, as well as detailed design, zero trust concepts
should be considered. The decision as to the degree of zero trust to be implemented into the
design and operation is generally made as part of the risk assessment work process.
1661
According to NIST SP 800-207, the tenets of zero trust include:
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
•
•
•
•
•
•
•
Zero Trust Architecture Concept
All data sources and computing services are considered resources
All communication is secured regardless of network location
Access to individual resources is granted on a per -session basis
Access to resources is determined by dynamic policy – including the observable state of
client identity, application/service, and the requesting asset – and may include other
behavioral and environmental attributes
The enterprise monitors and measures the integrity and security posture of all owned and
associated assets.
All resource authentication and authorization are dynamic and strictly enforced before
access is allowed.
The enterprise collects as much information as possible about the current state of assets,
network infrastructure and communications and uses it to improve its security posture.
When implementing zero trust architectures, basic assumptions include:
•
•
•
•
•
The entire enterprise private network is NOT considered an implicit trust zone
Devices on the network may not be owned or configurable by the enterprise
No resource is inherently trusted
Not all enterprise resources are on enterprise-owned infrastructure
Remote enterprise subjects and assets cannot fully trust their local network connection
ISA-TR84.00.09-2023
1680
1681
1682
1683
•
- 79 -
Assets and workflows moving between enterprise and non-enterprise infrastructure should
have a consistent security policy and posture
The following figure 9.2 shows the logical components of zero trust architecture, which includes
the policy engine, policy administrator and the policy enforcement point.
Control Plane
Policy Engine
CDM System
Policy
Administrator
Industry
Compliance
Threat
Intelligence
Untrusted
Subject
Activity Logs
Policy
Enforcement
Point
Data Access
Policy
Policy
Decision
Point
PKI
ID
Management
Trusted
Enterprise
Resource
System
SIEM
System
Data Plane
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
Figure 9.2
Recreated from NIST SP 800-207 (Figure 2)
Data sources and policy rules for use by the central policy engine are intended to include:
•
•
•
•
•
•
•
•
Continuous diagnostics and mitigation system
Industry compliance system
Threat intelligence feed(s)
Network and activity logs
Data access policies
Enterprise public key infrastructure
ID management system
Security information and event management system
1696
1697
Reference NIST Special Publication 800-207, Zero Trust Architecture for more detailed information
and implementation guidance on this subject .
1698
9.3.5
1699
1700
1701
1702
1703
The purpose of a data flow analysis and its subsequent documentation is to:
• Define the fundamental required communications that form the basis of normal expected
data flow
• Document justification of identified data flows, allowing management of change that
prevents implementation and/or removal of unjustified data flows
Data Flow Analysis and Documentation
1704
•
Identify vulnerable data flows that should have additional attention to reduce risk
1705
•
Identify data dependencies that can impact system integrity and functions
1706
1707
1708
1709
Understanding the data flow between the devices within zones and subzones helps to determine
if the zone and conduit segmentation is appropriate. The documentation of expected data flows
provides the baseline for any monitoring system intended to detect abnormal data flow, a key
component in a defense in depth strategy.
ISA-TR84.00.09-2023
- 80 -
1710
1711
The information contained within the Data Exchange Worksheets should be classified according
to company classification policies.
1712
Figure 9.3 below shows how analysis of data flow fits into the safety/security lifecycle.
Develop network architecture
of the IACS
Start
Document cyber asset
inventory
First pass effort to identify
zones & conduits
Perform high level cyber risk
assessment
Document
Document application
application
Documented initial
SL-T
Perform and Document Data
Flow Analysis
Refine / Update Z & C
Initial start of cyber
security req’mt spec
(CRS)
Perform detailed level risk
assessment
Confirm SL-T’s
Perform SPR verification
Documented SPR-C
No
Segmentation
Adequate?
Yes
Improve
countermeasures or
fundamental design
No
Risk Criteria Met?
Proceed to Design
1713
Yes
Update Cyber
Requirements
Specification
Process Safety
Management PHR
Revalidation
1714
Figure 9.3
1715
1716
1717
1718
1719
1720
Analysis and documentation of data flows should occur prior to the detailed cyber risk assessment
portion of capital projects. An inventory of cyber assets needs to be available to perform the
analysis. The final documentation of data flows can help rationalize the segmentation of the
architecture into zones and conduits whether to refine preliminary zone and conduit drawings or
as an input to their initial development. Reference Annex F, Data Flow Analysis for guidance on
how to perform a data flow analysis.
1721
1722
Once the initial analysis and documentation has been completed and approved, any proposed
changes to the data flow should undergo formal management of change (MOC).
ISA-TR84.00.09-2023
- 81 -
1723
9.3.6
Configuration Guidance
1724
9.3.6.1 Configuration Management Process
1725
1726
1727
1728
The configuration of an industrial control system , network and their components have a direct
impact on the security level capability of the system and may impact process safety as well. How
the configurations are created and how they are maintained should employ a disciplined approach
to provide and maintain adequate security.
1729
1730
OT security configuration requirements should be integrated into the existing configuration
management process. Specific OT security configuration activities include:
1731
1732
•
Identification and recording of configurations that impact the SL-C of the industrial control
system and the organization.
1733
1734
•
The consideration of security risks during approval of the initial configuration of the network,
control system and their components.
1735
•
The analysis of security implications due to changes to the configuration(s).
1736
1737
•
Documentation of the approved / implemented changes , including the rationale for the
changes.
1738
The four phases of a configuration management process are:
1739
1740
1741
•
Planning - Developing policies and procedures to incorporate the security requirements in
the existing configuration management process and disseminating the policy and
implementing the procedures throughout the organization.
1742
1743
1744
•
Identifying and implementing configurations - Develop and implement secure baseline
configurations. The baseline configuration for the system and its components represents
an approved secure state consistent with the tolerable risk criteria.
1745
1746
1747
1748
1749
1750
1751
1752
1753
•
Controlling configuration changes - Given the continually changing nature of a system
caused by failed component(s), replacements, software upgrades, software flaw
remediations, application modifications, and access requirements, resolution of test results,
management of change should ensure that changes are formally identified, proposed,
reviewed, analyzed for safety and security impact(s), tested, and approved prior to
implementation. There should be a process to implement emergency / unplanned changes.
These unplanned changes should be reviewed and approved. Each step in the
configuration process should be clearly articulated along with the responsibilities and
authorities of the roles involved.
1754
1755
1756
1757
•
Auditing - Activities (e.g., periodic audits, monitoring) validate that the system configuration
adheres to the policies, procedures, and approved baseline configurations. Monitoring
should identify undocumented system components, misconfigurations, vulnerabilities, and
unauthorized changes.
1758
1759
1760
1761
1762
Further guidance for secure configuration management can be found in IEC-TR63082-1; Intelligent
device management - Part 1: Concepts and terminology, IEC-63082-2; Intelligent device
management - Part 2: Normative Requirements and Recommendations, Top 20 Secure Coding
Practices, and NIST SP800-128; Guide for Security Focused Configuration Management of
Information Systems.
1763
9.3.6.2 Secure Configuration Practices
1764
Secure configurations for an IACS and associated network(s) are achieved through:
1765
1766
•
Secure configurations of the OT/IIOT components, such as but not limited to edge devices,
firewalls, managed switches, servers, workstations, controllers, I/O, field devices (e.g.,
ISA-TR84.00.09-2023
1767
1768
- 82 -
sensors, positioners, VFD, handheld configurators, portable tools, etc.) process analyzers,
fire and alarm panels, cameras, PLCs, network equipment, and protocol converters.
1769
1770
1771
•
Secure configurations typically follow principles such as: principle of least pri vilege,
principle of least functionality, principle of complexity reduction, principle of attack surface
reduction, the principle of secure failure , etc.
1772
1773
1774
•
Secure configurations documented using approved baselines, a set of security
specifications whose rationale has also been documented, formally reviewed, and
approved.
1775
•
Typical security settings are:
o
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
o
o
o
o
o
o
system settings (e.g., session time outs, number of remote connections, session
lock)
authentication controls (e.g., password length, use of special characters, minimum
password age, retry count)
access controls (e.g., permission to files, directories, disk partitions, registry keys,
access to system logs and permissions to install software)
Whitelisting / Firewall rules
methods of remote access (e.g., Secure Socket Layer (SSL), Virtual Private
Network (VPN), Hypertext Transfer Protocol Secure (HTTPS), Secure Shell
Protocol (SSH), Internet Protocol Security (IPSEC)
use of cryptographic algorithms (e.g., using validated cryptographic protocols and
hash algorithms)
audit settings (capturing events such as failures, logons, permission changes,
unsuccessful file access, creation of users and objects, deletion and modification
of system files, registry keys and kernel changes).
1791
1792
1793
1794
•
Secure configurations should start with setting all authorizations in the disabled state and
documenting the purpose of enabling the authorization or access features. Only features
that are required as a function of time (e.g., commissioning/test versus normal operation)
should be enabled.
1795
1796
•
Security impact analysis of each change by evaluating the adverse impact on safety and
security. This applies to both planned changes and emergency changes.
1797
•
As built documentation should be maintained for all configuration changes applied.
1798
9.3.7
1799
1800
1801
1802
1803
1804
In the interest of resource management, the organization may wish to designate the types of
changes that are preapproved (vendor provided security patches, replacement of failed
components) and changes that are typically not included under change control (e.g. , antivirus
signature updates). During the design and implementation work process, the software and
hardware asset inventory should be maintained to be up to date, including the firmware versions.
Chapter 15 provides more specific guidance relative to change management.
1805
1806
1807
1808
Changes to configurations or designs should be reviewed and approved by a cross functional team
of experts to ensure that a proposed change does not negatively impac t process safety or
cybersecurity. This review team includes qualified members of different disciplines such as: system
engineering, system maintenance, process operations, process safety and network engineering.
1809
1810
1811
1812
Best practice for change control includes vetting changes to the system by at least one authorized
individual who is independent from the change requestor. Adequate separation of duties should
prevent the authority to unilaterally propose and approve changes to the configuration. The vetting
activity should be recorded (actions to be taken, assigned responsibilities, target dates), archived
Design Procedures / Approvals
ISA-TR84.00.09-2023
- 83 -
1813
1814
1815
and periodically reviewed by management. Vendor participation may be valuable for insight into
product specific functions, features, or configurations but the su pplier should not be given a vote
on approval of the change.
1816
1817
1818
1819
1820
Prior to implementing secure configurations in the production environment, it is advised to test
them. Tests may identify issues with software compatibility, system driver issues, timing issues,
conflicts between configuration settings, and communication load issues. A tested and approved
configuration can be used as a baseline configuration for implementing system components that
are intended to perform identical functions.
1821
9.4
1822
1823
1824
1825
1826
During the detailed design, all procedures needed to ensure a safe and secure solution should be
confirmed if they already exist or developed in areas that are deficient. Performance criteria such
as the recovery time objective and the maximum tolerable downtime can highly influence both the
technical design as well as the procedures themselves. Several procedural types or categories are
discussed individually in more detail in the subsections below. These include:
Procedure Development
1827
•
Baseline organizational procedures
1828
•
Technical security measure support procedures
1829
•
Compensating security measure support procedures
1830
•
Testing and monitoring procedures
1831
•
Maintenance procedures
1832
•
Emergency Response / Business Continuity
1833
9.4.1
1834
1835
1836
1837
An existing operating company should have corporate policies and procedures that apply to the
entire company, including capital projects . To the extent that they do not exist, the capital project
should develop them as needed. These policies and procedures that apply to OT as well as IT to
the extent they impact OT would address topics such as:
1838
•
Baseline organizational procedures
Physical and logical user access control
o
1839
Least privilege
1840
•
User access control (local and remote)
1841
•
Patch management
1842
•
Malicious code protection
1843
•
Wireless
1844
•
Management of Change
1845
•
Service provider / supply chain integrity
1846
•
Backup/Restore
1847
•
Certificate management that addresses implementation, their expiration and resetting
1848
•
Periodic assessments/audits
o
1849
Key performance indicators
1850
•
Portable media
1851
•
System hardening
ISA-TR84.00.09-2023
1852
•
- 84 -
Personnel security management
1853
o
Personnel screening
1854
o
On boarding / Off boarding
1855
•
Risk assessment and management
1856
•
Network segmentation
1857
•
Maintenance requirements
1858
•
Incident response program and plan
1859
•
Business continuity
1860
•
Obsolescence management
1861
•
Training & Awareness
1862
9.4.2
1863
1864
1865
1866
1867
1868
1869
1870
1871
For each technical security measure to comply with ISA62443 -3-3 requirements included in the
design, the organizational measures necessary to enable the technical security measure
effectiveness should be identified. Once identified, procedures should be developed to document
the expected actions. In an existing facility, some of these procedures may already be in place,
however, this should be verified, and the quality and applicability of the procedure(s) conf irmed.
Whenever there is a gap, applicable procedures to support the technical measure(s) should be
developed and implemented. To accomplish, adequate resource availability should be made available.
This may also require some initial training, even for existing procedures as project personnel
(employees, contractors, system suppliers, etc.) may be new and not familiar with them.
1872
1873
9.4.3 Compensating Security Measure Support Procedures (support for technical or
procedural only)
1874
1875
1876
1877
1878
1879
1880
When the design is not able to implement the technical security measures to satisfy ISA62443 -33 requirements that are a function of the defined SL -T or there is a need for additional risk reduction
identified in the detailed level cyber risk assessment, compensating security measures are
generally warranted. These compensating security measures may be technical measures, or they
may be procedural measures. As stated, in the previous subsection, each technical security
measure included in the design should be supported by those organizational measures necessary
to ensure the technical security measure’s effectiveness.
1881
1882
1883
1884
1885
1886
An example of a technical compensating security measure would be intrusion monitoring. In this
case, procedures detailing expected responses to an intrusion alarm would be needed to realize
the risk reduction credit of the technical measure. An example of compensating procedures may
include the analysis of KPI’s and expected responses. Annex E, Defense in Depth / Security
Measures, contains a more extensive list of security measures and industry resource(s) that
provide guidance that may be useful when considering compensating security measures.
1887
9.4.4
1888
1889
1890
1891
1892
1893
1894
1895
1896
Determination of cyber alerts and alarms should be addressed during design so that they can be
properly managed. This requires understanding what threat events can occur, what the indicators
of compromise are to detect such a threat event, and what the consequence severity would be.
This information is typically the output of a detailed risk assessment. The proce dures necessary
to define the alarm strategy and types as well as how to handle alarms and alerts should be
developed. Once alarms are selected, appropriate actions to be taken as well as who are
responsible for such actions should be developed. It is impo rtant to note that t he number of cyber
Technical Security Measure Support Procedures
Cyber Alarm Management
security alarms should be limited. They should be defined for events that have a significant impact on the
technical/procedural security control measures. The number of alarms should be determined based on the
ISA-TR84.00.09-2023
- 85 -
1897
1898
system’s size, timely response requirements and handling capabilities”. More guidance on alarm management
can be found in ANSI/ISA-18.2-2016, Management of Alarm Systems for the Process Industries.
1899
1900
1901
A cyber security alarm requires a response, while a cyber securit y alert represents information that
allows an operator to determine if a response is warranted. An operator may be a board operator,
or it may be the personnel responsible for the health of the system and/or its associated network.
1902
1903
1904
An example of a cyber security alarm is an antivirus engine detecting a file with a computer virus
that will necessitate it being quarantined until the situation is resolved . An alert might be the start
of an interactive remote access connection, or the detection of a port or pin g scan on a firewall.
1905
1906
1907
1908
1909
Escalation of alert information to a mandatory response under certain conditions is a possibility.
For example, a remote connection during daytime may be an alert while the same alert should it
occur under abnormal conditions (e.g., out of office hours) can be considered an alarm, requiring
a response. For this type of correlation, a SIEM (Security Information and Event Management)
would be a possible solution.
1910
9.4.4.1 Defining cyber security alarm and alert responsibilities
1911
1912
1913
1914
1915
1916
1917
1918
1919
Cyber security is a 24x7 process. It is important to define who should be alerted and who should
receive the alarm to respond. In the case of cybersecurity, it is most often the industrial
cybersecurity engineer responsible for security operations who generally receives the information
and is in the best position to respond. In some cases, their response may not really impact process
operations, while in others, there can be an acute effect. As a result, there should be close
coordination between OT and IT as to defined roles and expectations. This should be formalized
in the procedures that address alarm management This information is a valuable input to
Operations for their development of the overall incident management work process that should
also include response to cyber incidents.
1920
This coordination can be organized in different ways. For example:
1921
1922
1923
1924
1925
•
1926
1927
1928
1929
Responding to alarms and incident handling requires specific skills , so it is important to make
certain that issues are escalated to the appropriate skill levels. It is important to coordinate security
incidents between different security organizations such as IT and OT s pecific incident response
organizations .
1930
9.4.4.2 Alarm performance
1931
1932
1933
1934
1935
1936
The number of alarm activations should not be too high as the cost of both too many security
alarms and false positive security alarms is high and lowers the effectiveness of this layer of
protection. As such, cyber alarms should be included in the alarm rationalization work process.
The alarm rationalization process should address cyber alarms irrespective of who is responsible
for initial response. This will require coordination between OT and IT where it is likely that a
combination of both joint and separate workshops may be warranted.
1937
9.4.4.3 Cyber security alarm handling
1938
1939
1940
1941
1942
1943
1944
1945
Every alarm should have a documented response. Given that the cause of the alarm may not be
known, there is often a need to troubleshoot, so the procedure should ensure that the correct
personnel are engaged and that others who may be adversely affected are notified. It is important
to differentiate between equipment failures, software failures and potential security events.
Therefore, it is important that the response procedures have guidance on how to triage and
respond to a cyber security alarm. This workflow can be either a document or can be automated,
e.g., a playbook used by Security Orchestration, Automation and Response technolo gy. When
automated, the basis for the required response should be documented .
•
•
A dedicated security incident response organization such as a security operations center
(SOC) can receive both the security alarms and alerts and follow -up.
The process operator can receive the cyber security alarms and escalate these to the
maintenance department to distinguish cause and organize further escalation.
Engineers on call can receive the security alarm allowing them to investigate and handle.
ISA-TR84.00.09-2023
- 86 -
1946
1947
1948
1949
1950
In general, cyber security alarm management benefits from having a centralized function that
reports the alarms and prioritizes them. An example of such a centralized solution ca n be a SIEM
system. SIEM’s can correlate alarms and generate new alerts or alarms based upon this
prioritization, SIEM’s can also automatically distribute the alarms and alerts to the right
organization.
1951
When cyber security alarm systems are designed, the following principles should be considered:
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
•
1978
For additional guidance regarding management of alarm systems, reference ANSI/ISA 18.2.
1979
9.4.5
1980
1981
1982
1983
1984
1985
1986
1987
Test procedures should be developed for the FAT, SAT, and the initial validation of the IACS and
associated networks. The test procedures should support the cyber portions of the factory
acceptance test and the site acceptance test, as well as the initial validation of the cybersecurity
security measures. It is important to have the right infrastructure in place to test the configuration
prior to implementation in the production environment. The procedures for FAT and SAT should
require that the vendor ensures the system is ready for test. This work should be conducted as
part of the PSCAI verification and validation. Annex J, Testing, provides more specific guidance
with respect to test procedures.
1988
1989
1990
1991
1992
1993
In addition, it should be determined which system will undergo a FAT. The decision to perform a
FAT is a function of cost which in turn is a function of the complexity of the system. The more
complex, the more costly it is to deal with issues that crop up in the field as well as having a
deleterious impact on schedule. Therefore, a FAT is generally recommended for complex s ystems.
For relatively simple systems, it is possible that the cost / benefit is such that the FAT is excluded
from the scope and the testing deferred until the SAT.
1994
1995
1996
The FAT can be considered a subset of the SAT where more of the system is available to te st. The
SAT is generally the test that allows turnover from the integration service provider to the asset
owner. As an input to the pre-startup safety review, there should be an initial validation of the
•
•
•
•
•
•
•
•
Every cyber security alarm should require a timely response, and that response should be a
necessary response otherwise the event doesn’t qualify as an alarm and should be
considered an alert. Such response should consider the impact on the production process
continuity and safety.
Every cyber security alarm activation should occur in a time that permits the organization to
successfully remedy the situation. If there is no immediate remedy, the process impact
should be considered.
A cyber security alarm should provide adequate information to allow an appropriate
response. The response process should be clear and well defined, including potential
escalations into the internal and external organizations.
Alarm only significant things. The number of cyber security alarms should be limited . As part
of the alarm rationalization exercise, it is important to consider which alarms are the primary
indicator of a cybersecurity condition and which indicators are secondary result s of the first
alarm. Prioritizing alarms can reduce the alarm load during a cyber -attack.
Cyber security alarms should be time-tagged so they can be ordered in the sequence of
occurrence.
There should be an alarm acknowledgement process that indicates that an alarm was
responded to.
Consider differentiation between:
o Primary action - explicitly acting to prevent a cyber breach to occur or reduce the impact
of such a breach.
o Secondary action - escalate the event or schedule follow-up action.
Design for human and organizational limitations.
Consider special plant states such as alarms during normal operations and during
shutdowns. Different activities can take place reflecting in different security alarms requiring
an adapted response.
Testing and Monitoring Procedures
ISA-TR84.00.09-2023
- 87 -
1997
1998
1999
2000
2001
2002
2003
system performed by a service provider who will be r esponsible once it is in operation. This test
should include not only confirmation of technical requirement capabilities, but also the support
procedures necessary for sustainable effectiveness of the technical security measures. When
writing these procedures, it is useful to understand that a sub-set of the initial validation will form
the foundation for future periodic revalidations. In addition, the various checks on the
organizational procedures forms an important input to on-going asset owner auditing by operations
after the plant is operational.
2004
2005
2006
2007
When automated monitoring systems (e.g., intrusion monitoring, etc.) are included in the scope,
procedures need to be developed as to their operation, maintenance, reporting, and response
requirements to alarms, as well as how to handle alerts. Additional guidance is found in the alarm
management section of this chapter.
2008
2009
2010
To support operations, it is important to monito r the IACS network and devices that includes how
to handle cyber alerts and alarms. Devices and Services that should be considered for monitoring
include:
2011
2012
2013
2014
2015
•
Firewall
o Up/down ping monitor – 1 month history
o CPU Utilization
o Watch/protect mode
o Firewall policy violations (e.g., protocol commands crossing zones)
2016
2017
•
Switches
o Up/down ping monitor – 1 month history
2018
2019
2020
2021
2022
•
Servers (physical and virtual)
o Disk Utilization – OS partition, 1 month history, weekly alerting suggested
o Up/down ping monitor for default network interface card – 1 month history
o Remote up/down monitor
o Hardware faults (power supply and hard driv e) – general – alerting suggested
2023
2024
2025
2026
2027
2028
•
Workstations (Engineering and Operator HMI)
o Disk Utilization – OS partition, 1 month history, weekly alerting suggested
o Up/down ping monitor for default network interface card – 1 month history
o Time controlled Remote access
o Least privilege and role-based access control activity
o System event logs
2029
2030
2031
2032
2033
2034
•
Local field HMI
o Sessions and user events
o Device logs
o Firmware changes
o OS changes
o Settings, config changes
2035
2036
2037
2038
2039
2040
•
Controllers (BPCS, SIS, etc.)
o Changes to firmware
o Changes to controller state
o Changes to controller logic
o Changes to controller settings
o Controller logs (e.g., syslog etc.)
2041
•
Network-attached Storage
ISA-TR84.00.09-2023
o
o
2042
2043
- 88 -
Hardware faults– general – alerting recommended
backup storage only – Disk utilization, 1 month history, weekly alerting suggested
2044
2045
•
Services Monitored
o Backups – less than x number success in y days – alerting suggested
2046
•
Network Events or incidents detected
2047
2048
o
Port to Port Traffic Over Threshold (Bandwidth Over Threshold) – transmit/receive
communications exceeds the threshold set for any network segment (device port to device port).
2049
o
Disconnects – communications is lost with an exisiting device on the network
2050
o
Detect Duplicate IP addresses – a new device is added using an exisitng IP address.
2051
o
Ping Time Over Threshold – indicates device is becoming overloaded
2052
2053
o
Detect Device Moves – detects movement of a device within a protected network including
unintended moves.
2054
2055
o
Link Speed Changes - indicator of poor signal quality or issues in the port setting between a device
and the switch
2056
Security-related monitoring metrics should be considered, e.g.,
2057
•
Number of times an unqualified person has attempted to access the protected network.
2058
2059
•
Number of times a non-approved communication has attempted to access the protected
network.
2060
•
IP Changes - tool sees that a device and its MAC address is associated with a new IP address.
2061
•
MAC Changes – new MAC address is seen at a known IP address
2062
2063
•
New Device Added – assures new devices are reviewed and approved. Detects rogue devices even if
connected for a brief period of time.
2064
2065
2066
Procedures for the collection, reporting and handling of key performance indicators (KPI) should
be developed for all KPIs included in the scope by Operation’s Management or the Business Area.
Annex L, Cybersecurity KPIs and Metrics provides examples of potential KPIs.
2067
9.4.6
2068
2069
2070
2071
2072
2073
2074
A maintenance philosophy should be defined prior to defining a maintenance plan. A maintenance plan
should be developed to define the work that needs to be done to proactively maintain assets including –
but not limited to – emergency, routine, and preventative maintenance philosophies, detailing the
resources needed (who, what and when). For instance, the maintenance plan should include a calibration
philosophy and calibration schedule including each piece of approved test equipment. The contents of the
maintenance plan help facilitate the continued use of an asset at optimum performance. It is important
to work with the operations and maintenance organizations during the development.
2075
2076
2077
2078
Since many technologies are new and small organizations might have limited resources and will depend
on the service providers/OEMs, confidentiality and NDAs should be in place. Moreover, calibration
schedule would be dependent on the proof test requirements for relevant instruments/control valves. For
technical security measures, maintenance manuals from OEMs should be referred.
2079
2080
2081
2082
2083
2084
Every activity in the plan should have its associated maintenance procedure. The maintenance procedure
should contain a detailed list of steps that describes how to perform the task, also
including recommended spare parts, modules, sub-assemblies, maintenance tools and test equipment,
maintenance manuals, and troubleshooting techniques. Maintenance benches, system simulators and
emergency spares storage should be defined. Tools and test equipment appropriate for multiple types of
installations should be defined.
2085
2086
2087
Appropriate portable tools for each technician and network technician with software that is approved and
secure for diagnostics and adjustment of the systems and associated equipment should be provided.
Requirements for how this equipment is to be managed to ensure security should be defined.
Maintenance Procedures
ISA-TR84.00.09-2023
- 89 -
2088
9.4.7
2089
2090
2091
2092
Cyber incident detection and response should be addressed within the operating facility’s
emergency response and business continuity procedures and plans. The cybersecurity aspects
should include assigning roles and responsibilities as applicable and how those roles interact with
an overall cross functional team that would typically include :
•
•
•
•
•
•
2093
2094
2095
2096
2097
2098
Emergency Response / Business Continuity Procedures
Operations
Process Controls and Technology
Corporate IT
Human Resources
Legal
Public Affairs
2099
2100
2101
2102
Site Cyber Incident Response and Recovery Plans sh ould be reviewed and approved by:
• Plant Manager
• Site Security Lead
• Corporate IT
2103
2104
2105
A cyber incident response and recovery plan should document the expected responses to a
detected cyber incident. The risk assessment should be used to help predefine appropriate
responses to cyber-attacks based upon the assets potentially compromised.
2106
2107
As part of recovery, identification, and elimination of the root cause of the infection should be
addressed.
2108
2109
Business continuity measures should have a full system backup and recovery management
program so that business operations can continue.
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
Employees should be trained to report anomalous security behaviors. The following topics should be
included in employee training to improve their overall awareness and the work process to report
potential cyber activities and/or intrusions based upon their roles:
•
Unusually slow Internet or devices
•
Locked out accounts
•
Unexpected software installs
•
Unexplained changes to files
•
Anomalies in normal network traffic patterns
•
Abnormal outbound traffic
•
Irregular access locations
•
Large number of requests for the same objects or file s
•
Suspicious activity on the network after-hours
•
Multiple failed login attempts
•
Unknown/unauthorized IP addresses on wireless networks
•
Unexplained system reboots or shutdowns
•
Services and applications configured to launch automatically
2126
2127
Personnel should be instructed to report any of the above conditions. Successful engagement of
personnel can dramatically increase the ability to detect a data breach in the early stages.
2128
9.5
Security Protection Rating (SPR) Verification
2129
9.5.1
SPR Overview
2130
2131
2132
2133
2134
2135
At this point in the process, the product supplier, architecture, version, and all specifics are
chosen. The goal is to finalize all aspects of the cybersecurity solution so that the next phases
may be conducted as efficiently as possible with minimal re-work. This includes the detailed design,
the metrics, the work process and production impacts to operations, and the long-term
sustainability plan of the system. All should work together to meet the intended level of
performance and draft the necessary documents for the sustainment of the system.
ISA-TR84.00.09-2023
- 90 -
2136
2137
2138
2139
2140
2141
Security Protection Ratings are a function of security level (SL) technical requirem ents and the
current maturity level of the implemented policies and practices needed to make the technical
requirements effective on a sustained basis. SPRs can be estimated for zones as each zone may
have different security level targets and requirements. SPRs are part of an overall protection
scheme that falls under the umbrella of the OT cybersecurity management system. Additional
guidance may be found in ISA 62443-2-2 which is under development.
2142
9.5.2
2143
Inputs include:
SPR Inputs
2144
2145
2146
2147
2148
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
•
2160
9.5.3
2161
2162
2163
2164
2165
2166
2167
Annex I, Security Protection Rating Verification, provides a method(s) for determination of zone
security Protection ratings. Outputs include an estimated SPR for each zone. Prior to initial startup
it would be considered the SPR implemented (SPR -I). It should be noted that at this stage, the
maturity level associated with each zone may only be an assumption. The strength of that
assumption depends upon whether the design is for a completely new Greenfield site or is a capital
project within an existing operating site. Actual maturity levels can onl y be determined following
experience gained and measured in actual operation and maintenance.
2168
2169
Following some period of actual operation, the maturity level should be able to be measured more
accurately resulting in an updated security protection rating dur ing operation (SPR-O)
2170
9.6
2171
2172
Included in this section are typical outputs that result from engineering to enable implementation
and subsequent operation / maintenance:
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186
The following information including any revisions to input documents:
• From Input List:
o Regulatory requirements
o Adopted industry standards
o Corporate policies and procedures
o SuC Description
o Controls Philosophy
o Cybersecurity implementation strategy / plan
o Reliability requirements
o Availability requirements
o SuC asset inventory (hardware and software)
o Process Safety Information
o P&ID’s
o Approved vendor list
•
•
Applicable technical requirements associated with each zone in accordance with ISA
62443-3-3. This information can be documented as a vulnerability or a capability
assessment depending upon one’s perspective. See Annex C, Vulnerability Identification
Methodologies, System technical capability gap analysis methodology.
Compensating technical requirements where the SL-C in accordance with ISA 62443-3-3
is deficient for the zone SL-T. See Annex E, Defense in depth/Security Measures,
supported by typical security measures, for additional potential security measures as a
function of IACS attack phases.
o Compensating measures may also include other means to reduce cyber caused
risk, e.g.
▪ safety controls not vulnerable to cyberattack.
▪ hard wired (nonprogrammable) interlock systems.
▪ pressure relief valves.
▪ check valves.
Maturity level of procedures necessary to support technical and compensating technical
security measures. See Annex A, Maturity Level Assessment for guidance.
SPR Verification and Outputs
Design Documentation (Outputs/Deliverables)
ISA-TR84.00.09-2023
- 91 -
o
o
o
o
o
o
o
o
o
o
2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
2199
2200
2201
2202
2203
2204
2205
2206
2207
2208
2209
2210
2211
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
2223
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Manufacturer security manuals
Finalized control system and OT network architectural drawings
Finalized Zone & Conduit Drawings
SIFs and safeguards assigned to layers of protection
HAZOP and / or CHAZOP worksheets / report
LOPA worksheets / report
Data flow requirements and rationale
Vulnerability assessment(s)
Initial cyber risk assessment report and recommendation closeo ut documentation
Detailed level cyber risk assessment report and recommendation closeout
documentation
o Risk register
o Revised Safety Requirements Specification (SRS)
o Updated Cybersecurity Requirements Specification (CRS)
o Access requirements based on least privilege (3 rd party service providers and
contractors as well as employees)
Control platform specification
Network device specifications for use in levels 0 through the DMZ
Configuration documentation
Wireless access control documentation
Instrument & Valve Specifications
Hardware system layout drawings
Device/equipment location plan drawing(s) for those requiring physical access controls
Conduit and tray layout for safety or security sensitive devices/equipment
C&E matrix drawing(s)
SPR-C verification report
SIL verification report
Maintenance philosophy
Mechanical integrity program procedures (including maintenance of security measures)
FAT/ SAT specification and procedures (including cybersecurity)
FAT Integration Procedures (including cybersecurity)
Site Integration Test Procedures (including cybersecurity)
Commissioning procedures (including cybersecurity)
Pre-validation checklist and validation procedures (including cybersecurity)
Emergency procedures (including security events and incidents)
Project Design Change Tracking documentation
Stage 2 assessment/audit findings
2224
10
2225
10.1.1 Purpose
2226
2227
2228
2229
The intent of the stage 2 project assessment is to ensure that the detailed design engineering is
complete and consistent with the conceptual design prior to issuing contracts for construction. This
helps to manage costs by reducing the chance of future rework/scope changes during detailed
construction & integration of equipment.
2230
10.1.2 Input and Guidance
2231
2232
2233
2234
Performance of a stage 2 cybersecurity assessment should occur following completion of detailed
design and prior to issuance of construction contracts by independent and competent personnel.
These persons should have both the knowledge and experience to judge both the completion of
expected work and when applicable, the quality of such work.
2235
The input for the stage 2 project assessment is
2236
Stage 2 Detailed Design Assessment
•
The current approved safety and cybersecurity requirements specification
ISA-TR84.00.09-2023
- 92 -
2237
•
Safety Requirements Specification
2238
•
Cybersecurity Requirements Specification
2239
•
Process Safety Information
2240
•
PFD‘s
2241
•
P&ID’s
2242
•
Hazard review report and worksheets (e.g. , HAZOP, LOPA, etc.)
2243
•
Recommendation closeout documentation
2244
•
SIFs and safeguards assigned to layers of protection
2245
•
Asset inventory
2246
•
System diagrams
2247
•
Architectural Drawings
2248
•
Zone & conduit drawings
2249
•
Data flow documentation
2250
•
Configuration standards and specifications
2251
•
Configuration documentation
2252
•
Control platform specification
2253
•
Instrument & Valve Specifications
2254
•
Network device specifications for use in levels 0 through the DMZ
2255
•
Hardware system layout drawings
2256
•
Manufacturer security manuals
2257
•
SPR-C verification report
2258
•
FAT/SAT specification and procedures
2259
•
Commissioning procedures
2260
•
Validation procedures
2261
•
Mechanical integrity program procedures
2262
•
MOC procedures
2263
•
Patch management procedures
2264
•
Vulnerability management procedures
2265
•
Training records
2266
•
Competency criteria and logs
2267
10.1.3 Output
2268
The result of stage 2 assessment is
2269
•
Either an approval to issue construction contracts OR
2270
•
A requirement to re-iterate and improve certain design aspects.
2271
2272
An example checklist template to aid in this assessment is included in Annex B, Cyber security
Assessment Stage Check List Templates .
2273
11
2274
2275
2276
2277
This stage executes the agreed upon designs while building and configuring the system in
accordance with the overall functional specifications. Focus shifts to execution, qualifications of
the Integration Service Provider, and cybersecurity management during the build and configure
phase. The goal during this phase is to build an integrated system that meets the functional
Implementation
ISA-TR84.00.09-2023
- 93 -
2278
2279
2280
2281
2282
specifications and ensuring that the system has not been compromised during this phase of work
(such as insertion of malware). Proper handling of the equipment and adherence to cybersecurity
principles during the integration process are essential. The integration team should be trained and
have demonstrated competence to carry out work on the system. The training and demonstra ted
competence should be at least equal to the design security level of the system being integrated.
2283
2284
2285
2286
2287
2288
2289
This phase of the lifecycle enables and provides the information necessary for the pre -startup
safety review (PSSR) that checks to make sure the system is ready and capable of performing as
it was defined and that all the recommendations made during the detailed level cyber risk
assessment have been appropriately addressed. Ensuring that the cybersecurity measures are in
place and have been tested and ready to go is part of the overall PSSR. The cybersecurity
contribution to the PSSR would be considered part the stage 3 asse ssment required by ISA 61511
and is covered in chapter 12.
2290
2291
This phase has several activities that are encompassed within the expanded System
Implementation (buy/build/configure) work process shown in figure 11.1 below.
Contract Execution
Training / Competence
System Integration - Construction
Factory Acceptance Test (FAT)
Installation and Commissioning
Site Acceptance Test (SAT)
Initial Validation of
Countermeasures
2292
Figure 11.1 - Expanded System Implementation (buy/build/configure) Work Process
2293
2294
11.1
2295
2296
In general, inputs for implementation are the output deliverables from design. However, there may
be some additional inputs, e.g.
2297
2298
•
•
Inputs
Contracts
Newly discovered vulnerabilities
2299
11.2
Roles / Training / Competence
2300
Many of the roles listed in the design chapter 9 continue as part of implementation. These include:
ISA-TR84.00.09-2023
2301
2302
2303
2304
2305
2306
2307
2308
2309
2310
2311
2312
•
•
•
•
•
•
•
•
•
•
•
•
Plant Manager
Project Manager
SIS System Engineer
SIS Instrument Engineer
Project SIS Team Member
BPCS Engineer
BPCS Team Engineer
OT cybersecurity vendor specialist
Industrial cybersecurity engineer
Construction
Auditor
Assessor
- 94 -
ISA-TR84.00.09-2023
2313
2314
- 95 -
Details about those roles can be found in chapter 9, Table 9.1. Table 11.1 below shows the additional roles that are required in the
installation phase of a project.
Additional Roles
Instrument Technician
Description
Competent and qualified person
installing and connecting the SIS
hardware and cabling. (Can be 3 rd
party)
Competency
Demonstrated knowledge of ISA/IEC 61511-1 Ed2 and
ISA/IEC 62443, especially 2-1, 2-4, and 4-2,
Awareness training with the integrated safety/security
lifecycle and understands their personal role and
responsibility,
Demonstrated experience in and trained for the specific
installation methods that are used in the IACS design.
Competent and qualified person
testing the hardware and cabling.
(Can be 3 rd party)
Test Engineer
Demonstrated knowledge of ISA/IEC 61511-1 Ed2 and ISA/
IEC 62443, especially 2-1, 2-4 and 3-3,
Awareness training with the integrated safety/security
lifecycle and understands their personal role and
responsibility,
Demonstrated knowledge and experience of test methods.
Commissioning Engineer
Competent and qualified person
commissioning the IACS.
Demonstrated knowledge of ISA/IEC 61511-1 Ed2 and
ISA/IEC 62443, especially 2-1, 2-4 and 3-3,
Awareness training with the integrated safety/security
lifecycle and understands their personal role and
responsibility,
Demonstrated knowledge and experience in commissioning
skills.
Field inspector
Competent and qualified person
supervising the installation, testing,
and commissioning of the IACS
hardware and cabling. (Can be 3 rd
party)
Demonstrated knowledge of ISA/IEC 61511-1 Ed2 and
ISA/IEC 62443 as applicable,
Awareness training with the integrated safety/security and
cybersecurity lifecycle and understands their personal role
and responsibility,
Experienced in or trained for the specific installation methods
that are used in the IACS solution.
2315
2316
Table 11.1
Cyber Training/Competence as a Function of Additional Generic Design Implementation Related Roles
ISA-TR84.00.09-2023
- 96 -
2317
11.3
Contract Execution
2318
2319
2320
2321
2322
2323
During implementation, the procedures developed during detailed design should be followed by the
engineering and integration service providers. The asset owner should coordinate with these Service
Providers to ensure that the equipment is installed in a manner that satisfies contract requirements. In
addition, the contract for inter-system and inter-site Control/Automation/Safety/Cybersecurity interfaces
should require compatibility and full functionality of systems per the design specifications and the
cybersecurity requirements specification.
2324
11.3.1 Implementation Responsibilities
2325
The following table 11.2 illustrates a typical RACI chart for implementation activities.
2326
2327
Table 11.2
Implementation Roles and Responsibilities
Implementation
Activities
Asset
Owner
Engineering
Service
Provider(s)
System
Integration
Service Provider
Maintenance
Service
Provider
Construction
A
C
R
C
Installation
A
C
R
C
FAT
A
C
R
I
SAT
A
C
R
I
Initial validation
A
C
C
R
Legend
R: Responsible – Party provides engineering and resources to produce deliverable
A: Approve – Party reviews and approves prior to issue of deliverable
C: Consult – Party collaborates in development or has mandatory review prior to issue
I: Inform – Provide information to party at time of approval
2328
11.3.2 Maintenance Activities
2329
2330
During implementation, there may be a need for various maintenance activities. These typical activities
may include:
2331
2332
•
Patching - Keep hardware and software up to date as there is a time lag that can range from
months to years between FAT, Commissioning and Plant Start up.
2333
•
Equipment repair needed resulting from diagnostics or testing.
2334
2335
2336
2337
•
Recording the temperature and humidity of Control systems, SIS, and I/O at site after delivery
from FAT site, until Startup and Turnover. Manufacturer’s requirements for Temperature and
humidity to be supported. This includes site locations of cabinets, workstations, servers, HMI
panels etc.
2338
2339
•
Workstation hardening - The workstation should meet the security policies for the plant where it is
installed. There may be some differences from the FAT location security policies.
2340
2341
•
User-account management- This will be different from the FAT location, as users on site
for implementation, and commissioning will be different and from multiple organizations.
2342
2343
2344
2345
2346
•
Maintain unique user account and password change rules in accordance with the asset owner’s
plant location policies and procedures during the implementation and commissioning phases.
User accounts and password-change routines should be established for the
implementation, commissioning, acceptance, startup, and turnover phases as they have a
very diverse set of short-term users from multiple organizations.
2347
2348
•
Data management: “Period between site implementation and Startup” - Develop guidelines
for secure implementation of site test data, transmission, storage, and destruction. The trial runs
ISA-TR84.00.09-2023
2349
2350
- 97 -
and test data may be destroyed after a set time, however, acceptance tests such as Site
Commissioning Test and SAT data should be preserved for the life of the plant.
2351
•
Configuration / Application program backups
2352
•
License renewals as applicable
2353
•
Maintenance of change logs
2354
•
Management of change
2355
•
Incident log maintenance
2356
11.3.3 Testing
2357
2358
2359
The Integration Service Provider(s) should execute the various contract specified tests in accordance with
the procedures developed and included during detailed design. Additional guidance is documented in
subsequent sections of the Implementation chapter.
2360
2361
2362
2363
A Site Acceptance Test (SAT) should be performed for e ach system to ensure the complete
functionality of the system(s) per the asset owner requirements. Upon satisfactory completion of
the SAT, the system should be handed over to the asset owner for operational use, and the
warranty period on the equipment should begin.
2364
11.3.4 Training
2365
2366
2367
2368
Training of appropriate personnel who will be responsible for the operation, maintenance and
support of the system should be performed according to the Contract. Testing to determine proof
of knowledge is recommended. Lack of cognizance in these areas may introduce significant risk into
2369
2370
2371
The training should provide all materials and training aids. The training is recommended to assume
a train-the-trainer approach, where videos are tak en of the class lectures that can later be used to
train future students on these systems.
2372
2373
At the completion, all training material, (e.g., videos, training aids, presentation materials, etc.)
should become the property of the asset owner.
2374
11.4
2375
2376
2377
2378
Planning is an essential first step for ultimate implementation of equipment involving control
platforms, package equipment as well as the systems they connect to. The work process can
involve factory acceptance tests (FAT), field construction, commissioning, site acceptance tests
(SAT), and initial validation.
2379
2380
2381
2382
2383
Initial planning should begin once the scope is defined. The results of final planning should be
documented as part of the contracts with various service providers, (e.g., construction ,
commissioning, integration, etc.) resulting from any negotiations between the asset owner and the
service providers. The documented plan/contract should address the following as applicable to the
specific work being performed:
2384
2385
2386
2387
2388
2389
2390
2391
2392
2393
a system design and should be specifically defined.
•
•
•
•
•
•
•
•
•
System Integration – Planning
Encompass all applicable asset owner specifications, standards, and drawings
Agreed upon scope should define the work to be performed
Deliverables
Acceptability criteria
Schedule milestones
Specialized test equipment or special tools and who is expected to provide them
Methods to gather test results, i.e., data logging systems or manually recorded
The plan to gather, analyze, and report on the test results and who is responsible for the
various activities
Safety and security program requirements to be followed during the work proce ss
ISA-TR84.00.09-2023
2394
2395
•
- 98 -
Stakeholder communication requirements during the work process, including points of
contact identified as responsible for the process
2396
11.5
Construction
2397
2398
There will typically be offsite as well as onsite construction. Offsite construction is performed by
system integrators as well as packaged equipment suppliers.
2399
2400
2401
2402
2403
Offsite construction should be performed in a manner that ensures both safety and security of the
system to be delivered. Once offsite construction is completed, there may be a requirement to
perform a factory acceptance test (FAT) witnessed by the asset owner. Typically, the service
provider will have their own quality assurance practices in plac e to help ensure that the FAT can
be performed in an efficient manner.
2404
2405
More guidance for the FAT is provided in the next subsection and onsite construction is covered
under installation and commissioning following the FAT subsection.
2406
11.6
2407
2408
2409
Performance of a FAT is a step that helps verify that newly manufactured and packaged equipment
satisfies its intended purpose. During the FAT the operation of the equipment is validated to ensure
that the asset owner’s contractual specifications and requirements are met.
2410
2411
2412
A FAT is performed to help address any functional issues before the equipment arrives at the asset
owner’s site. This helps to reduce costs and maintain schedules as issues identified at the site can
be more difficult to resolve.
2413
2414
2415
2416
2417
The execution of a security measure test plan should take place during factory acceptance test or
another suitable offline laboratory environment. A realistic simulation of the enterprise environment
should be considered as well as all the actual component versions / applications under test. This
test can be after the traditional FAT, but it should be conducted prior to shipment to the site. This
is done to allow time to resolve any issues prior to commissioning and startup.
2418
2419
2420
The FAT confirms that cybersecurity security measures have been properly set-up and configured
in accordance with the CRS and all other agreed documents. Testing should also confirm there
was no shipping damage to the components prior to installation .
2421
2422
2423
2424
2425
As new cybersecurity threats are always present, and considerable time may have passed since
the purchase of the equipment, a review of technical currency should be done (i.e., IACS alerts,
product supplier patches, etc.). The system’s security measures should be current to all known
threats at the time of the FAT. If it is not possible to take the latest updates, a written understanding
between all parties should occur.
2426
2427
2428
Inputs to this work are the inspection and test procedures and security measures detailed in design
documents. The CRS and all other documentation related to security measure identification or
design should be available for reference as the tests are conducted.
2429
2430
Performance of a successful FAT involves planning, applicable engineering documentation, and
testing.
2431
2432
2433
2434
Planning can begin as early as when the initial scope is provided to the integration service provider
during the bid process. The documented plan should encompass all applicable asset owner
specifications, standards, and drawings. The agreed upon scope of the FAT defines acceptability
criteria for the equipment being supplied.
2435
2436
2437
A complete set of reference documents should be compiled and sent to the integration service provider
prior to the actual FAT testing. This information is essential for the integration service provider to ready
the system for inspection and testing. These documents will include, but not be limited to:
Factory Acceptance Test (FAT)
2438
•
Scope and applicable asset owner cybersecurity requirement specifications
2439
•
Applicable manufacturer security manuals
2440
•
Drawings (e.g., architecture, configuration requirements, etc.)
ISA-TR84.00.09-2023
- 99 -
2441
•
Data Sheets
2442
•
Inspection and Test Plans
2443
•
Applicable Codes / References
2444
•
Checklists and Procedures specific to the FAT
2445
2446
Certificates should be implemented during the FAT by loading them locally. Once implemented,
they should be part of a management system that addresses their expiration and resetting.
2447
2448
Any instrumentation used to record data during the test should be verified to be secure and within the
calibration date as required by manufacturer or asset owner specifications, prior to the test.
2449
Testing during the FAT should accomplish the following:
2450
2451
1. Follow and reference the inspection and testing plan as well as the detailed test
procedures that have been developed
2452
2. Measure and record raw data
2453
3. Submit data to the asset owner
2454
2455
4. Review any revisions to drawings, procedures or other engineering documentation with
the asset owner or their representative.
2456
5. Perform any job-specific requirements as referenced in the asset owner specifications
2457
2458
2459
Test outputs should include a signed (pass / fail) response and any notes and observations for the
purpose of revising and improving the overall cybersecurity solution and work process. Guidance
for Inspection and testing to consider during the FAT are included in Annex J, Testing.
2460
2461
2462
2463
2464
2465
There may be a need to “turn off” some cybersecurity security measures during certain portions of
the buy / build / configure / install phase. It should be acknowledged that some cybersecurity
security measures may not be active in this phase or are not available while performing certain
tasks. Some examples include account setup, times when disconnected from networ k
infrastructure, etc. During these times, special care (alternate means of risk reduction) should be
taken.
2466
11.7
2467
2468
2469
2470
While systems are being manufactured and integrated offsite, onsite construction of either facilities
to accommodate the systems or package equipment or installation of additional equipment directly
onsite, e.g., field sensors, final elements, etc. will also be occurring. The overall planning should
account for the coordination of all these activities.
2471
2472
2473
Following the FAT, the IACS or packaged system is delivered, allowing installation and integration
with onsite equipment that has previously been installed as part of construction. Once equipment
has been installed, commissioning can begin.
2474
11.7.1 Construction / Installation
2475
2476
2477
2478
2479
2480
2481
2482
2483
Mechanical completion occurs at the end of construction once equipment is installed. The contract should
define the handover process. This may be formal, requiring forms to be signed confirming that equipment
is installed per the design. Inspection plans should be available for quality assurance of the installation
and should be agreed and witnessed by the asset owner. The construction team and commissioning
team should inspect the installation and perform a walkthrough to ensure that appropriate quality of
workmanship has been maintained and confirm there are no deficiencies. Any deficiencies should be
noted and added to a deficiency list that classifies the level of importance and urgency of correcting the
deficiency. Oftentimes the classification states mandatory before some milestone or is defined as punch
list item allowing more time to complete.
2484
2485
2486
Any changes identified relative to the design drawings or specifications should be reviewed and
either modified to reflect the drawings or redlined if the chang e management process approves
the identified changes. The construction team should deliver an accurate set of red -line drawings
Installation and Commissioning
ISA-TR84.00.09-2023
- 100 -
2487
2488
to the commissioning team so that the installed configuration of equipment in the field is accurately
documented.
2489
11.7.2 Commissioning
2490
2491
2492
2493
2494
Site Commissioning checks should be performed to verify that the site installation is ready prior to
integration with the relevant overall systems. Commissioning should begin after the Integration
Service Provider has successfully achieved Mechanical and Electrical Completion, including pre commissioning. This allows a burn-in time for the equipment and ensures that the levels and
connections have been correctly implemented.
2495
2496
2497
2498
2499
2500
2501
2502
2503
The commissioning team should be defined during the design/construct ion phase, identifying core
members of the commissioning team as well as support resources needed. At this stage it is
important to involve the asset owner’s operations team to be part of the work process to ensure
safety and security within the work processes. In addition, this allows operations personnel an
opportunity to become familiar with the new operating requirements prior to taking over the
systems. Other typical members of the commissioning team may include as applicable the
electrical / mechanical / automation key discipline leads, Industrial cybersecurity engineering lead,
consultant subject matter experts (SME), contract service providers, integration service provider
representatives, and manufacturer representatives.
2504
2505
2506
Commissioning documentation should be defined and prepared in advance of the commissioning
phase. This includes the inspection and test plans, including checklists, test procedures to be
used during commissioning, as well as applicable drawings provided by the construction team.
2507
2508
Pre-commissioning is the first step within commissioning. It can begin once mechanical and
electrical completion has occurred and any deficiencies are agreed upon.
2509
Pre-commissioning activities include:
•
•
•
2510
2511
2512
2513
2514
2515
2516
2517
2518
2519
2520
2521
2522
•
•
•
•
Cleaning and flushing of pipes, pressure testing, and leak testing
Bump testing rotating equipment which verifies current draw, pressure, and flow rates
Initial run-in period of motors and pumps to verify vibration and heating/cooling and to
minimize the potential for infant mortality issues later in actual o peration
Panel energization, communication checks, network communication checks, loop checks
(internal and external), and verification of any wiring to the central control room if required.
Detailed electrical checks of network, control, and protection circuits to confirm that any
minor updates since FAT are uploaded to the equipment, and that the correct settings are
applied.
Current injections on any current transformers to verify correct polarity and calibration
prior to applying primary power to major equipment.
Pre-commissioning checklists are completed for each piece of equip ment and possibly
witnessed by service provider subject matter expert to verify tasks have been completed.
2523
2524
2525
Any new deficiencies identified should be added to the open deficiency list containing those that
remain from prior FATs or from the mechanical and electrical completion activity. As before, the
level of importance and urgency of correcting the deficiency should be documented.
2526
2527
2528
Commissioning begins once pre-commissioning has fulfilled its requirements. The pre commissioning checklist is generally the handoff deliverable. During commissioning typical
activities include:
2529
2530
2531
2532
2533
2534
2535
2536
•
•
•
•
•
•
Verification that equipment has not been damaged during shipping to the site.
Confirmation that field device wiring is correct.
Performance of a subset of FAT tests repeated to ensure the equipment can communicate
to all field devices, including wireless if applicable.
Key certificates are up to date and not revoked
Equipment calibration.
Mechanical dry commissioning to confirm proper function of mechanical systems without
process fluids.
ISA-TR84.00.09-2023
2537
2538
2539
2540
2541
2542
2543
2544
2545
2546
2547
2548
2549
2550
2551
2552
•
•
•
•
•
•
•
•
•
•
•
- 101 -
Mechanical wet commissioning to confirm proper function of mechanical systems with
process fluids.
Pre-energization safety checks for electrical equipment.
Following confirmation of isolation, equipment racks may be powered up and system
integration can occur.
Field devices are verified to be correctly reflected on HMI screens
Control of capability from the central control or other applicable location verified.
End-to-end communications are verified as accurate and reliable.
Bring auxiliary systems online followed by major apparatus
o Note that when equipment is first energized as a system, it may be that construction
is still taking place next to equipment currently under test, and it should be ensured
that power is safely isolated from any equipment ins tallations.
Verification of interfaces for all equipment.
Completion of commissioning checklists witnessed by service provider SMEs.
Update deficiency list with any newly discovered deficiencies
Provisioning
2553
2554
2555
2556
Provisioning is the process of setting up IT and/or an OT infrastructure. This includes the steps required
to manage access to data and resources and make them available to users and systems. Provisioning is
not the same thing as configuration, but they are both steps in the deployment process. Once something
has been provisioned, the next step is configuration.
2557
2558
There are several different types of provisioning, e.g., server provisioning, user provisioning,
network provisioning, and service provisioning, w hich are described in additional detail below:
2559
2560
2561
2562
2563
2564
•
Server provisioning - The process of setting up a server (including virtual) to be used in a
network based on required resources. This can encompass all the operations needed to
create a new machine and bring it to a working state and includes the definition of the
desired state of the system. Server provisioning includes setting up the physical hardware,
installing and configuring software, including the operating system (OS) and applications,
and connecting it to middleware, networks, and storage.
2565
2566
2567
2568
2569
2570
2571
2572
2573
2574
2575
2576
•
User provisioning – This is a type of identity management that monitors access rights and
authorization privileges to help ensure least privilege. This type of provisioning is defined
through users, such as employees, suppliers, contractors, machines, etc. and specific user
attributes. Services provided might include access to an engineering workstation, field
devices, controllers, other process equipment, servers, or access to a network. User or
account provisioning technology creates, modifies, disables, and deletes user accounts
and their profiles across IT and / or OT infrastructure and applicable applications.
Configuring role-based access control (RBAC) is an example of user provisioning. RBAC
is generally comprised of permissions, roles, groups, and users. A user is assigned to a
group or groups, a group is assigned to roles (e.g., read -only, editor, or administrator), and
a role is comprised of permissions. User provisioning is often managed between IT/OT and
human resources.
2577
2578
2579
2580
2581
2582
•
Network provisioning - Sets up a network for access by users, servers, machines, and IIoT
devices, among other things. There are many different types of items that are network
consumers. Network provisioning has frequently been used by telecommunications as a
way to refer to providing a telecommunications service to a user, including the required
equipment and wiring. It may also include service activation of a wireless environment for
a user.
2583
2584
2585
2586
•
Service provisioning - Includes the setup of a service and management of the data
associated with OT. Involves applications such as process information, power monitoring
and control, telecommunications, as well as with cloud infrastructure should it be part of
OT.
ISA-TR84.00.09-2023
- 102 -
2587
2588
Upon completion of Commissioning, the Integration Service Provider should conduct the site
acceptance testing in accordance with contract requirements.
2589
11.8
2590
2591
2592
Once all devices in the SuC have been installed at the asset owner’s site, connected, and
configured, a SAT may be performed. Verification of the cyber security measures should be
conducted, just as initial verification of the PSCAI is conducted.
2593
2594
2595
2596
Field activities should allow time to ensure that the cybersecurity security measures are
implemented, updated (if required), and ready to test. These inspections and tests are to verify
that the system conforms to the CRS as well as identification of vulnerabilities during real life
simulations that may have been missed in prior reviews .
2597
2598
2599
2600
2601
2602
Performance of a Site Acceptance Test (SAT) is a step that helps verify that newly manu factured
and packaged equipment as installed at the site satisfies its intended purpose. During the SAT the
operation of the equipment is verified to ensure that the asset owner’s contractual specifications
and requirements are met. The SAT should not only visually check, test the functionality, and
performance of the system, but should also check the accuracy, clarity, and completeness of the
documentation.
2603
2604
2605
2606
A SAT is performed to help address any functional issues prior to startup. This not only helps to
reduce costs and maintain schedules as issues identified after startup can be more difficult to
resolve and may lead to safety concerns. Performance of a successful SAT involves planning,
applicable engineering documentation, and testing.
2607
2608
2609
2610
2611
The execution of a security measure test plan should take place during site acceptance
testing. Planning can begin as early as when the initial scope is provided to the integration service
provider during the bid process. The documented plan should encompass all applicable asset
owner specifications, standards, and drawings. The agreed upon scope of the SAT defines
acceptability criteria for the equipment being installed and tested.
2612
2613
2614
2615
2616
The SAT confirms that cybersecurity security measures have been properly set -up and configured
in accordance with the CRS and all other agreed documents. In addition, the SAT should ensure
that the installation does not introduce new issues when interconnected as an entire system, e.g.,
lack of compatibility between manufacturers, organizations, un foreseen vulnerabilities, etc.
Testing should also confirm there was no shipping damage to the components prior to installation.
2617
2618
2619
2620
As new cybersecurity threats are always present, and time has passed since the FAT, a review of
technical currency should be done (i.e., IACS alerts, product supplier patches, etc.). The system’s
security measures should be current to all known threats at the time of the SAT. If it is not possible
to take the latest updates, a written understanding between all parties should occu r.
2621
2622
2623
Inputs to this work are the inspection and test procedures and security measures detailed in design
documents. The CRS and all other documentation related to security measure identification or
design should be available for reference as the tests are co nducted.
2624
2625
2626
A complete set of reference documents should be available prior to the actual SAT testing. This
information is essential for the integration service provider to ready the system for inspection and testing.
These documents will include, but not be limited to:
Site Acceptance Test (SAT)
2627
•
Scope and applicable asset owner cybersecurity requirement specifications
2628
•
Process control description
2629
•
Applicable manufacturer security manuals
2630
•
Hardware inventories
2631
•
Software inventories
2632
•
Drawings (e.g., architecture, configuration requirements, etc.)
2633
•
Data Sheets
ISA-TR84.00.09-2023
- 103 -
2634
•
Program listings
2635
•
System I/O list
2636
•
Instrument calibration certificates
2637
•
Data Exchange documentation
2638
•
Logic flow diagrams
2639
•
Termination lists
2640
•
Communication interfaces
2641
•
Startup procedures
2642
•
Inspection and Test Plans
2643
•
Open FAT items
2644
•
Recommended spares list
2645
•
Applicable Codes / References
2646
•
Checklists and Procedures specific to the SAT
2647
2648
Any instrumentation used to record data during the test should be verified to be secure and within the
calibration date as required by manufacturer or asset owner specifications, prior to the test.
2649
Testing during the SAT should accomplish the following:
2650
2651
•
Follow and reference the inspection and testing plan as well as the detailed cyber test
procedures that have been developed
2652
•
Measure and record test data
2653
•
Asset owner to record documented results
2654
2655
2656
•
Review any revisions to drawings, procedures or other engineering documentation with
the asset owner or their representative. Should ensure any applicable changes have
undergone appropriate change management
2657
•
Perform any job-specific requirements as referenced in the asset owner specifications
2658
2659
2660
Test outputs should include a signed (pass / fail) response and any notes and observati ons for the
purpose of revising and improving the overall cybersecurity solution and work process. Guidance
for Inspection and testing to consider during the SAT are included in Annex J, Testing.
2661
2662
2663
2664
2665
2666
There may be a need to “turn off” some cybersecurity securit y measures during certain portions of
the buy / build / configure / install phase. It should be acknowledged that some cybersecurity
security measures may not be active in this phase or are not available while performing certain
tasks. Some examples include account setup, times when disconnected from network
infrastructure, etc. During these times, special care (alternate means of risk reduction) should be
taken.
2667
11.9
2668
2669
2670
As an input to the stage 3 assessment, there should be an initial validation of all security measures.
This includes the technical security measures and the organizational procedures needed to ensure
their effectiveness as well as organizational procedures intended to stand on their own.
2671
2672
2673
The validation team should show the same demonstrated competency as the integration team. It
is critical for the system to remain “uncompromised” (for example, no introduction of malware),
during this pre-operational activity.
2674
2675
2676
The initial validation is a repeat of the inspection and test procedures under independent evaluation
plus any additional tests necessary to confirm the installed business enterprise connections
against the approved design.
2677
At a minimum the initial validation should include:
Initial Validation of Security Measures
ISA-TR84.00.09-2023
- 104 -
2678
2679
•
Security measures are tested and practiced with plant support personnel present. Confirm
operation per SRS and CRS.
2680
•
Access control hierarchy is setup and finalized.
2681
2682
2683
•
Support work processes and procedures necessary for the technical security measures to
be effective are finalized and implementation validated, e.g., patch management,
configuration management, MOC, access control, etc.
2684
•
Metrics collection systems are reviewed and tested in the production environment.
2685
2686
•
Any deviations or vulnerabilities identified should be discussed and resolved following
change management practices, including the update of documentation.
2687
•
Documentation of results
2688
2689
Reference chapter 12, Stage 3 Assessment-Pre-startup Safety Review (PSSR) for additional
information.
2690
11.10
2691
The following are typical outputs following implementation in preparation for the PSSR:
2692
2693
2694
2695
2696
2697
2698
2699
2700
2701
2702
2703
2704
2705
2706
2707
2708
2709
2710
2711
2712
2713
2714
2715
2716
2717
2718
2719
2720
2721
2722
2723
2724
2725
2726
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Deliverables
Regulatory requirements
Adopted industry standards
Corporate policies and procedures
SuC Description
Controls Philosophy
Reliability requirements
Availability requirements
SuC asset inventory (hardware and software)
Process Safety Information
Current red lined P&ID’s
Control platform specification
Network device specifications for use in levels 0 through the DMZ
IIOT/Cloud specifications and requirements for use in in levels 0 through the DMZ
Manufacturer security manuals
Configuration requirements and as configured documentation
Instrument & Valve Specifications
As built control system and OT network architectural drawings
As built Zone & Conduit Drawings
Hardware system layout drawings
C&E matrix drawing(s)
SIFs and safeguards assigned to layers of protection
PHA worksheets / report
Data flow documentation including rationale for requirements
Current vulnerability documentation
Detailed level cyber risk assessment report and recommendation closeout documentation
Safety Requirements Specification (SRS)
Cybersecurity Requirements Specification (CRS)
SPR-I verification report
SIL verification report
FAT documentation
SAT documentation
Commissioning documentation
Pre-validation checklist results
Validation documentation
Key performance indicator report(s)
ISA-TR84.00.09-2023
•
•
2727
2728
2729
2730
2731
2732
2733
2734
2735
2736
2737
2738
•
•
•
•
•
•
•
•
- 105 -
Emergency procedures (including security events and incidents)
Access requirements based on least privilege (3 rd party service providers and contractors
as well as employees)
Operating procedures
Maintenance philosophy
Mechanical integrity program procedures (including maintenance of security measures,
e.g., patching, inspections, etc.)
Revalidation procedures
Project Design Change Tracking documentation
Change management policy, standards, and procedures
CSSA stage 3 assessment/audit results
PSSR punch list
2739
12
Stage 3 Assessment - Pre-Startup Safety Review (PSSR)
2740
2741
2742
2743
2744
Conducting the stage 3 assessment should be part of the pre-startup safety review (PSSR). This
is generally a requirement of Process Safety Management regulations, e.g. , OSHA 1910.119
subpart H, Process Safety Management of highly hazardous chemicals. Stage 3 Functional
2745
12.1.1 Purpose
2746
2747
2748
The intent of the stage 3 assessment is to provide the appropriate contribution to the PSSR
required by various governmental regulations so that that the plant is confirmed to be safe and
secure prior to beginning operation.
2749
12.1.2 Input and Guidance
2750
2751
2752
Performance of a stage 3 cybersecurity assessment should occur following the installation, pre commissioning, and completion of the final validation of the IACS cybersecurity security measures,
as well as development of operation, maintenance, and emergency response procedures.
2753
2754
2755
Competent personnel should complete performance of this assessment via an independent check.
These persons should have both the knowledge and experience to judge both the completion of
expected work and when applicable, the quality of such work.
2756
The input for the stage 3 project assessment is
safety assessments, required by ISA 61511, are a contribution to the PSSR. Stage 3
cybersecurity assessments are also an important contribution to the PSSR.
2757
•
Project Design Change Tracking documentation
2758
•
Stage 1 assessment report
2759
•
Stage 2 assessment report
2760
•
Safety Requirements Specification
2761
•
Cybersecurity Requirements Specification
2762
•
Hazard review report and worksheets (e.g. , HAZOP, LOPA, etc.)
2763
•
Data flow analysis report
2764
•
Detailed level cyber risk assessment report
2765
•
Vulnerability assessment
2766
•
SIL verification report
2767
•
Security Protection rating (SPR) verification report
2768
•
Control system architecture drawings
2769
•
Zone and conduit drawings
2770
•
Configuration documentation
ISA-TR84.00.09-2023
- 106 -
2771
•
Asset Inventory
2772
•
C&E matrix drawing(s)
2773
•
PFD’s
2774
•
P&ID’s
2775
•
FAT documentation and action items
2776
•
SAT documentation and action items
2777
•
Commissioning documentation
2778
•
Validation documentation
2779
2780
•
IACS safety system and security operating, maintenance, and emergency procedures,
inclusive with cybersecurity emergency response
2781
•
Inspection and test procedures
2782
•
Patching procedures
2783
•
Change management policy, standards, and procedures
2784
•
Key performance indicators that are implemented
2785
•
Employee training records
2786
•
Competency criteria and logs
2787
•
Plans or strategies for implementing further assessment stages
2788
12.1.3 Output
2789
The result of stage 3 assessment is
2790
•
Either an approval to commence startup OR
2791
2792
•
A requirement to re-iterate and improve certain design, implementation, or procedural
aspects.
2793
2794
An example checklist template to aid in this assessment is included in Annex B, Cyber security
Assessment Stage Check List Templates .
2795
13
2796
2797
2798
2799
2800
2801
Management of cyber security during the operation and maintenance phase of the lifecycle
includes management of automation asset integrity through a variety of measures, bypassing,
patch management, performance measurements as well as periodic assessments a nd audits. In
the event of cyber security related changes during operation, change management procedures are
used. Cyber security events and subsequent response is also a component of the Operate and
Maintain phase.
Operation and Maintenance
ISA-TR84.00.09-2023
- 107 -
Startup
Operation
Section 13.1
Maintenance
(Automation Asset Integrity Program)
Section 13.2
Audits and Assessments
Section 13.3
Security Monitoring and Performance
Measurement - Section 13.4
Take appropriate
action
Immediate
Threat
Detected?
Yes
No
No
Incident Response
Section 13.5
Revalidation
Due?
Yes
Stage 4 Assessment
Section 14
No
Modification to
SuC?
Yes
Stage 5 Assessment
Section 15
2802
2803
2804
Figure 13.1
Operation and Maintenance Lifecycle Phase
2805
2806
2807
2808
Figure 13.1 expands Figure 0.2, Generalized Integration of Safety / Security Lifecycle operation
and maintenance phase, including the stage 4 and 5 assessments that take place during the
operation and maintenance phase. Each box lists references to the section(s) that address the
topic.
2809
13.1
2810
2811
2812
2813
2814
2815
Following start-up, the plant continues with operation. Cyber events during operation represent
potential incidents involving safety, financial and environmental hazards, therefore it is necessary
to maintain the capability, including security, built into the design and the associated organizational
management measures necessary to support the on-going operational and safety needs. The
following sub-sections discuss several topics that can help maintain the requisite security
capability.
2816
13.1.1 Access Control
2817
2818
2819
2820
An access control policy should be in place to avoid unauthorized access that can lead to
compromise of information, or misuse of the PSCAI systems. User access rights should be subject
to review at regular intervals using a formal work process. The user a ccess rights should be
modified as applicable due to internal changes in responsibilities or job function and removed or
Operation
ISA-TR84.00.09-2023
- 108 -
2821
2822
disabled upon termination of the user relationship with the organization (employment, contract, or
agreement).
2823
2824
The access management system should take into consideration the type of user access: physical,
logical, and/or remote access. See ISA 62443-2-1 for additional guidance.
2825
13.1.2 Physical Access Security
2826
2827
2828
2829
2830
2831
Managing physical access to the SuC containing PSCAI (IACS) is a starting point for th e cyber
security program, independent of any cyber security risk assessment, especially servers used for
authentication and access control as well as process/safety controllers and their engineering
workstations without waiting on a formal risk assessment. Authorized physical access based on
the concept of least privilege is recommended. Jumpers for process transmitters should be in place
to prevent remote changes to process sensor configurations.
2832
2833
2834
Securing physical access helps to minimize malicious as well as non-malicious insider (i.e., person
with authorized access) cyber intrusions. Any unauthorized physical access to a PSCAI system
would be outside of acceptable limits.
2835
13.1.3 Logical access security
2836
2837
2838
Following physical access to control and / or network hardware, access should utilize a secure logon procedure in accordance with ISA 62443-2-1 and ISA 62443-3-3. As part of this, rules based
upon clearly defined roles provides the basis for granting or denying logical access.
2839
2840
2841
2842
Which ISA 62443-3-3 requirements are applicable are a function of the applicable target security
level SL-T and / or target security Protection rating SPR-T. All users should have authentication,
authorization, and approval measures. Users should not be allowed to log in more than once at
the same time. Avoiding common user ID’s as much as possible is a good practice
2843
2844
2845
2846
2847
2848
2849
2850
2851
Persons conducting activities not impacting real time operation of the plant should have unique
means of identification and passwords. Operators responsible for real time operatio n typically
utilize common passwords because imposing a requirement to remember a password during a
response to an emergency represents poor human factors and increases the likelihood of greater
harm, however, they should still log in using their own uniqu e identification. Measures should be
in place to log when specific operators log in and when they log out. Inactive sessions for those
personnel conducting activities not impacting real time operation of the plant should shut down
after a defined period of inactivity. Additional security for highly sensitive applications is provided
when a defined connection time is used.
2852
13.1.4 Wireless Access
2853
2854
2855
2856
2857
Wireless applications should implement ISA 62443-2-1 and ISA 62443-3-3 requirements for
wireless access. This includes both physical and logical access control considerations as
discussed in the previous sections. In some cases, remote access control considerations might
also apply. The standards provide additional requirements beyond access control due to the nature
of wireless designs.
2858
2859
2860
2861
2862
ISA 100 requirements support both out of band and over the air provisioning to address security
issues. Other industry initiatives are beginning to address Bluetooth. ISA 100 is directed at all
wireless applications at levels 0 and 1. When pr ocess safety risk is involved, then requirements of
ISA 62443 and ANSI/ISA 61511 should be applied with ISA 100 and take precedence when
warranted by the risk. This is also true with respect to Bluetooth applications.
2863
13.1.5 Remote access
2864
2865
2866
2867
Remote access by its very nature does not allow the additional security that is possible with the
use of physical access controls in addition to logical access controls. As such, it should be
limited to a minimum. A higher risk is present for remote access to PSCAI systems as it has the
potential to create significant cyber security vulnerabilities, especially when bypassing security
ISA-TR84.00.09-2023
- 109 -
2868
2869
2870
measures that may be present in higher network levels. Examples include allowing access for
remote operation, diagnostics, and programming. Disabling or removing remote access
capabilities is preferred whenever possible.
2871
Prior to allowing remote access, consider the following:
2872
•
Management approval should be obtained following a risk assessment.
2873
2874
•
The remote session should be for a limited duration and automatically ended upon
inactivity.
2875
2876
2877
2878
•
Identification and Authentication sufficient to ensure that only approved persons and
devices are accessing the system. The higher the risk consequence, the strong er and more
complex authentication technologies should be implemented, e.g., use of multifactor
authentication.
2879
•
Encryption of data flows.
2880
2881
•
Implementation of visiting PC/laptop cyber security policies. External PCs should have a
supported anti-malware protection program running.
2882
2883
•
Confirmation that accesses and communication of application external to the system are
not able to interfere with the operation of the PSCAI nor the safety -critical communications.
2884
•
System design that prevents potential for split tunn eling.
2885
•
Provisions to prevent unauthorized access to field devices via back doors in such devices.
2886
2887
•
Added monitoring, such as intrusion detection techniques on all remote connections to
assure that no abnormal activity or actions occur while the connection i s established.
2888
•
Cyber security log file kept for all remote session activities.
2889
2890
•
Use of host-based firewalls, and operating system/application software patches have
considered product supplier guidelines.
2891
•
Monitoring performance of remote activity.
2892
2893
•
Permanent and full control of the remote access by asset owner personnel (initiation and
stop)
2894
•
The ability to manually return the plant to a safe state independent of the PSCAI system
2895
Refer to ISA 62443-2-1 and ISA 62443-3-3 for specific requirements
2896
2897
2898
2899
2900
2901
2902
2903
2904
2905
2906
13.1.6 Electronic Use Criteria
Contemporary cyber incidents have proven that cyber-attacks and malware associated with
portable media can bypass boundary security measures. Portable media includes Universal Serial
Bus (USB) flash drives, external/removable hard drives, compact disks, digital video disks,
Zip/Jazz disks, data tapes, floppy disks, hand-held calibrators, cell phones, laptops, and tablets
etc. Policies and procedures making it clear what type of portable media ar e allowed and how they
are to be managed should be developed and implemented by the asset owner. Hardening guidance
provided by product suppliers are a source of information that can supply valuable information
when developing the electronic use criteria policies and procedures. Where technically possible,
enforcement using technical means that portable media content has been checked prior access to
access (e.g., BPCS, SIS, etc.) should be implemented by the asset owner.
2907
13.1.7 Bypasses / Overrides
2908
2909
2910
2911
2912
2913
Asset owners typically have bypass policies and procedures documented for situations when
instrumented protection (safety and/or security) requires disabling during operation. These
situations may involve on-line proof testing or repairs to failed equipment. Cyber secur ity is
protection for the entire IACS, including PSCAI. As such, amending bypass policies and
procedures to include the management of bypassing cyber security measures is appropriate within
the full scope as defined by this document.
ISA-TR84.00.09-2023
2914
2915
- 110 -
Considerations for updating these policies and procedures include, but are not necessarily limited
to the following:
2916
•
Minimize duration of the bypass.
2917
•
Diagnostics should alert appropriate personnel at repeated intervals.
2918
•
Record dates and times of bypass.
2919
•
Report bypass logs to independent third-party administrators within the company.
2920
•
An alert at the time a logical bypass / override is set.
2921
•
Bypass should alarm after a defined period if not restored.
2922
2923
2924
2925
2926
2927
•
Implement compensating security measures while the bypass is in place to ensure the
PSCAI is not compromised as part of a temporary MOC. For example, disconnect the
PSCAI system from the network and ensure that those engaged in interfacing to the PSCAI
system when in the bypass mode are trusted, as well as to follow all the policies,
procedures, and security measures that are commensurate with the applicable security
level.
2928
2929
Additional Management of Change guidance is provided in chapter 15, Stage 5 Assessments:
Management of Change / Decommissioning.
2930
13.2
2931
13.2.1 Routine maintenance
2932
2933
2934
2935
2936
When developing a maintenance program considering cyber security issues, a good place to start
is by reviewing manufacturer recommendations. Part of this maintenance program should be the
development of a patch management work process. More information about patch management is
provided in chapter 15, Stage 5 Assessments as patch management is most appropriately
considered a part of change management.
2937
2938
Periodic inspections and repair are part of routi ne maintenance. These may include but are not
necessarily limited to:
Maintenance
2939
•
Ensuring equipment hardening requirements not compromised
2940
2941
•
Comparison of performance against expected performance, e.g., calibration anomalies,
component configuration anomalies, etc.
2942
•
Identification of device vulnerabilities
2943
•
Password requirements being met
2944
•
Maintenance of monitoring tools (continuous, periodic or condition based)
2945
•
Repair due to detected failures
2946
2947
2948
The frequency of the inspections should be a function of what was determined dur ing the risk
assessment as well as whether they are manual or automated in nature. For more information
regarding automated security monitoring, see sub-section 13.4.2,
2949
2950
2951
Consideration should be given to the management scheme such as a regularly checking
procedures from the lifecycle point of view, and the technical scheme such as a regular audit of
the antivirus software and log.
2952
2953
2954
Updates to software (e.g., antivirus, application, embedded, etc.) should be validated by the
responsible party and tested before implementation. Prior to actual installation on site, end users
should consider the potential impacts of the changes.
ISA-TR84.00.09-2023
- 111 -
2955
2956
2957
2958
2959
When workstations that have application software installed are updated, a person authorized per
least privilege principles should be present at the workstation to either perform the work or monitor
the work if being done remotely, with the ability to terminate the session if problems arise. It is a
best practice to only have this type of software installed on engineering worksta tions where the
potential for software associated with process safety controls, alarms or interlocks exists.
2960
2961
2962
2963
2964
2965
Backup and restoration capabilities and procedures of all the PSCAI network configurations should
be provided and tested on a periodic basis. Test performance should be based on the RTO
(recovery time objective) and MTD (max tolerable downtime) of the recovery process to ensure
that recovery is possible for the different cyber -attack scenarios. The interval of time between
testing should be based as a function of number of changes being made ( e.g., monthly notification
of patch updates) and past test performance metrics as well as the level of risk.
2966
13.2.2 Automation Asset Integrity Program
2967
2968
2969
2970
2971
2972
2973
2974
2975
2976
2977
An asset integrity program begins with identifying what the safety functions are by component,
how each function and listing the known failure modes will all be important inputs in developing
the security for safety assets. Automation Assets need to be mon itored for the health of the security
asset and the safety asset whether individual components or systems. As such, a successful
automation asset integrity program should include the complete identification of compatible
security devices capable of protecting their appropriate safety function and its assets . The best
program leverages a full range of Secure-by-Design defense-in-Depth, with secure development
life cycle practices results with an integrity baseline . Careful attention should be paid to every
interaction between the safety function and how it is secured to later assist in verification .
Recording the security asset’s design and test parameters used to secure a particular safety
function supplements FMEA, FAT/SAT and review during MOC .
2978
13.2.3 Obsolescence Planning
2979
2980
It is often the case that legacy equipment in use is no longer supported by the manufacturer. This
is increasingly problematic over time due to:
2981
2982
2983
2984
2985
•
•
•
Increasing loss of reliability / integrity due to wear -out
Increasingly difficult to obtain spare parts that can be assured of the same OEM
capability / security
Inability to patch new vulnerabilities when they are identified, increasing risk of being
compromised
2986
2987
2988
2989
2990
2991
2992
As such, it is prudent for the asset owner to have a documented obsolescence plan in place to
address obsolescence of cybersecurity related equipment/mitigation/ software . The start of such a
plan is a complete asset inventory that documents the current versions of operating and application
software as well as any information from the manufactu rer about upcoming updates and / or plans
for stoppage of support. Based upon the timeframes, potential risks, and availability of other means
of support, a plan should be developed that considers when it is most advantageous to update the
obsolete equipment and how those updates should be managed.
2993
13.2.4 Tools
2994
2995
2996
Several tools perform necessary activities associated with the IACS and its associated network
and devices. The table 13.1 below illustrates examples of tools and associated activities relevant
to the IACS and its associated network as well as devices.
2997
ISA-TR84.00.09-2023
2998
- 112 -
Table 13.1
Tool Examples
Hand-held calibrators
IACS Example Activities
Calibrate field instrumentation
Guidance
Should manage in accordance
with ISA 62443-2-1 as well as
any requirements identified
during the risk assessment.
Device should comply with ISA
62443-4-2 for the highest
security level for the zone(s) it
is intended to be used or
implement compensating
measures as needed for SL-C.
Engineering
workstation(s)
Engineering configuration of
BPCS, SIS, power monitoring
equipment, and vibration
monitoring / protection
equipment.
Configure system integration as
well as devices such as
chromatographs, vibration
devices, water treatment
devices, safety logic solvers,
firewalls, servers, switches
Portable Hardened
devices, e.g., Laptop or
tablet (intermittent
connection to IACS and
associated network)
Diagnose firewalls, servers,
switches.
Configure devices such as
chromatographs, vibration
devices, water treatment
devices, safety logic solvers,
firewalls, servers, switches.
Manual data collection for
maintenance purposes,
inspection data, etc.
Vulnerability testing, penetration
testing.
Should manage in accordance
with ISA 62443-2-1 as well as
any requirements identified
during the risk assessment.
Device should comply with ISA
62443-4-2 for the highest
security level for the zone(s) it
is intended to be used or
implement compensating
measures as needed for SL-C.
Dedicated use is
recommended, e.g., used for a
specific purpose using a
specific software version to
support a specific supplier’s
device.
Should manage in accordance
with ISA 62443-2-1 as well as
any requirements identified
during the risk assessment.
Device should comply with ISA
62443-4-2 for the highest
security level for the zone(s) it
is intended to be used or
implement compensating
measures as needed for SL-C.
Dedicated use is
recommended, e.g., used for a
specific purpose using a
specific software version to
support a specific supplier’s
device.
Prior to use, check to ensure
most current asset owner
ISA-TR84.00.09-2023
Tool Examples
- 113 -
IACS Example Activities
Guidance
approved patches (OS and
malware) have been installed.
Hardened Test Device
workstation
Download engineering files from
the internet
Download patches from the
internet
Transfer engineering software,
patches to engineering
workstation following testing and
approval
General Purpose
Laptops
Not appropriate for use
General Purpose Tablets
Not appropriate for use
General Purpose Cell
phones
Not appropriate for use
Should manage in accordance
with ISA 62443-2-1 as well as
any requirements identified
during the risk assessment.
Device should comply with ISA
62443-4-2 for the highest
security level for the zone(s) it
is intended to interface with or
implement compensating
measures as needed for SL-C.
2999
3000
3001
3002
3003
If a tool is not sufficiently secure relative to its SL -T from a technical capability perspective, i.e. ,
failure of tool to comply with ISA 62443-4-2 for the SL-T required by the zone where it is used, the
zone SPR-C would be deficient as compared to the zone SPR-T. In addition, insufficient
management of the tool would also cause the zone SPR-C to be deficient as compared to the zone
SPR-T. In such situations, the tool becomes a potential threat vector to compromise the zone(s).
3004
3005
3006
3007
Proper management of tools involves development and implementation of rules embedded in
procedures for the tools used by engineering, maintenance, and service providers. Failure in the
proper management of these tools in a consistent and secure manner causes in efficient and
inaccurate work procedures leading to poorly managed risks.
3008
Lack of clear rules for tools results in the following:
3009
3010
3011
3012
3013
3014
3015
3016
3017
3018
3019
3020
3021
3022
3023
3024
•
•
•
•
Difficult or impossible procedures for end users
Lack of interoperability
Lack of integrity
Unnecessary chaos and associated c osts
From an application perspective, this document classifies tools as either manufacturer tools or
shop tools. Manufacturer tools provide unrestricted capability necessary for manufacturers to
create and support devices in an engineering development or factory environment. Shop tools
provide off network access to third parties or end users with less capability than manufacturer tools.
They are not appropriate for on network procedures. When there is a lack of security capability in
shop tools, the recommendation is to block on-network procedures.
Many of the current portable tools intended for use in the shop do not currently support cyber
requirements as documented in ISA 62443-2-1 and ISA 62443-3-3 for interfaces with the network
or internet, e.g., log on to networks and communicate over networks to host systems, even though
they have the capability to connect. Likewise, current host systems do not currently support
portable field tools. The current situation means that compensating security measures in the form
ISA-TR84.00.09-2023
- 114 -
3025
3026
3027
3028
3029
3030
3031
3032
3033
of increased reliance on management procedures and rules to address the gap in technical
capabilities are the only way to ensure compliance with the asset owner’s zone(s) SPR -T.
3034
The following provides guidance for the creation of rules for portable tools:
3035
3036
Portable field tools that provide required access to host support functions from a location proximate
to a field device should:
Due to the shop dealing with tools that potentially interface with multiple zones, consideration of
making the shop a separate zone with a SPR-T equal to the highest SPR-T of the zones its tools
interface with.
Host systems with the ability to communicate securely with portable field tools would convert
awkward 2-person procedures to more efficient 1-person procedures.
3037
3038
3039
•
Be logged in to host systems and should communicate with hosts. Commissioning and
maintenance procedures require field interaction with devices and process connections in
the field, but device and field tool interaction should be directed th rough a host.
3040
3041
3042
•
Disallow direct communication from a tool to a device after provisioning. Field tools can
facilitate provisioning and configuration; however, the recommendation is to automate
these procedures as much as possible.
3043
3044
3045
•
Authenticate and authorize devices, field tools, and users to allow access. This means that
devices be used that support authentication and authorization. It is recommended that they
also support backup and restore, data protection, and continuous monitoring.
3046
•
Have their activities logged by host systems.
3047
3048
•
Have capability to detect and reject direct commands from manufacturer and shop tools
while the devices are network connected.
3049
3050
3051
•
Implement procedural controls to compensate when they lack the firewall function to reject
unauthorized communication, i.e., for legacy devices. Monitoring is the primary procedural
control available for legacy protocols.
3052
•
Be included in change management program. Reference figure 15.1.
3053
3054
3055
•
Assessed for malware, and cyber security patches for all software compone nts prior to first
time connection or use on a PSCAI system and after any software or version update
following the first-time use.
3056
3057
Field tools can be a thin client (i.e., a simple computer that has been optimized for establishing a
remote connection with a server-based computing environment).
ISA-TR84.00.09-2023
- 115 -
Start
Device (e.g. field sensor,
controller, etc.) requires repair
or upgrade
Secured
Secured Internet
Internet
Download
Download
Returned to product
supplier for repair
Site Maintenance Shop
Replacement
in Kind
- Purchase order should make it
clear that 3rd party shops and
product suppliers acting in a
service provider role should
comply with 62443-2-4 as
necessary (defined in PO) to
comply with asset owner
standards and procedures.
- An expectation would also be
that 3rd party shops and
product suppliers acting in a
service provider role have a
cyber security management
system in place that complies
with 62443-2-1
Secured
Secured Internet
Internet
Download
Download
Secured
Secured Internet
Internet
Download
Download
Local 3rd party shop
No
Perform MOC
Yes
No
Approved
Yes
No
Resolve issues
PSSR
criteria met
Yes
Return to
service
3058
3059
Figure 13.2
3060
3061
3062
3063
Optimizing tools for ease of use by the supplier represents good design practice. This implies most
jobs are capable of performance by a single technician without engineering support and automation
of support for new device revisions (including MOC). This includes maintenance of full functionality
after update.
3064
3065
Reference Annex N, Security of Field Devices and Their Interface within the IACS , for additional
guidance for field devices and their interface with tools.
3066
13.3
3067
13.3.1 Audits
3068
3069
ISA 62443-2-1 provides the asset owner with a framework for development of their security
program that includes ongoing auditing for compliance and improvement.
3070
3071
3072
Audit records should be sufficient to monitor the effectiveness and proper operation of the
management system requirements in ISA 62443-2-1 and the security mechanisms utilized to meet
the requirements of ISA 62443-3-3 standards. Existing work processes for performing a udits
Audits and Assessments
ISA-TR84.00.09-2023
3073
3074
- 116 -
should be leveraged to incorporate various cyber security checks. These checks may include but
are not limited to the following topics:
3075
•
Compliance with Policies and Procedures
3076
•
Asset Management Compliance
3077
•
Device Security
3078
•
Least Privilege Conformance
3079
•
Use Control Conformance
3080
•
Physical Security
3081
•
Logical Access Security
3082
•
System Integrity Conformance
3083
•
Resource Availability
3084
•
Defined Data Flow Conformance
3085
•
Data Confidentiality Conformance
3086
•
Configuration Changes
3087
•
Security Logs
3088
•
Event Monitoring Results
3089
•
Alarm Events
3090
•
Zone SPR compliance
3091
•
Business continuity plan drills
3092
•
Emergency response plans drills
3093
•
Incident reporting Conformance
3094
•
Training Conformance
3095
3096
3097
Audit information includes all information (for example, audit records, audit settings and audit
reports) needed to successfully audit control system activity and capability. The audit information
is important for error correction, security breach recovery , investigations, and related efforts.
3098
3099
3100
3101
Audit records should be centrally managed and audit records should be compiled from multiple
components throughout the control system into a system -wide (logical or physical), timecorrelated audit trail. Audit records should be saved in a secure manner and stored in a safe
location, e.g., watertight, fireproof, etc.
3102
Ongoing audits manually performed should be performed at defined intervals.
3103
3104
Annex K, Example Audit Form(s), provides an example of a physical inspection audit form with
pass / fail criteria.
3105
Audit results can be an important input to key performance indicators.
3106
13.3.2 Job Cyber Assessments
3107
3108
3109
3110
3111
3112
3113
To identify cyber hazards related to activities performed by employees and contractors, one
method is to assess those procedures is to perform a job cyber assessment (JCA). This is like the
concept of job safety assessments (JSA) used within industry. The JCA methodology is intended
to be used for the assessment of site work instructions where errors can result in potential cybe r
security events. The JCA can help to identify appropriate measures to eliminate, reduce the
likelihood of, or mitigate the consequences of cyber hazards that may exist prior to engaging in
such work practices.
ISA-TR84.00.09-2023
- 117 -
3114
3115
3116
The development of a JCA is recommended for all specific procedural activities that that have the
potential to compromise cyber security of the IACS network and process controls. Annex M, Job
Cyber Assessment, provides a procedure for performing a JCA.
3117
13.3.3 Service provider / product supplier qualificati ons
3118
3119
Prior to the purchase of programmable devices or services, suppliers should be evaluated for
conformance with applicable ISA 62443 standards.
3120
3121
3122
For service providers, demonstrated conformance to ISA 62443 -2-4 is recommended. As part of
the assessment, understanding how their procedures dovetail with the asset owner’s procedures
is critical. The final procedural expectations should be documented in the contract for their services.
3123
3124
3125
3126
3127
3128
3129
With respect to product suppliers, demonstrated conformance to ISA 62443 -4-1 and ISA 62443-42 is recommended. Conformance to ISA 62443-4-1 helps to ensure that the product supplier work
processes are adequate. Any deficiencies found should be addressed and remedied. ISA 62443 4-2 provides the technical requirements as a function of SL for programmable devices. This applies
to all devices within the IACS and its associated network from levels 0 through 3.5, including those
devices (e.g., tools, remote access engineering workstations, portable media, etc.) that have
intermittent connectivity.
3130
3131
3132
Should the product supplier be a system integrator, ISA 62443 -3-3 should be included in the
specification and evaluated for conformance. ISA 62443-3-3 includes complete system
requirements as a function of security level for the system being provided.
3133
3134
3135
3136
3137
3138
3139
Understanding the technical security capabilities of the equipment and systems is essential to
determine what level of procedural support is necessary as well as if there is a need for additional
compensating measures. The evaluation process of the product supplier (devices and systems) is
important irrespective as to whether the equipment is being purchased from the original equipment
manufacturer (OEM) or some other distributor ( e.g., distributor, off the internet, etc.). When
purchased from a supplier other than the OEM, the evaluation should ensure that counterfeit
equipment is not being supplied.
3140
3141
In the case where refurbished equipment is being purchased, they should also be audited for
conformance to ISA 62443-2-4.
3142
13.4
3143
13.4.1 Alarms and Alerts
3144
3145
3146
3147
3148
3149
3150
3151
The ISA S18 standards define an alarm as an audible and/or visible means of indicat ing to the
operator an equipment malfunction, process deviation, or abnormal condition requiring a response
in a timely manner. They define an alert as an audible and/or visible means of indicating to the
operator an equipment or process condition that requires awareness, which is indicated separately
from alarm indications, and which does not meet the criteria for an alarm. One might consider the
IACS network as being a utility process operated in a supervisory manner. Consequences of
mismanagement or failure to respond to alarms indicating system compromise have the potential
to impact process safety. To mitigate this potential, asset owners should consider the following:
3152
3153
3154
3155
3156
3157
3158
3159
3160
3161
•
•
•
•
Security Monitoring and Performance Measurement
Identify all diagnostics and other indications of abnormal conditions involving the c ontrol
system and associated zone(s), conduit(s), networks. This should also include those that
are related to cyber security.
Perform alarm rationalization of these alarms and indications of abnormal conditions.
As part of the alarm rationalization, define the relationship among process operators,
network operators and maintenance.
When a cyber alarm is identified, define the required response in an appropriate
procedure. The procedure should define the interface between IT and OT so that a
coordinated response is possible. This should describe who is responsible for what as
well as any required communications.
ISA-TR84.00.09-2023
3162
3163
3164
•
- 118 -
Applicable training requirements to ensure appropriate comprehension and expected
response to an alarm consistent with the cause of the alarm, e.g. , equipment failure,
cyber-attack, etc.
3165
3166
More detailed information regarding alarm management may be found in the ISA 18 series of
standards and technical reports.
3167
13.4.2 Automated Security Monitoring
3168
3169
3170
3171
3172
3173
3174
3175
Automatic security monitoring should provide clear and meaningful information to the operations
or maintenance functions allowing for a quick and accurate response to a security breach .
Additionally, the security monitoring should be able to correctly identify if the security breech
impacted the availability of the safety system. The security monitoring system should display event
monitoring “results” and the appropriate action response to any alarms. If the security monitoring
identifies any abnormality it cannot identify, accurate information of the condition must be
displayed and logged for later forensics and incident response . All changes to the security
monitoring functions should follow MOC.
3176
3177
Specific monitoring requirements as a function of security level can be found in ANSI/ISA 62443 3-3.
3178
13.4.3 Key Performance Indicators
3179
3180
3181
3182
3183
3184
3185
Cyber security involving systems with PSCAI is a relatively new subject but, in fact, has always
been an inherent part of SIS design. For example, a SIS is by design supposed to be independent
and implemented to prevent unauthorized access. Cy ber security and SIS’s share much of the
same design attributes. Both are concerned with physical and logical access. Both are concerned
with change management authorization processes that ensure only authorized personnel and
authorized systems gain access to the SIS. For this reason, it makes sense to develop cyber
security metrics that benefit safety.
3186
3187
3188
3189
When creating metrics, both leading and lagging indicators help better understand the current level
of performance and how to prioritize future improvement activities. Figure 13.3 is a modification of
an API 754 figure that illustrates the relationship of leading and lagging indicators, as well as an
increase of severity as an event climbs the pyramid.
LOPC = Loss of Primary Containment
TIER 1
LOPC Events of
Greater Consequence
TIER 2
LOPC Events of
Lesser Consequence
Operating Discipline & Management Systems
Performance Indicators
3190
3191
Figure 13.3
s
tor
TIER 4
ica
nd
gI
din
Challenges to Safety & Security Systems
a
Le
TIER 3
ISA-TR84.00.09-2023
- 119 -
3192
Leading / Lagging Tier Structure
3193
3194
3195
3196
3197
3198
3199
Asset owners are encouraged to use various metrics and key performance indicators as they seek
to improve their performance. Different asset owners most likely will be at different points in their
maturity with respect to cyber security as well as having different risk profiles, therefore different
Key Performance Indicators (KPI) will be more appropriate. As an asset owner’s maturity level
improves, revisions to what KPI’s are emphasized will most likely change as well as their
associated failure criteria. Annex L, Cybersecurity KPIs and Metrics includes several KPI’s and
metrics for use as users see fit.
3200
13.5
3201
3202
3203
3204
3205
3206
3207
3208
3209
3210
3211
Threats may or may not be immediate. A documented plan should be in place that specifies how
responses to intrusion (intentional or unintentional) demands are addressed and responded to
considering their urgency and potential consequences. The incident response plan should include
procedures for how the organization will react to incidents as a function of the incident
consequence (high impact, low impact), including notification/communication, investigation and
recovery methods as well as identifying responsible personnel and actions to be performed by
designated individuals. The high-level risk assessment should have provided a starting point for
how to begin mitigation. Final development of the complete procedures should have occurred
during the design phase. These procedures should be reconciled or integrated with existing work
processes such as the site emergency response plan and near miss/incident reporting systems.
Confirmation of implementation should occur during the pre - startup safety review (PSSR).
3212
Refer to ISA 62443-2-1 for specific requirements related to incident management.
3213
3214
The resulting outputs from complying with ISA 62443-3-2 can provide a starting point to help
develop response procedure.
3215
3216
3217
3218
3219
Following a failed or successful attack, an analysis should determine if upgrades and corrective
actions are appropriate to reduce the likelihood in the fut ure. Quantification of incident metrics
based on type, volume, consequences and/or cost can support justification of such upgrades.
Recording and communicating unusual activities and events generates an environment specific
cyber-knowledge base.
3220
3221
3222
To prepare for potential attacks, the performance of drills to practice response procedures under
simulated conditions help to improve performance. These drills should be conducted on a periodic
basis.
3223
14
3224
14.1.1 Purpose
3225
3226
3227
3228
3229
The intent of the stage 4 assessment is to revalidate the process hazards analysis (PHA)
assumptions made versus actual experience and to correct and / or update as applicable. In
addition, this is an activity that also reviews changes made since the last validation or revalidation
to determine if the as found satisfies the requirements stated in the safety and cybersecurity
requirements specification.
3230
14.1.2 Input and Guidance
3231
3232
3233
3234
3235
3236
Performance of a stage 4 cybersecurity assessment should occur following a defined period of
operation providing a level of experience or sooner if conditions are found to warrant, e.g. , a
substantial change in the threat landscape posing a risk known to not be tolerable by asset owner
senior management. For plants regulated by Process Safety Mana gement standards, e.g., OSHA
1910.119 subpart H, Process safety management of highly hazardous chemicals, this is typically
every five years.
3237
3238
3239
During this assessment stage, the risk review team should revalidate the prior risk assessments.
The review of initial assumptions and any changes affecting the initial assumptions are key to a
successful revalidation. The following activities can assist this assessment:
Incident Management
Stage 4 Assessment - Periodic assessments
ISA-TR84.00.09-2023
- 120 -
3240
•
Review cybersecurity incidents since last revalidation
3241
•
Review cybersecurity related management of changes since last revalidation
3242
•
Review current vulnerability assessment
3243
•
Review detailed level cybersecurity risk assessment and update as applicable
3244
•
Review of KPIs that result from audit program
3245
•
Address all recommendations resulting from revalidation
3246
3247
3248
3249
Persons knowledgeable in the processes, operations, and design under review with at least one
person knowledgeable and competent in the assessment methodologies used in the workshops
should participate. The membership of the assessment team should include at le ast one senior
competent person not involved in the operation and maintenance.
3250
The input for the stage 4 project reassessment is
3251
•
Safety Requirements Specification
3252
•
Cybersecurity Requirements Specification
3253
•
Prior action item closure documentation
3254
•
Current HAZOP worksheets / report
3255
•
Current LOPA worksheets / report
3256
•
Current data flow analysis report
3257
•
Current detailed level cyber risk assessment report
3258
•
Current vulnerability assessment
3259
•
Current SIL verification report
3260
•
Current Security Protection Rating (SPR) verification report
3261
•
Control system architecture drawings
3262
•
Current zone and conduit drawings
3263
•
Current configuration documentation
3264
•
Current asset Inventory
3265
•
Current C&E matrix drawing(s)
3266
•
Current PFD’s
3267
•
Current P&ID’s
3268
•
Applicable Near miss, event, and incident records
3269
•
Applicable MOC records
3270
•
Obsolescence planning documentation
3271
•
Security procedures
3272
•
Security related maintenance procedures
3273
•
Inspection and test procedures
3274
3275
3276
•
•
•
Maintenance records
SIS/SIF work orders
Diagnostic alarms
3277
3278
•
•
Repair data
Inspection and test records
3279
•
Applicable KPIs
3280
•
Bypass policy and procedures
ISA-TR84.00.09-2023
3281
•
Bypass logs
3282
3283
•
•
Training records
Competency criteria and logs
3284
14.1.3 Output
3285
The result of stage 4 assessment is
- 121 -
3286
3287
•
An updated set of hazard review reports, e.g., HAZOP, LOPA, QRA, Cybersecurity Risk,
etc.
3288
•
Recommendations as applicable to address identified deficiencies
3289
3290
•
Action items with specified dates to eliminate deficiencies determined to not satisfy
corporate risk criteria
3291
3292
3293
Evidence of successful completion of all activities during this assessment stage may use the
example checklist template, provided in Annex B, Cyber security Assessment Stage Check List
Templates.
3294
15
3295
3296
3297
3298
3299
3300
Management of change (MOC) is a requirement of Process Safety Management regulations and
is associated with the stage 5 assessment. ISA 62443 -2-1 requires that all changes to the current
configuration baseline and infrastructure drawings / documentation, including revision and patch
levels, shall be authorized, validated, approved, and documented. In addition, as part of this
process it requires approval by two or more persons whenever the proposed actions can result in
serious impact to the industrial process.
3301
3302
3303
3304
3305
3306
Figure 15.1 is an expansion of the stage 5-assessment block within the generalized integrated
safety / security lifecycle documented in figure 0.2. The stage 5 flowchart shown in figure 15.1
starts with a proposed change and through a series of questions determines the type and extent
of recommendations to address the proposed change. For purposes of this technical report,
decommissioning is a subset of the MOC work process even though decommissioning is shown
separately in the Figure 0.2, generalized integrated safety / security lifecyc le.
Stage 5 Assessments: Management of Change / Decommissioning
ISA-TR84.00.09-2023
•
•
•
•
•
•
- 122 -
Risk assessment finding
Audit finding
Process Improvement
Software Updates
Vulnerability Identified
Personnel Changes
Change is proposed
or required
Significant
Design Change?
Yes
Execute full lifecycle
beginning with project
scope
No
Personnel
Change?
Yes
Execute specific
procedures designed
for personnel changes
Yes
Execute specific
procedures designed
for patch management
No
Patch
for identified
vulnerability?
No
Execute project scope
per lifecycle
No
Programmable
Equipment
Decommissioned?
Yes
Potential
replacement
in kind?
Yes
Modified model
or software
version?
Scrub software from
equipment being
replaced as part of
decommissioning
3307
No
Yes
Perform stage 5
assessment as applicable
in accordance with
process safety
management regulations
No
3308
Figure 15.1 – MOC / Decommissioning Work Process
3309
3310
15.1
Management of Change
3311
3312
3313
3314
3315
3316
Changes to the overall IACS and safety system may occur due to many reasons. Although MOC
is generally a well-established practice in the process industry, cybersecurity raises new issues
that should be considered. Any modification (see Figure 15.1) should trigger an analysis for impact.
The change should be evaluated against the process safety information, the SRS and the CRS as
developed and implemented. To support MOC, baseline information should be available. ISA
62443-2-1 requires the following:
3317
•
A current baseline configuration of all devices and their software components
3318
•
Documentation of configuration settings of all IACS devices and software applications
ISA-TR84.00.09-2023
- 123 -
3319
3320
•
Organization responsibilities, manufacturer, model, version numbers, serial numbers,
revision/patch levels and history.
3321
3322
•
A current baseline of the logical and physical infrastructure drawings / documentation of all
devices and their software components, including their network connectivity.
3323
General Change Management Considerations
3324
3325
In general, changes should be in accordance with the conventions set forth in the design basis
documents and suggested adherence to:
3326
•
product supplier’s safety manual.
3327
•
product supplier’s cybersecurity manual.
3328
3329
•
all business network integration agreements / policies / work process documents that
support the cybersecurity countermeasure implementation.
3330
3331
Examples of items that should be part of change management include but are not necessarily
limited to:
3332
3333
3334
•
Changes to access restriction to the maintenance/engineering interface. Restriction of
access can be procedural, designed and controlled via network, an d / or additionally
controlled via local plant key locks with active monitoring metrics.
3335
3336
3337
3338
•
Changes to administrative policies/procedures that define the conditions under which the
maintenance interface may be connected to the system during normal operation. This may
involve procedural or designed and controlled via closed network access ports that require
MOC to open, creating online metrics and make available for use.
3339
•
Changes to written approval with reasons for access.
3340
3341
•
Changes to documentation of persons allowed access and what work individuals are
permitted to perform via written approval process.
3342
3343
3344
•
Changes to documentation of required training and/or familiarity with the system before
access is permitted. (See section on competence and system integration (bu y / build /
configure) competence.)
3345
3346
•
Changes to documentation of the circumstances that allow access to be permitted; this
includes the procedures that control the use of maintenance bypasses.
3347
3348
3349
•
Changes to the use of virus checking software and appropriate pr ogram and file handling
procedures in the engineering workstation or other components inside the safety zone (See
section on competence and system integration (buy / build / configure) competence.)
3350
3351
3352
•
Changes to the use of metrics used in the PSCAI system uti lity software that tracks
revisions in the application logic and allows the determination (after the fact) of when a
change was made, who made the change, and what the change consisted of.
3353
3354
•
Changes to methods dealing with unauthorized and authorized access (remote or local) to
the process control or safety system logic solvers and I/O.
3355
3356
•
Changes to any logic that can affect the proper operation of the PSCAI (time delays, set
point changes, maintenance bypasses, and PSCAI device configuration changes).
3357
•
Software and firmware patch updates.
3358
3359
3360
3361
Based on the evaluated impact of the proposed modification, the tasks performed by personnel
with lifecycle responsibilities may change. Training should be performed when modifications are
made to personnel responsibilities, work processes, procedures, or tools prior to implementation
of the change.
3362
Replacement in Kind
ISA-TR84.00.09-2023
- 124 -
3363
3364
3365
3366
3367
3368
3369
3370
3371
The seemingly simplest reason for MOC to consider is whether a change can be considered
replacement in kind. From a cybersecurity viewpoint, this means no changes to a device model
number or changes to its firmware or software. With the advent of smart devices, this is seldom
the case. Manufacturers are frequently updating the software due to software patches or the
modification of software to change or add feature s. New or modified features may result in new
vulnerabilities and should be evaluated against the CRS as well as from a risk perspective and
tested prior to implementation. Consequently, from a cyber security perspective, any changes
should not be considered “replacement-in-kind” and should have a cyber security review performed
and documented as part of the MOC. Any unneeded features should be disabled.
3372
Emergency Changes
3373
3374
3375
3376
3377
3378
3379
When there is no choice as to a change, such as following a failure, review of the new device
specification should look for new features as compared to the current device specification. New or
unneeded features should be turned off until it has been determined that they will not have a
negative impact on the original design basis. New featu res that cannot be disabled should be
tested to ensure they do not affect the current design basis or operations. ISA 62443 -2-1 requires
documentation of explicit manual elevation of privileges, including supervisor overrides for all
operations that require elevated privileges.
3380
Routine Maintenance
3381
3382
Some changes are routine to maintain security within a well-documented procedure. Updating
table definitions is an example where a general MOC is not required.
3383
Patch Management
3384
3385
3386
3387
3388
3389
3390
Patching may be part of normal maintenance, or it may be required due to the identification of a
critical vulnerability. In both cases, patching is part of change management. In the case of patching,
it generally makes sense to have specific procedures rather than use the more generalized MO C
work process. In general, patching should be performed as applicable. End users should assure
that all authorized firmware upgrades have been implemented securely and that no unauthorized
firmware changes have been made. Additional guidance is available in ANSI/ISA-TR62443-2-32015.
3391
3392
3393
3394
3395
3396
Figure 15.2 illustrates a generalized patch management work process. As patches inherently
involve a relationship between service providers and end users, ISA 62443 -2-4 requires that
service providers have the capability to review, because of changes in security risks, how they
evaluate and approve security patches for Automation Solution software for which they are
responsible. Please note that while the service provider is responsible for providing patches, the
end user is accountable for the actual decision to accept, defer, or reject a particular patch.
ISA-TR84.00.09-2023
- 125 -
Vulnerability
Identified
No
Serious Risk?
Yes
Follow patch management
approval process
(e.g. ISA TR62443-2-3)
Install when no
risk to operation
No
Patch
Available?
Implement compensating
countermeasure(s)
Yes
Patch Tested?
Yes
Pass
Do Not
Install
Yes
Risk OK?
Yes
Schedule Patch
Deploy Patch /
Monitor
Performance
3397
3398
3399
Figure 15.2
Generalized Patch Management Work Process
3400
3401
Functionality Changes
3402
3403
3404
Many changes involve new or revised functionality. Oftentimes the functionality provided exceeds
that requested due to being part of a standard product. Table 15.1 lists typical types of functionality
changes and associated recommended practices to consider when performing MOC.
3405
ISA-TR84.00.09-2023
- 126 -
3406
Table 15.1
Change Type
Recommended Practice
•
Review functionality to ensure unneeded features are turned
off or will not impact original design basis.
•
Review intended functionality changes in the context of risk
for the system affected.
•
Testing required to ensure new features that cannot be
disabled will not affect current design basis or operations
Configuration / software
changes / upgrades, e.g.,
firewall, managed switch,
router, engineering
applications, operating
system, etc.
•
Review functionality to ensure unneeded features are turned
off or will not impact original design basis.
•
Review intended functionality changes in the context of risk
for the system affected.
•
Testing required to ensure new features that cannot be
disabled will not affect current design basis or operations
Flashable Instructions /
Firmware installation
•
Review additional functionality to ensure unneeded features
are turned off or will not impact original design basis.
•
Testing required to ensure new features that cannot be
disabled will not affect current design operations.
•
Review additional functionality to ensure unneeded features
are turned off or will not impact original design basis.
•
Testing may be required to ensure new features that cannot
be disabled will not affect current design basis or operation .
Replace Functionality
Enabling Previously
Disabled Features
3407
Access Changes
3408
3409
3410
3411
3412
3413
3414
3415
3416
3417
3418
3419
Access management is important to enforce least privilege, thus helping to minimize the attack
surface. Only persons who have a need to access specific systems and who are competent should
be allowed access. For example, not every control engineer should be allowed access to the SIS
engineering workstation while more control engineers would typically be granted permission to
access the BPCS workstation. Access management should have its own procedure as attempting
to manage this activity using the generalized MOC work process would be very inefficient. With in
the procedure, the responsibilities of those organizations that must work together should be
defined. Those organizations typically involved, includes operations, maintenance, electrical
engineering support, controls engineering support and human resour ces. From a least privilege
perspective, the specific job function represents a foundation for what access and to what level of
access rights one would have. Human resources should be involved as they should help manage
job function transfers as well as persons leaving the company or business area.
3420
15.2
3421
3422
3423
3424
3425
3426
3427
3428
3429
In this technical report, decommissioning represents a subset of management of change. For
smaller changes such as perceived replacement in kind, the MOC work process should ensure
that data be purged from the components being replaced. ISA 62443-2-1 requires that all data
requiring safeguarding are purged when the device is decommissioned or otherwise removed from
the IACS. With respect to control systems, ISA 62443-3-3 requires they have the capability to
purge all information for which explicit read authorization is supported from components that are
to be released from active service and/or decommissioned. Similarly, ISA 62443 -4-2 requires that
components provided by product suppliers have the c apability to erase all information, for which
explicit read authorization is supported, from components to be released from active service and/or
Decommissioning
ISA-TR84.00.09-2023
- 127 -
3430
3431
decommissioned. It is recommended that data purging be addressed with a procedure that details
required actions and who is accountable and responsible for execution of the procedure.
3432
3433
3434
ISA 62443-2-1 includes a requirement that procedures be established and audited with respect to
the addition, removal, and disposal of all assets. The decommissioning procedures shoul d include
(but not necessarily be limited to):
3435
3436
•
Device evaluation to determine if the device should be sanitized or if the data on the device
needs to be retained and transferred elsewhere within the company.
3437
3438
•
Procedures to transfer historian information (safety performance key indicators, incident
events, etc.).
3439
3440
3441
3442
•
Method of data destruction should be selected based on the data sensitivity (SL), e.g. ,
erasing/overwriting, degaussing (de-magnetizing), physical destruction, cryptographic
erase, etc. Transfer or re-use of the device is not recommended unless s anitization can be
fully validated.
3443
3444
•
Availability of decommissioning documentation, including device information, data
destruction / disposal method used, validation test availability for audit purposes.
3445
3446
When the changes impact the design of the controls ne twork, then decommissioning should
undergo a full SLC analysis.
3447
3448
3449
3450
If decommissioning is intended to shut down or remove all the facilities at a site, then cybersecurity
analysis is necessary once the exact method and timing for each decommissioning step is defined.
The resulting cybersecurity analysis may require revisiting and modification of previously
established method and timing for each decommissioning step.
3451
3452
3453
3454
Since decommissioning is an infrequent event, lack of experience in this process is common. Thu s,
an effort should be made to include all plant personnel familiar with the facility (for example,
operating, maintenance, management, engineering, controls, IT, safety) in the decommissioning
planning.
3455
3456
3457
3458
Before proceeding with decommissioning projects, all parties involved with this activity should fully
understand the scope and consider the potential cybersecurity issues addressed throughout the
lifecycle. The following will only list typical cybersecurity issues resulting from decommissioning to
help the reader to develop a proper decommissioning cybersecurity plan .
3459
3460
3461
3462
As-built information should be available before proceeding with any aspects of decommissioning
so that existing security level capabilities (SL-C), security protection ratings (SPR) and other
cybersecurity-related security measures, conduits, and zones are not compromised, and
decommissioning steps can be planned properly.
3463
3464
3465
While it is possible not all the SLC phases apply for any given decommissioning, each phase
should be considered. Listed below are the SLC phases providing simple decommissioning issues
often encountered that are related to that phase.
3466
3467
•
Hazard and Risk Assessment - The Hazard and Risk Assessment should identify risks
related to cybersecurity created through:
3468
3469
–
improper decommissioning
cybersecurity.
3470
–
loss of protection in zones, conduits, process control systems, or PSCAI systems.
3471
3472
3473
3474
–
impact of decommissioning on utilities (for example, electrical, steam, instr ument air)
that could impact the operability of programmable electronic devices used as
cybersecurity security measures (for example, overvoltage, under voltage, instrument
air pressure abnormality).
sequencing
resulting
in
loss
of,
or
reduction
of,
ISA-TR84.00.09-2023
–
3475
3476
- 128 -
the impact of new plant personnel and impact on existing plant personnel noted in the
introduction above.
3477
3478
3479
•
Allocation of security levels to security measures – The need for security measures will be
based on the results of the cyber risk analysis. This may include the addition of new security
measures or the modification of existing security measures.
3480
3481
3482
•
CRS for the cybersecurity security measures – Assuming either of the above two bullets
results in modifications to existing specifications documented in the existing CRS, the CRS
should be updated.
3483
3484
3485
3486
3487
3488
3489
•
Design and engineering of cybersecurity security measures – While the previous three
bullets can result in the need for design and engineering, an additional consideration
includes the temporary construction design and engineering requirements that may be
needed to maintain production of existing facilities safely and securely while
decommissioning is underway. This temporary construction may induce new cybersecurity
issues that should be addressed in the cyber risk assessment and subsequent steps as
needed.
3490
3491
3492
•
Design and development of other means of risk reduction – Loss of existing security
measures or need for additional security measures may require the design and
development of other means of cyber risk reduction.
3493
3494
•
Installation, commissioning, and validation – Any additional or modified cyber risk reduction
implementation should consider the need for installation, commissioning, and validation.
3495
•
Revalidation of access privileges given the changes to the system.
3496
•
Data sanitization of equipment removed.
3497
3498
3499
•
Operation and maintenance – Maintenance and operating procedures and training should
be put into effect if the implementations of earlier bullets noted above are determined to be
necessary.
3500
3501
3502
3503
3504
•
Competence of the people involved in decommissioning work is necessary to confirm all
participants have the necessary training and knowledge of the cybersecurity impact of the
decommissioning prior to performing these tasks. The membership of the assessment team
should include at least one senior competent person not involved in the project, e. g., design,
operation, and maintenance.
3505
3506
3507
3508
Based on the evaluated impact of the decommissioning, the tasks performed by personnel with
PSCAI lifecycle responsibilities may change. Training should be performed when modifications are
made to personnel responsibilities, work processes, procedures, or tools prior to the
decommissioning.
3509
15.3
3510
15.3.1 Purpose
3511
3512
3513
3514
3515
3516
The intent of the stage 5 assessment is to ensure a robust management of change program with
respect to cybersecurity and validation of assumptions made in the risk assessment are still
applicable. Once operations assume the responsibility for operation of the plant, execution of
individual MOC should occur for proposed changes. This is a requirement of Process Safety
Management regulations, e.g., OSHA 1910.119 subpart H, Process safety management of highly
3517
15.3.2 Input and Guidance
3518
3519
3520
The stage 5 assessment of the overall work process is recommended t o occur before or in
conjunction with the stage 4 assessment. Competent personnel should complete performance of
this assessment via an independent check. These persons should have both the knowledge and
Assessing the Stage 5 Work Process
hazardous chemicals.
ISA-TR84.00.09-2023
- 129 -
3521
3522
experience to judge both the completion of expected work and when applicable, the quality of such
work.
3523
The input for the stage 5 project assessment is
3524
3525
•
•
MOC documentation
MOC Approval documentation
3526
3527
•
•
Risk assessments for approved change
Other applicable baseline risk assessment reports
3528
•
MOC KPI records
3529
•
Current safety and risk assessment reports
3530
•
Current SPR-C verification report
3531
3532
3533
3534
3535
3536
3537
3538
3539
•
•
•
•
•
•
•
•
•
Cybersecurity requirements specification (CRS)
PHA / Risk assessment reports
Vulnerability assessments
Zone and conduit drawings
Configuration documentation
Security procedures
Operating procedures
Maintenance procedures
Other applicable design and / or procedural documents
3540
3541
•
•
Training records
Competency criteria and logs
3542
15.3.3 Output
3543
The result of stage 5 assessment is
3544
•
The relative maturity level of the current MOC work process as implemented and operated
3545
•
Recommendations for improvement as applicable.
3546
3547
An example checklist template to aid in this assessment is included in Annex B, Cyber security
Assessment Stage Check List Templates.
ISA-TR84.00.09-2023
- 130 -
Annex A - Maturity Level Assessment
3548
3549
Introduction
3550
3551
3552
3553
3554
3555
3556
The assessment of maturity can be performed to assess the current overall organizational
cybersecurity capability or to evaluate those organizational measures and procedures necessary
to support the effectiveness of technical measures that are an important component of the
determination of security protection ratings (SPR). This annex focuses on the contribution to SPR
determination, although it should be relatively easy to see how it can be applied to the entire CSMS.
There are several maturity models that can be found referenced in industry, but they tend to only
be slightly different. Table A.1 below illustrates the maturity levels.
ML
ML
ML
ML
ML
0
1
2
3
4
Assessment MLs
– Incomplete / Unaware
– Initial
– Managed
– Defined / Practiced
– Improving
3557
3558
3559
3560
3561
3562
3563
3564
Table A.1
Overall Assessment Work Process
1. Document applicable technical measures applicable to all zones
2. Document applicable technical measures applicable as a function of specific zones
3. Document organizational measures and procedures necessary to support specific
technical measures
4. Assess each organizational measure and procedure for its maturity level
5. Document the results
ISA-TR84.00.09-2023
3565
- 131 -
Maturity Level Assessment Procedure
Major Step
1. Document each
applicable
organizational measure
from ANSI/ISA 624432-1
2. Obtain information to
support measure
effectiveness
3. Evaluate policies and
procedures
Detailed steps
a. Identify required a technical
measure
b. Identify organizational measures
required to support technical
measure
c. If no more technical measures,
proceed to next step, otherwise
return to step 1a
a. Obtain policy and procedure
documentation
b. Obtain evidence of implementation
and ongoing sustainability
a. Review applicable policies and
procedures
b. Confirm content addresses measure
c. Confirm content adequately
addresses requirements specified by
the measure
Notes
Information can include but not limited to:
• Policies
• Standards
• Procedures
• Work Practices
• Architecture Drawings
• Zone and Conduit Drawings
• Data flow diagrams
• Asset inventory records
• Inspection and test results
• Assessment Result (vulnerability, risk, audit, etc.)
• FAT, SAT documentation
• MOC records
• Available KPI records
• Training Curricula
• Training records
• Incident response plan; Disaster recovery plan;
Business continuity plan
• Incident plan test records (tabletop test records)
• Incident records;
For ML 1 the organization may be able to present some
policies, processes, or procedures. These may range from a
quick outline of steps to extremely well-written documents.
For well-written documents, it may be determined through
personnel interviews that the documents may be flawed or
not followed based upon personnel experience. Personnel
interviews may reveal that personnel side-step documented
ISA-TR84.00.09-2023
- 132 -
procedures to perform certain expected actio ns related to
their job.
For ML 2 the organization will be able to produce generally
well-written policies, procedures, and practices for most
situations or aspects of this area of cyber security.
Personnel will be able to find the policies, procedures, an d
practice documentation relatively easy. Personnel will be
able to show that policies, procedures, and practices are
being followed under normal circumstances.
For ML 3 the organization will be able to produce well-written
and consistent policies, procedures, and practices for cyber
security. Personnel will be able to easily identify and find the
policies, procedures, and practices documentation.
Personnel will be able to show that policies, procedures, and
practices are being followed under both normal an d adverse
circumstances.
4. All measures evaluated
5. Evaluate training
6. All training materials
and records evaluated
7. Confirm implementation
of the policies and
procedures
8. All measures confirmed
for implementation and
use
a. If YES, proceed to next step
b. If NO, repeat step 3 for next
measure
a. Review personnel training material
with respect to the applicable
policies and procedures for each
measure
b. Review personnel training records
a. If YES, proceed to next step
b. If NO, repeat step 5
a. Interview personnel responsible for
security measure(s)
b. Confirm the actions taken
correspond to the policies and
procedures
c. Evaluate consistency among
interviews
d. Review KPI’s
a. If YES, proceed to next step
b. If NO, repeat step 7 for next
measure
Training should account for anyone who is to execute the
procedures, e.g., employees and contractors
Be on the lookout for short cuts and flaws in the
procedure(s).
When interviewing individual personnel have them describe
the actions they perform.
Following the interviews analyze the notes to determine if
actions by different personnel are consistent or not.
For ML 3 It is apparent that groups of pers onnel perform
their tasks consistently based upon their training.
Documentation should include training material that
personnel can identify related to this area of cyber security.
ISA-TR84.00.09-2023
9. Assign maturity level
10. All measures assigned
an ML
11. Document results
3566
- 133 -
a. Use Table A.2 to assist assigning
ML for each measure
a. If YES, proceed to next step
b. If NO, repeat step 9 for next
measure
a. Distribute results to applicable
stakeholders
Select ML where the evidence most closely aligns with the
stated ML attributes
ISA-TR84.00.09-2023
3567
- 134 -
Security Program Maturity Level Assessment Attributes
3568
Table A.2
Assessment
MLs
ML 0 –
Incomplete
ML Attributes
•
•
•
ML 1 – Initial
•
•
•
•
•
•
•
•
ML 2 – Managed
•
•
•
•
•
•
•
Documented policy and procedures are not available or not applicable
to task
Processes are either undocumented or not fully documented.
There is an over reliance on personnel to make up gaps in policies and
procedures in the performance of these actions or procedures.
The organization has demonstrated that they are performing some
actions / work processes and have some policies and procedures in
place related to cyber security.
Policies and procedures that exist may be available to employees.
Policies utilize ad-hoc assessment of risk and implementation.
The organization may also have well documented procedures and
processes, but personnel do not follow them consistently under normal
circumstances.
Individual personnel carry most of the burden to perform procedures
based upon their expertise. Personnel count on tr ibal knowledge
and/or direct sharing to pass along processes.
Technical solutions may have been implemented; however, they are
either not implemented consistently or not implemented in an industry
accepted or recommended way.
There is no formal training program for organizational procedures other
than some form of “On the Job” training under more experienced
personnel.
When personnel leave, there is often a loss of knowledge that cannot
be easily regained.
Policies and procedures written to cover most of the major facilities
and operations companywide or for a specific asset.
Policies delineate the IT / OT security management structure and
clearly assign ownership, compliance requirements and responsibilities
for most aspects.
Most policies are approved by key affected parties
Most policies identify specific penalties and disciplinary actions to be
used if the policy is not followed.
Organization has written policies, procedures, and practices for most
of their activities related to cyber security, and personnel mostly follow
them under normal circumstances.
There may be some policies, procedures, or practices that are either
undocumented or poorly documented, however, those are limited.
Policies, procedures, and practices may be written or implemented
differently throughout the organization.
The organization has information that demonstrates they are
performing most of the actions and have most of the procedures in
place related to this area of cyber security for use under normal
circumstances.
ISA-TR84.00.09-2023
•
•
•
•
•
•
•
•
•
•
•
•
•
•
- 135 -
Procedures clarify where the procedure is to be performed, how the
procedure is to be performed, when the procedure is to be performed,
who is to perform the procedure, and on what the procedure is to be
performed.
Procedures clearly define security responsibilities and expected
behaviors for
o Functional managers
o Process control engineers
o SIS engineers
o Control technicians
o Electrical engineers
o Electrical technicians
o Network engineers
o IT specialists
o Human Resources personnel
o Contractors
o System integrators
o Maintenance service providers
o Process safety personnel
o Security administrators
Under adverse conditions, the organization may not follow policies,
procedures, or practices completely or may use unwritten policies,
procedures, and practices to accomplish necessary tasks.
Procedures include contacts for further information, guidance, and
compliance
Procedures are generally communicated to individuals who are
required to follow them
There may be cases where policies, procedures, and practices have
been developed, but have never been tested in practice.
Organization has implemented some technical solutions at this level.
The technical solutions generally follow industry accepted or
recommended practices, although there may be differences in the
implementation throughout the organization.
The organization follows vendors, industry accepted, and
recommended practices or has a technical documented basis for
exceptions with regards to cyber security for most of the technology.
Personnel generally know their responsibilities and are trained to
perform their tasks related to cyber security.
When onboarding new personnel, some dedicated materials provided
to acquaint them with their responsibilities and tasks related to cyber
security.
Personnel transferring from other parts of the organization are
retrained on policies, procedures, and processes associated with the
new assignments
Personnel are expected to document their experiences and procedures
as a part of their job to institutionalize/codify tribal k nowledge.
Some tasks are still relayed from one person to another or understood
through experience.
ISA-TR84.00.09-2023
ML 3 –
Defined/Practiced
•
•
•
•
•
•
•
•
•
•
•
•
•
•
ML 4 – Improving
•
•
•
•
- 136 -
All of policies, procedures, and practices are fully documented and in
place related to each area of cyber security for use under both normal
and adverse circumstances.
Work processes, procedures and work practices are performed
consistently across the entire organization.
Verification and validation (e.g., Audits, Assessments, Tests, KPIs) are
routinely conducted to evaluate the adequacy and effectiveness of all
implementations.
Verification and validation ensure that all policies, procedures, and
controls are acting as intended and that they ensure the appropriate
security protection rating as a function of each defined zone.
Effective correction actions are taken to address iden tified
weaknesses, including those identified because of potential or actual
cyber security incidents, alarms, and alerts issued by industry sources,
vendors, and other trusted sources.
Evaluation requirements, including requirements regarding the type
and frequency of verification and validation, are documented,
approved, and effectively implemented.
The frequency and rigor with which individual controls are verified and
validated depend on the risks that will be posed if the controls are not
operating effectively.
Personnel know their roles and responsibilities and are trained to
perform their tasks related to cyber security.
When onboarding new personnel, they are required to spend time
reading and reviewing content describing their responsibilities and how
they will conduct the tasks related to their role.
Personnel transferring from other parts of the organization do not have
to be retrained on cyber security policies, procedures, or practices as
they are consistent throughout the organization.
Personnel are expected to relay experience from one person to
another through written documentation.
Technical solutions follow industry accepted or recommended
practices and are consistently applied throughout the entire
organization.
Exceptions to vendors, industry accepted, and recommended practices
have a documented basis with regards to cyber security.
Some of the technical solutions used by the organization may be
industry leading and/or implemented in a way to account for future
improvements.
All policies, procedures, and practices are professionally written,
consistent, in place and communicated to the organization related to
cyber security for use under both normal and adverse circumstances.
Organization has an active process in place to periodically review,
evaluate, and improve policies, procedures, and practices based on
changes in the organization, suggestions from personnel, changes in
the threat environment, and other collected information.
Cyber security is an integral part of overall risk management practices
(IT/OT/Safety/Financial/HR/Physical Security/O&M).
Key Performance Indicators for the security program are established,
measured, and continually improved.
ISA-TR84.00.09-2023
•
•
•
•
•
•
•
•
- 137 -
Threats and vulnerabilities are reevaluated whenever relevant, a nd
controls adapted as applicable.
Personnel know their roles and responsibilities and are trained to
perform their tasks related to cyber security.
When onboarding new personnel, they will be required to spend time
reading and reviewing content describing their responsibilities and how
they will conduct the tasks related to their role.
Personnel transferring from other parts of the organization will not
have to be retrained on cyber security policies, procedures, or
practices.
Personnel are encouraged to mentor and teach others as they perform
their tasks, including looking for ways to improve those tasks and
feeding that information back to improve policies, procedures,
practices, and training materials.
Technical solutions are deployed throughout the entire organization in
a consistent way and may be considered industry leading.
Exceptions to vendors, industry accepted, and recommended practices
have a documented basis with regards to cyber security.
Organization provides feedback to vendors, industry groups, standards
organizations, etc. on improvements that can be made to the
technology itself or the implementation of the technology.
3569
ML Assessment Documentation
3570
3571
3572
When conducting a ML assessment in the support of SPR determination, the result will be an as
found picture of the organization’s cyber security capability as it relates to effectiveness of
technical measures.
3573
3574
3575
3576
3577
One way to view the results of a ML assessmen t are to plot them on a radial diagram. This allows
each of the groupings to be shown along with their rating from 0 -4 in an easily visible graphical
format. It could also be shown in a bar chart or some other graph, however, the radial diagram has
seemed to represent the most accepted format for this type of maturity assessment rating. A
fictional example using the SPEs from the latest draft of ISA/IEC 62443 -2-1 is shown in Figure A..
ISA-TR84.00.09-2023
- 138 -
Example Maturity Level Assessment Based Upon Draft
62443-2-1
SPE 1 - Organizational
Security Measures
4
SPE 8 - System Integrity
SPE 2 - Configuration
3
and Availability
Management
2
1
SPE 7 - Event and Incident
SPE 3 - Network and
0
Management
Communication Security
SPE 6 - User Access
Control
SPE 4 - Component
Security
SPE 5 - Protection of Data
3578
3579
Figure A.1 – Example ML Assessment Based Upon Draft 62443-2-1
3580
3581
3582
3583
The results of the ML assessment can also serve as in an input to a roadmap for improving the
cyber security organization capability over time. A roadmap can describe the steps necessary for
the organization to move from where they are to where they want to be. Making use of appropriate
key performance indicators based upon current ML can assist implementation of a roadmap.
3584
ISA-TR84.00.09-2023
3585
- 139 -
Annex B - Cyber security Assessment Stage Check List Templates
ISA-TR84.00.09-2023
- 140 -
3586
Cybersecurity Assessment (CSSA) 1 Check List
3587
Cybersecurity Stage Assessment (CSSA) 1
3588
Project / Location: _________________________________
3589
Prepared by: _____________________________________ Date: __________________
3590
3591
Approval: ________________________________________
3592
3593
Acceptance: ______________________________________
Engineering Team Representative
Operations Representative
3594
Question
Typical Information to Review
•
•
Training records
Competency criteria and logs
3. IACS segmented into zones and conduits.
•
•
•
•
Risk Management Procedure
Hazards Assessment Procedure
Report and worksheets
Zone and conduit drawing(s)
4. Each zone and conduit assigned a security
protection rating target (SPR-T) value.
•
•
5. Safety requirements specification (SRS) and
cybersecurity requirement specification
(CRS) adequately documented.
6. Does the SRS and CRS reflect the process
design requirements?
•
•
Zone and conduit drawing(s)
Detailed level cyber risk
assessment
SRS
CRS
1. Does a competency log exist for personnel
involved in the PHA, LOPA, cyber risk
assessments, SRS, and CRS?
2. Performance and documentation of detailed
level cyber risk assessment.
7. Does the SRS and CRS reflect the
operational / business area requirements?
•
•
•
•
•
•
•
Controls Philosophy
SRS
CRS
Maintenance philosophy
Reliability & availability
philosophy’s
SRS
CRS
Pass
/ Fail
/ NA
Recommendation
ISA-TR84.00.09-2023
- 141 -
Question
8. Project specification adequate for detailed
design to proceed
Typical Information to Review
•
•
•
•
•
•
•
•
•
•
•
•
•
•
3595
Asset inventory
Process Safety Information
P&ID’s
Architectural Drawings
Zone & Conduit Drawings
System diagrams
SIFs and safeguards assigned to
layers of protection
HAZOP worksheets / report
LOPA worksheets / report
Data flow analysis report
Vulnerability assessment
Detailed level cyber risk
assessment
Safety Requirements
Specification
Cybersecurity Requirements
Specification
Pass
/ Fail
/ NA
Recommendation
ISA-TR84.00.09-2023
- 142 -
3596
Cybersecurity Stage Assessment (CSSA) 2 Check List
3597
Cybersecurity Stage Assessment (CSSA) 2
3598
Project / Location: _________________________________
3599
Prepared by: _____________________________________ Date: __________________
3600
3601
Approval: ________________________________________
3602
3603
Acceptance: ______________________________________
Engineering Team Representative
Operations Representative
3604
Question
Typical Information to Review
1. Does a competency log exist for personnel
involved in the involved in the detailed
design activities for the SIS and IACS
security?
•
•
Training records
Competency criteria and logs
2. Are Control System Architecture Diagrams
available?
•
Control System Architecture
Diagrams
3. IACS’s hardware system layout designed
and documented?
•
Hardware system layout drawings
4. Has lack of cybersecurity IPL independence
been identified and addressed in the detailed
level cyber risk assessment?
•
•
•
HAZOP worksheets
LOPA, fault trees, etc.
Detailed level cyber risk
assessment report
5. Detailed level cyber risk assessment Action
items resolved.
•
•
•
•
Risk Management Procedure
Hazards Assessment Procedure
Report and worksheets
Recommendation closeout
documentation
6. Requirements documented for each zone
and conduits.
•
•
Zone and conduit drawing(s)
CRS
Pass
/ Fail
/ NA
Recommendation
ISA-TR84.00.09-2023
- 143 -
Question
Typical Information to Review
7. Configuration requirements documented for
firewalls and managed switched
•
Configuration standards and
specifications
8. Control platform specification documented
•
Control platform specification
9. Instrument & Valve Specifications
documented.
•
Instrument & Valve Specifications
10. Control system network devices specified
(e.g., firewalls, routers, switches, etc.
•
Network device specifications for
use in levels 0 through the DMZ
11. Do Security Manuals exist for equipment in
each zone?
•
•
•
Asset inventory
Zone & conduit drawings
Manufacturer security manuals
12. Security manual requirements incorporated
into the mechanical integrity program for the
IACS SIS and security zones.
•
•
13. Have FAT, SAT, and validation procedures
been developed and documented?
•
Manufacturer security manuals
Mechanical integrity program
procedures
FAT/ SAT specification and
procedures
FAT Integration Procedures
Site Integration Test Procedures
Commissioning procedures
Pre-validation checklist and
validation procedures
14. Has a security protection rating (SPR)
verification been performed for all zones
•
•
Zone & conduit drawings
SPR-C verification report
15. Has the security manual requirements been
incorporated into the design and reflected in
SPR-C verification?
•
•
•
•
Asset inventory
Zone & conduit drawings
Manufacturer security manuals
SPR-C verification report
16. Cybersecurity change management
procedures implemented
•
•
•
MOC procedures
Patch management procedures
Vulnerability management
procedures
•
•
•
•
Pass
/ Fail
/ NA
Recommendation
ISA-TR84.00.09-2023
- 144 -
Question
17. Design documentation adequate to proceed
to procurement, construction, installation,
and pre-startup activities.
Typical Information to Review
•
Asset inventory
•
Process Safety Information
•
P&ID’s
•
Architectural Drawings
•
Zone & Conduit Drawings
•
System diagrams
•
SIFs and safeguards assigned to
layers of protection
•
Safety Requirements
Specification
Cybersecurity Requirements
Specification
FAT/SAT specification and
procedures
Commissioning procedures
Validation procedures
Configuration requirements
•
•
•
•
•
3605
Pass
/ Fail
/ NA
Recommendation
ISA-TR84.00.09-2023
- 145 -
3606
Cybersecurity Stage Assessment (CSSA) 3 Check List
3607
Cybersecurity Stage Assessment (CSSA) 3
3608
Project / Location: _________________________________
3609
Prepared by: _____________________________________ Date: __________________
3610
3611
Approval: ________________________________________
3612
3613
Acceptance: ______________________________________
Engineering Team Representative
Operations Representative
Question
Typical Information to Review
•
Project Design Change Tracking
documentation
2. Recommendations arising from the hazard
and risk assessments been implemented or
resolved?
•
•
•
•
3. Have the recommendations arising from any
prior assessment stage been resolved?
•
•
•
HAZOP worksheets / report
LOPA worksheets / report
Data flow analysis report
Detailed level cyber risk
assessment
Stage 1 assessment report
Stage 2 assessment report
Vulnerability assessments
1. Are project design change procedures in
place and been properly implemented?
4. Current vulnerability assessment issues
resolved
5. Is the design, construction, and installation of
the IACS in accordance with the SRS and
CRS, with any differences identified and
resolved?
6. Does information support both safety and
security during operation and provide a basis
for management of change?
•
•
•
•
•
•
•
•
•
•
•
•
SRS
CRS
Control system architecture
drawings
Zone and conduit drawings
Configuration documentation
Asset Inventory
C&E matrix drawing(s)
P&ID’s
Zone and Conduit drawing(s)
HAZOP worksheets / report
LOPA worksheets / report
Data flow analysis report
Pass
/ Fail
/ NA
Recommendation
ISA-TR84.00.09-2023
- 146 -
Question
Typical Information to Review
•
•
•
•
•
•
•
7. Are the safety, operating, maintenance and
emergency procedures pertaining to the
IACS safety systems and security in place?
8. Has an automation asset integrity program
been developed and implemented for the
IACS safety and security systems?
9. Completion of all action items from
FAT/SAT?
•
•
•
•
•
•
Inspection and test procedures
Patching procedures
Key performance indicators that
are implemented
FAT documentation and action
items
FAT Integration Test results and
action items
Site Integration Test results and
action items
SAT documentation and action
items
Commissioning documentation
Pre-validation checklist results
•
Validation documentation
•
Change management policy,
standards, and procedures
•
Employee training records
•
•
•
•
10. Completion of commissioning for the IACS
safety and security systems with no
outstanding action items?
11. Was the validation planning appropriate and
the validation activities been completed?
12. Does the management of change (MOC)
program include the IACS safety systems
and security concerns?
13. Has employee training for personnel
responsible for operations, as well as design
Vulnerability assessment
Detailed level cyber risk
assessment
SRS
CRS
Configuration documentation
SIL verification report
Security protection rating (SPR)
verification report
IACS safety system and security
operating, maintenance, and
emergency procedures
Pass
/ Fail
/ NA
Recommendation
ISA-TR84.00.09-2023
- 147 -
Question
Typical Information to Review
and maintenance support been completed
and appropriate?
14. Does a competency log exist for personnel
involved in the commissioning,
FAT/SAT/initial validation of the IACS?
15. Has operation and maintenance and
management information necessary to
support the of the IACS safety systems and
security been provided to the maintenance
and operating personnel?
•
Competency criteria and logs
•
•
•
•
Asset inventory
IACS safety system and security
operating, maintenance, and
emergency procedures
C&E matrix drawing(s)
P&ID’s
Zone and Conduit drawing(s)
HAZOP worksheets / report
LOPA worksheets / report
Data flow analysis report
Detailed level cyber risk
assessment
SRS
CRS
SIL verification report
Security protection rating (SPR)
verification report
SRS
CRS
•
Action item documentation
•
Action item documentation
•
Plans or strategies for
implementing further assessment
stages.
•
•
•
•
•
•
•
•
•
•
•
16. Has configuration of the maintenance
management system included periodic
inspection and testing in accordance with the
SRS and CRS?
17. Have all mandatory prior to start up action
items been resolved and closed out?
18. Does plan exist for resolving the nonmandatory?
19. Have further assessment stage plans or
strategies been developed and provided to
operations?
3614
Pass
/ Fail
/ NA
Recommendation
ISA-TR84.00.09-2023
- 148 -
3615
Cybersecurity Stage Assessment (CSSA) 4 Check List
3616
Cybersecurity Stage Assessment (CSSA) 4
3617
Project / Location: _________________________________
3618
Prepared by: _____________________________________ Date: __________________
3619
3620
Approval: ________________________________________
3621
3622
Acceptance: ______________________________________
Engineering Team Representative
Operations Representative
3623
Question
Typical Information to Review
1. Does a competency log exist for personnel
involved in the performance of inspection
and testing as part of the automation asset
integrity program for the IACS security
design, operation, and configuration?
•
•
Training records
Competency criteria and logs
2. Cyber incidents and events recorded.
•
Near miss, event, and incident
records
3. Are the inspection and testing procedures
current, and correct?
•
Security related maintenance
procedures
4. Have the data as required by OSHA PSM
(e.g., as found, as left) been documented as
part of each proof test and response to a
failed state?
•
•
•
Maintenance records
SIS/SIF work orders
Diagnostic alarms
5. Management of changes documented
•
•
MOC records
Detailed level cybersecurity risk
assessment report
6. Have any changes involved the design or
operation of the IACS security?
•
MOC records
7. For each MOC involving the IACS security,
have the associated documentation been
updated?
•
•
•
CRS
Asset inventory
Architectural drawings
Pass
/ Fail
/ NA
Recommendation
ISA-TR84.00.09-2023
- 149 -
Question
Typical Information to Review
•
•
•
•
•
Zone and conduit drawings
Detailed design drawings &
specifications
Security procedures
Inspection and test procedures
Associated training
8. Does Obsolescence plan exist?
•
Obsolescence plan
documentation
9. Is the standard for bypassing up to date,
including network security devices?
•
Bypass policy and procedures
10. When network security devices are
bypassed, are dates and durations
documented?
•
Bypass logs
11. Detailed level cybersecurity risk assessment
revalidated.
•
Detailed level cybersecurity risk
assessment report
12. Configuration tools (level 0 to DMZ) included
in risk assessment.
•
Detailed level cybersecurity risk
assessment report
13. Has a review of the demand history, repair
data, bypass and proof test data validated
assumptions used to determine SPR-C?
•
•
•
•
•
•
Near miss, event, and incident
records
Applicable KPIs
Repair data records
Inspection and test records
Bypass logs
SPR-C verification report
14. Validation of SPR-C assumptions performed
for all applicable zones.
•
•
SPR-C verification report
Zone and conduit drawings
15. All recommendations resulting from
revalidation properly resolved.
•
Revalidated detailed level
cybersecurity risk assessment
report
Recommendations from report
•
Pass
/ Fail
/ NA
Recommendation
ISA-TR84.00.09-2023
- 150 -
Question
Typical Information to Review
•
3624
Recommendation closure
documentation
Pass
/ Fail
/ NA
Recommendation
ISA-TR84.00.09-2023
- 151 -
3625
Cybersecurity Stage Assessment (CSSA) 5 Check List
3626
Cybersecurity Stage Assessment (CSSA) 5
3627
Project / Location: _________________________________
3628
Prepared by: _____________________________________ Date: __________________
3629
3630
Approval: ________________________________________
3631
3632
Acceptance: ______________________________________
Engineering Team Representative
Operations Representative
3633
Question
Typical Information to Review
1. Does a competency log exist for personnel
involved in the performance of the Change
Management work process with respect to
cybersecurity?
•
•
Training records
Competency criteria and logs
2. Proposed changes reviewed versus risk
applicable assessments
•
Risk assessment of proposed
change
Other applicable baseline risk
assessment reports
•
3. Are current practices in accordance with
Equipment Manufacturer Security Manuals?
•
Equipment security manuals
4. Are current practices in accordance with
Equipment Manufacturer Safety Manuals?
•
Equipment safety manuals
5. Has there been any MOC or identification of
a deficiency that would requires updating the
CRS to be updated? If so, is the CRS
current, and correct?
•
•
•
CRS
MOC documentation
Revalidated detailed level
cybersecurity assessment
6. Has there been any changes that would
require an update of the SPR-C
verification(s)? If so, is it current, and
correct?
•
•
Updated CRS
Revalidated detailed level
cybersecurity assessment
Updated SPR-C verification report
•
Pass
/ Fail
/ NA
Recommendation
ISA-TR84.00.09-2023
- 152 -
Question
7. All documentation (e.g., risk assessment,
design, Operating and maintenance
procedures, drawings, etc.) updated
Typical Information to Review
•
•
•
•
•
•
•
•
•
•
Asset inventory
Cybersecurity requirements
specification (CRS)
PHA / Risk assessment reports
Vulnerability assessments
Zone and conduit drawings
Configuration documentation
Security procedures
Operating procedures
Maintenance procedures
Other applicable documents
8. Revised training performed prior to
implementation of change.
•
Training records
9. All changes approved by competent
personnel prior to implementation of change.
•
•
Approval documentation
Competency logs
10. Data has been Purged from decommissioned
devices?
•
Device decommissioning records
3634
Pass
/ Fail
/ NA
Recommendation
ISA-TR84.00.09-2023
- 153 -
3635
Annex C – Vulnerability Identification Methodologies
3636
3637
3638
3639
3640
For a threat to be realized, it is necessary to exploit one or more vulnerabilities in one or more
assets or procedures. Vulnerability identification should be considered a subset of risk assessment.
Some vulnerabilities can be identified prior to a detailed level cyber risk assessment and used as
an input, while other vulnerabilities may be identified during the risk assessment, and still others
identified later in the lifecycle, once the IACS solution is physi cally available or in operation.
3641
3642
3643
3644
3645
3646
3647
3648
3649
Understanding those vulnerabilities that can be identified prior to a detailed cybersecurity risk
analysis is an important input for the risk analysis. These vulnerabilities help determine likelihoods
for various threat scenarios during the risk assessment workshop. This type of vulnerability
assessment is best performed prior to convening the risk assessment team to perform their
assessment as the composition of the personnel performing those assessments is often quite
different than those in the actual risk assessment workshop. It should also be acknowledged that
even when vulnerability assessments are performed prior to the risk assessment, which does not
preclude other vulnerabilities being identified during the risk ass essment, and even after the risk
assessment, e.g., FAT, SAT, initial validation, revalidation.
3650
This annex documents several distinct types of vulnerability assessments that may be performed.
3651
3652
3653
This annex does not include vulnerability identification that typically is identified during detailed
level cyber risk assessments, e.g., CHAZOP, FMEA, Cyber PHA’s, function -based risk
assessments etc.
ISA-TR84.00.09-2023
3654
- 154 -
Vulnerability Identification Methods Overview
Methodology Title
Applicability
C.1: Device technical
capability gap
analysis
•
C.2: Device
vulnerability
(Software and
firmware flaw)
identification
C.3: System
technical capability
gap analysis
C.4: Procedural
capability gap
analysis
Vulnerability Identification
Input for Detailed
Cybersecurity Risk
Assessment
C.5: IACS network
vulnerability
identification
C.6: System
integration
vulnerability
identification
FAT, SAT, Initial
Validation, Periodic
Revalidation
Methodology strengths
Methodology weaknesses / limitations
Documents capabilities as a function of
security level allowing user to consider
compensating security measures where
gaps exist
No guidance for potential compensating
security measures
Means to assess criticality and urgency •
to address vulnerabilities of assets in the
inventory of the asset owner.
Zero-day exploits (i.e., a software
compromise that has not yet been
reported or discovered) will not be
identified.
Documents capabilities as a function of
security level allowing user to consider
compensating security measures where
gaps exist
No guidance for potential compensating
security measures
Documents whether organizational
procedures required for technical security
measures to be effective are in place
•
Requires additional maturity level
assessment to determine expected
level of performance and
sustainability of implemented
procedure
•
Ultimately requires mapping of
organizational procedures to specific
technical measures
•
Decreases likelihood or magnitude of•
engineering changes following initial
cyber risk assessment.
•
Can help to define boundaries of
ownership and who is responsible for
various procedures.
•
Brain storming allows thinking freely.
•
Measures conformance to
requirements allowing fixes to be
made prior to process being at risk
Review is not generally performed using
a methodical procedure and may miss
some things that will need to be picked
up during detailed cyber risk assessment.
•
Requires competent personnel to
perform and in some cases,
personnel who are highly specialized,
e.g., penetration testing
ISA-TR84.00.09-2023
Methodology Title
3655
- 155 -
Applicability
Methodology strengths
•
Opportunity to identify vulnerabilities
overlooked or unknown during
previous assessments
•
Opportunity to identify vulnerabilities
missed after some period of operating
experience as well as new, previously
unknown vulnerabilities
Methodology weaknesses / limitations
ISA-TR84.00.09-2023
- 156 -
3656
C.1 Device technical capability gap analysis
3657
Summary
Annex Type
Methodology / Sample Template
Methodology
applicability
Input to Detailed Cybersecurity Risk Assessment
Methodology objective
The goal is to perform a security level capability assessment
versus the requirements in ANSI/ISA 62443-4-2.
3658
3659
Methodology description / procedure
3660
3661
3662
3663
The assessment identifies gaps in device technical capabilities relative to the security level target
of the zone where these devices are intended to be deployed by the asset owner. Understanding
the capabilities of the equipment help to perform system level assessments based on ANSI/ISA
62443-3-3.
3664
3665
3666
3667
3668
3669
3670
The easiest way to identify these gaps is to rely on the device ANSI/ISA 62443-4-2 certification,
should the level of detail resulting from this assessment be made available. Unfortunately, security
certifications to ISA 63443-4-2 typically only provide a single SL-C rather than the result of each
requirement, essentially making the certification useless for technical design and operational
procedures by the asset owner. This is problematic, because it is difficult to find a device having
a SL-C greater than 2 when in the process industry with the potential for major consequences, a
SL-T of 3 and 4 may be required.
3671
Otherwise, the procedure consists of:
3672
3673
3674
3675
3676
1. Determine and document whether specific requirement being investigated is applicable or
not
2. If not applicable document NA in pass/fail column and document rationale in
Evidence/Notes column.
3. If applicable, gather and document evidence of compliance. This can be obt ained through:
3677
3678
a. Documentation review (product manual, installation guide, existing literature on the
topic)
3679
b. Interviews with people familiar with the devices
3680
c. Functional tests
3681
3682
3683
3684
3685
3686
3687
d. Discussions with the manufacturer (Determine if guidance for management of and
maintenance of those procedures necessary for technical requirement to be
effective is available)
e. Evaluate evidence and document whether pass, fail, or not applicable (This
evaluation would generally involve a manufacturer’s threat modeling assessment of
the device’s SL-C)
3688
Figure C.1 provides an excerpt of an example worksheet template.
ISA-TR84.00.09-2023
- 157 -
3689
Req ID
Pass /
Fail
Reference Name
FR 1 – Identification and authentication
control
CR 1.1
Human user
identification and
authentication
3690
3691
3692
CR 1.1 (1)
Human user
identification and
authentication
CR 1.1 (2)
Human user
identification and
authentication
Requirement Description
Components shall provide the
capability to identify and authenticate
all human users according to
ISA-62443-3-3 SR 1.1 on all interfaces
capable of human user access. This
capability shall enforce such
identification and authentication on all
interfaces that provide human user
access to the component to support
segregation of duties and least
privilege in accordance with applicable
security policies and procedures. This
capability may be provided locally by
the component or by integration into a
system level identification and
authentication system.
SL-1
Y
Unique identification and
authentication. Components shall
provide the capability to uniquely
identify and authenticate all human
users.
Multifactor authentication for untrusted
interface. Components shall provide
the capability to employ multifactor
authentications for all human user
access to the component.
Figure C.1
Device SL-C Assessment Worksheet
Example Excerpt
SL-2
SL-3
SL-4
Y
Y
Y
Y
Y
Y
Y
Y
Assessment
Evidence / Notes
ISA-TR84.00.09-2023
- 158 -
3693
C.2 Device vulnerability (Software and firmware flaw) identification
3694
Summary
Annex Type
Methodology
Methodology
applicability
Device selection / Input to Detailed Cybersecurity Risk
Assessment / Security check as part of PSSR / Input to patching
program work process
Methodology objective
To identify flaws in programmable or configurable device software
that can be exploited by threat agents so that appropriate action
(e.g., install patch, employ compensating security measure, et c.)
may be taken to ensure security objectives are being met.
3695
3696
Methodology description / procedure
3697
3698
3699
3700
3701
3702
3703
3704
Numerous sources of information and tools exist regarding known and common vulnerabilities in
IACS, such as the industrial control system computer emergency response team (ICS-CERT)
database, NVD database, CVE database, etc. which can be used to look up and document existing
vulnerabilities for the proposed asset inventory. It should be recognized by asset owners that
software vulnerabilities can also be inherited from software components used in the product. To
allow a more thorough identification of vulnerabilities, device manufacturers a complete “ Software
Bill of Materials” (SBOM), listing all the external software components used and their version
should be obtained from the manufacturer. A generic procedure is to:
3705
3706
3707
3708
3709
3710
3711
3712
3713
3714
3715
3716
3717
•
•
•
•
•
•
•
•
Identify device(s) and software to be evaluated
Access on-line databases (e.g., ICS-CERT, NVD, CVE)
Search the databases (Databases will typically provide searching tips)
Refine database search as necessary
Evaluate results for vulnerabilities of concern
Document potential mitigations for implementation consideration
Repeat search and document steps until all vulnerabilities of concern have been evaluated
for potential mitigations
Document potential mitigation plan for consideration
ISA-TR84.00.09-2023
- 159 -
3718
C.3 System technical capability gap analysis
3719
Summary
Annex Type
Methodology / Sample Template
Methodology
applicability
Input to Detailed Cybersecurity Risk Assessment
Methodology objective
The goal is to perform a security level capability assessment
versus the requirements in ANSI/ISA 62443-3-3.
3720
Methodology description / procedure
3721
3722
3723
3724
3725
According to ISA62443-3-2, zone and conduit documentation is one of the requirements p rior to performing a detailed cyber security
risk assessment. One of the outputs from the initial risk assessment can be the assignment of SL -T for both devices and zones. Once
a zone has been assigned a SL-T, a vulnerability assessment can be performed to measure the applicable requirements in ANSI/ISA
62443-3-3 versus the technical measures that either exist or are proposed in a design scope. This activity would provide the SL -C for
each zone.
3726
The procedure consists of:
3727
3728
3729
1. Determine and document whether specific requirement being investigated is applicable or not
2. If not applicable document NA in pass/fail column and document rationale in Evidence/Notes column.
3. If applicable, gather and document evidence of compliance. This can be obtained through:
3730
a. Documentation review (compliance with product manual, security manual, installation guide, configuration requirements)
3731
b. Interviews with people familiar with the implementation of the system
3732
3733
3734
3735
c. Functional tests
4. Evaluate evidence and document whether pass, fail, or not ap plicable
Figure C.2 provides an excerpt of an example worksheet template.
Req ID
Pass /
Fail
Reference Name
FR 1 – Identification and authentication control
Requirement Description
SL-1
SL-2
SL-3
SL-4
Assessment
Notes
ISA-TR84.00.09-2023
3736
3737
3738
3739
3740
- 160 -
SR 1.1
Human user
identification and
authentication
The control system shall provide the
capability to identify and authenticate
all human users. This capability shall
enforce such identification and
authentication on all interfaces which
provide human user access to the
control system to support segregation
of duties and least privilege in
accordance with applicable security
policies and procedures.
SR 1.1 (1)
Human user
identification and
authentication
Unique identification and
authentication.
The control system shall provide the
capability to uniquely identify and
authenticate all human users.
CR 1.1 (2)
Human user
identification and
authentication
Multifactor authentication for untrusted
networks
The control system shall provide the
capability to employ multifactor
authentication for human user access to
the control system via an untrusted
network
CR 1.1 (3)
Human user
identification and
authentication
Multifactor authentication for all
networks
The control system shall provide the
capability to employ multifactor
authentications for all human user
access to the control system.
Figure C.2
Zone SL-C Assessment Worksheet
Example Excerpt
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
ISA-TR84.00.09-2023
- 161 -
3741
C.4 Procedural capability gap analysis
3742
Summary
Annex Type
Methodology / Sample Template
Methodology
applicability
Input to Detailed Cybersecurity Risk Assessment
Methodology objective
The goal is to perform a security level capability assessment
versus the requirements in ANSI/ISA 62443-2-1.
3743
Methodology description / procedure
3744
3745
3746
Once the organizational measures required by the technical measures are known, those organizational measures in place or included
within the scope can be compared to ISA 62443-2-1 to determine any gaps. As part of this vulnerability assessment, the maturity level
of those procedural measures should also be determined. Annex A provides guidance with respect to Maturity Level assessment.
3747
The general vulnerability assessment procedure is as follows:
3748
3749
3750
3751
3752
3753
3754
6. Document applicable technical measures applicable to all zones
7. Document applicable technical measures applicable as a function of specific zo nes
8. Document organizational measures (i.e., ANSI/ISA 62443-2-1) and procedures necessary to support specific technical
measures. Should those procedures include requirements from ANSI/ISA 62443 -2-4, then they must also be considered
9. Assess each organizational measure and procedure for its maturity level
10. Document the results
Figure C.3 provides an excerpt of an example worksheet template
Req ID
Pass / Fail
Reference Name
Requirement Description
Element – Security Policies and Procedures
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.
Assessment Notes /
Evidence
ISA-TR84.00.09-2023
4.3.2.6.3
3755
3756
3757
- 162 -
Maintain consistency between
risk management systems
Cyber security policies and procedures that deal
with IACS risks should be consistent with or
extensions of policies created by other risk
management systems.
Figure C.3
Organization Capability Worksheet
Example Excerpt
ISA-TR84.00.09-2023
- 163 -
3758
C.5 IACS architecture vulnerability identification
3759
Summary
Annex Type
Methodology
Methodology
applicability
Vulnerability Identification Input for Detailed Cybersecurity Risk
Assessment
Methodology objective
To assist development of scope and SuC during the preliminary
stages of a capital project or as part of a brown field site
vulnerability assessment
3760
Methodology description / procedure
3761
3762
3763
3764
As part of the development of architecture drawings, it is generally accepted good practice to
conduct an architecture drawing review. During this review meeting, vulnerabilities due to potential
segmentation issues are documented. At a minimum, the segmentation requirements within
ANSI/ISA 62443-3-2 should be used to determine adherence.
3765
The general network vulnerability assessment procedure is as follows:
3766
3767
3768
3769
3770
3771
3772
3773
3774
3775
3776
3777
3778
3779
1. Draft preliminary architecture drawings
2. Assemble team (e.g., Project manager, control engineer, electrical engineer, OT network
engineer, IT representative, operations representative, process safety engineer)
3. Conduct brain storming workshop considering
• Adequacy of segmentation per ANSI/ISA 62443-3-2
• Conduits between zones and their security level
• Access requirements to logical and physical locations (On site, remote, wireless)
• Consideration of data flows, protocols, applications, essential functions, etc.
• Consideration of communications and other utilities that may impact the IACS
• Manufacturer guidance
• Ownership, responsibilities and overlap between OT and IT
4. Redline the architecture diagram with any changes
5. Document any recommendations
6. Develop plan to consider recommendations and implement approved actions
ISA-TR84.00.09-2023
- 164 -
3780
C.6 System integration vulnerability identification
3781
Summary
Annex Type
Explanatory Guidance
Methodology
applicability
FAT, SAT, Initial Validation, Periodic Revalidation
Methodology objective
Identify vulnerabilities prior to and after actual operation through the
measurement and testing of integrated systems in simulated or
actual operation.
3782
3783
Methodology description / procedure
3784
3785
3786
3787
3788
System integration vulnerabilities require an integrated system to be in p lace. This vulnerability
assessment type is really a form of testing, analogous to proof testing of safety systems and
functions. Integration testing for vulnerabilities may occur as part of factory acceptance testing,
site acceptance testing, initial validation, or periodic revalidation. Additional information is provided
in Annex J, Testing
3789
ISA-TR84.00.09-2023
- 165 -
Annex D – Risk Assessment Methodologies
3790
3791
Introduction
3792
3793
3794
3795
3796
3797
ISA 62443-3-2 requires an initial cyber risk assessment and in addition, a detailed level cyber risk
assessment when the unmitigated consequences exceed the tolerable risk of the asset owner.
This annex details several risk assessment methodologies that encompass initial and detailed level
cyber risk assessments. The reader should not consider this list to be exhaus tive. Additional detail
for many of the methods may be found in the source reference upon which the content contained
herein is based.
3798
3799
3800
With multiple methodologies being available and each having their own strengths and weaknesses,
thought should be given as to the most appropriate methodology or methodologies to use. Factors
that impact selection include [46] :
3801
3802
3803
3804
3805
3806
3807
•
•
•
•
•
•
•
Motivation for the study
Type of results needed
Type of information available to perform the study
Characteristics of the analysis problem
Perceived risk associated with the subject process or activity
Resource availability and analyst / management preference
Compliance to regulations
3808
3809
In selecting the proper methodology, the user may assess these factors with respect to each
methodology’s strengths and weakness.
3810
3811
3812
3813
3814
3815
The motivation for the risk assessment is generally the most important consideration as it
establishes the purpose. From this the types of results expected will influence the methodology
selection. For example, initial risk assessments by their very nature limit the granularity of results,
but generally provide a good starting point for establishing criticality and prioritization. In other
cases, one detailed level risk methodology may be employed that is broader in nature so that
outputs are generated for another methodology intended to provide a quantitative result.
3816
3817
3818
3819
3820
3821
3822
Although some information input requirements are needed by all methodologies, methodologies
may have their own unique information input requirements. The actual availabilit y of this
information at the time of the risk assessment will impact what methodologies may be appropriate.
Availability of information can be a result of the current lifecycle stage and / or how well information
has been developed. Existing facilities tha t have not fully implemented the lifecycle activities may
not be able to perform detailed risk assessments until they have developed the requisite
information.
3823
3824
The actual SuC that represents the scope of assessment will contain the characteristics of the
analysis problem as follows:
3825
3826
3827
3828
3829
(1)
(2)
(3)
(4)
(5)
Actual complexity and size of the scope
Type of process being controlled
Type of operation(s) for the control system and associated network
Inherent hazards of the process
Inherent hazards of the work processes providing or receiving data
3830
3831
3832
3833
3834
The potential risk perceived by the organization also plays a role. When the perception is higher
risk, there will be a tendency to use methods that are more methodical in nature as it is believed
that they provide more rigor with respect t o hazard identification. For scenarios that result in
catastrophic hazard, additional assessment using more advanced techniques to provide better
insight may be used to deep drill some of the scenarios identified in the first assessment .
3835
3836
3837
In some cases, selection of methodology will be dictated by resources available and their level of
competence. Some methodologies require specialized technical skills that participants may not
have or require a specialized software program that is not available to the team . In addition, the
ISA-TR84.00.09-2023
- 166 -
3838
3839
comfort level and experience of the team facilitator will typically result i n some level of preference
bias for particular methodologies.
3840
3841
3842
In general, whatever method is selected, the person facilitating the assessment should be
knowledgeable with respect to the method and the other team member(s) should be knowledgeable
with respect to the design, operation, and maintenance of the SuC.
3843
ISA-TR84.00.09-2023
- 167 -
3844
Risk Assessment Methodologies Overview
3845
3846
3847
3848
3849
This annex introduces a non-exhaustive selection of cybersecurity risk assessment methodologies that may be used for cybersecurity
risk assessments in the context of functional safety. The methodologies may be more or less suitable for different organizational contexts
or use cases Below table provides guidance for choosing a methodology by comparing their strengths and weaknesses. The “appli cability”
column refers to the potential usage of the methodologies as initial or detailed cybersecurity risk assessments as introduced in ANSI/ISA
62443-3-2:2021.
3850
3851
Please note that applicability, strengths, and weaknesses in Table D.1 only address the methodology as described in this document,
even if there may be additional methodologies with the same title.
3852
Table D.1
Methodology Section and
Title
Applicability
Methodology strengths
D.1
Asset Focused
Cyber Risk
Assessment
Initial Cybersecurity
Risk Assessment
•
•
•
Relatively simple to use
Provides basis for asset SL-T’s
Good input for segmentation basis
•
Does not include security
measures.
D.2
Function Focused
Cyber Risk
Assessment
Initial Cybersecurity
Risk Assessment /
Detailed
Cybersecurity Risk
Assessment
•
Thinking in functions is intuitive for many
engineers. Also, they are often used to
function-based thinking from the concept
of safety functions.
The number of functions is typically
significantly lower than the number of
assets, resulting in a lower number of
overall risks to manage.
Functions are more stable than assets:
While the used PLC programming
software (=asset) may change over time,
the fact that a PLC needs to program
(=function) mostly does not.
Functions, in contrast to assets, include
human interactions, which contribute
significantly to both cybersecurity attack
surface and potential cybersecurity
measures.
Functions, in contrast to assets, include a
purpose (“why is an asset used this
•
Functions are best documented
and analyzed graphically.
However, creating and maintaining
function drawings using
conventional drawing tools like MS
Visio can become labor-intensive.
•
•
•
•
Methodology weaknesses /
limitations
ISA-TR84.00.09-2023
Methodology Section and
Title
D.3
Quantitative
Scenario based risk
assessment
- 168 -
Applicability
Initial Cybersecurity
Risk Assessment /
Detailed
Cybersecurity Risk
Assessment
Methodology strengths
•
•
•
•
•
•
•
•
•
way?”). This is beneficial for risk
assessments because knowing the
purpose facilitates answering questions
about criticality (“how bad is it if the
function is not effective?”).
Quantitative risk criteria aligned with the
LOPA process safety criteria. LOPA target
mitigated event likelihood criteria per
consequence rating is used for the risk
criteria.
Alignment between product functions /
features and risk. Functional deviations
are linked to the functionality of an IACS
function.
Estimation of residual risk allowing for
determining the risk reduction contribution
of barriers (security measures).
Estimating risk for different threat actor
profiles.
Allows for estimating both process
scenario related loss risk as well as
business scenario related loss risk.
Allowing computerized risk estimates
reducing labor time while increasing
number of attack scenarios evaluated.
Allowing periodic risk estimates against a
growing and maintained repository of
cyber-attacks.
Attacks are easily documented by bow-tie
diagrams.
Risk analyst agnostic, results are not
influenced by personal preferences of the
risk analyst (central management and
maintenance of repository).
Methodology weaknesses /
limitations
•
Requires tools to perform
•
Requires detailed knowledge of
the inner workings of the IACS
functions
Requires extensive databases for
threat actors, threat actions etc.
that need to be maintained
continually
•
ISA-TR84.00.09-2023
Methodology Section and
Title
D.4
CFATS Site
Vulnerability
Assessment
- 169 -
Applicability
Initial Cybersecurity
Risk Assessment
Methodology strengths
•
Risk results easily compare between
different plants, allows for benchmarking.
•
Prioritizes sites based upon potential risk
due to the type and quantity of chemicals
on site and
Assists in the development of a security
plan.
Provides useful input detailed cyber
security risk assessments.
•
•
D.5
Consequencedriven, cyberinformed
Engineering (CCE)
Detailed level risk
assessment
•
Prioritization based on potential cybersabotage or unintentional functional
impacts enables organizations to prioritize
limited resources.
•
The process encourages participation
from a variety of experts (e.g., IT/OT
cybersecurity, engineering design,
automation, operations, and threat
intelligence) and encourages
communication and collaboration across
disparate groups.
•
Engineers are intimately familiar with how
their production, automation,
communication, etc. systems are designed
and operate. The methodology leverages
this invaluable insight into potential
protection mechanisms.
•
Primary focus on cyber-sabotage critical
function impacts results in cybersecurity
strategies that are aligned with business
objectives, resilience and less mercurial to
incendiary threat reporting.
Methodology weaknesses /
limitations
•
•
Relatively narrow scope; only
applicable for organizations under
CFATS regulation
Significant redundancy with NIST
framework and ISA 62443 when
not required
•
•
•
Evaluation process can be
resource intensive.
Although threat-informed,
implementations of the CCE
methodology are intended to
be proactive, rather than
reactive, exercises. Leaps in
adversary capability, or
significant changes in
operational environments
(technology and/or PPT) may
require periodic re-evaluation
of potential attack scenarios
and HCEs.
Methodology may not identify
all unintentional cyber events.
ISA-TR84.00.09-2023
- 170 -
Methodology Section and
Title
Applicability
Methodology strengths
D.6
Initial Cybersecurity
Risk Assessment
•
Security PHA
Review for
Consequence
Based
Cybersecurity
•
•
•
•
•
D.7
Cyber PHA Risk
Assessment
Detailed
Cybersecurity Risk
Assessment
•
•
•
•
D.8
CHAZOP (Control
hazard and
operability review
that also includes)
High Level, Detailed
Cybersecurity Risk
Assessment
•
•
•
Cybersecurity risk assessment is part of
PHA process or a post review.
Uses the information generated in a
traditional PHA (e.g., scenarios,
consequences, and safeguards).
Provides opportunities at the preliminary
stages of safety lifecycle to consider
safeguards that are inherently safer to
cyberattacks.
Identifies scenarios that are not inherently
safe and / or vulnerable to cyber-attacks
Comprehensible by traditional PHA
facilitators
Provides useful input for detailed
cybersecurity risk assessments.
Uses methodology type familiar to
personnel, i.e., like HAZOP
Supports evaluation of segmentation
effectiveness
Addresses both external and insider
threats
Conducive to spreadsheet tools
Holistic evaluation, evaluates potential
systemic / common cause failure
scenarios that could impact system,
including Cybersecurity
Systemic analysis of SuC by defined
nodes, deviation scenarios to be
considered for potential consequence.
Aligned with PHA / LOPA output for
potential physical consequences
Methodology weaknesses /
limitations
•
•
•
•
•
May be more labor intensive than
other initial risk assessment
methodologies, although should
not be significant if conducted
during a traditional HAZOP.
Conservative due to the
assumption that likelihood
probability is equal to 1
Strictly a qualitative method like
HAZOP
May require additional more
rigorous methods to deep drill
threat vectors, kill chain. This
would be analogous to LOPA or
fault tree analyses following
HAZOP type PHAs
Typically, general classes of Cyber
compromises considered, not
exhaustive of all vectors or attack
chains
ISA-TR84.00.09-2023
- 171 -
Methodology Section and
Title
Applicability
Methodology strengths
D.9
Detailed
Cybersecurity Risk
Assessment support
•
Cyber Kill Chain
•
•
Typically, not a standalone
methodology
D.10
Sneak Path
Analysis
Detailed
Cybersecurity Risk
Assessment
•
Provides insight as to threat vector and
more granular effectiveness of security
measures
•
•
Requires specialist knowledge
Results are qualitative
D.11
Cyber Event Tree
Detailed
Cybersecurity Risk
Assessment
•
Provides insight as to threat vector and
more granular effectiveness of security
measures
Allows a more rigorous analysis of
selected scenarios identified in other
techniques such as cyber PHA
Results may be qualitative or quantitative
•
•
Requires specialist knowledge
Generally, much narrower in scope
other techniques such as cyber
PHA
Each event tree is limited to a
single threat agent and entry point
to the system/network
Provides insight as to threat vectors, more
granular effectiveness of security
measures and understanding of risk
Allows a more rigorous analysis of
selected scenarios identified in other
techniques such as cyber PHA
Results may be qualitative or quantitative
Top event can accommodate multiple
threat vectors
Easy to design and use
Less time consuming to administer
Identifies gaps to focus on detail design
and risk assessment
Apart from Risk Assessment the method
can be used in:
o Assessment/Audit,
o To determine rigor of MOC
Incident investigation
•
•
Requires specialist knowledge
Generally, much narrower in scope
other techniques such as cyber
PHA
•
•
Lack of inherent structure
Simple qualitative analysis without
any KPI/SL output.
Objective must be set before hand
and requires an elevated level of
experience to design a checklist to
meet the objective.
•
•
D.12
Cyber-attack Tree
Detailed
Cybersecurity Risk
Assessment
•
•
•
•
D.13
Check Lists
Initial Cybersecurity
Risk Assessment
•
•
•
•
•
3853
Improved understanding of
countermeasure effectiveness
Enhances other methodologies
Methodology weaknesses /
limitations
•
•
ISA-TR84.00.09-2023
- 172 -
3854
D.1 Asset Focused Cyber Risk Assessment
3855
Summary
Annex Type
Methodology
Methodology
applicability
Initial Cybersecurity Risk Assessment
Methodology objective
background
Provide an initial basis for asset SL-T’s that can help establish the
basis for segmentation into zones and conduits
3856
Methodology description / procedures
3857
3858
3859
3860
One asset based cyber risk assessment methodology was described in a paper by Paul Baybutt,
An Asset-Based Approach for Industrial Cyber Security Vulnerability Analysis [48] . The methodology
considers how cyber assets can be exploited by threat agents to do harm. The fol lowing provides
an overview of this methodology:
3861
3862
3863
3864
3865
3866
3867
3868
3869
1)
2)
3)
4)
5)
6)
7)
8)
9)
Preparation and organization
Target Analysis (Likelihood that identified critical assets will be attacked)
Threat Analysis (Identification of threat agents and purpose/type of threat)
Identification of vulnerabilities
Identification of consequences
Estimation of risks
Identification of recommendations
Documentation and reporting
Follow-up
3870
3871
Although the title of the paper uses the term vulnerability, it is really risk based and can be
considered a detailed cyber security risk assessment methodology.
3872
3873
3874
Another asset-based methodology is based on the paper by Harold Thomas and John Day,
Integrating Cybersecurity Risk Assessments into the Process Safety Management Work Process
[24] .
3875
A summary of the procedural steps is included below:
3876
3877
3878
3879
3880
3881
3882
3883
•
•
•
•
•
•
List cyber assets.
Identify worst case potential consequences as a function of process/utility area.
Document potential consequences if asset is compromised.
Document ease of propagation with open communication.
Select target security level for each asset category as a function of process/utility area.
Verify risk criteria are adequate for cyber risk management.
This methodology is an example of an initial cyber risk assessment. Figure D.1 provides an
example worksheet for the performing and documenting this methodology.
Process
/ utility
area
3884
Cyber
asset
type
Consequence
to process /
utility area if
compromised
Criticality
Security
level
Ease of
propagation
Recommended
response if
compromised
Figure D.1 - Example Asset Based Initial Cyber Risk Assessment Worksheet
ISA-TR84.00.09-2023
- 173 -
3885
D.2 Function Focused Cyber Risk Assessment
3886
Summary
Annex Type
Methodology and template
Methodology
applicability
Initial Cybersecurity Risk Assessment / Detailed Cybersecurity
Risk Assessment
Methodology objective
The methodology was designed for control engineers who need to
carry out cybersecurity risk assessments and have deep system
knowledge, but limited cybersecurity knowledge.
Its core is to gain a holistic understanding of the SuC’s
functionality that includes interactions of humans, system
components and their purpose. During the proposed procedure,
documentation and data flow diagrams are created in an intuitive
way for control engineers while doing risk assessments, even if
there is no system documentation or asset inventory to start with.
The methodology can vary in its level of detail and can thus be
used consecutively for initial and then detailed cybersecurity risk
assessments.
More background can be found here:
•
https://www.controlglobal.com/articles/2019/making -otsecurity-engineering-deserve-its-name/
•
https://fluchsfriction.medium.com/for-security-thinkfunctions-not-systems-b0e08a9d89b6
•
https://fluchsfriction.medium.com/think-in-functions-not-insystems-6afeb675b5d2
3887
Methodology description / procedure
3888
3889
Focusing on functions instead of assets as an alternative way to look at the SuC which can be
used in both initial and detailed cybersecurity risk assessments.
3890
3891
3892
Functions as used for this methodology are defined in chapter 6.3.1 (and Figure 6 .1). Thus, the
set of functions in scope are called “essential functions .” They likely include safety functions, but
also contain basic control functions and complementary functio ns.
3893
A function consists of
3894
•
technical system components,
3895
•
human system components, and
3896
•
interactions between system components,
3897
•
meeting a defined purpose.
3898
An example is given in the following sections.
3899
Function focused initial cybersecurity risk assessment
3900
3901
In the initial cybersecurity risk assessment, the following procedure is recommended for function focused assessments:
3902
3903
1. Function identification: List essential functions in scope (title and textual description)
2. Function criticality assessment:
ISA-TR84.00.09-2023
- 174 -
3904
3905
3906
3907
3908
a. Assess function criticality regarding availability. The corresponding question to
answer would be “what happens in the worst case if a function fails?
b. Assess function criticality regarding integrity and / or confidentiality. The
corresponding question to answer would be “what happens in the worst case if a
function is (maliciously) manipulated?”
3909
3910
For the function criticality assessment metric, the organizations risk criteria and metric can be
used. At this point, only the impact dimension is relevant.
3911
3912
3913
3914
Criticality regarding availability is assessed separately, while criticality regarding integrity and / or
confidentiality are assessed together. The reason behind that: for interfering with a function’s
availability, completely different worst-case scenarios need to be considered compared to
interfering with a function’s integrity or availability, and the impacts typically differ.
3915
3916
3917
3918
3919
This is illustrated in the example used in Error! Reference source not found.: If the function “PLC p
rogramming” is not available anymore, it would be less critical than if the function was manipulated
by uploading modified PLC logic. Moreover, for uploading modified PLC logic a more e laborate
attack scenario would need to be deployed than for merely disabling the programming function for
example by destroying the programming PC.
3920
3921
Note that during the initial cybersecurity risk assessment, risk scenarios do not need to be defined
and analyzed. This will be part of the detailed cybersecurity risk assessment.
3922
3923
3924
Table D.2
Template for a function focused initial cybersecurity risk assessment, including an
example
3925
3926
Function
Title
Function Description
PLC
programming
A control engineer
updates the PLC logic by
uploading PLC code from
his programming PC to the
PLC.
…
…
Criticality
(=impact)
regarding
availability
Low
Rationale
If the PLC logic
cannot be updated
for a while, the
plant and process
are not impacted.
PLC logic does not
need to be updated
frequently.
Criticality
(=impact)
regarding
integrity /
confidentiality
High
Rationale
Maliciously
modified PLC
logic can in the
worst case
(depending on
the PLC) cause
damage to plant,
process, or even
health and
environment.
ISA-TR84.00.09-2023
3927
- 175 -
Function focused detailed cybersecurity risk assessment
3928
3929
In the detailed cybersecurity risk assessment, the following procedure is recommended for
function-focused assessments:
3930
3931
3932
3933
3934
1. Function data flow analysis: Decompose each of the functions in scope identified during
the initial risk assessment into its components (technical system components, human
system components, interactions). This can be done best by creating function drawings
(see example in Figure D.2). Because they include interactions between assets, function
drawings can also serve as data flow diagrams for the SuC.
3935
3936
Figure D.2: Function data flow analysis for the example function “program PLC”
3937
3938
3939
2. Risk scenario identification: Identify one or more risk scenarios for each function. The
data flow analysis as well as the criticality assessments from the initial cybersecurity risk
assessment serve as guidance.
3940
3941
3942
3943
a. First, decide if the scenario is aimed at interfering with the function’s availability or
with its integrity or confidentiality. The function’s criticality assessment from the
initial risk assessment can help here: Which worst -case scenario are you trying to
achieve with the defined risk scenario?
3944
3945
3946
3947
b. Second, describe the scenario as realistic and detailed as possible. Looking at the
data flow analysis helps doing this. What steps would an attacker need to take to
achieve this scenario? What hurdles (hum ans in the loop, authentication
mechanisms…) would be needed to overcome?
3948
3949
3. Risk assessment: Assess the identified risk scenario regarding impact and likelihood. The
organizations risk metric and criteria can be used for the assessment.
3950
3951
3952
3953
3954
3955
a. Assess the scenario’s impact. Depending on if it is an availability or an
integrity/confidentiality scenario, the corresponding criticality rating from the initial
cybersecurity risk assessment is a good basis. Because the function’s criticality is
supposed to assume a function’s worst-case impact, the scenario’s impact is not
likely to rise in impact, but it could well be that a scenario under consideration
cannot achieve the worst-case impact but has a lower impact ranking.
3956
3957
3958
b. Assess the scenario’s likelihood. If a scenario has happened before in the
organization and the required effort and knowledge to carry out the scenario are
both good indicators for likelihood. A qualitative ranking may be used for likelihood.
3959
3960
A template and example for the risk scenario identification and risk assessment is given in Error! R
eference source not found..
3961
ISA-TR84.00.09-2023
- 176 -
3962
Table D.3
3963
3964
Template for a function focused detailed cybersecurity risk assessment, including an
example
Risk scenario
description
Function
PLC
programming
Risk scenario type
(availability or
integrity/confidentiality)
The PLC programmer’s
laptop is infected with
ransomware while it
was plugged into the
corporate network.
All files on the laptop
are lost, and it cannot
be used to update the
PLC logic anymore.
…
Impact &
rationale
Likelihood &
rationale
availability
low
medium
(function “program
PLC” is not available
anymore).
(See initial
risk
assessment)
(There are known
cases of
ransomware in
the corporate
network in the
past. The laptop
is frequently
connected to the
corporate
network)
Risk
medium
…
3965
3966
D.3 Quantitative Function Based Cyber Risk Assessment
3967
Summary
Annex Type
Methodology
Methodology
applicability
Initial / Detailed Cybersecurity Risk Assessment
Methodology objective
The methodology is designed for OT risk analysts who need a
quantitative cybersecurity risk analysis based on loss events of a
production facility. Loss events are identified for the primary
functions controlling the production process by the security
HAZOP/LOPA process scenarios and for the complementary
functions of the IACS (functions that interact with the company's
business functions) by business scenarios .
The objective is analyzing quantitative residual risk as a function
of the threat actor, the static and dynamic exposure of the primary
and complementary functions, implemented barriers (security
measures) and the functional deviations that may be caused by
the cyber-attack.
The methodology allows for determining the contribution to risk
reduction from different security measures and allows to estimate
the risk for different threat actors.
3968
Methodology description
3969
The methodology is based upon the following schematic model for a cyber-attack.
ISA-TR84.00.09-2023
- 177 -
SECURITY MEASURES (BARRIERS)
OFFERING PROTECTION FOR THE
VULNERABILITIES AGAINST THE
THREAT ACTION
THREAT ACTOR
THREAT ACTION
THREAT ACTOR INITIATES A THREAT
ACTION (THREAT EVENT)
1
B1
B9
Bx
SECURITY MEASURES
(BARRIERS) REDUCING
CONSEQUENCE
SEVERITY
VULNERABILITY
EXPLOITING THE VULNERABILITY
B2
By
DERIVED FROM HAZOP /
LOPA ANALYSIS RESULTS
LOSS OF
CONFIDENTIALITY
PROCESS DEVIATION
FUNCTIONAL DEVIATION
FUNCTIONAL DEVIATION
RESULTING IN FUNCTIONAL
DEVIATION OR BREACH OF
CONFIDENTIALITY
DEVELOPED BUSINESS
SCENARIOS NOT PART OF
HAZOP / LOPA
2 LOSS BASED RISK
RISK PRIORITY NUMBER
3970
3971
BUSINESS DEVIATION
The methodology allows for estimating two types of risk:
3972
3973
•
Risk expressed as a risk priority number. A numerical assessment of a risk value not linked
to the business impact (1).
3974
3975
3976
•
Risk expressed founded on loss events. An assessment of a risk value as function of a
quantitative average event frequency (likelihood) and a financial, safety, and / or
environmental loss event (1 + 2).
3977
3978
3979
3980
3981
3982
For security design purposes, estimating a risk priority numb er is typically sufficient for prioritizing
the risk mitigation effort or for detecting changes in risk. If either a financial justification in support
of the investment in security measures is required or a justification for showing compliance with
specific social risk limits (this when cyber-attack scenarios exist that result in single or multiple
fatalities) is required than a quantitative risk assessment considering an average event frequency
for loss events is obligatory.
3983
3984
3985
3986
3987
For cybersecurity risk based on loss events, the same process safety risk criteria also apply for
the cybersecurity risk. Consequence is valuated independent of its cause, therefor the likelihood
that a cybersecurity attack results in a functional deviation of the IACS operation must m eet the
defined target mitigated event likelihood (TMEL) set for that impact. See an example of quantitative
risk criteria below.
Total probable
business loss
Process Safety
Environmental Impact
Consequence
rating
Target mitigated
event likelihood
(TMEL)
On-site
Off-site
Less than 1M
Not defined
Not defined
Not defined
Negligible
(C1)
1.00E-01
1M - 10M
Reportable medical
treatment case or a day
away from work case
with full rehabilitation.
An accident or release
likely to create adverse
local publicity
An incident that needs to be reported to the Authorities. (e.g.
exceeding a water permit limit; a release of a chemical above the
reportable quantity limit - a one time event, little or no fine)
Minor
(C2)
1.00E-02
10M - 99M
A serious irreversible
injury
An accident resulting in
the local public being told
to take shelter indoors or
evacuation
An environmental incident where contamination is confined to the
site and where recovery is complete in 1 year. This includes
contamination to surface water and fish kill that is limited to the
site. (e.g. an National Pollutant Discharge Elimination System
violation or spill resulting in a consent order or a significant fine)
Moderate
(C3)
1.00E-03
100M - 1000M
1 to 2 fatalities
A serious irreversible
injury
An environmental incident which could contaminate ground water
in immediate area around the site or result in a substantial fish
kill (50+ fish) outside the site. (e.g. an incident affecting the
public or downstream water users, such as a drinking water
utility)
Major
(C4)
1.00E-04
> 1000M
3 to 9 fatalities
1 to 2 fatalities
An environmental incident that involves significant remediation of
soil off-site or contaminates sediments, ground or surface water
outside the site boundaries. Environmental incident that causes
significant damage to nature, such as tree and plant kills etc.
Catastrophic
(C5)
1.00E-05
3988
3989
3990
The methodology identifies primary functions, complementary functions and subfunctions of the
IACS and analyzes residual risk per function / subfunction.
ISA-TR84.00.09-2023
- 178 -
3991
3992
3993
Examples of primary functions are: Basic Process Control System (BPCS), Safety Instrumented
System (SIS), Compressor Control System (CCS), Machine Monitoring System (MMS), Advanced
Process Control (APC), Analyzer Management System (ANMS), etc.
3994
3995
Special primary functions are defined such as the process automation network (PAN), or integrated
control and safety system (ICSS) to evaluate the risk for functions focusing on common elements.
3996
3997
3998
3999
Examples of complementary functions are Data Acquisition Historian System (DAHS), Alarm
Management System (ALMS), Instrument Asset Management System (IAMS), Laboratory
Information Management System (LIMS), Permit to Work (PTW) system, Real-Time Performance
Management Systems, etc.
PRIMARY /
COMPLEMENTARY
FUNCTION
OPERATOR HMI(S)
ENGINEER HMI(S)
SERVER(S)
CONTROL DEVICE(S)
SUBFUNCTIONS
FIELD DEVICE(S)
PANEL(S)
CHANNEL(S)
4000
4001
4002
4003
Subfunctions are the supporting elements that constitute the primary or complementary function,
for example an operator station, server, a software package, or a protocol (channel) used by the
primary function.
4004
4005
Primary functions directly control or safeguard the production process, while complementary
functions have a support role.
4006
4007
4008
The subfunctions are the tangible targets for the cyber-attacks. For example, a cyber-attack might
attempt to gain unauthorized access into an engineer HMI, or a cyber-attack might attempt to inject
messages into a specific channel stream.
4009
4010
4011
The risk analyst typically builds a repository of cybersecurity hazards with the threat events,
barriers that protect against the threat event and the functional deviations caused by the threat
event for each subfunction. These hazards are defined as bow -tie diagrams.
4012
4013
4014
4015
So, for example for an ENGINEER HMI unauthorized access hazard, the different threat events
that can result in unauthorized access are defined together with the critical functional deviations
that can result from the access and the barriers (security measures) that counter the threat event
from succeeding or prevent a functional deviation to occur .
ISA-TR84.00.09-2023
- 179 -
PRIMARY FUNCTION
THREAT EVENT SPECIFIC
SECURITY MEASURES
CONSEQUENCE SPECIFIC
SECURITY MEASURES
FUNCTIONAL
DEVIATION #
THREAT EVENT #
OPERATOR HMI(S)
THREAT EVENT COMMON
SECURITY MEASURES
CONSEQUENCE COMMON
SECURITY MEASURES
THREAT EVENT #
OPERATOR HMI
HAZARD xxx
ENGINEER HMI(S)
FUNCTIONAL
DEVIATION #
THREAT EVENT #
SERVER(S)
THREAT EVENT #
FUNCTIONAL
DEVIATION #
CONTROL DEVICE(S)
FIELD DEVICE(S)
PANEL(S)
CHANNEL(S)
4016
4017
Three types of functional deviations are considered:
4018
4019
4020
4021
4022
•
Loss of required performance - The function no longer meets design or operational intent.
Examples of this are modifications of a control applica tion (e.g., a PLC program),
modification of process control parameters ( e.g., valve travel rate, alarm limit), not meeting
real-time performance criteria (e.g., causing a processing overload), invalid operating
window settings (e.g., modified range limits), etc.
4023
4024
4025
4026
4027
•
Loss of ability to perform - The inability to perform the function. Examples of this are loss
of observability of the control process (e.g., no alarms, no state changes, no process values,
no valve position data, no trending information, no historic al data, etc.), loss of
controllability (e.g., lost ability to intervene in the process state, lost ability to change the
position of a valve, lost ability to switch on / off process equipment, etc.)
4028
4029
4030
•
Loss of confidentiality - The confidentiality of information in the system has been breached.
Examples of this can be loss of industrial property, sensitive production data, design
information, access credentials, etc.
4031
4032
Functional deviations are linked to the functionality and features of the (primary / complem entary)
function / subfunction provided by the manufacturer / developer.
4033
Security barriers (security measures) can be:
4034
4035
4036
•
Externally added security measures, either prevention or detection. For example, a firewall,
an antivirus function, an anomaly detection function, a USB protection function, an intrusion
prevention function, cabinet locks, etc.
4037
4038
•
Primary function / subfunction capabilities, for example encrypted traffic, an authentication
function, an authorization function, an event logging function, a phys ical program key, etc.
4039
4040
•
Subfunction configuration settings, for example a write protection setting, a browse
protection setting, a value increment limitation, etc.
4041
4042
4043
Security barriers reduce the risk, their contribution to risk reduction is considered a funct ion of
their effectiveness and reliability. The method adapts the effectiveness of a barrier per threat actor
profile.
ISA-TR84.00.09-2023
- 180 -
4044
4045
4046
The repository with the threat actions requires continuous maintenance to include the latest tactics,
techniques, and procedures (TTP) applied in cyber-attacks that occur around the world. The
functional deviations are subfunction specific and differ for products from different vendors.
4047
4048
4049
The risk method used to estimate a quantitative risk value is generally based on the FAIR (Factor
Analysis of Information Risk) methodology. The FAIR methodology estimates three event
frequencies:
4050
4051
•
Contact event frequency (CEF) - the probable event frequency, within a given time frame,
that the threat actor will encounter the target.
4052
4053
•
Threat event frequency (TEF) - the probable event frequency, within a given time frame,
that the threat actor will act in a manner that may result in loss.
4054
4055
•
Loss event frequency (LEF) - the probable frequency, within a given time frame, that loss
will materialize from the threat actor’s action.
4056
4057
4058
4059
4060
The LEF is a function of the TEF, target exposure, and the risk reduction from the implemented
barriers. Exposure is split into static exposure (risk factors related to the system design
(connectivity, security zone residence, complexity, accessibility) and potential vulnerabilities) and
dynamic exposure (risk factors related to security operations such as patch latency, AV signature
update frequency, etc.)
4061
4062
4063
The TEF is a function of the CEF and the threat actor’s propensity to apply a specific TTP. The
CEF is a frequency that depends on the threat actor’s ability to “contact” the target, either physical
or logical (e.g., direct access to the system, or over the network access).
DERIVED FROM HAZOP / LOPA
ANALYSIS RESULTS
PROCESS DEVIATION
FUNCTIONAL DEVIATION
SAFEGUARD DEVIATION
BUSINESS DEVIATION
4064
DEVELOPED BUSINESS
SCENARIOS NOT PART OF
HAZOP
4065
4066
4067
In case a process scenario requires two separate cyber-attacks for accomplishing its objective
than the resulting LEF follows the rules for conditional probability and becomes the product of the
two event frequencies, so LEF SCENARIO = LEF ATTACK1 x LEF ATTACK2
4068
4069
4070
4071
4072
4073
For example, an attack scenario that requires separated attacks on both the BPCS and SIS, will
have a lower LEF compared to an attack scenario where a common point exists from where both
BPCS and SIS functions can be simultaneously altered. As would be the case if an engineering
HMI would host both the engineering tool for the BPCS and for the SIS. Other examples of targets
that can cause a common point for an orchestrated attacks on SIS and BPCS are MMS, IAMS and
ANMS.
4074
4075
4076
Quantitative function based initial cybersecurity risk assessment
In the initial cybersecurity risk assessment, the following procedure is recommended for function based assessments:
ISA-TR84.00.09-2023
4077
4078
4079
4080
4081
4082
4083
4084
4085
4086
4087
4088
4089
4090
4091
4092
4093
4094
4095
4096
4097
4098
4099
4100
4101
4102
4103
4104
4105
4106
4107
4108
4109
4110
4111
4112
4113
4114
4115
4116
4117
4118
4119
4120
4121
4122
4123
4124
4125
4126
- 181 -
1. Function identification: Identify primary and complementary functions that are in scope
of the risk assessment and create a scope diagram. Scope diagrams are topology diagrams
showing only those subfunctions that are considered essential for the risk estimate. So as
example, instead of showing four operator stations in the central control room (CCR) it only
shows 1 if the other stations are exposed to the s ame risk (part of the same console).
However, if risk exposure differs, e.g., an operator station in a local equipment room (LER),
additional stations are added to the diagram. Scope diagrams group elements of the same
function using colors, this allows in combination with the zone and conduit diagram to
quickly locate the various components of a function.
2. Function criticality assessment / business impact analysis:
a. Assess the dependencies between the primary / complementary functions and
subfunctions, the following types of dependencies are considered:
i.
Flow dependency, this dependency exists when a function depends on the
result of another function. For example, an APC function and a BPCS function
have a flow dependency, but also a BPCS / PLC relationship has a flow
dependency if a read after write (RAW) is required is required for reading status
information.
ii.
Anti-dependency, this dependency exists when a function depends on reading
data prior to updating it. (Write After Read - WAR) For example an IAMS that
first collects the information from a field device prior to altering it.
iii.
Output dependency (Write After Write - WAW), this dependency exists when a
function depends on another function to write the output. For example, a BPCS
that communicates with a field unit, where the field unit controls the actuator.
The BPCS has an output dependency of the field unit for controlling the valve.
iv.
Control dependency, a function has a control dependency if another up -stream
function determines if the function’s action is executed. An example of a control
dependency is a batch controller that depends on the batch manager for its
recipes, or a primary and secondary control loop configured on different
controllers.
Dependencies determine the upstream / downstream relations between functions.
These relationships influence the criticality of functions, but also define which data
flows exist between primary functions, complementary functions and subfunctions
as an input for the zone and conduit diagram.
b. Assess primary, complementary and subfunction criticality regarding loss of ability
to perform.
Criticality is a measure of importance of a function / subfunction for the business
process, not to be confused with severity which is a measure for the austerity of
the consequence resulting from a failure of the function.
Criticality is scored for the function and its subfunctions based on different
downtimes, typical downtimes assessed are: 0-4h, 4-8h, <1d, <1w, >1w.
For the subfunctions recovery time objective (RTO) and recovery poi nt objectives
(RPO) are defined, while for the primary function a maximum tolerable downtime is
defined.
c. Assess primary, complementary and subfunction criticality regarding loss of
required performance.
Here the sensitivity of the business process for fun ctional and / or operational
deviations is scored. What is the business process impact if the function does not
perform meeting design intent and / or operational intent.
d. Assess primary, complementary and subfunction criticality for loss of data
confidentiality.
ISA-TR84.00.09-2023
4127
4128
4129
4130
4131
4132
4133
4134
4135
4136
- 182 -
This assessment step scores the criticality of a confidentiality breach for the
function and its subfunctions. How sensitive is the data being exposed to non authorized entities.
e. Identify / define business scenarios for functions that have an impact on the
business in other ways than covered by the plant’s HAZOP and LOPA exercises.
Typically, a plant develops process safety scenarios using the HAZOP methodology,
however the IACS functions can also impact the business functions. This type of
scenario is developed here if not available. A scenario needs at minimum a cause
(the trigger) and a consequence (the reaction).
3. Function cause-consequence analysis
4137
4138
A scenario is a description of possible actions or events in the future, for OT risk
analysis three types of scenarios are considered:
4139
4140
4141
4142
4143
a. Cyber-attack scenarios - a description of a cyber-attack, a combination of threat
actor, threat action, and potential functional deviation caused by th e attack. Cyberattack scenarios are defined in the form of a bow -tie diagram, showing the threat
events, the protective / detective barriers, and the potential functional deviations of
the targeted function / subfunction.
4144
4145
4146
b. Process scenarios - a description of a process deviation, its cause, consequences,
and safeguards. Process scenarios are the result of a process safety HAZOP
exercise.
4147
4148
4149
4150
c. Business scenarios - a description of business disturbances resulting from IACS
function abnormalities, their cause, possible business consequences and protective
measures. Business scenarios are defined during the criticality assessment /
business impact analysis.
4151
4152
4153
Both process scenarios and business scenarios are input for the cause -consequence
analysis. Cyber-attack scenarios are ignored in the initial risk assessment, these are
the input for the detailed risk assessment.
4154
4155
4156
4157
4158
The objective of the cause-consequence analysis is to identify the process and
business scenarios that could be triggered by a cyber-attack, to identify the primary
function(s) that could do this because of a cyber-attack, and the consequence if the
cyber-attack succeeds. Following checks are made for each process and business
scenario:
4159
a. Is the cause of the scenario hackable?
4160
4161
b. If yes, which primary function(s) of the IACS need to be attacked to trigger the
scenario?
4162
4163
c. Are there hackable protective functions that trigger the scenario or disable the
protective function in the event of an attack?
4164
d. What is the consequence severity for the scenario?
4165
4166
4167
4168
4169
The cause-consequence analysis links the scenarios to hackable functions that can
trigger the scenario. The cause-consequence analysis additionally allows us to rank
the hackable scenarios according to the severity of the consequences. The detailed
risk analysis that optionally follows will first deal with the scenarios with the highest
consequence severity.
4170
The initial cybersecurity risk assessment activity provides:
4171
•
Information for the zone and conduit diagram (scope diagram(s), dependency analysis).
4172
•
Hackable functions and their relationship to a business or process loss scenario.
4173
•
The consequence severity for these loss scenarios.
ISA-TR84.00.09-2023
- 183 -
4174
4175
4176
Based upon this information we can decide which business / process scenarios we need to do a
detailed analysis for to determine if the risk meets the plant’s risk criteria and what options there
are to mitigate it if it does not meet the criteria.
4177
Quantitative function based detailed cybersecurity risk assessment
4178
4179
4180
4181
4182
4183
In the detailed cybersecurity risk assessment, we want to estimate the probability that a specific
scenario could develop. The scenarios, their consequences, the potential targets, and their
position in the IACS topology are determined in the initial risk assessment. The next step is to test
each potential target against a series of threat actions to identify if there are functional deviations
possible that contribute to the development of the scen ario and what the likelihood of success is.
For this we need to execute following tasks:
4184
4185
4186
•
Hazard identification. The task of identifying what can go wrong. This involves identifying
the hazards and threats that could cause a disruption that triggers the dev elopment of the
scenario.
4187
4188
4189
4190
•
Risk estimation, evaluation, and communication. The task of estimating the likelihood that
a threat, which can cause the harmful functional deviation, succeeds. Risk evaluation and
communication is the task of disseminating the analysis results in a form that provides clear
insight into the results of the estimation against the criteria.
4191
4192
The detailed risk analysis is based on input from the initial risk assessment and the development
of the zone and conduit diagram.
4193
1. Hazard identification
4194
The objectives of the hazard identification process are to:
4195
4196
•
Identify all the cybersecurity hazards and threats that are relevant during all intended use
and foreseeable misuse of the intended function.
4197
4198
•
Describe the threats, their possible functional deviation and the barriers that protect against
the success of the threat.
4199
•
Identify possible activation events and conditions related to each hazard.
4200
4201
4202
This form of detailed threat modelling is normally done prior to the actual detailed risk
assessment to build a repository of hazards/threats/functional deviations for the different
subfunctions (targets) of the IACS.
4203
4204
4205
This is a specialized and time-consuming job that requires detailed knowledge of the inner
workings of the subfunctions and the possible vulnerabilities. Typical hazards analyzed for
subfunctions in detail are:
4206
4207
•
Unauthorized access - The various threat actions that can accomplish unauthorized access
or privilege escalation into the function.
4208
4209
•
Malicious program code delivery, installation, and propagation - The various threat actions
that attempt to enter malicious program code or modify existing code.
4210
4211
•
Manipulation of network traffic - The various threat actions against protocols exploiting their
vulnerabilities.
4212
4213
•
Denial of service - The various threat actions that attempt to overload a function stopping
it to perform.
4214
4215
•
Reconnaissance and information gathering - The various threat actions that gather
information on the IACS infrastructure, functions, and data content.
4216
4217
•
Maintaining a presence in the IACS - The various threat actions that attempt to establish a
persistent presence in the system.
ISA-TR84.00.09-2023
- 184 -
THREAT EVENT SPECIFIC
SECURITY MEASURES
THREAT EVENT #
CONSEQUENCE SPECIFIC
SECURITY MEASURES
THREAT EVENT COMMON
SECURITY MEASURES
CONSEQUENCE COMMON
SECURITY MEASURES
FUNCTIONAL
DEVIATION #
THREAT EVENT #
OPERATOR HMI
HAZARD
FUNCTIONAL
DEVIATION #
THREAT EVENT #
THREAT EVENT #
FUNCTIONAL
DEVIATION #
4218
4219
An example bow-tie describing a cybersecurity hazard is shown above:
4220
4221
•
The threat event describes the threat action, the TTP used by the threat actor to achieve
the objective, which exploits a potential vulnerability.
4222
4223
4224
•
The security measures are the barriers that prevent the vulnerability from being exploited
(left side of the hazard) and / or the barriers that detect the attack or prevent the functional
deviation from occurring (right side of the hazard).
4225
4226
4227
•
The functional deviation is specific per function, it shows the functionality of the target and
how this functionality can deviate. An engineer HMI allows for different functional
deviations than an operator HMI.
4228
2. Identify risk reduction measures
4229
4230
Once the hazards and threats have been identified the next step in the method is to identify the
risk reduction measures, the barriers. There are various risk reduction measures:
4231
•
Engineering security measures
4232
4233
4234
o
Eliminate or minimize the hazard consequences through design changes. E xample is
hardwiring signal connections in place of using a vulnerable protocol to exchange
critical input or output data.
4235
4236
4237
o
Eliminate or minimize the hazard consequences through configuration changes.
Examples are use of tamper proof field equipment, blocki ng write actions through
configuration or mode requirements, dual approval.
4238
4239
o
Isolate the hazard with barriers. Example is application and network segmentation or
isolation of functions.
4240
4241
o
Enclose the hazard. Example is to install equipment in locked cabinets, and accesscontrolled equipment rooms.
4242
4243
•
Cyber security measures
4244
4245
o
Implement access controls. Examples are authentication, authorization, firewalls, IPS,
access control lists, multi-factor authentication, etc.
4246
4247
o
Implement software integrity controls. Examples are antivirus engines, application
whitelisting, signed software, etc.
4248
4249
o
Implement detection controls. Examples are anomaly detection functions, Security
Information and Event Management (SIEM), host intrusion prevention functions.
4250
4251
•
Administrative security measures
o
Implement procedures and policies.
ISA-TR84.00.09-2023
o
4252
- 185 -
Improve training.
4253
Identify which risk reduction controls are in place for the elements in the scope diagram.
4254
3. Risk estimation and evaluation
4255
4256
Risk estimation is the last step in risk assessment. Its objective is to produce a measure for the
risk. There are two possible measures:
4257
4258
4259
4260
•
Risk priority number, a numeric value for ranking risk. The higher the value the bigger the
risk. This measure is most often used for ranking risk for cyber security design purposes.
The measure allows to identify which hazards / threats are most likely to occur and what
security measures contribute most to reducing it.
4261
4262
•
Loss risk, loss risk is a measure related to a likelihood for suffering a business loss, a
human safety loss, or an environmental loss.
THREAT
ACTOR
CAPABILITIES
INTIATING
EVENT
FREQUENCY
THREAT ACTOR
THREAT ACTION
B1
4263
4264
DYNAMIC
EXPOSURE
EFFECTIVENESS
STATIC
EXPOSURE
RELIABILITY
THREAT ACTOR
CAPABILITIES
B9
Bx
VULNERABILITY
RISK REDUCTION
FACTOR
CONTACT
FREQUENCY
PROPENSITY
THREAT ACTOR
CAPABILITIES
DERIVED FROM HAZOP /
LOPA ANALYSIS RESULTS
LOSS OF
CONFIDENTIALITY
B2
By
FUNCTIONAL DEVIATION
CONSEQUENCE
SEVERITY
M
FUNCTIONAL DEVIATION
BUSINESS DEVIATION
DEVELOPED BUSINESS
SCENARIOS NOT PART OF
HAZOP / LOPA
THREAT EVENT
FREQUENCY
LIKELIHOOD (EVENT FREQUENCY) / PROBABILITY OF FAILURE ON ATTACK (PFA)
PROCESS DEVIATION
LOSS IMPACT RATING
RISK PRIORITY NUMBER
LOSS BASED RISK
The likelihood estimation is based upon:
4265
•
Threat actor
4266
•
Threat action
4267
•
Barriers (security measures)
4268
•
Vulnerability
4269
4270
4271
4272
4273
4274
4275
The diagram above shows the various risk factors that play a role in the quantitative estimate. The
model is based upon the FAIR methodology. The likelihood is expressed as an average frequency
that the cyber-attack succeeds to cause a functional deviation . The loss event frequency (LEF) is
the likelihood used for determining either a risk priority number or a loss risk. The first frequency
of importance is the threat event frequency (TEF), this frequency is a function of an assigned
initiating event frequency (IEF) for the TTP of the threat action and several risk factors that either
increase or decrease the TEF.
4276
4277
The Risk Reduction Number (RRN) depends on the effectiveness and reliability of the barrier,
where barrier effectiveness depends on the threat ac tor capabilities.
4278
LEF = RRN x TEF
4279
4280
4281
For evaluation of the results and communicating these to the stakeholders the method uses the
risk assessment matrix. For estimating a risk priority number, this requires converting the
(horizontal) likelihood scale and the (vertical) consequence severity scale into a qualitative value.
4282
4283
4284
4285
An example risk matrix using qualitative scales is shown below, the numbers in the matrix fields
are the risk priority numbers. The method divided the quantitative scale in five equal intervals,
determined in which interval the estimated LEF falls and uses the assigned weight as the value for
likelihood.
ISA-TR84.00.09-2023
- 186 -
Likehood
4286
No.
1
2
3
4
5
E
50
100
200
500
1000
4287
100
4288
Catastrophic
4289
100
250
500 4291
e.g., RPN = 5 x 50 = 250
4292
8
C
16
32
160 4293
80
4294
4
B
8
16
80 4295
40
8
Minor
50
16
Moderate
25
D
50
Major
Consequence severity (C)
4290
4296
0.5
A
1
2
5
10
4297
1
Negligible
4298
0.5
1
2
5
10
NOT FORESEEABLE
FORESEEABLE
EXPECTED
COMMON
CURRENT
4299
4300
4301
4302
4303
Estimating a loss risk is more complex because the likelihood scale then must match the defined
Target Mitigated Event Likelihood (TMEL) as defined for the losses. See risk criteria diagram in
section 0 for the definitions of the TMEL.
4304
4305
4306
4307
Many industrial installations pose a risk of potential fatalities, therefore the TMEL in a quantitative
cybersecurity risk assessment may be subject to local regulation. This requires that the
quantitative likelihood scale (expressed in events per annum) must match the quantitative
likelihood scale used by process safety in the LOPA process. See the example below.
A - Acceptable risk (Risk monitoring; Additional technical and / or organizational risk
reduction measures are not required but may be specified for implementation.)
TA - Tolerable-acceptable risk (Risk monitoring; Following ALARP principle - consider
implementation of additional technical and / or organizational risk reduction measures
if reasonable practicable; review alternative solutions).
TNA - Tolerable-unacceptable risk (additional technical and / or organizational risk
reduction measures shall be implemented on a date set separately).
NA - Unacceptable risk (stop the affected functions immediately and implement
additional technical and / or organizational risk reduction measures).
Consequence frequencies in events per annum
Loss categories
4308
Local community
Environment
Asset
TMEL
1
2
3
4
5
Fatality
Major injury
Environmental disaster
>= 20.000.000 €
Catastrophic
(C5)
1E10-5
TNA
NA
NA
NA
NA
C5
Many major injuries
Moderate injury
Major damage
< 20.000.000 € and >=
2.00.000 €
Major
(C4)
1E10-4
TA
TNA
NA
NA
NA
C4
Moderate injuries,
single major injury
Minor injury
Moderate damage
< 2.000.000 € and >=
100.000 €
Moderate
(C3)
1E10-3
TA
TA
TNA
TNA
NA
C3
Single injury
Smell, noise
Low impact noted in
report
< 100.000 € and >=
10.000 €
Minor
(C2)
1E10-2
A
TA
TA
TNA
TNA
C2
Minor injury
No impact
No impact
< 10.000 €
Negligible
(C1)
1E10-1
A
A
A
A
TA
C1
Consequence severity (C)
Personnel
1E10-5
1E10-4
1E10-3
1E10-2
1E10-1
NOT FORESEEABLE
FORESEEABLE
EXPECTED
COMMON
CURRENT
events per # annum
ISA-TR84.00.09-2023
4309
4310
4311
4312
4313
4314
- 187 -
In above risk assessment matrix, there are four risk levels defined (Acceptable (A), Tolerable (T),
Not Acceptable (NA)). In practice the number of risk levels varies because each level must have
a defined action. To determine how many risk levels are needed it is best to first make an inventory
of the decisions that need to be made, then the number of decisions translates into the number of
risk levels. In practice 4 or 5 risk levels are used.
ISA-TR84.00.09-2023
- 188 -
4315
D.4 CFATS Site Vulnerability Assessment
4316
Summary
4317
4318
4319
4320
4321
4322
4323
4324
Annex Type
Methodology
Methodology
applicability
Initial Cybersecurity Risk Assessment
Methodology objective /
background
CFATS is a regulatory program (6 CFR Part 27: Chemical Facility
Anti-Terrorism Standards (CFATS)) established in 2007 that
addresses chemical security by identifying and regulating high -risk
facilities that possess certain chemicals of interest (COI) at specific
concentrations and quantities.
(Assumes likelihood probability equals one, therefore this would be
considered an initial risk assessment.)
Methodology description / procedure
•
•
•
•
Compare chemicals handled, processed, or stored on site versus the chemicals of
interest in CFATS appendix A.
If CFATS applies, perform a site vulnerability assessment in accordance with the
regulatory instructions.
Document the results
Submit to the government agency
ISA-TR84.00.09-2023
- 189 -
4325
D.5 Consequence-driven, cyber-informed Engineering (CCE)
4326
Summary
Annex Type
Methodology
Methodology
applicability
Detailed Cybersecurity Risk Assessment
Methodology objective
The CCE methodology was designed to address discrepancies
between threat actor capabilities and existing operational
technology and information technology defenses. CCE evaluations
should leverage expertise from operational, cybersecurity, and
engineering domains, as well as threat intelligence (when
available). Although this approach can be utilized by both nascent
and advanced cybersecurity programs, those with established best
practices and robust cybersecurity programs will find the most
utility.
The primary goal of a CCE evaluation is to identify engineered
protections and mitigations that improve/ensure the resilience of
production capabilities. This process delivers the identification and
recommended implementation of targeted protections against
cyber-sabotage scenarios determined to have the greatest
potential for devastating impact.
Identified protections, mitigations, and implementations should be
evaluated for alignment with an organization’s risk values and
business strategy.
Additional background information can be found here:
•
https://www.osti.gov/biblio/1341416-consequence-drivencyber-informed-engineering-cce
•
https://www.osti.gov/biblio/1617458-cce-phaseconsequence-prioritization
•
https://www.osti.gov/biblio/1617457-cce-phase-systemsystem-analysis
•
https://www.osti.gov/biblio/1617456-cce-phaseconsequence-based-targeting
•
https://www.osti.gov/biblio/1617455-cce-phase-mitigationsprotections
•
https://www.routledge.com/Countering-Cyber-Sabo-tageIntroducing-Consequence-Driven-Cyber-Informed/Bochman-Freeman/p/book/9780367673710
4327
Methodology description / procedure
4328
4329
4330
4331
4332
4333
The CCE methodology employs four phases to identify: the critical functions of an organization,
potential cyber-sabotage scenarios that could disrupt delivery of those functions, the specific
adversary movements, and requirements necessary for attack success, and improvements to the
present implementation of PPT (people, process, technology) and support that serve to eliminate
or reduce the impact associated with each cyber -sabotage scenario.
• Phase 1: Consequence Prioritization
ISA-TR84.00.09-2023
4334
4335
4336
4337
4338
4339
•
•
•
- 190 -
Phase 2: System-of-Systems Analysis
Phase 3: Consequence-based Targeting
Phase 4: Mitigations and Protections
By focusing on critical functions and function delivery impacts, evaluators (and later defenders)
can best align limited resources to address the greatest production risk s to the organization.
Phase 1: Consequence Prioritization
4340
4341
4342
4343
4344
During this phase, evaluators define critical functions for their organizations and identify potential
cyber-sabotage events that could most impact delivery of those functions. Severity scoring
criteria are developed in alignment with the organization’s risk values and applied against each
event. Highest impact severity scoring documents the worst -case cyber-sabotage event(s) for the
organization, and these are identified as High Consequence Events (HCEs).
4345
The following procedure is recommended for identifying HCEs:
4346
4347
4348
1. Identify Critical Functions: Describe the actions or activities making up an organization’s
primary purpose or mission (e.g., bulk energy transport, telecommunications, data/content
services, industrial-scale production).
4349
4350
4351
2. Establish Baseline Assumptions: Ensure participants recognize that CCE evaluations
consider a well-resourced, determined, and knowledgeable adversary. For Phase 1
discussions, it is assumed that the adversary has also ac hieved access to targeted systems.
4352
4353
4354
4355
4356
3. Identify Scope and Boundary Conditions: Define any constraints or system exclusions
within the organization or business vertical (e.g., electric vs gas transmission, control
center vs field infrastructure vs station) . Define an evaluation objective that aligns with the
organization’s tolerance limit or threshold for critical function delivery impact (e.g., duration
and/or possibly breadth).
4357
4358
4359
4360
4361
4. Brainstorm Events and Scenarios: Consider past or potential impacts resulting fr om
human error, engineering failures, or natural events. Develop potential cyber -based events
with consideration to the ubiquity of some technologies within the operation, system
interdependencies, infrastructure or process critical nodes, and any producti on or business
activities that require automation for control.
4362
4363
4364
5. Develop Scoring Criteria: Determine and define impact criteria and severity thresholds
for scoring cyber-attacks scenarios. Identify weighting coefficients for criteria, as necessary,
to reflect organizational business priorities more closely .
4365
4366
4367
4368
6. Score Scenarios: Apply the previously defined Severity Criteria against the cyber sabotage events to identify those that have the potential for greatest impact to critical
function delivery. These high-scoring items are the HCEs that will be evaluated in the
remaining CCE phases.
4369
Phase 2: System of Systems Analysis
4370
4371
4372
4373
4374
4375
4376
4377
4378
4379
4380
Within the scope of each HCE, evaluators identify the people, processes, technology, and services
(supply chain, etc.) presently implemented for delivery of the targeted critical function. Evaluations
consider the full life cycle for the process, process support, and deployed technologies from design
through procurement, installation, maintenance, and decommissioning, as any one of these can
present exploitation and impact opportunities for the adversary. The process also takes into
consideration embedded dependencies and “unverified trust” that could be leveraged in the HCE.
Phase 3: Consequence-based Targeting
During this phase, the evaluators refine and develop the targeting requirements an adversary
would need to successfully carry out the HCE. This includes identifying the adversary’s technical
approach (access, actions, timing/triggering) to quantify “how” t o achieve a specific impact against
a target.
ISA-TR84.00.09-2023
- 191 -
4381
4382
4383
4384
4385
4386
4387
Although the CCE process is primarily focused on the potential impacts of cyber -attacks or cyberenabled sabotage, Phase 3 introduces the first concepts of attack probability or likelihood.
Scenarios of concern must be deemed feasible or within the realm of the possible. By identifying
the adversary technical approach in detail, the analysis team may eliminate some events as they
are not achievable via cyber means. Most commonly this elimination occurs followin g the
identification of a physical or mechanical stopgap that is not controllable or alterable (i.e.,
unhackable). In these cases, the probability of the event occurring is considered zero.
4388
4389
4390
4391
4392
4393
Remaining events and associated adversary technical approach are accessed to identify those
that are most likely. This is enabled through an evaluation of the relative complexity of the technical
approach combined with a review of existing threat actor capabilities. Technical approaches that
are less complex (e.g., require fewer steps, do not leverage state or conditional triggering) are
assessed more likely. The analysis team collectively assigns probability scores to these technical
approaches:
4394
1. Almost no chance/remote (01-05%).
4395
2. Very unlikely/highly improbable (05-20%).
4396
3. Unlikely/improbably (20-40%).
4397
4. Roughly even chance/roughly even odds (45-55%).
4398
5. Likely/probable (55-80%).
4399
6. Highly likely/highly probable (80-95%); and,
4400
7. Nearly certain (95-99%).
4401
4402
4403
4404
4405
4406
4407
4408
Analytic teams should also investigate the degree to which cyber actors have been observed
pursuing capabilities or access related to the adversary technical approach. Previous releases of
business sensitive information or cyber intrusions may indicate that a cyber actor has collected
the critical information needed for cyber-enabled sabotage. Depending on the existing security
posture of the organization, the evaluators may choose to eliminate blended cyber -attacks, or
those which can be accomplished via supply chain or human -enabled means, such as insider
attacks. Organizations with more nascent security programs may choose to focus on “cyber -only”
scenarios, in which an attacker conducts remote network -based actions only.
4409
Identify Adversary’s Critical Information Needs
4410
4411
4412
4413
4414
4415
4416
4417
4418
4419
4420
4421
4422
4423
4424
Successful attack operations require that an adver sary understand the technologies and
technology implementation/operation/support as well as people, processes, and services that are
employed and unique to the targeted organization, The adversary must acquire the information
and build understanding around its use and support to sabotage it. The amount of critical
information needed for an attack is related to the target objective and target environment
complexity. In many cases, an attack against the core of an ICS may require somewhat creative
access mechanisms beyond traditional ideas around “connectivity”. As demonstrated in 2013
during the Havex campaign, in 2017 during the Nuclear 17 targeting, and in 2020 during the Solar
Winds compromise, the adversary may choose to initially exploit an environment, service, system
or platform/device outside of the primary target organization. This approach can enable alternative
access methods beyond traditional network-based operations. Acknowledging flexibility in
adversary approach options is a key theme in Phase III. To properly protect critical function delivery,
CCE encourages the identification of relevant information artifacts both within and beyond the
organization’s boundaries. Additional security precautions can be taken for critical information that
exists (intentionally or unintentionally) outside the organization’s area of control.
4425
4426
4427
4428
4429
Phase 4: Mitigations and Protections
The evaluators realize CCE’s fundamental goal in Phase 4, during which potential mitigation and
protection strategies are investigated. Ideally, “protections” are put in place that render the subject
HCE cyber-sabotage event unfeasible (e.g., hard-wired vibration sensors to disrupt malicious
operation of motors). In some cases, engineered process or process control protections may not
ISA-TR84.00.09-2023
4430
4431
4432
4433
4434
4435
- 192 -
be viable. In these instances, the organization should focus on enhanced detection and response
capabilities to reduce potential impacts from each HCE. These measures are known as
“mitigations.” Additional benefit includes increasing the cost (effort, financial) of cyber-enabled
sabotage for the adversary. These secondary options correlate to three of the NIST CSF Functions,
“Detect,” “Respond,” and “Recover.”
ISA-TR84.00.09-2023
- 193 -
4436
D.6 Security PHA Review for Consequence Based Cybersecurity
4437
Summary
Annex Type
Template and Methodology
Methodology
applicability
Initial Cybersecurity Risk Assessment
Methodology objective /
background
The Security PHA Review for Consequence Based Cybersecurity
method uses the wealth of information derived from a traditional
PHA using the cause by consequence technique coupled with layers
of protection analysis to determine the Security Level - Target (SLT) of a Safety Instrumented System (SIS) implementing a Safety
Instrumented Function. Complete guidance is provided in the ISA
book, "Security PHA Review for Consequence- Based
Cybersecurity," by Edward Marszal and Jim McGlone.
4438
Methodology description / procedure
4439
4440
4441
4442
In a HAZOP, the PHA team examines the deviations to the design intent and ensures there are
appropriate safeguards to prevent the c onsequence of concern. The team makes
recommendations to modify the process to make it inherently safer, improve the existing
safeguards, or add a protection layer if the degree of safeguarding is inadequate.
4443
4444
4445
4446
4447
While the above process systematically and thoroughly assesses potential hazard scenarios, it
does not ensure that a plant is inherently more secure against cyberattacks. A malicious attack
could disable the safeguards or potentially initiate the cause. The Security PHA Review for
Consequence Based Cybersecurity study is a methodology that can be used during or after a PHA
to perform the review of security issues that are pertinent to the PHA.
4448
4449
4450
4451
4452
4453
4454
4455
A PHA scenario can define an attack scenario by deliberately generating the cause (initiating event)
while disabling the relevant safeguards through external control of industrial control system (ICS)
equipment. In the Security PHA Review for Consequence Based Cybersecurity method, the PHA
team reviews each PHA scenario to determine any vulnerable pathway to cyber attacks. If a
hackable path does exist, then the PHA team recommends an inherently safer safeguard (non hackable), Or, if it is not feasible to provide a non -hackable protection layer, the team determines
the Security Level – Target (SL-T) for the ICS equipment based on the Company's tolerable risk
criteria.
4456
4457
The flowchart in Figure D.3 provides a work process for the Security PHA Review for Consequence
Based Cybersecurity study procedure.
4458
ISA-TR84.00.09-2023
- 194 -
4459
4460
Figure D.3 Security PHA Review for Consequence Based Cybersecurity Study Flowchart
ISA-TR84.00.09-2023
4461
4462
4463
The documentation for the Security PHA Review for Consequence Based Cybersecurity study
method can take on many forms including adding columns to the PHA scenario format as shown
in Figure D.4 below.
Scenar
io
Ref.
4464
- 195 -
Initiating Event (Cause)
description
Locati
on
Hackable
(Yes/No)
Zon
e
Safeguard (SG)
Descripti
on
Hackabl
e
Locatio
n
All
SG
Hackable
?
(Yes/No)
Zon
e
Scenario
Hackable
(Yes/No)
Consequence
Descriptio
n
S
L
Catego
ry
Figure D.4 - Security PHA Review for Consequence Based Cybersecurity report document
4465
Example Security PHA Review for Consequence Based Cybersecurity Study
4466
4467
4468
To illustrate the Security PHA Review for Consequence Based Cybersecurity study process, two
PHA scenarios, one non-hackable scenario and another with hackable scenario, are discussed in
the following sections.
4469
Non-Hackable scenario
4470
4471
For the purposes this methodology, a scenario is considered non-hackable if a pathway
vulnerable to a malicious cyberattack cannot lead to an unwanted scenario consequence.
4472
4473
4474
Consider a hypothetical scenario from a PHA study, where the consequence is “potential for gas
blow-by into the Low- Pressure (LP) separator V-102, resulting in overpressure of the LP Separator,
the potential for loss of mechanical integrity, rupture, loss of containment, explosion and fire.”
4475
4476
The cause of the scenario, as documented in the PHA, is “ failure of control loop upstream of the
Low -Pressure Separator such that the control valve is too much open.”
4477
The PHA documented safeguards are:
4478
4479
•
•
A Relief valve in the LP Separator sized for gas blow -by.
Low level in the upstream HP Separator closing the LP Separator inlet shutdown valve.
4480
4481
4482
4483
The first step is to review the cause whether it can be hackable in the context of this methodology.
In the above scenario, the flow control valve upstream of the LP Separator (the cause) is
considered hackable because it can be controlled through a PLC and could be manipulated by
cyber means.
4484
4485
4486
4487
4488
4489
4490
4491
Since the cause could be created by a hacker, the next step is to review all the protection layers
listed for the above scenario and identify if any non -hackable safeguard exists. In the above
scenario, the relief valve safeguard is a mechanical device that is non-hackable. Even though the
safeguard “Low level in the upstream HP Separator closing the LP Separator inlet shutdown valve ”
is a SIF implemented in the SIS can be hacked, the scenario is considered non -hackable because
at least one safeguard cannot be controlled by cyber means, e.g., mechanical device. For example,
if the scenario includes “operator inadvertently open a mechanical bypass valve,” then the cause
is non-hackable, and therefore, the scenario is considered non-hackable.
4492
4493
4494
4495
Considering the above Security PHA Review for Consequence Based Cybersecurity study, this
Zone of ICS components, as defined in ISA 62443, would rely on traditional cybersecurity
measures without any special requirements. Refer to Fig ure D.5 for the Security PHA Review for
Consequence Based Cybersecurity documentation for the above scenario.
Scenar
io
Ref.
Node 5,
Dev 1
descriptio
n
Initiating Event (Cause)
Locatio
n
Zon
e
Hacka
ble
(Yes/N
o)
failure
of
control
loop
upstream
of the Low Pressure
Separat or
such
that
the control
valve is too
much open
DCS
1
Yes
Safeguard (SG)
Description
Relief valve in
the
LowPressure
Separat or
sized f or gas
blow-by
Low level in
the upstream
HP Separator
closing the LP
Locatio
n
Zon
e
Hacka
ble
(Yes/N
o)
All
SG
Hackabl
e?
(Yes/No)
Scenar
io
Hacka
ble
(Yes/N
o)
-
-
No
No
No
SIS-1
1
Yes
Consequence
SL
Description
Cate
gory
potential for gas
blow-by int o t he
LowPressure
(LP)
separat or
V-102, resulting
in overpressure
of
the
LP
Separat or,
potential for loss
of
mechanical
int egrity,
High
Note
1
ISA-TR84.00.09-2023
Scenar
io
Ref.
- 196 -
Initiating Event (Cause)
descriptio
n
Locatio
n
Zon
e
Hacka
ble
(Yes/N
o)
Safeguard (SG)
Description
Locatio
n
Zon
e
Hacka
ble
(Yes/N
o)
All
SG
Hackabl
e?
(Yes/No)
Scenar
io
Hacka
ble
(Yes/N
o)
Separat or inlet
shut down
valve
operat or
inadvertent
ly open a
mechanical
bypass
valve
4496
1
No
Relief valve in
the
LowPressure
Separat or
sized f or gas
blow-by
Low level in
the upstream
HP Separator
closing the LP
Separat or inlet
shut down
valve
-
-
No
SIS-1
1
Yes
No
No
Description
rupt ure, loss of
cont ainment,
explosion,
and
fire.
potential for gas
blow-by int o t he
LowPressure
(LP)
separat or
V-102, resulting
in overpressure
of
the
LP
Separat or,
potential for loss
of
mechanical
int egrity,
rupt ure, loss of
cont ainment,
explosion,
and
fire.
SL
Cate
gory
High
Note
1
Note1: No special requirements for security measures
4497
4498
4499
Field
Consequence
Figure D.5 - Non-Hackable Scenario - Security PHA Review for Consequence Based
Cybersecurity documentation
Hackable Scenarios
4500
4501
4502
For the purposes this methodology, a scenario is considered hackable if a pathway
vulnerable to a malicious cyberattack can lead to an unwanted scenario consequence by
overriding the cause and all safeguards for the scenario.
4503
4504
4505
Consider two hypothetical scenarios from a PHA study, where the consequence is “potential overfill
of the LP Separator, potential liquid carryover to Export Gas Compressor, potential compressor
damage, potential fire, explosion, equipment damage, and personnel injury.”
4506
The causes of the scenarios, as documented in the PHA, are:
4507
4508
4509
•
•
Failure of control loop in the gas outlet of the LP Separator such that the control valve is
too much closed.
Failure of shutdown valve in the closed position in the gas outlet.
4510
4511
4512
4513
The PHA documented safeguards for both the causes are:
• High level shutdown closes inlet feed valves.
• Operator response to shut down the compressor on low flow alarm in the LP Separator
gas outlet line.
4514
4515
4516
4517
4518
4519
4520
4521
4522
4523
4524
4525
4526
4527
4528
4529
4530
In the above example, the causes and the safeguards are hackable because they reside in a PLC.
For instance, even the low flow alarm could be overridden in the PLC, so they alarm never sounds.
Therefore, there is a high potential for creating the scenarios because of cyberattack by
deliberately manipulating the causes and simultaneously disabling the safeguards. The above
cyberattack can cause the consequence of concern. The hackable scenarios must be assessed
considering the severity of the consequence. The severity category is “High ,” and as per the
example risk tolerance criteria given in the Figure D.7, the Security Level for the ICS components
in the specified Zone will be SL 2. Refer to Figure D.6 for the Security PHA Review for
Consequence Based Cybersecurity documentation for the above scenarios.
After assessing all scenarios in a specific Zone, the analyst identifies the highest SL -T in the
specified Zone. The above SL-T target becomes requirements for the zone in developing the
cybersecurity measures for the specified zone. If a given zone is part of many PHA studies, then
the SL-T assigned to the zone would be the highest SL-T of any hackable scenario considering all
PHA studies for the equipment.
ISA-TR84.00.09-2023
Scenar
io
Ref.
Node 5,
Dev 4
4531
4532
- 197 -
descriptio
n
Initiating Event (Cause)
Locatio
n
Zon
e
Hacka
ble
(Yes/N
o)
Failure of
control
loop in the
gas outlet
of the LP
Separat or
such
that
the control
valve is too
much
closed
DCS
1
Yes
Failure of
shut down
valve in the
closed
position in
the
gas
out let
SIS-1
1
Yes
Safeguard (SG)
Locatio
n
Zon
e
Hacka
ble
(Yes/N
o)
All
SG
Hackabl
e?
(Yes/No)
Scenar
io
Hacka
ble
(Yes/N
o)
High
level
shut down
closes
inlet
feed valves
SIS-1
1
Yes
Yes
Yes
Operat or
response
to
shut down the
compressor on
low flow alarm
in
the
LP
Separat or gas
out let line
DCS
1
Yes
High
level
shut down
closes
inlet
feed valves
Operat or
response
to
shut down the
compressor on
low flow alarm
in
the
LP
Separat or gas
out let line
SIS-1
1
Yes
Yes
Yes
DCS
1
Yes
Description
Consequence
Description
Catego
ry
potential
overf ill of the
LP Separator,
potential liquid
carryover
to
Export
Gas
Compressor,
potential
compressor
damage,
potential fire,
explosion,
equipment
damage, and
personnel
injury
potential
overf ill of the
LP Separator,
potential liquid
carryover
to
Export
Gas
Compressor,
potential
compressor
damage,
potential fire,
explosion,
equipment
damage, and
personnel
injury
High
High
SL
SL2
SL2
Figure D.6
Hackable Scenario - Security PHA Review for Consequence Based Cybersecurity documentation
S
0
Category
None
1
Very Low
2
Low
3
Moderate
4
High
Safety
No
significant
safety
consequence
Minor injury- first aid
needed
Lost time- injury (not
requiring
extended
hospitalization)
Severe injury (extended
hospitalization,
dismemberment)
Single fatality
5
Very High
Multiple fatalities
6
Very-very
High
Multiple off-site fatalities
4533
4534
Environment
None
Commercial
None
TMEL
N/A
SL
1
Small release with minimal cleanup
requirements
Moderate release limited to on-site
damage with moderate cleanup
effort
Large release with limited off-site
impact; requires significant on-site
cleanup
Large release off-site with extensive
cleanup and damage to sensitive
areas
Very large release off-site with
extensive cleanup and permanent
damage to several sensitive areas
Very-very large release off-site with
extensive cleanup and ongoing
remediation for many years along
with permanent damage to many
sensitive areas
$50,000
1E-02
1
$500,000
1E-03
2
$5M
1E-04
2
$50M
1E-05
2
$500M
1E-06
3
$5billion
1E-07
4
Figure D.7 - Example Consequence Categories with SL
(For demonstration purpose only extracted from the referenced ISA book)
4535
D.7 Cyber PHA Risk Assessment
4536
Summary
Annex Type
Methodology
Methodology
applicability
Detailed Cybersecurity Risk Assessment
Methodology objective /
background
Cyber process hazard analyses follow a systematic, safety -oriented
methodology to conduct a cyber security risk assessment of an
ISA-TR84.00.09-2023
- 198 -
industrial control or safety system. The methodology integrates
multiple engineering disciplines, including process safety, industrial
automation, industrial IT, and cyber security. It leverages
established process safety management methodologies and uses
that information to perform a Cyber PHA, using HAZOP like
worksheets. It delivers a risk ranked mitigation plan that typically
includes both cyber and non-cyber safeguards and security
measures. It also provides a methodology for meeting the security
requirements called out for in the ISA/IEC 61511 standard.
4537
4538
Methodology description / procedure
Methodology overview
4539
4540
4541
4542
4543
4544
This methodology is like a HAZOP; however, the methodology evaluates cyber nodes that
represent the cyber assets that are part of the zone and conduit design. Although the concern is
with the process safety controls, alarms, and interlocks, the entire OT plant network including all
internet and wireless access points, including 3rd party connections, networks, OT cloud services,
and devices should be addressed in so far as they can be pathways to compromise the IACS, or
provide some level of risk reduction via the defense in depth strategy.
4545
4546
4547
4548
4549
4550
4551
4552
The typical process hazard analysis (PHA) has a much greater d egree of granularity than a
cybersecurity PHA. In a PHA, individual control loops are considered as potential cause of a hazard
whereas in a cyber PHA, an entire process control system or sub system(s), ( e.g., engineering
workstation, specific PLC, asset management system, field device(s), etc.) consisting of multiple
loops would be considered all at once. Non-cyber causes are more predictable as the common
mode failure of an entire controller would result in all outputs failing the same way, whereas a
cyber-attack is insidious as it can cause different outputs to respond , resulting in a worst-case
consequence.
4553
4554
4555
4556
4557
4558
4559
4560
4561
The final difference is that the PHA will consider safeguards that may or may not be vulnerable to
cyber-attack. A cyber PHA generally has no practical means to consider safeguards that are not
vulnerable to cyber-attack during the hazard identification portion of the cyber PHA due to the
different levels of granularity of what is being reviewed. For instance, if a control failure resulted
in high pressure, a relief valve might be listed as a safeguard in a HAZOP. In a cyber PHA it is not
practical to consider this as it does not look at individual loops, but all the loops, alarms, interlocks
that may be contained in a single process control system. Onc e the major hazards have been
identified, it would be reasonable to consider some safeguards that are not vulnerable to a cyber attack on an exception basis.
4562
Procedure
4563
1. Leverage the PHA
4564
4565
4566
4567
4568
After the traditional PHA has been performed, it is recommended to consider whether initiating
causes and safeguards are potentially vulnerable to cyber -attack. Those that are not vulnerable
do not need to be considered in the cyber risk assessment. For those that are vulnerable, the
ultimate consequence should be noted. These consequences can be ranked into appropriate
categories to be considered in the detailed cyber risk assessment.
4569
4570
4571
4572
4573
4574
4575
4576
The exercise to determine these consequences of concern can be performed by reviewing the
HAZOP or by preferentially going through the exercise with the layer of protection analysis (LOPA)
if performed. If an adequate level of LOPA has been performed, it is more efficient to use these as
they typically cover the major hazards of concern. It is not necessary to evaluate every ha zard in
a detailed cyber risk assessment as once the process control and SCAI systems are protected
against major hazards, they would also be protected against the lesser hazards. Tables D4 and
D.5 show detailed procedures to leverage the PHA in this manne r for HAZOP and LOPA
respectively.
ISA-TR84.00.09-2023
- 199 -
4577
4578
Alternatively for this step, the results from a PHA that used the “Security PHA Review for
Consequence Based Cybersecurity” methodology documented in section A7 could be used.
4579
4580
Table D.4
Procedure for leveraging the PHA ̶ HAZOP
Major procedural step
Detailed step
Perform traditional PHA.
Use company HAZOP procedures.
Excerpt high risk cause
consequence pairs.
Filter worksheet data to only include high
risk consequence severities.
Comments
There is no credit for any
safeguards at this point.
Export the following data fields:
Discard those causes not
susceptible to cyber
influence.
•
Cause
1.
Consequence
•
Severity
2.
Safeguards
•
PHA recommendations
3.
Comments
•
Sort the report by descending
consequence severities
Review each cause.
If it can be caused by a cyber-attack indicate
“yes”
If it is not vulnerable to cyber-attack,
indicate “no”
Filter the report to only show those cause
consequence pairs that are susceptible to
cyber-attack.
Identify safeguards not
susceptible to cyber
influence.
Review the safeguards for remaining causes
as to susceptibility to cyber-attack.
If it can be manipulated by a cyber-attack
indicate “yes.”
If it is not vulnerable to cyber-attack,
indicate “no”
Filter the report to only show those
safeguards that are not susceptible to cyberattack.
Perform revised risk ranking.
Update likelihood of cause.
Update likelihood with safeguards.
Only take credit for safeguards
not susceptible to cyber-attack.
Update risk ranking.
Sort revised worksheet by risk in descending
order.
Provide sorted worksheet to
cyber risk assessment team.
Risk ranking is based on the
potential consequence and the
likelihood of cyber threat being
perpetrated and failure of the
safeguards not susceptible to
cyber-attack for the specific risk
receptor category.
The risk ranked worksheet is to
be used by the cyber risk
assessment team to:
•
Improve estimate of actual
consequences and severity.
4.
Achieve improved granularity
of risk when credit for
cybersecurity security
measures is assessed.
ISA-TR84.00.09-2023
4581
4582
- 200 -
Table D.5
Procedure for leveraging the PHA ̶ LOPA
Major procedural step
Detailed step
Comments
Perform traditional PHA.
Use company LOPA procedure.
Evaluate all high
consequence severities.
Company to define what constitutes a high
consequence severity
There is no credit for any
safeguards at this point.
Discard those initiating events
(IE) not susceptible to cyber
influence.
Review each initiating event.
Treat high demand as one per
year as a matter of convenience.
If it can be caused by a cyber-attack assume
high demand
If it is not vulnerable to cyber-attack, then IE
frequency = 0/year.
Identify safeguards not
susceptible to cyber
influence.
Review the IPLs for remaining initiating
events as to susceptibility to cyber-attack.
If it can be manipulated by a cyber-attack
assume PFD =1.
If it is not vulnerable to cyber-attack, use
PFD for that safeguard.
Recalculate hazard
frequency.
Perform LOPA calculations with applicable
IE frequency and safeguard PFDs.
Only take credit for safeguards
not susceptible to cyber-attack.
Provide sorted hazard
frequencies to cyber risk
assessment team.
Categorize LOPAs by consequence severity
in descending order, i.e., highest severity to
lowest severity.
The sorted information is to be
used by the cyber risk
assessment team to:
Within each category, list hazard
frequencies in descending order, i.e.,
highest frequency to lowest frequency.
4583
4584
4585
4586
4587
4588
4589
4590
4591
4592
4593
4594
4595
4596
•
Improve focus of cyber
review with respect to most
significant risks.
5.
Achieve improved granularity
of risk assessment when
credit for cybersecurity
security measures is
evaluated.
2. Risk assessment preparation
Prior to the start of the detailed cyber risk assessment, key process safety information should be
obtained. This information includes:
•
•
•
•
Results from the traditional PHA as leveraged in step 1.
Complete list of cyber assets (should be available from the high-level cyber risk
assessment or a vulnerability assessment).
Zone and conduit drawings that show:
o Zone location for each cyber asset.
o Means of communication between zones.
Known security measures that exist or are included in new project scope
Once the requisite information is available the tool/worksheet being used to conduct the review
should be organized to list the zones and assets within each zone before the full team meets.
Figure D.8 shows a conceptual example of a zone and conduit drawing using the hierarchy
approach from ANSI/ISA-95.00.01.
ISA-TR84.00.09-2023
- 201 -
4597
4598
4599
Remote Access Zone (Z2)
On Site Enterprize Zone (Z0)
Level 4
Network Protection
Sub Zone
Shared Functions Sub Zone
Hist-1
RSW01
DS-1
SW ADM1
DataH-1
FW-1
Remote Engineering
Sub Zone
Compressor
Service Provider
Support
Cloud Sub Zone
C2
Sub Zone
Rem EWS
C1
DMZ Zone (Z3)
Remote access sub
zone
Historian Sub Zone
Level 3.5
HC-1
Shared functions Sub Zone
JS-1
FW-2
DS-2
RSW02
Level 3
Level 2
Supervisory Control
Zone (Z5)
HMI Sub Zone operations
OWS-1
OWS-2
C3
Operations Management Zone (Z4)
Process Optimization (FUTURE)
Shared Functions
Sub Zone
SW03
SG-1
HMI Sub Zone maintenance / engineering
EWS-1
EWS-2
AMS-1
PR1
C4
C5
Control Zone (Z6)
Level 1
PU-1
SIS Control Zone (Z8)
Shared Functions Sub Zone
Compression Sub Zone
BR-2
SW02
RA-2
HMI Sub Zone engineering
Potential Future
SIS Control Sub Zone
SIS-1 Controller
LD1
BPCS-1
Shared Function
Sub Zone
SW04
C7
Process Control Sub Zone
C6
C8
Level 0
4600
4601
4602
BPCS Field
Zone (Z7)
NON-SIS Sensors
& Final Elements
SIS Field Zone (Z9)
Sub Zone
C1 Calibrator
M1
SIS Sensors &
Final Elements
Zones Rev 1
Figure D.8 - Zones and cyber nodes example
(Taken from ISATR84.00.09 part 2 case study currently under development)
Shared Function
Sub Zone
SW01
ISA-TR84.00.09-2023
4603
4604
4605
- 202 -
3. Perform the detailed level cyber risk assessment
Utilize a qualitative HAZOP type approach to perform the cyber risk assessment. A summary of
the method is included below:
4606
4607
4608
4609
4610
4611
4612
1.
2.
3.
4.
5.
6.
7.
Select a zone
Select cyber node, e.g., a cyber asset.
Identify and record a cyber threat.
Identify and record causes.
Identify and record qualitative cause likelihood (without any credit for security measures).
Identify and record consequences (without any credit for security measures).
Determine and record qualitative severity of consequences.
4613
4614
NOTE Consequences may have been identified and / or quantified in the traditional PHA. If this is the case, this
information should be used as applicable.
4615
4616
4617
4618
8.
9.
10.
11.
4619
4620
4621
NOTE Security level verification is not part of the risk assessment methodology but should be performed after the
review for high severity hazards to ensure that the identified security measures are sufficient to provide the risk
reduction needed to satisfy corporate risk criteria.
Identify and record security measures applicable to the cyber threat and cause.
Document the security level requirement for the threat vector.
Determine and record qualitative likelihood (with existing security measures).
Determine if risk is tolerable per risk criteria. If not make recommendation(s).
4622
D.8 CHAZOP (Integrated safety / security)
4623
Summary
Annex Type
Methodology
Methodology
applicability
Initial Cybersecurity Risk Assessment and Detailed Cybersecurity
Risk Assessment
Methodology objective /
background
To identify risks to the facility that may originate or exist within the
Process Control and Safety System (PAS) due to design,
vulnerabilities, failures, or abnormal conditions of the PAS itself.
Process HAZOP is expected to identify risks due to individu al field
instrument and loop-level failures, whereas CHAZOP is expected
to identify risks that would originate from within the PAS or the
PAS’s response to a plausible outside disturbance or abnormal
condition, including Cybersecurity threats . CHAZOP is typically
conducted using the control system architecture, and it is identified
functional nodes for what-if evaluation of internal and external
events (deviations) that could produce a hazardous response or
event because of the PAS response, or lack of prop er response to
the considered initiating event. Key utilities, environmental
conditions and geographical locations t will also be considered for
potential deviations that may affect the PAS, such as electrical
power, instrument air, HVAC, proximity to other threat sources
such as flare radiation, etc.
The checklist and potential deviations for consideration are not a
closed set of conditions. Each category and case to attempt to
stimulate thought and discussion about plausible “what if”
scenarios and deviations that would be expected or possible that
may affect the PAS. Details are added as required to develop
more refined deviation cases through the collective input from the
group during a CHAZOP exercise.
ISA-TR84.00.09-2023
- 203 -
For initial (high-level) risk analysis, entire systems/sub-systems
are typically used as the nodes for analysis.
4624
4625
Methodology description / procedure
4626
4627
4628
4629
4630
4631
4632
4633
CHAZOP is a nodal potential deviation analysis methodology, where a SuC is subjected to
systematic “what-if” analysis of the potential consequences and outcomes of various deviations
from normal / design operating conditions. For Industrial Control systems that control processes
that have potentially hazardous physical/process consequences of control system failure or mis operation, these consequences are evaluated for risk severity and requirement for mitigation . Risk
evaluation typically applies the facility owner’s Risk Tolerance criteria for these types of outcomes,
and as such may be aligned with Process Hazard Assessment, HAZOP, or LOPA consequence
data.
4634
4635
4636
Input Documents
The following documents are typically required to plan and carry out a CHAZOP Risk
Assessment:
4637
4638
4639
•
System Architecture diagram, with clear delineation or depictions of the major subsystems
comprising the SuC (for initial assessments). For detailed assessments, a Zones and
Conduits diagram is typically used.
4640
4641
4642
4643
4644
4645
•
A System List or Index. A list of principal systems and types of network and computing
devices to be used in the SuC. This will be an early stage of the Hardware and Software
Asset Registers to be developed later in the cybersecurity design process . For Initial Risk
Assessment, individual subcomponents of major subsystems may not be considered, but
subsystems as a whole (e.g., Basic Process Controllers and I/O, Safety Instrumented
System and I/O, Third-Party PLC systems).
o
4646
The list should identify:
4647
• Vendor of each subsystem or major computing component
4648
• Model/Brand/Series of Equipment
4649
• Operating Systems used for engineering, configuration, operation
4650
4651
•
Process Flow Diagrams, showing major unit operations for reference as to process
equipment and potential process risks.
4652
4653
•
Owner-provided Risk Assessment Procedure and Risk Matrix, with definitions of
Consequence and Likelihood (frequency) criteria for evaluation and ranking.
4654
4655
4656
4657
4658
•
Facility Plot Plans with locations of key control system equipment highlighted or indicated
on the plot plan. Google Earth with color-coded pins for various zone equipment locations
or key buildings, I/O buildings is recommended practice, as it allows “fly in” and inte ractive
viewing during planning and risk assessment related to physical security or location -driven
potential for common cause failures.
4659
4660
•
HAZOP and/or LOPA reports for reference and use in identifying potential consequences
of system failures.
4661
Planning and Preparation
4662
4663
For new construction projects, it is preferable to conduct the Risk Assessment after a HAZOP or
LOPA. This ensures consistency in consequence definition when it relates to loss of containment
ISA-TR84.00.09-2023
- 204 -
4664
4665
or process upset. For brownfield projects, historical (ideally current) HAZOP/LOPA report
information should be used for alignment / calibration of consequences of failures.
4666
4667
With the input documents, the following preparatory steps are typically required to prepare for a
CHAZOP evaluation workshop:
4668
4669
4670
4671
•
Develop a CHAZOP Nodes list. Using the system architecture (high-level assessment) or
Z&C diagrams (detailed assessment) and the Network Nodes list, generate a nodes list
using a CHAZOP Nodes and Deviations Worksheet Template extracted from the PHA
software.
4672
4673
•
Consolidate components into nodes based on location and common risks ( e.g., Controllers,
Local I/O and Controller Firewalls in a common Zone as a single CHAZOP node).
4674
4675
4676
•
Where location of components of the system within a zone are in separate locations (e.g.,
Remote I/O located in Field separated from controllers), consider remotely located systems
or components as a separate CHAZOP node.
4677
•
List each Zone-to-Zone conduit as a separate node.
4678
4679
4680
4681
4682
•
Add specific stations or controllers/system where higher potential risks are envisioned as
individual nodes to consider above and beyond “typical” stations in the same zone ( e.g.,
equipment outside of physical access controls, PLCs, etc. outside of fence line or accesscontrolled buildings, systems with external or dual home -network connections, systems
accessed or maintained by others or with uncontrolled computers or media).
4683
4684
4685
4686
4687
4688
•
Review provided PHA and/or LOPA results and identify cases that do not include any non control or safety system IPLs, where failure of the computer -based system would result in
a compromise of credited layers of protection without non -instrumented layers of protection
(e.g., no preventative mechanical layers of protection) . These will be target cases for
evaluation in the high-level CHAZOP, with the potential consequences cited in the PHA or
LOPA as potential consequence of system compromise.
4689
4690
4691
•
Prepare a CHAZOP Terms of Reference document, incorporating owner standards (Risk
Criteria and Matrix), Z&C (if developed for detailed assessment), Nodes, Deviations
worksheets, plot plan or Google Earth site maps .
4692
4693
4694
•
Have the PHA scribe prepare for the CHAZOP and pre-populate PHA software with the
information from a pre-populated CHAZOP Nodes and Deviations Worksheet. Provide the
scribe with a copy of the Terms of Reference and the supporting planning input worksheets.
4695
4696
4697
4698
•
Issue the terms of reference document as Issued for Review with the owner, for comments,
planning and coordination for participants and scheduling. Coordinate with the customer
for scheduling of the meeting, timing location, participants, using the terms of reference
document as a reference document.
4699
Assessment Execution
4700
4701
4702
4703
4704
CHAZOP assessments are typically conducted in a “workshop” environment, where subject matter
experts are gathered physically, virtually or a combination thereof. In the workshop, the group will
be facilitated through the “what-if” considerations of the potential deviations on the identified nodes.
•
Open the first day of the CHAZOP with a campus safety briefing, introductions, and an
overview of the CHAZOP process.
ISA-TR84.00.09-2023
- 205 -
4705
4706
4707
•
Before beginning the first node, provide a brief walk -thorough of the Deviations list, with a
high-level “why” and “what we are looking for” for each of the classes of deviations, looking
for scenarios which could result in worst-case consequences as identified in HAZOP/LOPA.
4708
4709
4710
•
Direct the considerations in each node to the highest plausible consequence case, such as
unit with highest potential for Safety, Environmental, Asset or Production loss impact when
considering the general node types.
4711
4712
•
Document the agreed potential consequences, validated safeguards using the PHA
software.
4713
4714
4715
•
Generate mitigation recommendations where resulting Residual Risk ranking is above
Tolerable threshold, following the owner Risk Management / PHA proced ures. Capture
recommendations in the PHA software.
4716
4717
•
Close each day reviewing the Recommendations, completed node list / count, Parking Lot
Observations / Recommendations and starting point for the next day.
4718
4719
4720
4721
•
If the workshop is longer than four days, issue a n interim draft copy of the Nodal Scenario
report from the PHA software for initial review and checking every fourth day (once per
working week). This allows for timely, in-process checking for errors in data capture,
clarification, and validation of the results.
4722
4723
4724
4725
•
At the end of the workshop, produce a report with executive summary, highlighting statistics,
significant findings, recommendations, and action items from the assessment.
Recommendations should have a clearly assigned owner, and due date for dispos ition of
recommendations.
4726
4727
•
CHAZOP data, report, Recommendations and Action item lists or databases, including
native data files from PHA software should be formally handed over to the owner.
4728
4729
ISA-TR84.00.09-2023
- 206 -
4730
D.9 Cyber Kill Chain
4731
Summary
Annex Type
Support for other methodologies
Methodology
applicability
Detailed Cybersecurity Risk Assessment
Methodology objective /
background
Support methodologies with insight to provide defense in depth with
security measures that are effective as a function of kill chain
phase(s). Supports more insightful understanding of risk reduction.
4732
4733
Methodology description / procedure
4734
4735
4736
4737
4738
A cyber kill chain represents the concept that an attacker needs to go through a series of
distinguishable phases to affect a successful attack. Stopping the attack is possible anywhere in
the process if the chain linking two phases is broken. Table D.6 illustrates the kill chain progression
of activities or phases an attacker would have to take for a targ eted malware attack as developed
by Lockheed Martin.
Kill Chain Phase
[39]
Description
Reconnaissance
Research performed to identify and select target
Weaponization
Means of coupling a Trojan and an exploit designed to
accomplish attacker’s objective
Delivery
Transmission of the weapon into the targeted system
Exploitation
Attacker’s code triggered
Installation
Allows attacker to maintain a presence within the system,
e.g., remote access Trojan or backdoor
Command and control
Allows attacker access to the programming / configuration
keyboard
Actions on objectives
Attacker can now achieve their objective
4739
4740
Table D.6
Cyber Kill Chain Phases
4741
4742
4743
By understanding every point in the chain of events of a cyber-attack, an analyst can help focus
the efforts on breaking that chain and mitigating the damages. A generic approach to the kill chain
would be to:
4744
4745
4746
4747
4748
4749
4750
4751
4752
4753
•
•
•
•
•
•
Define attack objective of concern
Identify each entry point to the system / network
Identify the threat vectors to compromise assets necessary to achieve objective
For each threat vector evaluate what security measures exist to prevent or mitigate each
phase of the kill chain
Identify weaknesses that may exist
Make recommendations as applicable to address weaknesses
Refer to Annex E, Defense in Depth / Security Measures, for guidance regarding security measures
as a function of kill chain phase applicability.
ISA-TR84.00.09-2023
- 207 -
4754
D.10 Sneak Path Analysis
4755
Summary
Annex Type
Methodology
Methodology
applicability
Detailed Cybersecurity Risk Assessment
Methodology objective /
background
The objective of this methodology is to identify flaws in systems that
may result in serious consequences should an attack be successful.
This sneak path methodology was described in a paper by Paul
Baybutt, Sneak Path Security Analysis for Industrial Cyber Security
[50] .
4756
Methodology description / procedure
4757
The following provides an overview of this methodology:
4758
4759
4760
4761
4762
4763
4764
4765
4766
4767
4768
4769
4770
4771
4772
4773
4774
4775
4776
4777
4778
4779
4780
4781
4782
4783
4784
1) Collection of needed information (e.g., system architectures, interfaces between systems
and networks, security measures, control software logic, hardware and software asset
inventory information, potential threats)
2) Development of system topology diagram (e.g., zone and conduit diagram)
3) Identification of sources (e.g., threat agent and their motivation and available skills)
4) Identification of targets (i.e., specific attack objective concern(s)
5) Identification of paths (i.e., threat vectors)
6) Identification of events and impacts ( i.e., consequences should there be a successful
attack on objective
7) Identification of barriers (Available security measures that prevent or mitigate an attack)
8) Estimation of risks
9) Development of recommendations
Once a path (step 5) and potential event(s) (step 6) have been i dentified, barriers or security
measures (step 7) are identified that would prevent or mitigate the attack from continuing via that
path. The severity should the attack be successful and the likelihood of being successful are
qualitatively documented. The sneak path security analysis is considered a detailed cyber security
risk assessment methodology.
Step 7 may be enhanced by also considering the kill chain phases associated with that threat
vector and what security measures are effective as a function of the kill chain phase. Refer to
Annex E, Defense in Depth / Security Measures, for guidance regarding security measures as a
function of kill chain phase applicability.
If more quantitative results are desired, the information resulting in steps 1 through 7 may be used
as input to an attack tree or an event tree.
ISA-TR84.00.09-2023
4785
D.11 Cyber Event Tree
4786
Summary
- 208 -
Annex Type
Methodology
Methodology
applicability
Detailed Cybersecurity Risk Assessment
Methodology objective /
background
Evaluate and document the relationship of a single threat source
starting with a single-entry point to the system/network.
4787
Methodology description / procedure
4788
4789
4790
4791
4792
Creating an event tree is an inductive procedure showing all possible outcomes that result from
an initiating event and proceeding to lay out sequences of events linked by conditional probabilities.
In case of a cyber-attack, a threat source utilizing a specific entry point to the system/network with
an intent to compromise the system/network with an attack on objection in mind is the initiating
event.
4793
A general procedure can be followed as indicated:
4794
1. Define a specific initiating event (e.g., threat source, entry point, objective attack)
4795
4796
2. Identify the available security measures that are designed to mitigate or prevent the attack
as it progresses through the kill chain phases
4797
3. Construct the event tree
4798
4. Describe the (potential) resulting attack sequences
4799
4800
5. Determine the frequency or probability of the attack event and the (conditional) probabilities
of the branches in the event tree
4801
6. Calculate the probabilities/frequencies for the identified consequences (outcomes)
4802
7. Compile and present the results from the analysis
4803
4804
4805
4806
4807
4808
4809
4810
An example of an event tree is included in figure D.9. It illustrates a contrived model to evaluate
the likelihood of an internal denial of service (DoS) occurrence due to a mistake by an employee.
Security measures that were available included:
•
•
•
Portable media ports physically removed from process control systems
Portable media ports physically removed from connected portions of the Process Control network
Network protected by a firewall with SL 2 capability.
ISA-TR84.00.09-2023
- 209 -
SL 2 Administrative work
process and awareness
training successful. 99%
No Issue
Unintentional Internal
DoS, human error (e.g.
Plug in two ends of cable
creating a loop, bad
network interface card,
infected portable media
(1 per year)
Portable media ports physically removed
from process control systems and
connected portions of the PCN
protected by a SL 2 firewall. 99%
No Issue
Human error. 1%
Firewall failure. 1%
4811
4812
Operability Issue
1e-4 per year
Potential for degraded
response or relatively
short duration shutdown
resulting in $50,000 $500,000 losses
Figure D.9
4813
D.12 Cyber-attack Tree
4814
Summary
Annex Type
Methodology
Methodology
applicability
Detailed Cybersecurity Risk Assessment
Methodology objective /
background
Evaluate and document the relationships that result in a specific
attack on objective being achieved.
4815
Methodology description / procedure
4816
4817
4818
4819
Cyber-attack trees use Boolean logic using gates in the same manner that fault trees are created.
The top gate would be the expression of a successful attack. The gates leading up to the top gate
would model demand by threat agents exploiting vulnerabilities AND the failure of security
measures to prevent or mitigate the demands.
4820
The general procedure for constructing an attack tree is as follows:
4821
1. Start with attack on objective as the top event
4822
2. Identify initiating events (threat source(s) and entry point combinations
4823
4824
3. For each initiating event combination, identify sub-events as a function of the kill chain
phases
4825
4. Determine what protection (e.g., security measures) exists for each sub-event.
4826
5. Develop fault tree shell relating subevents using AND gates and OR gates
4827
6. Look for common mode within potential protections throughout the tree
4828
7. Perform qualitative evaluation or calculate likelihood
ISA-TR84.00.09-2023
4829
4830
- 210 -
8. Make recommendations as appropriate
A fault or attack tree example is illustrated below in figure D.10 to show the concept:
Successful
Attack on objectives
Kill Chain Phase
Security Measures
Fail
Attacker commands
& controls
Kill Chain Phase
Security Measures
Fail
Malicious software
installed
Kill Chain Phase
Security Measures
Fail
System exploited by
attacker’s code
Kill Chain Phase
Security Measures
Fail
Delivery of
weaponised code
Kill Chain Phase
Security Measures
Fail
Weaponization to
accomplish objective
Kill Chain Phase
Security Measures
Fail
Reconnaissance to
support objective
Kill Chain Phase
Security Measures
Fail
4831
Threat
Agent
Attack
4832
Figure D.10
4833
4834
Refer to Annex E, Defense in Depth / Security Measure, for guidance regarding security measures
as a function of kill chain phase applicability.
ISA-TR84.00.09-2023
4835
D.13 Check Lists
4836
Summary
- 211 -
Annex Type
Template and Methodology
Methodology
applicability
Initial Cybersecurity Risk Assessment
Methodology objective /
background
A checklist is a non-scenario-based risk assessment technique to
broadly indicate gaps in security measures that need to be
addressed. This can be used during pre-FEED and FEED stage of
green field as well as brownfield projects to check for compliance
to corporate security criteria. There can also be separate
checklists designed and used for assessment, incident
investigation and to determine the rigor of MOC.
4837
Methodology description / procedure
4838
4839
4840
4841
4842
The checklist method employs prepared list of check points to identify concerns in meeting the
criteria and prompts analysts to determine whether the existing security measures are adequate
to address company standards and known vulnerabilit ies. The check points and questions are
based on experience and knowledge of analysts about the network, devices, vulnerabilities and
required counter measures.
4843
4844
4845
Checklists can also be applied individually to specific parts of the system like zone/conduit. Check
points require regular updates and may need to be modified to address various aspects of the SuC,
such as a BPCS or SIS zone, etc.
4846
4847
4848
4849
4850
4851
4852
4853
Procedure to perform checklist study:
1. Select or generate the checklist based on the topic chosen for study
2. Perform the study
3. Document the results
4. Identify action points
5. Close the action points
6. Approve the study
7. Use for further design/implementation
4854
Checklist Example
4855
4856
4857
4858
4859
The check list below is simply an example and may be considered as a starting point for a SIS
zone that also contains some general issues. It should be recognized that there are differences in
requirements for zones and conduits based on their respective SL -T and SPR-T. When using the
check list approach, it is recommended to develop one for each applic able zone as well as one to
address requirements that are applicable to all zones.
Item Criteria
No
Authentication & Authorization
1
Unique identification and
authentication of human users
2
Least privilege principle applied for
human user authentication
3
User account review and termination
policy is place
4
Identification and authentication of
software processes and devices
Yes
No
N/A
Detail
ISA-TR84.00.09-2023
Item
No
5
- 212 -
Criteria
Two/Multi-factor authentication for
remote access
6
Wireless access security in place and
in line with connecting zone security
requirement
7
Strong password acceptance policy
8
No default and hard coded passwords
9
Role based configuration and change
authorization enforced
10
All activity and events are logged with
time stamp
11
Audit records available in standard
formats for analysis
12
Design of non-repudiation capability of
all actions.
13
Communication encryption
14
Use of OPC UA
15
Categorization of application and data
as confidential, restricted, and public.
Authentication and authorization
designed accordingly
16
Third party access restricted to only
required machines and resources.
17
Field device authentication and
authorization policy in place
Integrity
1
Cryptographic communication and data
transfer
2
Protection against unauthorized
software and configuration changes
(such as code signing)
3
Input validation
4
Safe state output upon
adversary/attack detection
5
Audit information and findings
protection
6
Firmware integrity verification
7
Control flow integrity checks
8
Data integrity checks in place for all
ICS/SIS communication
9
Cryptographic hash check of any
Vendor program download
Data Confidentiality
1
Protection of data in rest and transit
including data rights management
2
Data inventory with read, modify, and
write access authority defined
3
Purging of data in memory before
reuse in volatile and shared memory
devices
4
Keep user list live and updated for
group access of data
Yes
No
N/A
Detail
ISA-TR84.00.09-2023
Item
No
5
- 213 -
Criteria
Secure methods used for data/file
transfer.
Data Flow Restriction
1
Logical and physical segmentation of
SIS network from control and other
non-critical networks.
2
SIS shall be in a separate critical zone
with capability to support partitioning of
data, applications and services based
on criticality
3
Network design based on deny by
default and allow by exception
principle.
4
Capability to analyze network data for
uncommon data flows
Response to Events
1
SIS system logs available on read only
basis
2
All security mechanism performance
continuously monitored, and any
security breach reported in a timely
manner
3
Critical system back up and storage
procedure
4
Incident response team and plan along
with testing procedure available
5
Audit vendor/service provider response
to events capability
Resource availability
1
DoS/DDoS multi plane attack
prevention, monitoring and mitigation
techniques available.
2
Availability of program execution
monitoring watchdog timers
3
Availability of fixed frequency and
event based back up capability.
4
Functions, ports, protocols, and
services not necessary for the tasks to
be carried out by the machine
disabled.
5
Procedure for system component
(hardware, software, firmware,
applications, configuration, changes
etc.,) inventory listing and updating
6
Version update and patch management
procedure
7
Ability for the system to continue to
operate in degraded fashion under
DoS/DDoS attack.
Physical & Personal security
1
Lockdown and physically secure access
to control room(s), controllers, portable
Yes
No
N/A
Detail
ISA-TR84.00.09-2023
Item
No
- 214 -
Criteria
Yes
No
N/A
Detail
devices, wireless devices, encryption
hardware and removable media.
2
Perform physical inspections of all
software and hardware to identify
tampering indications.
3
Physical controls should be in place so
that no unauthorized person would have
access to the safety controllers,
peripheral safety equipment and/or the
safety network
4
All controllers should reside in locked
cabinets and never be left in the
“PROGRAM” mode.
5
Any change is monitored and proper
MOC process available.
6
All classified and restricted information
stored in media encrypted
7
Access to unused physical ports in
computer and network equipment
deactivated.
8
All personal (employees and
contractors) in ICS domain trained and
aware of ICS security policies.
9
Records of personal access
information including roles,
responsibilities and authorization level
to ICS systems maintained and
updated.
10
Background checks of personal who
have access to ICS domain performed
and updated
11
Procedure for removing access to
employees leaving the ICS domain in
place
12
Procedure for escorting visitors to ICS
area available
Competency & Training
1
Basic Induction ICS security training
available for all personal getting
inducted into ICS domain
2
Tasks RACI chart available for tasks in
ICS domain
3
Competency & Training needs
identified for each role and training
plan implemented
4860
Annex E – Defense in Depth / Security Measures
4861
Cyber Kill Chain / Defense in Depth
4862
4863
4864
A useful concept when considering defense in depth for cyber security is the cyber kill
chain as described by Hutchins, E.M. et. al. [39] The cyber kill chain represents the concept
that an attacker must go through a series of distinguishable phases to affect a successful
ISA-TR84.00.09-2023
4865
4866
4867
- 215 -
attack. Stopping the attack is possible anywhere in the process if the chain linking two
phases is broken. Providing security measures that account for each of these phases
provides defense in depth. Table E.1 illustrates the kill chain progression of activities.
Kill Chain Phase
[39]
Description
Reconnaissance
Research performed to identify, enumerate, and select targets
Weaponization
Means of coupling a Trojan and an exploit designed to
accomplish attacker’s objective
Delivery
Transmission of the weapon into the targeted system
Exploitation
Attacker’s code triggered
Installation
Allows attacker to maintain a presence within the system,
e.g., remote access Trojan or backdoor
Command and control
Allows attacker access to the programming / configuration
keyboard
Actions on objectives
Attacker can now achieve their objective
Table E.1
Cyber Kill Chain Phases
4868
4869
4870
Example Security Measures
4871
4872
4873
4874
4875
4876
4877
4878
4879
4880
4881
4882
4883
4884
4885
4886
Cybersecurity measure represent any process or technology developed to negate or offset
offensive cyber activities. It is not enough to understand what a security measure does —what it
detects, what it prevents. One must understand how it works. An OT secur ity engineer must
understand their organization’s security measures —precisely what they do, how they do it, and
their limitations—if security measures are to be effectively employed.
4887
Table E.2
In defensive planning, a team tasked with identifying security gaps mus t plan their engagement
with expert knowledge of the security measure’s functionality if they are to evade it. The team
considering cybersecurity must understand what problem it is trying to solve, whether and how it
has been solved before, and why the proposed solution is better or novel.
Table E.2 includes a sampling of potential security measures that in general can be
expected to provide risk reduction for threats where they are applicable. Their attributes
as shown help to guide the user as to their applicability with respect to threats. It is not a
comprehensive listing. In some cases, other security measures must be in place to allow
credit for the security measure listed.
Security Measure Description(s)
Firewall
•
General purpose firewall with ruleset known to Process Control Network
(PCN) group
Firewall
•
Industrial control system stateful firewall
•
Access control list managed by PCN group
•
Minimum rule set defined
ISA-TR84.00.09-2023
- 216 -
Security Measure Description(s)
Firewall
•
Industrial control system stateful firewall
•
Access control list managed by PCN group
•
Minimum rule set defined
•
Deep packet inspection capability
•
No firmware encoded rules.
Firewall
•
Industrial control system stateful firewall
•
Access control list managed by PCN group
•
Rules encoded in firmware
•
No deep packet inspection capability
Firewall
•
Industrial control system stateful firewall
•
Access control list managed by PCN group
•
Rules encoded in firmware, i.e., no external configuration ability
•
Deep packet inspection capability
Router between enterprise and PCN
•
Rules unknown or PCN has no control
Router between enterprise and PCN
•
Rules known by PCN group but not under PCN control
Switch
•
Configured to segment network into VLANS
Switch
•
Switch configured to segment network into VLANS
•
Incorporates access control list to restrict communications and protocols
Vigilant user
Patch management conducted on ad hoc basis
Patch management formal procedures in place
Patch management
•
Centrally managed
•
Updates in accordance with documented procedure
Patch management
•
Centrally managed
•
Updates in accordance with documented procedure
•
Whitelisting implemented and updated in accordance with documented
procedure
•
Formal procedure in place to investigate whitelisting discrepancies
identified
ISA-TR84.00.09-2023
- 217 -
Security Measure Description(s)
Anti-virus (AV) software
•
Installed and periodically updated
Anti-virus (AV) software
•
Installed and updated per formal procedures when revisions are made
available
•
Updated within less than a week when new updates available
Anti-virus (AV) software
•
Centrally managed and updated in accordance with documented procedure.
•
Updated within less than a week when new updates available
Anti-virus (AV) software
•
Centrally managed and updated in accordance with documented procedure
•
Updated within less than a week when new updates a vailable
•
Whitelisting implemented and updated in accordance with documented
procedure
•
Formal procedure in place to investigate whitelisting discrepancies
identified
Audit log
•
Audit records relevant to cybersecurity are generated for access control,
request errors, operating system events, control system events, backup and
restore events, configuration changes, potential reconnaissance activity and
audit log events.
•
Individual audit records include the timestamp, source (originating device,
software process or human user account), category, type, event ID and
event result. Sufficient audit record storage capacity exists for log
management and system configuration.
•
Audit mechanisms are in place to ensure the capacity is not exceeded.
•
Personnel are alerted in the event of audit processing failure with
appropriate actions in response defined in operating procedures.
ISA-TR84.00.09-2023
- 218 -
Security Measure Description(s)
Audit log
•
Audit records relevant to cybersecurity are generated for access control,
request errors, operating system events, control sy stem events, backup and
restore events, configuration changes, potential reconnaissance activity and
audit log events.
•
Individual audit records include the timestamp, source (originating device,
software process or human user account), category, type, eve nt ID and
event result.
•
Internal system clocks synchronize at a configured frequency.
•
Audit events are centrally managed.
•
Audit records are compiled from multiple components throughout the control
system into a system-wide (logical or physical), time-correlated audit trail.
•
Audit records are produced in industry standard formats for analysis by
standard commercial log analysis tools.
•
Compiled audit records are periodically analyzed within a timeframe
sufficient to mitigate the potential identified risk.
•
Sufficient audit record storage capacity exists for log management and
system configuration.
•
Audit mechanisms are in place to ensure the capacity is not exceeded.
Warning is automatically issued when the allocated audit record storage
volume reaches a configured percentage of maximum audit record storage
capacity allowing sufficient time to respond.
•
Personnel are alerted in the event of an audit processing failure and
appropriate actions in response are defined in operating procedures.
ISA-TR84.00.09-2023
- 219 -
Security Measure Description(s)
Audit log
•
Audit records relevant to cybersecurity are generated for access control,
request errors, operating system events, control system events, backup and
restore events, configuration changes, potential reconnaissance activity and
audit log events.
•
Individual audit records include the timestamp, source (originating device,
software process or human user account), category, type, event ID and
event result.
•
Internal system clocks synchronize at a configured frequency and
timestamp source is protected from unauthorized alteration. All alterations
cause an audit event.
•
Audit events are centrally managed.
•
Audit records are compiled from multiple components throughout the control
system into a system-wide (logical or physical), time-correlated audit trail.
•
Audit records are produced in industry standard formats for analysis by
standard commercial log analysis tools.
•
Compiled audit records are periodically analyzed within a timeframe
sufficient to mitigate the potential identified risk.
•
Sufficient audit record storage capacity exists for log management and
system configuration.
•
Audit mechanisms are in place to ensure the capacity is not exceeded.
Warning is automatically issued when the allocated audit record storage
volume reaches a configured percentage of maximum audit record storage
capacity allowing sufficient time to respond.
•
Personnel are alerted in the event of an audit processing failure and
appropriate actions in response to an audit processing failure are defined in
operating procedures.
Portable media
•
Controlled via administrative controls
Portable media
•
Ports disabled via software
•
Control system prevents the execution of mobile code, requiring proper
authentication and authorization for origin of the code, restricts mobile code
transfer to/from the control system, and monitors the use of mobile code.
•
Control system automatically enforces configurable usage restrictions that
include preventing the use of portable and mobile devices, requiring context
specific authorization, and restricting code and data transfer to/from
portable and mobile devices.
Portable media
•
Ports disabled via hardware means
•
Control system prevents the execution of mobile code, requiring proper
authentication and authorization for origin of the code, restricts mobile code
transfer to/from the control system, and monitors the use of mobile code.
•
Control system automatically enforces configurable usage restrictions that
include preventing the use of portable and mobile devices, requiring context
specific authorization, and restricting code and data transfer to/from
portable and mobile devices.
ISA-TR84.00.09-2023
- 220 -
Security Measure Description(s)
Portable media
•
Ports disabled via hardware means
•
Control system automatically enforces configurable usage restrictions that
include preventing the use of portable and mobile devices, requiring context
specific authorization, and restricting code and data transfer to/from
portable and mobile devices.
•
Portable or mobile devices attempting to connect to a zone are verified to
comply with the cybersecurity requirements of that zone.
Portable media
•
Ports do not exist
Personnel security
•
Standard background check
Personnel security
•
Background check looks at social media for terrorist connections as well
checking for past criminal behavior
Personnel security
•
Background check looks at social media for terrorist connections as well
checking for past criminal behavior and financial hist ory
•
Annual revalidation of background checks
•
Access permissions removed at SAME time employee discharged from
service
Physical access
•
Equipment located in controlled access building
Physical access
•
Managed door lock
•
Locked enclosure procedure
Physical access
•
Equipment located in key card-controlled access room
•
Entry limited to pre-approved personnel
Physical access
•
Equipment located in key card-controlled access room
•
Entry limited to pre-approved personnel
•
Unauthorized entry alarm with formal response procedure
Intrusion detection
•
Comparison diagnostics employed
•
Procedure in place to periodically review diagnostics and investigate
anomalies
Intrusion detection
•
Comparison diagnostics employed with alarm
•
Procedure requires immediate response to investigate and respond to
anomalies
ISA-TR84.00.09-2023
- 221 -
Security Measure Description(s)
Intrusion detection
•
Comparison diagnostics employed with alarm
•
Procedure requires immediate response to investigate and respond to
anomalies
•
Periodic drills to validate proven in use for assumed value
4888
Security Measures as a Function of Kill Chain Phases
4889
4890
4891
4892
4893
As noted earlier, defense in depth is made possible by implementing security measures
that address all the kill chain phases. As such, it is important to understand which security
measures can be effective for each of the kill chain phases. Table E.3 provides a sample
list of security measures and what phase of the Lockheed Kill Chain Phase [39] they are
believed to be effective.
4894
Table E.3
Security Measure Type
Kill Chain Phase
[39]
Web analytics
Reconnaissance
Firewall
Reconnaissance
Command and control
Router between enterprise and PCN
Reconnaissance
Delivery
Switch
Delivery
Network Intrusion Detection System
Reconnaissance
Delivery command and control
Network Intrusion Prevention System
Reconnaissance
Delivery
Command and control
Vigilant user
Delivery
Proxy filter
Reconnaissance
Delivery
In-line anti-virus (AV)
Delivery
Exploitation
Host Intrusion Detection System
Exploitation
Installation
Patch management
Exploitation
Data Execution Prevention
Exploitation
Anti-virus (AV) software
Installation
Tarpit
Reconnaissance
Command and control
ISA-TR84.00.09-2023
- 222 -
Security Measure Type
Kill Chain Phase
Audit log
Actions on objectives
Quality of service metrics
Actions on objectives
Honeypot
Actions on objectives
Portable media protection
Reconnaissance
Delivery
Exploitation
Personnel security
Reconnaissance
Delivery
Physical access protection
Weaponization
Reconnaissance
Delivery
Exploitation
[39]
4895
4896
4897
4898
4899
This information can also be used in evaluating the potential effectiveness of security
measures to protect against threats being made through different attack vectors or paths.
Table E.4 provides an example analysis showing a small sample of threats and vectors,
the security measures that may provide some level of risk reduction against those attacks,
and the kill chain phase(s) where each countermeasure would be effective.
4900
Table E.4
Threat
Vector
Denial of
service
Portable
media
Portable media protection
Via
internet
Firewall
Portable
media
Portable media protection
General
virus
Via
internet
Potential Security Measures
Kill Chain Phase
[39]
Reconnaissance
Command and control
Personnel security
Physical access protection
Weaponization
Patch management
Exploitation
In-line anti-virus (AV)
Delivery
Exploitation
Anti-virus (AV) software
Installation
Patch management
Exploitation
In-line anti-virus (AV)
Delivery
Exploitation
Anti-virus (AV) software
Installation
ISA-TR84.00.09-2023
- 223 -
4901
MITRE ATT&CK ® for ICS Framework Description / Procedure
4902
4903
4904
4905
4906
4907
4908
MITRE ATT&CK ® for ICS, https://collaborate.mitre.org/attackics/index.php/Main_Page,
provides a curated knowledge base of cyber adversary behavior, reflecting the various
phases of an adversary's attack lifecycle and the assets they are known to target. The
MITRE ATT&CK ® for ICS matrix, shown below in Figure E.1, contains a set
of techniques used by adversaries to accomplish specific technical goals. Those technical
goals are categorized as tactics, which are an expansion of the kill chain phases, in the
MITRE ATT&CK® for ICS Matrix.
4909
4910
4911
Figure E.1
4912
4913
4914
4915
Within each tactic of the MITRE ATT&CK® for ICS matrix there are adversary techniques
https://collaborate.mitre.org/attackics/index.php/All_Techniques, which describe how the
adversary achieved the technical goal (tactic) and how procedure examples were actually
performed. A small example of some of those techniques are shown in figure E.2 below.
4916
4917
Figure E.2
ISA-TR84.00.09-2023
4918
4919
4920
- 224 -
Potential security measures or mitigations are made available based upon the technique
https://collaborate.mitre.org/attackics/index.php/Mitigations. A small sample of those
mitigations are shown below in figure E.3.
4921
4922
Figure E.3
4923
4924
Their list of behaviors can be mapped to the cyber kill chain phases as documented in
Table E4.
4925
Table E4
Kill Chain
Phase [39]
Description –
Kill Chain
Reconnaissance
Research
performed to
identify and
select target
Weaponization
Means of
coupling a Trojan
and an exploit
designed to
accomplish
attacker’s
objective
Delivery
Transmission of
the weapon into
the targeted
system
MITRE
ATT&CK ® for
ICS Tactics
Description - MITRE
Initial Access
Trying to get into the
ICS environment, i.e.,
spear phishing
Discovery
Locating information to
assess and identify their
targets in the target
environment , i.e.,
ISA-TR84.00.09-2023
Kill Chain
Phase [39]
Exploitation
Installation
- 225 -
Description –
Kill Chain
Attacker’s code
triggered
Allows attacker to
maintain a
presence within
the system, e.g.,
remote access
Trojan or
backdoor
MITRE
ATT&CK ® for
ICS Tactics
Execution
Description - MITRE
exploring what the
attacker can control
Trying the run
malicious code,
manipulate system
functions, parameters,
and data in an
unauthorized way, e.g.,
running a remote
access tool
Privilege
Escalation
Trying to gain higherlevel permissions, e.g.,
leveraging a
vulnerability to elevate
access
Lateral
Movement
Moving through the
environment, e.g.,
using legitimate
credentials to pivot
through multiple
systems
Persistence
Trying to maintain a
foothold, e.g., changing
configurations
Evasion
Trying to avoid being
detected, e.g., using
trusted processes to
hide malware
Command and
control
Allows attacker
access to the
programming /
configuration
keyboard
Command and
Control
Communicating with
compromised systems
to control them, e.g.,
mimicking normal web
traffic to communicate
with a victim network
Actions on
objectives
Attacker can now
achieve their
objective
Collection
Gathering data of
interest to the
adversary goal, e.g.,
accessing data
operational parameters
ISA-TR84.00.09-2023
Kill Chain
Phase [39]
- 226 -
Description –
Kill Chain
MITRE
ATT&CK ® for
ICS Tactics
Description - MITRE
Inhibit
Response
Function
Trying to prevent the
safety, protection,
quality assurance, and
operator intervention
functions from
responding to a failure,
hazard, or unsafe state
Impair
Process
Control
Trying to manipulate,
disable, or damage
physical control
processes.
Impact
Manipulate, interrupt,
or destroy systems and
data, i.e., encrypting
data with ransomware
4926
4927
4928
4929
4930
4931
The level of abstraction for adversary tactics and techniques within ATT&CK is an important
distinction between it and other types of threat models. As a mid -level adversary model, ATT&CK
for ICS represents adversary tactics and techniques at a level of ab straction between that of other
existing threat models. This includes adversary lifecycles at a high level, such as the SANS ICS
Cyber Kill Chain, and exploit and vulnerability databases at a lower level, such as Common
Vulnerabilities and Exposures (CVE) and DHS CISA Advisories which are ordered by vendor.
4932
4933
4934
4935
4936
4937
4938
A mid-level model, such as ATT&CK for ICS, helps to both contextualize lower -level details and
tie together individual actions within an attack lifecycle. While high level models provide an
understanding of the overall processes, they are less effective at relating individual adversary
actions to each other. As with the existing ATT&CK knowledge bases, ATT&CK for ICS can tie in
valuable information regarding these actions, such as asset and platform cons iderations, data
sources, and security measures. In contrast, a low-level model provides specific technical
examples that are often disconnected from a wider context that informs their purpose and use.
4939
4940
ISA-TR84.00.09-2023
Annex F – Data Flow Analysis
4941
4942
4943
4944
- 227 -
Inputs to perform a data flow analysis include
•
•
Asset inventory – This provides the list of potential data sources and targets
Architecture drawings
4945
4946
4947
4948
Once complete, there should be documentation of data flow from/to each device. Knowing the SLT for the devices as determined in the high-level cyber risk assessment, allows determination of
the SL-T for the conduit through which the data must flow. This knowledge helps to endure the
segmentation strategy is sound.
4949
Analysis of Data Flow Methodology
4950
4951
4952
4953
4954
4955
4956
4957
4958
4959
4960
4961
4962
4963
4964
4965
4966
4967
4968
4969
4970
4971
For each data source, complete the Data Exchange Worksheet shown below in Table F1. The table
and supporting input guidance is a modification of what was presented in the Sandia National Labs
SAND2013-5472 report.
• Use Tables F2 for guidance and explanation of input fields.
• When considering consequences, the following questions may be used to assist
identification.
o What if data becomes corrupted unusable?
o What if data is spoofed, e.g., misrepresented to the human interface?
o What if data is modified/compromised?
o What if data is lost
o What if data is stolen?
• Use documented consequences as a basis for SL -T of conduit
• Based upon information contained in the Data Exchange Worksheet, determine if:
o Data exchange is appropriate
o Data protocol proposed is appropriate
o Zone and conduit segmentation is appropriate
• Update data exchange worksheet information as applicable.
• Review the applications to identify the value of the data being processed by a given
application
o Determine whether the data is worthwhile and whether it should be approved or
should not be approved
• Document approved data flows in Data Flow Summary Form, Table F11
4972
Data Exchange Worksheet Template
4973
4974
4975
Table F1
Data Exchange Worksheet Template
Attribute
Data Source
Data Target
Exchange Attributes
Data Type
Interval
Method
Communication Protocol
Priority
Latency Tolerance
Data Attributes
Value
ISA-TR84.00.09-2023
- 228 -
Type
Accuracy
Precision
Timeliness
Volume
Reliability
Consequence of Data Compromise
Consequences
SL-T
4976
4977
Data Exchange Worksheet Table Input Descriptions
4978
4979
Table F2
Data Exchange Worksheet Table Input Descriptions
Input
Description
Data Source
Device / application where data originates.
Data Target
Devices / applications that data is meant to be communicated to.
Exchange Attributes
Data Type
Category
Safety
Sub-Category
Process Safety
Non-process Safety
Alarm
Alert (Diagnostic)
Security
Log
Alert (Diagnostic)
Alarm
Operational
Continuous operation
Sequential operation
State change (e.g., shutdown, process hold,
cleanout, unit testing, etc.)
Batch Signals
Reliability
Probability
Availability
Maintenance
Predictive
Preventative
Commerce
Purchase
Sales
Interval
Frequency of data exchange e.g., continuous, on demand, batch,
etc.
Method
How data will be exchanged, e.g.
• Unicast - Transmission from one point to another point
ISA-TR84.00.09-2023
- 229 -
Input
•
•
•
Communication Protocol
•
•
•
Description
Multicast - Transmission is addressed to a group of computers
simultaneously
Any-cast - Network and routing methodology in which a single
destination IP address is shared by devices, typically servers,
in multiple locations
Broadcast - Transferring a message to all recipients
simultaneously
Client to server
Thin client (remote)
See Protocol table
Priority
Relative importance of data to be exchanged, e.g., High, medium,
low
Latency Tolerance
Tolerance to delayed access to control/protect processes and
delayed exchange of data, e.g.:
• High – Normal operation is maintained even when receiving
significantly delayed data
• Medium – Operability issues, safety not compromised
• Low – Normal operation and / or process safety protection
compromised
Reliability / Quality
•
•
High
Low
Data Attributes
Sub-Type
Additional details related to Exchange Type, e.g., voltage, set point,
process variable, status
Accuracy
The degree to which the result of a measurement, calculation, or
specification conforms to the correct value or a standard
Precision
The reproducibility or repeatability of a result from repeated
measurements under unchanged conditions.
Note: It is possible for precision measurements to not be accurate.
Timeliness
•
•
•
•
•
•
Volume
Amount of data to be transferred per exchange, e.g., bytes,
kilobytes
Reliability
Necessity of access to control or protect processes and data
Consequences
• Safety concerns
• Malicious activity
• Operability issues
• Financial concerns, etc.
Consider
• What if data is corrupted?
• What if data is spoofed?
• What if data is modified?
Millisecond(s)
Second(s)
Minutes(s)
Hours(s)
Day(s)
Month(s)
ISA-TR84.00.09-2023
- 230 -
Input
•
•
Security Level Target for conduit used for communication based
upon potential consequences of compromised data
SL-T
4980
Description
What if data is lost or erased?
What if data is stolen?
Electrical Connection Type Security Capability Estimates
4981
4982
Table F3
Electrical Connection Summary of Relative Security
Electrical Connection Type
4983
4987
4988
Comments
Hardwired analog without communication
protocol
Intrinsically secure
Non-programmable, no intelligence
Hardwired analog with communication
protocol, e.g., superimposed HART
Cybersecurity is a
function of the
superimposed
protocol
Function of protocol also used
Medium
Assumes
•
Field device is always connected
directly to the I/O board
•
Field devices are NOT part of a
network asset management program
Hardwired Point to Point digital
communication
Medium
Assumes
•
Field device is always connected
directly to the I/O board
•
Field devices are NOT part of a
network asset management program
Serial connection (RS232) point to point
High
Serial connection (RS232) with converter
Generally low
Cybersecurity is a function of converter
and other equipment used.
Serial connection RS422 / RS485 point to
point
High
Assumes ethernet is NOT used
Serial connection RS422 / RS485 point to
point with converter
Generally low
Cybersecurity is a function of converter
and other equipment used.
Multidrop connection (RS485)
Low
Communication Protocol Security Capability Estimates
4984
4985
4986
Relative Cyber
Security Capability
Table F4
Communication Protocol Summary of Relative Security
Table Notes:
1. Assignment of low, medium, high, and very high relative security capabilities are based on
the evaluations contained in tables F5 through F11 following this table F4.
Communication Protocol
Relative Security
Capability
Comments
Bacnet
Not evaluated
Bacnet secure
Not evaluated
DNP3
Low
Reference Table F8
DNP3 - Security
Medium
Reference Table F8
Ethernet/IP
Not evaluated
File Transfer Protocol (FTP)
Not evaluated
ISA-TR84.00.09-2023
4989
- 231 -
Goose
Not evaluated
Hart
Low
Reference Table F5
Hart IP
Low to Medium
Reference Table F5
Hart Wireless
High
Reference Table F5
Hypertext transfer protocol (HTTP)
Not evaluated
Hypertext transfer protocol secure (HTTPS)
High
Reference Table F10
IEC 61850
Low
Reference Table F8
Low currently applies to all variations
Internet protocol (IP)
Not evaluated
ISA 100.11a
High
LDAP (Lightweight Directory Access Protocol)
Version 2
Not evaluated
LDAP (Lightweight Directory Access Version 3
High
Reference Table F9
Modbus RTU
Low
Reference Table F6
Modbus TCP
Low to Medium
Reference Table F6
Foundation fieldbus
Low
Reference Table F7
Profibus DP
Low
Reference Table F6
Profinet (TCP/IP)
Low
Reference Table F9
RDP
High
Reference Table F10
TCP
Not evaluated
TLS
High
Reference Table F10
OPC DA, OPC HD, OPC AE
Medium
Reference Table F7
OPC UA
High
Reference Table F7
Reference Table F6
ISA-TR84.00.09-2023
- 232 -
4990
Table F5
OSI model
7
Application
TCP/IP model
Application
HART
HART 5, 6 commands:
- Universal commands
- Common practice
commands
- Device specific commands
Write protection through
tamper proof devices
HART-IP
Wireless HART
HART 5, 6 commands:
- Universal commands
- Common practice
commands
- Device specific
commands
HART 7 commands
Write protection through
tamper proof devices
Command and response
structure
Centralized network
configuration of super
frames links, and routes
Joining
Master - Slave protocol
No authentication,
authorization or encryption
implemented
No authentication,
authorization or encryption
implemented
Master - Slave protocol
6
Data encoding
Presentation
Encryption and data
integrity
5
Session
4
Transport
Key management
TCP port 5094
UDP port 5094
Transport
Checksum (single digit
errors) over header,
pseudo-IP header, and
data.
Connectionless service,
Reliable delivery with an
acknowledgement service.
Auto-segmentation for
large data transports
Supports TLS / SSL
protocol for encrypted end
to end protection
3
Network
Internet Protocol, unicast
Internet
IPv4 header checksum
(single bit errors), 32 bits
address space
IPv6 no header checksum,
128 bits address space
IP address filters
Graph and source routing.
Graph routes include the “1
through n Access Points”
allowing redundant /
multiple connections to the
backbone networks. This
enables a single network to
support very high
throughput. Joining
Security: end-to-end
encryption and data
integrity.
Mesh network architecture
16 and 64 bits addressing
map
2
Data Link
Network interface
HART message structure,
1 byte checksum (single bit
errors)
Ethernet IEEE 802.3
message structure with
HART message embedded
Cyclic Redundancy Check
(double digit errors)
Time slotted,
TDMA channel hopping,
channel blacklisting,
Secure acknowledgements,
Clock propagation,
hop by hop data integrity
check
4 priority levels
ISA-TR84.00.09-2023
OSI model
1
- 233 TCP/IP model
HART
HART-IP
Bell 202 AFSK
1200 bps / HD
Physical
Wireless HART
10BASE-T, 100BASE-T,
1000BASE-T
connectionless service,
Reliable delivery with an
acknowledgement service.
IEEE 802.3
RS-485, RS-232C using
HART multiplexer
Auto-segmentation for
large data transports
Supported security features
SECURITY EVALUATION
Authentication
-
IF TLS implemented
√
Certificate support
-
-
-
Authorization
-
IF TLS implemented
√
Encryption
-
IF TLS implemented
√
Message integrity / authenticity
-
-
√
Access filter
-
√
Write protection
Physical
IP address / port address
level
Physical
Security Capability
LOW
LOW without TLS
(Transport Layer Security)
MEDIUM with TLS
HIGH
4991
-
Table F6
7
OSI model
TCP/IP model
ISA 100.11a
MODBUS RTU
MODBUS TCP
PROFIBUS DP
Application
Application
No process & control
application layer
Modbus function codes
Modbus function
codes
Profibus DP
protocol
Master - Slave
protocol
Master - Slave
protocol (From DP
master to DP
slave)
Master - Slave protocol
Centralized network
configuration of super
frames links, and
routes Joining
Options for:
Distributed network
configuration
Object and method
services structure
Quality of service
support
6
Presentation
Data encoding,
Message Integrity
Code
5
Session
Key management
No authentication,
authorization or encryption
implemented
Write protection
through external
firewall filtering
on function
codes or in
combination
with filter on
specific register
ranges.
Not available for
Modbus/TCP
Security in
combination
with TLS.
Client - Server
protocol (From DP
master to DP
master)
PROFI-safe,
HART on DP
No authentication,
authorization or
encryption
implemented
ISA-TR84.00.09-2023
4
- 234 -
OSI model
TCP/IP model
ISA 100.11a
Transport
Transport
Connectionless UDP
service, end-to-end
encryption (AES-128)
and data integrity
MODBUS RTU
Modbus/TCP
Security
protocol TCP
port 802
Supporting TLS
with encryption
and
authentication
based on
x.509v3
certificates
Fragmentation and
reassembly at
backbone router.
Note, if fragmentation
and reassembly is
used then graph
routing terminates and
reassembles
messages at the
single backbone router
introducing a single
point of failure.
Network
Internet
PROFIBUS DP
TCP port 502
UDP port 502
Time stamped
communication
preventing replay
attack
3
MODBUS TCP
IETF IPv6 and
6LoWPAN
Internet
Protocol,
unicast
Mesh network
architecture
IPv4 header
checksum
(single bit
errors), 32 bits
address space
IPv6 no header
checksum, 128
bits address
space
16-, 64-, and 128-bits
addressing map
IP address
filters
2
Data Link
Network
interface
Time slotted,
TDMA channel
hopping,
channel blacklisting,
adaptive hopping,
Secure
acknowledgements,
Clock propagation,
hop by hop data
integrity check and
encryption, Graph, and
source routing
Joining Options for:
Slow hopping and
hybrid slow/fast
hopping
Dual
Acknowledgement
Configuration based
time slot sizes
Explicit congestion
notification
2 priority levels
Modbus message structure
Cyclic Redundancy Check
(double digit errors)
Ethernet IEEE
802.3 message
structure with
Modbus
message
embedded.
Cyclic
Redundancy
Check (double
digit errors)
Fieldbus Data
Link (FDL)
Token passing
method
4992
ISA-TR84.00.09-2023
OSI model
1
TCP/IP model
Physical
- 235 ISA 100.11a
MODBUS RTU
MODBUS TCP
PROFIBUS DP
IEEE 802.15.4
RS-485, RS-232C
10BASE-T,
100BASE-T
IEC 61158/61784
2.4 Ghz DSSS / HD
4800/9600/19200/38400
bps
IEEE 802.3
RS 485, RS-485IS
9600 bps - 12
Mbps
MBP, MBP-LP,
MBP-IS
31.25 kbps
Supported security features
Authentication
√
-
Certificate support
-
-
Authorization
√
-
Encryption
√
-
Message integrity / authenticity
√
-
Access filter
√
-
Write protection
-
-
Security Capability
HIGH
LOW
IF TLS
implemented
-
-
IF TLS
implemented
IF TLS
implemented
-
-
IP address /
port address
level
Using external
firewall
LOW-MEDIUM
-
-
-
LOW
ISA-TR84.00.09-2023
- 236 -
4993
Table F7
OSI model
7
Application
TCP/IP model
Application
Presentation
5
Session
4
Transport
3
OPC UA
FF function codes
OPC API, DCOM
OPC UA
Fieldbus Message
Specification (FMS)
DCOM security
(authentication,
authorization, launch
permission, message
encryption, integrity)
authentication,
authorization, encryption,
integrity, trust list using X509 certificates
Fieldbus Access Sublayer
(FAS)
6
OPC DA, OPC HD, OPC
AE
FOUNDATION FIELDBUS
No authentication,
authorization or encryption
implemented
OPC XML-DA
Authorizations per point
level
Client - server protocol
Client - server protocol
Master - Slave protocol
Special support for
authorization per point
level is available, just like
secure tunnelling options.
RPC protocol,
Secure RPC
TCP ports DA 62547,
62546
TCP ports AE 62544,
62543
TCP ports HD 62550,
62549
TCP ports RPC 135
UDP ports RPC 135
TCP ports UA server 51210, 51211
Internet Protocol, unicast
Internet Protocol, unicast
IPv4 header checksum
(single bit errors), 32 bits
address space
IPv6 no header checksum,
128 bits address space
IPv4 header checksum
(single bit errors), 32 bits
address space
IPv6 no header checksum,
128 bits address space
IP address filters
IP address filters
Ethernet IEEE 802.3
message structure
Ethernet IEEE 802.3
message structure
IEC 61158-2 / ISA S50.02
10BASE-T, 100BASE-T
10BASE-T, 100BASE-T,
1000BASE-T
H1 bus 31.25 kbps (IS)
H2 bus 1 - 2.5 Mbps
HSE 100 Mbps
IEEE 802.3
Authentication
-
√
√
Certificate support
-
-
√
Authorization
-
√
√
Encryption
-
Secure RPC
√
Message integrity / authenticity
-
-
√
Access filter
-
External firewall
√
Write protection
-
Optionally
√
Network
2
Data Link
1
Physical
Transport
Internet
Network interface
TCP ports UA client 61210, 61211
IEEE 802.3
Supported security features
ISA-TR84.00.09-2023
OSI model
- 237 TCP/IP model
Security level
FOUNDATION FIELDBUS
LOW
4994
OPC DA, OPC HD, OPC
AE
MEDIUM
OPC UA
HIGH
Table F8
OSI model
7
Application
TCP/IP model
Application
DNP3
DNP3 Security
DNP3 operations
DNP3
Master - slave protocol,
however the IED doesn't
connect to a single
master (not dual-endpoint
implementation)
Master - slave protocol
using Authorization
Management Protocol
(AMP)
IEC 61850
MMS (Manufacturing
Message Specification ISO 9506-1/9506-2)
Application-level security
IEC 62351-4
4 modes of operations:
Master - slave protocol
- Quiescent operation,
- Unsolicited report by
exception operation
- Polled report by
exception operation
- Polled static operation
Client-server (peer to
peer MMS)
4 modes of operations:
- Quiescent operation,
- Unsolicited report by
exception operation
- Polled report by
exception operation
- Polled static operation
Encryption (AES-256)
Support for access
control list at slave
(outstation) enforcing
permissions per point
level
6
Presentation
ISO 8823-1/X.226
MMS (Manufacturing
Message Specification ISO 9506-1/9506-2)
AES 128/256 encryption
5
4
Session
Transport
Transport
TCP port 20000
UDP port 20000
DNP3-SA (Secure
Authentication and
certificate-based
message integrity
checking)
ISO 8327-1/X.225
TCP port 20000
UDP port 20000
TCP port 102 (MMS)
X.509 certificates
UDP port 102 (Goose)
UDP port 102 (SVSampled Values)
In combination with TLS
TCP port 3782)
ISA-TR84.00.09-2023
OSI model
3
Network
- 238 TCP/IP model
Internet
DNP3
DNP3 Security
Internet Protocol, unicast
Internet Protocol, unicast
IPv4 header checksum
(single bit errors), 32 bits
address space
IPv6 no header
checksum, 128 bits
address space
IPv4 header checksum
(single bit errors), 32 bits
address space
IPv6 no header
checksum, 128 bits
address space
IP address filters
IP address filters
IEC 61850
Multicast protocol for
Goose
Internet Protocol, unicast
for MMS
IPv4 header checksum
(single bit errors), 32 bits
address space
IPv6 no header
checksum, 128 bits
address space
IP address filters
Ethernet IEEE 802.3
message structure
Ethernet IEEE 802.3
message structure
Ethernet IEEE 802.3
message structure
10BASE-T, 100BASE-T
10BASE-T, 100BASE-T
BACnet
BACnet
RS-232, RS-485
RS-232, RS-485
10BASE-T, 10BASE-FI,
10BASE-210BASE-5,
100BASE-TX, 100BASESX, 100BASE-T4,
100BASE-FX, 1000BASEF, 10000BASE-F
230 kbps
230 kbps
Authentication
-
√
√
Certificate support
-
√
√
Authorization
-
√
√
Encryption
-
√
√
Message integrity / authenticity
-
√
√
Access filter
External firewall
√
√
Write protection
Optionally
√
√
Security Capability
LOW
HIGH
HIGH
2
Data Link
1
Physical
Network interface
Supported security features
4995
Table F9
OSI model
7
Application
TCP/IP model
Application
Profinet (TCP/IP) / IEC 61158
DP (Decentralized Peripheral) / FMS
(Fieldbus Message Specification)
protocol
NRT (NonReal-time
channel)
6
Presentation
RT (RealTime
Channel)
LDAP (Lightweight Directory Access
Protocol) Version 3
Lightweight Directory Access Protocol
(Subset of X500)
IRT
(Isochronous
Real-Time
channel)
Basic Encoding Rules (BER)
4996
4997
ISA-TR84.00.09-2023
OSI model
- 239 TCP/IP model
LDAP (Lightweight Directory Access
Protocol) Version 3
Profinet (TCP/IP) / IEC 61158
5
Session
RPC
-
-
4
Transport
Transport
UDP
3
Network
Internet
IP
2
Data Link
Network interface
Ethernet IEEE 802.3 message structure
1
Physical
LDAPS (LDAP over TLS), Kerberos for
authentication / LDAP for authorization
TCP / UDP
-
(NRT / RT) IEEE 802.3
CSMA-CD (Carrier
Sense Multiple Access Collision Detect)
-
(IRT) IEEE
802.3
TDMA (Time
Division
Multiple
Access)
IP
Ethernet IEEE 802.3 message structure
10BASE-T, 10BASE-FI, 10BASE-210BASE5, 100BASE-TX, 100BASE-SX, 100BASET4, 100BASE-FX, 1000BASE-F,
10000BASE-F
10BASE-T, 10BASE-FI, 10BASE210BASE-5, 100BASE-TX, 100BASE-SX,
100BASE-T4, 100BASE-FX, 1000BASEF, 10000BASE-F
Supported security features
Authentication
-
√
Certificate support
-
Only LDAPS, not for Kerberos
Authorization
-
√
Encryption
-
√
Message integrity / authenticity
-
√
Access filter
-
√
Write protection
-
-
Security Capability
LOW
HIGH
ISA-TR84.00.09-2023
- 240 -
4998
Table F10
OSI model
7
Application
6
Presentation
5
Session
TCP/IP model
RDP
HTTPS
TLS 1.2
Application
Remote Desktop Protocol
(T.120 family of protocols)
Hyper Text Markup
Language (HTML)
Application Layer Protocol
Negotiation (ALPN)
RDP supports 3 types
of security layers:
Negotiate, RDP
security layer, and
SSL.
TLS 1.2
Diffie-Hellman handshake,
RSA handshake
Use of Diffie-Hellman
handshake is advised
Server Name Indication
(SNI)
By default, RDS
sessions use the
Negotiate method,
where the client and
remote desktop session
host (RDSH) server
agree on the most
secure protocol the
client supports.
Certificate revocation
support including Online
Certificate Status Protocol
(OCSP)
For example, if the
client supports TLS 1.2,
then the RDS
infrastructure uses it.
Otherwise, the RDS
infrastructure uses the
RDP security layer.
Supports Multi-Factor
Authentication
Support for multi-tenant
architectures
4
Transport
Transport
TCP
TCP
TCP
4999
ISA-TR84.00.09-2023
OSI model
- 241 -
TCP/IP model
RDP
HTTPS
TLS 1.2
3
Network
Internetwork
IP
IP
IP
2
Data Link
Network interface
Ethernet IEEE 802.3
message structure
Ethernet IEEE 802.3
message structure
Ethernet IEEE 802.3
message structure
1
Physical
10BASE-T, 10BASE-FI,
10BASE-210BASE-5,
100BASE-TX, 100BASE-SX,
100BASE-T4, 100BASE-FX,
1000BASE-F, 10000BASE-F
10BASE-T, 10BASE-FI,
10BASE-210BASE-5,
100BASE-TX, 100BASE-SX,
100BASE-T4, 100BASE-FX,
1000BASE-F, 10000BASE-F
10BASE-T, 10BASE-FI,
10BASE-210BASE-5,
100BASE-TX, 100BASESX, 100BASE-T4,
100BASE-FX, 1000BASE-F,
10000BASE-F
Supported security features
SECURITY EVALUATION
Authentication
√
√
√
Certificate support
√
√
√
Authorization
√
√
√
Encryption
√
√
√
Message integrity / authenticity
√
√
√
Access filter
√
√
√
Write protection
-
-
-
Security Capability
HIGH
HIGH
HIGH
ISA-TR84.00.09-2023
5000
- 242 -
Data Flow Summary Documentation Template
5001
Table F11
Data Source
Enterprise Server(s)
Remote Support
Proxy Server
Patching Server
Asset Management Server
Web Server
Data Historian
Maintenance Station
Process Optimization
Supervisory Control
Operator Workstation
Operator Workstation SIS
Engineering Workstation –
DCS
Engineering Workstation –
PLC
Data Source
Application
Data Target(s)
Data Target
Application
Data Protocol
Action Constraints
(Read only, write
only, read & write)
ISA-TR84.00.09-2023
Data Source
- 243 -
Data Source
Application
Data Target(s)
Data Target
Application
Data Protocol
Action Constraints
(Read only, write
only, read & write)
Engineering Workstation –
SIS
I/O Server(s)
SIS Server
DCS server
Programmable Logic
Controller
Packaged Equipment
SIS Controller
Sensors/Final Elements SIS
Sensors/Final Elements Control
Analyzers
5002
Note: Jump servers are not a data source or target. They represent data access and fall under access control policies and practices.
ISA-TR84.00.09-2023
- 244 -
5003
Annex G - Cybersecurity Requirements Specification (CRS) Template
5004
5005
5006
An example template is provided below for documentation of a CRS. The template organization is divided into general and zone-specific
information for documentation of user defined cybersecurity requirements. Should a user adopt ISA62443-3-2, the template generally
incorporates the standard’s minimum requirements as well as some additional suggestions.
5007
General Security Requirements
5008
System under consideration (SUC) description
5009
The overall scope and of the SUC is described in tabl e G1 below:
5010
Table G1
Data Field Descriptor
Field Input Guidance
SuC Name
Function
High-level description of the function and the intended usage
of the SUC
Equipment/Process under
control
Description of the equipment or process under control.
Associated data and process
flows
Illustration of the SuC and its associated data flows and
process flows
Required network
communications uptime (at all
levels)
Network reliability
requirements (at all levels)
5011
Examples
ISA-TR84.00.09-2023
- 245 -
5012
Asset Inventory
5013
5014
The following table G2 documents the suggested information for devices contained within the cyber asset inventory. Due to the
substantial number of devices, a spreadsheet or database is generally the most efficient means to store and manage the information.
5015
Hardware Inventory
5016
Table G2
Data Field Descriptor
Device Name-ID
Device DescriptionPurpose
Device Category
Device SL-T
Zone
Plant Area Association
Physical Location
Connection
Permanent /Temporary
Manufacturer Name
Manufacturer Model #
Real Time Operating
System (OS)
Bios/Firmware
Notes
5017
Software Inventory
Field Input Guidance
Examples
ISA-TR84.00.09-2023
Data Field Descriptor
- 246 -
Field Input Guidance
Examples
Device Name - ID
Operating System
Software/Application Name
Software /Application
Category
Manufacturer Name
Manufacturer Version
Known IACS Alerts
During design, ports, protocols, services, and application
programming interfaces will be determined and documented.
This specification may be updated to reflect the documents
where this in information is documented.
Notes
5018
Regulatory requirements
5019
5020
Regulatory requirements that have been accepted for compliance are referenced in the following table G3. Any exceptions to listed
regulatory documents are noted.
5021
Table G3
Number
CFR 19.10 Subpart H
5022
5023
5024
Exceptions:
1. {Document as applicable}
Title (Examples)
Process safety management of highly hazardous chemicals
ISA-TR84.00.09-2023
- 247 -
5025
Adopted industry standards
5026
5027
Industry standards that have been accepted for compliance are referenced in the following table G4. Any exceptions to listed regulatory
documents are noted.
5028
Table G4
Number
5029
5030
5031
Title (Generic Examples)
ISA 61511-1
Functional safety – Safety instrumented systems for the process industry sector – Part 1:
Framework, definitions, system, hardware, and application programming requirements
ISA 62443-2-1
Security for Industrial Automation and Control Systems Part 2-1: Establishing an Industrial
Automation and Control Systems Security Program.
DRAFT ISA 62443-2-2
Security for Industrial Automation and Control Systems Part 2-2: Implementation Guidance
for and IACS Security Management System.
ISA TR62443-2-3
Security for Industrial Automation and Control Systems Part 2-3: Patch Management in the
IACS Environment.
ISA 62443-2-4
Security for Industrial Automation and Control Systems Part 2-4: Requirements for IACS
Solution Providers.
ISA 62443-3-2
Security for industrial automation and control systems Part 3-2: Security risk assessment
for system design.
ISA 62443-3-3
Security for Industrial Automation and Control Systems Part 3-3: System Security
Requirements and Security Levels.
ISA 62443-4-2
Security for Industrial Automation and Control Systems Part 4-2: Technical Security
Requirements for IACS Components
Exceptions:
1. {Example: SPR requirements that exceed zone security protection level targets are not required}
2. {Document as applicable}
ISA-TR84.00.09-2023
- 248 -
5032
Organizational security policies
5033
5034
Company policies, standards and procedures associated with cybersecurity expected for the design, operation, and maintenance of the
IACS throughout the lifecycle are documented in the table G5 below.
5035
Table G5
Number
Title
General Security Policy
Risk Management Policy
Management Of Change Policy
Personnel Security Policy
Bypass Policy
Cybersecurity Management System
Risk & Vulnerability Assessment Lifecycle Work Process
Access Management and Control
Electronic Use
Cybersecurity Change Management
ICS Patch Management
Network Architecture & Segmentation
Requirements for ICS Network Firewalls
Boundary Device Requirements – Managed Switches
Malware Protection
ICS Wireless Requirements
ISA-TR84.00.09-2023
- 249 -
Number
Title
Cybersecurity Event Monitoring
Cybersecurity Audit Standard
Cybersecurity Incident Detection and Response
Business Continuity
Cybersecurity stage assessment standard (CSSA) 1 thru 5
Commissioning Standard (inclusive of cybersecurity)
Acceptance Testing Standard (FAT/SAT) (inclusive of cybersecurity)
Cybersecurity Mechanical Integrity Program
Cybersecurity Training Requirements
Decommissioning
Personnel Security Management
Cybersecurity Change Management
Secure Programming Practices (For guidance reference https://top20.isa.org/login as well as
secure application coding practices such as OWASP top 20 )
Backup & Restore Procedure
ICS Patch Management Procedure
Job Cyber Assessment Procedure
Cybersecurity High Level Risk Assessment Procedure
Cybersecurity Detailed Level Risk Assessment Procedure
Communication / Data Flow Analysis Procedure
ISA-TR84.00.09-2023
- 250 -
Number
Title
Design Vulnerability Assessment Procedure
Security Level Verification Procedure
Countermeasure Inspection & Test Procedure
Audit/Compliance Procedures
Anti-Malware Procedure
User Account Management Procedure
Cybersecurity Asset Management Procedure
5036
Security measures
5037
Security measures to be implemented are documented in the table G6 below.
5038
Table G6
Data Field Descriptor
Network wide security
measures
Field Input Guidance
It is important that all systems incorporate the baseline
security policies established by the organization, e.g.
•
Requirement that the cybersecurity security measures
should not impact the performance of the PSCAI system
•
If the cybersecurity countermeasure(s) has the potential
to impact the overall response time of the safety
functions, then the response time impact of the
cybersecurity countermeasure should be incorporated in
the evaluation of the overall response time of the safety
functions (for example, the time from process deviation
detection through the process response to final element
action)
•
Definition of the safe state of the process for each
identified countermeasure.
Examples
ISA-TR84.00.09-2023
- 251 -
Data Field Descriptor
Device/Host Specific Security
measures
Field Input Guidance
•
Management support requirements for security
measures.
•
Description of system hardening measures required
•
Virus prevention and detection measures required
•
Requirements for manual action as part of
countermeasure, for example, physical isolation of the
control network from enterprise network/DMZs, etc.
•
Disaster recovery requirements for restoring full
functionality following actuation of a countermeasure
•
Upgrade strategy to address emerging and future
potential threats as they become known
Ensure security features, configuration baselines such as
Operating systems, firmware, hardware, Public Key
Infrastructure (PKI) certificates, and application Secure
Technical Implementation Guides (STIGs) are reviewed,
tested, and applied publicly available examples of STIGs.
reference https://stigviewer.com/stigs
5039
5040
Human Resources
5041
5042
5043
5044
5045
5046
{Provide reference to organizational policy, standard(s) and / or procedure(s) that document:
• Initial background checks
• Periodic refresh of background checks
• Training requirements
• Competency requirements
• Management of access rights due to change in role, transfer, retirement, or termination}
5047
Supply Chain
5048
5049
5050
5051
5052
5053
Provide reference to organizational policy, standard(s) and / or procedure(s) that document:
• Standard purchase order contract requirements relevant to cybersecurity
• Product supplier requirements including:
o hardware bill of materials list
o Firmware bill of materials list
o Software bill of materials list
Examples
ISA-TR84.00.09-2023
5054
5055
•
•
- 252 -
Product supplier cybersecurity manuals
Service provider requirements
5056
Corporate risk criteria
5057
5058
5059
5060
5061
Provide reference to organizational policy, standard(s) and / or procedure(s) that document:
• Corporate risk criteria
• Lifecycle management requirements
• Acceptable methodologies
• Frequency of revalidation
5062
Zone and conduit drawings
5063
5064
The drawing(s) list in the table G7 below illustrates the zone and conduit boundaries and the assets contained within those boundaries
for the SUC to document and communicate how the SUC is to be partitioned.
5065
Table G7
Drawing Number
Title
Guidance
It is important to identify the connectivity between
zones and conduits to identify all the logical access
points into and within the system.
Per ISA 62443-3-2
•
Each asset in the SUC is to be assigned to a zone
or a conduit
•
The CRS shall identify and document the physical
and logical environment in which the SUC is
located or planned to be located. This may be
documented on the zone and conduit drawings or
other form of documentation as applicable
5066
Threat environment
5067
The threat environment potentially impacting the SUC, and the sources of this evaluation are documented below.
5068
Current threat description: {Describe as applicable}
5069
Emerging threats description: {Describe as applicable}
ISA-TR84.00.09-2023
5070
5071
5072
5073
5074
5075
5076
5077
5078
5079
- 253 -
Threat information sources: EXAMPLES
1.
2.
3.
4.
5.
6.
7.
8.
9.
Computer emergency response teams (CERTs)
ICS-CERT
Public-private partnerships such as ISACs
IACS product suppliers
Industry advisory groups
Government agencies such as an information security agency
Threat intelligence services
Public / Private software tools that identify and/or document threats
Organizational security policies
5080
Testing
5081
Tests that are to be performed documented in the table G8 below.
5082
Table G8
Data Field Descriptor
Cybersecurity test
5083
Field Input Guidance
For each test, consider documentation of countermeasure:
•
Response times to bring the process to a safe state
•
Inspection and test frequencies
Examples
•
Host/component/application
Secure Technical
Implementation Guide (STIG)
checks (e.g., manufacturing
security manual guide setting
checks, hardening checks, etc.)
•
Basic Fuzz Testing
•
Advanced Fuzz Testing
•
Comprehensive Fuzz Testing
•
Storm Testing
•
Security Requirements Testing
•
Known Vulnerability Scan
•
Threat Mitigation Testing
•
Binary Scan for Vulnerabilities
•
Penetration testing
ISA-TR84.00.09-2023
- 254 -
5084
Zone Specific Requirements
5085
The following zones are included in the SuC:
5086
•
{Provide list of zone names}
5087
Zone and conduit characteristics
5088
5089
The following zones document their boundaries and zone-specific information and requirements. Conduits connectin g zones are
assigned to the zone with the highest SL/SPR target value.
5090
5091
Zone Name and/or unique identifier: {Provide zone name and/or unique identifier and its associated information documented in the
table G9 below for each zone}
5092
Table G9
Data Field Descriptor
Field Input Guidance
Accountable organization(s)
Accountable organization(s) – The accountable organization
is the person, group or groups who are responsible and
accountable for the security of the zone or conduit.
NOTE: The accountable and responsible organizations may
be different. If so, they should both be identified.
Safety designation
It is important to identify if the zone or conduit is safety related
or contains safety related assets.
SPR-T - Zone
The SPR-T communicates the level of protection required for
a zone or conduit based upon the results of the risk
assessment.
Device SL-T
SL-T for each device (asset contains within the zone or
conduit)
Definition of logical boundary
The logical boundary is important because it delineates the
boundary between the zone or conduit and the rest of the
system. It also helps identify the demarcation point for all
communications entering or exiting the zone or conduit.
Definition of physical
boundary
It is important to document the physical boundary if the zone
or conduit requires physical security to achieve its SPR -T.
List of assets and their
classification, criticality, and
business value
It is important to identify the IACS assets contained with in
each zone or conduit and their classification, criticality, and
business value to develop an understanding of the
consequences should that zone or conduit be compromised.
Examples
ISA-TR84.00.09-2023
Data Field Descriptor
- 255 -
Field Input Guidance
This information should be available
assessment and management of change.
Examples
to
support
risk
Physical access requirements
Remote access requirements
List of third-party connections
•
List of third parties with external interfaces and type of
connection for each, e.g.:
–
Modbus.
–
Profibus.
–
OPC.
–
IEC-61850.
–
DNP3.
–
Wireless (ISA100, WI HART, 802.11).
–
Other vendor system-specific protocols.
Logical access restrictions for
all logical access points within
the zone or conduit
Logical access points are any place where electronic
information can cross the logical boundary of a zone or
conduit.
Physical access restrictions
for all physical access points
within the zone
Physical access points (for example, fences, doors and
enclosures, card readers, locks, etc.) are any place where
personnel can gain physical access to zone or conduit assets.
List of data flows associated
with each access point
To detect anomalies, it is important to identify and document
the expected flow of data (for example, source, destination,
and protocol) throughout the system and the flow of data in
and out of a zone or conduit.
Applicable zone-specific
security policies
For each zone and conduit, it is necessary to identify the
applicable organizational security policies needed to achieve
the SPR-T. Some policies may be common to all zones or
conduits in the SUC while others may be specific.
Applicable zone-specific
security requirements
For each zone and conduit, the applicable security
requirements needed to achieve the SPR-T should be
identified and documented. Some requirements may be
common to all zones or conduits in the SUC while others
may be specific.
ISA-TR84.00.09-2023
Data Field Descriptor
5093
- 256 -
Field Input Guidance
NOTE Security requirements specification cannot be
finalized until after completion of the detailed risk
assessment.
Assumptions and external
dependencies
Oftentimes, the security of a zone or conduit is dependent
upon factors outside of the zone or conduit, such as clean
power and additional layers of physical and networ k security.
These assumptions and interdependencies should be
documented.
Other mitigations per risk
assessment
Examples may include but not be limited to certificates,
encryption, intrusion detection, white listing, etc.
Examples
ISA-TR84.00.09-2023
- 257 -
5094
Annex H − Manufacturer Security Manuals
5095
5096
5097
5098
5099
5100
When programmable / configurable equipment is involved, asset owners should expect equipment
suppliers of devices and system integrators to provide guidance relative to ensuring that security
levels defined by the asset owner can be met. Systems refer to products provided by system
integrators (e.g., control platforms, compressor packages, power monitoring and control, water
treatment systems, boiler systems, analyzers, etc.). The Security Manual should contain the
following minimum content:
5101
5102
•
Recommended architecture(s) and rules for specific tasks and compliance with ISA 62443
SL-Cs
5103
•
Suppliers’ software and version compatibility and supportability guidance with third parties
5104
•
Supplier recommended hardening practices
5105
5106
•
Security level capability documentation as a function of ISA 62443 -3-3 and / or ISA
62443-4-2 as applicable
5107
•
Required / Recommended diagnostics
5108
•
Recommended testing procedures
5109
•
Support for end of life (including hardware and software bill of materials)
5110
Recommended Architectures
5111
5112
5113
5114
5115
Description(s) of system tested recommended architecture(s) segmented into zones and conduits
should be provided as a function of tasks and what is needed to support zone SL -Cs as defined in
ISA 62443-3-3. A collection of associated recommended ent erprise integration guidelines and
rules for each architecture should also be provided. The rules should be consistent with the
intended SL-C.
5116
Compatibility / Supportability
5117
5118
5119
Asset owners typically have multiple suppliers as part of their controls and network systems. As a
result, for any specific supplier, third party software compatibility is an important concern for the
asset owner.
5120
5121
5122
5123
5124
As such, asset owners should expect their suppliers to provide information like what is illustrated
as an example in table H1 as well as the process to access the most current information. The list
of software for which compatibility has been tested and verified should include the product
supplier’s programs, operating system software, malware protection software, other 3 rd party utility
software, 3 rd party security monitoring software, asset management programs, etc.
5125
5126
Table H1
Example Compatibility List for Company ABC for Software Product XYZ (Status Date to be input)
Description
Microsoft Windows 7
Microsoft Windows
Domain Controller
5XT22 Product XYZ
library
Sub Description
Ultimate (64 bit) SP1
Ultimate (32 bit) SP1
Professional (64 bit) SP1
Professional e (32 bit) SP1
Enterprise (64 bit) SP1
Enterprise (32 bit) SP1
2016 Standard Ed. 64 bit
2012 R2 Standard Ed. 64 bit
Version x+2
Version x+1
Version x
Version x
Version x+1
Version x+2
ISA-TR84.00.09-2023
Description
McAfee Endpoint
Security
Microsoft.Net
Microsoft Office Word
Viewer
Microsoft SQL Server
Microsoft Windows
Firewall
- 258 -
Sub Description
Version x
Version x+1
Version x+2
V10.7
V10.5
V10.2
V4.6.2
2003 SP3
2014 SP3
2014 SP2
Version of installed operating
system
5127
5128
5129
5130
5131
5132
5133
5134
The definition of supported software and non-supported software should be clearly communicated,
as well as the user’s role regards use of non-tested/ non-supported third-party software. This is
intended to support asset owners as they evaluate compatibility and supportability of any third party software with the host system. As part of this evaluation the asset owner seeks to understand
the impact to the system with respect to compatibility impact on cost, ease of troubleshooting and
overall version compatibility lifecycle with the Host system and to ensure that any conflicts can be
efficiently resolved in a timely manner. This information should be provided to help ensure that the
overall IACS performance expectations remain intact .
5135
5136
5137
5138
5139
The supplier / integrator should not engage in the practice of r ecommending security capabilities
for which the supplier cannot troubleshoot or support in their system. In some cases, there may
be a conflict between two suppliers that are both essential to the asset owner. In this situation, it
may be necessary for the asset owner to implement work arounds to be implemented to ensure
overall supportability.
5140
Suppliers Recommended Hardening practices
5141
5142
5143
5144
5145
5146
5147
5148
Suppliers recommended hardening practices should also be provided . It should also be indicated
if any of these hardening practices are a function of the claimed SL-C. The user expects
documentation for all configuration details required to be defined or changed from default for both
the operating systems as well as any optional configurations. As part of these recommended
practices, a list of manufacturer default settings (to support check list intended to ensure they are
changed prior to operation) should be provided . In addition, any configurable network components
(switches, firewalls, failure contacts, alarms, etc.) should be itemized to include any data required
or needed to secure the system.
5149
Security Level Capability
5150
5151
5152
5153
5154
Security capabilities should be provided with respect to applicable ISA 62443 standards for the
products manufacturers or integrators supply . The applicable standard defining capability
requirements as a function of security level (SL) for components (devices) is ISA 62443 -4-2. The
applicable standard defining capability requirements as a function of security level (SL) for
systems is ANSI/ISA 62443-3-3.
5155
5156
5157
For each requirement with claimed conformance, s uppliers should document what organizational
procedures are required to be implemented to ensure that those capabilities that satisfy the
requirement(s) are effective.
5158
5159
Where conformance to technical requirements is lacking, the supplier should suggest what
compensating security measures might be appropriate to close the security level gap.
5160
5161
Any additional (add-on) software required to achieve this capability shall be noted so that the
asset owner understands the impact to plant lifecycle version control, com patibility, and cost.
5162
5163
5164
The information should be considered part of the operating manual, whether it is embedded in
that document or provided separately. For a cyber vulnerable device that has been approved for
use in safety systems, a manufacturer’s secur ity manual should be considered part of the safety
ISA-TR84.00.09-2023
- 259 -
5165
5166
manual. The security manual may be directly incorporated into the safety manual, or it may be a
stand-alone document.
5167
5168
5169
5170
Table H2 illustrates a format that may be used to convey the technical capabilities av ailable as a
function of either ANSI/ISA 62443-3-3 or ISA 62443-4-2 as applicable as well as the organizational
procedures required to be implemented by the asset owner to ensure the technical measures are
effective.
5171
5172
5173
5174
5175
5176
Since all the capabilities employed must be tested during the FAT and SAT, the supplier and
integrator should provide documentation regards pass/fail testing criteria. This will assist in
periodic inspection and testing that should be performed to ensure that the security capabilitie s
provided by the supplier should also be documented in the security manual. This should include
recommended intervals for the asset owner’s consideration, or a basis for the asset owner to
determine appropriate intervals.
ISA-TR84.00.09-2023
5177
5178
- 260 -
Table H2
Conformance to Technical Capabilities
Applicable Standard: [e.g. ANSI/ISA 62443-3-3, ANSI/ISA 62443-4-2]
Requirement Conformance
Capability
Req
ID
5179
5180
5181
5182
5183
5184
Reference
Name
Requirement Description
SL-1
SL-2
SL-3
SL-4
Organizational
Procedures Required
for Technical
Measure to be
Effective
Compensating
Security measures
for Consideration (1)
(1) Although suppliers cannot be accountable for compensating security measures either employed or not employed by the asset
owner, potential security measures should be documented in the security manual in those instances where the product security
level capability is not available for a requirement. While device manufacturers can n ever be responsible for compensating security
measures implemented by the asset owner, system integrators, while not inherently responsible, can be made responsible to the
extent it is documented in a written contract between the asset owner and the system integrator.
ISA-TR84.00.09-2023
- 261 -
5185
Required / Recommended diagnostics
5186
5187
5188
All diagnostics required to ensure capability as a function of security level should be documented
as well as the required action to the alarm(s). Recommended diagnostics should be documented
for consideration by the asset owner to treat as an alarm or an alert.
5189
Recommended Testing Procedures
5190
Guidance should be provided for the following testing activities:
5191
5192
5193
5194
•
•
•
•
FAT
SAT
Revalidation
Testing prior to and/or following patches, upgrades, rep air
5195
5196
5197
5198
5199
5200
The FAT guidance should be focused on helping to make the SAT following commissioning more
efficient. The SAT should focus on security performance assuming traditional control system
commissioning / SAT activities in addition to FAT activities have bee n performed as a foundation
(i.e., Any temporary loop checking architecture removed and final architecture is in place and
prepared to support startup). After an appropriate interval, revalidation testing should be performed.
This is analogous to safety system proof testing and is generally a subset of the FAT/SAT activities.
5201
5202
5203
In all cases specific documented guidance for the determination of pass / fail criteria should be
provided in the security manual. Reference Annex J, Testing, for additional information regarding
types of tests.
5204
Support end of life
5205
5206
For each version, end of life dates should be provided. End of life represents the point when no
additional patches will be system tested for that version.
5207
Page 261 of 12
ISA-TR84.00.09-2023
- 262 -
Annex I − Security Protection Rating (SPR) Verification
5208
5209
Purpose
5210
Determine estimated SPR for comparison with an applicable SPR -T.
5211
Overview
5212
5213
5214
SPR is a function of a zone or conduit security level (SL) and the maturity level (ML) of those
organizational procedures necessary to sustain the effectiveness of the defined security measures
in a specific application.
5215
Depending upon the lifecycle timeline, different SPRs are applicable. These are:
5216
5217
SPR-I - Indicates predicted compliance with targeted requirements of 62443-3-3 mapped to
Level x and below which can be fulfilled during operation by
5218
5219
•
technical security measures of a zone of the Automation Solution
including compensating technical security measures
5220
•
and reliably performed and sustained operational process measures:
5221
•
Process security measures to fulfill applicable requirements of ISA/IEC 62443 -2-1
5222
•
and process measures to fulfill applicable requirements of ISA/IEC 62443 -3-3
5223
5224
•
Process security measures associated with the technical security
measures
5225
•
and compensating process security measures
5226
5227
SPR-O - Indicates current measured compliance with targeted requirements of 62443 -3-3
mapped to Level x and below which are fulfilled during operation by
5228
5229
•
technical security measures of a zone of the Automation Solution
including compensating technical security measures
5230
5231
•
and reliably performed and sustained operational process measures (ML -O equal or
above 3):
5232
•
Process security measures to fulfill applicable requirements of ISA/IEC 62443-2-1
5233
•
and process measures to fulfill applicable requirements of ISA/IEC 62443 -3-3
5234
5235
•
Process security measures associated with the technical security
measures
5236
•
and compensating process security measures
5237
5238
Detailed assessments will typically be done by auditors in the asset owner’s organization or by
independent evaluation organizations.
5239
5240
5241
Detailed assessments are useful to find out weaknesses by highlighting requirements which are
not fulfilled. These will guide responsible organizations to develop focused organizational,
technical, or compensating security measures to remediate weaknesses identified.
5242
Procedure
5243
5244
1) Determine applicable technical requirements, e.g., requirements from ISA 62443 -3-3, physical
requirements, compensating security measures, et c.
5245
5246
a) Applicable technical requirements would typically result from a risk assessment where a
SL-T for a zone was established.
5247
5248
5249
2) For each of the applicable technical requirements that apply to the zone, verify the security
level capability (SL-C), The rating of technical measures is the lowest SL for all applicable
technical requirements.
ISA-TR84.00.09-2023
- 263 -
5250
5251
a) Reference the System Technical Capability Gap Analysis methodology contained within,
Annex - Vulnerability Identification Methodologies for guidance.
5252
5253
3) Determine applicable organizational requirements as a function of the specific technical
requirements.
5254
5255
5256
4) For each of the applicable organizational requirements, evaluate the maturity level (ML), the
alignment to the technical measures and the effectiveness to fulfill the purpose. The rating of
organizational measures is the lowest ML for the aligned and efficient requirements.
5257
5258
5259
5260
a) Reference Annex – Maturity Level Assessment for guidance
5) Based upon the determined SL and ML, determine the security protection rating (SPR) from an
appropriate matrix as determined by the asset owner. An example shown in figure I1 is provided
below:
SL1
SL2
SL3
SL4
ML4
SPR 1
SPR 2
SPR 3
SPR 4
ML3
SPR 1
SPR 2
SPR 3
SPR 3
ML2
SPR 1
SPR 1
SPR 2
SPR 2
ML1
SPR 0
SPR 0
SPR 0
SPR 0
5261
Figure I1
5262
5263
6) If the determined SPR is less than the SPR-T, then consider how to correct the situation, e.g.,
compensating security measures, improved design, or organizational measures, etc.
5264
7) The process should be performed until all zones and conduits have been assessed.
5265
5266
5267
5268
Notes:
1) Conduits should have a SL-T that is equal to or greater than the highest zone SL -T to which it
is connected.
ISA-TR84.00.09-2023
- 264 -
Annex J – Testing
5269
5270
Introduction
5271
5272
5273
5274
5275
5276
To ensure industrial automated control system (IACS) component and network technical security
measures work as intended, they should be tested. This annex describes various tests that may
be performed during FATs, SATs, initial validations, and periodic revalidations during operation as
well as providing a means to determine which tests are applicable as a function of technical
requirements contained in ISA 63443-3-3 and ISA-62443-4-2. In addition, an example check list
for inspections that supplement tests, and an issue/defect/anomaly form are provided.
5277
Work Process
5278
Whenever testing is to be performed the following should be considered :
5279
•
Document acceptance testing activities and pass -fail criteria.
5280
5281
5282
•
Document who will be part of the inspection and testing team. This is generally a
combination of integrator and asset owner personnel and/or contractors working on
behalf of the asset owner.
5283
•
Document roles and responsibilities of the acceptance testing team members.
5284
5285
•
Identify or develop test procedures for testing to be included in th e work process.
o As part of the test procedure, identify tool(s) to be used
5286
•
Develop test traceability documentation
5287
•
Set up the Acceptance Testing Environment
5288
•
Document the hardware and software inventories
5289
5290
•
Document how access lists shall be managed during testing to account for temporary
personnel.
5291
•
Conduct acceptance test readiness review
5292
5293
5294
•
Execute acceptance inspection and testing
o Perform tests identified as part of work process
o Perform the work needed to complete check lists
5295
5296
5297
5298
•
Document results
o Issues and deficiencies must be documented using the form in Appendix C
o Each issue/deficiency must be individually tracked and managed
o Communicate results to personnel required to address issues and deficiencies
5299
•
Resolve issues and deficiencies
5300
5301
5302
•
Retest as needed.
o It may be appropriate to retest deficiencies identified during the FAT at the SAT
depending upon project schedule.
5303
5304
5305
•
Document acceptance testing results
o FAT documentation including open Issue/Deficiency form information shall be
communicate to appropriate personnel as an input to the SAT.
5306
5307
5308
5309
5310
5311
5312
•
Issue and deficiencies identified during the SAT or still open from the FAT shall be
classified as mandatory prior to startup or as a punch list item
o Mandatory items must be resolved prior to approval of the pre -startup safety
review (PSSR) permitting the process to begin startup.
o Punch list items are to be resolved in a timely manner, but in no case to exceed 6
months from actual startup.
o Communicate information to appropriate personnel
5313
•
Document final acceptance testing results
ISA-TR84.00.09-2023
- 265 -
5314
o
5315
Identification of Tests
5316
D3FEND
5317
5318
5319
The following sections describe the process for mapping IEC 62443 -3-3 Security Requirements
(SR) to D3FEND and then using D3FEND’s existing mapping to ATT&CK to assist with se lecting
tests as a function of the technical security requirement.
5320
Identify a Security Requirement of interest for testing
5321
5322
5323
To help with understanding the process of mapping an SR to D3FEND, the following SR was
chosen as an example, SR 5.2 Zone Boundary Protection. SR 5.2 Zone Boundary Protection within
IEC 62443-3-3 states the following:
Communicate information to appropriate personnel
5324
5325
5326
5327
5328
5329
5330
5331
5332
5333
5334
5335
Map the Security Requirement to a D3FEND Technique
D3FEND’s model of defensive techniques and artifacts provides a knowledge base that
characterizes countermeasure technology and relates it to offensive tactics, techniques, and
procedures (TTP) in ATT&CK. The following steps provide information and guidance on how to
map SRs to D3FEND techniques. SR 5.2 Zone boundary protection identified in the previous
section will be used as an example.
1. Review the “Requirement” and “Rationale and supplemental guidance” text of the SR and
make a list of the security functions or capabilities that the SR provides. Also use the
Foundational Requirement category name to help narrow which area the SR applies to.
Some SRs might combine more than one security function or analytic. For SR 5.2 Zone
Boundary Protection:
5336
a. The FR is “Restricted Data Flow”.
5337
5338
b. The security function or capabilities to note include “monitor and control
communications” and “restrict or prohibit network access”.
5339
5340
5341
5342
2. For each security function and analytic, determine the digital artifact associated with each
function. Example of D3FEND digital artifacts include file, URL, DNS domain, process
code, etc. An excerpt of all digital artifacts is shown below in figure J1.
ISA-TR84.00.09-2023
- 266 -
5343
5344
5345
5346
5347
5348
5349
5350
5351
5352
5353
5354
Figure J1
The complete list of digital artifacts is located at the following site: Digital Artifact Ontology |
MITRE D3FEND™. For SR 5.2 Zone Boundary Protection the digital artifact “network traffic”
applies.
3. Analyze the security function interaction with each digital artifact. Examples of interactions with
digital artifacts include filtering a URL, blocking DNS traffic, analyzing a file, etc. For SR 5.2,
determine what action is being taken against network traffic. From reviewing the SR, actions such
as “restrict” and “prohibit” refer to filtering and isolation when reviewing the D3FEND matrix. The
figure J2 screenshot below shows the “Isolate” tactic and the “Network Isolation” column from the
D3FEND matrix.
ISA-TR84.00.09-2023
- 267 -
5355
5356
5357
5358
5359
Figure J2
By reviewing the titles of techniques in the column, the techniques “Inbound Traffic Filtering” and
“Outbound Traffic Filtering” may apply. The user can review the techniques in more detail by
clicking on each to review the writeup.
ISA-TR84.00.09-2023
- 268 -
5360
5361
Figure J3
5362
5363
5364
5365
5366
5367
5368
Figure J4
Reviewing the writeups confirm that “Inbound Traffic Filtering” (figure J3) and “Outbound Traffic Filtering”
(figure J4) D3FEND techniques map to SR 5.2 Zone Boundary Protection.
Use D3FEND to Identify what ATT&CK Techniques to Select as a Test Case
Within each writeup most D3FEND techniques include related ATT&CK techniques that have been
mapped to D3FEND’s model of defensive techniques and artifacts. For Outbound Traffic Filtering,
ISA-TR84.00.09-2023
5369
5370
- 269 -
the related ATT&CK techniques are shown below in figure J5. Each ATT&CK technique can be
reviewed in more detail on the MITRE ATT&CK website.
5371
5372
5373
5374
5375
5376
5377
Figure J5
Test a SR using an offensive technique
Each of the identified ATT&CK techniques can be used to test a SR by reviewing the writeup of
the ATT&CK technique and developing a test. Co ntinuing with example of SR 5.2 Zone Boundary
Protection, one of the related ATT&CK techniques is Network Denial of Service. The writeup of an
example ATT&CK technique is shown below in figure J6.
ISA-TR84.00.09-2023
- 270 -
5378
5379
5380
Figure J6
5381
5382
5383
5384
5385
5386
Each ATT&CK technique has an explanation of what the technique is and a section for “Procedure
Examples”. The “Procedure Examples” provides references with links to detailed explanations of
how the offensive technique was used by adversaries. By reviewing the writeup and the references
in the “Procedure Examples” section, tests can be developed that emulate adversary behavior and
test the implementation and configuration of SR 5.2. This same procedure can be repeated for
other SRs to test against different offensive techniques.
5387
Other Test Selection Guidance
5388
5389
5390
5391
5392
5393
5394
Table J1 provides a list of tests that can be run as part of the cybersecurity program throughout
the facilities lifecycle. When determining what tests to conduct, it is advisable to consider the
consequences and the associated risk to the company versus t he costs of conducting the various
tests. This document assumes a desire to reduce the risk by an order of magnitude for each
increase in SL-T. As such, the table below uses the SL-T as a proxy for consequences to help the
asset owner make decisions. The value of the tests is that they seek to determine vulnerabilities
irrespective of whether a specific SL is attained relative to conformance with ISA 62443 -3-3.
5395
5396
5397
It should be noted that there are situations where new solutions may be proposed. Thus, it is
desirable to test prior to authorization to use. This should occur earlier in the lifecycle so as not to
impact project(s) cost and schedule.
5398
5399
When developing test procedures for a project, the level of testing that has been performed earlier
may influence the test procedures performed in later projects.
5400
Table J1
Test Type
Basic Fuzz Testing
Advanced Fuzz Testing
SL-T 1
X
SL-T 2
SL-T 3
SL-T 4
X
X
X
X
X
X
ISA-TR84.00.09-2023
- 271 -
Storm Testing
X
X
X
X
Security Requirements Testing
X
X
X
X
Known Vulnerability Scan
X
X
X
X
Threat Mitigation Testing
X
X
X
X
X
X
X
X
X
X
X
Binary Scan for Vulnerabilities
Penetration Testing
Communication Robustness Testing
X
X
5401
5402
Table 2 provides a list of tests considering their appropriateness for different activities over the
lifecycle.
5403
Table 2
Test
Basic Fuzz Testing
Advanced Fuzz Testing
Storm Testing
Security Requirements Testing
Known Vulnerability Scan
Threat Mitigation Testing
Binary Scan for Vulnerabilities
Penetration Testing
Communication Robustness Testing
FAT
SAT
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X (1)
Initial
Validation
X
X
Periodic
Revalidation
X
X
X
X
X (1)
X
5404
1) Only if system is not connected to any actual operations.
5405
Test Descriptions
5406
For each of the tests in the table above, additional guidance and descriptions are provided.
5407
Fuzz Testing
5408
5409
5410
5411
5412
Fuzzing is a dynamic testing method used for identifying bugs and vulnerabilities in software. It is
mainly used for security and stability testing of the codebase. The software under test is injected
with invalid, malformed, or unexpected inputs into the system to reveal software defects and
vulnerabilities. An automated fuzzing tool is used to inject these inputs into the system and then
monitors for unexpected occurrences such as crashes or information leakage.
5413
The generalized Fuzz Testing Procedure is as follows:
5414
1. Step 1) Identify the target system.
5415
2. Step 2) Identify inputs.
5416
3. Step 3) Generate Fuzzed data.
5417
4. Step 4) Execute the test using fuzzy data.
5418
5. Step 5) Monitor system behavior.
5419
6. Step 6) Log defects.
5420
7. Step 7) Take steps to eliminate or mitigate vulnerabilities identified
ISA-TR84.00.09-2023
5421
- 272 -
Types of Fuzzing tests include but not limited to:
5422
5423
•
Random fuzzing - Random inputs are sent to an application without any systematic
method.
5424
5425
5426
5427
5428
5429
•
Template or grammar-based fuzzing – This method relies on a template that’s manually
generated. This template provides the information to the fuzzing tool necessary to
generate each input. The template relies on the persons creating the template to have
knowledge of how the protocol is built, leading to intelligent input generation. The metho d
is somewhat limited by the knowledge of the developers as well as it constrains the areas
of application to a single approach irrespective of different applications.
5430
5431
5432
5433
5434
5435
•
Guided fuzzing – Guided fuzzing tools rely solely on its target applications behavior to
inform how to generate its inputs. So, the fuzzing tool will generate 1 input, observe how
the application behaves and then then generate the next input based upon what it has
learned. These fuzzing can be more effective than template fuzzing tools becaus e they
custom generate tests specific to the applications. Their limitation is that they have
difficulty with complex conditional code within a program, limiting their testing depth.
5436
5437
5438
5439
5440
•
Advanced Fuzz Testing - Takes the method of guided fuzzing and combines i t with
symbolic execution. Symbolic execution is a method that uses a dynamic analysis
technology to solve complex branch conditions. In doing so, it generates a body of
information. This allows the fuzzing tool to methodically resume its testing and analy ze
deeper into the program.
5441
5442
5443
5444
5445
5446
5447
5448
5449
5450
5451
5452
5453
5454
5455
5456
5457
5458
5459
5460
5461
5462
5463
5464
5465
5466
5467
Storm Testing
Storm testing is intended to determine:
•
•
The degree to which broadcast storms, where excessive traffic, that can cause a control
system to stop working or work in an indeterminate way is mitigated.
The triggers that can cause a network storm
Network storms can be due to cyber-attacks, poor design, simple mistakes, or an overreaction to
normal conditions. Issues that can make network storms more likely include:
•
•
•
•
Cabling issues, e.g., cable loops present
Poor network management / monitoring
Improperly maintained network configuration
Inadequate network design
The storm test is conducted by ramping up traffic stepwise from 0% to a 100% while simulating
how the system will respond and perform. Typical results include understanding the effects:
•
•
•
•
•
Loss of communication
Loss of redundancy
Loss of HMI connections
A frozen controller
Capacity limitations
Targets for a storm test typically include:
•
•
•
•
Programmable Logic Controllers
Operator stations
Servers and historians
Network devices, e.g., routers, switches, firewalls.
Prior to the test, it is important to define pass-fail criteria that generally considerers:
•
•
Control system can maintain its functionality as expected by the operators
Appropriate alerts and alarms are generated. This also includes checking that procedures
for the expected response have been documented and personnel trained accordingly.
ISA-TR84.00.09-2023
5468
5469
5470
5471
5472
5473
5474
5475
5476
•
•
•
•
- 273 -
Detection of any control system unexpected behavior
Response should a fatal error occur
Ability to handle DoS attack
Ability to recover should there be a failure of communications during a DoS attack
Security Requirements Testing
This is intended to ensure that the requirements documented in the cybersecurity requirements
specification have been implemented and t hat the organizational procedures are in place. This is
often accomplished by use of a check list with validation as required by the pass / fail criteria.
Known Vulnerability Scan
5477
5478
5479
The purpose of Vulnerability Identification Testing (VIT) is to scan a devi ce under test with a
commercially available tool to identify known vulnerabilities. Identified vulnerabilities can then be
addressed to ensure adequate mitigation is in place.
5480
5481
5482
5483
5484
The ISASecure program uses the US-CERT National Vulnerability Database (NVDB) as the
reference list for identifying known vulnerabilities, providing objectivity and transparency for the
ISASecure assessment process. Known vulnerabilities in the US-CERT NVDB are organized into
globally accepted Common Weakness Enumeration Specificatio n (CWE) categories and the NVDB
is updated on an on-going basis as new vulnerabilities are identified and verified.
5485
Note:
5486
5487
5488
5489
5490
5491
5492
1. Certification of a device or system does not mean that a zone security level capability
(SL-C) will be met for the SL-T as the certification is for known vulnerabilities at the time
of certification and rely on the end user’s cybersecurity management system (CSMS) to
provide adequate protection for several the threat vectors that cannot be inherently
prevented by the device. Using certified devices does, however, provide a better-known
starting point that should minimize the potential for serious surprises that are difficult to
address.
5493
5494
5495
5496
5497
2. Even when using certified equipment, ISCI recommends that end -users require their
suppliers to re-run the VIT during factory acceptance testing (FAT) and site acceptance
testing (SAT). These procurement steps help ensure that new vulnerabilities that may
have been discovered and added to the US-CERT NVDB during the time interval between
the ISASecure certification VIT scan date and commissioning date are identified.
5498
5499
5500
5501
Information about the US-CERT NVDB may be found on the Unites States NIST website at:
http://nvd.nist.gov
Information about Common Weakness Enumeration Specification (CWE) categories may be found
on the US NIST website at:
5502
5503
5504
5505
5506
ISCI evaluates commercially available VIT test tools and recognizes them for use. VIT tools are
selected based upon several factors including but not limited to broad availability/support, industry
acceptance, and tight linkages with the US-CERT NVDB.
5507
A list of ISCI Recognized VIT test tools can be found using this link:
5508
5509
5510
5511
5512
5513
5514
5515
http://nvd.nist.gov/cwe.cfm
Listing of ISCI recognized Vulnerability Identification Testing Tools
ISA-TR84.00.09-2023
- 274 -
5516
5517
5518
5519
5520
5521
5522
5523
Threat Mitigation Testing
Threat mitigation testing is a method that is employed for testing the effectiveness of the mitigation
against threats identified and validated in a threat model. Threat mitigation testing can be done at
3 different levels as shown in figure J7 below:
Threat intelligence level
Focus on external factors such as geo-politics
adversary centric profiling, threat life cycle stages.
System (function) level
Focus on IACS architecture and related IACS functions,
data flows, functional deviations, (inter)dependencies,
potential consequences.
Equipment, channel or application
level
5524
5525
Focus on exploitation of software flaws in system software,
applications, and protocol (channel) vulnerabilities. Aligned
with IEC 63443-4-1 SVV-2 requirement
Figure J7 - Hierarchy of threat mitigation analysis
5526
5527
5528
5529
5530
5531
5532
5533
5534
5535
5536
•
Threat intelligence level - At this level an adversary centric approach is followed such as described
by the Cyber Threat Framework of the US Office of Director of National Intelligence (ODNI). The
Cyber Threat Framework divides the threat lifecycle into 4 stages: Preparation, Eng agement,
Presence, and Effect/Consequence. These form the top layer (layer 1) of the framework, for each of
the stages the framework defines objectives (layer 2), and an actions nomenclature (layer 3). Threat
mitigation testing at this level assists in:
o Threat profiling for strategic decision making identifying the intent, and capabilities of potential
threat adversaries.
o Characterize and categorize threat activity to support selection of appropriate levels of
protection.
o Achieve common situational awareness across the organization.
5537
5538
5539
5540
5541
5542
5543
5544
5545
5546
5547
5548
•
System (function) level - At this level the threat mitigation analysis considers the overall
IACS architecture and the various inter-relationships / dependencies between IACS primary
functions (e.g., BPCS, SIS, APC, LIMS, etc.) and its components (e.g., operator stations,
engineer stations, servers, network equipment, domain controllers, etc.) and data flows.
The user first models the system / assets / data flows and then determines the relevant
threat events to the system. A typical example of this is a function-based risk assessment
that exercise a set of cyber-attack scenarios against a model of the IACS investigating the
likelihood that a specific consequence occurs, or loss scenario is triggered (e.g., a process
safety LOPA scenario). Threat mitigation testing at this level is typically done as part of the
feasibility phase (defining security mitigation requirements), building phase (identifying
mitigation gaps in the security design), and operational phase (identifying securit y
mitigation gaps caused by a changing security landscape)
ISA-TR84.00.09-2023
- 275 -
5549
5550
5551
5552
5553
5554
•
5555
5556
5557
5558
5559
5560
5561
5562
Threat mitigation testing can be isolated to the technical system / component or can include the
consequence for the installation or production process. In the first case the test identifies the
technical consequences, in the second case the cyber physical consequences are included. Threat
mitigation testing for cyber physical consequence is always done at system (function) level using
a combination of cyber-attack scenarios and loss scenarios such as defined in LOPA or HAZOP
exercises (CAUSE => SAFEGUARD => CONSEQUENCE). In these cases, the consequence (a
functional deviation) of the cyber-attack is mapped on either the cause or safeguard of the loss
scenario. This extended scenario is then used for the threat mitigation evaluation.
Equipment, channel, or application level - Threat analysis at this level is the most granular
and carried out by the manufacturers and certification bodies for the IACS equipment.
Threat analysis is based on threat modeling methods such as STRIDE (Spoofing, Tampering,
Repudiation, Information disclosure, Denial of Service, Elevation of privilege) , heuristic
techniques, and fuzzing. Threat mitigation testing at this level needs to meet IEC 62443-4-1
Security and Verification requirements.
5563
5564
Binary Scan for Vulnerabilities
5565
5566
5567
5568
5569
This method tests at the binary code level using an analysis tool to assist identification of certain
known vulnerabilities that can give rise to common attack vectors . Evaluation of stripped binary
code allows analysis of software without any help from the manufacturer of the person who wrote
the code. The method can also be used to evaluate third party libraries, enabling analysis of how
applications will interact.
5570
5571
5572
5573
Binary code level analysis is important as many cyber security threats move from network-level
attacks to application layers. Binary code is fundamental, so it is a means to evaluate complex
applications, each using different code languages from multiple sources while they are in a static
state, i.e., non-running state.
5574
5575
5576
Penetration Testing
The performance of a penetration test simulates a cyber-attack on the IACS solution to identify
vulnerabilities. To conduct a penetration test, the following steps are generally performed:
5577
5578
5579
5580
5581
5582
5583
5584
5585
5586
5587
5588
5589
5590
5591
5592
5593
5594
5595
•
5596
5597
•
•
•
•
Plan and perform reconnaissance – this entails the scope definition and a description of
what is expected to be achieved. In addition, the tests to be us ed need to be selected.
Once the scope is agreed, reconnaissance is performed to gather intelligence regarding
the network to better understand how the system works and what potential vulnerabilities
may exist.
Scanning – Intended to determine how the system will respond to different types of
intrusions. Both static analysis where inspection of an application’s code is performed in
a non-running state to appraise or judge how it will perform while running and dynamic
analysis that involves inspection of an application’s state while it is running. Dynamic
analysis should be more effective, however, performance on a system in actual
production mode can be dangerous.
Gaining Access – Vulnerabilities are discovered using web application attacks (e.g.,
cross-site scripting, SQL injection, backdoors, etc.). Once a vulnerability is discovered,
attempts to exploit are performed. This may involve escalation of privileges, data theft,
traffic interception, etc. The knowledge gained allows a better understanding of what
potential damage may occur in a successful attack.
Maintaining access – Once access is gained, the vulnerability is then used to determine if
a persistent presence can be maintained that is long enough to achieve more in -depth
access, thus mimicking an advanced persistent threat.
Analysis – Once the tests are complete, the results are tabulated that detail the specific
vulnerabilities exploited, what sensitive data was accessed, as well as the time without
ISA-TR84.00.09-2023
5598
5599
5600
- 276 -
detection. This information is then used to help d etermine improved firewall settings as
well as other security measure solutions.
Various penetration testing methods include:
5601
•
External testing that targets assets than can be scanned from the internet .
5602
5603
•
Internal testing below the firewall to simulate an attack by a malicious insider who may be
an employee, contractor, or by someone who was able to steal their credentials.
5604
5605
•
Blind testing provides for a real-time view of an actual attack by only providing the name
of the system that is to be targeted.
5606
5607
5608
5609
•
Double-blind testing provides no prior knowledge of the simulated attack to the personnel
responsible for security monitoring as well as only providing the penetration tester the
name of the system that is to be targeted. This type of test provides the most realist ic
simulation of an actual attack.
5610
5611
5612
•
Targeted testing allows both the penetration tester and the personnel responsible for
security monitoring to work together, keeping each other updated as to their movements.
This method can be a valuable training aid.
5613
Communication Robustness Testing
5614
5615
Communication Robustness Testing and Security Requirements Testing is intended to help ensure
that devices and systems are more robust against network attacks.
5616
5617
5618
5619
The ISA Security Compliance Institute operates a structured Communication Robustness Testing
tool recognition program to identify communication robustness testing tools. communication
robustness testing tool recognition requirements in ISASecure specifications, available for
download on this website.
5620
https://www.isasecure.org/en-US/Test-Tools
5621
5622
ISCI is in constant contact with cybersecurity test tool suppliers and new test tools may be added
in the future.
ISA-TR84.00.09-2023
- 277 -
5623
Example Check List
5624
5625
Table J2 shows as generic check list. It should be modified (add or delete items) as appropriate for the type of acceptance testing (e.g.,
FAT, SAT, etc.) or audit being performed.
5626
Table J2
Check List Item
Pass/ Fail Criteria
1. Accounts
•
•
Account list created
Only approved and needed
accounts exist on the specific
applications
2. Account Management
•
Accounts are managed under
formal change management
3. Unused firewall ports
disabled/blocked
•
Used ports have defined
business case
No port without a defined
business case is open
All unused ports have physical
blocks installed
All unused services and drivers
have been disabled or
uninstalled
•
•
•
4. Unused PC, server, switch,
router, gateway, KVM and
monitor ports
disabled/blocked
•
•
•
•
5. Default passwords changed
•
Pass
Fail
NA
Ports available for use (physical
and virtual) have defined
business case
All virtual ports initially closed
and only added as approved
software/application is installed
All unused physical ports
disabled and have physical
blocks installed
All unused services and drivers
have been disabled or
uninstalled
All applications and device
specific hardware requiring
Page 277 of 12
Comments
ISA-TR84.00.09-2023
- 278 -
Check List Item
•
6. Hardware inventory
•
•
•
Pass/ Fail Criteria
passwords identified and
documented
Verification that each default
password has been changed
Hardware inventory exists
All IACS equipment have been
identified as a cyber asset with
an identification number
Hardware inventory is up to date
7. Software inventory
•
•
Software inventory exists
All firmware and software are
most recent version, i.e., up to
date
8. Installed software
•
•
No blacklisted software installed
Only whitelisted software
installed
All unnecessary modules and
software are removed
•
9. Patch management
•
Formal patch management work
process in place
10. Operating System (OS)
•
OS load is up to date and
patched accordingly
Any aspects, applications or
services not utilized are removed
•
11. Keyboard, video, mouse
(KVM) servers are setup
•
•
•
•
12. Switches, hubs, gateways,
and firewalls setup
•
Functional requirements
documented
Setup per design
Any aspects, applications or
services not utilized are removed
Functional requirements perform
as needed
Functional requirements
documented
Pass
Fail
NA
Comments
ISA-TR84.00.09-2023
- 279 -
Check List Item
•
•
•
Pass/ Fail Criteria
Configured per the cybersecurity
requirements specification (CRS)
/ including profile, including
power up and power down
routine.
Any aspects, applications or
services not utilized are removed
Functional requirements perform
as needed
13. Foreign device interfaces,
e.g., industrial firewall,
general boundary device that
manage connections
between other networks and
the process control network.
•
14. Engineering Workstation
•
bios boot sequence is locked to
ensure it does not boot up from
another undocumented source
15. Controller setup
•
Functional requirements
documented
All unused features are disabled,
e.g., web server
Functional requirements perform
as needed
Functional requirements for
controller logic matching
community best practices for
secure programming e.g., Top 20
PLC secure coding practices
•
•
•
•
16. Human Machine Interface
(HMI)
17. Shared Drives
•
Designed in accordance with the
CSRS
Installed per design
•
All HMI included in hardware
inventory
Screen savers and timing set in
accordance with CSRS are
enabled on all HMI
•
Valid per documented design
Pass
Fail
NA
Comments
ISA-TR84.00.09-2023
- 280 -
Check List Item
18. Data flows
Pass/ Fail Criteria
•
•
•
19. Packaged Equipment
•
•
•
•
Expected data flows across
zones are mapped and
documented
Data flow traffic baseline is
documented
Data flow traffic baseline
consistent with data flow map
Functional requirements
documented
All interfaces designed in
accordance with CSRS
All unused features are disabled
Functional requirements perform
as needed
20. Malware protection
•
•
•
Anti-virus software installed
Anti-virus software up to date
Anti-virus software under formal
update procedure
21. Logging
•
•
All FAT diagnostic logs cleared
Logging management review is
in place
22. Intrusion Detection
•
Implemented per manufacturer
recommendations
23. Security measures per risk
assessment
recommendations
•
•
Recommendations implemented
Security measures perform per
their expectations
24. Backup / restore
•
•
Backup work process fully tested
Restoration work process fully
tested
25. Diagnostic alarms
•
Diagnostic alarms have been
identified and documented
Diagnostic alarms tested
•
Pass
Fail
NA
Comments
ISA-TR84.00.09-2023
- 281 -
Check List Item
26. Fuzz testing
Pass/ Fail Criteria
•
•
Level (i.e., basic, advanced,
comprehensive) of testing
performed per SL-T
No drop out of Essential
Functions monitors (upward &
downward) during test.
27. Storm testing
•
No dropout of upward essential
function monitors except during
100% storms, and monitor must
return at completion of storm.
No downward monitor (Controller
IO) dropout is allowed.
28. Security Requirements
Testing
•
Manufacturer security
requirements (from user and/or
security manual) implemented
and function as intended
All the security capabilities from
IEC62443-4-2 for desired
security level. All security
requirements have been verified
by test if possible, or by analysis
otherwise. (Note: Wherever
equipment certification
documentation is adequate, it
may be used as proof of
compliance as a function of
specific requirements)
•
29. Vulnerability scanning, e.g.,
Nessus
•
No vulnerabilities above medium
severity and any medium
severity vulnerabilities must be
explained and justified.
30. Binary Scan for
Vulnerabilities
•
No vulnerabilities above medium
severity and any medium
severity vulnerabilities must be
explained and justified.
Pass
Fail
NA
Comments
ISA-TR84.00.09-2023
- 282 -
Check List Item
Pass/ Fail Criteria
31. Threat Mitigation Testing
(Note: Requires the creation
of a threat model. This may
be beyond personnel
capabilities. Should only be
entertained if recommended
by detailed level risk
assessment)
•
All mitigations in the threat
model have been tested and
perform as designed
32. Penetration test (Note:
Should never be run if plant
is operating)
•
No loss or major deviation of
Essential Function monitors
during penetration test. No loss
of confidentiality, integrity, or
availability because of test.
33. Test equipment
•
Test engineering programs
removed from all computing
equipment
34. Gathering and Implementing
Manuals and hardening
guides
•
Ensure user, technical,
configuration and commissioning
manuals from vendors, suppliers,
service providers are gathered,
reviewed, and implemented
Ensuring security best practices
guides are leveraged and
implemented for applications and
operating systems in
collaboration with vendor guides
(e.g., security technical
implementation guides STIGs)
•
5627
Pass
Fail
NA
Comments
ISA-TR84.00.09-2023
5628
- 283 -
Sample Issue/Defect/Anomaly Form
5629
Table J3
ISSUE / DEFECT / ANOMALY REPORT
Issue ID:
Tester Name:
Hardware impacted
Bios / firmware version
OS Version
Applications impacted
Application version
Preliminary Severity Assessment
Nature of Issue / Defect / Anomaly:
What occurred:
What activity was underway at time
of occurrence
How did it occur:
What piece of equipment first
identified
When did it occur:
Describe how to reproduce the
error:/ vulnerability
ISSUE INFORMATION
Severity
following
assessment
5630
5631
5632
Status:
Issue / Defect / Anomaly Form
ISA-TR84.00.09-2023
- 284 -
5633
Annex K – Example Audit Form(s)
5634
Table K1
Instructions:
Complete 1 Physical Inspection form for each area or location where ICS PCs, Servers and Controllers are physically located.
Area / Location:
Cybersecurity Mechanical Integrity Quarterly Validation
Date:
Physical Inspection Section
I/O/Server/Control/ Production Floor Location
Name
Category
Pass Fail Criteria
Operation
Unit
Name
Status
Pass
Physical Security
Control enclosures and/or server/IO room is locked and secure.
Fail
Pass
Screen savers on servers are still active and times out after a
maximum of 10 minutes of inactivity and that requires a
password to unlock.
Device Security
0.1.1.1
All USB ports (used or unused) on ICS PCs,
servers, KVMs (Keyboard, Video, monitor extender),
terminals, USB hubs, or on similar devices are still secured
to prevent unauthorized access.
Fail
Pass
Fail
Pass
All ICS network ports are still secured to prevent unauthorized
access. This applies to all used and unused ports on network
equipment, workstations, and servers.
Fail
Pass
Checked by
ISA-TR84.00.09-2023
- 285 -
Fail
All configuration ports are secured to prevent unauthorized access
and changes.
Basic
Layers
Protection
Personal
Usage
of
Device
Physical Inspection Continued
Pass
Connectivity through a primary firewall that is approved, installed,
and configured by site IT in conjunction with the facility ICS Security
Fail
Lead. Access to the internet is still unavailable for the ICS
equipment connected via the firewall. For example, a Google
page cannot be reached via ay ICS PC.
No USB personal devices were observed attached to the ICS
PC’s
Pass
Fail
No passwords were posted in visible unsecure locations
Pass
Fail
Cybersecurity
Awareness
ICS assets are clearly identified vs business assets
Pass
Fail
5635
ISA-TR84.00.09-2023
- 286 -
Annex L - Cybersecurity KPIs and Metrics
5636
5637
Introduction
5638
5639
5640
This annex uses the core principle of ISO 14253-1 “Decision rules for proving conformance or nonconformance with specifications” to differentiate whether conformance or non -conformance is
determined.
5641
5642
5643
5644
5645
5646
5647
Conformance metrics should be developed for the cybersecurity policies, practices, and
operational performance specific to the systems under consideration. Which metrics are to be
measured and used to create key performance indicators (KPI’s) is a decision made by the asset
owner as they are generally used to help improve performance ov er time. An assessment of their
organization’s relative maturity level may assist what KPI’s are most relevant over time as well. As
performance improves, KPI’s may be changed, performance expectations raised or revised to
assist continuous improvement.
5648
5649
5650
5651
Sample key performance indicators have been documented in this annex and are organized as a
function of an asset owner’s cyber security management system. This is intended to provide
example KPIs and Metrics to help measure their performance for the purpose of improved
management.
5652
5653
5654
As part of quality assurance, the example KPIs and Metrics provided have been reviewed using
the metric development checklist documented in Table L1. This table can also be useful should
the reader wish to develop additional KPIs and Metrics for their use.
5655
Table L1 – Metric Development checklist
Priority
1
Description
KPIs and Metrics should satisfy
the criteria specified in ISO
14253-1
Remarks
Measurable: consistently measured with objective criteria
Context specific: relevant to the user (Asset Owner, System
Integrator, Product Provider, Service Provider, and
Compliance Authority)
NOTE 1 The criteria require KPIs and Metrics to be
actionable.
Conformance KPIs and Metrics: expressed as a cardinal
number or percentage
NOTE 2 Qualitative labels like high, medium, and low are
not acceptable.
NOTE 3
Expressed using at least one unit of measure.
Collection and processing: automated to the maximum extent
possible
NOTE 4 In order to avoid intensive labor and ensure
timeliness, the criteria recommend the use of automation
where possible.
2
KPIs and Metrics should be
actionable
Action trigger values are informative breakpoints that can be
used or changed by the user.
If triggered, recommended action(s) to be taken
3
KPIs and Metrics should be
associated with requirements
Format should provide the capability to relate KPIs and
Metrics to the relevant documents in the Error! Unknown
document property name. series or IEC-61511 series.
NOTE 1 KPIs and Metrics are not associated with security
level per se.
4
KPIs and Metrics should be
mapped to primary Stakeholders
of the metric
Owner/Operator, Product Supplier, Service Provider, System
Integrator, Compliance Authority
ISA-TR84.00.09-2023
Priority
5
5656
5657
- 287 -
Description
KPIs and Metrics and associated
models and terminology should
consider the governing
requirements in Error! Unknown
document property name. and
include the necessary extensions
to provide the proper context for
system conformance KPIs and
Metrics.
Remarks
.
For additional information regarding cybersecurity KPIs and Metrics, the reader may wish to refer
to the following references:
5658
5659
•
Center for Internet Security (CIS), CIS Security KPIs and Metrics, v1.1.0, November 1,
2010.
5660
5661
•
Center for Internet Security (CIS), A Measurement Companion to CIS Critical Security
Controls, Version 6, October 2015.
5662
5663
•
NIST Special Publication 800-55 Revision1, Performance Measurement guide for
Information Security, July 2008.
5664
Sample Performance KPIs and Metrics
5665
5666
Table L2 provides guidance for each of the data attributes when creating a specific KPI. This
guidance was used when creating example KPI’s that follow.
5667
Table L2 – KPI Table Guidance
KPI ID
A unique identifier for KPI’s or Metric
Description
Name of the KPI or Metric
Input (Data Source)
Description of the data used to perform the calculation.
Output (KPI)
The mathematical equation used to compute the output
numerical value.
Unit of Measure
Associated descriptor that provides context for a numeric value
calculated and enhances the meaning. <<ed. “Description seems
more appropriate for the measurement name than the calculation
method. It is recognized that 84.00.04 combines both into a
single field >>
Leading / Lagging
“Leading” – a forward looking measure which indicates the
performance.
“Lagging”– a retrospective looking measure which indicates the
performance.
Fail Criteria
a cardinal number or percentage that when exceeded results in
applicable action as described.
Impacted
Stakeholders
Primary
KPIs and Metrics should be mapped to primary Stakeholders of
the metric, e.g., Owner/operator, product supplier, service
provider, system integrator, compliance authority
Applicable Action
KPIs and Metrics should be actionable. Note that action trigger
values are informative breakpoints that can be used or changed
by the user.
If triggered, action required should be taken.
Relative Value
A description of how the measurement when utilized generates
value <<ed, “relative” seems unnecessary>>
ISA-TR84.00.09-2023
- 288 -
Maturity Model Relation
Identify any predicator metrics which must be at high maturity prior
to implementing this KPI or metric
Comments
Open field for author comments
Traceability
A description of what the technical basis was (if applicable)
5668
Organizational security measures
5669
5670
5671
5672
The balance of this annex provides example KPI’s that may be considered by asset owners to
assist measurement of their performance. Which KPI’s are used is a decision an asset owner
decides upon, recognizing that these may change as a function of what is their current maturity
level with respect to security.
5673
ORG 1 - Security related organization and policies
5674
ISA-TR84.00.09-2023
5675
- 289 -
Org 1.1
KPI ID
Org 1.1
Description
Percentage of personnel that are compliant with cyber hygiene
(awareness) training
Input (Data Source)
•
•
•
•
Output (KPI)
[(CHTE + CHTC) / (TotE + TotC)] *100
Unit of Measure
Percent
Leading / Lagging
Leading
Fail Criteria
Impacted
Stakeholders
< 99 %
Primary
Owner/operator, service provider, system integrator
Applicable Action
Schedule persons not compliant for required training
Relative Value
Employees and contractors who do not understand or practice
good cyber hygiene represent a significant vulnerability that can
be exploited by cyber threat agents.
Maturity Model Relation
As actual percentage increases, it is an indication of increasing
maturity level.
Comments
•
•
Traceability
5676
Total # employees (TotE)
Total # contractors (TotC)
# Employees compliant with cyber hygiene (awareness)
training (CHTE)
# Contractors compliant with cyber hygiene (awareness)
training (CHTC)
When first implementing, it may be more appropriate to use a
lower percentage for fail criteria and to raise it as training is
initially implemented to promote continuous improvement.
Asset owner would define audit frequency (e.g., quarterly)
and reporting frequency (e.g., annually)
Modification of NIST SP 800-55 Rev 1 Measure 4
Org 1.2
KPI ID
Org 1.2
Description
Percentage of automation personnel that are compliant with
targeted cybersecurity training
Input (Data Source)
•
•
•
•
Total # automation & electrical employees (TotAE)
Total # automation & electrical contractors (TotAC)
# Automation & electrical employees compliant with targeted
cyber training (CHTAE)
# Automation & electrical contractors compliant with targeted
cyber training (CHTAC)
Output (KPI)
[(CHTAE + CHTAC) / (TotAE + TotAC)] *100
Unit of Measure
Percent
Leading / Lagging
Leading
Fail Criteria
< 99 %
Impacted
Stakeholders
Applicable Action
Primary
Owner/operator, service provider, system integrator
Schedule persons not compliant for required training
ISA-TR84.00.09-2023
- 290 -
KPI ID
Org 1.2
Relative Value
Employees and contractors who have access to the control system
and associated network who are not competent relative to
cybersecurity represent a significant vulnerability that can be
exploited by cyber threat agents.
Maturity Model Relation
As actual percentage increases, it is an indication of increasing
maturity level.
Comments
•
•
Traceability
5677
Companies may wish to create additional sub KPI’s using the
input metrics
Asset owner would define audit frequency (e.g., quarterly)
and reporting frequency (e.g., annually)
Modification of NIST SP 800-55 Rev 1 Measure 4
Org 1.3
KPI ID
Org 1.3
Description
Percentage of system components that undergo maintenance in
accordance with formal maintenance schedules
Input (Data Source)
•
•
Output (KPI)
(NSC/TSC) *100
Unit of Measure
Percent
Leading / Lagging
Leading
Fail Criteria
A value less than the percentage selected by the asset owner.
This value should be chosen as a function of risk determination
(e.g., identification of components if not maintained represent a
security risk) During initial implementation, values that are less
conservative may be used and then made more challenging as
performance improves.
Impacted
Stakeholders
Primary
Total number of system components (TSC)
Number of system components included in a formal PM
and/or condition-based maintenance program (NSC)
Owner/operator, product supplier, service provider, system
integrator, compliance authority
Applicable Action
Evaluate the maintenance program to determine what activities
should be part of a PM and / or a condition-based maintenance
program.
Relative Value
An optimized maintenance program should provide improved
integrity and availability of the system.
Maturity Model Relation
Measures the relative depth and breadth of the maintenance
program. A low value may indicate a run until it breaks program
which can lead to a reactive rather than a proactive approach. This
in turn can lead to a lower security capability.
Comments
•
•
•
The measure is intended to help ensure maintenance is
performed in a timely manner.
KPI requires a formally documented maintenance program to
be in place as well as documentation of how many
components underwent maintenance in accordance the
formal maintenance program.
Asset owner would define audit frequency (e.g., quarterly)
and reporting frequency (e.g., annually)
ISA-TR84.00.09-2023
5678
5679
- 291 -
KPI ID
Org 1.3
Traceability
Modification of NIST SP 800-55 Rev 1 Measure 11
ORG 2 - Security assessments and reviews
Org 2.1
KPI ID
Org 2.1
Description
Average frequency of audit records review and analysis for
inappropriate activity
Input (Data Source)
•
•
•
•
Output (KPI)
NAR/TP
Unit of Measure
Per unit time (e.g., day, week, month, year) as applicable to
audit schedule
Leading / Lagging
Leading
Fail Criteria
NAR/TP less than or equal to the defined frequency
Impacted
Stakeholders
Primary
Owner/operator, service provider, system integrator, compliance
authority
Applicable Action
Investigate reason for audits not being performed on time and
take action to correct the situation
Relative Value
Failure to measure performance degrades ability to manage,
therefore, loss of audit system health will lead to degraded
security.
Maturity Model Relation
KPI provides some evidence of how well audit program is
functioning. Initially will provide some evidence that
implementation is improving. Once implemented with some
success, will provide an indication if things are slipping.
Comments
•
•
Traceability
5680
Defined audit procedure
Defined audit interval (AI)
Summation of applicable audit analysis reports (NAR)
Definition of evaluation period (e.g., 1 to 5 years for quarterly
audits, etc.) - (TP)
Strategic goal is to help ensure an environment of
comprehensive security and accountability for personnel,
facilities, and products.
Asset owner would define audit frequency (e.g., daily) and
reporting frequency (e.g., quarterly)
Modification of NIST SP 800-55 Rev 1 Measure 5
Org 2.2
KPI ID
Org 2.2
Description
Percentage of unclosed recommendations stemming from cyber
risk assessments and/or audits overdue
Input (Data Source)
•
•
•
•
•
Output (KPI)
100 * {TotR - ∑ (RC = yes) – ∑ [(RD + ATC) < CD]} / ∑ TotR
Total Recommendations (TotR)
Recommendation closed (RC) = yes or no
Recommendation date (RD)
Allowable time to close (ATC)
Current data (CD)
ISA-TR84.00.09-2023
- 292 -
KPI ID
Org 2.2
Unit of Measure
Percent
Leading / Lagging
Leading
Fail Criteria
>0%
Impacted
Stakeholders
Primary
Owner/operator, service provider, system integrator, compliance
authority
Applicable Action
Prioritized recommendations and secure additional recourses to
complete agreed to action items
Relative Value
Failure to manage recommendations in a timely manner leaves the
company exposed as well as sending a signal to employees and
contractors that safety and security are not important, further
exacerbating the situation.
Maturity Model Relation
As actual percentage decreases, it is an indication of increasing
maturity level.
Comments
•
•
•
Traceability
5681
Allowable time to close is often a function of estimated risk
vs corporate PHA criteria.
When first implementing, it may be more appropriate to use a
higher percentage for fail criteria and to lower it when relative
consistency is achieved to promote continuous improvement.
Asset owner would define audit frequency (e.g., monthly) and
reporting frequency (e.g., monthly)
Modification of NIST SP 800-55 Rev 1 Measure 16
ORG 2.3
KPI ID
Org 2.3
Description
Number of program changes without valid change authorization
(MOC)
Input (Data Source)
Listing of cyber changes
Approved MOC’s
Output (KPI)
Total cyber related changes – Cyber approved MOC
Unit of Measure
Numerical quantity
Leading / Lagging
Lagging
Fail Criteria
>0
Impacted
Stakeholders
Primary
Owner/operator, service provider, system integrator, compliance
authority
Applicable Action
Respond to and investigate all unauthorized changes, remediate
risks
Relative Value
Unauthorized changes can compromise the safety function.
Maturity Level Relation
A robust change management program that includes cyber security
provides some support for higher maturity levels.
Comments
Asset owner would define audit frequency ( e.g., Annually) and
reporting frequency (e.g., annually)
Traceability
CCM1 (TR84.09 annex second edition)
ISA-TR84.00.09-2023
5682
- 293 -
Org 2.4
KPI
Org 2.4
Description
Cyber PHA’s: Percent Overdue
Input (Data Source)
Total number of IACS related networks
Number of network cyber PHA’s that are required.
Number of networks with documented up to date cyber PHA’s
Output (KPI)
% KPI = 100 X (No. overdue / Total cyber PHA required)
Unit of Measure
Percent
Leading / Lagging
Leading
Pass/Fail Criteria
> 0% for initial reviews
> 0% for revalidations at 5-year intervals
Impacted
Stakeholders
Primary
Owner/operator, service provider, compliance authority
Applicable Action
Schedule, perform and document outstanding cyber PHA’s
Relative Value
•
•
Maturity Level Relation
A robust audit program that shows KPI’s are being met provides
some support for higher maturity levels.
Comments
•
•
Traceability
5683
Keep plant current with respect to understanding of risks
relative to company risk criteria
Maintain compliance with OSHA PSM
An alternate to KPI based on networks is to base it on well defined zones and conduits
Asset owner would define audit frequency (e.g., quarterly)
and reporting frequency (e.g., quarterly)
Modification of ISA TR84.00.04
Org 2.5
KPI ID
Org 2.5
Description
Output (KPI)
Number of cyber security related changes without valid change
authorization
• Total number of Cyber Security related changes (TSC).
• Approved MOC’s and changes (AMOC)
KPI = (AMOC/TC) *100
Unit of Measure
Percent
Leading / Lagging
Leading
< 100% for recommended monthly periodic reviews
Input (Data Source)
Fail Criteria
Impacted Stakeholders
Applicable Action
Relative Value
Owner/operator, service provider, system integrator, compliance
authority
• Assess the possible risk of un-approved MOCs.
• Remediate the immediate risk on a high priority basis
• Review and take appropriate action for all previously un approved MOCs
• Investigate all unauthorized changes and take steps to
improve work process
• Unauthorized changes can compromise the safety
function.
ISA-TR84.00.09-2023
- 294 -
Org 2.5
KPI ID
Maturity Model Relation
•
•
Possible risk to people, environment, and monetary loss
A high degree of compliance indicates a higher level of
organizational maturity relative to change management
Comments
•
This KPI measures the performance of the work process,
not the quality of the work performed.
Integration of Cyber Security Change Management within
the overall management of change work process would
allow this KPI to be broadened covering all changes that
are not replacement in kind.
Failure to document changes will result in misleading
KPI.
Sources of information include but are not limited to Plant
MOC Logs, configuration change logs, patch update logs,
reported threat incidents resulted due to un-approved
change.
Fail criteria represents a suggested value when highest
maturity level achieved. Prior to that, a company may
choose to use lower thresholds help manage continued
improvement by providing what currently would be a
stretch goal.
Asset owner would define audit frequency (e.g.,
quarterly) and reporting frequency (e.g., quarterly)
•
•
•
•
•
Traceability
5684
5685
NA
ORG 3 - Security of physical access
Org 3.1
KPI ID
Org 3.1
Description
Annual average number of physical security incidents allowing
unauthorized entry info facilities containing information system
Input (Data Source)
•
•
•
Number of unauthorized physical access incidents during a
defined time interval (NUPA)
Time interval (TI) where units = year
Number of interval data points (NIDP)
Output (KPI)
[∑(NUPA)] / (NDP*TI)
Unit of Measure
Whole number
Leading / Lagging
Lagging
Fail Criteria
<0
Impacted
Stakeholders
Primary
Owner/operator, service provider, system integrator, compliance
authority
Applicable Action
Initiate evaluation of incidents and act based on findings to
reduce likelihood of reoccurrence.
Relative Value
Reducing unauthorized access reduces both non-malicious as
well as malicious threats
Maturity Model Relation
As average decreases, it is
effectiveness and maturity level.
Comments
Asset owner would define audit frequency ( e.g., quarterly) and
reporting frequency (e.g., quarterly)
an
indication
of
increasing
ISA-TR84.00.09-2023
5686
5687
- 295 -
KPI ID
Org 3.1
Traceability
Modification of NIST SP 800-55 Rev 1 Measure 13
Org 4 – Supply Chain
Org 4.1
KPI ID
Org 4.1
Description
Output (KPI)
Percentage of system and service acquisition contracts that
include security requirements and/or specifications.
• Total # of contracts and specifications for hardware and
Software that has some inclusion of programmable devices
(TSPEC)
• Total # of contracts or specifications for hardware and
Software that has some inclusion of programmable devices
that specifically call out applicable ISA 62443 security
requirements. (Tno62443)
• KPI = (Tno62443/TSPEC) *100
Unit of Measure
Percent
Leading / Lagging
Fail Criteria
Leading
< 100 %
Impacted Stakeholders
Owner/operator, product supplier, system integrator
Applicable Action
Educate personnel responsible for contracts and specifications
that cybersecurity must be addressed when applicable.
Reduce likelihood of changes due to identification of security
deficiencies thereby lowering overall cost.
All functional disciplines having an understanding that
cybersecurity must be addressed along with other functional
requirements is an indication of higher organizational maturity
level
Input (Data Source)
Relative Value
Maturity Model Relation
Comments
•
•
Traceability
5688
Fail criteria represents a suggested value when highest
maturity level achieved. Prior to that, a company may choose
to use lower thresholds help manage continued improvement
by providing what currently would be a stretch goal.
Asset owner would define audit frequency (e.g., quarterly)
and reporting frequency (e.g., annually)
Modification of NIST SP 800-55 Rev 1 Measure 17
Org 4.2
KPI ID
ORG 4.2
Description
Output (KPI)
Percentage of IACS assets with SL-C compliance to ISA 62443-42.
• Total # of IACS assets (TASSET)
• Total # of IACS assets meeting SL-C ISA 62443-4-2
compliance (TSLC)
KPI = (TSLC/TASSET) *100
Unit of Measure
Percent
Leading / Lagging
Leading
< 100%
Input (Data Source)
Fail Criteria
ISA-TR84.00.09-2023
- 296 -
KPI ID
ORG 4.2
Impacted Stakeholders
Owner/operator, product supplier, system integrator
Applicable Action
•
•
Relative Value
•
•
•
Maturity Model Relation
•
•
Comments
•
•
•
Traceability
5689
5690
Evaluate assets for compliance
Implement compensating security measures to close gap as
needed
Provides asset owner insight as to the relative strength or
weakness of the assets they purchase.
Allows insight as to what compensating security measures
are needed to facilitate conformance with company risk
criteria
Provides baseline information for communication with
suppliers to improve their products to better meet the needs
of the asset owner
Understanding the security strengths and weaknesses
indicates a higher level of organizational maturity.
Encouraging the suppliers to improve their products based
on asset owner needs represents continuous improvement,
an indication of higher maturity level
Fail criteria represents a suggested value when highest
maturity level achieved. Prior to that, a company may choose
to use lower thresholds help manage continued improvement
by providing what currently would be a stretch goal.
Compliance may be determined by:
- Asset owner evaluation
- Third party assessor at the request of asset owner
- SL-C certification certificate provided by Supplier that
provides the necessary information allowing asset owner
to determine what, if any compensating security
measures are needed to close gap between SL-C and
asset owner SL-T
Asset owner would define audit frequency (e.g., annually)
and reporting frequency (e.g., annually)
NA
Configuration management
CM 1.1
KPI ID
CM 1.1
Description
Percentage of organization's hardware assets documented in their
asset inventory with the appropriate information:
• Unique Asset identifier
• Organizational responsibilities
• Manufacturer
• Model
• Hardware Serial number
• BIOS / Firmware version
• BIOS / Firmware Revision / patch levels
• Virtual environment Manufacturer
• Virtual environment version
• Operating System software Manufacturer
• Operating System Version number
• Operating System Revision / patch levels
ISA-TR84.00.09-2023
- 297 -
KPI ID
CM 1.1
• Application Software Version numbers
• Application Software Revision / patch levels
• History
Note: Fields above include the baseline ISA62443-2-1 inventory
data requirements plus additional recommendations
Input (Data Source)
•
•
Output (KPI)
(INV/TotHA) *100
Unit of Measure
Percent
Leading / Lagging
Leading
Fail Criteria
<100%
Impacted
Stakeholders
Primary
Owner/operator, service provider, compliance authority
Applicable Action
•
•
Update inventory with required information
Evaluate management of change work process to ensure that
new hardware assets are being added or updated within the
asset inventory
Relative Value
•
•
Support MOC with documentation of approved assets
Assist assurance that only hardware assets that have been
approved are connected to the network.
Assist identification of rogue devices connected to the
network
•
Maturity Model Relation
A well-managed asset inventory and associated work process
helps establish evidence of a higher maturity level.
Comments
•
•
Traceability
5691
5692
Total # of Hardware Asset (TotHA)
# Of Hardware Assets included in organization’s asset
inventory (INV) with required information
When first establishing this KPI, it may be useful to lower the
failure criteria and successively increase it as compliance is
improved.
Asset owner would define audit frequency (e.g., annually)
and reporting frequency (e.g., annually)
CIS Controls Measures and Metrics for Version 7 (Sub Control
1.5)
NET 1 - System segmentation
Net 1.1
KPI ID
Net 1.1
Description
Percentage of the organization's hardware assets that are
managed with specific access control lists
Input (Data Source)
•
•
Output (KPI)
(Access/TotHA) *100
Unit of Measure
Percent
Leading / Lagging
Leading
Fail Criteria
<100% for all zones that require access control list to manage
access
Total # of programmable Hardware Asset (TotHA)
# Of Hardware Assets using access control lists (Access)
ISA-TR84.00.09-2023
KPI ID
Impacted
Stakeholders
- 298 -
Net 1.1
Primary
Owner/operator, product supplier, service provider, system
integrator, compliance authority
•
Applicable Action
•
Relative Value
Evidence that Least Privilege is practiced. Minimizing the persons
who are allowed access to assets to those with a need helps
reduce the cyber-attack footprint.
Maturity Model Relation
Evidence of Least Privilege being practiced supporting security
level and security program level targets is an indication of higher
maturity levels.
Comments
•
•
•
5694
Field sensors and final elements are accounted for via the
tools used for access. This means that not all field devices
would be included in the denominator, but that all the tools
used for access would be.
When approved compensating security measures are used,
the denominator needs to have those devices removed and
documentation of approved security measures managed.
Asset owner would define audit frequency (e.g., quarterly)
and reporting frequency (e.g., quarterly)
CIS Controls Measures and Metrics for Version 7 (Sub Control
14.6)
Traceability
5693
Initiate management of change to implement access
management to include access control lists
If not possible, implement compensating security measures
NET 2 - Secure wireless access
Net 2.1
KPI ID
Net 2.1
Description
Percentage of wireless
authentication protocols
authentication for access
Input (Data Source)
•
•
Total # of Hardware Asset using Wireless Access
(TotWirelessHA)
# Of Hardware Assets using Wireless Access that uses
approved authentication protocols and mutual multi-factor
authentication
Output (KPI)
(Auth/TotWirelessHA) *100
Unit of Measure
Percent
Leading / Lagging
Leading
Fail Criteria
<100%
Impacted
Stakeholders
Applicable Action
Primary
applications that utilize approved
that requires mutual, multi-factor
Owner/operator, product supplier, service provider, system
integrator, compliance authority
•
•
•
Disconnect non-compliant applications from the IASC
network
Upgrade applications to be compliant if application must have
access to the IACS network
Perform root cause investigation of management of change
work process to determine why there was non-compliance
ISA-TR84.00.09-2023
5695
5696
- 299 -
KPI ID
Net 2.1
Relative Value
Assist verification that zone security level targets are in
compliance
Maturity Model Relation
Compliance provides evidence that is supportive of higher
maturity levels. Lack of compliance indicates a relatively low
maturity level.
Comments
•
•
Traceability
CIS Controls Measures and Metrics for Version 7 (Sub Control
15.8)
KPI not applicable if there are no wireless networks
Asset owner would define audit frequency (e.g., quarterly)
and reporting frequency (e.g., quarterly)
NET 3 - Secure remote access
Net 3.1
KPI ID
Net 3.1
Description
Percentage of remote access points used to gain unauthorized
access
Input (Data Source)
•
•
Output (KPI)
(NURAP/ TRAP) *100
Unit of Measure
Percent
Leading / Lagging
Lagging
Fail Criteria
Any value that does not support the SPR-T should be considered
a failure
Impacted
Stakeholders
Primary
Total number of remote access points (TRAP)
Number of remote access points used for unauthorized
access (NURAP)
Owner/operator, service provider, system integrator, compliance
authority
Applicable Action
Investigate both technical and organizational measures for
vulnerabilities and take corrective actions to mitigate those that
are identified.
Relative Value
Inferior performance would indicate facility at significant risk
Maturity Model Relation
Performance measure provides some support as to whether SPR T (function of technical SL and ML) is being achieved
Comments
•
•
•
•
Traceability
Measures whether access is restricted to individuals or
machines that are identifiable, known, credible, and
authorized.
This KPI requires the maintenance of up-to-date network
diagrams that identifies all remote access points.
To be most effective, KPI would require intrusion detection
system to monitor traffic traversing remote access points as
well as periodic analysis of audit logs associated with remote
access points.
Asset owner would define audit frequency (e.g., monthly) and
reporting frequency (e.g., quarterly)
Modification of NIST SP 800-55 Rev 1 Measure 3
ISA-TR84.00.09-2023
5697
5698
- 300 -
COMP 1 - Devices and media
COMP 1.1
KPI ID
COMP 1.1
Description
Percentage of mobile computers and devices that perform all
cryptographic
operations
using
FIPS
140-3
validated
cryptographic modules operating in approved modes of operation
Input (Data Source)
•
•
Output (KPI)
(NFIPS/TMD) *100
Unit of Measure
Percent
Leading / Lagging
Leading
Fail Criteria
Impacted
Stakeholders
Total number of mobile computers and devices (TMD)
Number of mobile computers and devices that are used to
communicate with the system that are fully compliant with
FIPS 140-3 (NFIPS)
Less than 100% (See comments)
Primary
Owner/operator, product supplier, service provider, system
integrator, compliance authority
Applicable Action
Strive for full compliance as part of a managed program
Relative Value
Helps to allocate resources to adequately protect electronic
communication traffic infrastructure.
Maturity Model Relation
•
Comments
•
•
Traceability
5699
FIPS Publication 140-3 is a U.S. government computer
security standard used to approve cryptographic modules
With respect to the use of the failure criteria, the actual trend
towards the goal is most important, therefore an asset owner
may wish to initially use a less conservative value and
steadily increase the expectation over time.
Asset owner would define audit frequency (e.g., quarterly)
and reporting frequency (e.g., annually)
Modification of NIST SP 800-55 Rev 1 Measure 18
COMP 1.2
KPI ID
COMP 1.2
Description
Percentage of devices that do not have the capability to prevent
unsecured access relative to implementation of ISA 62443 -3-3 or
ISA 62443-4-2
Input (Data Source)
•
•
Output (KPI)
(NDUA/TND) *100
Unit of Measure
Percent
Leading / Lagging
Leading
Fail Criteria
Less than 100% (See comments)
Impacted
Stakeholders
Primary
Total number of Devices (TND)
Number of devices that do not have the capability to prevent
unsecured access relative to implementation of ISA 62443 -33 or ISA 62443-4-2 (NDUA)
Owner/operator, product supplier, service provider, system
integrator, compliance authority
ISA-TR84.00.09-2023
- 301 -
KPI ID
COMP 1.2
Applicable Action
Strive for full compliance as part of a managed program
• Provides asset owner insight as to the relative strength or
weakness of the assets they purchase.
• Allows insight as to what compensating security measures
are needed to facilitate conformance with company risk
criteria.
• Provides baseline information for communication with
suppliers to improve their products to better meet the needs
of the asset owner.
• Understanding the security strengths and weaknesses
indicates a higher level of organizational maturity.
• Encouraging the suppliers to improve their products based
on asset owner needs represents continuous improvement,
an indication of higher maturity level.
Relative Value
Maturity Model Relation
•
Comments
•
•
Traceability
5700
This KPI can be used to look at categories of assets
separately, e.g., field sensors and final elements, controllers,
engineering workstations, servers, routers, switches,
firewalls, etc.
With respect to the use of the failure criteria, the actual trend
towards the goal is most important, therefore an asset owner
may wish to initially use a less conservative value and
steadily increase the expectation over time for a device
category of their choosing.
Asset owner would define audit frequency (e.g., annually)
and reporting frequency (e.g., annually)
Not applicable
COMP 1.3
KPI ID
COMP 1.3
Description
Percentage of devices that do not use certificates ( e.g., for
software or file transfer, software/firmware upgrades, authenticity
of product, etc.)
Input (Data Source)
•
•
Output (KPI)
(NDNC/TND) *100
Unit of Measure
Percent
Leading / Lagging
Leading
Fail Criteria
Less than 100% (See comments)
Impacted
Stakeholders
Applicable Action
Relative Value
Primary
Total number of Devices (TND)
Number of devices that do not use certificates (NDNC)
Owner/operator, product supplier, service provider, system
integrator, compliance authority
Strive for full compliance as part of a managed program
• Provides asset owner insight as to the relative strength or
weakness of the assets they purchase or their current
installed base.
• Allows insight as to what compensating security measures
are needed to facilitate conformance with company risk
criteria.
ISA-TR84.00.09-2023
KPI ID
- 302 -
Maturity Model Relation
COMP 1.3
• Provides baseline information for communication with
suppliers to improve their products to better meet the needs
of the asset owner.
• Understanding the security strengths and weaknesses
indicates a higher level of organizational maturity.
• Encouraging the suppliers to improve their products based
on asset owner needs represents continuous improvement,
an indication of higher maturity level.
Comments
•
•
•
Traceability
5701
5702
This KPI can be used to look at categories of assets
separately, e.g., field sensors and final elements, controllers,
engineering workstations, servers, routers, switches,
firewalls, etc.
With respect to the use of the failure criteria, the actual trend
towards the goal is most important, therefore an asset owner
may wish to initially use a less conservative value and
steadily increase the expectation over time for a device
category of their choosing.
Asset owner would define audit frequency (e.g., annually)
and reporting frequency (e.g., annually)
Not applicable
COMP 2 - Malware protection
COMP 2.1
KPI ID
COMP 2.1
Description
Percentage of the organization's hardware assets not utilizing
application whitelisting technology to block unauthorized
applications from executing on the system
Input (Data Source)
•
•
Asset inventory with total number of devices and their
associated operating and application software (TotHWSW)
Number of devices within asset inventory that do not use
whitelisting (NHW)
Output (KPI)
(NHW/TotHWSW) *100
Unit of Measure
Percent
Leading / Lagging
Leading
Fail Criteria
A value less than the percentage selected by the asset owner.
This value should be chosen as a function of risk determination.
During initial implementation, less conservative values may be
used and then made more challenging as performance improves.
Impacted
Stakeholders
Applicable Action
Primary
Owner/operator, service provider, product supplier, system
integrator, compliance authority
•
•
•
•
Develop an initial plan for implementation of whitelisting.
Use KPI to measure implementation performance.
Once implemented continue to monitor KPI to ensure no
slippage of performance.
Should performance degrade, develop an action plan to
correct the situation.
ISA-TR84.00.09-2023
- 303 -
KPI ID
COMP 2.1
Relative Value
Having application whitelisting technology on all assets
significantly reduces potential malware by ensuring that only
authorized software executes, and all unauthorized software is
blocked from executing on assets.
Maturity Model Relation
An improvement in the trend of the KPI over time is an indication
of continuous improvement which is a higher maturity level.
Performance that is bad or degrading is an indication of lower
maturity levels.
Comments
•
•
Modification of CIS Controls Measures and Metrics for Version 7
(Sub Control 2.7)
Traceability
5703
During initial implementation, it may be appropriate t o use a
less conservative failure criteria that is increased over a
scheduled implementation timeline.
Asset owner would define audit frequency (e.g., annually)
and reporting frequency (e.g., annually)
COMP 2.2
KPI ID
COMP 2.2
Description
Percentage of the organization's network boundaries configured
to require network-based Intrusion Detection Systems (IDS)
sensors to look for unusual attack mechanisms and detect
compromise of these systems at the boundary?
Input (Data Source)
•
•
Output (KPI)
(IDS/TotNB) *100
Unit of Measure
Percent
Leading / Lagging
Leading
Fail Criteria
>99%
Impacted
Stakeholders
Primary
Total # of Network Boundaries (TotNB)
# Of Network Boundaries that are configured with network based Intrusion Detection Systems (IDS) sensors - (IDS)
Owner/operator, service provider, system integrator, compliance
authority
Applicable Action
Implement configuration of network boundaries with networkbased Intrusion Detection Systems (IDS) sensors
Relative Value
Having network boundaries with network-based Intrusion
Detection Systems (IDS) sensors represents additional defense in
depth and a greater degree of security protectio n.
Maturity Model Relation
As actual percentage increases, it is an indication of increasing
technical security level capability
Comments
•
•
Initially, it may be appropriate to restrict this KPI to the
network boundaries that must help to protect zones wit h high
security level targets and extend to other zones as those
most critical zones are able to demonstrate a security
protection rating capability (SPR- C zone) that meets or
exceeds its SPR-T.
During initial implementation, it may be appropriate to use a
lower failure criterion that is increased over a scheduled
implementation timeline.
ISA-TR84.00.09-2023
5704
5705
- 304 -
KPI ID
COMP 2.2
• Asset owner would define audit frequency (e.g., annually)
and reporting frequency (e.g., annually)
Traceability
CIS Controls Measures and Metrics for Version 7 (Sub Control
12.6)
COMP 3 - Patch management
COMP 3.1
KPI ID
COMP 3.1
Description
Percentage of operating system vulnerabilities for which patches
have been applied or that have been otherwise mitigated
Input (Data Source)
•
•
Output (KPI)
(NP/TV) *100
Unit of Measure
Percent
Leading / Lagging
Leading
Fail Criteria
Less than value determined by asset owner. The goal would be
100%, however there will always be a time lag between
identification and patch implementation, therefore a value less
than 100% but as high as practical would be more useful once
the dynamics of the patch program are better known.
Impacted
Stakeholders
Primary
Owner/operator, product supplier, service provider, system
integrator, compliance authority
Applicable Action
Evaluate patch management program to determine reasons for
lack of patching. Upgrade program based upon evaluation of
risk.
Relative Value
The longer vulnerabilities exist, the more likely it is that a
compromise will occur
Maturity Model Relation
Performance measure provides some support as to whether SPR T (function of technical SL and ML) is being achieved
Comments
•
•
•
•
Traceability
5706
Total number of applicable vulnerabilities (TV)
Number of applicable vulnerabilities mitigated with successful
patch implemented (NP)
KPI intended to measure protection from malicious code at
appropriate locations within organization, monitor security
alerts and advisories, allowing appropriate response actions.
Asset owner may wish to base this KPI on the criticality
classification of vulnerabilities rather than all vulnerabilities.
As the dynamics of the patch program are better understood,
the asset owner can use increasingly higher fail criteria to
promote continuous improvement.
Asset owner would define audit frequency (e.g., weekly) and
reporting frequency (e.g., monthly).
Modification of NIST SP 800-55 Rev 1 Measure 19
COMP 3.2
KPI ID
Comp 3.2
Description
Percentage of high vulnerabilities identified and mitigated within
organization’s defined time periods after discovery
ISA-TR84.00.09-2023
- 305 -
KPI ID
Comp 3.2
Input (Data Source)
•
•
•
•
Output (KPI)
[1 - ∑ {(DATE:M – DATE:D) > ATTM}/TVD] * 100
Unit of Measure
Percent
Leading / Lagging
Leading
Fail Criteria
< 99%
Impacted
Stakeholders
Primary
Owner/operator, service provider, system integrator
Applicable Action
Mitigation should be triggered for any high vulnerability that is
overdue.
Relative Value
A decrease in vulnerabilities decreases the cyber footprint that is
subject to attack.
Maturity Model Relation
As actual percentage increases, it is an indication of increasing
maturity level.
Comments
•
•
•
Traceability
5707
5708
Date high vulnerability detected (DATE:D)
Date high vulnerability mitigated (DATE:M)
Allowed time to mitigate (ATTM)
Total high vulnerabilities detected (TVD)
Mitigation can be accomplished via a patch or by introduction
of suitable compensating countermeasure via MOC or
temporary MOC.
When first measuring, a lower percentage may be
appropriate. As performance improves, the percentage
should be increased, ultimately reaching 100% for maturity
level 5 companies.
Asset owner would define audit frequency (e.g., quarterly)
and reporting frequency (e.g., quarterly).
Modification of NIST SP 800-55 Rev 1 Measure 2
DATA – Data protection
Data 1.1
KPI ID
Data 1.1
Description
Percentage of media that passes sanitization procedures testing
for high impact systems
Input (Data Source)
•
•
Total count of assets permanently removed from service
during audit interval (TARS)
Count of assets not adequately sanitized prior to disposal
(NNS)
Output (KPI)
100*(TARS – NNS)/TARS
Unit of Measure
Percent
Leading / Lagging
Leading
Fail Criteria
Less than 100%
Impacted
Stakeholders
Applicable Action
Primary
Owner/operator, service provider, compliance authority
Evaluate work process to determine where breakdowns are
occurring and take remedial action to improve work process.
ISA-TR84.00.09-2023
- 306 -
KPI ID
Data 1.1
Relative Value
Equipment that is taken out of service (e.g., discarded following
repair, decommissioning) is a source of information for potential
threat agents if configuration and data are not proper sanitized
prior to disposal.
Maturity Model Relation
Provides some evidence to support ML achieved in practice.
Comments
•
•
Traceability
5709
5710
Lack of sanitization test records is needed to determine
count of assets not adequately sanitized prior to disposal.
Asset owner would define audit frequency (e.g., quarterly)
and reporting frequency (e.g., annually).
Modification of NIST SP 800-55 Rev 1 Measure 12
USER 1 - Identification and authentication
User 1.1
KPI ID
User 1.1
Description
Percentage of the organization's hardware assets not configured
to utilize multi-factor authentication and encrypted channels
•
•
Input (Data Source)
Total # of Hardware Asset (TotHA)
# Of Hardware Assets using MFA and Encrypted
Channels (MFA)
Output (KPI)
(MFA/TotHA) *100
Unit of Measure
Percent
Leading / Lagging
Leading
Fail Criteria
<100%
Impacted
Stakeholders
Primary
Owner/operator, product supplier, service provider, system
integrator, compliance authority
Applicable Action
Configure MFA on hardware assets
Relative Value
Hardware Assets not configured with MFA represent
vulnerability that can be exploited by cyber threat agents
Maturity Model Relation
As actual percentage increases, it is an indication of increasing
maturity level
Comments
•
Traceability
a
Initially, it may be appropriate to restrict this KPI to the
assets in the zones with the highest SL-T and extend to
assets in other zones as those most critical zones are able to
demonstrate a security protection rating capability (SPR - C
zone) that meets or exceeds its SPR-T.
• During initial implementation, it may be appropriate to use a
lower failure criterion that is increased over a scheduled
implementation timeline.
• Asset owner would define audit frequency (e.g., monthly) and
reporting frequency (e.g., quarterly)
CIS Controls Measures and Metrics for Version 7 (Sub Control
4.5)
ISA-TR84.00.09-2023
5711
- 307 -
User 1.2
KPI
User 1.2
Description
Percentage of IACS user access attempts that fail authentication
verification.
Input (Data Source)
Successful IACS user access attempts & Unsuccessful IACS user
attempts.
Output (KPI)
Unsuccessful access attempts divided by total access attempts
Unit of Measure
Percent
Leading / Lagging
Lagging
Fail Criteria
> 5%
Impacted
Stakeholders
Primary
Owner/operator, service provider
Applicable Action
Respond to and investigate high rates of failed IACS user
access attempts, remediate risks, and recover normal operation.
Relative Value
A high rate of failed IACS user access attempts can indicate a
situation where unauthorized users are attempting to access to
the IACS in a manner that can compromise safety/security
functions.
Maturity Level Relation
•
Comments
•
Traceability
5712
5713
Successful & unsuccessful IACS user access attempts
should be automatically recorded by IACS.
Asset owner would define audit frequency (e.g., weekly) and
reporting frequency (e.g., monthly)
CCM2 (TR84.09 annex) second edition
USER 2 - Authorization and access control
User 2.1
KPI ID
User 2.1
Description
Percentage of individuals screened before being granted access
to organizational information and information systems
Input (Data Source)
•
•
Total number of persons who have approved access to
organizational information and the IACS and its associated
network (TAA)
Number of persons with access who have been adequately
screened (TAS)
Output (KPI)
(TAS/TAA) *100
Unit of Measure
Percent
Leading / Lagging
Leading
Fail Criteria
Less than 100%
Impacted
Stakeholders
Applicable Action
Primary
Owner/operator, product supplier, service provider, system
integrator, compliance authority
Consider removing access rights until screening is completed.
Perform screening immediately and either continue allowing
access or remove access rights immediately depending upon the
screening results.
ISA-TR84.00.09-2023
- 308 -
KPI ID
User 2.1
Relative Value
Reduces the insider threat likelihood
Maturity Model Relation
Provides some evidence to support ML achieved in practice.
Comments
•
•
Traceability
5714
KPI is intended to help ensure that individuals occupying
positions of responsibility within organizations are trustworthy
and meet established security criteria for those positions.
Asset owner would define audit frequency (e.g., quarterly)
and reporting frequency (e.g., annually).
Modification of NIST SP 800-55 Rev 1 Measure 15
User 2.2
KPI ID
User 2.2
Description
Percentage of the organization's system administrators not
required to use a dedicated machine for all administrative tasks or
tasks requiring elevated access
Input (Data Source)
•
•
Output (KPI)
(NSANR/TotSA) *100
Unit of Measure
Percent
Leading / Lagging
Leading
Fail Criteria
A value less than the percentage selected by the asset owner.
During initial implementation, less conservative values may be
used and then made more challenging as performance improves
ultimately with a failure criterion of greater than zero percent.
Impacted
Stakeholders
Primary
Applicable Action
Total Number of System Administrators (TotSA)
Number of system administrators not required to use a
dedicated machine for all administrative tasks or tasks
requiring elevated access (NSANR)
Owner/operator, service provider, compliance authority
•
•
•
Develop an initial plan for implementation of work process
and infrastructure that ensures system administrators are
required to use a dedicated machine for all administrative
tasks or tasks requiring elevated access.
Use KPI to measure implementation and sustained
performance.
When an audit reveals failed criteria, take immediate action
to remedy situation.
Relative Value
Machines dedicated to purpose provide a smaller cyber footprint
to attack.
Maturity Model Relation
Compliance with KPI indicates some support for higher maturity
levels
Comments
•
•
During initial implementation, it may be appropriate to use a
less conservative failure criteria that is made more stringent
over a scheduled implementation timeline.
Intended to help ensure administrators use a dedicated
machine for all administrative tasks or tasks requiring
administrative access. This machine should be segmented
from the organization's primary network and not be allowed
ISA-TR84.00.09-2023
5715
- 309 -
KPI ID
User 2.2
Internet access. This machine should not be used for reading
e-mail, composing documents, or browsing the Internet.
• Asset owner would define audit frequency (e.g., quarterly)
and reporting frequency (e.g., annually)
Traceability
Modification of CIS Controls Measures and Metrics for Version 7
(Sub Control 4.6)
User 2.3
KPI ID
User 2.3
Description
Percentage of the organization's user accounts that do not have
an expiration date that is monitored and enforced
Input (Data Source)
•
•
Output (KPI)
(NUA/tutu) *100
Unit of Measure
Percent
Leading / Lagging
Leading
Fail Criteria
A value less than the percentage selected by the asset owner.
During initial implementation, less conservative values may be
used and then made more challenging as performance improves
ultimately with a failure criterion of greater than zero percent.
Impacted
Stakeholders
Primary
Applicable Action
Total # of the organization's user accounts (Toatoa)
Number of the organization's user accounts that do not have
an expiration date that is monitored and enforced (NUA)
Owner/operator, service provider, system integrator, compliance
authority
•
•
•
Develop an initial plan for implementation of work process
and infrastructure to effectively manage user accounts.
Use KPI to measure implementation and sustained
performance.
When an audit reveals failed criteria, take immediate action
to remedy situation.
Relative Value
Effectively managed user accounts reduce the likelihood of
unauthorized access.
Maturity Model Relation
Compliance with KPI indicates some support for higher maturity
levels
Comments
•
•
•
Traceability
During initial implementation, it may be appropriate to use a
less conservative failure criteria that is made more stringent
over a scheduled implementation timeline.
Intended to ensure that all accounts have an expiration date
that is monitored and enforced.
Asset owner would define audit frequency (e.g., quarterly)
and reporting frequency (e.g., annually)
Modification of CIS Controls Measures and Metrics for Vers ion 7
(Sub Control 16.10)
ISA-TR84.00.09-2023
5716
User 2.4
KPI ID
User 2.4
Description
Percentage of users with access to shared accounts for which a
small percentage is desired (e.g., engineering workstations,
servers, etc.)
Input (Data Source)
Total number of persons with access to the system in question
(TNSQ)
Number of users with access to shared accounts for system in
question (NUSQ)
Output (KPI)
(NUSQ/TNSQ) *100
Unit of Measure
Percent
Leading / Lagging
Leading
Fail Criteria
Greater than zero
Impacted
Stakeholders
5717
- 310 -
Primary
Owner/operator, service provider, system integrator, compliance
authority
Applicable Action
Eliminate the shared account(s) and replace with individual
accounts
Relative Value
Minimizing the number of shared accounts reduces the cyberattack surface
Maturity Model Relation
Performance measure provides some support as to whether SPR T (function of technical SL and ML) is being achieved
Comments
•
•
Traceability
Modification of NIST SP 800-55 Rev 1 Measure 9
Each account type should have its own KPI
Asset owner would define audit frequency (e.g., monthly) and
reporting frequency (e.g., monthly)
User 2.5
KPI ID
USER 2.5
Description
Percentage of the organization's systems, where multi -factor
authentication is not supported (such as local administrator, root,
or service accounts) or not used, even if supported, the accounts
use passwords that are unique to that system
Input (Data Source)
•
•
Total # of System Accounts not using multi-factor
authentication (TotSA)
# Of System Accounts not using MFA having unique
passwords to that system (UP)
Output (KPI)
(UP/TotSA) *100
Unit of Measure
Percent
Leading / Lagging
Leading
Fail Criteria
<99%
Impacted
Stakeholders
Applicable Action
Primary
Owner/operator, product supplier, service provider, system
integrator
Implement unique password on System Accounts not using multifactor authentication
ISA-TR84.00.09-2023
- 311 -
KPI ID
USER 2.5
Relative Value
Not having a unique password on system accounts not protected
with MFA represent a vulnerability that can be exploited by cyber
threat agents
Maturity Model Relation
As actual percentage increases, it is an indication of increasing
maturity level
Comments
•
•
CIS Controls Measures and Metrics for Version 7 (Sub Control
4.4)
Traceability
5718
5719
To account for applications such as general board/HMI
operator accounts, the KPI equation or the failure criteria
may need to be adjusted.
Asset owner would define audit frequency (e.g., quarterly)
and reporting frequency (e.g., quarterly)
Event and incident management
EVT 1.1
KPI ID
EVT 1.1
Description
Percentage of industrial automated control system that have
conducted annual contingency plan testing
Input (Data Source)
•
•
Output (KPI)
(NFCSTF / ToTCST) *100
Unit of Measure
Percent
Leading / Lagging
Leading
Fail Criteria
This should be a high percentage that is defined by the asset
owner.
Impacted
Stakeholders
Primary
Total number of control system(s) tests (ToTCST)
Number of failures (NFCSTF)
Owner/operator, service provider, system integrator, compliance
authority
Applicable Action
Evaluate test results and taken corrective actions based upon
lessons learned.
Relative Value
Satisfactory performance helps to mitigate the potential damage
should a security attack occur.
Maturity Model Relation
Performance measure provides some support as to whether SPR T (function of technical SL and ML) is being achieved
Comments
•
•
•
Traceability
To perform the test requires that a contingency plan to test
against has been developed and personnel trained in its
execution.
Fail criteria should be made more stringent as performance
improves to promote continuous improvement
Asset owner would define audit frequency (e.g., annually)
and reporting frequency (e.g., annually)
Modification of NIST SP 800-55 Rev 1 Measure 8
ISA-TR84.00.09-2023
5720
- 312 -
EVT 1.2
KPI ID
EVT 1.2
Description
Percentage of incidents reported within required timeframe per
applicable incident category
Input (Data Source)
•
•
Output (KPI)
(NRIOT/TRI) *100
Unit of Measure
Percent
Leading / Lagging
Lagging
Fail Criteria
This should be a high percentage that is defined by the asset
owner.
Impacted
Stakeholders
Primary
Owner/operator, product supplier, service provider, system
integrator, compliance authority
Applicable Action
Evaluate work process for reasons why performance is subpar
and take corrective action.
Relative Value
Satisfactory performance helps to disseminate lessons learned,
thus mitigating the potential for future security attacks to be
successful.
Maturity Model Relation
Provides some evidence to support ML achieved in practice.
Comments
•
•
•
Traceability
5721
Total number of reported incidents (TRI)
Number of reported incidents reported on time (NRIOT)
It is recommended that incident categories be developed
(e.g., unauthorized access, denial of service, malicious code,
improper usage, scans/probes/attempted access, etc.) and
KPI value reported for each.
Fail criteria should be made more stringent as performance
improves to promote continuous improvement
Asset owner would define audit frequency (e.g., monthly) and
reporting frequency (e.g., annually)
Modification of NIST SP 800-55 Rev 1 Measure 10
EVT 1.3
KPI ID
EVT 1.3
Description
Mean time to detected cyber intrusion
Input (Data Source)
•
•
•
Date and time of cyber intrusion first occurred for each
intrusion (DTIFO)
Date and time of cyber intrusion detection for each intrusion
(DTCI)
Number of cyber intrusions (NCI)
Output (KPI)
∑ i to N (DTCI i - DTIFO i )/N
Unit of Measure
Unit of time
Leading / Lagging
Lagging
Fail Criteria
As low as practical
Impacted
Stakeholders
Applicable Action
Primary
Owner/operator, service provider, compliance authority
Measurement provides direct feedback as to the capability being
achieved with respect to security capabilities.
ISA-TR84.00.09-2023
- 313 -
KPI ID
EVT 1.3
Relative Value
Knowledge of capability being achieved, or lack thereof helps to
prioritize actions to improve critical performance objectives.
Maturity Model Relation
Improving mean time to detect cyber intrusions is an indication of
continuous improvement which is a higher maturity level.
Performance that is bad or degrading is an indication of lower
maturity levels.
Comments
•
•
Traceability
5722
Not Applicable
EVT 1.4
KPI ID
EVT 1.4
Description
Mean time to recover from a cyber intrusion
Input (Data Source)
•
•
•
Date and time of cyber intrusion detection for each intrusion
(DTCI)
Date and time of cyber intrusion resolved, and operation
restored to normal (DTCIR)
Number of cyber intrusions (NCI)
Output (KPI)
∑ i to N (DTCIR i -DTCI i )/N
Unit of Measure
Unit of time
Leading / Lagging
Lagging
Fail Criteria
As low as practical
Impacted
Stakeholders
Primary
Owner/operator, service provider, compliance authority
Applicable Action
Measurement provides direct feedback as to the capability being
achieved for the business response plan.
Relative Value
Knowledge of capability being achieved, or lack thereof helps to
prioritize actions to improve critical performance objectives.
Maturity Model Relation
Improving restoration times is an indication of continuous
improvement which is a higher maturity level. Performance that is
bad or degrading is an indication of lower maturity levels.
Comments
•
•
Traceability
5723
Determination of date/time of initial intrusion typically
requires an incident investigation
Asset owner would define audit frequency (e.g., annually)
and reporting frequency (e.g., annually)
During initial implementation, it may be appropriate to use a
higher failure criterion that is decreased over time as
improvements are made.
Asset owner would define audit frequency (e.g., annually)
and reporting frequency (e.g., annually)
Not Applicable
EVT 1.5
KPI ID
EVT 1.5
Description
Cyber risk from penetration
Input (Data Source)
•
Total Number of recorded Cybersecurity Events (Tevt)
ISA-TR84.00.09-2023
KPI ID
- 314 -
EVT 1.5
•
Output (KPI)
Cybersecurity Events which penetrated the IACS network
resulting in an incident (Tinc)
KPI = (Tinc/Tevt) *100
Unit of Measure
Percent
Leading / Lagging
Lagging
Fail Criteria
Risk based fail criteria
• Low Consequence penetrations: > 1% value fail criteria
(adjust based upon maturity level)
• High Consequence penetrations leading to significant
incident: > 0%
Owner/operator, product supplier, service provider, system
integrator, compliance authority
• Perform root cause investigation for more significant
incidents and consider means to reduce risk
• Periodically evaluate events in aggregate to determine ways
to reduce overall cybersecurity risk
Evaluation and understanding the type and measure of successful
penetrations can lead to better predictions and future reductions
of loss due to penetrations
Performance measurements that show a high degree of success
where SPR-A meets or exceeds SPR-T indicates a higher level of
organizational maturity whereas a low level of success indicates
company risk criteria is not being met.
• It may be useful to document the types of cyber incidents as
a function of consequences
• KPI will improve its value as company improves its
recognition of cyber events and penetrations.
• Asset owner would define audit frequency (e.g., annually)
and reporting frequency (e.g., annually)
NA
Impacted Stakeholders
Applicable Action
Relative Value
Maturity Model Relation
Comments
Traceability
5724
5725
AVAIL 1 - System availability and intended functionality
AVAIL 1.1
KPI ID
AVAIL 1.1
Description
Percentage of the organization's software applications or
operating systems not currently supported by the software's
vendor
Input (Data Source)
•
•
Output (KPI)
(NSW/TotSW) *100
Unit of Measure
Percent
Leading / Lagging
Leading
Fail Criteria
A value less than the percentage selected by the asset owner.
During initial implementation, less conservative values may be
used and then made more challenging as performance improves
ultimately with a failure criterion of greater than zero percent.
Total software asset inventory (TotSW)
Number of software assets that are not currently supported
by the software's vendor (NSW)
ISA-TR84.00.09-2023
KPI ID
Impacted
Stakeholders
- 315 -
AVAIL 1.1
Primary
Owner/operator, service provider, system integrator, compliance
authority
Applicable Action
•
•
Relative Value
The ability to patch software to eliminate newly identified
vulnerabilities helps to maintain a reduced attack surface
Maturity Model Relation
Systems operating with software that no longer are supported by
the vendor is indicative of a declining maturity level.
Comments
•
•
•
Intended to help obsolescence planning to ensure that only
software applications or operating systems currently
supported by the software's vendor are utilized in the system.
Unsupported software should be tagged as unsupported in
the inventory system.
During initial implementation, it may be appropriate to use a
less conservative failure criteria that is made more stringent
over a scheduled implementation timeline.
Asset owner would define audit frequency (e.g., quarterly)
and reporting frequency (e.g., annually)
Modification of CIS Controls Measures and Metrics for Version 7
(Sub Control 2.2)
Traceability
5726
Develop plan to upgrade software.
Implement upgraded or replacement software that is
supported.
AVAIL 1.2
KPI ID
AVAIL 1.2
Description
Percent Devices SL-C < Device SL-T
Input (Data Source)
•
•
Output (KPI)
(NHA/THA) *100
Unit of Measure
Percent
Leading / Lagging
Leading
Fail Criteria
This should be a low value defined by the asset owner based
upon the dynamic changes as to availability of suitably secure
equipment from manufacturers as well as the asset owner’s
obsolescence plan.
Impacted
Stakeholders
Primary
Applicable Action
Owner/operator, product supplier, service provider, system
integrator
•
•
Relative Value
•
•
Maturity Model Relation
Total number of hardware assets (THA)
Number of hardware assets that do not satisfy SL-T for the
zone it is located (NHA)
Lobby manufacturers to provide equipment capable of
meeting their security needs
Use as an input to obsolescence plan
Inferior performance would indicate facility at potentially
greater risk
Gives attention to where the need for compensating security
measures may be warranted
Performance measure provides some support as to whether SPR T (function of technical SL and ML) is being achieved
ISA-TR84.00.09-2023
- 316 -
KPI ID
AVAIL 1.2
Comments
•
•
Traceability
5727
When first implementing, it may be more appropriate to use a
lower percentage for fail criteria and to raise it to promote
continuous improvement.
Asset owner would define audit frequency (e.g., annually)
and reporting frequency (e.g., annually)
Not applicable
AVAIL 1.3
KPI ID
AVAIL 1.3
Description
Percentage of vulnerabilities and associated safeguard security
measures successfully exploited by red teaming and pen testing
for selected system.
Input (Data Source)
•
•
Output (KPI)
(NVE/TNV) *100
Unit of Measure
Percentage
Leading / Lagging
Leading
Fail Criteria
Impacted
Stakeholders
Number of identified vulnerabilities (TNV)
Number of vulnerabilities exploited by red team (NVE)
Percentage greater than zero
Primary
Applicable Action
Owner/operator, product supplier, service provider, system
integrator, compliance authority.
•
•
All vulnerabilities exploited should be reviewed and actions
taken to mitigate the potential for future mitigation. Action
items should be prioritized based upon risk.
Where products are found deficient, should contact product
supplier to assist risk reduction going forward.
Relative Value
Failure to test can lead to an increasing number of vulnerabilities,
waste of resources and enable an attacker greater opportunity to
exploit the system that may result in the most severe
consequences. (Trisis/Triton/Hatman proved that some attackers
will go directly after safety systems and their safeguards.
Maturity Model Relation
Red teaming provides insight to actual security protection rating
potentially achieved irrespective of what compliance to 62443
requirements would indicate from a capability perspective.
Comments
•
•
•
Identified vulnerability input from cyber risk assessments and
/ or Cyber vulnerability assessment
Additional information that provides value includes:
o Number of discovered vulnerabilities tested or attacked
(should be captured per safeguard, per System, per field
device, per site/location/cabinet/panel etc.)
o Number of Systems, Devices, locations, safeguards,
mitigations etc. tested (should be broken down to that
level for sub KPI reporting visibility)
o Number of vulnerabilities unable to successfully exploit,
either indirectly or directly
Metric used to prioritize which vulnerability mitigations should
be prioritized and implemented first based on which can be
exploited.
ISA-TR84.00.09-2023
5728
5729
- 317 -
KPI ID
AVAIL 1.3
• Asset owner would define audit frequency (e.g., initial prior to
start-up, bi-annually) and reporting frequency (e.g., upon test
completion).
Traceability
Not applicable
AVAIL 2 - Backup / restore / archive
AVAIL 2.1
KPI ID
AVAIL 2.1
Description
Percentage of the organization's hardware assets configured to
back up system data automatically on a regular defined basis
Input (Data Source)
•
•
Output (KPI)
(BACKUP/TotHA) *100
Unit of Measure
Percent
Leading / Lagging
Leading
Fail Criteria
>99%
Impacted
Stakeholders
Primary
Owner/operator, service provider, compliance authority
Applicable Action
Require hardware assets to be configured to back up system
data automatically on a regular basis
Relative Value
Having regular backups allows recovery to a stable, recent state,
thus reducing the amount of downtime to make the system
operational after a cyber attack
Maturity Model Relation
As actual percentage increases, it is an indication of increasing
maturity level
Comments
•
•
Traceability
5730
Total # of Hardware Asset (TotHA)
# Of Hardware Assets whose system data is being backed up
on a regular basis (BACKUP)
KPI output equation or fail criteria may need to be adjusted
to account for manual backup work processes.
Asset owner would define audit frequency (e.g., quarterly)
and reporting frequency (e.g., quarterly)
CIS Controls Measures and Metrics for Version 7 (Sub Control
10.1)
AVAIL 2.2
KPI ID
AVAIL 2.2
Description
Percentage of OT hardware asset backups testing overdue
Input (Data Source)
•
•
•
•
Inventory of OT assets A 1 → A n
Backup/Restore test interval for each asset I 1 → I n
Last Backup/Restore test date for each OT asset LDA 1 →
LDA n
Current date (CD)
Output (KPI)
100 * ∑ {[(LDA 1 + I 1 ) < CD] → [(LDA n + I n ) < CD]} / ∑ (A 1 → A n )
Unit of Measure
Percent
Leading / Lagging
Leading
ISA-TR84.00.09-2023
- 318 -
KPI ID
AVAIL 2.2
Fail Criteria
>0%
Impacted
Stakeholders
Primary
Owner/operator, service provider, system integrator, compliance
authority
Applicable Action
Schedule backup/restore testing
Relative Value
Failure to have backups with the ability to restore service results
in greater harm due to increased downtime
Maturity Model Relation
As actual percentage decreases, it is an indication of increasing
maturity level.
Comments
•
•
Traceability
5731
5732
When first implementing, it may be more appropriate to use a
higher percentage for fail criteria and to lower it when relative
consistency is achieved to promote continuous improvement.
Asset owner would define audit frequency (e.g., monthly) and
reporting frequency (e.g., quarterly)
Modification of CIS
ISA-TR84.00.09-2023
- 319 -
5733
Annex M - Job Cyber Assessment
5734
5735
5736
5737
5738
To identify cyber hazards related to activities performed by employees and contractors, one means
to assess those procedures is to perform a job cyber assessment (JCA). This is like the concept
of job safety assessments (JSA) used within industry. The JCA can help to identify appropriate
measures to eliminate, reduce the likelihood of, or mitigate the consequences of cyber hazards
that may exist prior to engaging in such work practices.
5739
5740
5741
The development of a JCA is recommended for all specific procedural activities that that have the
potential to compromise cybersecurity of the IACS network and process controls. Figure M1 below
provides the basic steps for performing a JCA.
Select the job / task to be
analyzed
Start
Select team members
Break the job / task down
into a sequence of steps
Identify potential cyber
hazards for step
Identify and document
existing countermeasures
Yes
Adequate?
No
Document
recommendation(s)
All steps complete?
No
Yes
5742
5743
5744
5745
5746
5747
5748
5749
5750
Document assessment
and develop action plan
as applicable
Figure M1
JCA Procedure
JCA work process best practices include:
• Management commitment is key to an effective JCA process
– Observe and participate in JCA meetings during site security visits
– Conducting audits of the JCA process during site security visits
– Holding employees and supervisors accountable for JCAs
• Involving the right people in the JCA process
ISA-TR84.00.09-2023
5751
5752
5753
5754
5755
5756
5757
5758
5759
5760
5761
5762
5763
5764
5765
5766
5767
5768
5769
5770
5771
5772
5773
5774
5775
5776
5777
5778
5779
5780
5781
5782
5783
5784
5785
5786
5787
5788
5789
5790
- 320 -
–
•
•
•
•
•
•
•
•
•
•
JCA process will be more thorough and more easily implemented if the persons
impacted have "ownership" of the physical/cyber security and safety
procedures/policies
– Purpose of the JCA is to make sure that the employees & contractors who will be
conducting a task understand the potential hazards and how to mitigate them
Participant engagement
– Make sure all participants are active and engaged in the process, not just going
through the motions
Preparation
– Set up a clear process for determining what jobs require a JCA at your company and
allow sufficient time for the JCA process to be conduc ted prior to beginning the job.
Pre-Job Inspections
– Conduct a pre-job review to ensure that all hazard mitigation plans identified during
the JCA process have been implemented & understood by personnel
JCA documentation
– JCA worksheet should include the following information:
• List of job / task steps
• List of related cyber hazards associated with each step
• List hazard mitigation plan for each step as applicable
• Assign accountability for mitigation
• Document who participated and have supervisor s ign off on form
• Include a cyber hazard checklist to help your employees identify risks
Provide JCA specific training impacted employees and/or contractors
Handling change
– Watch for a changing cyber landscape that might require changes to the JCA
– Determine when it is appropriate to stop a job due to changing conditions or
awareness of new cyber hazards to go back and revise the JCA.
Post-job evaluation following implementation
– Conduct a post-job evaluation to determine actual performance versus assumptions
– Revise the JCA if appropriate for the next time that job is performed
JCA review, auditing & metrics
– Include regular audits of the JCA process
– Incorporate automated metrics to measure effectiveness
– Evaluate metrics to look for means to improve
Develop an action plan to address any deficiencies
Determine corrective actions and develop a plan for completing them whenever breakdowns
occur
–
These action items should be tracked to ensure completion
The worksheet template form provided below can assist the performance of a JCA.
ISA-TR84.00.09-2023
5791
- 321 -
Job Cyber Assessment Worksheet Form
5792
5793
Table M1
Job Cyber Assessment Worksheet
Job Title:
5794
Analysis By:
Reviewed By:
Approved By:
Date:
Date:
Date:
Sequence of Steps
Potential Cyber Incidents / Hazards
Preventative Measures
ISA-TR84.00.09-2023
5795
- 322 -
Annex N – Security of Field Devices and Their Interface within the IACS
5796
Introduction
5797
5798
5799
5800
This annex describes cybersecurity, safety standards and recommendations for field networks and
devices as well as their means of communication with other equipment within the IACS . The annex
also provides some information relating to compensating security measures employed to mitigate
identified shortcomings.
5801
5802
5803
5804
5805
5806
At the time of this writing, neither cybersecurity nor process safety standards have adequately
addressed the cybersecurity of the field devices and their communication with other levels of the
IACS and various networks. Field devices consisting of sensors and final elements are part of level
0 and 1 as shown in the figure 1.0 reference model introduced in section 1, Scope. For control and
protection, they would typically communicate with level 2, however, with the use of asset
management systems and Ethernet ports, they may communicate with higher levels.
5807
5808
5809
5810
5811
5812
IEC62443-4-2 states that when the cybersecurity requirements cannot be met, which is generally
the case for legacy devices and device networks as well as many systems currently being sold,
compensating security measures and controls are required. However, meaningful guidance
dealing with these is not currently readily available. This annex intends to provide some guidance
to enable compensating security measures and future technology improvements that will provide
efficient, effective compensating countermeasure.
5813
5814
5815
5816
5817
The reference model shown in figure 1.0 illustrates a structure for software functions in a control
system. For this document, the Level 0, 1, and 2 functions in the reference model typically occur
within the 1 millisecond to 1 minute time frame. Safety functions typically involve a few milliseconds
to a few seconds’ time. Because of the brief time frames, operator-based compensating controls
are generally not effective.
5818
5819
5820
5821
5822
5823
Most of the devices and networks covered in this annex are physically located i n the field (process
connected). In addition, configuration/hand-held devices are also considered. Some are located
inside fenced-in facilities with managed physical access, while others are in public areas, with or
without physical barriers. Both physical and logical access security as described in Chapter 4, the
Access Management section and chapter 13, Access Control sub -sections are key factors to
consider in the cybersecurity analysis of these devices and networks.
5824
5825
5826
5827
5828
5829
5830
5831
5832
5833
5834
5835
5836
Until new systems are developed and made available with the needed capabilities, the
authentication and authorization of people physically working on systems in the field will continue
to be procedural. The Center for Chemical Process Safety (CCPS) ranks procedural effectiveness
as the least effective of methods to address process hazards and reduce risk with inherent, passive,
and active risk reduction strategies being more effective. For example, procedural security
measures may work in some locations, however not everywhere and the effecti veness is limited at
best. People assigned to work on these devices should have authorized physical and/or A&A for
remote access. Whilst working on BPCS and SIS systems require a work order as well as a signed
work permit, there is no actual enforcement of these procedural controls at the device due to the
device’s inability to enforce logical access controls. As a result, there is no authentication
authorization from a cyber security perspective, making least privilege much more difficult to
accomplish relative to the field devices. This can have a deleterious impact on the system to which
it is connected.
5837
5838
5839
5840
5841
People using tools with access are the primary source of cyber threats. Persons with no malicious
intent represent an unintentional threat and have the h ighest likelihood of occurrence. These
unintentional threats can range from nuisance to potentially catastrophic. In many historical
incidents, high consequence incidents have occurred due to an accumulation of multiple seemingly
unrelated events over time combining to produce high a consequence outcome.
5842
5843
5844
Threat agents with malicious intent, either outsiders gaining remote access or insiders with
malicious intent, also represent a threat. Just as with unintentional threat, the consequences can
range from nuisance to potentially catastrophic. Whilst the likelihood of threat may be lower, when
- 323 -
ISA-TR84.00.09-2017
5845
5846
5847
malicious intent is involved, the consequences are generally higher on a relative basis due to the
targeted nature and intent of the attack. Both unintentional and intent ional threats have the
potential for and have caused high consequence events.
5848
Block diagrams
5849
5850
5851
5852
A series of block diagrams in this annex describe typical designs used for device communication,
configuration, and diagnostic monitoring. These block diagrams use the following block diagram
used by “safety protocols” as a basis. It shows the protection of data in transit for safety message
communications. The diagram shown in figure N1 is also the basis for IEC 61784-3 edition four.
5853
5854
5855
Figure N1: Standard Safety Communications Protocol Diagram
5856
5857
Since the above drawing is incomplete, it is also not appropriate for risk analysis purposes. The
following sections will discuss missing information.
5858
Current Status Including Deficiencies
5859
5860
5861
5862
5863
5864
Existing cyber security standards such as ISA 62443 h ave not to date adequately addressed the
cyber security vulnerabilities of field level devices and their lower -level networks (e.g.,
authentication, authorization, encryption, cyber security logging, etc.). At present, there is no
explicit coverage on how to address field devices and their low-level protocols should they not
fulfill the requirements of ISA 62443, even though ISA 61511 requires consideration of
cybersecurity.
5865
5866
5867
5868
This section gives a general outline of deficiencies in current protocols and devices and
summarizes protections provided and those missing for several network types . The block diagrams
concept helps to describe the designs used for device communication, configuration, and
diagnostic monitoring in the context of the pr otection being available or missing.
5869
General Protocol and device deficiencies
5870
5871
5872
5873
5874
Industry currently operates on an installed base of unsecured devices and device networks not
designed to address cyber security. Products including safety products have limited to no intrinsic
security protection built in for control system field devices, and most sensor -level protocols have
no inherent network security protection. Additionally, safety protocol standards have excluded
cybersecurity from their scope.
ISA-TR84.00.09-2023
- 324 -
5875
5876
5877
5878
Whether for process control or safety systems, field devices and their communication protocols do
not have any cybersecurity certification. Moreover, current products including safety certified
products are not currently capable of achieving cybersecurity certification based upon intrinsic
capabilities currently built into the product.
5879
5880
5881
5882
5883
5884
5885
5886
Although the concepts of least privilege apply and those working on field devices for BPCS, and
safety systems should have a work order and signed permits the devices used for direct acc ess
and their users have no login capability or authentication . Such access includes provisioning,
configuration, commissioning, and maintenance (including calibration and troubleshooting). In this
context, unrestricted means no authentication or authoriza tion is possible when accessing the
devices. The need for direct access results in unsecured backdoors for which changes are then
unrestricted through lack of authorization and authentication to enforce least privilege and to leave
a log of activity.
5887
5888
5889
5890
5891
5892
The portable tools used for access require metadata and executable files, generally obtained by
downloading them from the Internet. The processes for updating the tools are often not secure.
These tools can provide intermittent monitoring of device condition w hile leaving the device
unmonitored for considerable time durations. These tools have high error rates for single
parameter keyboard entry of configuration parameters. There is an expectation of increasing error
rates with these tools now available using c ellular technologies.
5893
5894
5895
5896
5897
5898
5899
Field devices can only be air gapped temporarily, as their purpose is to provide operational
information or perform operational actions. The only times when they would be air gapped would
be to configure, test, or maintain/repair. Initial access occurs when they are connected, i.e., not
air gapped. The majority of BPCS and SIS controllers support Authentication and Authorization .
Access to field devices for all reasons other than providing process data to a host system is only
possible through an unsecured backdoor with no authentication, authorization, encryption, cyber
security logging, etc.
5900
5901
5902
5903
Some protocols allow for authentication and authorization of devices. However, no protocols
currently offer authentication and authorization of u sers or authentication and authorization of
portable field tools used to access the devices. Additionally, the devices themselves may not be
capable of authentication and authorization.
5904
5905
5906
5907
5908
5909
5910
5911
One cyber threat from a high likelihood perspective involves personnel assigned to do work on
devices who have authorized physical access, access tools, and no malicious intent . These
workers generally have inadequate tools and procedures for managing their work and mistakes
are easy to make and hard to find because of inadequate infrastructure such as continuous device
monitoring. Malicious cyber threats exist but are less likely. Should they occur, however, the
consequences have a greater likelihood of being more catastrophic. The situation is further
exacerbated by the lack of cyber forensics, as it may not be possible to identify device anomalies
as being cyber-related prior to, or during, an actual attack or incident.
5912
Present Network Types and Protections
5913
5914
This section summarizes several network types and the protections provided or missing. The
numeric references given with each protocol type references specific sub clauses in Annex H.
5915
Listed in Table N1 below are the various protocol types:
Annex H Ref.
Network Type
Example
H2.3
Safety bus
Profisafe
H2.4
Legacy digital P-P
HART, fieldbus, Profibus
Legacy digital routable
HART IP, Profinet, FF HSE
Analog
4-20 mA
H2.5
- 325 -
H2.6
Wireless edge networks
See Table H3
OPC UA
5.0
Proposed (OPC UA with extensions)
5916
5917
ISA-TR84.00.09-2017
Wireless HART, ISA100
Table N1: Table of Protocol Types
Listed in Table N2 are the potential protections available:
Protection
Notes/Description
Data in transit – up to gateway
Data in transit – end to end
Devices - including application software in the
device
transmitters, valves, controllers, logic solvers
etc.
Networks
Physical/mac
firewalls
address,
switches, routers,
Application software
Authentication & Authorization
Including users/roles
Other
5918
Table N2: Table of Protections Available
5919
5920
5921
5922
5923
Table N3 summarizes the protections available as listed in Table H2 for each protocol type given
in Table N1. Most networks offer options for diagnostics and monitoring. However, the strength of
diagnostics and monitoring technology varies widely, and users have the option of not
implementing or not using the monitoring options. Therefore, monitoring is not included in Table
H3, however, monitoring is discussed in the text for the various options.
Data in
transit
up
to
gateway
Data
in
transit
end
to
end
Devices
Networks
Application
software
A&A
including
users
H2.3
Excellent
Excellent
None
None
None
Only
for
safety
application
software
H2.4
moderate
None
None
None
None
None
H2.5
None
None
None
None
None
None
H2.6
Good
None
None
Good
None
None
OPC UA
Good
Note 1
None
None
Partial
Needs work
ISA-TR84.00.09-2023
H5.0 (Note 3)
5924
5925
5926
5927
5928
5929
5930
5931
5932
5933
5934
5935
5936
5937
5938
5939
- 326 -
Good
Proposed
Proposed
Possible
(Note 2)
Proposed
Proposed
Table N3: Table of Protections for Protocol Types
Notes:
1. OPC UA is often used end-to-end (no gateway). Where this is the case, the protection
does exist end-to-end. If a gateway is present, data integrity protection is often broken.
Data integrity protection with a gateway will require special application work by a system
integrator. OPC UA might become available as a safety proto col. OPC, shown as an
improvement over legacy digital networks can be a basis for a long -term solution. OPC
UA contains many optional building blocks, which makes the technology difficult to
classify.
2. Network protection is possible for a dedicated network. Where multiple protocols share a
network, a single protocol cannot protect the shared network. Network protection is
possible using a common network management system. Common network management is
exceedingly rare in automation systems.
3. In progress are proposals to provide secure tools and procedures to go with new network
technologies (Clause 5). Most legacy networks do not offer secure tools and procedures
(see Clause 4).
5940
Safety Protocols
5941
5942
5943
The diagram in figure N2 below provides a more complete view of a safety protocol including typical
unsecured access. Use of incomplete diagrams such as Figure N1 will lead to incorrect conclusions
about the safety and cybersecurity of devices and networks.
5944
5945
Figure N2: Safety Communications Protocol Diagram with Portable Tool
5946
5947
5948
5949
Although the above diagram shows more of the connections involved in a safety protocol, it does
not show connections to the system. Risk analysis should include a full diagram of connections to
an endpoint (if an endpoint exists). Analysis of the entire system should include the “as installed”
system architecture, inventories, and connections.
- 327 -
ISA-TR84.00.09-2017
5950
5951
5952
5953
Safety protocols in common use and defined by current safety protocol standards provide no
cybersecurity protection at a device, network, or system level. The safety protocols only protect
integrity of data in transit. It should be noted that the data may be corrupted before it is sent over
the protected link.
5954
Legacy Digital Including Routable Legacy Digital Protocols
5955
5956
5957
5958
5959
5960
5961
5962
5963
5964
5965
5966
5967
Non-routable legacy digital protocols
Most digital protocols offer some protection for data in transit. Safety protocols and some wireless
protocols provide the best protection. Other digital protocols offer checksum or parity checks.
Some digital protocols also offer time stamps for detection of stale dat a. Rank ordering the different
protocol approaches from highest to lowest data integrity would be:
-
Safety systems (best data integrity protection)
Wireless with encryption and time stamps
CRC checksums and time stamps without encryption (wired)
Parity check with no time stamps (wired or wireless)
Analog (no data integrity protection)
Many legacy protocols do not offer encryption or other tools to protect devices and networks
because of the limitations of legacy technology – in particular, the lack of encryption chips in legacy
devices and slow data transmission rates of legacy protocols.
5968
5969
Figure N3: Standard Digital Communications Protocol
5970
5971
The picture in figure N3 is like the safety protocol minus the safety layer contained in the
application layer. The picture represents the devices and not different zones .
5972
5973
5974
5975
5976
Many legacy protocols are point-to-point protocols designed to serve a single application layer.
These protocols generally have a communication stack designed to transmit only messages that
are a part of the protocol. These protocols do not easily, (if at all) transmit rogue messages that
can be used for security threats, although as stated before, data may be corrupted before it is sent
over the protected link.
5977
5978
5979
Routable legacy digital protocols
The application layer of many of these legacy protocols have been transformed so that they will
communicate over a standard commercial off-the-shelf (COTS) Ethernet – IP communication stack.
ISA-TR84.00.09-2023
- 328 -
5980
5981
5982
The use of a routable protocol with a COTS stack can provide speed, cost, and ease of use benefits
without any effect on the application layer or functionality of the protocol. The block diagram shown
in figure N3 is not changed by use of routable protocols such as Ethernet.
5983
5984
5985
5986
The use of a COTS Ethernet stack enables many additional vulnerabilities that these legacy
protocols are not designed to address. The stack can easily transmit messages (such as malware)
with no relation to the intended application layer. The routable nature of these networks allows
messages to propagate to targets other than the intended recipient.
5987
5988
5989
5990
Encryption of messages will have no effect on the expanded vulnerabilities of these networks
unless other measures protect the integrity of devices sending and receiving data, improving
management of network integrity. This expanded vulnerability applies to both control and safety
networks.
5991
5992
Analog and wired HART
Analog signals offer no protection for data in transit.
5993
Figure N4: HART Communications Protocol
5994
5995
5996
5997
The system can detect input device failures through the analog signal using NAMUR NE 43. This
failure detection mechanism is used, but often a proprietary version of this detection method is
used which is not interoperable. This failure detection method does not detect all device errors,
failures in analog input signal transmission, and does not work for analog outputs.
5998
5999
It is necessary to configure the NE43 failure detection in the device and in the host before enabling
the failure detection diagnostic. It will not work correctly otherwise.
6000
6001
6002
The HART digital signal provides more extensive coverage of diagnostic information than provided
through NE43 for analog inputs and can provide error or failure detection in analog out puts. The
claimed diagnostic coverage for HART devices is only available through HART digital signals.
6003
6004
6005
Some HART devices have a safety certification for use in safety applications. However, neither the
analog or HART signal transmission of signals is safet y certified, nor is either signal path certified
as secure.
- 329 -
6006
6007
6008
6009
6010
ISA-TR84.00.09-2017
Wireless Protocols
Wireless networks generally provide network and security management for the wireless networks
and provide authentication and authorization for wireless devices that join to the network. This
management system does not extend to authentication and authorization of users. An example
wireless communication protocol is shown in figure N 5
6011
6012
Figure N5: Wireless communications protocol
6013
Safety protocols can operate over a wireless network for improved end -to-end integrity protection.
6014
6015
6016
6017
Wireless networks do not provide any management of field tools unless the tools are authenticated
to join the wireless network. Most field tool connections are direct (not via the wireless network)
and not authenticated. Prior to access, there is no logical authentication and authorization for
actual users of the tools in wireless networks.
6018
6019
Certification
6020
6021
6022
6023
6024
Certification is a significant source of cost and schedule delay in production of new products. It
can also be a significant benefit to service providers, system integrato rs, and end users of products.
Certification is a well-established industry concept that is highly desirable when it produces useful
and meaningful information to the users referenced above and, in some cases, are mandated by
regulations.
6025
6026
6027
6028
6029
6030
6031
6032
6033
Certification provides assurance that a device or a protocol conforms to, or complies, with a
standard or a set of performance requirements. All certifications are of narrow focus and only
provide assurance concerning certain aspects covered by the relevan t standard. It is important
that the certification information clearly describe what the device can do and what it cannot do
relative to the benchmark used for certification. It is especially important to describe what the asset
owner must do to take credit for any specific device capabilities. There are gaps in both standards
and certifications for field devices with respect to cyber security technology ( e.g., no standard or
requirement for authentication and authorization in the certified device) and the protocols used for
communication to/from the field devices.
ISA-TR84.00.09-2023
- 330 -
6034
Types of certifications
6035
6036
Although many types of certifications exist, they are separate and not organized as a complete set.
Overlaps may exist and they certainly leave gaps. Common types of certif ications are:
6037
1) Protocols
6038
6039
6040
Protocols for compliance to safety or cybersecurity conformance. Some protocols have safety
conformance certification. Where protocols have a specific physical layer, the physical layer can
also receive certification for electrical properties like intrinsic safety.
6041
6042
The most common certification associated with protocols are certifications that assure
conformance to interoperability requirements.
6043
2) Devices
6044
Examples of device certifications include:
6045
6046
6047
6048
6049
6050
•
•
•
•
6051
6052
Professional certification tests the knowledge of disciplines, e.g., process safety, cybersecurity,
automation engineer, electrical engineer, etc.
6053
4) Systems
6054
6055
6056
Some protocols have system interoperability certification or host requirements. Systems normally
require customization to fit an application so that the system and application certification are not
separate.
6057
6058
6059
6060
Different certifications supplied by different certification agencies often use different standards.
The different standards are sometimes specific to a country. This is the case with electrical safety
standards. However helpful the different certifications, generic product certifications are
incomplete.
6061
6062
Safety certifications and cybersecurity certifications are separate and currently do not link together,
even though ISA 61511 now includes cybersecurity as a requirement.
6063
Certification supplements and effects
6064
6065
6066
6067
6068
Safety certification has improved the quality of devices in the market by ensuring better
development processes, ensuring devices have diagnostics coverage, and provide a safety manual
for the product. They can also lead to a false sense of security, as the product does not make the
application inherently safer or more secure and often requires implementation of management
systems on the part of the end user to ensure that certified capabilities are effective.
6069
6070
6071
The safety manual informs the end user users what they should and should not do with the product
in safety applications to accomplish the level of safety expected but does not address cyber
security.
6072
6073
6074
6075
6076
6077
The certification agency has leverage to enforce th e supplier certification through reviews,
inspections, and audits. However, no entity other than the asset owner has authority to enforce
the provisions in the safety manual. Integration, compliance with the safety manual, operation and
maintenance activities of a device installed as part of an entire system are activities that extend
far beyond a device certification at purchase. The asset owner is accountable for the installed
system as well as its operation and maintenance.
6078
6079
There is certification for safety systems personnel who perform work for safety systems; however,
this certification covers their knowledge and capability. In some, but not all cases, the certification
electrical safety such as for intrins ic safety
susceptibility to emissions of electromagnetic interference
interoperability certification
safety certifications that assure diagnostic coverage and development methodology
3) Professionals
- 331 -
ISA-TR84.00.09-2017
6080
6081
6082
6083
6084
provider requires evidence of experience to better measure competency. Training by itself is simply
an enabler on the path to competency and does not represent competency by itself. Even in the
case of experienced personnel, it does not guarantee adequate application as their actions are
subject to company expectations managed by persons who may or may not have bought into the
expected requirements.
6085
6086
6087
At the time of writing, field device products do not have a security manual, a security certification,
or anything equivalent. The limitations of safety protocol c ertification are that they protect data in
transit but do not provide safety or security .
6088
6089
6090
6091
BPCS and SIS are systems of systems and consist of many individual devices, networks, and
software. The complete system encapsulating all tools, devices, networks, and boundaries
generally require compensating security measures to ensure what is reasonable for safety and
security. Certification simply does not exist for whole systems in operation as that is impractical.
6092
Summary of Certifications
6093
6094
6095
6096
6097
The diagrams provided in section H2 of this annex detail the lack of security methods such as
authentication and authorization specified in ISA/IEC 62443 -4-2. The certification process is
incomplete and costly. Currently, compliance certification for these devices and networks do not
exist. As a result, it is up to system integrators and end users to provide compensating security
measures as detailed in section H4 to achieve the required risk management.
6098
Mitigation and Management (Compensating Security measures)
6099
6100
6101
6102
6103
ISA-TR63082 (TR108)-2020 Intelligent Device Management covers some of the material in this
section. Part 1, Concepts and Terminology is published and part 2, Normative Requirements is in
development. The work processes and procedures described here can partially compensat e for
lack of inherent security measures. New security tools and technology outlined in section H5 can
supplement (not replace) these security measures for new devices and systems.
6104
Isolation or “Air Gapping”
6105
6106
6107
6108
Providing isolation or air gapping does not prov ide an inherently secure countermeasure. These
devices require digital access for configuration, commissioning, and maintenance tasks. This
access violates the principle of isolation. Maximizing and managing isolation does provide
improved security by reducing the time of exposure, but it does not provide inherent security.
6109
6110
6111
6112
When isolation is considered, all connections whether temporary or permanent should be identified.
In other words, a full topology showing all possible routes to a device or network shou ld be included
in the analysis of security. If most of the connections are secure and some are not, then the overall
security level capability is no better than the weakest link.
6113
6114
6115
6116
6117
One of the most difficult cyber security issues is managing the use of tempo rary connections from
portable tools. Portable tools required for many commissioning and maintenance procedures have
not currently been designed for security, e.g., in accordance with ISA 62443-4-2. These devices
use system network access for download and archival of configuration information and use Internet
access for download of metadata and executable files used for communication with devices.
6118
6119
6120
6121
The work processes and procedures available with these tools often involve single parameter entry
of configuration information. This single parameter entry technique is the most error prone of
methods for use with smart devices. In addition, not designed with security in mind, these portable
tools usually have no support for security.
6122
6123
6124
6125
6126
6127
More accurate and reliable means of configuration management is available through a permanent
host system connection that provides reliable upload, archival, and download of device
configuration as well as continuous monitoring of device condition. The permanent connection
does not remove the need for temporary access by portable tools for some field support activities,
but it makes these field activities more limited in scope, easier to manage, and can reduce the
cyber security gap if the configuration management is done securely.
ISA-TR84.00.09-2023
- 332 -
6128
Continuous Monitoring
6129
6130
6131
6132
Basic requirements of security management include Authentication, Authorization, and Accounting
(AAA). Accounting is the same as monitoring. One of the first steps in an active compensating
security measures program is to implement monitoring to identify unauthorized changes. This can
partially compensate for lack of support for authentication and authorization in current products.
6133
6134
6135
6136
6137
All types of intelligent devices and communication protocols support continuous monitoring.
Oftentimes, continuous monitoring implementation only monitors process measurement
parameters. However, monitoring of configuration and diagnostic information should be included
as well. This information provides the potential for valuable mitigation against unauthorized
configuration changes.
6138
6139
6140
6141
6142
Monitoring that is not continuous or does not include monitoring of configuration and diagnostic
information for devices and networks leads to a higher likelihood of undetected errors in field
devices and networks. Lack of a continuous monitoring program reduces the effectiveness of a
key compensating control path for cyber security and makes the claimed diagnostics in field
devices mostly ineffective.
6143
6144
Monitoring is more than a technical capability for diagnostics. Monitoring program requirements
include:
6145
6146
6147
6148
6149
6150
•
•
•
•
Configuration of diagnostics to generate proper notifications ( e.g., alerts or alarms)
Configuration of notifications for direction to responsible parties with proper priority
Monitoring software that can collect and present notificat ions with some analysis that can
provide an indication of potential cyber impacts
Assignment of personnel to use the tools and take appropriate corrective action within an
appropriate time frame.
6151
6152
6153
6154
Device diagnostics can be communicated for action where devi ces can be modified/corrected in
minimal time (hours instead of months or years) with the correct priority. Continuous monitoring of
all device configuration parameters and diagnostic conditions can significantly improve device
integrity.
6155
6156
6157
6158
6159
Condition monitoring is not simply the reporting of internal diagnostics of device condition(s).
Device diagnostics can also detect and report problems or conditions external to the device such
as freezing conditions, plugging or abnormal flow conditions, or process proble ms. Condition
monitoring is effectively a predictive maintenance program that can help determine/justify
maintenance intervals especially if the condition history is documented and periodically analyzed.
6160
6161
6162
6163
6164
In addition, monitoring in a host system can detect problems with signal transmission or detection
of drift or deviation from expected measurements. Detection of certain problems can only occur on
the receiving end whereas detection of many other problems can only occur on the sending end.
Good diagnostic coverage depends on a monitoring system that detects and reports problems on
both ends.
6165
Configuration management
6166
6167
6168
6169
6170
6171
System level configuration management tools are available that support generation of a
configuration database, validation of configuration, download to field devices, archiving of field
changes, and detection of field errors. These system level tools often used with portable field tools
offer single parameter data entry and are generally error prone. The field tools are necessar y for
commissioning and maintenance work, but their use for configuration presents a challenge for
maintaining integrity of configuration.
6172
6173
6174
6175
Use of templates in conjunction with configuration tools aids removal of some of the random
choices associated with custom parameters. It is possible to eliminate potential random choices
with standardized choices supported by expert analysis. Audits of field configuration integrity can
also use templates to improve audit effectiveness.
- 333 -
ISA-TR84.00.09-2017
6176
6177
6178
6179
6180
Some practices have allowed technician level configuration with a portable tool, using only the
information on an instrument procurement data sheet such as an ISA S20 form. Configuration of
intelligent devices with data sheet forms not designed to support configuration is discouraged.
Engineering review and assessment of templates can provide a complete and accurate
configuration. This is an engineering level activity.
6181
6182
Configuration management includes physical configuration (including use of option jumpers) as
well as software and firmware downloads.
6183
6184
6185
Establishment and maintenance of a configuration management system is vital to safety and
cybersecurity. Implementation of the recommended tools will provide improved results, less errors,
along with improved efficiency and ease of use.
6186
Administrative procedures
6187
6188
Administrative policies and procedures are an essential part of effective application of
compensating security measures. The following apply:
6189
6190
6191
6192
6193
6194
6195
6196
6197
•
•
•
•
•
Access control by policies and procedures that substitute for missing system level tools.
Administrative procedures are currently the only means of access control with present
technology for field devices.
Continuous and intermittent monitoring policies and procedures to supplement the tools
that are available.
Configuration management that includes archiving. This is an engineering level activity.
Audit procedures to ensure compliance with associated procedures.
Management of metadata file downloads and installation is a system level, administration
activity that uses secure download and installati on processes.
6198
6199
6200
The administrative procedures should provide for clearly defined roles, responsibilities, and
accountability. Policies, procedures, and training should assure proper administration of security
and safety related activities.
6201
Long Term Solutions
6202
6203
6204
6205
6206
6207
6208
6209
6210
6211
6212
The need for continuous monitoring, configuration management and administrative procedures will
continue if the intelligent devices are in use. Implementation of existing well -defined technology
measures can make the work processes and procedures more ef fective and easier to use and
administer. These technologies include network and security management, and configuration
management enhancements. Higher speeds provided by new physical layers, such as the
advanced physical layer (Ethernet APL) could facilit ate these technologies. Legacy field protocol
physical layers are stable and perform their design function, but they are slow, not designed for
secure operation and lack of security support makes them vulnerable. Legacy field protocols
typically do not have encryption capability and the protocols do not support certificates,
authentication, and authorization. Higher speed can make many security measures perform fast
and easy where the slow speeds of old physical layers are a barrier to implementing security .
6213
Network Management
6214
6215
6216
6217
6218
ISA100.20 covers the concepts and terminology necessary for network management. The
technology described in this document are general in nature and is applicable to any
communication network with connected devices. The proper applicati on of network management
technology greatly simplifies the administration of field device networks. ISA100.15 covers
additional information on this topic.
6219
6220
6221
6222
Management of network access for devices and users through authentication and authorization
(A&A) represents a good practice. A&A is a control defining those with allowed access and their
rights. Network communication and security management systems for field devices will be
necessary to leverage A&A in the defense against unauthorized changes.
6223
ISA-TR84.00.09-2023
- 334 -
6224
6225
Figure N6: Managed Secure Protocol
6226
6227
6228
6229
The diagram above shows a management function incorporated into the “system .” It is not practical
to have an independent management function for each network. Rather, a common management
policy centrally managed and distributed to support local policy enforcement. ISA100.20 describes
models and terminology for this management architecture.
6230
6231
6232
6233
Devices, portable tools, applications, and users should establish unique identification and role based authorization. The IACS should provide the A&A by a security, network node manager.
Security (key distribution, time distribution, encryption, etc.) would be a normal accessory for the
security node in addition to the A&A function.
6234
6235
6236
6237
6238
Network node management can also provide for priority and schedule for communications when
used with technologies such as time sensitive networks. Time sensitive networks allow for
application optimization by scheduling application algorithms as well as communication. The
technology provides for significant improvement in performance over conventional unmanaged (or
poorly managed) networks.
6239
6240
6241
6242
6243
It is a poor practice allowing anonymous access for portable tools to devices connected to the
IACS. This practice is discouraged. Providing provisions for shop (off -line) access to devices
disconnected from the IACS is appropriate, coupled with procedures to manage risks associated
with off-line access. A job cyber assessment can help to ensure the procedure is adequate to
manage the potential risks.
6244
The continuous IACS connection should provide monitoring for changes and diagnostic errors.
6245
6246
6247
6248
6249
6250
Whitelisting all Network Management entities fully leverages the benefits. Whitelisting is the
practice of explicitly allowing authenticated entities (users, devices, or applications) authori zation
for a list of privileges or authorities, services, or networks to ensure only those approved can
execute or access data and network resources. The whitelist can also manage priority and
schedule across networks. Network management with comprehensive whitelisting is one of the
most effective methods for enforcing cybersecurity.
6251
Configuration Management
6252
Configuration management should be easier and more secure.
- 335 -
6253
ISA-TR84.00.09-2017
Files in device / plug and play
6254
6255
6256
6257
6258
The metadata files such as electronic device description lan guage (EDDL) and device templates
can be stored in devices. These files allow a host system to connect to a device and establish
communication without any need for obtaining and installing files from an external source (over
the Internet). The files are thus available when needed and where needed without administrative
support services, improving security.
6259
6260
6261
6262
The inclusion of these files inside a device could speed and simplify download procedures. Only a
minimal amount of data would require a download after adoption of a template made the device
setup correct for an application type. Reduction of variability in device configuration caused by
lack of understanding or simple error is a benefit.
6263
6264
6265
Some of the more complex support functions might be too large for i nclusion in devices and require
external source, but assurance of basic functions is still possible, reducing the need for Internet
downloads.
6266
Communication between portable field tools and IACS over field network
6267
6268
6269
6270
6271
Some communication between portable field tools and host systems is necessary for network
management and security purposes. Additional communication functions could support features
like field tool request for device download. Communication between host system and field tool
could increase productivity and ease of use by field personnel while improving accuracy of their
work.
6272
Internal (Device) Security / Perimeter Security
6273
History and perimeter security
6274
6275
6276
6277
6278
6279
6280
6281
6282
6283
6284
6285
6286
6287
Device security and protocol security have not existed for most of the history of smart devices to
date. Security deficiencies have been described in this annex. The deficiencies have existed
because of a lack of computing and memory resources in low power field devices, and a lack of
support for security by communication protocols and systems used w ith these devices. The history
of this goes back to an era when device security was not a subject of public awareness. The lack
of protocol and device security has led to reliance on perimeter security and manual procedures
to address security concerns. The perimeter security concept is problematic as the procedures are
difficult to enforce and not very effective.
Perimeter security can and should be enhanced. Supply chain vulnerabilities are always a
challenge and continuous improvement is a worthy goal for perimeter security. Perimeter defenses
cannot be achieved by simple appliances. Secure procedures are necessary to support and
enforce the capabilities provided by the devices.
A picture showing a model of threats, perimeter defenses and internal securit y is shown in figure
N7.
ISA-TR84.00.09-2023
- 336 -
Cybersecurity
Fantasy
Cybersecurity
Reality
External
Threats
IT Threats
IACS Zone
Supply Chain &
Cloud Service
Threats
IACS Zone
“Trusted” & Safe
Secure
Perimeter
6288
6289
Internal Malicious
& Non-malicious
Threats
Leaky Perimeter
Security
Figure N7 Internal and Perimeter Security
6290
Internal device and protocol security
6291
6292
6293
6294
6295
6296
6297
6298
6299
New communication protocols are now available that can support device level security. Devices
now have the computing resource availability to address device security in the future. The need to
rely solely on ineffective perimeter security no longer exists. Designs are now in progress to
provide protocol and device level support for internal security that is ind ependent from perimeter
security and can provide protection from internal threats. Improvements in device and protocol
security provide support for “zero trust” concepts.
New security capabilities in devices and protocols do not eliminate the need for good procedures,
but the new tools can make the procedures easier to enforce, easier to use, and more effective.
Procedures are still a primary control to mitigate internal threats.
6300
New and improved internal security tools
6301
6302
6303
6304
6305
6306
6307
6308
6309
6310
6311
6312
6313
6314
6315
6316
6317
A partial list of new tools includes the following:
• Devices and protocols will support authentication and authorization (A&A) for all tools
and users. Access without A&A will no longer be necessary and should not be allowed.
Protocols and host systems will have the capability to provide A&A when a device is
commissioned and, on a network, and devices will be able to provide A&A when they are
off network (such as for shop work).
• Change logging capability will be provided by protocols and host systems (on network)
and by devices (off network).
• Devices can be built with tamper resistant chips to prevent tampering and help to secure
firmware downloads.
• Devices can be built to include encryption support and protocols will use this support for
secure communication and for network management.
• Portable tools can be modified to use host support while on network. New procedures
and new tools can be developed in tandem for improved security, ease of use and
effectiveness.
• Implementation of supply chain security can improve device procurement, replacement,
and update procedures.
- 337 -
ISA-TR84.00.09-2017
6318
6319
6320
6321
Internal security at a device level can only be achieved by common industry efforts. The technology
for this effort is not simple. However, the goal is to make security easier to use, effective, and
mandatory. This technology is possible and practi cal but will take some time to fully develop and
implement.
6322
Summary
6323
6324
6325
6326
6327
6328
6329
Many security compromises occur during normal maintenance or other field activities where the
cybersecurity compromise is unintentional or accidental. This can lead to a host of potential
consequences from minor to severe. Security compromise also leads to an increased likelihood of
compromise by malicious outsiders. Many of the remaining problems are unrecognized due to a
lack of monitoring. Compromise through remote access is less common but can occur. Changes
to field devices such as firmware upgrades or configuration changes can have safety and
environmental significance whether the change is malicious or not.
6330
6331
To combat current deficiencies in support of cybersecurity with respect to dev ices, tools, and
networks, compensating security measures are necessary to counteract those deficiencies.
6332
6333
6334
6335
6336
New technology is available for use in new products that can improve the efficiency and
effectiveness of compensating security measures. The new technology should be more secure,
user friendly, less prone to human error, and enable higher efficiency. Even with new and improved
technology, there will likely be a need for compensating security measures to comply with tolerable
risk criteria. Active risk management will always be important regardless of technology employed.
6337
ISA-TR84.00.09-2023
- 338 -
6338
Bibliography
6339
6340
NOTE Draft bibliography items referenced in the body of the report refer to the draft copy current as of the date of
ISA-TR84.00.09.
6341
6342
[1]
6 CFR part 27: Chemical Facility Anti-Terrorism Standards (CFATS) Risk-Based Performance
Standard (RBPS) 8, Cyber
6343
[2]
OSHA 1910.119 subpart H, Process Safety Management of highly hazardous chemicals
6344
[3]
TSA Pipeline Security Guidelines, April 2011
6345
6346
[4]
IEC 61508, Functional safety of electrical/electronic/programmable electronic safety -related
systems
6347
[5]
IEC 61511, Functional safety – Safety instrumented systems for the process industry sector
6348
6349
[6]
DRAFT ANSI/ISA-84.91.03, Functional Safety: Process safety controls, alarms, and interlocks for
the Process Sector. Unpublished.
6350
[7]
ISA-TR84.00.03-2012, Mechanical Integrity of Safety Instrumented Systems (SIS).
6351
6352
[8]
ANSI/ISA-95.00.01-2010 (IEC 62264-1 Mod), Enterprise-Control System Integration - Part 1:
Models and Terminology.
6353
[9]
ANSI/ISA-18.2-2016, Management of Alarm Systems for the Process Industries.
6354
6355
[10] ANSI/ISA-ISA100.11a, Wireless Systems for Industrial Automation: Process Control and Related
Applications.
6356
[11] IEC TR63082-1; Intelligent device management - Part 1: Concepts and terminology.
6357
6358
[12] IEC 63082-2; Intelligent
Recommendations.
6359
6360
[13] ISA-TR63082-1 (TR108.1)-2020, Intelligent Device Management – Part 1: Concepts and
Terminology.
6361
6362
[14] ANSI/ISA-62443-1-1 (99.01.01)-2007, Security for Industrial Automation and Control Systems Part
1: Terminology, Concepts, and Models.
6363
6364
[15] DRAFT ISA-62443-1-3, Security for Industrial Automation and Control Systems Part 1-3: Cyber
Security System Conformance Metrics. Unpublished.
6365
6366
[16] DRAFT ISA-TR62443-1-4, Security for Industrial Automation and Control Systems Part 1-4:
Security Life Cycle and Use Cases. Unpublished.
6367
6368
[17] ANSI/ISA-62443-2-1 (99.02.01)-2009, Security for Industrial Automation and Control Systems Part
2-1: Establishing an Industrial Automation and Control Systems Security Program .
6369
6370
[18] DRAFT ISA-TR62443-2-2, Security for Industrial Automation and Control Systems Part 2-2: IACS
Security Protection Ratings. Unpublished.
6371
6372
[19] ANSI/ISA-TR62443-2-3-2015, Security for Industrial Automation and Control Systems Part 2-3:
Patch Management in the IACS Environment.
6373
6374
[20] ANSI/ISA-62443-2-4, Security for Industrial
Requirements for IACS Solution Providers.
6375
6376
[21] ANSI/ISA-62443-3-2, Security for industrial automation and control systems Part 3-2: Security risk
assessment for system design.
device
management
–
Part
Automation
2:
Normative
and
Control
Requirements
Systems
Part
and
2-4:
ISA-TR84.00.09-2023
- 339 -
6377
6378
[22] ANSI/ISA-62443-3-3 (99.03.03)-2013, Security for Industrial Automation and Control Systems Part
3-3: System Security Requirements and Security Levels.
6379
6380
[23] ANSI/ISA-62443-4-1, Security for Industrial Automation and Control Systems Part 4-1: Secure
product development lifecycle requirements.
6381
6382
[24] ANSI/ISA-62443-4-2, Security for Industrial Automation and Control Systems Part 4-2: Technical
Security Requirements for IACS Components.
6383
[25] IEC TR 63069, Security Environments and Security Risk Analysis, 2019.
6384
6385
[26] ISO/IEC 27002, Information technology — Security techniques — Code of practice for information
security controls.
6386
6387
[27] Thomas H. W & Day J.; Integrating Cyber security Risk Assessments into the Process Safety
Management Work Process, 11th Global Congress on Process Safety, April 2015.
6388
6389
[28] Bhojani, R.; IT Security and Functional Safety in Industrial Automation and Control Systems (IACS) ,
Automation Conference, Baden-Baden, Germany, 2010.
6390
6391
[29] NIST, Framework for Improving Critical Infrastructure Cyber security, Version 1.0, 12 February
2014.
6392
[30] NIST Special Publication 800-30, Guide for Conducting Risk Assessments
6393
6394
[31] NIST Special Publication 800-55 Revision1, Performance Measurement guide for Information
Security, July 2008.
6395
[32] NIST Special Publication 800-88 Revision 1, Guidelines for Media Sanitization, December 2014.
6396
[33] NIST Special Publication 800-94, Guide to Intrusion Detection and Prevention Systems (IDPS)
6397
6398
[34] NIST Special Publication 800-115, Technical Guide to Information Security Testing and
Assessment.
6399
6400
[35] NIST Special Publication 800-128, Guide for Security-Focused Configuration Management of
Information Systems
6401
[36] NIST Special Publication 800-153, Guidelines for Securing Wireless Local Area Networks (WLANs)
6402
[37] NIST Special Publication 800-207, Zero Trust Architecture, 2020.
6403
6404
[38] CCPS, Guidelines for Analyzing and Managing the Security Vulnerabilities of Fixed Chemical Sites ,
2003.
6405
[39] CCPS, Guidelines for Safe Automation of Chemical Processes , 2017.
6406
[40] CCPS, Guidelines for Developing Quantitative Safety Risk Criteria , 2009.
6407
[41] CCPS, Guidelines for Risk Based Process Safety, 2007.
6408
[42] API 780, Security Risk Assessment Methodology for the Petroleum and Petrochemical Industries
6409
[43] API 1164 Pipeline SCADA Security, September 2004
6410
6411
6412
[44] Hutchins, E.M; Cloppert, M. J.; and Rohan, A. M.; Intelligence-Driven Computer Network Defense
Informed by Analysis of Adversary Campaigns and Intrusion Kill Chains , Lockheed Martin
Corporation.
6413
[45] NAMUR NA 163, Security Risk Assessment of SIS
6414
[46] NAMUR NA 163 Checklist
ISA-TR84.00.09-2023
- 340 -
6415
[47] Center for Internet Security (CIS), CIS Security Metrics, v1.1.0, November 1, 2010.
6416
6417
[48] Center for Internet Security (CIS), A Measurement Companion to CIS Critical Security Controls ,
Version 6, October 2015.
6418
6419
[49] Palmer, D, Cyber security: The key lessons of the Triton malware cyberattack you need to learn ,
ZDNet.
6420
[50] IEC 61784-3 edition 4, Functional safety fieldbuses – General rules and profile definitions.
6421
[51] Bridges, W; Selection of Hazard Evaluation Techniques , 2008.
6422
[52] United Kingdom Health and Safety Executive (HSE), Guidance, ALARP “at a glance”
6423
6424
[53] Baybutt P.; An Asset-Based Approach for Industrial Cyber Security Vulnerability Analysis , Process
Safety Progress, p. 220, December 2003, Vol. 22, No. 4.
6425
6426
[54] Baybutt P.; Scenario Based Approach for Industrial Cyber Security Vulnerability Analysis , p. 220,
June 2004.
6427
6428
[55] Baybutt P.; Sneak Path Security Analysis for Industrial Cyber Security , Intech, p. 56, September
2004, Vol. 51, Issue 9.
6429
[56] Top 20 Secure Coding Practices
6430
[57] Health and Safety Executive, Risk Management: Expert Guidance, ALARP at a Glance
ISA-TR84.00.09-2023
6431
6432
6433
6434
6435
6436
6437
6438
6439
6440
6441
6442
6443
6444
6445
6446
6447
6448
6449
- 341 -
Developing and promulgating sound consensus standards, recommended practices, and technical
reports is one of ISA’s primary goals. To achieve this goal the Standards and Practices Department
relies on the technical expertise and efforts of volunteer committee members, chairmen and
reviewers.
ISA is an American National Standards Institute (ANSI) accredited organization . ISA administers
United States Technical Advisory Groups (USTAGs) and provides secretariat support for
International Electrotechnical Commission (IEC) and International Organization for
Standardization (ISO) committees that develop process measurement and control standards . To
obtain additional information on the Society’s standards program, please write:
ISA
Attn: Standards Department
67 Alexander Drive
P.O. Box 12277
Research Triangle Park, NC 27709
ISBN: 978-1-945541-49-0