Isa 62443 1 1 WD

IS TO BE USED SOLELY FOR THE PURPOSES OF FURTHER DEVELOPMENT OF ISA STANDARDS, AND MAY NOT
BE OFFERED FOR FURTHER REPRODUCTION OR FOR SALE. THE COPYRIGHT RESTS WITH ISA.
FOR USE AND REVIEW ONLY BY MEMBERS OF ISA99 AND APPROVED PARTIES:
This document includes working drafts of, or extracts from documents in the ISA-62443 series.
THIS COPY OF A FULL OR ABRIDGED ISA PUBLICATION IS TO BE USED SOLELY FOR THE PURPOSES OF
New versions will be generated periodically as individual documents are revised.

FURTHER DEVELOPMENT OF ISA STANDARDS. IT MAY NOT BE OFFERED FOR FURTHER REPRODUCTION
OR FOR SALE. THE COPYRIGHT RESTS WITH ISA.
Copyright by the International Society of Automaton. All rights reserved. Not for resale. Printed in
the United States of America. No part of this publication may be reproduced, stored in a retrieval
system, or transmitted, in any form or by any means (electronic, mechanical, photocopying, recording, or
otherwise), without the prior written permission of the Publisher.
ISA
67 Alexander Drive
P. O. Box 12277
Research Triangle Park, North Carolina 27709
USA
This page intentionally left blank
10
9
8
7
6
5
4
3
2
1
Draft 6, Edit 2
ISA-62443-1-1
September 2016
Models and Concepts
Security for industrial automation and control systems
ISA-62443-1-1, D6E2, September 2016 4 ISA99, WG03
11 ISA
12 Security for industrial automation and control systems
13 Models and Concepts
14 ISBN: -to-be-assigned-
15 Copyright 2016 by ISA. All rights reserved. Not for resale. Printed in the United States of America.
16
17 ISA
18 67 Alexander Drive
19 P. O. Box 12277
20 Research Triangle Park, NC 27709 USA
21
ISA99, WG03 5 ISA-624431-1, D6E2, September 2016
22 PREFACE
23 This preface, as well as all footnotes and annexes, is included for information purposes and is not
24 part of ISA-62443-1-1.
25 This document has been prepared as part of the service of ISA, the Internatio nal Society of
26 Automation, toward a goal of uniformity in the field of instrumentation. To be of real value, this
27 document should not be static but should be subject to periodic review. Toward this end, the Society
28 welcomes all comments and criticisms and asks that they be addressed to the Secretary, Standards
29 and Practices Board; ISA; 67 Alexander Drive; P. O. Box 12277; Research Triangle Park, NC
30 27709; Telephone (919) 549-8411; Fax (919) 549-8288; E-mail: standards@isa.org.
31 The ISA Standards and Practices Department is aware of the growing need for attention to the
32 metric system of units in general and the International System of Units (SI) in particular, in the
33 preparation of instrumentation standards. The Department is further aware of the benefits to U SA
34 users of ISA standards of incorporating suitable references to the SI (and the metric system) in

35 their business and professional dealings with other countries. Toward this end, this Department will
36 endeavor to introduce SI-acceptable metric units in all new and revised standards, recommended
37 practices and technical reports to the greatest extent possible. Standard for Use of the International
38 System of Units (SI): The Modern Metric System, published by the American Society for Testing
39 and Materials as IEEE/ASTM SI 10-97, and future revisions, will be the reference guide for
40 definitions, symbols, abbreviations, and conversion factors.
41 It is the policy of ISA to encourage and welcome the participation of all concerned individuals and
42 interests in the development of ISA standards, recommended practices and technical reports.
43 Participation in the ISA standards-making process by an individual in no way constitutes
44 endorsement by the employer of that individual, of ISA or of any of the standards, recommended
45 practices and technical reports that ISA develops.
46 CAUTION ISA adheres to the policy of the American National Standards Institute with
47 regard to patents. If ISA is informed of an existing patent that is required for use of the
48 standard, it will require the owner of the patent to either grant a royalty-free license for use
49 of the patent by users complying with the standard or a license on reasonable terms and
50 conditions that are free from unfair discrimination.
51 Even if ISA is unaware of any patent covering this Standard, the user is cautioned that
52 implementation of the standard may require use of techniques, processes or materials
53 covered by patent rights. ISA takes no position on the existence or validity of any patent
54 rights that may be involved in implementing the standard. ISA is not responsible for
55 identifying all patents that may require a license before implementation of the standard or
56 for investigating the validity or scope of any patents brought to its attention. The user should
57 carefully investigate relevant patents before using the standard for the users intended
58 application.
59 However, ISA asks that anyone reviewing this standard who is aware of any patents that may
60 impact implementation of the standard notify the ISA Standards and Practices Departme nt
61 of the patent and its owner.
62 Additionally, the use of this standard may involve hazardous materials, operations or
63 equipment. The standard cannot anticipate all possible applications or address all possible
64 safety issues associated with use in hazardous conditions. The user of this standard must
65 exercise sound professional judgment concerning its use and applicability under the users
66 particular circumstances. The user must also consider the applicability of any governmental
67 regulatory limitations and established safety and health practices before implementing this
68 standard.
69 The following people served as active members of ISA99, Working Group 03 during the preparation
70 of this document:
71
Name Company Contributor Reviewer

Bruce Billedeaux Maverick Technologies
Eric Cosman OIT Concepts LLC
Jim Gilsinn Kenexis
Tom Good Consultant
Dennis Holstein OPUS Consulting Group
Jean-Pierre Hauet
Vic Hammond Argon National Labs

Eric Hopp Rockwell Automation
Ben Jackman Emerson Process Management
Rick Kaun On Track Consulting
Pierre Kobes Siemens
Jeff Potter Emerson Process Management
Ragnar Schierholz ABB
Bradley Taylor UDC
Hal Thomas Exida
Rich Weekly Pro-Tech Power Sales Inc.
72
73 TABLE OF CONTENTS
74 PREFACE ............................................................................................................................... 5
75 FOREWORD ......................................................................................................................... 11
76 INTRODUCTION ................................................................................................................... 12
77 0 Scope ............................................................................................................................. 13
78 1 Normative references ..................................................................................................... 13
79 2 Terms, definitions, abbreviated terms, acronyms, and conventions ................................. 14
80 2.1 Terms and definitions ............................................................................................ 14
81 2.2 Abbreviated terms and acronyms ........................................................................... 26
82 2.3 Conventions .......................................................................................................... 26
83 3 The ISA62443 series ..................................................................................................... 28

84 3.1 Purpose ................................................................................................................. 28
85 3.2 Approach ............................................................................................................... 28
86 3.3 Structure ............................................................................................................... 29
87 3.4 Organization .......................................................................................................... 29
88 3.5 Applying the Standards ......................................................................................... 30
89 3.6 Metrics .................................................................................................................. 30
90 4 The Situation .................................................................................................................. 30
91 4.1 Overview ............................................................................................................... 30
92 4.2 Business Environment ........................................................................................... 30
93 4.3 Current Systems .................................................................................................... 31
94 4.4 Current Trends ...................................................................................................... 32
95 4.5 Potential Consequences ........................................................................................ 32
96 4.6 Impact of Countermeasures ................................................................................... 33
97 4.7 Requirements ........................................................................................................ 33
98 5 Security Elements ........................................................................................................... 34
99 5.1 Introduction ........................................................................................................... 34
100 5.2 Category Descriptions ........................................................................................... 34
101 5.3 Configuration Management Example ..................................................................... 36
102 5.4 Summary ............................................................................................................... 37
103 6 IACS Definition ............................................................................................................... 38
104 6.1 Functionality Included ............................................................................................ 39
105 6.2 Systems and Interfaces ......................................................................................... 39
106 6.3 Activity-Based Criteria ........................................................................................... 39
107 6.4 Asset-Based Criteria ............................................................................................. 40
108 6.5 Consequence-Based Criteria ................................................................................. 40
109 6.6 Requirements ........................................................................................................ 41
110 7 Principal Roles ............................................................................................................... 41
111 7.1 General ................................................................................................................. 41
112 7.2 Role Descriptions .................................................................................................. 41
113 7.3 Requirements ........................................................................................................ 43
114 8 Models ........................................................................................................................... 44
115 8.1 General ................................................................................................................. 44
116 8.2 Reference Model ................................................................................................... 44

117 8.3 Physical Architecture Model .................................................................................. 45
118 8.4 Zone Model ........................................................................................................... 46
119 8.5 Requirements ........................................................................................................ 48
120 9 General Concepts ........................................................................................................... 48
121 9.1 Security Context .................................................................................................... 48
122 9.2 Security Objectives ................................................................................................ 49
123 9.3 Least Privilege ...................................................................................................... 50
124 9.4 Defense in Depth ................................................................................................... 50
125 9.5 Threat-Risk Assessment ........................................................................................ 50
126 9.6 Policies and Procedures ........................................................................................ 50
127 9.7 Topics Covered by Policies and Procedures .......................................................... 53
128 9.8 Supply Chain Security ........................................................................................... 55

129 10 Fundamental Concepts ................................................................................................... 56
130 10.1 Security Life Cycle ................................................................................................ 57
131 10.2 Maturity Levels ...................................................................................................... 65
132 10.3 Zones and Conduits .............................................................................................. 69
133 10.4 Security Levels ...................................................................................................... 75
134 10.5 Foundational Requirements ................................................................................... 82
135 10.6 Security and Safety ............................................................................................... 85
136 BIBLIOGRAPHY ................................................................................................................... 88
137 Annex A Zones and Conduits Examples ............................................................................. 89
138 A.1 Introduction ........................................................................................................... 89
139 A.2 Untrusted Conduits ................................................................................................ 89
140 A.3 Multi-Plant Model................................................................................................... 89
141 A.4 (Description) .......................................................................................................... 90
142 A.5 SCADA Applications .............................................................................................. 91
143 Annex B Truck Loading Description.................................................................................... 96
144 B.1 Introduction ........................................................................................................... 96
145 B.2 Process Description............................................................................................... 96
146 B.3 Safety and Security ............................................................................................. 106
147 Annex C Example: Procedure to apply foundational requirements .................................... 108
148 C.1 Overview ............................................................................................................. 108
149 C.2 System security assurance when commissioned .................................................. 112
150 C.3 System security assurance during after commissioning ....................................... 112
151 Annex D Key Management ............................................................................................... 113
152 D.1 Introduction ......................................................................................................... 113
153 D.2 Generation and distribution of keys ..................................................................... 113
154 D.3 Key State Phases ................................................................................................ 114
155
156 TABLE OF FIGURES

157 Figure 1 ISA62443 Series Elements .................................................................................. 29
158 Figure 2 Application of the ISA62443 Series ..................................................................... 30
159 Figure 3 Security Elements Grouping ................................................................................. 34
160 Figure 4 Implementation of People, Process, and Technol ogy ............................................ 38
161 Figure 5 Organizational Responsibilities ............................................................................ 42
162 Figure 6 Reference Model .................................................................................................. 44
163 Figure 7 Physical Architecture Model Example ................................................................... 46
164 Figure 8 Zone Model Example ............................................................................................ 47
165 Figure 9 Context Element Relationships ............................................................................. 49

166 Figure 10 Context Model .................................................................................................... 49
167 Figure 11 Trojan Capability Example .................................................................................. 56
168 Figure 12 Life Cycle Steps ................................................................................................. 58
169 Figure 13 Life Cycle Relationships ..................................................................................... 59
170 Figure 14 Life Cycle ........................................................................................................... 60
171 Figure 15 Alternate View of Life Cycle ............................................................................... 61
172 Figure 16 Life Cycle Interdependencies ............................................................................. 62
173 Figure 17 High-level process-industry example showing zones and conduits...................... 79
174 Figure 18 High-level manufacturing example showing zones and conduits ......................... 80
175 Figure 19 High-level manufacturing example showing zones and conduits ......................... 81
176 Figure A-1 Conduit Example .............................................................................................. 89
177 Figure A-2 Multi-plant Zone Example ................................................................................. 90
178 Figure A-3 Separate Zones Example .................................................................................. 91
179 Figure A-4 SCADA Zone Example ...................................................................................... 92
180 Figure A-5 SCADA Separate Zones Example ..................................................................... 93
181 Figure A-6 Enterprise Conduit ............................................................................................ 94
182 Figure A-7 SCADA Conduit Example .................................................................................. 95
183 Figure B-1 Chemical Truck Loading Control System Architecture Diagram ......................... 96
184 Figure B-2 Chemical Truck Loading System with Definition of SUT Boundary .................... 97
185 Figure B-3 Diagram of major components for chemical truck loading example .................... 99
186 Figure B-4 Zone and Conduit Identification ...................................................................... 102
187 Figure B-5 Process Industry Example Showing Zones and c \Conduits ............................. 104
188 Figure B-6 Manufacturing Example Showing Zones and Conduits ..................................... 105
189 Figure C-1 Example application - Chemical truck loading station ...................................... 108
190 Figure D-1 Key management life cycle ............................................................................. 113
191
192 TABLE OF TABLES

193 Table 1 Elements Applied to Change Control and Configuration Management .................... 37
194 Table 2 Entities with relevant life cycles and the respective main responsible role ............. 57
195 Table 3 Security Maturity Phases ....................................................................................... 67
196 Table 4 Concept Phase ...................................................................................................... 67
197 Table 5 Functional Analysis Phase ..................................................................................... 67
198 Table 6 Implementation Phase ........................................................................................... 68
199 Table 7 Operations Phase .................................................................................................. 68
200 Table 8 Recycle and Disposal Phase ................................................................................. 68
201 Table B-1 Typical Likelihood Scale .................................................................................... 98
Table B-2 Typical Consequence Scale ............................................................................... 98

202
203 Table B-3 Table of Assets .................................................................................................. 99
204 Table B-4 Typical Risk Level Matrix ................................................................................. 100
205 Table B-5 Zone Characteristics ........................................................................................ 103
206
207
208 FOREWORD
209 This document is the first of a series of standards and technical reports that addresses the issue
210 of security for industrial automation and control systems (IACS). It has been developed by working
211 group 03 of the ISA99 committee in cooperation with IEC Technical Committee, Work Group 10.
212 This standard describes the concepts and models that form the foundation of all documents in the
213 series. Many of these topics are addressed in more detail in one or more related standards or
214 reports.
215 This document supersedes the first edition of this standard, which was published as ISA99.00.01
216 2007.
217
218 INTRODUCTION
219 The format of this document follows the requirements and conventions presented in ISO/IEC
220 Directives, Part 2. [1] 1 These directives specify the format of this document as well as the use of
221 terms like shall, should, and may. The use of those terms for the requirements specified in
222 Clause 3 of this document use the conventions discussed in the ISO/IEC Directives, Appendix H.
223

1 Numbers in brackets refer to the Bibliography.
224 0 Scope
225 This standard introduces concepts and models that are d escribed and applied in more detail in
226 subsequent standards in the series.
227 The content includes both general purpose cyber security elements that are applicable in the
228 Industrial Automation and Control Systems (I ACS) environment, as well as a small set of concepts
229 and models that are specific or unique to IACS. Normative content is limited to what required to
230 define essential concepts that must be consistently applied across all aspects of and IACS security
231 response.
232 The intended audience for this standard is the IACS community, including asset owners, system
233 integrators, product suppliers, service providers and, where appropriate, compliance authorities.
234 Compliance authorities include but are not limited to government agencies and regulators with the
235 legal authority to perform audits to verify compliance with governing laws and regulations.

236 System integrators, product suppliers and service providers will use this standard to evaluate
237 whether their products and services can provide the functional security cap ability to meet the asset
238 owners target security level requirements. As with the assignment of these requirements,
239 applicability of individual control system requirements and requirement enhancements must be
240 based on an asset owners security policies, pr ocedures and risk assessment in the context of their
241 specific site.
242 There is insufficient detail in this standard to design and build a comprehensive security
243 architecture. That requires additional system -level analysis and development of derived
244 requirements that are the subject of other standards in the ISA62443 series.
245
246 1 Normative references

247 The following referenced documents are indispensable for the application of this document. For
248 dated references, only the edition cited applies. For undated references, the latest edition of the
249 referenced document (including any amendments) applies.
250 ISATR62443-1-2, Security for Industrial Automation and Con trol Systems Master Glossary
251 ISA62443-2-1, Security for industrial automation and control systems Requirements for an
252 Industrial automation and control system security management system
253 ISA62443-3-2, Security for Industrial Automation and Control Systems Security Risk Assessment
254 and System Design
255 ISA62443-3-3, Security for Industrial Automation and C ontrol Systems System Security
256 Requirements and Security Levels
257 ISA62443-4-1, Security for Industrial Automation and Control Systems Product Development
258 Requirements
259 ISA62443-4-2, Security for Industrial Automation and Control Systems Technical Security
260 Requirements for IACS Components
261 ISO/IEC 27001 Information technology Security techniques Information security management
262 systems Requirements
263 ISO/IEC 27002, Information technology Security techniques Code of practice for information
264 security management
265
266 2 Terms, definitions, abbreviated terms, acronyms, and conventions

267 2.1 Terms and definitions
268 For the purposes of this document, the terms and definitions given in ISA62443-1-1 and the
269 following apply.
270 2.1.1
271 access
272 ability and means to communicate with or otherwise interact with a system in order to use syst em
273
resources
274 Note to entry: Access may involve physical access (authorization to be allowed physically in an area, possession of a
275 physical key lock, PIN code, or access card or biometric attributes that allow access) or logical access (authorization to
276 log in to a system and application, through a combination of logical and physical means)
277 2.1.2
278 access control

279 protection of system resources against unauthorized access; a process by which use of system
280 resources is regulated according to a security policy and i s permitted by only authorized entities
281 (users, programs, processes, or other systems) according to that policy
282 2.1.3
283 accountability
284 property of a system (including all of its system resources) that ensures that the actions of a system
285 entity may be traced uniquely to that entity, which can be held responsible for its actions
286 2.1.4
287 actuator
288 actuating element connected to process equipment and to the control system
289 2.1.5
290 application
291 software programs executing on the infrastructure that are used to interface with the pr ocess or the
292 control system itself
293 2.1.6
294 area
295 subset of a sites physical, geographic, or logical group of assets
296 Note to entry: An area may contain manufacturing lines, process cells, and production units. Areas may be connected to
297 each other by a site local area network and may contain systems related to the operations performed in that area.
298 2.1.7
299 asset
300 physical or logical object owned by or under the custodial duties of an organization, having either
301 a perceived or actual value to the organization
302 Note to entry: In the case of industrial automation and control systems the physical assets that have the largest directly
303 measurable value may be the equipment under control.
304 2.1.8
305 asset operator
306 individual or organization responsible for the operation of the IACS
307 2.1.9
308 asset owner
309 individual or organization that owns the IACS assets
310 2.1.10
311 attack
312 assault on a system that derives from an intelligent threat i.e., an intelligent act that is a
313 deliberate attempt (especially in the sense of a method or technique) to evade security serv ices
314 and violate the security policy of a system
315 Note to entry: There are different commonly recognized classes of attack:
316 An active attack attempts to alter system resources or affect their operation. A passive attack attempts to learn or
317 make use of information from the system but does not affect system resources.
318 An inside attack is an attack initiated by an entity inside the security perimeter (an insider) i.e., an entity that is
319 authorized to access system resources but uses them in a way no t approved by those who granted the authorization. An
320 outside attack is initiated from outside the perimeter, by an unauthorized or illegitimate user of the system (including an
321 insider attacking from outside the security perimeter). Potential outside at tackers range from amateur pranksters to
322 organized criminals, international terrorists, and hostile governments.
323
2.1.11
324 audit
325

independent review and examination of records and activities to assess the adequacy of system
326 controls, to ensure compliance with established policies and operational procedures, and to
327 recommend necessary changes in controls, policies, or procedures (See security audit)
328 Note to entry: There are three forms of audit. (1) External audits are conducted by parties who are not employees or
329 contractors of the organization. (2) Internal audit are conducted by a separate organizational unit dedicated to inter nal
330 auditing. (3) Controls self-assessments are conducted by peer members of the process automation function.
331 2.1.12
332 authentication
333 security measure designed to establish the validity of a transmission, message, or originator, or a
334 means of verifying an individual's authorization to receive specific categories of information
335 2.1.13
336 authorization
337 right or a permission that is granted to a system entity t o access a system resource
338 2.1.14
339 availability
340 probability that an asset, under the combined influence of its reliability, maintainability, and
341 security, will be able to fulfill its required function over a stated period of time, or at a given point
342 in time
343 2.1.15
344 border
345 edge or boundary of a physical or logical zone
346 2.1.16
347 botnet
348 collection of software robots, or bots, which run autonomously
349 Note to entry: A botnet's originator can control the group remotely, possibly for nefarious purposes.
350 2.1.17
351 boundary
352 software, hardware, or other physical barrier that limits access to a system or part of a system
353 2.1.18
354 business system
355 collection of information technology elements (i.e., hardware, software and services) installed with
356 the intent to facilitate an organizations business process or processes (administrative or project)
357 2.1.19
358 cell
359 lower-level element of a manufacturing process that performs manufacturing, field device control,
360 or vehicle functions
361 Note to entry: Entities at this level may be connected together by an area control network and may contain information
362 systems related to the operations performed in that entity.
363 2.1.20
364 channel
365 specific communication path established within a communication conduit (See conduit).
366 2.1.21
367 client
368 device or application receiving or requesting services or info rmation from a server application
369 2.1.22

370 communication path
371 logical connection between a source and one or more destinations, which could be devices,
372 physical processes, data items, commands, or programmatic interfaces
373 Note to entry: The communication path is not limited to wired or wireless networks, but includes other means of
374 communication such as memory, procedure calls, state of physical plant, portable media, and human interactions.
375 2.1.23
376 communication system
377 arrangement of hardware, software, and propagation media to allow the transfer of messages
378 (ISO/IEC 7498 application layer service data units) from one application to another
379 2.1.24
380 compromise
381 unauthorized disclosure, modification, substitution, or use of information (incl uding plaintext
382 cryptographic keys and other critical security parameters)
383 2.1.25
384 conduit
385 logical grouping of communication assets that protects the security of the channels it contains
386 Note to entry: This is analogous to the way that a physical co nduit protects cables from physical damage.
387 2.1.26
388 confidentiality
389 assurance that information is not disclosed to unauthorized individuals, processes, or devices
390 2.1.27
391 control center
392 central location used to operate a set of assets
393 Note to entry: Infrastructure industries typicall y use one or more control centers to supervise or coordinate their
394 operations. If there are multiple control centers (for example, a backup center at a separate site), they are typically
395 connected together via a wide area network. The control center contai ns the SCADA host computers and associated
396 operator display devices plus ancillary information systems such as a historian.
397 Note to entry: In some industries the term control room may be mor e commonly used.
398 2.1.28
399 control equipment
400 class that includes distributed control systems, programmable logic controllers, SCADA systems,
401 associated operator interface consoles, and field sensing and control devices used to manage and
402 control the process
403 Note to entry: The term also includes field bus networks where control logic and algorithms are executed on intelligent
404 electronic devices that coordinate actions with each other, as well as systems used to monitor the process and the
405 systems used to maintain the process.
406 2.1.29
407 control network
408 time-critical network that is typically connected to equipment that controls physical processes
409 Note to entry: The control network can be subdivided into zones, and there can be multiple separate control networks
410 within one company or site.
411 2.1.30
412 cost
413 value of impact to an organization or person that can be measured
414 2.1.31
415 countermeasure
416 action, device, procedure, or technique that reduces a threat, a vulnerability, or an attack by
417 eliminating or preventing it, by minimizing the harm it can cause, or by disc overing and reporting it
418 so that corrective action can be taken
419 Note to entry: The term Control is also used to describe this concept in some contexts. The term countermeasure has

420 been chosen for this standard to avoid confusion with the word control in the context of process control.
421 2.1.32
422 cryptographic algorithm
423 algorithm based upon the science of cryptography, including encryption algorithms, cryptographic
424 hash algorithms, digital signature algorithms, and key agreement algorithms
425 2.1.33
426 cryptographic key
427 input parameter that varies the transformation performed by a cryptographic algorithm
428 Note to entry: Usually shortened to just key.
429 2.1.34
430 data confidentiality
431 property that information is not made available or disclosed to any unauthorized system entity,
432 including unauthorized individuals, entities, or processes
433 2.1.35
434 data integrity
435 property that data has not been changed, destroyed, or lost in an unauthorized or accidental
436 manner
437 Note to entry: This term deals with constancy of and confidence in data values, not wi th the information that the values
438 represent or the trustworthiness of the source of the values.
439 2.1.36
440 decryption
441 process of changing cipher text into plaintext using a cryptographic algorithm and key (See
442 encryption)
443 2.1.37
444 defense in depth
445 provision of multiple security protections, especially in layers, with the intent to delay if not prevent
446 an attack
447 Note to entry: Defense in depth implies layers of security and detection, even on single systems, and provides the
448 following features:
449 a) attackers are faced with breaking through or bypassing each layer without being detected
450 b) flaw in one layer can be mitigated by capabilities in other layers
451 c) system security becomes a set of layers within the overall network security.
452 2.1.38
453 demilitarized zone
454 perimeter network segment that is logically between internal and external networks
455 Note to entry: The purpose of a demilitarized zone is to enforce the internal networks policy for external information
456 exchange and to provide external, untrusted sources with restricted access to relea sable information while shielding the
457 internal network from outside attacks.
458 Note to entry: In the context of industrial automation and control systems, the term internal network is typically applied
459 to the network or segment that is the primary focus of protection. For example, a control network could be considered
460 internal when connected to an external business network.
461 2.1.39
462 denial of service
463 prevention or interruption of authorized access to a system resource or the delaying of system
464 operations and functions
465 Note to entry: In the context of industrial automation and control systems, denial of service can refer to loss of process
466 function, not just loss of data communications.

467 2.1.40
468 digital signature
469 result of a cryptographic transformation of data which, wh en properly implemented, provides the
470 services of origin authentication, data integrity, and signer non -repudiation
471 2.1.41
472 distributed control system
473 type of control system in which the system elements are dispersed but operated in a coupled
474 manner
475 Note to entry: Distributed control systems may have shorter coupling time constants than those typically found in SCADA
476 systems.
477 Note 2 to entry: Distributed control systems are commonly associated with continuous processes such as electric power
478 generation; oil and gas refining; chemical, pharmaceutical and paper manufacture, as well as discrete processes such as
479 automobile and other goods manufacture, packaging, and warehousing.
480 2.1.42
481 domain
482 environment or context that is defined by a security policy, security model, or s ecurity architecture
483 to include a set of system resources and the set of system entities that have the right to access the
484 resources
485 2.1.43
486 eavesdropping
487 monitoring or recording of communicated information by unauthorized parties
488 2.1.44
489 electronic security
490 actions required to preclude unauthorized use of, denial of service to, modifications to, disclosure
491 of, loss of revenue from, or destruction of critical systems or informational assets
492 Note to entry: The objective is to reduce the risk of causing personal injury or endangering public health, losing public or
493 consumer confidence, disclosing sensitive assets, failing to protect business assets or failing to comply with regulations.
494 These concepts are applied to any system in the production process and include both s tand-alone and networked
495 components. Communications between systems may be either through internal messaging or by any human or machine
496 interfaces that authenticate, operate, control, or exchange data with any of these control systems. Electronic security
497 includes the concepts of identification, authentication, accountability, authorization, availability, and privacy.
498 2.1.45
499 encryption
500 cryptographic transformation of plaintext into ciphertext that conceals the datas original meaning
501 to prevent it from being known or used (See decryption)
502 Note to entry: If the transformation is reversible, the corresponding reversal process is called decryption, which is a
503 transformation that restores encrypted data to its original state.
504 2.1.46
505 enterprise
506 business entity that produces or transports products or operates and maintains infrastructure
507 services
508 2.1.47
509 equipment under control
510 equipment, machinery, apparatus or plant used for manufacturing, process, transportation, medical
511 or other activities
512 2.1.48
513 essential function
514 function or capability that is required to maintain health, safety, the environment and availability for
515 the equipment under control

516 Note to entry: Essential functions include, but are not limited to, the safety instrumented function (SIF), the control
517 function and the ability of the operator to view and manipulate the equipment under control. The loss of essential functions
518 is commonly termed loss of protection, loss of control and loss of view respectively. In some industries additional functions
519 such as history may be considered essential.
520 2.1.49
521 firewall
522 inter-network connection device that restricts data communication traffic between two connected
523 networks
524 Note to entry: A firewall may be either an application installed on a general -purpose computer or a dedicated platform
525 (appliance) that forwards or rejects/drops packets on a network. Typically, firewalls are used to define zone borders.
526 Firewalls generally have rules restricting which ports are open.
527 2.1.50
528 gateway
529 relay mechanism that attaches to two (or more) computer networks that have similar functions but
530 dissimilar implementations and that enables host computers on one network to communicate with
531 hosts on the other
532 Note to entry: Also described as an intermediate system that is the translation interface between two computer networks.
533 2.1.51
534 geographic site
535 subset of an enterprises physical, geographic, or logical group of assets
536 Note to entry: A geographic site may contain areas, manufacturing lines, process cells, process units, control centers,
537 and vehicles and may be connected to other sites by a wide area network.
538 2.1.52
539 host
540 computer that is attached to a communication subnetwork or inter -network and can use services
541 provided by the network to exchange data with other attached systems
542 2.1.53
543 industrial automation and control systems
544 collection of personnel, hardware, and software that can affect or influence the safe, secure, and
545 reliable operation of an industrial process
546 Note to entry: These systems include, but are not limited to:
547 a) industrial control systems, including distributed control systems (DCSs), programmable logic controllers (PLCs),
548 remote terminal units (RTUs), intelligent electronic devices, supervisory control and data acquisition (SCADA),
549 networked electronic sensing and control, and monitoring and diagnostic syste ms. (In this context, process
550 control systems include basic process control system and safety -instrumented system [SIS] functions, whether
551 they are physically separate or integrated.)
552 b) associated information systems such as advanced or multivariable control , online optimizers, dedicated
553 equipment monitors, graphical interfaces, process historians, manufacturing execution systems, and plant
554 information management systems.
555 c) associated internal, human, network, or machine interfaces used to provide control, safe ty, and manufacturing
556 operations functionality to continuous, batch, discrete, and other processes.
557 2.1.54
558 insider
559 trusted person, employee, contractor, or supplier who has information that is not generally known
560 to the public (See outsider)
561
2.1.55
562 integrity
563 quality of a system reflecting the logical correctness and reliability of the operating system, the
564 logical completeness of the hardware and software implementing the protection mechanisms, and
565 the consistency of the data structures and occurrence of the stored data
566

Note to entry: In a formal security mode, integrity is often interpreted more narrowly to mean protection against
567 unauthorized modification or destruction of information.
568 2.1.56
569 interception
570 capture and disclosure of message contents or use of traffic analysis to compromise the
571 confidentiality of a communication system based on message destination or origin, frequency or
572 length of transmission, and other communication attributes
573 2.1.57
574 interface
575 logical entry or exit point that provides access to the module f or logical information flows
576 2.1.58
577 intrusion
578 unauthorized act of compromising a system (See attack).
579 2.1.59
580 intrusion detection
581 security service that monitors and analyzes system events for the purpose of finding, and providing
582 real-time or near real-time warning of, attempts to access system resources in an unauthorized
583 manner
584 2.1.60
585 ISO
586 International Organization for Standardization
587 2.1.61
588 key management
589 process of handling and controlling cryptographic keys and related material (such as initialization
590 values) during their life cycle in a cryptographic system, including ordering, generating, distributing,
591 storing, loading, escrowing, archiving, auditing, and destroying the keys and related material
592 2.1.62
593 line
594 lower-level element of a manufacturing process that performs manufactur ing, field device control,
596 Note to entry: See Cell
597 2.1.63
598 local area network
599 communications network designed to connect computers and other intelligent devices in a limited
600 geographic area (typically less than 10 kilometers)
601 2.1.64
602 malicious code
603 programs or code written for the purpose of gathering information about systems or users,
604 destroying system data, providing a foothold for further intrusion into a system, falsifying system
605 data and reports, or providing time-consuming irritation to system operations and maintenance
606 personnel
607 Note to entry: Malicious code attacks can take the form of viruses, worms, Trojan Horses, or other automated exploits.
608 Note to entry: Malicious code is also often referred to as malware.
609 2.1.65
610 manufacturing operations
611 collection of production, maintenance, and quality assurance operations and their relationship to
612 other activities of a production facility
613 Note to entry: Manufacturing operations include:
614 a) manufacturing or processing facility activities that coordinate the personnel, equipment, and material involved

615 in the conversion of raw materials or parts into products.
616 b) functions that may be performed by physical equipment, human effort, and information systems.
617 c) managing information about the schedules, use, capabil ity, definition, history, and status of all resources
618 (personnel, equipment, and material) within the manufacturing facility.
619 2.1.66
620 OPC
621 set of specifications for the exchange of information in a process control environment
622 Note to entry: The abbreviation OPC originally came from OLE for Process Control, where OLE was short for Object
623 Linking and Embedding.
624 2.1.67
625 outsider
626 person or group not trusted with inside access, who may or may not be known to the targeted
627 organization (See insider)
628 Note to entry: Outsiders may or may not have been insiders at one time.
629 2.1.68
630 penetration
631 successful unauthorized access to a protected system resource
632 2.1.69
633 plaintext
634 unencoded data that is input to and transformed by an encryption process, or that is output by a
635 decryption process
636 2.1.70
637 privilege
638 authorization or set of authorizations to perform specific functions, especially in the context of a
639 computer operating system
640 Note to entry: Examples of functions that are controlled through the use of privilege include acknowledging alarms,
641 changing setpoints, modifying control algorithms.
642 2.1.71
643 process
644 series of operations performed in the making, treatment or transportation of a product or material
645 Note to entry: This standard makes extensive use of the term process to describe the equipment u nder control of the
646 industrial automation and control system.
647 2.1.72
648 protocol
649 set of rules (i.e., formats and procedures) to implement and control some type of association (e.g.,
650 communication) between systems
651 2.1.73
652 reference model
653 framework for understanding significant relationships among the entities of some environment, and
654 for the development of consistent standards or specifications supporting that environment.
655
Note to entry: A reference model is based on a small number of unifying concepts and may be used as a basis for
656 education and explaining standards to a non-specialist.
657 2.1.74
658 reliability
659 ability of a system to perform a required function under stated conditions for a specified period of
660 time

661 2.1.75
662 remote access
663 use of systems that are inside the perimeter of the s ecurity zone being addressed from a different
664 geographical location with the same rights as when physically present at the location
665 Note to entry: The exact definition of remote can vary according to situation. For example, access may come from a
666 location that is remote to the specific zone, but still within the boundaries of a company or organization. This might
667 represent a lower risk than access that originates from a location that is remote and outside of a companys boundaries.
668 2.1.76
669 repudiation
670 denial by one of the entities involved in a communication of having participated in all or part of the
671 communication
672 2.1.77
673 risk
674 expectation of loss expressed as the probability that a particular threat will exploit a particular
675 vulnerability with a particular consequence
676 2.1.78
677 risk assessment
678 process that systematically identifies potential vulnerabilities to valuable system resources and
679 threats to those resources, quantifies loss exposures and consequences based on probability of
680 occurrence, and (optionally) recommends how to allocate resources to countermeasures to
681 minimize total exposure
682 Note to entry: Types of resources include physical, logical and human.
683 Note to entry: Risk assessments are often combined with vulnerability assessments to identify vulnerabilit ies and quantify
684 the associated risk. They are carried out initially and periodically to reflect changes in the organization's risk tolerance,
685 vulnerabilities, procedures, personnel and technological changes.
686 2.1.79
687 risk management
688 process of identifying and applying countermeasures commensurate with the value of the assets
689 protected based on a risk assessment
690 2.1.80
691 router
692 gateway between two networks at OSI layer 3 and that relays and directs data packets through that
693 inter-network. The most common form of router passes Internet Protocol (IP) packets
694 2.1.81
695 safety
696 freedom from unacceptable risk
697 2.1.82
698 safety-instrumented system
699 system used to implement one or more safety-instrumented functions
700 Note to entry: A safety-instrumented system is composed of any combination of sensor(s ), logic solver(s), and actuator(s).
701 2.1.83
702 safety integrity level
703 discrete level (one out of four) for specifying the safety integrity requirements of the safety -
704 instrumented functions to be allocated to the safety-instrumented systems
705 Note to entry: Safety integrity level 4 has the highest level of safety integrity; safety integrity level 1 has the lowest.
706 2.1.84

707 secret
708 condition of information being protected from being known by any system entities except those
709 intended to know it
710 2.1.85
711 security
712 1. measures taken to protect a system
713 2. condition of a system that results from the establishment and maintenance of measures to
714 protect the system
715 3. condition of system resources being free from unauthorized access and from unauthorized or
716 accidental change, destruction, or loss
717 4. capability of a computer-based system to provide adequate confidence that unauthorized

718 persons and systems can neither modify the software and its data nor gain access to the system
719 functions, and yet to ensure that this is not denied to authorized persons and systems
720 5. prevention of illegal or unwanted penetration of or interference with the proper and intended
721 operation of an industrial automation and control system
722 Note to entry: Measures can be controls related to physical security (controlling physical access to computing assets) or
723 logical security (capability to login to a given system and application.)
724 2.1.86
725 security architecture
726 plan and set of principles that describe the security services that a system is required to provide to
727 meet the needs of its users, the system elements required to implement the services, and the
728 performance levels required in the elements to deal with the threat environment
729 Note to entry: In this context, security architecture would be an architecture to protect the control netwo rk from intentional
730 or unintentional security events.
731 2.1.87
732 security audit
733 independent review and examination of a system's records and activities to determine the adequacy
734 of system controls, ensure compliance with established security policy and procedures, detect
735 breaches in security services, and recommend any changes that are indicated for countermeasures
736 2.1.88
737 security control
738 See countermeasure
739 2.1.89
740 security event
741 occurrence in a system that is relevant to the security of the system
742 2.1.90
743 security incident
744 adverse event in a system or network or the threat of the occurrence of such an event
745 Note to entry: The term near miss is sometimes used to describe an event that could have been an incident under
746 slightly different circumstances.
747 2.1.91
748 security level
749 level corresponding to the required effectiveness of countermeasures and inherent security
750 properties of devices and systems for a zone or conduit based on assessment of risk for the zone
751 or conduit

752 2.1.92
753 security objective
754 aspect of security which to achieve is the purpose and objective of using certain mitigation
755 measures, such as confidentiality, integrity, availability, user authenticity, access authorization,
756 accountability
757 2.1.93
758 security perimeter
759 boundary (logical or physical) of the domain in which a security poli cy or security architecture
760 applies, i.e., the boundary of the space in which security services protect system resources
761 2.1.94
762 security policy
763 set of rules that specify or regulate how a system or organization provides security services to
764 protect its assets
765 2.1.95
766 security procedures
767 definitions of exactly how practices are implemented and executed
768 2.1.96
769 security program
770 a combination of all aspects of managing security, ranging from the definition and communication
771 of policies through implementation of best industry prac tices and ongoing operation and auditing
772 2.1.97
773 security services
774 mechanisms used to provide confidentiality, data integrity, authentication, or no repudiation of
775 information
776 2.1.98
777 security violation
778 act or event that disobeys or otherwise breaches security policy t hrough an intrusion or the actions
779 of a well-meaning insider
780 2.1.99
781 zone
782 grouping of logical or physical assets that share common security requirements
783 Note to entry: All unqualified uses of the word zone in this standard should be assumed to refer to a security zone.
784 Note to entry: A zone has a clear border with other zones. The security policy of a zone is typically enforced by a
785 combination of mechanisms both at the zone edge and within the zone. Zones can be hierarchical in the sense that they
786 can be comprised of a collection of subzones.
787 2.1.100
788 sensor
789 measuring element connected to process equipment and to the control system
790 2.1.101
791 server
792 device or application that provides information or services to client applications and devices
793 2.1.102
794 supervisory control and data acquisition (SCADA) system
795
type of loosely coupled distributed monitoring and control system commonly associated with electric
796 power transmission and distribution systems, oil and gas pipelines, and water and sewage systems
797 Note to entry: Supervisory control systems are also used within batch, continuous, and discrete manufacturing plants to
798 centralize monitoring and control activities for these sites.
799 2.1.103

800 system
801 interacting, interrelated, or interdependent elements forming a complex whole
802 2.1.104
803 system software
804 special software designed for a specific computer system or family of computer systems to facilitate
805 the operation and maintenance of the computer system and associated programs and data
806 2.1.105
807 threat
808 potential for violation of security, which exists when there is a circumstance, capability, action, or
809 event that could breach security and cause harm
810 2.1.106
811 traffic analysis
812 inference of information from observable characteristics of data flow(s), even when the data are
813 encrypted or otherwise not directly available, including the identities and locations of source(s) and
814 destination(s) and the presence, amount, frequency, and duration of occurrence
815 2.1.107
816 trojan horse
817 computer program that appears to have a useful function, but also has a hidden and potentially
818 malicious function that evades security mechanisms, sometimes by exploiting legitimate
819 authorizations of a system entity that invokes the program
820 2.1.108
821 unit
822 lower-level element of a manufacturing process that performs manufacturing, field device control,
824 Note to entry: See Cell
825 2.1.109
826 use case
827 technique for capturing potential functional requirements that employs the use of one or more
828 scenarios that convey how the system should interact with the end user or another system to
829 achieve a specific goal
830 Note to entry: Typically use cases treat the system as a black box, and the interactions with the system, including system
831 responses, are as perceived from outside of the system. Use cases are popular because they simplify the description of
832 requirements, and avoid the problem of making assumptions about how this functionality will be accomplished.
833 2.1.110
834 user
835 person, organization entity, or automated process that accesses a system, whether authorized to
836 do so or not
837 2.1.111
838 virus
839 self-replicating or self-reproducing program that spreads by inserting copies of itself into other
840 executable code or documents
841
2.1.112
842 vulnerability
843 flaw or weakness in a system's design, implementation, or operation and management that could
844 be exploited to violate the system's integrity or security pol icy
845 2.1.113
846

wide area network
847 communications network designed to connect computers, networks and other devices over a large
848 distance, such as across the country or world
849 2.1.114
850 wiretapping
851 attack that intercepts and accesses data and other information contained in a f low in a
852 communication system
853 Note to entry: Although the term originally referred to making a mechanical connection to an electrical conductor that
854 links two nodes, it is now used to refer to reading information from any sort of medium used for a link or even directly
855 from a node, such as a gateway or subnetwork switch.
856 Note to entry: Active wiretapping attempts to alter the data or otherwise affect the flow; passive wiretapping only
857 attempts to observe the flow and gain knowledge of information it con tains.
858 2.1.115
859 worm
860 computer program that can run independently, can propagate a complete working version of itself
861 onto other hosts on a network, and may consume computer resources destructively
862 2.2 Abbreviated terms and acronyms

863 The following abbreviated terms and acronyms are used in this document.
ANSI American National Standards Institute

CIA Confidentiality, Integrity, and Availability
CN Control Network
COTS Commercial Off The Shelf
IACS Industrial Automation and Control System
IEC International Electrotechnical Commission
ISA International Society of Automation
ISO International Organization for Standardization
SUC System Under Consideration
TR Technical Report
864 2.3 Conventions

865 There are several conventions used in this standard, as described in the following paragraphs.
866 2.3.1 Reserved terms

867 The following terms are reserved for normative clauses.
868 shall: The word shall, equivalent to "is required to", is used to indicate mandatory
869 requirements, to be followed strictly in order to confor m to the standard and from which
870 no deviation is permitted.
871 must: The use of the word must is depreciated and shall not be used when stating mandatory
872 requirements. The word must is only used to describe unavoidable situations.
873 should: The word should, equivalent to "is recommended that", is used to indicate
874 Among several possibilities one is recommended as particularly suitable, without
875 mentioning or excluding others.
876 That a certain course of action is preferred but not required.
877 That (in the negative form) a certain course of action is depreciated but not

878 prohibited.
879 may: The word may, equivalent to "is permitted", is used to indicate a course of action
880 permissible within the limits of this standard.
881 can: The word can, equivalent to "is able to", is used to indicate possibility and capability,
882 whether material or physical.
883 2.3.2 Proper nouns
884 The term Solution is used as a proper noun (and therefore capitalized) in this document to prevent
885 confusion with other uses of the term.
886
887 3 The ISA62443 series

888 3.1 Purpose
889 The ISA62443 series includes standards and technical reports that address the need to design
890 electronic security robustness and resilience into industrial automation control systems (IACS).
891 Robustness provides the capabilities for the system under consideration (SuC) to operate under a
892 range of cyber-induced perturbations and disturbances. Resilience provides the capa bilities to
893 restore the SuC after unexpected and rare cyber -induced events. Robustness and resilience are
894 not general properties of IACS but are relevant to specific classes of cyber -induced perturbations.
895 A SuC that is resilient or robust to a certain typ e of cyber-induced perturbations may be brittle or
896 fragile to another. Such a trade-off is the subject of profiles, which others can derive from the
897 ISA62443 requirements and guidelines.
898 The goal in developing the ISA62443 series is to improve the availability, integrity and
899 confidentiality of components or systems used for industrial automation and control, and to provide
900

criteria for procuring and implementing secure industrial automation and control systems.
901 Application of the requirements and guidance in ISA62443 is intended to improve electronic
902 security and help to reducing the risk of compromising confidential informat ion or causing
903 degradation or failure of the equipment (hardware and software) of systems under control.
904 The concept of industrial automation and control systems electronic security is applied in the
905 broadest possible sense, encompassing all types of plant s, facilities, and systems in all industries.
906 Automation and control systems include, but are not limited to:
907 hardware and software systems such as DCS, PLC, SCADA, networked electronic sensing, and
908 monitoring and diagnostic systems
909 associated internal, human, network, or machine interfaces used to provide control, safety, and
910 manufacturing operations functionality to continuous, batch, discrete, and other processes
911 The requirements and guidance are directed towards those responsible for designing,
912 implementing, or managing industrial automation and control systems. This information also applies
913 to users, system integrators, security practitioners, and control systems manufacturers and
914 vendors.
915 3.2 Approach

916 The ISA62443 series builds on established standards for the security of general purpose
917 information technology systems (e.g., the ISO/IEC 27000 series), identifying and addressing the
918 important differences present in Industrial Automation and Control Systems (IACS ). Many of these
919 differences are based on the reality that cyber security risks with IACS may have Health, Safety or
920 Environment (HSE) implications and the response should be integrated with other existing risk
921 management practices addressing these risks.
922 3.3 Structure

923 Each of the individual standards and reports in the ISA62443 series address a specific aspect of
924 the subject, as shown in Figure 1.
925
926 Figure 1 ISA62443 Series Elements
927 3.4 Organization

928 The elements of the series are arranged in four groups, corresponding to the primary focus and
929 intended audience.
930 The first or general group includes elements that address t opics that are common to the entire
931 series. These are:
932 ISA62443-1-1 (This document) introduces the concepts and models used throughout the
933 series.
934 ISATR62443-1-2 is a master glossary of terms and abbreviations used throughout the series.
935 ISA62443-1-3 describes a series of quantitative metrics derived from the foundational
936 requirements, system requirements and associated.
937 ISA-TR62443-1-4 provides a more detailed description of the underlying life cycle for IACS
938 security, as well as several use cases that illustrate various applications.
939 The elements in the second group focus on the policies and procedures associated with IACS
940 security. These are:
941 ISA62443-2-1 describes what is required to define and implement an effective IACS cyber
942 security management system.
943 ISA62443-2-2 provides specific guidance on what is required to operate an effective IACS
944 cyber security management system.
945 ISATR62443-2-3 provides guidance on the specific subject of patch manageme nt for IACS.
946 ISA62443-2-4 (adopted from IEC 62433-2-4) specifies requirements for suppliers of IACS.
947 The elements in the third group address requirements at the system level. These are:
948 ISATR62443-3-1 describes the application of various security technologies to an IACS

949 environment.
950 ISA62443-3-2 addresses security risk assessment and system design for IACS.
951 ISA62443-3-3 describes the foundational system security requirements and security assurance
952 levels.
953 Elements in the fourth and final group includes information about the more specific and detailed
954 requirements associated with the development of IACS products. These are:
955 ISA62443-4-1 describes the derived requirements that are applicable to the development of
956 products.
957 ISA62443-4-2 contains sets of derived requirements that provide a detailed mapping of the
958 system requirements to subsystems and components of the system under consideration.
959 3.5 Applying the Standards
960

Each of the standards and technical reports in the series is specifically intended for application at
961 one or more stages of the life cycle of and IACS, as shown in the following figure.
962 This figure will be redrawn to conform to IEC guidelines.
IACS life cycle
Asset Owner System Asset Owner Asset Owner

Integrator (Service provider)
Security
Automation solution Automation solution Automation solution
targets
Project application Security measures and settings Decommissioning

Configuration, User Management Operational policies and policies and
Security measures and settings procedures procedures
2- 4 2- 1 3- 2 2- 1
2- 1 2- 3
3- 2 2- 3
3- 3 2- 4 3- 3 2- 4
Specification Integration / Commissioning Operation / Maintenance Decommissioning
963
964 Figure 2 Application of the ISA62443 Series
965 3.6 Metrics

966 Specific and detailed metrics are necessary in order to assess progress in the application of the
967 ISA62443 standards.
968
969 4 The Situation

970 4.1 Overview
971 Industrial automation and control systems operate within a complex environment. An in depth
972 understanding of this environment is an essential prerequisite to ensuring its security. This includes
973 the business environment, current systems and trends, and potential consequences.
974 4.2 Business Environment

975 Organizations are increasingly sharing information between business and industrial automation
976 systems, and partners in one business venture may be competitors in another. At the same time
977 new technology enables more advanced capabilities in support of business needs.
978 Although technology changes and partner relationships may be good for business, they increase
979 the potential risk of compromising security. As the threats to businesses increas e, so does the need
980 for security.
981 Because industrial automation and control systems equipment connects directly to a process, loss
982 of sensitive information or interruption in the flow of information are not the only consequences of
983 a security breach. The potential loss of life or production, environmental damage, regulatory
984 violation, and compromise to operational safety are far more serious consequences. These may
985 have ramifications beyond the targeted organization; they may grievously damage the infrastru cture
986 of the host region or nation.
987 External threats are not the only concern. Knowledgeable insiders with malicious intent or even an
988 innocent unintended act can pose a serious security risk. Additionally, industrial automation and
989 control systems are often integrated with other business systems. Modifying or testing operational
990 systems has led to unintended effects on system operations. Personnel from outside the control
991 systems area increasingly perform security testing on the systems, exacerbating the n umber and
992 consequence of these effects. Combining all these factors, it is easy to see that the potential of
993 someone gaining unauthorized or damaging access to an industrial process is not trivial.
994 4.3 Current Systems
995 Industrial automation and control systems have evolved from individual, isolated computers with
996 proprietary operating systems and networks to interconnected systems and applications employing

997 commercial off the shelf (COTS) technology (i.e., operating systems and protocols). These control
998 systems are increasingly being integrated with non-IACS systems and applications through various
999 communication networks.
1000 4.3.1 Business Benefits

1001 This increased level of integration provides significant business benefits, including:
1002 Increased visibility of industrial control system activities (work in process, equipment status,
1003 production schedules) and integrated processing systems from the business level, contributing
1004 to the improved ability to conduct analyses to drive down production costs and improve
1005 productivity.
1006 Integrated manufacturing and production systems have more direct access to business level
1007 information, enabling a more responsive enterprise.
1008 Common interfaces that reduce overall support costs and permit remote support of production
1009 processes.
1010 Remote monitoring of the process control systems that reduces support costs and allows
1011 problems to be solved more quickly.
1012 4.3.2 Security Considerations
1013 There are definite security related considerations associat ed with each of these benefits.
1014 Devices, open networking technologies and increased connectivity provide increased
1015 opportunities for cyber-attack against control system hardware and software. That weakness
1016 may lead to health, safety and environmental (HSE), financial and/or reputational consequences
1017 in deployed control systems.
1018 Organizations deploying general commodity information technology (IT) cyber security solutions
1019 to address IACS security may not fully comprehend the results of this decision. While many
1020 business IT applications and security solutions can be applied to IACS, they need to be applied
1021 in an appropriate way to eliminate inadvertent consequences. For this reason, the approach
1022 used to define system requirements needs to be based on a combination of functional
1023 requirements and risk assessment, often including an awareness of operational issues as well.
1024 It is possible to define standards for models and information exchanges that allow the industrial
1025 automation and control systems community to share information in a consistent way. However,
1026 this ability to exchange information increases vulnerability to misuse and attack by individuals
1027 with malicious intent and introduces potential risks to the enterprise using industrial automation
1028 and control systems.
1029 Industrial automation and control systems configura tions can be very complex in terms of
1030 physical hardware, programming, and communications. This complexity can often make it
1031 difficult to determine:
1032 who is authorized to access electronic information,
1033 when a user can have access to the information,
1034 what data or functions a user should be able to access,
1035 where the access request originates, and
1036 how the access is requested.
1037 4.4 Current Trends
1038 Several trends contribute to the increased emphasis on the security of industrial automation and
1039 control systems:
1040 Businesses have reported more unauthorized attempts (either intentional or unintentional) to

1041 access electronic information each year than in the previous year.
1042 Industrial automation and control systems include more COTS software components (e.g.,
1043 operating systems and protocols) and are interconnecting with business networks, making these
1044 systems susceptible to the same software attacks as are present in business and desktop
1045 devices.
1046 The use of joint ventures, alliance partners, and outsourced services in t he industrial sector has
1047 led to a more complex situation with respect to the number of organizations and groups
1048 contributing to security of the industrial automation and control system.
1049 Tools to automate attacks are commonly available. The potential threa t from the use of these
1050 tools now includes cyber criminals and cyber terrorists who may have more resources and
1051 knowledge to attack an industrial automation and control system.
1052 The focus on unauthorized access has broadened from amateur attackers or disgru ntled
1053 employees to deliberate criminal or terrorist activities aimed at impacting large groups and
1054 facilities.
1055 The adoption of industry standard protocols such as Internet Protocol (IP) for communication
1056 between industrial automation and control systems an d field devices exposes these systems to
1057 the same vulnerabilities as business systems at the network layer.
1058 These and other trends have combined to significantly increase organizations risks associated with
1059 the design and operation of their industrial aut omation and control systems. At the same time,
1060 electronic security of industrial control systems has become a more significant and widely
1061 acknowledged concern. This shift requires more structured guidelines and procedures to define
1062 electronic security applicable to industrial automation and control systems, as well as the respective
1063 connectivity to other systems.
1064 4.5 Potential Consequences

1065 People who know the features and weaknesses of open operating systems and networks could
1066 potentially intrude into console devices, remote devices, databases, and, in some cases, control
1067 platforms. The consequences of intrusions into industrial automation and control systems may
1068 include:
1069 unauthorized access, theft, or misuse of confidential information

1070 publication of information to unauthorized destinations
1071 loss of integrity or reliability of process data and production information
1072 loss of system availability
1073 process upsets leading to compromised process functionality, inferior product quality, lost
1074 production capacity, compromised process safety, or environmental releases
1075 equipment damage

1076 personal injury
1077 violation of legal and regulatory requirements
1078 risk to public health and confidence
1079 threats to a nations security.
1080 4.6 Impact of Countermeasures
1081 Security countermeasures applied in an IACS environment should not have the potential to cause
1082 loss of essential services and functions, including emergency procedures. IACS security goals
1083 focus on control system availability, plant protection, plant operations (even in a degraded mode)
1084 and time-critical system response. General purpose security goals often do not place the same
1085 emphasis on these factors and may be more concerned with protecting information rather than
1086
physical assets. These different goals need to be clearly stated as secur ity objectives regardless
1087 of the degree of plant integration achieved.

1088 A key step in risk assessment, as required by ISA62443-2-1, is the identification of which services
1089 and functions are truly essential for operations. (For example, in some facilities engineering support
1090 may be determined to be a non-essential service or function.) It may be acceptable for a security
1091 action to cause temporary loss of a non-essential service or function, unlike an essential se rvice
1092 or function that should not be adversely affected.
1093 4.7 Requirements

1094 There are several general requirements that arise from the above situation.
1095 4.7.1 GEN x.x Support of Essential Functions

1096 4.7.1.1 Requirement
1097 Security measures shall not adversely affect essential fu nctions of a high availability IACS unless
1098 supported by a risk assessment.
1099 NOTE: Refer to ISA62443-2-1 regarding the documentation requirements associated with the risk assessment required
1100 to support instances where security measures may affect essential functions.
1101 4.7.1.2 Rationale
1102 When reading, specifying and implementing the normative requirements in this standard,
1103 implementation of security measures should not cause loss of protection, loss of control, loss of
1104 view or loss of other essential functions. After a risk analysis, some facilities may determine certain
1105 types of security measures may halt continuous operations, but security measures shall not result
1106 in loss of protection that could result in health, safety and environmental (HSE) consequences.
1107 Specifically;
1108 Access Controls (IAC and UC) shall not prevent the operation of essential functions, including:
1109 Accounts used for essential functions shall not be locked out, even temporarily.
1110 Verifying and recording operator actions to enforce non-repudiation shall not add significant
1111 delay to system response time.
1112 For high availability control systems, the failure of the certificate authority shall not interrupt
1113 essential functions.
1114 Identification and authentication shall not prevent the initiation of the SIF. Similarly for
1115 authorization enforcement.
1116 Incorrectly time stamped audit records shall not adversely affect essential functions.
1117 Essential functions of an IACS shall be maintained if zone boundary protection goes into fail-
1118 close and/or island mode.
1119 A denial of service (DoS) event on the control system or safety instrumented system (SIS)
1120 network shall not prevent the SIF from acting.
1121 4.7.2 GEN x.x Compensating countermeasures
1123 Compensating countermeasures shall be applied as necessary to improve the security of existing
1124 systems.

1126 Throughout the ISA62443 series normative language may state that the control system shall
1127 provide the capability to support some specific security requirement. If the control system does not
1128 have the inherent capability to meet such a requirement it is acceptable to employ an ex ternal
1129 component. In such a case, the control system shall provide an interface to that external
1130
component. Some examples of compensating countermeasures include user identification
1131 (including centralized versus distributed), password strength enforcemen t, signature validity

1132 checking, security event correlation and device decommissioning (information persistence).
1133 NOTE 1 The control system security requirements detailed in this document pertain to all technical functions relevant
1134 to a control system including tools and applications. However, as noted here, some of these functions can be handled by
1135 an external resource.
1136 NOTE 2 In some high resource availability applications (high SL -T(RA,control system)), compensating countermeasures
1137 external to the control system (such as additional physical security measures and/or enhanced personnel background
1138 checks) will be needed. In these cases, it may be possible to see a normally high resource availability SL control system
1139 at a lower IAC SL 1 or 2 rating, dependi ng upon the compensating countermeasures. Lockout or loss of control due to
1140 security measures is increased, not decreased for very high availability SL control system. Thus higher SLs are not
1141 always better, even where cost is not a significant factor.
1142
1143 5 Security Elements

1144 5.1 Introduction
1145 The analysis of a complex system often leads to the breakdown of its elements into the three broad
1146 categories of people, processes and technology, as shown in Figure 3.
1147 Revise this figure to be more similar to the one used by WG3TG3
Te
s
ch
es
no
oc
Pr
log
Security
y
People
1148
1149 Figure 3 Security Elements Grouping
1150 5.2 Category Descriptions

1151 Each of these categories must be addressed in order respond to the chall enges associated with
1152 IACS cybersecurity. Effective technology is of course important, but s trong processes can often
1153 help to overcome potential vulnerabilities in a security product, while poor implementation can
1154 render good technologies ineffective. Often, human weaknesses can diminish the effectiveness of
1155 technology.
1156 5.2.1 People

1157 In the context of IACS cyber security, this category includes the management, staff, contractors,
1158 and other personnel who develop, follow, implement, enforce, and manage all component s of the
1159 IACS cyber security program. It is important that all stakeholders and participants understand their
1160 roles and responsibilities, and positively support and promote security.
1161 Specific recommendations included in this category include:
1162 Relationships Make a concerted effort to break down the traditional relationship barriers
1163 between the Control and Business IT groups at all management levels of the organization. The
1164 goal is to have cooperative relationships across the different functional areas of t he company,
1165 and organizational levels. This also applies to the relationship between the Asset Owner and
1166 the Vendor or Integrator responsible for installing and maintaining the IACS.
1167 Intent, Buy-In, Support Ensure that all personnel have the intent and m otivation to uphold
1168 cyber security policies, practices, and ensure continual improvement. People must be entirely
1169

supportive of the security program.
1170 Resourcing It is essential to have the appropriate staffing levels and time commitment to
1171 perform the tasks associated with the IACS Security Management System (e.g. log revi ews,
1172 patching, risk assessment).
1173 Roles and Responsibilities Define who owns the process, who supports the process, and
1174 the respective responsibilities. There is a commonly used method for assigning those
1175 Responsible, Accountable, Consulted, and Informed (RACI) for each task of the process.
1176 Training and Capability Ensure that personnel are adequately qualified to perform the duties
1177 associated with IACS security, and that new capabilities are developed where they may not
1178 have existed in the organization before (e.g. risk analysis, security intelligence, vulnerabil ity
1179 management).
1180 Awareness and Influenced Decision Making Ensure that personnel have sufficient
1181 awareness and understanding of security policies and security processes as it will influence
1182 their decision making and voluntary use of these processes.
1183 A measurement of success for effectively addressing these issues is a culture of security within the
1184 organization with people motivated and active promoting adherence with security requirements.
1185 5.2.2 Processes

1186 The processes category includes the policies, procedures , forms, business processes, and other
1187 documentation associated with the IACS Security Management System. The objective is to
1188 establish business processes and associated task to be completed. Examples include management
1189 of change, access management, patching, inventory management, and security testing.
1190 Processes may be implemented in several ways, but are built upon smaller components of
1191 documentation.
1192 Policy This is a formal, brief, and high-level statement or plan that embraces an organization's
1193 general beliefs, goals, objectives, and acceptable procedures for a specified subject area.
1194 Standard This is a formal document that establishes mandatory requirements, engineering,
1195 technical criteria, methods, etc. A standard is meant to convey a mandatory acti on or rule and
1196 is written in conjunction with a policy.
1197 Process A process typically describes the act of taking something through an established
1198 and usually routine set of procedures or steps to convert it from one form to another, such as
1199 processing paperwork to grant physical or cyber access, or converting computer data from one
1200 form to another.
1201 Guideline These are not required as part of a policy framework, but they can play an important
1202 role in conveying best practice information to the user commun ity. Guidelines are meant to
1203 guide users to adopt behaviors which increase the security posture of a network, but are not
1204 yet required (or in some cases, my never be required).
1205 Definition of the specific structure and content of policies, standards, processes and guidelines is
1206 the responsibility of the IACS asset owner. The ISA62443 addresses the following subjects in this
1207 category:
1208 Security Policy

1209 Organization of Security
1210 Asset Management
1211 Human Resources Security
1212 Physical and Environmental Security
1213 Communications and Operations Management
1214 Access Control

1215 Systems acquisition, development and maintenance
1216 Incident Management
1217 Business Continuity Management
1218 Compliance
1219 For a traditional information system, requirements and details on each of these subjects can be
1220 found in ISO/IEC 27002 Code of Practice for Information Security Management. For an IACS
1221 Security Management System, the unique requirements and enhancements can be found in
1222 ISA62443-2-1 (Requirements for an IACS Security Management System).
1223 5.2.3 Technology

1224 This category includes all of the technical security capabilities and controls in place to ensure the
1225 availability, integrity, and confidentiality of the IACS. Thi s includes solutions for authentication,
1226 access control, encryption, as those technical measures are applied to reduce the security risks to
1227 the IACS. The objective of technology relative to IACS is to ensure that security risks are reduced
1228 and security-related business processes could be automated where feasible.
1229 Within the ISA62443 series, the technical security controls are grouped into a set of foundational
1230 requirements. These are described briefly in a later section of this standard. Additional detail is
1231 provided in ISA62443-3-3 (System Security Requirements and Security Levels). These
1232 foundational requirements are expressed in terms of IACS, and are robust enough c ategories to
1233 allow any security control or setting (e.g., firewall rules, running services) to have an appropriate
1234 category.
1235 5.3 Configuration Management Example

1236 Configuration management (including change control) is particularly important to assuring the
1237 security integrity, trust and confidence of the IACS. The seemingly subtle configuration changes
1238 within the control systems components could be excluded from change control processes because
1239 they are quick to perform and are assumed to have limited, controllable effects. However, these
1240 same changes can have drastic effects on the operability, reliability, and vulnerabilities associated
1241 with the IACS. Table 1 illustrates how strategies and solutions can be applied using the people-
1242 process-technology methodology.
1243 Table 1 Elements Applied to Change Control and Configuration Management
Category Application
People It is recommended that this subject is started first to have the greatest success.
- Obtain Senior Management support that all IACS changes must be authorized
and the adoption of security risk assessment into the change control process
is required.
- Identify those individuals in the organization who are accountable for ens uring
their business unit adheres to the change control process.
- Identify those responsible in the organization for supporting the change
control process and their respective roles.
- Communicate to and provide training to all participants of the change cont rol
process.
Processes This subject is started once strategies for people are in progress.
- Document the appropriate policy that all staff and contractors must follow

change control standards and procedures.
- Identify and update all existing change control processes to include review of
all IACS changes, and evaluation of its security risks.
- Develop training programs and sessions on the new processes and
procedures.
- Monitor and audit the success of the new program and adjust as needed.
Technology Technology may be considered to improve productivity, efficiency, and process
consistency.
- Develop technical requirements for the submission of change requests,
evaluation, approval, and evidence retention.
- Migrate proven change control procedures and forms into the technology
platform. Verify consistency with paper-based methods.
- Implement technology to identify and track configuration changes of all IACS
components, hardware, and software.
1244 This example is not a detailed plan for improving change control an d configuration management
1245 processes, but it effectively summarizes the importance of the people -process-technology triad.
1246 The three aspects of people, process and technology must be addressed simultaneously in order
1247 to have the greatest success.
1248 In the following sections each of the principles of people, process and technology are further
1249 defined and their subjects identified.
1250 5.4 Summary

1251 Now that the concepts of people, processes, and technology are clearly defined; they can now be
1252 visualized with their respective subject areas. The core and foundational principle of the IACS
1253 Security Management System is the people-process-technology triad.
C)
ol (A
o ntr
Fo
sC
un
s
ce
da
Ac
tio
a nd
na
ion
lR
s
t
e
tica
us
eq
Or Se
ga en
Cla
uir
niz cu uth
em
ati ri ty A
Co on Po n,
en
Ph o
mm Hu As of licy ati
ts
ysi
u nic ca
la
ma
nR
se
tM Se
cu n tific C )
Sy a Ide
st tio nd es an rity l (U
em ns En ou a ge tro )
s ac an
dO vir rce me C on (SI
qu on sS nt se ri ty
isit pe me ec U eg )
ion rat nta uri Int DC
i on lS ty y(
,d
ev s e st em alit
elo Ma cu
rity Sy nti )
na ide F
Te
pm Ac ge f RD
n
w( E)
en ce me Co
ss
ta s ta lo (TR
ch
Bu s n t t
sin nd Co Da aF en
e
Inc ma t
es ntr Da Ev
no
ide
oc
sC nt int ol ict to
on Ma en str se
an n )
Re
Pr
tin
log
uit n ce po RA
yM ag es (
em R ility
an en Security ely ilab
y
ag t Tim
em A va
Co en
mp t rce
lian ou
s
Re
ce
People
Resourcing
Relationships
Intent, Buy-In, Support
Training and Capability
Decisions and Awareness

Roles & Responsibilities

1254 Not part of ISA-62443 series of documents
1255 Figure 4 Implementation of People, Process, and Technology
1256 The technical requirements associated with IACS security are prescribed by the ISA62443
1257 standards commensurate with the Security Level (SL) assigned to each zone and conduit. The
1258 Foundation Requirements defined in ISA62443-1-1 are the categories used to organize these
1259 technical security controls, and set the foundation for other ISA62443 normative requirements.
1260 The policy and procedure (process) requirements build on those containe d in the ISO/IEC 27000
1261 series, with specific requirements unique to IACS.
1262 The personnel and resource (people) requirements associated with an IACS Security Management
1263 System are outside the scope of ISA62443. Although it is considered extremely important, the
1264 outputs of ISA62443 shall continue to be focused on technical and process requirements. Readers
1265 are advised to research and study topics such as organizational behavior, instituting change, and
1266 other business sociology and leadership materials.
1267 Each of these essential elements are reflected in a description of cyber security related concepts.
1268 These concepts in turn are broken into two groups. The first group includes the concepts that are
1269 applicable to virtually any cyber security response, while the second group includes concepts that
1270 are specific or unique to the industrial automation and control systems environment. Each of these
1271 groups are described in subsequent clauses.
1272
1273 6 IACS Definition
1274 In order to fully articulate the systems and components the ISA62443 standards address, the range
1275 of coverage may be described from several perspectives, including:
1276 1) range of functionality included

1277 2) systems and interfaces
1278 3) criteria for selecting included activities
1279 4) criteria for selecting included assets
1280 5) consequence based criteria
1281 Each of these is described in the following paragraphs.
1282 6.1 Functionality Included

1283 The scope of IACS security can be described in terms of the range of functionalit y within an
1284 organizations information and automation systems. This functionality is typically described in terms
1285 of one or more models.
1286 This standard is focused primarily on industrial automation and control, as described in a reference
1287 model. Industrial automation and control includes the supervisory control components typically
1288 found in process industries, as well as SCADA (supervisory control and data acquisition) systems
1289 that are commonly used by organizations that operate in critical infrastructure in dustries. These
1290 include:
1291 a) electricity transmission and distribution
1292 b) gas and water distribution networks

1293 c) oil and gas production operations
1294 d) gas and liquid transmission pipelines
1295 This is not an exclusive list. SCADA systems may also be found in other critical and non-critical
1296 infrastructure industries.
1297 While business planning and logistics systems are not explicitly addressed within the scope of this
1298 standard, the integrity of data exchanged between business and industrial systems is considered.
1299 6.2 Systems and Interfaces

1300 It is also possible to describe the IACS in terms of connectivity to associated systems. In
1301 encompassing all industrial automation and control systems, this standard covers systems that can
1302 affect or influence the safe, secure, and reliable operati on of industrial processes. They include,
1303 but are not limited to:
1304 1) Industrial control systems and their associated communications networks, including
1305 distributed control systems (DCSs), programmable logic controllers (PLCs), remote
1306 terminal units (RTUs), intelligent electronic devices, SCADA systems, networked electronic
1307 sensing and control, metering and custody transfer systems, and monitoring and diagnostic
1308 systems. In this context, industrial control systems include basic process control system
1309 and safety-instrumented system (SIS) functions, whether they are physically separate or
1310 integrated.
1311 2) Associated systems at level 3 or below of the Reference Model. Examples include advanced
1312 or multivariable control, online optimizers, dedicated equipment monitors , graphical
1313 interfaces, process historians, manufacturing execution systems, pipeline leak detection
1314 systems, work management, outage management, and electricity energy management
1315 systems.
1316 3) Associated internal, human, network, software, machine or device in terfaces used to
1317 provide control, safety, manufacturing, or remote operations functionality to continuous,
1318 batch, discrete, and other processes.
1319 6.3 Activity-Based Criteria
1320 The ANSI/ISA-95.00.03 standard defines a set of criteria for defining activities associ ated with
1321 manufacturing operations. A similar list has been developed for determining the scope of this
1322 standard. A system should be considered to be within the range of coverage of these standards if
1323 the activity it performs is necessary for any of the fo llowing:
1324 1) predictable operation of the process

1325 2) process or personnel safety
1326 3) process reliability or availability
1327 4) process efficiency

1328 5) process operability
1329 6) product quality
1330 7) environmental protection
1331 8) compliance with relevant regulations
1332 9) product sales or custody transfer affecting or influencing industrial processes.
1333 6.4 Asset-Based Criteria
1334 The coverage of this standard includes industrial automation and control systems that has -assets
1335 that meet any of the following criteria, or whose security is essential to the protection of other
1336
assets that meet these criteria:
1337 1) The asset is necessary to maintain the economic value of a manufacturing or operating
1338 process.

1339 2) The asset performs a function necessary to operation of a manufacturing or operating
1340 process.
1341 3) The asset represents intellectual property of a manufacturing or operating process.
1342 4) The asset is necessary to operate and maintain security for a manufacturing or operating
1343 process.
1344 5) The asset is necessary to protect personnel, contractors, and visitors involved in a
1345 manufacturing or operating process.
1346 6) The asset is necessary to protect the environment.
1347 7) The asset is necessary to protect the public from events caused by a manufacturing or
1348 operating process.
1349 8) The asset is a legal requirement, especially for security purposes of a manufacturing or
1350 operating process.
1351 9) The asset is needed for disaster recovery.
1352 10) The asset is needed for logging security events.
1353 This range of coverage includes systems whose compromise could result in the endangerment of
1354 public or employee health or safety, loss of public confidence, violation of regulatory requirements,
1355 loss or invalidation of proprietary or confidential information, environmental contamination, and/or
1356 economic loss or impact on an entity or on local or national security.
1357 6.5 Consequence-Based Criteria

1358 The coverage of this standard includes industrial automation and control systems whose
1359 compromise could result in any or all of the following situations:
1360 1) endangerment of public or employee safety

1361 2) environmental protection
1362 3) loss of public confidence
1363 4) violation of regulatory requirements
1364 5) loss of proprietary or confidential information
1365 6) economic loss
1366 7) impact on entity, local, state, or national security

1369 6.6.1 GEN x.x Risk Assessment

1371 During all phases of the systems life cycle, cybersecurity risk assessments shall include a
1372 determination of where and what could go wrong to disrupt IACS operations, what is the likelihood
1373 that a cyber-attack could initiate such a disruption, and what are the consequences that could
1374 result.
1376 The output from this determination shall include sufficient information to help the ordinary user (not
1377 necessarily security-conscious ones) to identify and determine the releva nt security properties.
1378 The method of determination shall include a decomposition of a system under consideration in

1379 accordance with the specifications in ISA62443-3-2 and make visible the interaction between
1380 individual components. Functional relationships and the models used to translate the security
1381 strength of lower level components into aggregated measures shall be delineated to the degree
1382 necessary to determine the response action in accordance with the spec ifications in ISA62443-1-
1383 3.
1384
1385 7 Principal Roles

1386 7.1 General
1387 The People element of a cybersecurity management is addressed through the definition and
1388 consistent application of a set of common role descriptions. These descriptions define the specific
1389 accountability and responsibilities of each role, as well as the relationships and dependencies
1390 between roles.
1391 7.2 Role Descriptions

1392
1393 7.2.1 Organizational roles
1394 Should we include RACI chart(s) here? As a minimum we have to emphasize the difference between accountability and
1395 responsibility. We could use RACI as a tool to aid in our discussions.
Industrial Automation and Control System (IACS)

operates
Asset Owner Operational policies and procedures
maintains
Maintenance Provider Maintenance policies and procedures
+
Automation Solution
designs and deploys
Integration Provider
BPCS SIS HW/SW
IACS environment (product specific)
Is the base for

designs and supports Control System
control systems as a combination of components
Product Supplier
develps and supports Embedded Network Host
Applications
components Devices Compents Devices
develops capabilities
Service Provider to provide Integration and Maintenance Services
Independent of IACS environment

1396
1397 Figure 5 Organizational Responsibilities
1398 The organizational roles shown in figure 5 are defined as follows:
1399 Asset Owner This is the person or organization that has primary accountability for the IACS and
1400 its security. Responsibilities include the identification of the consequence component of risk, and
1401 the consistent operation of the cybersecurity management system.
1402 Asset Operator This is the person or organization that is accountable for the operation of the
1403 system under consideration. This may or may not be the same entity as the Asset Owner. For
1404 example, the Asset Owner may be different in situations involving some sorts of joint ventures or
1405 similar business structures.
1406 Maintenance Provider
1407
1408 Integration provider It is common for an automation solution to be designed and configured by
1409 an independent or external system integrator, according to specifications and requirements
1410 provided by the asset owner.
1411 Product Supplier The principal responsibility of the product supplier is to design and provide the
1412 specific components that are used to assemble the IACS.
1413 Service Supplier Ensuring the security of an IACS also requires services throughout the life
1414 cycle, including regular maintenance and system updates.
1415 7.2.2 Regulatory Organizations

1416 In some industries there may be additional requirements and constraints as a result of external
1417 regulations. Compliance to these requirements are typically confirmed by an external, independent
1418 party.
1419 Regulatory Authority
1420 Compliance Authority Organizations in this role include government agencies and regulators
1421 with the legal authority to perform audits to verify compliance with governing laws and regulations.
1422 7.2.3 Asset owner functions
1423 Within an asset owner organization there are several functions or departments that may play a role
1424 in the identification, specification, operation and support of the IACS. These are described in the
1425 following paragraphs.
1426 Asset owner and asset operator may be very different. The main distinction may be in ultimate accountability for

1427 performance (e.g, production, safety, etc.)
1428 Business defines case for investment and tangible asset owner of record
1429 Finance obtains funding and tracks asset value
1430 Procurement negotiates and purchases assets
1431 Engineering specifies equipment design and installs equipment
1432 Operations asset custodian which uses equipment to convert materi als into finished goods
1433 Scheduling aligns customer orders with available equipment
1434 Maintenance sustains the integrity and reliability of procured assets

1437 7.3.1 Individuals

1438 End user
1439 Administrator
1440 Planner/Developer
1441 Visitor
1442 Supervisor
1443 Process control engineer
1444 IT specialist
1445 Process safety engineer
1446 Process engineer
1447 7.3.2 GEN x.x Role descriptions

1449 The cybersecurity management system shall include the definition and consistent application of a
1450 set of common role descriptions.

1452 These descriptions define the specific accountability and responsibilities of each role, as well as
1453 the relationships and dependencies between roles.
1454
1455 8 Models
1456 8.1 General
1457 The basis for identifying the security needs and important characteristics of the environment at a
1458 level of detail necessary to address security issues can expressed as a series of models, each of
1459 which is described in the following paragraphs.
1460 8.2 Reference Model
1461 A reference model establishes a frame of reference for the more detailed information that follows.

1462 It describes a generic view of an integrated manufacturing or production system, expressed as a
1463 series of logical levels. The reference model used by the ISA62443 series of standards appears
1464 in figure 6. This model is derived from the general model used in ANSI /ISA-95.00.01-2000,
1465 Enterprise-Control System Integration Part 1: Models and Terminology.
Enterprise Systems
Level 4
(Engineering, Business Planning & Logistics)
Operations / Systems
Level 3 Management
Supervisory Control
Level 2
Site Monitoring & Local Display
Industrial Automation
and Control Systems
Level 1 Basic Control
Safety and Protection
Level 0 Process
(Equipment Under Control)
1466
1467 Figure 6 Reference Model
1468 Detailed descriptions of each of the levels in this model are provided in ANSI/ISA-95.00.01-2000,
1469 Enterprise-Control System Integration Part 1: Models and Terminology, and summarized in the
1470 following paragraphs.
1471 Level 4 (Enterprise Business Systems) This level includes the functions involved in the
1472 business-related activities needed to manage a manufacturing organization. For the purposes
1473 of this standard, engineering systems are also considered to be in this level.
1474 Level 3 (Operations Management) This level includes the functions involved in managing
1475 the work flows to produce the desired end products. Examples include dispa tching production,
1476 detailed production scheduling, reliability assurance, and site -wide control optimization.
1477 Level 2 (Supervisory Control) This level includes the functions involved in monitoring and
1478 controlling the physical process. There are typically multiple production areas in a plant or
1479 facility.
1480 Level 1 (Local or Basic Control) This level includes the functions involved in sensing and
1481 manipulating the physical process. Process monitoring equipment reads data from sensors,

1482 executes algorithms if necessary, and maintains process history. It includes continuous control,
1483 sequence control, batch control, and discrete control. Equipment at this level includes, but is
1484 not limited to DCS controllers, PLC and RTUs.
1485 Also included in Level 1 are safety and protection systems2 that monitor the process and
1486 automatically return the process to a safe state if it exceeds safe limits. This category also
1487 includes systems that monitor the process and alert an operator of impending unsafe conditions.
1488 Safety and protection systems often have additional safety requirements that may not be
1489 consistent or relevant to cyber security requirements. These systems include the safety systems
1490 in use in chemical and petrochemical plants as identified in the ANSI/ISA -84 series of
1491 standards, nuclear plant safety or safety-related systems as identified in the ANSI/ISA-67
1492 series, and protective functions as identified in IEEE Power Engineering Society standards.
1493 Level 0 (Process) This level is the actual physical process, which includes a number of
1494 different types of production facilities in all sectors including, but not limited to, discrete parts
1495 manufacturing, hydrocarbon processing, product distribution, pharmaceuticals, pul p and paper,
1496 and electric power. It includes the sensors and actuators directly connected to the process and
1497 process equipment.
1498 8.3 Physical Architecture Model
1499 A physical architecture model is used to describe the various operational components and how they
1500 are connected. The details are specific to each individual system under consideration. It is common
1501 for an organization to have a single generic model that has been generalized to cover all operating
1502 facilities. An example of a simplified reference architect ure model for a manufacturing function is
1503 shown in Figure 7.

2 These systems are referred to as safety instrumented systems in standards such as the ANSI/ISA-84 series.
Enterprise
Laptop
Workstation Mainframe Server Server
computer
Plant A Plant B Plant C

Router Router Router
Laptop Laptop Laptop

Workstation Workstation Workstation
computer computer computer
File/Print App. Data File/Print App. Data File/Print App. Data
Server Server Server Server Server Server Server Server Server
Firewall Firewall Firewall
Plant A Control System Plant A Control System Plant A Control System

App. Data Maint. App. Data Maint. App. Data Maint.
Controller Controller Controller Controller Controller Controller
I/O I/O I/O I/O I/O I/O

1504
1505 Figure 7 Physical Architecture Model Example
1506 8.4 Zone Model

1507 A zone model is derived from the physical architecture model. The assets are groupe d into entities
1508 (e.g., business, facility, site, or IACS) that are then analyzed for security policies and hence
1509 requirements. Figure 8 is an example of a zone model.
E-Commerce Enterprise Firewall
Internet
Enterprise
Enterprise Infrastructure
Zone Web Server
Enterprise WLAN
uit
File Server
Cond
Inventory
Terminal Services / Management
Data Historian Mirror Router/
Firewall

Industrial/
Enterprise
DMZ Zone
Managed
Switch(es)
Domain Controller, Anti-Virus,
Patch Management
Manufacturing Execution
System (MES)
uit
Cond
PLC Router/
Firewall Local
Switch
Industrial
Network #1 HMI
Legacy/Fieldbus
...
Field Devices
1510
1511 Figure 8 Zone Model Example
1512 This model provides the context for assessing common threats, vulnerabilities, and the
1513 corresponding countermeasures needed to attain the level of security required to protect the
1514 grouped assets. After grouping assets in this manner, a security policy is defined for all assets that
1515 are members of the zone. This results of this analysis is used to determine the appropriate
1516 protection required based on the activities performed in the zone.
1517 The ISA62443-3-2 standard describes the above process in more detail.

1519 There are several general requirements related to the use of models
1520 8.5.1 GEN x.x Reference Model

1522 The asset owner shall describe the logical arrangement of system elements in the co ntext of an
1523 established reference model.
1525 The use of known or established reference models as the basis for the logical design aids in
1526 communication or concepts and requirements with stakeholders.
1527 8.5.2 GEN x.x Physical Architecture Model

1529 The asset owner shall create and maintain one or more physical architecture models depending on
1530 the business functions performed, as well as the functions under review.

1532 The physical architecture model provides a framework or context for the ident ification of all assets,
1533 as well as the connections between them.
1534 8.5.3 GEN x.x Zone Model

1536 The asset owner shall use zones and conduits as a means of segmenting the network infrastructure
1537 for the purpose of risk assessment.

1539 In all but the simplest of configurations there is a potential or need to determine different levels of
1540 risk for subsets of the infrastructure. The identification of zones and conduits is the first step in this
1541 process.
1542
1543 9 General Concepts

1544 There are several general concepts that are important in the field of cyber security, irrespective of
1545 the scope of application. The purpose of this clause is to provide a n informative overview of those
1546 concepts.
1547 9.1 Security Context

1548 The security context forms the basis for the interpretation of terminology and concepts and shows
1549 how the various elements of security relate to each other. The term security is considered here to
1550 mean the prevention of illegal or unwanted penetration of or interference with the proper and
1551 intended operation of an industrial automation and control system. Electronic security includes
1552 computer, network, or other programmable components of the system.
1553 The context of security is based on the concepts of threats, risks, and countermeasures, as w ell as
1554 the relationships between them. The relationship between these concepts can be shown in a model
1555 such as the one described in the international standard ISO/IEC 15408 -1 (Common Criteria) [2]. It
1556 is reproduced in Figure 9.
value
Owners wish to minimize
impose
Countermeasures
Threat Agents To
reduce
Risk
to
that increase
Threats to Assets
give rise to

wish to abuse and/or may damage
1557
1558 Figure 9 Context Element Relationships
1559 A different view of the relationship is shown in Figure 10, which shows how an expanded set of
1560 concepts are related within the two interconnected proc esses of information security assurance
1561 and threat-risk assessment.
Information Security
Assurance
Assurance
Evaluation
Techniques
Threat-Risk
produce gives evidence of Assessment
Assurance
Owners Threats
require
Confidence using
Vulnerabilities
in
require
Countermeasures
to minimize
Risk
to
Assets
1562
1563 Figure 10 Context Model
1564 9.2 Security Objectives

1565 Information security has traditionally focused on achieving three objectives, confidentiality,
1566 integrity, and availability, which are often abbreviated by the acronym CIA. An information
1567 technology security strategy for typical back office or business systems may place the primary
1568 focus on confidentiality and the necessary access controls needed to achieve it. Integrity might fall
1569 to the second priority, with availability as the lowest.
1570 In the industrial automation and control systems environment, the general priority of these
1571 objectives is often different. Security in these systems is primarily concerned with maintaining the
1572 availability of all system components. There are inherent risks associated with industrial machinery
1573 that is controlled, monitored, or otherwise affected by industrial automation and control systems.
1574 Therefore, integrity is often second in importance. Usual ly confidentiality is of lesser importance,
1575 because often the data is raw in form and must be analyzed within context to have any value.
1576 The facet of time responsiveness is significant. Control systems can have requirements of system
1577 responsiveness in the 1 millisecond range, whereas traditional business systems are able to
1578 successfully operate with single or multiple second response times.
1579 9.3 Least Privilege
1580 The principle of least privilege means giving a user or application only those privileges which are
1581 essential to complete the necessary tasks. When applied to users, the terms least user access or
1582 least-privileged user account (LUA) are also used, referring to the concept that all user accounts
1583 at all times should run with as few privileges as possible, an d also launch applications with as few
1584 privileges as possible.

1585 9.4 Defense in Depth
1586 It is typically not possible to achieve the security objectives through the use of a single
1587 countermeasure or technique. A superior approach is to use the concept of defense in depth, which
1588 involves applying multiple countermeasures in a layered or stepwise manner. For example,
1589 intrusion detection systems can be used to signal the penetration of a firewall.
1590 9.5 Threat-Risk Assessment

1591 Within the threat-risk assessment process, assets are subject to risks. These risks are in turn
1592 minimized through the use of countermeasures, which are applied to address vulnerabilities that
1593 are used or exploited by various threats. Each of these elements is described in more detail in this
1594 clause.
1595 9.6 Policies and Procedures

1596 This section needs to be edited to condense the material. The target is to reduce it to one page or less. Some of the
1597 content may be suitable for the normative section describing the use of policy as part of a CSMS.
1598 9.6.1 General

1599 The definitions in the Processes sub-clause have to be consistent with the information below.
1600 If the objective is to reduce this section to one page or less, consider extracting good information from this section and
1601 moving it to the sub-clause Processes.
1602 Security policies enable an organization to follow a consistent program for maintaining an
1603 acceptable level of security. Policies are defined at different levels in an organization, ranging from
1604 governance or management policies established at the enterprise level to operation policies
1605 defining the details of security administration. Policies at the most specific level are the
1606 organization's standard against which security audits can measure compliance.
1607 A security policy is a formal, brief, and high-level statement or plan that embraces an organizations
1608 general beliefs, goals, objectives, and acceptable procedures that specify or regulate how an
1609 organization protects sensitive and critical system resources. Policies unambiguously state what is
1610 mandatory. Because policies are mandatory and unambiguous, they make audits possible. The
1611 organization's security policies also take into account legal, regulatory, and contractual obligations.
1612 They are the measuring stick against which audits test the actual practices of the organization.
1613 Complementing policies are standards and procedures. A standard is a formal document that
1614 establishes mandatory requirements, engineering, technical criteria, methods, etc. A standard is
1615 meant to convey a mandatory action or rule and is writt en in conjunction with a policy. A process
1616 or procedure document may also be called a standard, which typically describes the act of taking
1617 something through an established and usually routine set of procedures or steps to convert it from
1618 one form to another, such as processing paperwork to grant physical or cyber access, or converting
1619 computer data from one form to another. Security procedures define in detail the sequence of steps
1620 necessary to provide a certain security measure.
1621 Contrasting with policies, standards and procedures are guidelines. Guidelines are not mandatory.
1622 They are intended to describe a way to do something that is desirable but not mandatory and are
1623 not a required element of a policy framework; however, they can play an important role in conveying
1624 best practice information to the user community. Guidelines are meant to guide users to adopt
1625 behaviors which increase the security posture of a network, but are not yet required (or in some
1626 cases, my never be required). Because guidelines are not mandatory and may be ambiguous,
1627 practices cannot be audited against guidelines. Guidelines are sometimes written by a group that
1628 does not have the authority to require them to be followed. Guidelines are inappropriate to describe
1629 practices that are mandatory.
1630 In an attempt to reduce the size of this section, the following paragraph could be discarded.
1631 Because the policies, standards and procedures for different parts of an organization are often
1632 different, it is important that they be adequately coor dinated. Specifically, the security policy for

1633 IACS must be coordinated with similar policies for general purpose IT security. The security
1634 program will work more successfully if there are good working relationships among the parties, and
1635 a well-coordinated set of policies can support good relationships.
1637 Some consistency to the structure of the various policies, standards and procedures increases the
1638 coherence of the overall set of policies and procedures. Each policy or procedure document has a
1639 short but precise statement of its purpose. It also has a statement of scope that defines where the
1640 document applies. It has a description of the risks that it is intended t o reduce and of the key
1641 principles of the document. These common items guide the reader by providing more information
1642 about the intention of the policy or procedure. They also describe the intent of the document to
1643 provide guidance, which is useful when the document needs to be revised.
1645 Different phases in a systems life cycle have different profiles of security issues. Security policies
1646 and procedures may address only certain life cycle phases. Some policies and procedures may
1647 specify that they only pertain to certain phases. All of the security concerns from all of the various
1648 phases are addressed in corresponding places in the set of security policies and proced ures.
1649 Security policies, standards and procedures contain instructions on how the organization will
1650 measure compliance and update the policies. Organizations often recognize that policies need to
1651 be updated when performing or evaluating audits. Audits may identify ambiguities in policies and
1652 procedures as well as parts of policies and procedures that do not make the required process or
1653 outcome clear. Audits can identify issues that should be added to policies and procedures. Audits
1654 may also identify requirements that should be reevaluated and adjusted or possibly retracted.
1655 Policies, standards and procedures should allow for unforeseen circumstances that make it
1656 infeasible to follow them. Policies should also state how to document and approve exceptions to
1657 policies and procedures. Documenting approved exceptions leads to a clearer state of security than
1658 leaving imprecision and ambiguity in the policies and procedures.
1659 In addition, organizations should be unambiguous about what is a requirement versus what is
1660 optional advice in a policy or standard. Precise use of words like shall, must, may, and is
1661 removes the ambiguity. Policy statements can define these words in their introduction sections to
1662 be more precise. Shall and must are used for requireme nts. May is used for advice that is
1663 optional, and therefore is not used in the mainstream of policies and procedures. It can be
1664 appropriate to provide options for addressing a requirement. Phrases like when possible or
1665 unless necessary introduce ambiguity unless the statement also describes how to determine
1666 whether the case is possible or necessary.
1667 Responsibilities are not always found in policy documents. They may be found in standards and procedures, as well as
1668 stand-alone RACI charts.
1670 Policies, standards and procedures identify who is responsible for what. Is the process control staff
1671 responsible for the control network? Is it responsible for a demilitar ized zone (DMZ) between the
1672 control network and the enterprise network? If an enterprise information systems department is
1673 responsible for conditions that require the process control staff to perform certain operations, then
1674 these operations should be described.
1675 For an organization that is just starting to create its security program, policies and standards are a
1676 good place to begin. Initially, they can be written to cover the set of security practices that the
1677 organization is equipped to handle in the nea r term. Over time they can be revised and tightened
1678 as the organization's capability grows. They can be put in place without the lead time of procuring
1679 and installing systems and devices.
1680 9.6.2 Enterprise Level

1682 The policy at the enterprise level mandates the security program and sets the direction. It states
1683 the organization's overall security objectives.
1684 The policy statement of top management should be circumspect enou gh to remain pertinent and
1685 accurate through changes in the structure of the organization, changes in system and security
1686 technology, and changes in the kinds of security threats. By being circumspect, the policy can be
1687 stable and will need to be rewritten only when the organization's basic position on security changes.
1688 However, the policy statement is also unambiguous; it clearly identifies what is required.
1689 The enterprise level policy identifies areas of responsibility and assigns accountability for those
1690 areas. The policy can define the relationship between the enterprise IT department and plant
1691 operations and identify their different responsibilities. The policy can differentiate security
1692 objectives of the control system from those of the enterprise netwo rk. For example, maintaining
1693 confidentiality may be a top consideration of security for the enterprise network, whereas
1694 maintaining continuous operation may be a top consideration for the control system.
1695 In addition, the policy identifies particular standa rds and regulations that apply to the organization.
1696 It may identify training as an important component of the security program. The policy may also
1697 indicate the consequences for policy violations.
1698 Management should communicate the policy throughout the org anization so that all employees
1699 understand it.
1700 9.6.3 Operational Level

1702 Operational policies, standards and procedures are developed at lower levels of the organization
1703 to specify how the enterprise level policy is implemented in a specific set of circumstances. Security
1704 standards and procedures put the policy into effect. They define what the organization will do to
1705 achieve the objectives and to meet the requirements of the policy. The procedures establish
1706 processes that will address all the concerns of the policy.
1707 The standards and procedures address all components needed in a security program, including:
1708 a) system design

1709 b) procurement
1710 c) installation
1711 d) process operation
1712 e) system maintenance

1713 f) personnel
1714 g) audit
1715 h) training
1716 The standards and procedures identify specific activities, who is accountable for their performance,
1717 and when activities will be performed.
1718 The written procedures describe the process by which they will be changed when th e situation
1719 changes. Each policy, standard or procedure has an identified owner responsible for recognizing
1720 when updates are needed and for ensuring they are made.
1721 The effectiveness of policies, standards and procedures should be measured to check whether they
1722 serve their intended purpose. The cost to the organization should also be measured, so the
1723 organization can determine whether the balance of risk reduction aligns with the cost to implement
1724 the policies. If the balance is unacceptable, the policy and procedures may have to be adjusted.

1725 Procedures also have to be updated to reflect changes in technology.
1726 Procedures are able to support audits. A security audit compares the observed actions of the
1727 organization against the written procedures.
1728 9.7 Topics Covered by Policies and Procedures

1729 In an attempt to reduce the size of this section, this section could be discarded. If this section remains, the list of topic s
1730 should have alignment with other parts of ISA -62443. Such as the list of Clauses in ISO -27000 and ISA-62443-2-1.
1731 On 2012-12-30 it was raised that this section should match other sections, most notably to ensure it corresponds to
1732 section 7.4. It has been asked that either section 5.7 or 7.4 is changed.
1733 There are several topics that policies and procedures can cover. Every organization is different and
1734 should determine the appropriate policies and procedures that are applicable for its industrial
1735 automation and control systems. Possible topics include:
1736 Risk Management Risk management is vital to developing a cost-effective security program that
1737 provides a uniform layer of adequate security, but that does not require equipment or procedures
1738 that are too costly and significantly beyond the range of adequate security. However, risk
1739 management is complex and needs to be tailored to the organization. The policy on risk
1740 management defines how an acceptable level of risk is determined and how to control the risk. This
1741 level varies depending upon the goals and circumstances for a particular organization. The process
1742 for determining risk level should be repeated periodically in order to accommodate changes to the
1743 environment.
1744 Access Management Security is improved in a system by restricting access to only those users
1745 who need and are trusted with the access. Access management policy identifies different roles of
1746 users and what kind of access each role needs to each class of asset (physical or logical). It
1747 specifies the responsibilities of employees to protect the assets and of administrators to maintain
1748 access management procedures. Authorization for these access privileges should have well -
1749 documented approval by management and be periodically reviewed. Access management may be
1750 as important or even more important to system integrity and availability as the need to protect data
1751 confidentiality.
1752 Availability and Continuity Planning Policies in this area provide the necessary framework and
1753 requirements expectations for backup and recovery, as well as business continuity and disaster
1754 recovery planning. They also define archiving characteristics (e.g., how long must data be
1755 retained).
1756 Physical Security The security of the control system depends upon the physical security of the
1757 space that contains the control system. The plant site may already have a physical security policy
1758 before the security policy is written for the control system. However, policies related to systems
1759 physical access may differ from those involving non-systems assets. For instance, all oil refinery
1760 personnel may have general access to almost all facilities within the plant fences, but IT
1761 infrastructure rooms may need to have access limited to only IT -related personnel if for no other
1762 reason than to prevent accidental damage. The control system security policy should include a
1763 reference to the physical security policy and state its dependency. The security policy for the control
1764 system must contain enough specifics on physical security to make any specific application of the
1765 site physical security policy to the control system. For example, some equipment must be in locked
1766 cabinets, and the keys must be kept in a restricted place.
1767 Architecture Policies and procedures describe secure configurations of control systems including
1768 such issues as:
1769 a) recommended network designs
1770 b) recommended firewall configuration
1771 c) user authorization and authentication

1772 d) interconnecting different process control networks
1773 e) use of wireless communications
1774 f) domains and trust relationships
1775 g) patch management (including authentication)
1776 h) anti-virus management
1777 i) system hardening in terms of closing software ports, disabling or avoiding unused or
1778 dangerous services, and disabling the use of removable storage devices
1779 j) access to external networks (i.e., the internet)
1780 k) appropriate use of e-mail.
1781 Portable Devices Portable devices pose all the security risks of stationary equipment, but their
1782 mobility makes it less likely that they will be covered by the normal security procedures from
1783 installation to audit. Their portability provides additional opportunities for corruption while outside
1784 physical security zones or for interception of information while connecting to secure zones. Thus,
1785 a special policy is often needed to cover portable devices. The policy should require the same
1786 security protection as a stationary device, but the technical and ad ministrative mechanisms that
1787 provide this protection may differ.
1788 Wireless Devices and Sensors Control equipment using radio frequency transmission in place of
1789 wires has been widely used in certain control system applications for many years. As costs
1790 decrease and new standards emerge, potential applications in automation and control systems
1791 continue to expand, in part due to lower installation costs. A key difference between wired and
1792 wireless devices is that in the latter case signals are not confined wit hin a physical security
1793 boundary, making them more prone to interception and corruption. Therefore, a security policy
1794 specific to wireless devices is appropriate for organizations that currently use or may in the future
1795 deploy wireless devices or sensors in their operations. The policy may specify which applications
1796 can use wireless devices, what protection and administrative methods are required, and how wired
1797 and wireless networks are interconnected.
1798 Remote Access Remote access bypasses the local physic al security controls of the boundaries
1799 of the system. It extends access to the trusted zone to a completely different geographic location
1800 and includes a computer that may not have undergone the security checks of the computers that
1801 are physically in the area of the trusted zone. Different mechanisms are required to provide the
1802 same level of security as the trusted zone.
1803 Personnel Personnel issues are likely to be defined in the enterprise personnel and IT security
1804 policies. The control system security policy provides specifics, whereas the more general policies
1805 do not include control system aspects. For example, the control system security policies coordinate
1806 control system access roles with personnel screening and monitoring practices.
1807 Subcontractor Policy Security issues include work that may involve subcontractors in roles such
1808 as supplier, integrator, maintenance service provider, or consultant. A security policy that covers
1809 subcontractors addresses the interactions with the subcontractor that could o pen vulnerabilities.
1810 The policy identifies the responsibilities of the different parties. It addresses the changing
1811 responsibilities as projects progress through their phases and as materials and systems are
1812 delivered. The policy may require certain terms to be written into contracts with subcontractors.
1813 Without proper management of contract programmers, application integrity may be compromised
1814 or programming code may not be maintainable. It is important to find well -qualified contract
1815 programmers who will follow your programming and documentation standards and perform
1816 adequate testing, as well as being trustworthy and timely.
1817 Auditing The security of the system is audited regularly to measure the degree of compliance with
1818 the security policies and practices. The security policy addresses the need for audits and specifies
1819 the responsibility, the regularity, and the requirement for corrective action. A comprehensive
1820 auditing process may address aspects other than security, such as process efficiency and

1821 effectiveness, and regulatory compliance.
1822 Security Policy Updating The security policy is monitored to determine changes needed in the
1823 policies themselves. Monitoring security policy is a part of each policy and procedure document,
1824 and the enterprise security policy sets forth the overall approach. Each operational policy and
1825 procedure document contains a statement of when and by whom the policy or procedure itself is to
1826 be reviewed and updated.
1827 Training Training programs should be in place for new hires, o perations, maintenance, upgrades
1828 and succession planning. Training programs should be well documented, structured, and updated
1829 at regular intervals to incorporate changes in the operating environment.
1830 9.8 Supply Chain Security

1831 This sub-clause is reserved for a general discussion on supply chain security, including any references to other standards
1832 in the series that may address aspects of the subject .
1833 Supply chain cybersecurity refers to efforts to enhance cybersecurity within the supply chain. It is
1834 a subset of supply chain security and is focused on the management of cybersecurity requirements
1835 for information technology systems, software and networks, which are driven by threats such as
1836 cyber-terrorism, malware, data theft and the advanced persistent threat (A PT). Typical supply chain
1837 cyber security activities for minimizing risks include buying only from trusted vendors, disconnecting
1838 critical machines from outside networks, and educating users on the threats and protective
1839 measures they can take. 3
1840 Examples of supply chain cyber security issues include, but are not limited to the following:
1841 Network or computer hardware that is delivered with malware installed on it already.
1842 Malware that is inserted into software or hardware (by various means).
1843 Vulnerabilities in software applications and networks within the supply chain that are discovered
1844 by malicious threat agents
1845 Counterfeit computer hardware
1846 For example, without practicing security due diligence at all levels in the supply chain, an attacker
1847 with malicious intent could build into the hardware a Trojan that triggers digital and analog actions
1848 targeting the payload of data processed by that hardware. The following figure is an example of a
1849 Trojan's capability to impact the proper operation of a hardware compone nt.

3 https://en.wikipedia.org/wiki/Supply_chain_cyber_security
1850

1851 Figure 11 Trojan Capability Example
1852 Most IACS components and subsystems that comprise an IACS system include parts manufactured
1853 by suppliers to the original equipment manufacturer (OEM), or to an integrator. Some of These
1854 suppliers may operate low cost businesses to compete in the market place. Their business model
1855 may have a lower priority on building security into their processes to avoid substantial increases in
1856 cost. The ISA62443 standards attempt to improve this situation by imposing cybersecurity
1857 requirements for people, process and technology that flows down to subordinate levels in the supply
1858 chain.
1859 As part of their U.S. Resilience Project, NIST offers three recommendations th at should be included
1860 in managing supply chain risk.
1861 1. Securing IT and OT systems against malicious codes that exploit unknown vulnerabilities (zero
1862 day vulnerabilities)
1863 2. Narrowing the time to trace and close supply chain breaches from 230 days to days or ev en
1864 hours.
1865 3. Integrating hardware development and manufacturing operations under a single executive and
1866 physical and cybersecurity under a single executive for "two in a box" risk management.
1867 These recommendations are addressed in the ISA62443 standards.
1868 One of the goals of ISA62443 is to prioritize the potential supply chain risk:
1869 Preventing malware insertions in the componentry of programmable parts;

1870 Preventing malware insertions during the manufacturing process or test and loading of
1871 operating systems;
1872 Preventing tampering with products in the service depots or fulfillment channels; and
1873 Mitigating risk of purchases from non-authorized vendors.
1874
1875 10 Fundamental Concepts

1876 This is a working file for the development of the description of ISA -62443-1-1 (2 nd Edition). When finalized this content
1877 will be moved back into the main document.
1878 There are several fundamental concepts that are essential to the formu lation and execution of an
1879 Industrial Automation and Control Systems security program.
1880 Security Life Cycles This life cycle is focused on the security level of a portion of the system over
1881 time. A change to a physical asset may trigger a set of security level activities, or a change in
1882 security vulnerabilities or an asset may trigger a change in the physical asset.
1883 Security Program Maturity A mature security program integrates all aspects of cyber security,
1884 incorporating desktop and business computing s ystems with industrial automation and control
1885 systems. The development of a program shall recognize that there are steps and milestones in
1886 achieving this maturity
1887 Zone and Conduits Segmenting or dividing a system under consideration for the purpose of
1888 assigning security levels and associated measures is an essential step in the development of the
1889 program.
1890 Security Levels Assets that make up the system under consideration shall be assigned desired
1891 security levels using the mechanism defined in ISA62443-3-2.
1892 Foundational Requirements The full scope of detailed technical and program requirements shall
1893 be derived from a small set of foundational requirements.

1894 Safety and Security In an IACS context the subjects of Security and Safety are closely linked. A
1895 failure to secure an IACS can in turn result in a potentially unsafe System under Control.
1896 Each of these concepts is introduced in subsequent clauses and addressed in more detail in one
1897 or more standards in the ISA62443 series.
1898 Should add more specifics with respect to which parts of the series address each concept.
1899
1900 10.1 Security Life Cycle
1901 10.1.1 Introduction
1902 This section explains the different security a spects in the relevant life cycles of an IACS and
1903 outlines which parts of the ISA62443 series provide guidance for the security aspects of the
1904 respective life cycle. The entities of these relevant life cycles and the respective main responsible
1905 role are shown in table 2.
1906 Table 2 Entities with relevant life cycles and the respective main responsible role
Entity Responsible role
Product used in the IACS Product Supplier
Project integrating various products into a solution System Integrator
Solution as operated, maintained and eventually decommissioned Asset Owner
1907 For each entity and the associated life cycle, the security aspects are defined and implemented in
1908 a security process model, often referred to as the Plan -Do-Check-Act (PDCA) cycle. For each of
1909 these PDCA cycles, a different role is mainly responsible to ensure that all the cyber security
1910 aspects are properly addressed.
1911
1912 Figure 12 Life Cycle Steps
1913
1914 The Association of German Engineers (Verein Deutscher Ingenieure or VDI) described relationship
1915 between the three lfe cycles in a guideline designated VDI/VDE Guideline 2182, as shown in the
1916 following figure. 4
1917 When integrating this into the final -1-1 document, please add reference to VDI 2182 into the bibliography

4 http://www.vdi.eu/guidelines/vdivde_2182_blatt_22 -
informationssicherheit_in_der_industriellen_automatisierung_anwendungsbeispiel_des/
1918
1919 Figure 13 Life Cycle Relationships
1920 Revise this figure to expand the role abbreviations, and change all text to the proper font and size.
1921 An editable version of this figure can be found in the presentation for WG3 TG3.
1922 As also shown in Figure 13, there are a number of interdependencies between these PDCA cycles.
1923 While Figure xx shows a role centric view on the security aspects in IACS environments, Figure xx
1924 shows a life cycle centric view.
1925 The product life cycle must address the security aspects of the product. Product development is
1926 usually done independent of any specific project instead products are developed for a perceived
1927 market. Therefore, the product PDCA cycle is fairly decoupled from the others. However, past and
1928 current project requirements and feedback from the installed base are a source for market
1929 requirements. After a product is released into the market, it needs to be maintained. At the same
1930 time, the product PDCA cycle needs to continuously support projects and the installed base
1931 throughout the life cycle of the product with product security documentation and operational
1932 guidelines. Eventually the product will be taken off the market.
1933 The IACS life cycle addresses the security aspects of the project in which an automation solution
1934 is designed and commissioned as well as the continuous operation and maintenance of the solution
1935 and its eventual decommissioning. Integration projects are dependent on informa tion from the
1936 various product suppliers feeding into the project and in return provide requirements and feedback
1937 for consideration in future updates and new products. At the same time, based on the project
1938 requirements and in particular the security targets specified by the asset owner, the design of the
1939 automation solution done in the integration project largely determines how the IACS will be
1940 operated. Therefore, the integration projects PDCA cycle must supply appropriate information in
1941 particular the solution security documentation to the operations PDCA cycle.
1942 Asset owners operations teams provide requirements both to integration projects as well as to
1943 product suppliers. In return they depend on initial documentation and continuous support
1944 throughout the solutions lifecycle. Hence it is obvious that the life cycle of the integration project
1945 and the operations are tightly intertwined. In fact, usually the integration project activity is not
1946 started unless the eventual asset owner issued a request for b ids.
Assess Phase
High-Level Cyber Risk
Assessment
1 (ISA 62443-3-2)
Allocation of IACS
Assets to Security
Zones or Conduits
2 (ISA 62443-3-2)
Cyber Security Management System: Policies, Procedures, Training & Awareness
Detailed Cyber Risk
Assessment

3 (ISA 62443-3-2)
Develop &
Implement
Phase
Periodic Cybersecurity Audits

Cybersecurity Requirements
Specification
(ISA 62443-3-2) Design and development
(ISA 62443-2-1)
(ISA 62443-2-1)
4
of other means of risk
reduction
Design and engineering of
cybersecurity
countermeasures
5
Installation, commissioning and

validation of cybersecurity
countermeasures
6 (62443-2-4)
Maintain
Maintain
Cybersecurity Maintenance, Phase
Phase
Monitoring and Management of
Change
7 (ISA 62443-2-1)
Cyber Incident
Response & Recovery
8 (ISA 62443-2-1)
1947
1948 Figure 14 Life Cycle
1949 There is another view of this life cycle that appeared in previous versions. (and shown in IC32C
1950 training).
Assess Phase Implement Phase Maintain Phase
Scope System and ID Maintain Security

Detailed Design
Critical Assets (Patch & A/V Mgmt)
Establish Zones &
Repeat until security risk =< tolerable risk
Verification of Design Monitor Security

Conduits
(Achieved SL) (IDS, SIEM, etc.)

Adapted from ISA S99.01.01
(Conceptual Design)
Analyze Security Risk Modification

Construction
for each Zone/Conduit or Decommissioning
Document Security Periodic Assessments

Requirements Validation (SVA)
(FAT and SAT)
1951
1952 Figure 15 Alternate View of Life Cycle
1953
1954 Figure 16 Life Cycle Interdependencies
1955 The following subsections provide more detail on the PDCA cycles shown in Figure xx and the
1956 corresponding security aspects and explain how the different parts of the ISA62443 series
1957 correlate to them.
1958 10.1.2 Product life cycle

1959 Although some products are specifically developed for a given project, in general the aim of the
1960 product supplier is to offer components and systems with a reasonable level of confidence that they
1961 are free from vulnerabilities and meet the required security requirements of their intended target
1962 markets. It is recommended to conduct several PDCA cycles during the product development cycle.
1963 The first cycle should take place in the specification phase and should be focused on the expected
1964 threats coming from the operating environment of the product. In the design phase PDCA cycles
1965 should be applied to product architecture and data flow aspects. During commercialization and
1966 maintenance, the product supplier has to take care of vulnerability handling and to issue security
1967 patches and updates as necessary. Finally, in the phase out early announcement of the termination
1968 of support and security updates is important. Beside the security relevant technical documentation,
1969 the product supplier should also document the security recommendations for integration and
1970 operation of the product as well as the description of the continuous support during the whole life
1971 cycle.
1972 On one side the product suppliers organization should estab lish a product development process
1973 ensuring that all measures to avoid the creation of vulnerabilities are addressed. In ISA62443-4-1
1974 the product supplier will find process requirements which help him to systemat ically address the
1975 security issues from specification phase throughout design, implementation, verification and
1976 validation and release until phase out. The purpose of this part is to improve the quality of product
1977 development process and to include securit y specific measures in the organizational as well in the
1978 technical area. On the other side ISA62443-3-3 and ISA62443-4-2 specify security capabilities
1979 which should be fulfilled by the control system or components of the control system to support a
1980 defense in depth strategy when deploying an automation solution. A product supplier may choose
1981 to integrate a given set of functionalities depending on the security level expe cted in the target
1982 industries of the product. To achieve the required security level of the automation solution additional
1983 compensating countermeasures may be necessary.
1984 In addition, product suppliers should consider ISATR62443-2-3 for the patch management
1985 process. ISATR62443-3-1 provides assessments of current cyber security tools, mitigation
1986 counter-measures, and technologies that may be applied to products and solutio ns.
1987 10.1.3 IACS Life Cycle

1988 10.1.3.1 Specification Phase
1989 Usually the functional and design specification is a first phase of a new project. In some cases, the
1990 specification uses some material from previous projects that might be applicable or reusable, e.g.
1991 a set of user needs. Based on that, the asset owner then begins work on identifying the relevant
1992 security targets and the corresponding risks. This part is also known as a high level risk
1993
assessment. Hence the risk identification as part of the overall system specification takes into
1994 account lessons learned, existing checklists and brainstorming to identify known or new risks.

1995 Furthermore, it includes also the determination of the currently assumed likelihood of risk occurring
1996 and impact.
1997 The asset owner describes the security related requirements for the construction and operation of
1998 the plant (target security level, SLT) in the form of the tender requirements specification of the
1999 potential integrators The asset owner also describes which strategic or company internal
2000 requirements have to be considered (e.g., security policies, physical constrains) during the overall
2001 project. System integrators responding to the tender create the functional specifications of the
2002 automation solution as part of their offer based on the tender specification and mainly the external
2003 technical documentation of all the eligible solutions/ components from one or more product
2004 suppliers. The asset owner has to check this functional specification to ensure, that all requirements
2005 will be addressed by the automation solution. If the functional specification is accepted by the asset
2006 owner, a contract will be negotiated and the collaborat ive project will be started.
2007 ISA62443-2-1 defines the requirements for an industrial automation and control system (IACS)
2008 security management system (IACS-SMS) and provides guidance on how to develop it. Specifically,
2009 for the patch management aspect of an IACS-SMS, ISATR62443-2-3 provides detailed guidance.
2010 Finally, ISA62443-3-2 establishes requirements for defining the zones a nd conduits of the system
2011 under consideration, assessing risk, establishing a target security level (SL -T), providing informal
2012 guidance on how to verify these requirements.
2013 10.1.3.2 Integration and Commissioning Phase

2014 The integration and commissioning phase is an iterative process of the system integrator, mainly
2015 used for designing and implementing the appropriate secure automation solution requested by the
2016 asset owner (and its security targets). The solution of the system integrator is characterized by:
2017 using the zone and conduit model to design a secure automation infrastructure,
2018 selecting and integrating products from the product supplier(s) according their security
2019 capabilities (taking into account the product security documentation/ guidelines/ support),
2020 configuration and parameterization of all products (not limited to products with dedicated
2021 security capabilities),
2022 providing evidence during the commissioning, and in the final application of the asset owner,
2023 that the final integrated solution fulfils all require ments appropriately,
2024 supporting the final integrated solution along the asset owners life cycle (operation,
2025 maintenance, decommissioning),
2026 In the end of the integration and commissioning phase the system integrator must ensure that all
2027 the measures implemented for the achieved Security Level (SL -A) are efficient, suitable and match
2028 the target Security Level (SL-T).
2029 As part of the result of the project the system integrator should provide the asset owner with
2030 external technical documentation and support such that the asset owner will then:
2031 be able to operate, maintain and decommission the automation solution securely within its
2032 specification,
2033 be able to find all IT security-relevant information necessary for future changes of the
2034 solution,
2035 be able to regularly check the implemented countermeasures for their effectiveness, and
2036 be able to adapt the implemented countermeasures when the threat situ ation changes
2037 Furthermore, the documentation should also provide information concerning the operating and
2038 maintenance of the overall automation solution which is also a basis for the training the asset
2039 owners personnel.
2040 ISA62443-2-4 specifies capabilities for IACS Solution Suppliers, especially system integration
2041 service providers. ISA62443-3-2 provides requirements how to determine the achieved security

2042 level (SL-A) of the overall solution and to validate that it matches the previously defined security
2043 target level (SL-T). ISA62443-1-3 defines system cyber security conformance metrics for an
2044 industrial automation and control system (IACS). Finally, ISATR62443-3-1 provides an overview
2045 of security technologies and their appropriate use in IACS environments.
2046 10.1.3.3 Operations & Maintenance Phase

2047 It is one of his major responsibilities of the o wner or operator of an IACS to ensure during the
2048 operation and maintenance phase the security capabilities of the IACS will be kept on the achieved
2049 and approved security levels in all of its zones and conduits. He has to keep the risk of security
2050 breaches and associated consequences at an acceptable level.
2051 In general, the security properties of each IACS will change over time due to the following changes
2052 in the primary or initial security milieu. Those changes can be the following:
2053 The confidence in the security capabilities of the ICAS components is reduced due to
2054 discovered vulnerabilities.
2055 The security requirements of the IACS are changed e.g. due to changes of the threat
2056 situation.
2057 Technical, organizational and/or operational changes impacting the se cure operation of the
2058 IACS.
2059 The security properties relevant to the IACS must be audited and/or tested at regular intervals or
2060 whenever a new vulnerability is discovered to ensure that SL(Achieved) matches SL(Target). The
2061 product supplier and the system integrator have to inform the asset owner or operator whenever
2062 they have discovered any change in the security capabilities of their products or systems leading
2063 to a degradation of their associated security capabilities.
2064 The central document in the standardization series ISA62443 describing the process of operating
2065 and maintaining the achieved security capabilities is the part ISA62443-2-1: Industrial automation
2066 and control system security management system. That document describes among other topics
2067 also the maintenance and improvement steps of a cyber security management system (CSMS)
2068 following the outline of the ISO standard 27001 and 27002. The asset owner should cont inuously
2069 monitor, review and audit the selected security controls and measures and their effectiveness. It
2070 should implement decided upon improvements and adjustments and communicate those actions to
2071 all involved parties.
2072 Further attention should be given the technical report on patch management (ISATR62443-2-3),
2073 one of the important tasks to keep the level of security (SL achieved) of implemented SW
2074 applications to its originally implemented level. The asset owne r should specifically monitor and
2075 assess maintenance providers development in respect to the defined maturity levels during his
2076 involvement with the IACS (see ISA62443-2-4), possibly involving IACS service providers. Re-
2077 assessing previous risk assessments can have an impact on the design of the security zones and
2078 conduits (ISA62443-3-2) and the choice of mitigation measures to meet the selected technical or
2079 organizational setup of an IACS the system (ISA62443-3-3).
2080 10.1.3.4 Decommissioning Phase

2081 When decommissioning an automation solution or parts thereof, there is a risk of compromising the
2082 security of the surrounding environment (e.g. the asset owners organization) or the remaining
2083 automation solution. Decommissioning may range from discontinuing the entire automation solution
2084 (with or without replacement) to removal of individual assets (with or without replacement). The risk
2085 of security compromise stems from the potential disclosure of data or information which may be left
2086 on the assets in a format that may be useful for an attacker (e.g. encryption keys, authentication
2087 credentials, architecture information). It is the responsibility of the asset owner to ensure to an
2088 appropriate level that such information is removed or otherwise rendered useless during the
2089 decommissioning. To live up to this responsibility, the asset owner depends on documentation from
2090 the system integrator and the product suppliers on where such information may be located and how

2091 to properly remove it or render it unusable otherwise. ISA62443-2-1 has requirements and
2092 guidance on security aspects of decommissioning such as disposal or reuse of information, media
2093 as well as equipment.
2094
2095 10.2 Maturity Levels
2096 Driven by increasing cyber security risks, many organizations have taken a proactive approach
2097 towards addressing the security risks of their information technology systems and networks. They
2098 are beginning to realize that addressing cyber security is a continuous activity or process and not
2099 a project with an identified start and stop.
2100 Historically organizations providing and supporting business information systems and industrial
2101 automation and control systems operated in two mutually exclusive areas. The expertise and
2102 requirements of each organization were not understood or appreciated by the other. Issues arose
2103 as organizations tried to employ common IT security practices to industrial automation and control
2104 systems.
2105 In some cases, the security practices were in opposition to normal production practices designed
2106 to maximize safety and continuity of production. Because todays open information technologies
2107 are used extensively in industrial automation and control systems, additional knowledge is required
2108 to safely employ these technologies. The IT and manufacturing or production organizations should
2109 work together and bring their knowledge and skills together t o tackle security issues. In industries
2110 with a high potential for health, safety, and environmental incidents, it is important to involve
2111 Process Safety Management (PSM) and physical security personnel as well.
2112 The goal is a mature security program that integrates all aspects of cyber security, incorporating
2113 desktop and business computing systems with industrial automation and control systems. Many
2114 organizations have fairly detailed and complete cyber security programs for their business
2115 computer systems, but cyber security management practices are not as fully developed for IACS.
2116 A common mistake is to address cyber security as a project with a start and end date. When this
2117 occurs, the security level often declines over time. Cyber security risks constant ly change as new
2118 threats and vulnerabilities surface along with ever -changing technology implementations. A
2119 different approach is needed to sustain the security gains and hold risk to an acceptable level.
2120 The recommendation is to develop and implement an organization-wide cyber security

2121 management system (CSMS) that includes provisions to reassess risk and take corrective actions
2122 to eliminate the tendency for security levels to decline over time. An in -depth description of the key
2123 components of a cyber security management system is provided in the second standard in this
2124 series.
2125 Every organizations journey to implement a cyber security management system will be different
2126 based on the organizations objectives and tolerance for risk. Integrating cyber securi ty into an
2127 organizations standard practices is a cultural change that takes time and resources. As the figures
2128 suggest, it cannot be achieved in one step. It is an evolutionary process that standardizes on the
2129 approach to cyber security. The security prac tices to be implemented must be proportionate to the
2130 risk level and will vary from one organization to another, and may even be different for various
2131 operations within the same organization based on global needs and requirements. Individual
2132 policies and procedures may also be different for each class of system within an organization
2133 because the level of risk and security requirements may be different. A cyber security management
2134 system establishes the overall program that accommodates these differences.
2135 Education and awareness are critical for successfully addressing IACS cyber security risks as noted
2136 above. There are several options to consider:
2137 a) Training the IACS personnel to understand the current information technology and cyber
2138 security issues.

2139 b) Training IT personnel to understand IACS technologies, along with the Process Safety
2140 Management processes and methods.
2141 c) Developing practices that join the skill sets of all the organizations to deal with cyber security
2142 collaboratively.
2143 For the cyber security program to be successful, it is necessary to assemble the right mix of people
2144 on both the mitigation projects and the overall CSMS program development. Contributing groups
2145 include:
2146 IT and Telecom support

2147 IT security
2148 Suppliers
2149 Operations and Maintenance
2150 IACS Support
2151 Process Safety
2152 10.2.1 Maturity Phases
2153 It is possible to describe the relative maturity of a cyber security program in terms of a life cycle
2154 that consists of several phases. Each of these phases consists of one or more steps.
2155 Portions of the industrial automation and control system, or control zones within a control system
2156 can be at different phases of maturity. There are several reasons for this situation, including
2157 budgetary constraints, vulnerability and threat assessments, schedules placed against ri sk analysis
2158 results, automation upgrades, plans for dissolution or replacement, plans to sell a segment of the
2159 facility or business, or availability of other resources to upgrade the security systems to a more
2160 mature phase.
2161 Organizations can achieve a more detailed evaluation of security maturity by assessing
2162 achievements within portions of the industrial automation and control system in terms of the phases
2163 and steps shown in the following table.
2164 Table 3 Security Maturity Phases
Phase Step
Concept Identification
Concept
Functional Analysis Definition

Implementation Functional Design
Detailed Design
Construction
Operations Operations
Compliance Monitoring
Recycle and Disposal Disposal

Dissolution
2165 The tables that follow provide general descriptions for each of the phases and steps in the maturity
2166 life cycle.
2167 Table 4 Concept Phase
Step Description
Identification Recognize need for protection of property, assets, services, or personnel
Start developing the security program
Concept Continue developing the security program
Document assets, services, and personnel needing some level of protection
Document potential internal and external threats to the enterprise
Establish security mission, visions, and values
Develop security policies for industrial automation and control systems and
equipment, information systems and personnel
2168 Table 5 Functional Analysis Phase
Step Description
Definition Continue developing the security program
Establish security functional requirements for industrial automation and
control systems and equipment, production systems, information systems,
and personnel
Perform vulnerability assessment of facilities and associated services against
the list of potential threats
Discover and determine legal requirements for industrial automation and
control systems
Perform a risk analysis of potential vulnerabilities and threats
Categorize risks, potential impacts to the enterprise, and potential
mitigations
Segment security work into controllable tasks and modules for development
of functional designs
Establish network functional definitions for security portions of industrial
automation and control systems
2169 Table 6 Implementation Phase
Step Description
Functional Design Development of the security program is completed in this phase
Define functional security requirements for enterprise zones, plant zones,
and control zones. Potential activities and events are defined and
documented to perform the functional requirements and implement plans
for a secured enterprise.
Define functional security organization and structure
Define functions required in the implementation plan
Define and publish security zones, borders, and access control portals
Complete and issue security policies, and procedures

Detailed Design Design physical and logical systems to perform the functional requirements
previously defined for security

Conduct training programs
The implementation plan is fully developed
Initiate asset management and change management programs
Design borders and access control portals for protected zones
Construction Implementation plan is executed. Physical security equipment, logical
applications, configurations, personnel procedures are installed to complete
the secured zones and borders within the enterprise.
Access control portal attributes are activated and maintained
Training programs are completed
Asset management and change management programs are functional and
operating
Security system turnover packages are completed and ready for acceptance
by operations and maintenance personnel
2170 Table 7 Operations Phase
Step Description
Operations Security equipment, services, applications and configurations are completed
and accepted by operations and maintenance
Personnel are trained, and continued training is provided on security
matters
Maintenance monitors security portions of enterprise, plant, or control
zones and keeps them functioning properly
Asset management and change management is operational and maintained
Compliance Monitoring Internal audits
Risk reviews
External audits
2171 Table 8 Recycle and Disposal Phase
Step Description
Disposal Obsolete security systems are properly disassembled and disposed of
Security borders are updated or recreated for zone protection
Access control portals are created, redefined, reconfigured, or closed
Personnel are briefed about changes in the security systems and items along
with the impact to associated security systems
Dissolution Intellectual property is properly collected, documented, and securely

archived or destroyed
Access control portals and respective links are closed
Personnel are briefed about dissolution of the security systems and items
along with the impact to remaining security systems
2172
2173
2174 10.3 Zones and Conduits
2176 Every situation has a different acceptable level of security. For large or complex systems, it may
2177 not be practical or necessary to apply the same level of security to all components. Differenc es can
2178 be addressed by using the concept of a zone, defined as a logical or physical grouping of physical,

2179 informational, and application assets sharing common security requirements. This concept can be
2180 applied in an exclusive manner where some systems are included in the security zone and all others
2181 are outside the zone.
2182 A conduit is a particular type of zone that groups communications that can be logically organized
2183 into a grouping of information flows within and also external to a zone. Channels are the specific
2184 communication links established within a communication conduit.
2185 10.3.2 Zones

2186 A zone has a border, which is the boundary between included and excluded components. The
2187 concept of a zone also implies the need to access the assets in a zone from both within and without.
2188 This defines the communication and access required to allow information and people to move within
2189 and between the security zones. Zones may be considered to be trusted or untrusted.
2190 Zones can be defined in physical terms (i.e., a physical zon e), in logical terms (i.e., virtual zone),
2191 or in some combination. Physical zones are defined by grouping assets by physical location. In this
2192 type of zone, it is easy to determine which assets are within each zone. Virtual zones are defined
2193 by grouping assets, or parts of physical assets, into security zones based on functionality or other
2194 characteristics, rather than the actual location of the assets.
2195 There can also be zones within zones that provide layered security, giving defense in depth and
2196 addressing multiple levels of security requirements. Defense in depth can also be accomplished by
2197 assigning different properties to security zones.
2198 10.3.3 Conduits

2199 Information must flow into, out of, and within a security zone. Even in a non -networked system,
2200 some communication exists (e.g., intermittent connection of programming devices to create and
2201 maintain the systems). To cover the security aspects of communication and to provide a construct
2202 to encompass the unique requirements of communications, this standard is defi ning a special type
2203 of security zone: a communications conduit.
2204 A conduit can be a single service (i.e., a single Ethernet network) or can be made up of multiple
2205 data carriers (multiple network cables and direct physical accesses). As with zones, it can be made
2206 of both physical and logical constructs. Conduits may connect entities within a zone or may connect
2207 different zones.
2208 As with zones, conduits may be either trusted or untrusted. Conduits that do not cross zone
2209 boundaries are typically trusted by the c ommunicating processes within the zone. Trusted conduits
2210 crossing zone boundaries must use an end-to-end secure process.
2211 Untrusted conduits are those that are not at the same level of security as the zone endpoint. In this
2212 case the security of the communication becomes the responsibility of the individual channel.
2213 Further information on this scenario is available in the Annex.
2214 10.3.4 Channels

2215 Not clear how to introduce this, since it is not a main topic like zones and conduits.
2216 Channels inherit the security properties of the conduit used as the communication media (i.e., a
2217 channel within a secured conduit will maintain the security level of the secured conduit). Channels
2218 may be trusted or untrusted.
2219 Trusted channels are communication links that allow secure communi cation with other security
2220 zones. A trusted channel can be used to extend a virtual security zone to include entities outside
2221 the physical security zone.
2222 Untrusted channels are communication paths that are not at the same level of security as the
2223 security zone under study. The communications to and from the reference zone (the zone that

2224 defines the communication as non-secure) must be validated before accepting the information.
2225 10.3.5 Determining Requirements

2226 Is there any potential for expanding on this theme to i dentify possible NORMATIVE content?
2227 When organizing a system into zones and conduits an organization must first assess the security
2228 requirements (security goals) and then determine the positioning of asset within the zone structure.
2229 The security requirements can be broken down into the following types:
2230 Communications Access For a group of assets within a security border to provide value, there
2231 must be links to assets outside the security zone. This access can be in many forms, including
2232 physical movement of assets (products) and people (employees and vendors) or electronic
2233 communication with entities outside the security zone.
2234 Remote communication is the transfer of information to and from entities that are not in proximity
2235 to each other. For purposes of this document, remote access is defined as communication with
2236 assets that are outside the perimeter of the security zone being addressed.
2237 Local access is usually considered communication between assets within a single security zone.
2238 Physical Access and Proximity Physical security zones are used to limit access to a particular
2239 area because all the systems in that area require the same level of trust of their human operators,
2240 maintainers, and developers. This does not preclude having a higher -level physical security zone
2241 embedded within a lower-level physical security zone or a higher-level communication access zone
2242 within a lower-level physical security zone. For physical zones, locks on doors or other physical
2243 means protect against unauthorized access. The boundary is the wall or cabinet that restricts
2244 access. Physical zones should have physical boundaries commensurate with the level of security
2245 desired, and aligned with other asset security plans.
2246 One example of a physical security zone is a typical manufa cturing plant. Authorized people are
2247 allowed into the plant by an authorizing agent (security guard or ID), and unauthorized people are
2248 restricted from entering by the same authorizing agent and by fences.
2249 Assets that are within the security border are those that must be protected to a given security level,
2250 or policy. All devices that are within the border must share the same minimum level of security
2251 requirements. In other terms, they must be protected to meet the same security policy. Protection
2252 mechanisms can differ depending on the asset being protected.
2253 Assets that are outside the security zone are by definition at a lesser or different security level.
2254 They are not protected to the same security level, and by definition cannot be trusted to the same
2255 security level or policy.
2256 10.3.6 Defining Zones

2257 In building a security program, zones are one of the most important tools for program success, and
2258 proper definition of the zones is the most important aspect of the process. When defining the zones,
2259 organizations must be sure to use both the reference architecture and the asset model to develop
2260 the proper security zones and security levels to meet the security goals established in the industrial
2261 automation and control systems security policy.
2262 When different level activities are performed within one physical device, an organization can either
2263 map the physical device to the more stringent security requirements, or create a separate zone
2264 with a separate zone security policy that is a blended policy between the two zon es. A typical
2265 example of this occurs in process historian servers. To be effective, the server needs access to the
2266 critical control devices that are the source of the data to be collected. However, to meet the
2267 business need of presenting that data to super visors and process optimization teams, a more liberal
2268 access to the device is required than typical control system security requirements allow.
2269 If multiple applications involving different levels of activities are running on a single physical device,

2270 a logical zone boundary can also be created. In this case, access to a particular application is
2271 restricted to persons having privileges for that level of application. An example is a single machine
2272 running an OPC server and OPC client-based analysis tools. Access to the OPC server is restricted
2273 to persons having higher level privileges while access to spreadsheets using OPC client plug -in is
2274 available to all employees.
2275 10.3.7 Zone Identification

2276 Zones can be a grouping of independent assets, a grouping of subzones, or a combination of both
2277 independent assets and assets that are also grouped into subzones contained within the major
2278 zone. Zones have the characteristic of inheritance, which means a child zone (or subzone) must
2279 meet all the requirements of the parent zone.
2280 10.3.7.1 Zone Characteristics

2281 Each zone has a set of characteristics and security requirements that are its attributes. These take
2282 the form of:
2283 a) Security attributes (security policies and security levels)

2284 b) Asset Inventory
2285 c) Access Requirements and Controls
2286 d) Threats and Vulnerabilities
2287 e) Consequences of a Security Breach
2288 f) Authorized Technology
2289 g) Change Management Process.
2290 Each of these attributes is described in more detail in the following paragraphs.
2291 10.3.7.1.1 Security Attributes

2292 Each zone has a controlling document that describes t he overall security goals and how to ensure
2293 the Target Security Level is met. This includes:
2294 a) the zone scope

2295 b) the zone security level (Target security levels, SL -T)
2296 c) the organizational structure and responsibilities to enforce the security policy
2297 d) the risks associated with the zone
2298 e) the security strategy to meet the required goals
2299 f) the security policies to be enforced
2300 g) the types of activities that are permitted within the zone
2301 h) the types of communication allowed access to the zone
2302 i) documentation of the zone attributes.
2303 All of the above are documented and combined into the zone security policy, which is used to guide
2304 and measure the construction and maintenance of the assets contained within the zone.
2305 10.3.7.1.2 Asset Inventory

2306 To maintain security within a zone, an organization must maintain a list of all of the assets (physical
2307 and logical). This list is used to assess risk and vulnerabilities and to determine and maintain the
2308 appropriate security measures required to meet the goals of the security policy. Inventory acc uracy
2309 is a key factor in meeting the security goals set forth in the security policy. The list must be updated
2310 when assets within the zone change, or their electronic connections change, as well as when new
2311
assets are added to the zone to ensure that the s ecurity goals are met.
2312 Physical assets and components are the physical devices contained within the zone. Some

2313 examples include:
2314 a) computer hardware (e.g., workstations, servers, instruments, controls, power supplies, disk
2315 drives, or tape backups)
2316 b) network equipment (e.g., routers, switches, hubs, firewalls, or physical cables)
2317 c) communications links (e.g., buses, links, modems, and other network interfaces, antennas)
2318 d) access authentication and authorization equipment (e.g., domain controllers, radius servers,
2319 readers, and scanners)
2320 e) development system hardware
2321 f) simulation and training system hardware
2322 g) external system hardware
2323 h) spare parts inventories
2324 i) monitoring and control devices (e.g., sensors, switches, and controllers)
2325 j) reference manuals and information.
2326 Logical assets include all the software and data used in the zone. Some examples are:
2327 a) computer system software (e.g., applications, operating systems, communication interfaces,
2328 configuration tables, development tools, analysis tools, and utilities)
2329 b) patches and upgrades for operating systems and application tool sets
2330 c) databases
2331 d) data archives
2332 e) equipment configuration files
2333 f) copies of software and data maintained for backup and recovery purposes
2334 g) design basis documentation (e.g., functional requirements including information and assets,
2335 security classification and levels of protection, physical and software design, vulnerability
2336 assessment, security perimeter, benchmark tests, assembly, and installation documents)
2337 h) supplier resources (e.g., product updates, patches, service packs, utilities, and validation
2338 tests).
2339 10.3.7.1.3 Access Requirements and Controls
2340 By its nature, a zone implies that access is limited to a small set of all the possible entities that
2341 could have access. A security policy for a zone must then articulate th e access required for the
2342 zone to meet its business objectives, and how this access is controlled.
2343 10.3.7.1.4 Threat and Vulnerability Assessment

2344 Threats and corresponding vulnerabilities exist within a given zone. Organizations must identify
2345 and evaluate these threats and vulnerabilities to determine their risk of causing the assets within
2346 the zone to fail to meet their business objectives. The process of documenting the threats and
2347 vulnerabilities happens in the threat and vulnerability assessment that is part of th e zone security
2348 policy.
2349 Many possible countermeasures exist to reduce the risk of a threat exploiting a given vulnerability
2350 within a zone. The security policy should outline what types of countermeasures are appropriate to
2351 meet the Target Security Level for the zone, within the cost versus risk trade-off.
2352 10.3.7.1.5 Authorized Technology
2353 As industrial automation and control systems evolve to meet changing business needs, the
2354
technology used to implement the changes needs to be controlled. Each of the technologies used
2355 in these systems brings with it a set of vulnerabilities and corresponding risks. To minimize the
2356

risks to a given zone, the zone security policy needs to have a dynamic list of technologies allowed
2357 in the zone, as well as those not allowed.
2358 10.3.7.1.6 Change Management Process

2359 A formal and accurate process is required to maintain the accuracy of a given zones asset
2360 inventory and how changes to the zone security policy are made. A formal process ensures that
2361 changes and additions to the zone do not compromise the se curity goals. In addition, a way to
2362 adapt to changing security threats and goals is required. Threats and vulnerabilities, with their
2363 associated risks, will change over time.
2364 10.3.8 Defining Conduits

2365 Conduits are security zones that apply to specific communicatio ns processes. As security zones
2366 they are a logical and/or physical grouping of assets (communication assets in this case). A security
2367 conduit protects the security of the channels that it contains in the same way that the physical
2368 conduit protects cables from physical damage. Conduits can be thought of as pipes that connect
2369 zones or that are used for communication within a zone. Internal (within the zone) and external
2370 (outside the zone) conduits enclose or protect the communications channels (conceptual ly cables)
2371 that provide the links between assets. Most often in an IACS environment the conduit is the same
2372 as the network. That is, the conduit is the wiring, routers, switches, and network management
2373 devices that make up the communications under study. C onduits can be groupings of dissimilar
2374 networking technologies, as well as the communications channels that can occur within a single
2375 computer. Conduits are used to analyze the communication threats and vulnerabilities that can
2376 exist in the communications within and between zones.
2377 Conduits can be considered pipes that contain data and/or provide physical connections for
2378 communication between zones. A conduit can have sub conduits to provide a one-to-one or one-
2379 to-many zone communication. Providing secure communication for the conduit can be
2380 accomplished by implementing the appropriate zone security policy.
2381 10.3.8.1 Conduits Characteristics

2382 Physically a conduit can be a cable that connects zones for communication purposes.
2383 A conduit is a type of zone that cannot have subzones; that is, a conduit is not made up of sub
2384 conduits. Conduits are defined by the list of all zones that share the given communication channels.
2385 Both physical devices and applications that use the channels contained in a conduit define the
2386 conduit end points.
2387 Like a zone, each conduit has a set of characteristics and security requirements that are its
2388 attributes. These take the form of:
2389 a) Security attributes

2390 b) Asset Inventory

2391 c) Access Requirements and Controls
2392 d) Threats and Vulnerabilities
2393 e) Consequences of a Security Breach
2394 f) Authorized Technologies
2395 g) Change Management Process
2396 h) Connected Zones.
2397 10.3.8.1.1 Security Attributes
2398 Each conduit has a controlling document that describes the overall security goals and how to ensure
2399 the Target Security Level is met. This document includes:
2400 a) the conduit scope

2401 b) the conduit security level (SL-T)
2402 c) the organizational structure and responsibilities to enforce the conduit security policy
2403 d) the risks associated with the conduit
2404 e) the security strategy to meet the required goals
2405 f) the security policies to be enforced
2406 g) the types of channels that are permitted within the conduit
2407 h) documentation of the conduit attributes.
2408 All of the above are documented and combined into the conduit security policy, which is used to
2409 guide and measure the construction and m aintenance of the assets contained within the conduit.
2410 10.3.8.1.2 Asset Inventory

2411 As with the zone inventory, an accurate list of the communications assets is required.
2412 10.3.8.1.3 Access Requirements and Controls

2413 By its nature, a conduit implies that access is restricted to a l imited set of all the possible entities
2414 that could have access. A security policy for a conduit must then articulate the access required for
2415 the conduit to meet its business objectives, and how this access is controlled.
2416 10.3.8.1.4 Threat and Vulnerability Assessment

2417 Threats and corresponding vulnerabilities exist for a given conduit. Organizations must identify and
2418 evaluate these threats and vulnerabilities to determine their risk of causing the assets within the
2419 conduit to fail to meet their business objectives. The process of documenting the threats and
2420 vulnerabilities happens in the threat and vulnerability assessment that is part of the conduit security
2421 policy.
2422 Many possible countermeasures exist to reduce the risk of a threat exploiting a given vulnerability
2423 within a conduit. The security policy should outline what types of countermeasures are appropriate
2424 within the cost versus risk trade-off.
2425 10.3.8.1.5 Authorized Technology

2426 As industrial automation and control systems evolve to meet changing business needs, the
2427 technology used to implement the changes needs to be controlled. Each of the technologies used
2428 in these systems brings with it a set of vulnerabilities and corresponding risks. To minimize the
2429 risks to a given conduit, the conduit security policy needs to have a dyna mic list of technologies
2430 allowed in the conduit.
2431 10.3.8.1.6 Change Management of Process

2432 A formal and accurate process is required to maintain the accuracy of a given conduits policy and
2433 how changes are made. A formal process ensures that changes and additions to th e conduit do not
2434 compromise the security goals. In addition, a way to adapt to changing security threats and goals
2435 is required. Threats and vulnerabilities, with their associated risks, will change over time.
2436 10.3.8.1.7 Connected Zones

2437 A conduit may also be described in terms of the zones to which it is connected.
2438
2439 10.4 Security Levels
2441 Safety systems have used the concept of safety integrity levels (SIL) for almost two decades. This
2442 allows the safety integrity capability of a component or the safety integrity level of a deployed

2443 system to be represented by a single number that defines a protection factor required to ensure
2444 the health and safety of people or the environment based on the probability of failure of that
2445 component or system. The process to determine the required protection factor for a safety system,
2446 while complex, is manageable since the probability of a component or system failure due to random
2447 hardware failures can be measured in quantitative terms. The overall risk can be calculated based
2448 on the consequences that those failures could potentially have on Health, Safety and Environmental
2449 (HSE).
2450 Security systems have much broader application, a much broader set of consequences and a much
2451 broader set of possible circumstances leading up to a possible event. Security systems are still
2452 meant to protect HSE, but they are also meant to protect the industrial process itself, company -
2453 proprietary information, public confidence and national security among other things in situations
2454 where random hardware failures may not be the root cause. In some cases, it may be a well -
2455 meaning employee that makes a mistake, and in other cases it may be a devious attacker bent on
2456 causing an event and hiding the evidence. The increased complexity of secur ity systems makes
2457 compressing the protection factor down to a single number much more difficult.
2458 10.4.2 Concept Definition

2459 Security levels provide a qualitative approach to addressing security for a zone. As a qualitative
2460 method, security level definition has applicability for comparing and managing the security of zones
2461 within an organization. As more data become available and the mathematical representations of
2462 risk, threats, and security incidents are developed, this concept will move to a quantitative approach
2463 for selection and verification of Security Levels (SL). It will have applicability to both end user
2464 companies, and vendors of IACS and security products. It will be used to select IACS devices and
2465 countermeasures to be used within a zone and to identify and compare security of zones in different
2466 organizations across industry segments.
2467 The asset owner will be required to come up with their own definition of what those classifications
2468 mean for their particular application. The long-term goal is to move as many of the security levels
2469 and requirements to quantitative descriptions, requirements and metrics as possible to establish
2470 repeatable applications of the standard across multiple companies and industries. Achieving this
2471 goal will take time, since more experience in applying the standards and data on industrial security
2472 systems will need to be acquired to justify the quantitative approach.
2473 When mapping requirements to the different Security Levels, standard developers need some
2474 frame of reference describing what the different Security Levels mean and how they differ from
2475 each other. The goal is to propose such a frame of reference.
2476 10.4.3 Level Definitions

2477 The ISA62443 series define SLs in terms of five different levels ( 0, 1, 2, 3 and 4), each with an
2478 increasing level of security. The current model for defining SLs depends on protecting against an
2479 increasingly more complex threat and differs slightly depending on what type of SL it is applied to.
2480 For SL-C, this means that a particular component or system is capable of being configured by an
2481 asset owner or system integrator to protect against an increasingly complex type of threat. For SL -
2482 T, this means that the asset owner or system integrator has determined through a risk assessment
2483 that they need to protect this particular zone, system or component against this level of threat. For
2484 SL-A, this means that the asset owner, system integrator, product supplier and/or any combination
2485 of these has configured the zone, system or c omponent to meet the particular security requirements
2486 defined for that SL.
2487 The language used for each of the Security Levels uses terms like casual, coincidental, simple,
2488 sophisticated, and extended. This language is intentionally vague to allow the same b asic language
2489 to be used for all of the standards in the ISA62443. Each of the individual standards in the series
2490 will define the requirements for the Security Levels that apply to their particular purpose.

2491 While the requirements for each of the Security Levels will be different throughout the ISA62443
2492 series, there needs to be a general understanding of what each of the Security Levels should
2493 protect against. The following paragraphs provide guidance on how to differentiate between the
2494 Security Levels.
2495 Security Level 0: No specific requirements or security protection necessary

2496 SL 0 has multiple meanings depending on the situation in which it is applied. In defining
2497 SL-C it would mean that the component or system fails to meet some of the SL 1
2498 requirements for that particular FR. This would most likely be for components or systems
2499 that would be part of a larger zone where other components or systems would provide
2500 compensating countermeasures. In defining SL-T for a particular zone it means that the
2501 asset owner has determined that the results of their risk analysis indicate that less than the
2502 full SL 1 specific requirements are necessary for that particular FR on that comp onent or
2503 system. This would more likely happen for individual components within a system or zone
2504 that do not contribute in any way to the FR-specific requirements. In defining SL-A it would
2505 mean that the particular zone fails to meet some of the SL 1 requi rements for that particular
2506 Foundational Requirement (FR).
2507 Security Level 1: Protection against casual or coincidental violation

2508 Casual or coincidental violations of security are usually through the lax application of
2509 security policies. These can be caused by well-meaning employees just as easily as they
2510 can be by an outsider threat. Many of these violations will be security program related and
2511 will be handled by enforcing policies and procedures.
2512 A simple example would be an operator able to change a set point on the engineering station
2513 in the BPCS zone to a value outside certain conditions determined by the engineering staff.
2514 The system did not enforce the proper authentication and use control restrictions to disallow
2515 the change by the operator. Another example would be a password being sent in clear text
2516 over the conduit between the BPCS zone and the DMZ zone, allowing a network engineer
2517 to view the password while troubleshooting the system. The system did not enforce proper
2518 data confidentiality and authenticator protection to protect the password. A third example
2519 would be an engineer that means to access the PLC in Industrial Network #1 but actually
2520 accesses the PLC in Industrial Network #2. The system did not enforce the proper restriction
2521 of data flow preventing the engineer from accessing the wrong system.
2522 Security Level 2: Protection against intentional violation using simple means with low
2523 resources, generic skills and low motivation
2524 Simple means do not require much knowledge on the part of the attacker. The attacker does
2525 not need detailed knowledge of security, the domain or the particular system under attack.
2526 These attack vectors are well known and there may be automated tools for ai ding the
2527 attacker. They are also designed to attack a wide range of systems instead of targeting a
2528 specific system, so an attacker does not need a significant level of motivation or resources
2529 at hand.
2530 An example would be a virus that infects the maintenanc e workstation in the Plant DMZ
2531 zone spreading to the BPCS engineering workstation since they both use the same general
2532 purpose operating system. Another example would be an attacker compromising a web
2533 server in the enterprise network by an exploit download ed from the Internet for a publicly
2534 known vulnerability in the general purpose operating system of the web server. The attacker
2535 uses the web server as a pivot point in an attack against other systems in the enterprise
2536 network as well as the industrial network. A third example would be an operator that views
2537 a website on the HMI located in Industrial Network #1 which downloads a Trojan that opens
2538 a hole in the routers and firewalls to the Internet.
2539 Security Level 3: Protection against intentional violation u sing sophisticated means

2540 with moderate resources, IACS specific skills and moderate motivation
2541 Sophisticated means require advanced security knowledge, advanced domain knowledge,
2542 advanced knowledge of the target system or any combination of these. An attac ker going
2543 after a Security Level 3 system will likely be using attack vectors that have been customized
2544 for the specific target system. The attacker may use exploits in operating systems that are
2545 not well known, weaknesses in industrial protocols, specific information about a particular
2546 target to violate the security of the system or other means that require a greater motivation
2547 as well as skill and knowledge set than are required for Security Level 1 or 2.
2548 An example of sophisticated means could be passwor d or key cracking tools based on hash
2549 tables. These tools are available for download, but applying them takes knowledge of the
2550 system (such as the hash of a password to crack). Another example would be an attacker
2551 that gains access to the FS- PLC through the serial conduit after gaining access to the
2552 control PLC through a vulnerability in the Ethernet controller. A third example would be an
2553 attacker that gains access to the data historian by using a brute -force attack through the
2554 industrial/enterprise DMZ firewall initiated from the enterprise wireless network.
2555 Security Level 4: Protection against intentional violation using sophisticated means
2556 with extended resources, IACS specific skills and high motivation
2557 Security Level 3 and Security Level 4 are very similar in that they both involve sophisticated
2558 means used to violate the security requirements of the system. The difference comes from
2559 the attacker being even more motivated and having extended resources at their disposal.
2560 These may involve high-performance computing resources, large numbers of computers or
2561 extended periods of time.
2562 An example of sophisticated means with extended resources would be using super
2563 computers or computer clusters to conduct brute-force password cracking using large hash
2564 tables. Another example would be a botnet used to attack a system using multiple attack
2565 vectors at once. A third example would be an organized crime organization that has the
2566 motivation and resources to spend weeks attempting to analyze a system and develop
2567 custom zero-day exploits.
2568 10.4.4 Types of Security Levels

2569 Security Levels have been broken down into three different types: target, achieved and capability.
2570 These types, while they all are related have to do with different aspects of the security life cycle.
2571 Target Security Levels (SL-T) are the desired level of security for a particular system. This
2572 is usually determined by performing a risk assessment on a system and determining that it
2573 needs a particular level of security to ensure its correct operation.
2574 Achieved Security Levels (SL-A) are the actual level of security for a particular system.
2575 These are measured after a system design is available or when a system is in place. They
2576 are used to establish that a security system is meeting the goals that were originally s et out
2577 in the target Security Levels.
2578 Capability Security Levels (SL-C) are the security levels that component or systems can
2579 provide when properly configured. These levels state that a particular component or system
2580 or component is capable of meeting the target Security Levels natively without additional
2581 compensating controls when properly configured and integrated.
2582 Each of these Security Levels is intended to be used in different phases of the security life cycle
2583 according the ISA62443 series of standards. Starting with a target for a particular system, an
2584 organization would need to build a design that included the capabilities to achieve the desired
2585 result. In other words, the design team would first develop th e target Security Level necessary for
2586 a particular system. They would then design the system to meet those targets, usually in an iterative
2587 process where after each iteration the achieved Security Levels of the proposed design are
2588 measured and compared to the target Security Levels. As part of that design process, the designers

2589 would select systems and components with the necessary capability Security Levels to meet the
2590 target Security Level requirements or where such systems and components are not availa ble,
2591 complement the available ones with compensating security controls. After the system went into
2592 operation, the actual Security Level would be measured as the achieved Security Level and
2593 compared to the target SAL.
2594 10.4.5 Using Security Levels

2595 The application of security levels is covered in detail in 62443-3-2, so it is probably not necessary to provide or explain
2596 the examples here.
2597 When designing a new system (green field) or revising the security of an existing system (brown
2598 field), the first step is to break the system into different zones and define conduits connecting these
2599 zones where necessary. Details on how to accomplish this are given in ISA62443-3-2. Once a
2600 zone model of the system is established each zone a nd conduit is assigned a target SAL, based
2601 on a risk analysis, which describes the desired security for the respective zone or conduit. During
2602 this initial zone and conduit analysis, it is not necessary to have completed a detailed system
2603 design. It is sufficient to describe the functionality that should be provided by assets in a zone and
2604 the connections between zones in order to meet the security objectives.
2605 Figure 17 and Figure 18 show high-level examples of systems broken down into zones connected
2606 by conduits. Figure 17 is a graphical representation of a control system for a chlorine truck loading
2607 station. The full use-case that accompanies this figure will be discussed in ISA-TR62443-1-4. It has
2608 five zones shown: the basic process control system (BPCS), the SIS, the control center, the plant
2609 DMZ, and the enterprise. The BPCS and the SIS both use PLCs to operate different aspects of the
2610 loading station with the SIS using a special functional safety PLC (FS -PLC) rated for use in safety
2611 systems. The two PLCs are connected via a non-routable serial or Ethernet connection using a
2612 boundary protection device. Each of the PLCs is connect ed to a local switch with an engineering
2613 workstation for programming and HMI for operating. The BPCS and SIS zones also contain an
2614 instrument asset management system (IAMS) to measure and test the instruments. A control center
2615 containing multiple workstations and the BPCS are both connected to the plant DMZ. A plant DMZ
2616 can house a variety of components and systems, for example a data historian and a maintenance
2617 workstation as shown in the figure. The plant DMZ is shown connected to the enterprise systems,
2618 which contain the corporate wireless local area network (WLAN) and web server. Multiple domain
2619 controllers and boundary protection devices are shown in the figure to indicate some of the
2620 countermeasures that may be applied to improve security.
2621
2622 Figure 17 High-level process-industry example showing zones and conduits
2623 Figure 18 is a graphical representation of a manufacturing plant. It has four zones defined: the
2624 enterprise network, the industrial/enterprise DMZ, and two industrial networks. The enterprise
2625 infrastructure has a wireless local area network (WLAN) and a connection to the Internet. Many
2626 companies use a DMZ between important parts of their systems to isolate the network traffic. In
2627 this particular example, each industrial network operates relatively independent of each other with
2628 its own PLC, field devices, and HMI.
2629
2630 Figure 18 High-level manufacturing example showing zones and conduits
2631 After determining the target Security Levels, the system can be designed (green field) or redesigned
2632 (brown field) to try to meet those target Security Levels. The design process is usually an iterative
2633 approach where the system design is checked against the target multiple times throughout the
2634 process. Multiple parts of the ISA62443 series of standards contain guidance on different aspects
2635 of the programmatic and technical requirements that go into the design process. ISA62443-2-1
2636 provides guidance on the programmatic aspects of the design process while ISA62443-3-3 and
2637 ISA62443-4-2 define system-level and component-level technical security requirements and relate
2638 them to different capability Security Levels.
2639 During the design process for a system, it is necessary to evaluate the security capabilities of
2640 different components and subsystems. Product suppliers will have to provide these as capability
2641 Security Levels for their components or systems by comparing product features and capabilities
2642 with the requirements defined in the ISA62443 series for the different capability Security Levels.
2643 These capability Security Levels can be used to determine whether a given component or system
2644 is capable of meeting the target Security Level for the system. The product supplier or system
2645 integrator will also have to provide guidance on how to configure the component or subsystem to
2646 meet the claimed Security Levels.
2647 It is likely that in a particular design there will be som e components or systems that cannot fully
2648 meet the target SAL. Where the capability Security Level of a component or system is lower than
2649 the target SAL, compensating controls need to be considered to meet the desired target SAL.
2650 Compensating controls may include changing the design of the component or system to increase
2651 its capabilities, choosing another component or system to meet the target Security Level or adding
2652 additional components or systems to meet the target SAL. After each iteration in the desig n
2653 process, the system designs achieved Security Levels should be reevaluated to see how they
2654 compare to the target Security Levels for the system.
2655 Once the system design is approved and implemented, the system needs to be evaluated to prevent
2656 or mitigate deterioration of the systems security level. It should be evaluated during or after system
2657 modifications and on a regular schedule. ISA62443-2-1 and ISA62443-2-2 provide guidance on
2658 the steps necessary to operate the security program and how to evaluate its effectiveness. After
2659 the achieved Security Levels have been determined, it will be necessary to evaluate whether the
2660 system is still meeting the original target Security Levels (for example, using the system
2661 requirements from ISA62443-3-3). If the system is not meeting those requirements, there may be
2662 multiple reasons including the lack of maintenance of the program or the need to redesign parts of
2663 the system.
2664 In essence, the control system security capabilities are determined independent from a given use
2665 context, but are used in a given context in order to achieve the target SL of the respective system
2666 architecture, zones and/or conduits (see Figure refernce).
2667
2668 Figure 19 High-level manufacturing example showing zones and conduits
2669 10.4.6 Foundational Requirements

2670 Security Levels are based on the seven Foundational Requirements for security.
2671 1) Identification and authentication control (IAC),

2672 2) Use control (UC),
2673 3) System integrity (SI),
2674 4) Data confidentiality (DC),
2675 5) Restricted data flow (RDF),
2676 6) Timely response to events (TRE), and

2677 7) Resource availability (RA).
2678 Instead of compressing Security Levels down to a single number, it is po ssible to use a vector of
2679 Security Levels that uses the seven FRs above instead of a single protection factor. This vector of
2680 Security Levels allows definable separations between Security Levels for the different FRs using
2681 language.
2682 This language can be based on the additional consequences associated with security systems or
2683 different attacks against the security objectives addressed by the FRs. The language used in the
2684
Security Level definitions can contain practical explanations of how one system is more secure
2685 than another without having to relate everything to HSE consequences.
2686 10.4.7 Security Level Vector Format
2687 A vector can be used to describe the security requirements for a zone, conduit, component or
2688 system better than a single number. This vector may conta in either a specific Security Level

2689 requirement or a zero value for each of the foundational requirements (see 10.3.6).
2690 FORMAT SL-?([FR,]domain) = { AC UC DI DC RDF TRE RA }
2691 Where;
2692 SL-? = (Required) The Security Level type (see 10.3.3). The possible formats are:
2693 SL-T = Target SAL

2694 SL-A = Achieved SAL
2695 SL-C = Capabilities SAL
2696 [FR,] = (Optional) Field indicating the FR that the Security Level value applies. The FRs are
2697 written out in abbreviated form instead of numerical form to aid in readabilit y.
2698 domain = (Required) The applicable domain that the Security Level applies. Domains can
2699 refer to zones, control systems, subsystems or components. Some examples of different
2700 domains from Figure A.1 are SIS zone, BPCS zone, BPCS HMI, Plant DMZ domain
2701 controller, Plant DMZ to Control Center conduit and SIS to BPCS serial conduit. In this
2702 particular standard, all requirements refer to a control system, so the domain term is not
2703 used as it would be by other documents in the ISA62443.
2704 EXAMPLE 1 SL-T(BPCS Zone) = { 2 2 0 1 3 1 3}
2705 EXAMPLE 2 SL-C(SIS Engineering Workstation) = { 3 3 2 3 0 0 1}
2706 EXAMPLE 3 SL-C(RA, FS- PLC) = 4

2707 NOTE The last example specifies only the RA component of a 7 -dimension SL-C.
2708
2709 10.5 Foundational Requirements
2710 As noted in the discussion of fundamental concepts (see n.n), there are basic or Foundational
2711 Requirements (FRs) that form the basis for subsequent requirements in this standard as well as
2712 other standards in the ISA62443 series. All aspects associated with meeting a desired IACS
2713 security level (people, processes and technology) are derived through meeting the requirements
2714 associated with the following Foundational Requirements:
2715 1) Identification and authentication control (IAC),

2716 2) Use control (UC),
2717 3) System integrity (SI),

2718 4) Data confidentiality (DC),
2719 5) Restricted data flow (RDF),
2720 6) Timely response to events (TRE), and
2721 7) Resource availability (RA).
2722 As an example, the system requirements (SRs) and associated capability security levels (SL -C)
2723 defined in ISA62443-3-3 are organized and numbered by Foundation Requirement. Rather than
2724 compressing security levels down to a single number, a vector is used to express the nuances
2725 associated with an often complex security or protection level. This vector of security levels allows
2726 definable separations between security levels on a requirement by requirement basis.
2727 10.5.1 FR 1 Identification and authentication control (IAC)

2729 Based on the target security level (SL-T) determined, and using the processes defined in
2730 ISA62443-3-2, the IACS shall provide the necessary capabilities to reliably identify and
2731 authenticate all users (humans, software processes and devices) attempting to access the ICS.
2732 10.5.1.2 Rationale

2733 Asset owners will have to develop a list of all valid users (humans, software processes and devices)
2734 and to determine for each zone the required level of identification and authentication control (IAC)
2735 protection. The goal is to protect the ICS from unauthenticated access by verifying the identity of
2736 any user requesting access to the ICS before activating the communication. Rec ommendations and
2737 guidelines should include mechanisms that will operate in mixed modes. For example, some zones
2738 and individual ICS components require strong IAC, such as strong authentication mechanisms, and
2739 others do not.
2740 10.5.2 FR 2 Use control (UC)

2742 Based on the target security level (SL-T) determined using the processes defined in ISA62443-3-
2743 2, the IACS shall provide the necessary capabilities to enforce the assigned privileges of an
2744 authenticated user (human, software process or device) to perform the requested action on the
2745 system or assets and monitor the use of these privileges.
2746 10.5.2.2 Rationale

2747 Once the user is identified and authenticated, the control system has to restrict the allowed actions
2748 to the authorized use of the control system. Asset owners and system integrators will have to assign
2749 to each user (human, software process or device), group, role, etc. the privileges defining the
2750 authorized use of the IACS. The goal of UC is to protect against unauth orized actions on ICS
2751 resources by verifying that the necessary privileges have been granted before allowing a user to
2752 perform the actions. Examples of actions are reading or writing data, downloading programs and
2753 setting configurations. Recommendations and guidelines should include mechanisms that will
2754 operate in mixed modes. For example, some ICS resources require strong use control protection,
2755 such as restrictive privileges, and others do not. By extension, use control requirements need to
2756 be extended to data at rest. User privileges may vary based on time-of-day/date, location and
2757 means by which access is made.
2758 10.5.3 FR 3 System integrity (SI)

2761 2, the IACS shall provide the necessary capabilities to ensure the integrity of the IACS to prevent
2762 unauthorized manipulation.
2763 10.5.3.2 Rationale

2764 An IACS will often go through multiple testing cycles (unit testing, factory acceptance testing (FAT),
2765 site acceptance testing (SAT), certification, commissioning, etc.) to establish that the systems will
2766 perform as intended before they even begin production. Once operational, asset owners are
2767 responsible for maintaining the integrity of the IACS. Using their risk assessment methodology,
2768 asset owners may assign different levels of integrity protection to different systems, communication
2769 channels and information in their IACS. The integrity of physical assets should be maintained in
2770 both operational and non-operational states, such as during production, when in storage or during
2771 a maintenance shutdown. The integrity of logical assets should be maintained while in transit and
2772 at rest, such as being transmitted over a network or when re siding in a data repository.
2773 10.5.4 FR 4 Data confidentiality (DC)
2776 2, the IACS shall provide the necessary capabilities to ensure the confidentiality of information on

2777 communication channels and in data repositories to prevent unauthorized disclosure.
2778 10.5.4.2 Rationale

2779 Some control system-generated information, whether at rest or in transit, is of a confidential or
2780 sensitive nature. This implies that some communication channels and data -stores require
2781 protection against eavesdropping and unauthorized access.
2782 10.5.5 FR 5 Restricted data flow (RDF)

2785 2, the IACS shall provide the necessary capabilities to segment the control system via zones and
2786 conduits to limit the unnecessary flow of data.
2787 10.5.5.2 Rationale

2788 Using their risk assessment methodology, asset owners need to determine necessary information
2789 flow restrictions and thus, by extension, determine the configuration of the conduits used to deliver
2790 this information. Derived prescriptive recommendations and guidelines should include mechani sms
2791 that range from disconnecting control system networks from business or public networks to using
2792 unidirectional gateways, stateful firewalls and demilitarized zones (DMZs) to manage the flow of
2793 information.
2794 10.5.6 FR 6 Timely response to events (TRE)

2797 2, the IACS shall provide the necessary capabilities to respond to security violations by notifying
2798 the proper authority, reporting needed evidence of the violation and taking timely corrective action
2799 when incidents are discovered.
2800 10.5.6.2 Rationale

2801 Using their risk assessment methodology, asset owners should establish security policies and
2802 procedures and proper lines of communication and control needed to respond to security violations.
2803 Derived prescriptive recommendations and guidelines should include mechanisms that collect,
2804 report, preserve and automatically correlate the forensic evidence to ensure timely correct ive
2805 action. The use of monitoring tools and techniques should not adversely affect the operational
2806 performance of the control system.
2807 10.5.7 FR 7 Resource availability (RA)

2810 2, the IACS shall provide the necessary capabilities to ensure the availability of the control system
2811 against the degradation or denial of essential services.
2812 10.5.7.2 Rationale and supplemental guidance

2813 The aim of this FR is to ensure that the control system is resilient against various types of denial
2814 of service events. This includes the partial or total unavailability of system functionality at various
2815 levels. In particular, security incidents in the control system should not affect SIS or other safety-
2816 related functions.
2817
2818 10.6 Security and Safety

2819 This is a working file for the development of the description of ISA -62443-1-1 (2 nd Edition). When finalized this content
2820 will be moved back into the main document.
2821 Safety Instrumented Systems (SIS), represent one layer of protection that may be implemented in
2822 order to reduce risks associated with Industrial Automation Control Systems. Traditional risk
2823 assessment methodologies in the past, have generally excluded the potential for cyber related
2824 attacks to cause safety related incidents. Given that targeted attacks on Industrial Automation
2825 Control Systems have occurred and these systems are increasingly being connected to other
2826 business systems, they represent a significant potential for common mode failure. As a result, it is
2827 necessary in today's world to include cyber security in the overall Risk Assessment.
2828 Without addressing cyber security throughout the entire safety lifecycle, it is imposs ible to
2829 adequately understand the relative integrity of the various layers of protection that involve
2830 instrumented systems, including the SIS.
2831 The underlying premise of this standard is that the means to implement, operate, and maintain
2832 system security should not compromise the performance of the safety instrumented systems (SIS).
2833 It should also be understood that achieving higher security levels may result in less convenience
2834 to the end user.
2835 Note- the ISA84 Technical Report would like to use a modified ve rsion of the first 2 paragraphs that is specific to the
2836 process industry, but probably not the Rationale section. I also have reservations about including the Rationale section.
2837 We can discuss if the first 2 paragraphs have enough content for the Foundatio nal Clause, or if the Rationale section
2838 should also be included and/or edited down.
2839 Note update Jun 06, 2015. The wording of the first 2 paragraphs has been modified, and a third paragraph has been
2840 added. These changes align with the ISA84 Technical Report , yet maintains a generic approach to safety & security (in
2841 contrast to ISA84's process specific approach).
2842 10.6.1 Rationale
2843 To take advantage of digital advances, Industrial Control Systems have changed dramatically in
2844 the last two decades. Once isolated and proprietary, ICS today are part of a converged network
2845 that connects plant operations to the administrative environment. The migration from single -
2846 purpose supervisory control and data acquisition (SCADA) systems to industry standard, network -
2847 based systems provided numerous benefits, including increased information -sharing across the
2848 operation, and remote (Internet and wireless) access to Industrial Control Systems.
2849 But those advances also created security gaps. By connecting to the larger web of networks, w ater-
2850 control systems are exposed to the myriad threats that lurk in cyber space, including viruses, worms
2851 and Trojans. Poor control-system architecture, unfettered user access, and lax oversight of security
2852 policies and procedures have all combined to heighten the risk.
2853 Meanwhile, manuals and training videos on ICS are publicly available, and many hacker tools can
2854 be downloaded or purchased on the Internet. Cyber criminals need little systems knowledge to
2855 infiltrate ICS operations. For all these reasons, the number of control-system cyber-security
2856 incidents has escalated sharply.
2857 According to RISI, almost half of all cyber incidents across all industries were caused by malware,
2858 including viruses, worms and Trojans. But unauthorized access or sabotage by internal sources,
2859 such as disgruntled workers or contractors using access privileges to cause harm, rose
2860 considerably at the same time. Network anomalies also triggered failures in control -system
2861 equipment.
2862 The increasing inter-connectivity of control systems is equally important to industry since new
2863
benefits also bring new challenges. Open industrial networks that seamlessly coexist in broader
2864 Ethernet systems are being used to link various plant -wide control systems together and connect
2865 these systems into expansive, enterprise-level systems via the Internet. As the pace of control
2866 system and enterprise network architecture convergence quickens, industrial security depends on
2867 staying both flexible and vigilant and successfully controlling the space. What may be considered
2868 adequate protection today should evolve as vulnerabilities are identified and new threats emerge.

2869 The discovery of malware that specifically targets industrial control systems brought industrial
2870 security to the forefront in manufacturing. As a result, there is growing recognition of the risks and
2871 real-world threats that are capable of disrupting control system operation and adversely affecting
2872 safety.
2873
2876
2875
2874
ISA99, WG03
87

ISA-624431-1, D6E2, September 2016
2877 BIBLIOGRAPHY
2878 NOTE This bibliography includes references to sources used in the creation of this standard as well as references to
2879 sources that may aid the reader in developing a greater understanding of cyber security as a whole and developing a
2880 management system. Not all references in this bibliography are referred to throughout the text of this standard. The
2881 references have been broken down into different categories depending on the type of source they are.
2882 [1] ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards
2883 [2] ISO/IEC 15408-1 (Common Criteria)
2884 [3] ANSI/ISA-95.00.01-2000, Enterprise-Control System Integration Models and
2885 Terminology, Clause 5 (Hierarchy Models)
2886
2887 Annex A Zones and Conduits Examples

2888 A.1 Introduction
2889
2890 A.2 Untrusted Conduits

2891 Untrusted conduits are those that are not at the same level of security as the zone endpoint. In this
2892 case the security of the communication becomes the responsibility of the individual channel. This
2893 is illustrated in Figure xx.
Enterprise Zone
Laptop computer Workstation Mainframe Server Server

Enterprise Conduit
Plant A Zone Plant B Zone Plant C Zone
Laptop computer Workstation Laptop computer Workstation Laptop computer Workstation

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

App. Data Maint. Firewall App. Data Maint. Firewall App. Data Maint. Firewall
Plant Control Conduit Plant Control Conduit Plant Control Conduit

2894
2895 Figure A-1 Conduit Example
2896 This figure represents a three-plant organization with a separate corporate headquarters. The three
2897 plants are connected to the enterprise network to allow communications to headquarters and the
2898 other plants. Four possible conduits are defined in the drawing (others would also be defined, but
2899 are skipped for brevity). The first is the enterprise conduit, shown at the top of the figure. It connects
2900 multiple plants at different locations to the corporate data center. If the wide area netwo rk (WAN)
2901 is constructed using leased or private communications, then it could be considered a trusted
2902 conduit. If it uses both public and private networks, then it may be classified as untrusted. Included
2903 in the conduit is all of the communications equipment and firewalls that make up the plant links.
2904 Instances of the second conduit class are shown in each plant. Here each of the plants has its own
2905 trusted conduit to allow control communication.
2906 A.3 Multi-Plant Model

2907 A simplified multi-plant zone model is shown in Figure xx. Here the plant zone are the parents, and
2908 each plant control zone is a child contained within the plant subzone.
2909 I believe that the notion of parent and child only applies to the Plant zones and to the Plant Control zones.
2910 NOTE: There is a distinct advantage to aligning zones with physical areas or zones in a facility for example, aligning
2911 a control center with a control zone.
Enterprise Zone
Laptop computer Workstation Mainframe
Server Server


2912
2913 Figure A-2 Multi-plant Zone Example
2914 A.4 (Description)

2915 The same enterprise architecture could be grouped into separate zones as in Figure xx. In this
2916 model, the zone policies would be independent, and each zone could have totally different security
2917 policies.
Enterprise Zone

Firewall Firewall

Firewall


2918
2919 Figure A-3 Separate Zones Example
2920 A.5 SCADA Applications

2921 Similar models can be constructed for SCADA applications, as shown in Figures xx and xx.
Enterprise Zone
Server Server
Control Center Backup Control Center

Firewall
WAN
App. SCADA SCADA App. SCADA
SCADA
Server Server Server
SCADA System Zone

Communications Communications
Processor Processor
Serial orf IP
SCADA Network
WAN
Satellite
Radio / Microwave / Public /Private Network
Cellular Network Telephone Network
Network Network Network Network

Local HMI Interface Local HMI Interface Local HMI Interface Local HMI Interface
RTU or PLC RTU or PLC RTU or PLC RTU or PLC
I/O I/O I/O I/O
Site A Control Zone Site B Control Zone Site X Control Zone Site Y Control Zone
2922
2923 Figure A-4 SCADA Zone Example
Enterprise Zone
Server Server
Primary Control Center Backup Control Center

Zone Zone
Firewall
WAN
App. SCADA SCADA App. SCADA
SCADA
Server Server Server Server Server
Server
SCADA System Zone

Communications Communications
Processor Processor
Serial or IP
SCADA Network
WAN
Satellite
Radio / Microwave / Network
Public /Private
Cellular Network
Telephone Network
Network Network Network Network

Local HMI Interface Local HMI Interface Local HMI Interface Local HMI Interface
RTU or PLC RTU or PLC RTU or PLC RTU or PLC
I/O I/O I/O I/O
Site A Control Zone Site B Control Zone Site X Control Zone Site Y Control Zone
2924
2925 Figure A-5 SCADA Separate Zones Example
2926 The enterprise conduit is highlighted in Figure xx.

Enterprise Zone
Server Server Server Server Server Server



2927
2928 Figure A-6 Enterprise Conduit
2929 Just as with zones, a similar view can be constructed for use in SCADA applications. An example
2930 is shown in Figure xx.
2933
2932
2931
ISA99, WG03
95
Figure A-7 SCADA Conduit Example

2934 Annex B Truck Loading Description

2935 B.1 Introduction
2936 The example system is a control system for a chemical truck loading facility. The facility is a self -
2937 service loading station where drivers of chemical tanker trucks can drive in, connect a dispensing
2938 arm to the tanker inlet, and initiate the filling of the truck throu gh a local operator panel. There is a
2939 central control room for the facility where full time operators can also monitor and control the
2940 process. However, the primary role of the operators is to operate the chemical manufacturing
2941 process.
2942 A system architecture diagram is shown below in Figure B-1. The architecture selected is means
2943 to represent a fairly modern design that is typical of what is found in many plants today. There are
2944 some cybersecurity controls in place but there are int entionally several vulnerabilities in the design.
IT Data Center
Corporate

Domain
Data Controller WAN
Historian
Enterprise
Firewall
Business LAN
Business
LAN
Control Room Operator Operator

Consoles Consoles
PCN
Equipment Room
SIS
Engineering DCS Server DCS Server
Workstation BPCS
Engineering
Workstation
PCN
` `
PCN
FS-PES Control PES
Field
BPCS HMI
2945
2946 Figure B-1 Chemical Truck Loading Control System Architecture Diagram
2947 B.2 Process Description

2948 The first step in the process is to identify the System -under-Consideration (SuC).
2949 Figure B-2 is an illustration of the system delineating the boundary of the SUT.
IT Data Center
Corporate
Domain
Data Controller WAN
Historian
Enterprise
Firewall
Business LAN
Business
LAN
Control Room Operator Operator
Consoles Consoles

PCN
Equipment Room
SIS
Engineering DCS Server DCS Server
Workstation BPCS
Engineering
Workstation
PCN
` `
PCN
FS-PES Control PES
Field
BPCS HMI
2950
2951 Figure B-2 Chemical Truck Loading System with Definition of SUT Boundary
2952 The organization shall perform a high-level risk assessment of the assets within the SuC (per
2953 ISA99.02.01:2009 Clause 4.2.3.1-4) to determine financial and health, safety and environmental
2954 (HSE) impact based on function, location, and potential consequences.
2955 Based upon the risk assessment (HAZOP) performed on the chemic al truck loading facility, the
2956 worst-case credible scenario is that the system attempts to fill a truck when there is not one present
2957 which would result is a large release of hazardous and flammable material. Under certain
2958 conditions, it is possible for the vapor cloud to ignite and explode. Fire suppression systems in the
2959 facility may be able to prevent the explosion and mitigate the damage if they react in time. While
2960 there are several interlocks in place designed to prevent this scenario, they are all ca pable of being
2961 bypassed by the control or safety system. A local operator or truck driver has the ability to initiate
2962 an emergency-stop that is hard-wired to interrupt power to the system. However, there are several
2963 scenarios where the local operator or truck driver fails or is unable to react in time to prevent the
2964 worst case consequence.
2965 There are several more scenarios that can result in lower category consequences such as:
2966 A small spill

2967 Theft
2968 Inability to load tanker
2969 Under-filling
2970 Incorrect record keeping (or loss of record)
2971 Using the following tables (Table A.1, A.2) we will perform a cybersecurity risk assessment on the
2972 control system.
2973 Table B-1 Typical Likelihood Scale
2974
If required in the final document, this table will be redrawn to confirm to the necessary conventions.

2975
2976 If required in the final document, this table will be redrawn to confirm to the necessary conventions.
2977 Table B-2 Typical Consequence Scale
2978
2979 Figure B-3 shows a diagram of the major components of a chemical truck loading station to illustrate
2980 how the requirements related to the zones and conduits concepts can be used for doing risk
2981 assessments or consequence analyses. This figure also is intended to clarify some of the
2982 terminology used.
2983 If required in the final document, this figure will be redrawn to confirm to the necessary conventions.
2984
2985 Figure B-3 Diagram of major components for chemical truck loading example
2986
2987 We start by creating a table of the assets in the control system
2988 Table B-3 Table of Assets

Consequence Likelihood
IACS Device Asset Risk Rating
Rating Rating
DCS Engineering Workstation B H High
SIS Engineering Workstation A M High
Data Historian B M Med
Maintenance Workstation B M Med
FS-PES A L Med
Domain Controller B M Med
Firewall B M Med
Operator Stations B M Med
Control PES B L Med
DCS Servers B M Med
DMZ Switch B L Low
BPCS HMI C L Low
PCN Switch(es) B L Low
2989
2991
2992
2993 Table B-4 Typical Risk Level Matrix
2995
2996 NOTE: The External Network shown in the diagram above represents all networks external to the SuC, so could be a
2997 companys enterprise network, which in turn would be connected to external networks, including the Internet. The SuC
2998 shown here encompasses all parts of the plant that are to be modeled using zone s and conduits.
2999 In order to provide clearer descriptions of concepts and boundaries that are significant for
3000 explaining security issues and areas of responsibility, the following hierarchy is proposed.
3001 Significant networks in a company can be arranged with the enterprise network at the highest level.
3002 This network serves the entire company and includes office automation support and
3003 communications needed for the business side and managed by the Information Technology (IT)
3004 Department. The business side includes financial, procurement, legal, and administrative activities.
3005 An Office Automation Network (OAN) supports these office automation activities.
3006 The technical operations part of the company includes the industrial automation and control
3007 systems (IACS) support, most of which is managed by an Industrial Automation (IA) Department or
3008 control systems group. The IACS includes the system under consideration (SuC) and technical
3009 support for it. Both the SuC and additional organizational support (policies, guidelines , operator
3010 training activities, etc.) which all combine to make up the IACS are also connected to the enterprise
3011 network through a firewall.
3012 As a practical matter the IACS should include all assets needed to maintain normal plant operations
3013 in stand-alone mode should it be necessary to disconnect the IACS from all external networks
3014 during a sustained cyber attack (a period of time that could last weeks).
3015 The system under consideration (SuC) consists of the control system zone and everything
3016 contained in it, the router or firewall conduit separating the control system zone and plant network
3017 zone, the plant network zone, and the router/firewall separating the plant network from the company
3018 enterprise network. The SuC in this example shows a hierarchy of zones contained in zones (zone
3019 nesting is allowed) and conduits within zones.
3020
An initial high level risk assessment identifies the most significant vulnerabilities at the SuC level
3021 affecting the station as a whole such as a large catastrophic release of chlori ne gas (a very bad
3022 leak), physical damage from a large explosion or major rupture of a tank, and access restrictions
3023 to support maintaining the physical integrity of the station and its operation.
3024 The control system (PLC) network is isolated from the plant network by a router/firewall, even
3025

though both are part of the SuC, in order to reduce risks associated with a potentially very
3026 hazardous operation (transfer of chlorine gas).
3027 In the example considered here activities supported on the plant network are mo deled using zones
3028 and conduits and are included in the consequence assessment (risk analysis) with associated
3029 assignment of security assurance levels (SALs) that must be met. Once the facility is in operation,
3030 management of the plant network activities could be done either by the IT or IA parts of the
3031 organization. A major IT objective is usually protection of information while a major objective for an
3032 industrial automation application (control system) is protection of and availability of the plant (in
3033 this example the ability at all times to control operation of the loading station). A control system
3034 often has hazardous energy sources which are not part of an office automation environment.
3035 It will be important to have IT participation at some level in the z ones and conduits modeling and
3036 consequence assessment activities. Roles and responsibilities of plant personnel in both areas (IT
3037 and IA) need to be clearly defined. Network monitoring and management goals may be different,
3038 so need to be defined. Likewise, things like patch management, system testing, and upgrades to
3039 software and operating systems.
3040 Step 3: Identify Zones & Conduits

3046
3045
3044
3043
3042
3041
Name and/or unique identifier

ISA-62443-1-1, D6E2, September 2016
Step 4: Document Security Requirements

102
Figure B-4 Zone and Conduit Identification

ISA99, WG03
3047 Logical boundary
3048 Physical boundary, if applicable
3049 List of all access points and associated boundary devices
3050 List of data flows associated with each access point
3051 Connected zones or conduits
3052 List of assets and associated consequences
3053 Security Level Target
3054 Applicable security policies
3055 Assumptions and external dependencies

3056 Table B-5 Zone Characteristics
Name and/or unique identifier Process Control Zone
Logical boundary This zone interfaces with the Process Information Zone,
Process Safety Zone and Process Measurement Zone
through 3 distinct conduits
Physical boundary, if applicable The Process Control Zone is physically located within the
equipment room
List of all access points and associated boundary devices Logical Access Points:
Process Safety / Process Control Conduit

Process Operations / Process Control Conduit
Process Control / Process Measurement
Conduit
Physical Access Points
Door to Equipment Room

List of data flows associated with each Logical Access Process Safety / Process Control Conduit:
point
Read-only status of safety system variables to
Control System Servers for display on Operator
Stations
Process Operations / Process Control Conduit:
Read-only status of Control PES variables for

display on Operator Stations
Data writes from Operator Stations to Control
PES (e.g. setpoint changes)
Process Control / Process Measurement Conduit
Two-way flow of data between Control PES and

field HMI panel and remote I/O.
Connected zones Process Operations Zone

Process Safety Zone
Process Measurement Zone
List of assets and associated consequences DCS Servers B (Medium)
DCS Engineering Workstation - B (Medium)
CLAN-2 Switch - B (Medium)
Control PES - B (Medium)
Security Level Target Medium
Applicable security policies
Assumptions and external dependencies
3057 Figures B-17 and B-18 show high-level examples of systems broken down into zones connected
3058 by conduits. Figure B-17 is a graphical representation of a control system for a chlorine truck
3059 loading station. It has three zones defined: the control system, the safety integrated system (SIS),

3060 and the plant network. The control system and SIS both use programmable logic controllers (PLCs)
3061 to operate different aspects of the loading station. The two PLCs are connected via a non -routable
3062 serial Modbus network.
3063
3064 Figure B-5 Process Industry Example Showing Zones and c\Conduits
3065 Figure B-18 is a graphical representation of a manufacturing plant. It has four zones defined: the
3066 enterprise network, the industrial/enterprise demilitarized zone (DMZ), and two industrial networks.
3067 The enterprise infrastructure has a wireless local area network (WLAN) and a conn ection to the
3068 Internet. Many companies use a DMZ between important parts of their systems to isolate the
3069 network traffic. In this particular example, each industrial network operates relatively independent
3070 of each other with its own PLC, field devices, and human-machine interface (HMI).
3071
3072 Figure B-6 Manufacturing Example Showing Zones and Conduits
3073 After determining the target SALs, the system can be designed (green field) or redesigned (brown
3074 field) to try to meet those target SALs. The design process is usually an iterative approach where
3075 the system design is checked against the target multiple tim es throughout the process. Multiple
3076 parts of the ISA99 series of standards contain guidance on different aspects of the programmatic
3077 and technical requirements that go into the design process. ISA62443-2-1 provides guidance on
3078 the programmatic aspects of the design process while ISA62443-3-3 and ISA62443-4-2 define
3079 system-level and component-level technical security requirements and relate them to different
3080 capability SALs.
3081 During the design process for a system, it is necessary to evaluate the security capabilities of
3082 different components and subsystems. Vendors will have to provide these as capability SALs for
3083 their products by comparing product features and capabilities with the requirements defined in the
3084 ISA62443 series for the different capability SALs. These capability SALs can be used to determine
3085 whether a given system or component is capable of meeting the target SAL for the system. The
3086 vendor or system integrator will also have to provide guidance on how to configure the component
3087 or subsystem to meet the claimed SALs.
3088 It is likely that in a particular design there will be some components or systems that cannot fully
3089 meet the target SAL. Where the capability SAL of a component or system is lower than the target
3090 SAL, compensating controls need to be consider ed to meet the desired target SAL. Compensating
3091 controls may include changing the design of the component or system to increase its capabilities,
3092 choosing another component or system to meet the target SAL, or adding additional components
3093 or systems to meet the target SAL. After each iteration, the system design SALs should be
3094 reevaluated to see how they compare to the target SALs for the system.
3095 Once the system design is approved and implemented, the system needs to be evaluated to prevent
3096 or mitigate deterioration of the systems security level. It should be evaluated during or after system
3097 modifications and on a regular schedule. ISA62443-2-1 and ISA62443-2-2 provide guidance on
3098 the steps necessary to operate the security program and how to evaluate its effectiveness. After
3099 the achieved SALs have been determined, it will be necessary to evaluate whether the system is
3100 still meeting the original target SALs (e.g. using th e system requirements from ISA62443-3-3). If
3101 the system is not meeting those requirements, there may be multiple reasons including the lack of
3102 maintenance of the program or the need to redesign parts of the syste m.
3103 B.3 Safety and Security

3104 The specific area of interest from the safety prospective is facilitated by interlocks on the
3105 connections to the truck that assures recirculation of air via two separate hoses. The pumps cannot
3106 be turned ON unless there is a positive confirmation that the hoses are connected. If a hose is
3107 removed, it would automatically shut off the pumps. There is also a high -level protection switch that
3108 assures that if the chemical tank is at a certain level that is automatic shuts off the pumps. Th ere
3109 is also gas detection a truck unloading area and any place along the injection lines to the equipment
3110 that will use the chemical. If there is an alert, it will automatically shut down the pumps and signal
3111 the operator. In some processes where the chemical is being injected into a burning process for
3112 example, the emissions are monitored. This would be the case when a hazardous chemical is being

3113 used as part of any part of a process.
3114 The safety system must be tested prior to commissioning of the system b y circulation and injection
3115 of water to determine if there are any leaks. Otherwise, the hazardous chemical or gases could
3116 escape and create a unsafe condition for personnel the system should also have a flush cycle to
3117 inject water once again to flush the hazardous chemical out of the lines. This system must all be
3118 tested to assure proper operation. Emissions monitoring is extremely important in these types of
3119 applications where the gases can be released into the air, into the ground, or nearby bodies of
3120 water. This would put the plant at risk for OSHA or MSHA violation including EPA emissions
3121 violation, which all would be punishable by fines. Personal injury prevention is important so if any
3122 action has consequence that would expose personnel or if release i nto the air or water it may affect
3123 people many miles from the facility. Spill control is also important safety relevant condition so run
3124 off monitor and positioning of eyewash stations must be monitored and provide alerts to operations,
3125 which may include key personnel. Personal training is done for safety conditions including lockout
3126 and wearing proper safety gear but there is no explanation of security concerns other than potential
3127 limitation of use of cell phones and other radios in a particular area. The re is always a need to have
3128 an emergency shutdown and those conditions must be evaluated since immediate shutdown of a
3129 control system must be able to recover form unexpected or an emergency shutdown.
3130 In some process these alerts may extend to monitor when the take is low since a hazardous
3131 chemical may be an integral part of a production process to reduce NOX emissions for example. In
3132 these situations, the monitoring of a 30-day average may be important to maintain EPA compliance.
3133 Process operation many need to be changed to assure the long-term accumulation of release of
3134 toxic gases into the air many mean that there will be an even wider effect related to use of
3135 hazardous chemicals, which are needed as part of a productions process. There may be other
3136 instruments including sensors that may exist to detect unsafe conditions and can provide
3137 notification to operator.
3138 The use of hazardous chemicals in a process requires that all aspects of a system must operate
3139 perfectly since they cannot be allowed to operate i n a reduced capacity. Consequently, the system
3140 will have interlocks that prevent startup and will force a shutdown if those permissive are lost or
3141 changed. There are other conditions such as power and water supplies that now become critical
3142 which under normal operation they could be operated at a reduced capability.
3143 The backup power systems should be monitored. Sufficient water and air for pneumatic devices
3144 must be monitored and frequently checked to assure that they are operating properly. There is
3145 limited leeway and having an ample supply of power, water, and air are essential for plant
3146 operations especially if used in safety operations. Generally, physical security was the only
3147 consideration and there is no requirement or standard to provide assurance tha t restriction of
3148 packets that could adversely affect operations and impact safety of those systems.
3149 It is important to define the safety aspects to recognize what can be the impact. The security
3150 aspects need to provide protection against intrusion and alte ration of operations. This may include
3151 confidentiality if knowledge of those conditions or restriction to access of that system needs further
3152 restriction. The end devices are generally vulnerable since the protection against cyber
3153 infringement due not exists. Consequently, new capabilities are need to isolate those operations
3154 yet providing a means to facilitate a dialog with other devices, user, and applications that are trusted
3155 to view or control operations of security-safety related systems.
3156
3157 Annex C Example: Procedure to apply foundational requirements

3158 C.1 Overview
3159
3160 C.1.1 Description of example system under consideration
3161 Figure C-1 shows a chemical truck loading station, where a Programmable Logic Control ler (PLC)
3162 is used to control the loading of liquid chlorine, a hazardous chemical, from a storage tank to a tank
3163 truck. For the purpose of this example, this is the system under consideration (SuC).
3164 If required in the final document, this figure will be r edrawn to confirm to the necessary conventions.
3165
3166 Figure C-1 Example application - Chemical truck loading station
3167 Components of the IACS include:
3168 Field instruments such as flow sensors and transmitters, valves, motor control for pumps.
3169 PLC system including power supplies, CPU, and interface modules for field signals.
3170 Workstations for operation, supervision, maintenance and engineering.
3171 Communication infrastructure including switches and firewalls.
3172 C.1.2 Technical Approach
3173 Objective
3174 The objective of this example is show how the foundational requirements are applied to an example
3175 problem - in this case, the chemical loading truck station.
3176 Assumptions
3177 It was assumed that ISA62443-3-3 is applied throughout the life-cycle of the security architecture.
3178 Therefore, the target, design, achieved and measured system security assurance level needed to
3179 be addressed. At each stage in the life-cycle, all 4 levels are included to provide a comparison and
3180 basis for system security assurance level selection.
3181 In C.1.2.3, the selection is based on reviewing company policy and the AC guideline provided in
3182 ISA62443-3-3.
3183 In C.2.1 the selection is based on FR1 AC3 and the add ed security strength requirements to
3184 discriminate between system security assurance levels. System security assurance is designated
design because the additional detail provides information needed for the build -to decision.
3185
3186 In C.2.2 and C.3 the selection is based on the same information described previously, but now
3187 given an installed security architecture which has been validated after site acceptance testing and
3188 commissioning. This is designated time t0 and the system security assurance is now lab eled
3189 achieved.

3190 In C.4, the maintenance life-cycle phase includes comments regarding system security compliance
3191 metrics and the designation is labeled measured based on assessment of measured performance.
3192 Consequence analysis
3193 It is interesting to note that the selected requirements from does not mention consequence
3194 analysis per se. This example assumes that consequence analysis occurs throughout the life -
3195 cycle. It is not a one-time analysis. Each time it is performed the parameters of the consequence
3196 analysis are somewhat different.
3197 For example, when developing a company policy, a consequence analysis of sufficient depth is
3198 needed to establish the policies and procedures and provided sufficient guidance to establish the
3199 target security assurance level for the SuC.
3200 When the security architecture is selected (design), a consequence analysis is repeated with
3201 parameters that reflect the capability of enabling security mechanisms.
3202 When installed and commissioned (achieved) at time t0, a consequenc e analysis is repeated to
3203 account for any variance between design expectations and real capability that has been verified by
3204 testing & analysis for commissioning.
3205 Lastly, during maintenance of the installed security architecture, a consequence analysis is
3206 repeated based on collected measurements of performance and other reports required by
3207 ISA62443-1-3. Practical experience has shown that deviations from the norm (what was expected)
3208 may or may not have an impact on the assessed consequence.
3209 Selected application of ISA62443-3-3 to the system under consideration
3210 ISA62443-3-3 defines the guidelines to apply assessment criteria. Fo r this example (Figure C-1),
3211 tailored for IACS application, the AC-3 guideline is prescribed in terms of control with supplemental
3212 guidance.
3213 Control: The Industrial Automation Control System shall provide the capability to en force assigned
3214 authorizations for controlling access to the system in accordance with applicable policy.
3215 Supplemental guidance: Access control policies (e.g., identity-based policies, role-based policies,
3216 rule-based policies) and associated access enforcement mechanisms (e.g., access control lists,
3217 access control matrices, cryptography) are employed by organizations to control access between
3218 users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes,
3219 programs, domains) in the IACS. In addition to controlling access at the information system level,
3220 access enforcement mechanisms are employed at the application level, when necessary, to provide
3221 increased information security for the organization. Consideration is given to the implementation of
3222 a controlled, audited, and manual override of automated mechanisms in the event of emergencies
3223 or other serious events. If encryption of stored information is employed as an access enforcement
3224 mechanism, the cryptography used is FIPS 140-2 (as amended) compliant.
3225 For this example, a review of company policies and procedures determined that the organization
3226 explicitly defines privileged functions and security-relevant information for the IACS. Furthermore,
3227 the organization explicitly authorizes personnel access to privileged functions and security-relevant
3228 information in accordance with organizational policy. And, the IACS restricts access to privileged
3229 functions (deployed in hardware, software, and firmware) and security -relevant information to
3230 explicitly authorized personnel (e.g., security administrators). Lastly, automated test mechanism
3231 implementing access enforcement policies are widely deployed.
3232 For these reasons, access enforcement requires security assurance which is constrai ned by the
3233 need to ensure IACS operational availability, comply with the need to ensure public and
3234 environmental safety, guard against total system failure and to guard against the possibility of loss
3235 of life. Based on the installed operational concept, th e asset owners senior management states

3236 that for this example, the following target system security assurance levels ( ) which are
3237 subject to verification by the system integrator; and if required, a recognized certification autho rity:

3238 = 1: IACS security functions are not mission critical and are not the target of
3239 adversarial threats.

3240 = 2: IACS security functions are not mission critical, but are the target of

3242 = 3: IACS security functions are mission critical, are the target of adversarial
3243 threats, do not require immediate response, but disruption could result in significant
3244 performance and financial impact resulting from the total failure of IACS operating
3245 capability.

3246 = 4: IACS functions are mission critical, are the target of adversarial threats, but
3247 require immediate response to ensure public and environmental safety resulting from
3248 the total failure of IACS operating capability or loss of life.
3249 Focus on Access Enforcement
3250 Design (build-to) security assurance level
3251 An example of mapping this methodology to the IACS security requirements for Figure C -1 is
3252 described in this clause. For the purpose of this example, the design security assurance levels
3253 S_system^design are based on selected (build-to) security architecture.
3254 FR 1: Access Control (AC)
3255 ISA62443-3-3 AC-3: Access Enforcement (AE)
3256 Requirement: The IACS shall provide the capability to enforce assigned authorizations for
3257 controlling access to the system in accordance with applicable policy.
3258 Rationale/Supplemental Guidance: Access control policies (e.g., identity-based policies, role-
3259 based policies, rule-based policies) and associated access enforcement mechanisms (e.g., access
3260 control lists, access control matrices, cryptography) are employed by organizations to control
3261 access between users (or processes acting on behalf of users) and objects (e.g., devices, files,
3262 records, processes, programs, domains) in the IACS. In addition to controlling access at the system
3263 level, access enforcement mechanisms are employed at the application level, when necessary, to
3264 provide increased information security for the organization. Consideration is given to the
3265 implementation of a controlled, audited and manual override of automated mechanisms in event of
3266 emergencies or other serious events. The organization ensures that access enforcement
3267 mechanisms do not adversely impact the operation performance of the IACS.
3268 Requirement Enhancement (RE-1): The IACS shall provide the capability to restrict access to
3269 privileged functions (deployed in hardware, software, and firmware) and security -relevant
3270 information to explicitly authorized personnel.
3271 Enhancement Rationale/Supplemental Guidance: Explicitly authorized personnel must include,

3272 for example, IACS operators, security administrators, system and communication network
3273 administrators, and other privileged users. Privileged users are individuals who have access to
3274 system control, monitoring, or administration functions (e.g., systems administrators, SAS security
3275 officers, maintainers, system programmers).
3276
Requirement Enhancement (RE-2): The IACS shall provide the capability for dual authorization,
3277 based on approved organization procedures, to privileged functions that have impacts on facility,
3278 human, and environmental safety.
3279
RE-2 Security Strength 0: No explicit security strength is mandated.
3280 RE-2 Security Strength 1: Organization with functional responsibility shall sign -off (approval) on

3281 access privileges.
3282 RE-2 Security Strength 2: Senior management with oversight responsibility of the functional
3283 organization responsible shall sign-off (approval) on access privileges.
3284 Enhancement Rationale/Supplemental Guidance: The organization does not employ dual-
3285 approved mechanisms when an immediate response is necessary to ensure human and
3286 environmental safety.
3287 Design System Security Assurance Levels:

3288 = 1: FR-1, 800-53 AC-3 with security strength 0

3289 = 2: FR-1, 800-53 AC-3, RE-1 and RE-2 with security strength 0

3290 = 3: FR-1, 800-53 AC-3, RE-1 and RE-2 with security strength 1 (note, reserved for
3291 possible total system failure)

3292 = 4: FR-1, 800-53 AC-3, RE-1 and RE-2 with security strength 2 (note, reserved for
3293 possible total system failure or loss of life)
3294 This example illustrates the caveat which states that RE-1 and RE-2 may not provide sufficient

3295 discrimination to differentiate between assignments. Furthermore, the aggregation of

3296 =1, 2, 3 or 4 contributed by each zone, conduit, or class of device shown above depends on
3297 the implementation of ISA-99.03.02 (security assurance levels for zones and conduits), ISA -
3298 99.01.03 (system security compliance metrics), ISA -99.03.04, ISA-99.04.01.. 04 (derived
3299 requirements for classes of components). Is important to remember that allocation of system
3300 security assurance to zones, conduits and classes of components, as well as aggregation of
3301 security assurance provide by elements of the SuC are not within the scope of ISA62443-3-3.
3302 C.1.3 Achieved security assurance level

3303 Based on a review of company policies and procedures it was determined that the organization
3304 explicitly defines privileged functions and security-relevant information for the IACS. Furtherm ore,
3305 the organization explicitly authorizes personnel access to privileged functions and security -relevant
3306 information in accordance with organizational policy. And, the IACS restricts access to privileged
3307 functions (deployed in hardware, software, and fir mware) and security-relevant information to
3308 explicitly authorized personnel (e.g., security administrators). Lastly, automated test mechanism
3309 implementing access enforcement policies are widely deployed.
3310 For these reasons, access enforcement requires secur ity assurance which is constrained by the
3311 need to ensure IACS operational availability, comply with the need to ensure public and
3312 environmental safety, guard against total system failure and to guard against the possibility of loss
3313 of life. Based on the installed security architecture, the asset owner now states for the example,

3314 the following achieved system target security levels ( ) which are subject to verification:

3315 = 1: IACS security functions are not mission critical and are not the target of

3317 = 2: IACS security functions are not mission critical, but are the target of

3319 = 3: IACS security functions are mission critical, are the target of adversarial
3320 threats, do not require immediate response, but disruption could result in significant
3321 performance and financial impact resulting from the total failure of IACS operating
3322 capability.

3323 = 4: IACS functions are mission critical, are the target of adversarial threats, but
3324 require immediate response to ensure public and environmental safety resulting from

3325 the total failure of IACS operating capability or loss of l ife.
3326 Furthermore, the asset owner states that all metrics for this example are subject to the following
3327 considerations:

3328 All = 1 metrics are limited to applications related to protection of company data.

3329 All = 2 metrics are limited to applications subject to threat.

3330 All = 3 metrics are applicable to performance constrained mission critical
3331 applications that can result in total system failure.

3332 All = 4 metrics are applicable to mission critical applications that can result in loss
3333 of life.
3334 C.2 System security assurance when commissioned

3335 Subject to all conditions described in C.1.3, when the security architecture has been implemented
3336 and all site acceptance testing is complete, the achieved system security assurance level is

3337 (t 0 ) = 4.
3338 In retrospect, the Asset Owners senior management could have stated that their goal was to design

3339 and install a security architecture that could be rated (t 0 ) = 4. Then, when the design was
3340 complete, by analysis the system integrator could state that the build -to system security assurance

3341 is (t 0 ) = 4. As a cross check the system integrator could sum the contribution of each zone
3342 and conduit security assurance using the calculation procedure specified in ISA -99.03.02.
3343 C.3 System security assurance during after commissioning

3344 If security is maintained in accordance with ISA-99.02.02 and quantitative metrics described in ISA-
3345 99.01.03 are collected and automatically processed in a timely manner, the measured system
3346 security assurance can be assessed on a regular basis using the same procedures described in

3347 C.2. The result should be labelled (t) = f(processed metrics). When (t) degrades
3348 to an unacceptable level (a value determined by the Asset Owner), corrective action is required to
3349 plus-up the system security assurance. Guidance for plus -up action is described in ISA-99.01.03
3350 for each system metric.
3351
3352 Annex D Key Management

3353 D.1 Introduction
3354 Understanding key management first requires an insight into the life cycle for the keys that are part
3355 of a key management schema. Fundamentally, a key is a piece of auxiliary information that changes
3356 the detailed operation of an encryption algorithm. A key should be selected before using an
3357 encryption algorithm to encrypt an IACS message or piece of information. Without knowledge of
3358 the key, it should be difficult, if not impossible, to decrypt the resulting ciphertext into human or
3359 machine readable plaintext.
3360 A life cycle may begin with a crypto-period for the keys which describes the life stages (key states)
3361 from creation to revocation and disposal. IACS operations run 24/7 which depends on continuous
3362 availability of critical communication resources. For this reason, special attention needs to be given
3363 to the requirements for timely disposition of keys described by the system triggers shown in Figure
3364 1.

3366
3367 Figure D-1 Key management life cycle
3368 D.2 Generation and distribution of keys

3369 Generation and distribution of keys that maintain the secret value afforded the key is provided in a
3370 timely manner to support 24/7 P&C operations. A key management schema or system is only
3371 effective if something (usually the key but could be an encryption algorithm) is secret. How to
3372 maintain the secret across widely geographically dispersed IACS operational entities and unknown
3373 entities becomes the challenge for a key management design. So, generating a key for which that
3374 key may have a wide breath of use or a very narrow use leads to defining an effective distribution
3375 channel. The channel can be a physical channel such as a courier or equivalent, the channel can
3376 be an electronic channel such as the Internet which should not be trusted. The means used to
3377 distribute the keys is largely determined by the timeliness requirements imposed by critical IACS
3378 operations that require high security.
3379 Except in simple IACS operations where key components remain fixed for all time, crypto -periods
3380 are needed for keys, and these keys need to be updated periodically. The time frame for a key to
3381 be used varies. The crypto-period of a key is the time period during which the key is valid for use
3382 by legitimate human and non-human entities. Crypto-periods serve to:
3383 Limit the information (related to a specific key) available for cryptanalysis;
3384 Limit exposure in the case of compromise of a single key;

3385 Limit the use of a particular technology to its estimated effective lifetime; and
3386 Limit the time available for computationally intensi ve cryptanalytic attacks (in IACS applications
3387 where long-term key protection is not required).
3388 D.3 Key State Phases

3389 IACS operation requires secure management of the keying material in all ke y state phases shown
3390 in Figure 1: pre-operational, operational, post-operational, and destruction. Furthermore, the key
3391 management system should provide a secure method to account for how the keys are maintained.
3392 Backup key management and key recovery becomes extremely important to maintain 24 /7
3393 operations when the primary key management system fails or is disconnected.
3394
3397
3396
3395
ISA99, WG03
115

3398 Developing and promulgating technically sound consensus standards and recommended practices
3399 is one of ISA's primary goals. To achieve this goal, the Standards and Practices Department relies
3400 on the technical expertise and efforts of volunteer committee members, chairmen, and reviewers.
3401 ISA is an American National Standards Institute (ANSI) accredited organization. ISA administers
3402 United States Technical Advisory Groups (USTAGs) and provides secretariat support for
3403 International Electrotechnical Commission (IEC) and International Organization for Standardization
3404 (ISO) committees that develop process measurement and contr ol standards. To obtain additional
3405 information on the Society's standards program, please write:
3406
3407 ISA
3408 Attn: Standards Department
3409 67 Alexander Drive
3410 P.O. Box 12277
3411 Research Triangle Park, NC 27709

3412
3413 ISBN: -to-be-assigned-
3414

Isa 62443 1 1 WD

Uploaded by

Copyright:

Available Formats

Isa 62443 1 1 WD

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Isa 62443 1 1 WD

Uploaded by

Copyright:

Available Formats

IS TO BE USED SOLELY FOR THE PURPOSES OF FURTHER DEVELOPMENT OF ISA STANDARDS, AND MAY NOT

New versions will be generated periodically as individual documents are revised.

12 Security for industrial automation and control systems

13 Models and Concepts

New versions will be generated periodically as individual documents are revised.

Name Company Contributor Reviewer

New versions will be generated periodically as individual documents are revised.

New versions will be generated periodically as individual documents are revised.

116 8.2 Reference Model ................................................................................................... 44

New versions will be generated periodically as individual documents are revised.

156 TABLE OF FIGURES

New versions will be generated periodically as individual documents are revised.

192 TABLE OF TABLES

New versions will be generated periodically as individual documents are revised.

New versions will be generated periodically as individual documents are revised.

246 1 Normative references

266 2 Terms, definitions, abbreviated terms, acronyms, and conventions

New versions will be generated periodically as individual documents are revised.

New versions will be generated periodically as individual documents are revised.

New versions will be generated periodically as individual documents are revised.

New versions will be generated periodically as individual documents are revised.

New versions will be generated periodically as individual documents are revised.

New versions will be generated periodically as individual documents are revised.

New versions will be generated periodically as individual documents are revised.

New versions will be generated periodically as individual documents are revised.

New versions will be generated periodically as individual documents are revised.

New versions will be generated periodically as individual documents are revised.

717 4. capability of a computer-based system to provide adequate confidence that unauthorized

New versions will be generated periodically as individual documents are revised.

New versions will be generated periodically as individual documents are revised.

New versions will be generated periodically as individual documents are revised.

862 2.2 Abbreviated terms and acronyms

ANSI American National Standards Institute

864 2.3 Conventions

866 2.3.1 Reserved terms

New versions will be generated periodically as individual documents are revised.

887 3 The ISA62443 series

New versions will be generated periodically as individual documents are revised.

915 3.2 Approach

922 3.3 Structure

927 3.4 Organization

948 ISATR62443-3-1 describes the application of various security technologies to an IACS

New versions will be generated periodically as individual documents are revised.

Asset Owner System Asset Owner Asset Owner

Project application Security measures and settings Decommissioning

Specification Integration / Commissioning Operation / Maintenance Decommissioning

965 3.6 Metrics

969 4 The Situation

974 4.2 Business Environment

New versions will be generated periodically as individual documents are revised.

1000 4.3.1 Business Benefits

New versions will be generated periodically as individual documents are revised.

1064 4.5 Potential Consequences

1069 unauthorized access, theft, or misuse of confidential information

1075 equipment damage

New versions will be generated periodically as individual documents are revised.

1093 4.7 Requirements

1095 4.7.1 GEN x.x Support of Essential Functions

1125 4.7.2.2 Rationale