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