ISA 62443 1 1 Draft

FOR REVIEW PURPOSES ONLY!
THIS DOCUMENT IS A WORKING DRAFT OF AN ISA99 COMMITTEE WORK PRODUCT. IT MAY NOT
BE ACCURATE OF COMPLETE AND IS SUBJECT TO CHANGE WITHOUT NOTICE.
IT IS PROVIDED SOLELY FOR THE PURPOSE OF REVIEW IN SUPPORT OF FURTHER DEVELOPMENT

OF COMMITTEE WORK PRODUCTS.
THIS DOCUMENT MAY NOT BE COPIED, DISTRIBUTED TO OTHERS, OR OFFERED FOR FURTHER
REPRODUCTION OR FOR SALE.
Copyright by the International Society of Automation. 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
2
1
August 2015
Draft 5, Edit 4
ISA-62443-1-1
Models and Concepts

Security for industrial automation and control systems
This document is a WORKING DRAFT of an ISA99 committee work product. It may not be accurate of complete and is subject to change without notice.
It is provided SOLELY for the purpose of review in support of further development of committee work products.
This document may not be copied, distributed to others, or offered for further reproduction or for sale.
5
4
3
ISA
ISA
America.
P. O. Box 12277
67 Alexander Drive
Models and Concepts
ISBN: -to-be-assigned-
ISA-62443-1-1, D5E4, August 2015
Research Triangle Park, NC 27709 USA

2
Security for industrial automation and control systems
Copyright 2015 by ISA. All rights reserved. Not for resale. Printed in the United States of
ISA99, WG03
ISA99, WG03 3 ISA-62443-1-1, D5E4, August 2015
6 PREFACE
7 This preface, as well as all footnotes and a nnexes, is included for information purposes and is
8 not part of ISA-62443-1-1.
9 This document has been prepared as part of the service of ISA, the International Society of
10 Automation, toward a goal of uniformity in the field of instrumentation. To be of real value, this
11 document should not be static but should be subject to periodic review. Toward this end, the
12 Society welcomes all comments and criticisms and asks that they be addressed to the
13 Secretary, Standards and Practices Board; ISA; 67 Alexander Drive; P. O. Box 12277;
14 Research Triangle Park, NC 27709; Telephone (919) 549 -8411; Fax (919) 549-8288; E-mail:
15 standards@isa.org.
16 The ISA Standards and Practices Department is aware of the growing need for attention to the
17 metric system of units in general and the International System of Units (SI) in particular, in the
18 preparation of instrumentation standards. The Department is further aware of the benefits to
19 USA users of ISA standards of incorporating suitable references to the SI (and the metric
20 system) in their business and professional dealings with other countries. Toward this end, this
21 Department will endeavor to introduce SI-acceptable metric units in all new and revised
22 standards, recommended practices and technical reports to the greatest extent possible.
23 Standard for Use of the International System of Units (SI): The Modern Metric System,
24 published by the American Society for Testing and Materials as IEEE/ASTM SI 10-97, and
25 future revisions, will be the reference guide for definitions, symbols, abbreviations, and
26 conversion factors.
27 It is the policy of ISA to encourage and welcome the participation of all concerned individuals
28 and interests in the development of ISA standards, recommended practices and technical
29 reports. Participation in the ISA standards-making process by an individual in no way
30 constitutes endorsement by the employer of that individual, of ISA or of any of the standards,
31 recommended practices and technical reports that ISA develops.
32 CAUTION ISA adheres to the policy of the American National Standards Institute with
33 regard to patents. If ISA is informed of an existing patent that is required for use of the
34 standard, it will require the owner of the patent to either grant a royalty -free license for
35 use of the patent by users complying with the standard or a license on reasonable
36 terms and conditions that are free from unfair discrimination.
37 Even if ISA is unaware of any patent covering this Standard, the user is cautioned that
38 implementation of the standard may require use of techniques, processes or materials
39 covered by patent rights. ISA takes no position on the existe nce or validity of any
40 patent rights that may be involved in implementing the standard. ISA is not responsible
41 for identifying all patents that may require a license before implementation of the
42 standard or for investigating the validity or scope of any patents brought to its
43 attention. The user should carefully investigate relevant patents before using the
44 standard for the users intended application.
45 However, ISA asks that anyone reviewing this standard who is aware of any patents that
46 may impact implementation of the standard notify the ISA Standards and Practices
47 Department of the patent and its owner.
48 Additionally, the use of this standard may involve hazardous materials, operations or
49 equipment. The standard cannot anticipate all possible applications or address all
50 possible safety issues associated with use in hazardous conditions. The user of this
51 standard must exercise sound professional judgment concerning its use and
52 applicability under the users particular circumstances. The user must also consid er the
53 applicability of any governmental regulatory limitations and established safety and
54 health practices before implementing this standard.
55
ISA-62443-1-1, D5E4, August 2015 4 ISA99, WG03
56 The following people served as active members of ISA99, Working Group 03, Task Group 0
57 for the preparation of this document:
58
Name Company Contributor Reviewer
Bruce Billedeaux Maverick Technologies
Eric Cosman OIT Concepts LLC
Jim Gilsinn Kenexis
Tom Good DuPont
Evan Hand Conagra Foods
Dennis Holstein OPUS Consulting Group
Jean-Pierre Hauet
Eric Hopp Rockwell Automation
Pierre Kobes Siemens
Jeff Potter Emerson Process Management
Ragnar Schierholz ABB
Leon Steinocher Consultant
Chris Stephens Fluor
Bradley Taylor The George Washington University/

NAVSEA
Donovan Tindill Honeywell
Rich Weekly Barr-Thorp Electric Co., Inc.
59
60
61 CONTENTS
62
63 PREFACE ............................................................................................................................... 3
64 FOREWORD ........................................................................................................................... 9
65 INTRODUCTION ................................................................................................................... 10
66 1 Scope ............................................................................................................................. 11
67 2 Normative references ..................................................................................................... 11
68 3 Terms, definitions, abbreviated terms, acronyms, and conventions ................................. 12
69 3.1 Terms and definitions ............................................................................................ 12
70 3.2 Abbreviated terms and acronyms ........................................................................... 24
71 3.3 Conventions .......................................................................................................... 24
72 4 The ISA62443 standards ............................................................................................... 25
73 5 The Situation .................................................................................................................. 27
74 5.1 Overview ............................................................................................................... 27
75 5.2 Business Environment ........................................................................................... 27
76 5.3 Current Systems .................................................................................................... 27
77 5.4 Current Trends ...................................................................................................... 28
78 5.5 Potential Consequences ........................................................................................ 29
79 5.6 Impact of Countermeasures ................................................................................... 29
80 5.7 Common Constraints ............................................................................................. 29
81 5.7.1 Support of Essential Functions .................................................................. 29
82 5.7.2 Compensating countermeasures ................................................................ 30
83 6 Security Elements ........................................................................................................... 30
84 6.1 Introduction ........................................................................................................... 30
85 6.2 People ................................................................................................................... 31
86 6.3 Processes ............................................................................................................. 32
87 6.4 Technology ............................................................................................................ 32
88 6.5 Use Cases ............................................................................................................. 33
89 6.6 Summary ............................................................................................................... 35
90 7 Roles and Responsibilities .............................................................................................. 35
91 7.1 General ................................................................................................................. 35
92 8 IACS Definition ............................................................................................................... 36
93 8.1 Functionality Included ............................................................................................ 36
94 8.2 Systems and Interfaces ......................................................................................... 37
95 8.3 Activity-Based Criteria ........................................................................................... 37
96 8.4 Asset-Based Criteria ............................................................................................. 37
97 8.5 Consequence-Based Criteria ................................................................................. 38
98 9 Models ........................................................................................................................... 38
99 9.1 General ................................................................................................................. 38
100 9.2 Reference Model ................................................................................................... 38
101 9.2.1 Level 4 Enterprise Business Systems ..................................................... 39
102 9.2.2 Level 3 - Operations Management ............................................................. 39
103 9.2.3 Level 2 Supervisory Control .................................................................... 39
104 9.2.4 Level 1 Local or Basic Control ................................................................ 39
105 9.2.5 Level 0 Process ...................................................................................... 40
106 9.3 Reference Architecture Model ............................................................................... 40
107 9.4 Zone Model ........................................................................................................... 41

108 10 General Concepts ........................................................................................................... 41
109 10.1
Security Context .................................................................................................... 41
110 10.2
Security Objectives ................................................................................................ 42
111 10.3
Least Privilege ...................................................................................................... 43
112 10.4
Defense in Depth ................................................................................................... 43
113 10.5
Threat-Risk Assessment ........................................................................................ 43
114 10.6
Policies and Procedures ........................................................................................ 43
115 10.6.1 General ..................................................................................................... 43
116 10.6.2 Enterprise Level ........................................................................................ 44
117 10.6.3 Operational Level ...................................................................................... 45
118 10.7 Topics Covered by Policies and Procedures .......................................................... 45
119 10.8 Key Management................................................................................................... 47
120 10.8.1 Introduction ............................................................................................... 47
121 10.8.2 Generation and distribution of keys ............................................................ 48
122 10.8.3 Key State Phases ...................................................................................... 49
123 11 Fundamental Concepts ................................................................................................... 49
124 11.1 Security Life Cycle ................................................................................................ 49
125 11.1.1 Introduction ............................................................................................... 49
126 11.1.2 Product life cycle ....................................................................................... 51
127 11.1.3 IACS Life Cycle ......................................................................................... 52
128 11.2 Maturity Levels ...................................................................................................... 54
129 11.2.1 Maturity Phases ......................................................................................... 55
130 11.3 Zones and Conduits .............................................................................................. 58
131 11.3.1 Introduction ............................................................................................... 58
132 11.3.2 Zones ........................................................................................................ 58
133 11.3.3 Conduits .................................................................................................... 58
134 11.3.4 Channels ................................................................................................... 59
135 11.3.5 Determining Requirements ........................................................................ 59
136 11.3.6 Defining Zones .......................................................................................... 60
137 11.3.7 Zone Identification ..................................................................................... 60
138 11.3.8 Defining Conduits ...................................................................................... 62
139 11.4 Security Levels ...................................................................................................... 64
140 11.4.1 Introduction ............................................................................................... 64
141 11.4.2 Definition ................................................................................................... 64
142 11.4.3 Types of Security Levels ............................................................................ 65
143 11.4.4 Using Security Levels ................................................................................ 65
144 11.4.5 Security Level Vector ................................................................................. 68
145 11.4.6 Foundational Requirements ....................................................................... 68
146 11.4.7 Level Definitions ........................................................................................ 69
147 11.4.8 Security Level Vector Format ..................................................................... 70
148 11.5 Foundational Requirements ................................................................................... 71
149 11.5.1 FR 1 Identification and authentication control (IAC) ................................ 71
150 11.5.2 FR 2 Use control (UC) ............................................................................ 72
151 11.5.3 FR 3 System integrity (SI) ....................................................................... 72
152 11.5.4 FR 4 Data confidentiality (DC) ................................................................ 72
153 11.5.5 FR 5 Restricted data flow (RDF) ............................................................. 73
154 11.5.6 FR 6 Timely response to events (TRE) ................................................... 73
155 11.5.7 FR 7 Resource availability (RA) .............................................................. 73

156 11.6 Safety and Security ............................................................................................... 73
157 11.6.1 Rationale ................................................................................................... 74
158 12 Compliance Metrics ........................................................................................................ 74
159 Annex A Zones and Conduits Examples ............................................................................. 75
160 A.1 Introduction ........................................................................................................... 75
161 A.2 Untrusted Conduits ................................................................................................ 75
162 A.3 Multi-Plant Model................................................................................................... 75
163 A.4 (Description) .......................................................................................................... 76
164 A.5 SCADA Applications .............................................................................................. 77
165 Annex B Truck Loading Description.................................................................................... 81
166 B.1 Introduction ........................................................................................................... 81
167 B.2 Safety and Security ............................................................................................... 90
168 Annex C Example: Procedure to apply foundational requirements ...................................... 92
169 C.1 Overview ............................................................................................................... 92
170 C.1.1 Description of example system under consideration ................................... 92
171 C.1.2 Technical Approach ................................................................................... 92
172 C.1.3 Achieved security assurance level ............................................................. 95
173 C.2 System security assurance when commissioned .................................................... 96
174 C.3 System security assurance during after commissioning ......................................... 96
175 Annex D (informative) Understanding how to use the ISA99 adaptation of the IEC
176 styleguide ....................................................................................................................... 97
177 D.1 Overview ............................................................................................................... 97
178 D.2 Document and page formatting .............................................................................. 97
179 D.3 Sectioning ............................................................................................................. 98
180 D.4 Figures .................................................................................................................. 99
181 D.5 Tables ................................................................................................................... 99
182 D.6 Wording and language recommendations ............................................................ 100
183 BIBLIOGRAPHY ................................................................................................................. 101
184
185 Figure 1 ISA62443 Work Products .................................................................................... 26
186 Figure 2 Security Elements Grouping ................................................................................. 31
187 Figure 3 Three-Legged Table ............................................................................................. 34
188 Figure 4 Implementation of People, Process, and Technology ............................................ 35
189 Figure 5 Reference Model .................................................................................................. 39
190 Figure 6 Physical Architecture Model Example ................................................................... 41
191 Figure 7 Context Element Relationships ............................................................................. 42
192 Figure 8 Context Model ...................................................................................................... 42
193 Figure 9 Key management life cycle ................................................................................... 48
194 Figure 10 Security aspects in relevant life cycles ............................................................... 50
195 Figure 11 Interdependencies in product and IACS lifecycles .............................................. 51
196 Figure 12 High-level process-industry example showing zones and conduits...................... 66
197 Figure 13 High-level manufacturing example showing zones and conduits ......................... 67
199 Figure 15 Conduit Example ................................................................................................ 75
200 Figure 16 Multiplant Zone Example .................................................................................... 76
201 Figure 17 Separate Zones Example ................................................................................... 77

202 Figure 18 SCADA Zone Example ....................................................................................... 78
203 Figure 19 SCADA Separate Zones Example ....................................................................... 79
204 Figure 20 Enterprise Conduit ............................................................................................. 79
205 Figure 21 SCADA Conduit Example ................................................................................... 80
206 Figure 22 Chemical Truck Loading Control System Architecture Diagram .......................... 81
207 Figure 23 Chemical Truck Loading System with Definition of SUT Boundary ...................... 82
208 Figure 24 Diagram of major components for chemical truck loading example ..................... 83
209 Figure 25 Zone and Conduit Identification .......................................................................... 86
210 Figure 26 High-level process-industry example showing zones and conduits...................... 88
212 Figure 28 Example application - Chemical truck loading station ......................................... 92
213
214 Table 1 Elements Applied to Change Control and Configuration Management .................... 34
215 Table 2 Entities with relevant life cycles and the respective main responsible role ............. 50
216 Table 3 Security Maturity Phases ....................................................................................... 56
217 Table 4 Concept Phase ...................................................................................................... 56
218 Table 5 Functional Analysis Phase ..................................................................................... 56
219 Table 6 Implementation Phase ........................................................................................... 57
220 Table 7 Operations Phase .................................................................................................. 57
221 Table 8 Recycle and Disposal Phase ................................................................................. 57
222 Table 9 Zone Characteristics ............................................................................................. 87
223
224
225 FOREWORD
226 This document is part of a multipart standard th at addresses the issue of security for industrial
227 automation and control systems (IACS). It has been developed by working group 03 of the
228 ISA99 committee in cooperation with IEC TC65/WG10.
229 This document describes the concepts and models that form the foundation of all standards in
230 the series. Many of these topics are addressed in more detail in one or more related
231 standards. It supersedes the original version of this standard ( ISA-99.00.01-2007).
232
233
234 INTRODUCTION
235 NOTE The format of this document follows the ISO/IEC requirements discussed in ISO/IEC Directives, Part 2.
236 [15] 1 The ISO/IEC Directives specify the format of this document as well as the use of terms like shall, should,
237 and may. The use of those terms for the requirements specified in Clause 4 of this document use the conventions
238 discussed in the ISO/IEC Directives, Appendix H.
239
240

1 Numbers in square brackets refer to the Bibliography.
241 1 Scope
242 This document is the first in the ISA62443 series of standards that addresses various aspects
243 of IACS security. It introduces concepts and models that are described and applied in more
244 detail in subsequent standards in the series.
245 The content of this document includes both general purpose cyber security elements that are
246 applicable in the IACS environment, as well as a small set of concepts and models that are
247 specific or unique to IACS. Normative content is limited to what required to define essential
248 concepts that must be consistently applied across all aspects of and IACS security response.
249 The intended audience for this specification is the IACS community, including asset owners,
250 system integrators, product suppliers, service providers and, where appropriate, compliance
251 authorities. Compliance authorities include but are not limited to government agencies and
252 regulators with the legal authority to perform audits to verify compliance with governing laws
253 and regulations.
254 System integrators, product suppliers and service provide rs will use this document to evaluate
255 whether their products and services can provide the functional security capability to meet the
256 asset owners target security level requirements. As with the assignment of these
257 requirements, applicability of individual control system requirements and requirement
258 enhancements must be based on an asset owners security policies, procedures and risk
259 assessment in the context of their specific site.
260 There is insufficient detail in this document to design and build a compre hensive security
261 architecture. That requires additional system -level analysis and development of derived
262 requirements that are the subject of other documents in the ISA62443 series.
263 2 Normative references

264 The following referenced documents are indispensable for the application of this document.
265 For dated references, only the edition cited applies. For undated references, the latest edition
266 of the referenced document (including any amendments) applies.
267 ISATR62443-1-2, Security for Industrial Automation and Control Systems Master Glossary
268 ISA62443-2-1, Security for industrial automation and control systems Requirements for an
269 Industrial automation and control system security management system
270 ISA62443-3-2, Security for Industrial Automation and Control Systems Security Risk
271 Assessment and System Design
272 ISA62443-3-3, Security for Industrial Automation and Control Systems System Security
273 Requirements and Security Levels
274 ANSI/ISA-95.00.01-2000, Enterprise-Control System Integration Models and Terminology,

275 Clause 5 (Hierarchy Models)
276 ISO/IEC 27001 Information technology Security techniques Information security

277 management systems Requirements
278 ISO/IEC 27002, Information technology Security techniques Code of practice for
279 information security management
280
281 3 Terms, definitions, abbreviated terms, acronyms, and conventions

282 3.1 Terms and definitions
283 For the purposes of this document, the terms and definitions given in ISA62443-1-1 and the
284 following apply.
285 3.1.1
286 access
287 ability and means to communicate with or otherwise interact with a system in order to use
288 system resources
289 Note to entry: Access may involve physical access (authorization to be allowed physically in an area, possession of
290 a physical key lock, PIN code, or access card or biometric attributes that allow access) or logical access
291 (authorization to log in to a system and application, through a combination of logical and physical means)
292 3.1.2
293 access control
294 protection of system resources against unauthorized access; a process by which use of
295 system resources is regulated according to a security policy and is permitted by only
296 authorized entities (users, programs, processes, or other systems) according to that policy
297 3.1.3
298 accountability
299 property of a system (including all of its system res ources) that ensures that the actions of a
300 system entity may be traced uniquely to that entity, which can be held responsible for its
301 actions
302 3.1.4
303 actuator
304 actuating element connected to process equipment and to the control system
305 3.1.5
306 application
307 software program that performs specific functions initiated by a user command or a process
308 event and that can be executed without access to system control, monitoring, or
309 administrative privileges
310 3.1.6
311 area
312 subset of a sites physical, geographic, or logical group of assets
313 Note to entry: An area may contain manufacturing lines, process cells, and production units. Areas may be
314 connected to each other by a site local area network and may contain systems related to the operations performed
315 in that area.
316 3.1.7
317 asset
318 physical or logical object owned by or under the custodial duties of an organization, having
319 either a perceived or actual value to the organization
320 Note to entry: In the case of industrial automation and control systems the physical assets that have the largest
321 directly measurable value may be the equipment under control.
322 3.1.8
323 asset operator
324 individual or organization responsible for the operation of the IACS
325 3.1.9
326 asset owner
327 individual or organization that owns the IACS assets
328 3.1.10
329 attack
330 assault on a system that derives from an intelligent threat i.e., an intelligent act that is a
331 deliberate attempt (especially in the sense of a method or technique) to evade security
332 services and violate the security policy of a system
333 Note to entry: There are different commonly recognized clas ses of attack:
334 An active attack attempts to alter system resources or affect their operation. A passive attack attempts to learn
335 or make use of information from the system but does not affect system resources.
336 An inside attack is an attack initiated by an entity inside the security perimeter (an insider) i.e., an entity that
337 is authorized to access system resources but uses them in a way not approved by those who granted the
338 authorization. An outside attack is initiated from outside the perimet er, by an unauthorized or illegitimate user of
339 the system (including an insider attacking from outside the security perimeter). Potential outside attackers range
340
from amateur pranksters to organized criminals, international terrorists, and hostile governme nts.
341
3.1.11
342 audit
343 independent review and examination of records and activities to assess the adequacy of
344 system controls, to ensure compliance with established policies and operational procedures,
345 and to recommend necessary changes in controls, policies, or proc edures (See security
346 audit)
347 Note to entry: There are three forms of audit. (1) External audits are conducted by parties who are not employees
348 or contractors of the organization. (2) Internal audit are conducted by a separate organizational unit dedicated to
349 internal auditing. (3) Controls self assessments are conducted by peer members of the process automation
350 function.
351 3.1.12
352 authenticate
353 verify the identity of a user, user device, or other entity, or to establish the validity of a
354 transmission
355 3.1.13
356 authentication
357 security measure designed to establish the validity of a transmission, message, or originator,
358 or a means of verifying an individual's authorization to receive specific categories of
359 information
360 3.1.14
361 authorization
362 right or a permission that is granted to a s ystem entity to access a system resource
363 3.1.15
364 availability
365 probability that an asset, under the combined influence of its reliability, maintainability, and
366 security, will be able to fulfill its required function over a stated period of time, or at a given
367 point in time
368 3.1.16
369 border
370 edge or boundary of a physical or logical security zone
371 3.1.17
372 botnet
373 collection of software robots, or bots, which run autonomously
374 Note to entry: A botnet's originator can control the group remotely, possibly for nefarious purposes.
375 3.1.18
376 boundary
377 software, hardware, or other physical barrier that limits access to a system or part of a system
378 3.1.19
379 business system
380 collection of information technology elements (i.e., hardware, software and services) installed
381 with the intent to facilitate an organiza tions business process or processes (administrative or
382 project)
383
3.1.20
384 cell
385 lower-level element of a manufacturing process that performs manufacturing, field device
386 control, or vehicle functions
387 Note to entry: Entities at this level may be connected together by an area control network and may contain
388 information systems related to the operations performed in that entity.
389 3.1.21
390
channel
391 specific communication path established within a communication conduit (See conduit).
392 3.1.22
393 client
394 device or application receiving or requesting services or information from a server application
395 3.1.23
396 communication path
397 logical connection between a source and one or more destinations, which could be devices,
398 physical processes, data items, commands, or programmatic interfaces
399 Note to entry: The communication path is not limited to wired or wireless networks, but includes other means of
400 communication such as memory, procedure calls, state of physical plant, portable media, and human interactions.
401 3.1.24
402 communication system
403 arrangement of hardware, software, and propagation media to allow the transfer of messages
404 (ISO/IEC 7498 application layer service data units) from one application to another
405 3.1.25
406 compromise
407 unauthorized disclosure, modification, substitution, or use of information (including plaintext
408 cryptographic keys and other critical security parameters)
409 3.1.26
410 conduit
411 logical grouping of communication assets that protects the security of the channels it contains
412 Note to entry: This is analogous to the way that a physical co nduit protects cables from physical damage.
413 3.1.27
414 confidentiality
415 assurance that information is not disclosed to unauthorized individuals, processes, or devices
416 3.1.28
417 control center
418 central location used to operate a set of assets
419 Note 1 to entry: Infrastructure industries typically use one or m ore control centers to supervise or coordinate their
420 operations. If there are multiple control centers (for example, a backup center at a separate site), they are typically
421 connected together via a wide area network. The control center contains the SCADA h ost computers and
422 associated operator display devices plus ancillary information systems such as a historian.
423 Note 2 to entry: In some industries the term control room may be mor e commonly used.
424 3.1.29
425 control equipment
426 class that includes distributed control systems, programmable logic controllers, SCADA
427 systems, associated operator interface consoles, and field sensing and control devices used
428 to manage and control the process
429 Note to entry: The term also includes field bus networks where control logic and al gorithms are executed on
430 intelligent electronic devices that coordinate actions with each other, as well as systems used to monitor the
431 process and the systems used to maintain the process.
432 3.1.30
433 control network
434 time-critical network that is typically connected to equipment that controls physical processes
435 Note to entry: The control network can be subdivided into zones, and there can be multiple separate control
436 networks within one company or site.
437 3.1.31
438 cost
439 value of impact to an organization or person that can be measured
440 3.1.32
441
countermeasure
442 action, device, procedure, or technique that reduces a threat, a vulnerability, or an attack by
443 eliminating or preventing it, by minimizing the harm it can cause, or by discovering and
444 reporting it so that corrective action can be taken
445 Note to entry: The term Control is also used to describe this concept in some contexts. The term countermeasure
446 has been chosen for this standard to avoid confusion with the word control in the context of process control.
447 3.1.33
448 cryptographic algorithm
449 algorithm based upon the science of cryptography, including encryption algorithms,
450 cryptographic hash algorithms, digital signature algorithms, and key agreement algorithms
451 3.1.34
452 cryptographic key
453 input parameter that varies the transformation performed by a cryptographic algorithm
454 Note to entry: Usually shortened to just key.
455 3.1.35
456 data confidentiality
457 property that information is not made available or disclosed to any unauthorized system entity,
458 including unauthorized individuals, entities, or processes
459 3.1.36
460 data integrity
461 property that data has not been changed, destroyed, or lost in an unauthorized or accidental
462 manner
463 Note to entry: This term deals with constancy of and confidence in data values, not with the i nformation that the
464 values represent or the trustworthiness of the source of the values.
465 3.1.37
466 decryption
467 process of changing cipher text into plaintext using a cryptographic algorithm and key (See
468 encryption)
469 3.1.38
470 defense in depth
471 provision of multiple security protections, especially in layers, with the intent to delay if not
472 prevent an attack
473 Note to entry: Defense in depth implies layers of security and detection, even on single systems, and provides the
474 following features:
475 a) attackers are faced with breaking through or bypassing each layer without being detected
476 b) flaw in one layer can be mitigated by capabilities in other layers
477 c) system security becomes a set of layers within the overall network security.
478 3.1.39
479 demilitarized zone
480 perimeter network segment that is logic ally between internal and external networks
481 Note 1 to entry: The purpose of a demilitarized zone is to enforce the internal networks policy for external
482 information exchange and to provide external, untrusted sources with restricted access to releasable i nformation
483 while shielding the internal network from outside attacks.
484 Note 2 to entry: In the context of industrial automation and control systems, the term internal network is
485 typically applied to the network or segment that is the primary focus of prot ection. For example, a control network
486 could be considered internal when connected to an external business network.
487 3.1.40
488 denial of service
489 prevention or interruption of authorized access to a system resource or the delaying of system
490 operations and functions
491 Note to entry: In the context of industrial automation and control systems, denial of service can refer to loss of
492 process function, not just loss of data communications.
493 3.1.41
494
digital signature
495 result of a cryptographic transformation of data which, when pr operly implemented, provides
496 the services of origin authentication, data integrity, and signer non -repudiation
497 3.1.42
498 distributed control system
499 type of control system in which the system elements are dispersed but operated in a coupled
500 manner
501 Note 1 to entry: Distributed control systems may have shorter coupling time constants than those typically found
502 in SCADA systems.
503 Note 2 to entry: Distributed control systems are commonly associated with continuous processes such as electric
504 power generation; oil and gas refining; chemical, pharmaceutical and paper manufacture, as well as discrete
505 processes such as automobile and other goods manufacture, packaging, and warehousing.
506 3.1.43
507 domain
508 environment or context that is defined by a security policy, security model, or secu rity
509 architecture to include a set of system resources and the set of system entities that have the
510 right to access the resources
511 3.1.44
512 eavesdropping
513 monitoring or recording of communicated information by unauthorized parties
514 3.1.45
515 electronic security
516 actions required to preclude unauthorized use of, denial of service to, modifications to,
517 disclosure of, loss of revenue from, or destruction of critical systems or informational assets
518 Note to entry: The objective is to reduce the risk of causing personal injury or end angering public health, losing
519 public or consumer confidence, disclosing sensitive assets, failing to protect business assets or failing to comply
520 with regulations. These concepts are applied to any system in the production process and include both stand -alone
521 and networked components. Communications between systems may be either through internal messaging or by any
522 human or machine interfaces that authenticate, operate, control, or exchange data with any of these control
523 systems. Electronic security includes the concepts of identification, authentication, accountability, authorization,
524 availability, and privacy.
525 3.1.46
526 encryption
527 cryptographic transformation of plaintext into ciphertext that conceals the datas original
528 meaning to prevent it from being known or used (See decryption)
529 Note to entry: If the transformation is reversible, the corresponding reversal process is called decryption, which is
530 a transformation that restores encrypted data to its original state.
531 3.1.47
532 enterprise
533 business entity that produces or transports products or operates and maintains infrastructure
534 services
535 3.1.48
536 equipment under control
537 equipment, machinery, apparatus or plant used for manufacturing, process, transportation,
538 medical or other activities
539 3.1.49
540
essential function
541 function or capability that is required to maintain health, safety, the environment and
542 availability for the equipment under control
543 Note to entry: Essential functions include, but are not limited to, the safety instrumented function (SIF), the control
544 function and the ability of the operator to view and manipulate the equipment under control. The loss of essential
545 functions is commonly termed loss of protection, loss of control and loss of view respectively. In some industries
546 additional functions such as history may be consi dered essential.
547 3.1.50
548 firewall
549 inter-network connection device that restricts data communication traffic between two
550 connected networks
551 Note to entry: A firewall may be either an application installed on a general -purpose computer or a dedicated
552 platform (appliance) that forwards or rejects/drops packets on a network. Typically firewalls are used to define zone
553 borders. Firewalls generally have rules restricting which ports are open.
554 3.1.51
555 gateway
556 relay mechanism that attaches to two (or more) computer networks that have similar functions
557 but dissimilar implementations and that enables host computers on one network to
558 communicate with hosts on the other
559 Note to entry: Also described as an intermediate system that is the translation interface between two computer
560 networks.
561 3.1.52
562 geographic site
563 subset of an enterprises physical, geographic, or logical group of assets
564 Note to entry: A geographic site may contain areas, manufacturing lines, process cells, process units, control
565 centers, and vehicles and may be connected to other sites by a wide area network.
566 3.1.53
567 host
568 computer that is attached to a communication subnetwork or inter -network and can use
569 services provided by the network to exchange data with other attached systems
570 3.1.54
571 industrial automation and control systems
572 collection of personnel, hardware, and software that can affect or influence the safe, secure,
573 and reliable operation of an industrial process
574 Note to entry: These systems include, but are not limited to:
575 a) industrial control systems, including distributed c ontrol systems (DCSs), programmable logic controllers (PLCs),
576 remote terminal units (RTUs), intelligent electronic devices, supervisory control and data acquisition (SCADA),
577 networked electronic sensing and control, and monitoring and diagnostic systems. ( In this context, process control
578 systems include basic process control system and safety -instrumented system [SIS] functions, whether they are
579 physically separate or integrated.)
580 b) associated information systems such as advanced or multivariable control, online optimizers, dedicated
581 equipment monitors, graphical interfaces, process historians, manufacturing execution systems, and plant
582 information management systems.
583 c) associated internal, human, network, or machine interfaces used to provide control, saf ety, and manufacturing
584 operations functionality to continuous, batch, discrete, and other processes.
585 3.1.55
586 insider
587 trusted person, employee, contractor, or supplier who has information that is not generally
588 known to the public (See outsider)
589 3.1.56
590 integrity
591 quality of a system reflecting the logical correctness and reliability of the operating system,
592 the logical completeness of the hardware and software implementing the protection
593 mechanisms, and the consistency of the data structures and occurrence of the s tored data
594 Note to entry: In a formal security mode, integrity is often interpreted more narrowly to mean protection against
595 unauthorized modification or destruction of information.
596 3.1.57
597 interception
598 capture and disclosure of message contents or use of traffic analysis to compromise the
599 confidentiality of a communication system based on message destination or origin, frequency
600 or length of transmission, and other communication attributes
601
3.1.58
602 interface
603 logical entry or exit point that provides access to the module for logical information flows
604 3.1.59
605 intrusion
606 unauthorized act of compromising a system (See attack).
607 3.1.60
608 intrusion detection
609 security service that monitors and analyzes system events for the purpose of finding, and
610 providing real-time or near real-time warning of, attempts to access system resources in an
611 unauthorized manner
612 3.1.61
613 ISO
614 International Organization for Standardization
615 3.1.62
616 key management
617 process of handling and controlling cryptographic keys and related material (such as
618 initialization values) during their life cycle in a cryptographic system, including ordering,
619 generating, distributing, storing, loading, escrowing, archiving, auditing, and destroying the
620 keys and related material
621 3.1.63
622 line
623 lower-level element of a manufacturing process that performs manufactu ring, field device
625 Note to entry: See Cell
626 3.1.64
627 local area network
628 communications network designed to connect computers and other intelligent devices in a
629 limited geographic area (typically less than 10 kilometers)
630 3.1.65
631 malicious code
632 programs or code written for the purpose of gathering information about systems or users,
633 destroying system data, providing a foothold for further intrusion into a system, falsifying
634 system data and reports, or providing time-consuming irritation to system operations and
635 maintenance personnel
636 Note 1 to entry: Malicious code attacks can take the form of viruses, worms, Trojan Horses, or other automated
637 exploits.
638 Note 2 to entry: Malicious code is also often referred to as malware.
639 3.1.66
640 manufacturing operations
641 collection of production, maintenance, and quality assurance operations and their relationship
642 to other activities of a production facility
643 Note to entry: Manufacturing operations include:
644
a) manufacturing or processing facility activities that coor dinate the personnel, equipment, and material involved in
645 the conversion of raw materials or parts into products.
646 b) functions that may be performed by physical equipment, human effort, and information systems.
647 c) managing information about the schedules, use, capability, definition, history, and status of all resources
648 (personnel, equipment, and material) within the manufacturing facility.
649 3.1.67
650 OPC
651 set of specifications for the exchange of information in a process control environment
652 Note to entry: The abbreviation OPC originally came from OLE for Process Control, where OLE was short for
653 Object Linking and Embedding.
654 3.1.68
655 outsider
656 person or group not trusted with inside access, who may or may not be known to the
657 targeted organization (See insider)
658 Note to entry: Outsiders may or may not have been insiders at one time.
659 3.1.69
660 penetration
661 successful unauthorized access to a protected system resource
662 3.1.70
663 plaintext
664 unencoded data that is input to and transformed by an encryption process, or that is output by
665 a decryption process
666 3.1.71
667 privilege
668 authorization or set of authorizations to perform specific functions, especially in the context of
669 a computer operating system
670 Note to entry: Examples of functions that are controlled through the use of privilege include ackno wledging alarms,
671 changing setpoints, modifying control algorithms.
672 3.1.72
673 process
674 series of operations performed in the making, treatment or transportation of a product or
675 material
676 Note to entry: This standard makes extensive use of the term process to describ e the equipment under control of
677 the industrial automation and control system.
678 3.1.73
679 protocol
680 set of rules (i.e., formats and procedures) to implement and control some type of association
681 (e.g., communication) between systems
682 3.1.74
683 reference model
684 framework for understanding significant relationships among the entities of some environment,
685 and for the development of consistent standards or specifications supporting that
686 environment.
687 Note: A reference model is based on a small number of unifying concepts and may be used as a basis for
688 education and explaining standards to a non-specialist.
689 3.1.75
690 reliability
691 ability of a system to perform a required function under stated conditions for a specified period
692 of time
693 3.1.76
694
remote access
695 use of systems that are inside the perimeter of the security zone being addressed from a
696 different geographical location with the same rights as when physically present at the location
697 Note to entry: The exact definition of remote can vary according to situation. For example, access may come from
698 a location that is remote to the specific zone, but still within the boundaries of a company or organization. This
699 might represent a lower risk than access that originates from a location that is remote and outside of a companys
700 boundaries.
701 3.1.77
702 repudiation
703 denial by one of the entities involved in a communication of having participated in all or part of
704 the communication
705 3.1.78
706 risk
707 expectation of loss expressed as the probability that a particular threat will exploit a particular
708 vulnerability with a particular consequence
709 3.1.79
710 risk assessment
711 process that systematically identifies potential vulnerabilities to valuable system resources
712 and threats to those resources, quantifies loss exposures and consequences based on
713 probability of occurrence, and (optionally) recommends how to allocate resources to
714 countermeasures to minimize total exposure
715 Note 1 to entry: Types of resources include physical, logical and human.
716 Note 2 to entry: Risk assessments are often combined with vulnerability assessments to identify vulnerab ilities and
717 quantify the associated risk. They are carried out initially and periodically to reflect changes in the organization's
718 risk tolerance, vulnerabilities, procedures, personnel and technological changes.
719 3.1.80
720 risk management
721 process of identifying and applying countermeasures commensurate with the value of the
722 assets protected based on a risk assessment
723 3.1.81
724 router
725 gateway between two networks at OSI layer 3 and that relays and directs data packets
726 through that inter-network. The most common form of router passes Internet Protocol (IP)
727 packets
728 3.1.82
729 safety
730 freedom from unacceptable risk
731 3.1.83
732 safety-instrumented system
733 system used to implement one or more safety-instrumented functions
734 Note to entry: A safety-instrumented system is composed of any combination of sens or(s), logic solver(s), and
735 actuator(s).
736 3.1.84
737 safety integrity level
738 discrete level (one out of four) for specifying the safety integrity requirements of the safety -
739 instrumented functions to be allocated to the safety-instrumented systems
740 Note to entry: Safety integrity level 4 has the highest level of safety integrity; safety integrity level 1 has the lowest.
741 3.1.85
742 secret
743 condition of information being protected from being known by any system entities except
744 those intended to know it
745 3.1.86
746
security
747 1. measures taken to protect a system
748 2. condition of a system that results from the establishment and maintenance of measures to
749 protect the system
750 3. condition of system resources being free from unauthorized access and from unauthorized
751 or accidental change, destruction, or loss
752 4. capability of a computer-based system to provide adequate confidence that unauthorized
753 persons and systems can neither modify the software and its data nor gain access to the
754 system functions, and yet to ensure that this is not denied to authorized persons and
755 systems
756 5. prevention of illegal or unwanted penetration of or interference with the proper and
757 intended operation of an industrial automation and control system
758 Note to entry: Measures can be controls related to physical security (controlling physical access to computing
759 assets) or logical security (capability to login to a given system and application.)
760 3.1.87
761 security architecture
762 plan and set of principles that describe the security services that a system is required to
763 provide to meet the needs of its us ers, the system elements required to implement the
764 services, and the performance levels required in the elements to deal with the threat
765 environment
766 Note to entry: In this context, security architecture would be an architecture to protect the control netwo rk from
767 intentional or unintentional security events.
768 3.1.88
769 security audit
770 independent review and examination of a system's records and activities to determine the
771 adequacy of system controls, ensure compliance with established security policy and
772 procedures, detect breaches in security services, and recommend any changes that are
773 indicated for countermeasures
774 3.1.89
775 security control
776 See countermeasure
777 3.1.90
778 security event
779 occurrence in a system that is relevant to the security of the system
780 3.1.91
781 security incident
782 adverse event in a system or network or the threat of the occurrence of such an event
783 Note to entry: The term near miss is sometimes used to describe an event that could have been an incident under
784 slightly different circumstances.
785 3.1.92
786 security level
787 level corresponding to the required effectiveness of countermeasures and inherent security
788 properties of devices and systems for a zone or conduit based on assessment of risk for the
789 zone or conduit
790 3.1.93
791 security objective
792 aspect of security which to achieve is the purpose and objective of using certain mitigation
793 measures, such as confidentiality, integrity, availability, user authenticity, access
794 authorization, accountability
795
3.1.94
796 security perimeter
797 boundary (logical or physical) of the domain in which a security pol icy or security architecture
798 applies, i.e., the boundary of the space in which security services protect system resources
799 3.1.95
800 security policy
801 set of rules that specify or regulate how a system or organization provides security services to
802 protect its assets
803 3.1.96
804 security procedures
805 definitions of exactly how practices are implemented and executed
806 3.1.97
807 security program
808 a combination of all aspects of managing security, ranging from the definition and
809 communication of policies through implementation of best industry pra ctices and ongoing
810 operation and auditing
811 3.1.98
812 security services
813 mechanisms used to provide confidentiality, data integrity, authentication, or no repudiation of
814 information
815 3.1.99
816 security violation
817 act or event that disobeys or otherwise breaches security policy through an intrusion or the
818 actions of a well-meaning insider
819 3.1.100
820 security zone
821 grouping of logical or physical assets that share common security requirements
822 Note 1 to entry: All unqualified uses of the word zone in this standard should be assumed to refer to a security
823 zone.
824 Note 2 to entry: A zone has a clear border with other zones. The security policy of a zone is typically enforced by a
825 combination of mechanisms both at the zone edge and within the zone. Zones can be hierarchical in the sense that
826 they can be comprised of a collection of subzones.
827 3.1.101
828 sensor
829 measuring element connected to process equipment and to the control system
830 3.1.102
831 server
832 device or application that provides information or services to client applications and devices
833 3.1.103
834 supervisory control and data acquisition (SCADA) system
835 type of loosely coupled distributed monitoring and control system commonly associated with
836 electric power transmission and distribution systems, oil and gas pipelines, and water and
837 sewage systems
838 Note to entry: Supervisory control systems are also used within batch, continuous, and discrete manufacturing
839 plants to centralize monitoring and control activities for these sites.
840 3.1.104
841 system
842 interacting, interrelated, or interdependent elements forming a complex whole
843 3.1.105
844 system software
845 special software designed for a specific computer system or family of computer systems to
846 facilitate the operation and maintenance of the computer system and associated programs
847 and data
848 3.1.106
849 threat
850 potential for violation of security, which exis ts when there is a circumstance, capability, action,
851 or event that could breach security and cause harm
852 3.1.107
853 traffic analysis
854 inference of information from observable characteristics of data flow(s), even when the data
855 are encrypted or otherwise not directly available, including the identities and locations of
856 source(s) and destination(s) and the presence, amount, frequency, and duration of occurrence
857 3.1.108
858 trojan horse
859 computer program that appears to have a useful function, but also has a hidden and
860 potentially malicious function that evades security mechanisms, sometimes by exploiting
861 legitimate authorizations of a system entity that invokes the program
862 3.1.109
863 unit
864 lower-level element of a manufacturing process that performs manufacturing, field device
866 Note to entry: See Cell
867 3.1.110
868 use case
869 technique for capturing potential functional requirements that employs the use of one or more
870 scenarios that convey how the system should interact with the end user or another system to
871 achieve a specific goal
872 Note to entry: Typically use cases treat the system as a black box, and the interactions with the system, including
873 system responses, are as perceived from outside of the system. Use cases are popular because they simplify the
874 description of requirements, and avoid the problem of making assumptions about how this functionality will be
875 accomplished.
876 3.1.111
877 user
878 person, organization entity, or automated process that accesses a system, whether authorized
879 to do so or not
880 3.1.112
881 virus
882 self-replicating or self-reproducing program that spreads by inserting copies of itself into other
883 executable code or documents
884 3.1.113
885 vulnerability
886 flaw or weakness in a system's design, implementation, or operation and management that
887 could be exploited to violate the system's integrity or sec urity policy
888 3.1.114
889 wide area network
890 communications network designed to connect computers, networks and other devices over a
891 large distance, such as across the country or world
892 3.1.115
893 wiretapping
894 attack that intercepts and accesses data and other information contained in a flow in a
895 communication system
896 Note 1 to entry: Although the term originally referred to making a mechanical connection to an electrical conductor
897 that links two nodes, it is now used to refer to reading information from any sort of medium u sed for a link or even
898 directly from a node, such as a gateway or subnetwork switch.
899 Note 2 to entry: Active wiretapping attempts to alter the data or otherwise affect the flow; passive wiretapping
900 only attempts to observe the flow and gain knowledge o f information it contains.
901 3.1.116
902 worm
903 computer program that can run independently, can propagate a complete working version of
904 itself onto other hosts on a network, and may consume computer resources destructively
905 3.1.117
906 zone
907 See security zone
908 3.2 Abbreviated terms and acronyms

909 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
910 3.3 Conventions

911 SKELETON NOTE This sub-clause is where specific conventions used in the document, like specific clause/sub -
912 clause formatting, special text conventions, or any other things that the reader should know in order to read the
913 document. The reader may still need some introduction to conventions used throughout the document, but this sub -
914 clause allows for a greater explanation in one place.
915 3.3.1 Reserved terms

916 The following terms are reserved for normative clauses.
917 shall: The word shall, equivalent to "is required to", is used to indicate mandatory
918 requirements, to be followed strictly in order to conform to the standard and from which no
919 deviation is permitted.
920 must: The use of the word must is depreciated and shall not be used when stating
921 mandatory requirements. The word must is only used to describe unavoidable situations.
922 should: The word should, equivalent to "is recommended that", is used to indicate
923 Among several possibilities one is recommended as particularly suitable, without
924 mentioning or excluding others.
925 That a certain course of action is preferred but not required.
926 That (in the negative form) a certain course of action is depreciated but not prohibited.
927 may: The word may, equivalent to "is permitted", is used to indicate a course of action
928 permissible within the limits of this standard.
929 can: The word can, equivalent to "is able to", is used to indicate possibility and capability,
930 whether material or physical.
931 3.3.2 Proper nouns
932 Commensurate with ISA6244324, the term Solution is used as a proper noun (and
933 therefore capitalized) in this document to prevent confusion with other uses of the term.
934 4 The ISA62443 standards
935 ISA62443 is a multi-part standard designed to address the need to design cybersecurity
936 robustness and resilience into industrial automation control systems (IACS). Robustness
937 provides the capabilities for the system under consideration (SuC) to operate under a ran ge of
938 cyber-induced perturbations and disturbances. Resilience provides the capabilities to restore
939 the SuC under unexpected and rare cyber-induced events. Robustness and resilience are not
940 general properties of IACS but a relative to specific classes of c yber-induced perturbations. A
941 SuC that is resilient or robust to a certain type of cyber -induced perturbations may be brittle or
942 fragile to another. Such a trade-off is the subject of profiles, which others can derive from the
943 ISA62443 requirements and guidelines.
944 The goal in developing the ISA62443 series is to improve the availability, integrity and
945 confidentiality of components or systems used for industrial automat ion and control, and to
946 provide criteria for procuring and implementing secure industrial automation and control
947 systems. Conformance with the guidance in ISA62443 is intended to improve electronic
948 security and help identify and address vulnerabilities, reducing the risk of compromising
949 confidential information or causing degradation or failure of the equipment (hardware and
950 software) of processes under control.
951 The concept of industrial automation and control systems electronic security is applied in the
952 broadest possible sense, encompassing all types of plants, facilities, and systems in all
953 industries. Manufacturing and control systems include, but are not limited to:
954 hardware and software systems such as DCS, PLC, SCADA, networked electronic
955 sensing, and monitoring and diagnostic systems
956 associated internal, human, network, or machine interfaces used to provide control, safety,
957 and manufacturing operations functionality to continuous, batch, discrete, and othe r
958 processes.
959 Guidance is directed towards those responsible for designing, implementing, or managing
960 industrial automation and control systems. This guidance also applies to users, system
961 integrators, security practitioners, and control systems manufacture rs and vendors.
962 The ISA62443 series builds on established standards for the security of general purpose
963 information technology systems (e.g., the ISO/IEC 27000 series), identifying and addressing
964 the important differences present in Industrial Automation and Control Systems (IACS). Many
965 of these differences are based on the reality that cyber security risks with IACS may have
966 Health, Safety or Environment (HSE) implications and the response should be integrated with
967 other existing risk management practices addressing these risks.
968 The structure and organization of the ISA62443 series of work products is shown in Figure 1.
969
970 Figure 1 ISA62443 Work Products
971 The standards and reports in the series are arranged in four groups or tiers, corresponding to
972 the primary focus and intended audience.
973 The first of general tier includes documents that address topics that are common to the entire
974 series. These include:
975 ISA62443-1-1 (This document) introduces the concepts and models used throughout the
976 series.
977 ISATR62443-1-2 is a master glossary of terms and abbreviations used throughout the
978 series.
979 ISA62443-1-3 describes a series of quantitative metrics derived from the foun dational
980 requirements, system requirements and associated.
981 ISA-TR62443-1-4 provides a more detailed description of the underlying life cycle for IACS
982 security, as well as several use cases that illustrate various applications.
983 Documents in the second tier focus on the policies and procedures associated with IACS
984 security. These include:
985 ISA62443-2-1 describes what is required to define and implement an effective IACS cybe r
986 security management system.
987 ISA62443-2-2 provides specific guidance on what is required to operate an effective IACS
988 cyber security management system.
989 ISATR62443-2-3 provides guidance on the specific subject of patch management for
990 IACS.
991 ISA62443-2-4 (adopted from IEC 62433-2-4) specifies requirements for suppliers of IACS.
992 Documents in the third tier address requirements at the system level. These include:
993 ISATR62443-3-1 describes the application of various security technologies to an IACS

994 environment.
995 ISA62443-3-2 addresses security risk assessment and system design for IACS.
996 ISA62443-3-3 describes the foundational system security requirements and security
997 assurance levels.
998 The fourth and final tier includes information about the more specific a nd detailed
999 requirements associated with the development of IACS products. These include:
1000 ISA62443-4-1 describes the derived requirements that are applicable to the development
1001 of products.
1002 ISA62443-4-2 contains sets of derived requirements that provide a detailed mapping of
1003 the system requirements to subsystems and components of the system under
1004 consideration.
1005 5 The Situation

1006 5.1 Overview
1007 Industrial automation and control systems operate within a complex environment. Appreciation
1008 of the nature of this environment is an essential prerequisite to ensuring its security. This
1009 includes understanding the business environment, current systems and trends, and potential
1010 consequences.
1011 5.2 Business Environment

1012 Organizations are increasingly sharing information between business and industrial
1013 automation systems, and partners in one business venture may be competitors in another. At
1014 the same time new technology enables more advanced capabiliti es in support of business
1015 needs.
1016 Although technology changes and partner relationships may be good for business, they
1017 increase the potential risk of compromising security. As the threats to businesses increase, so
1018 does the need for security.
1019 Because industrial automation and control systems equipment connects directly to a process,
1020 loss of sensitive information or interruption in the flow of information are not the only
1021 consequences of a security breach. The potential loss of life or production, environment al
1022 damage, regulatory violation, and compromise to operational safety are far more serious
1023 consequences. These may have ramifications beyond the targeted organization; they may
1024 grievously damage the infrastructure of the host region or nation.
1025 External threats are not the only concern; knowledgeable insiders with malicious intent or
1026 even an innocent unintended act can pose a serious security risk. Additionally, industrial
1027 automation and control systems are often integrated with other business systems. Modif ying
1028 or testing operational systems has led to unintended effects on system operations. Personnel
1029 from outside the control systems area increasingly perform security testing on the systems,
1030 exacerbating the number and consequence of these effects. Combinin g all these factors, it is
1031 easy to see that the potential of someone gaining unauthorized or damaging access to an
1032 industrial process is not trivial.
1033 5.3 Current Systems

1034 Industrial automation and control systems have evolved from individual, isolated computers
1035 with proprietary operating systems and networks to interconnected systems and applications
1036 employing commercial off the shelf (COTS) technology (i.e., operating systems and
1037 protocols). These control systems are increasingly being integrated with non -IACS systems
1038 and applications through various communication networks. This increased level of integration
1039 provides significant business benefits, including:
1040 a) Increased visibility of industrial control system activities (work in process, equipment
1041 status, production schedules) and integrated processing systems from the business
1042 level, contributing to the improved ability to conduct analyses to drive down production
1043 costs and improve productivity.
1044 b) Integrated manufacturing and production systems have more direct acc ess to business
1045 level information, enabling a more responsive enterprise.
1046 c) Common interfaces that reduce overall support costs and permit remote support of
1047 production processes.
1048 d) Remote monitoring of the process control systems that reduces support costs and
1049 allows problems to be solved more quickly.
1050 There are definite security related considerations associated with each of these benefits.
1051 Devices, open networking technologies and increased connectivity provide in creased
1052 opportunities for cyber-attack against control system hardware and software. That weakness
1053 may lead to health, safety and environmental (HSE), financial and/or reputational
1054 consequences in deployed control systems.
1055 Organizations deploying general commodity information technology (IT) cy ber security
1056 solutions to address IACS security may not fully comprehend the results of this decision.
1057 While many business IT applications and security solutions can be applied to IACS, they need
1058 to be applied in an appropriate way to eliminate inadvertent consequences. For this reason,
1059 the approach used to define system requirements needs to be based on a combination of
1060 functional requirements and risk assessment, often including an awareness of operational
1061 issues as well.
1062 It is possible to define standards for models and information exchanges that allow the
1063 industrial automation and control systems community to share information in a consistent way.
1064 However, this ability to exchange information increases vulnerability to misuse and attack by
1065 individuals with malicious intent and introduces potential risks to the enterprise using
1066 industrial automation and control systems.
1067 Industrial automation and control systems configurations can be very complex in terms of
1068 physical hardware, programming, and communications. This complexity can often make it
1069 difficult to determine:
1070 a) who is authorized to access electronic information.

1071 b) when a user can have access to the information.
1072 c) what data or functions a user should be able to access.
1073 d) where the access request originates.
1074 e) how the access is requested.
1075 5.4 Current Trends
1076 Several trends contribute to the increased emphasis on the security of industrial automation
1077 and control systems:
1078 a) Businesses have reported more unauthorized attempts (either intentional or

1079 unintentional) to access electronic information each year than in the previous year.
1080 b) Industrial automation and control systems include more COTS software components
1081 (e.g., operating systems and protocols) and are interconnecting with business
1082 networks, making these systems susceptible to the same software attacks as are
1083 present in business and desktop devices.
1084 c) The use of joint ventures, alliance partners, and outsourced services in the industrial
1085 sector has led to a more complex situation with respect to the number of organization s
1086 and groups contributing to security of the industrial automation and control system.
1087 d) Tools to automate attacks are commonly available. The potential threat from the use of
1088 these tools now includes cyber criminals and cyber terrorists who may have more
1089 resources and knowledge to attack an industrial automation and control system.
1090 e) The focus on unauthorized access has broadened from amateur attackers or
1091 disgruntled employees to deliberate criminal or terrorist activities aimed at impacting
1092 large groups and facilities.
1093 f) The adoption of industry standard protocols such as Internet Protocol (IP) for
1094 communication between industrial automation and control systems and field devices
1095 exposes these systems to the same vulnerabilities as business systems at the networ k
1096 layer.
1097 These and other trends have combined to significantly increase organizations risks
1098 associated with the design and operation of their industrial automation and control systems.
1099 At the same time, electronic security of industrial control systems ha s become a more
1100 significant and widely acknowledged concern. This shift requires more structured guidelines
1101 and procedures to define electronic security applicable to industrial automation and control
1102 systems, as well as the respective connectivity to othe r systems.
1103 5.5 Potential Consequences
1104 People who know the features and weaknesses of open operating systems and networks
1105 could potentially intrude into console devices, remote devices, databases, and, in some
1106 cases, control platforms. The consequences of intrusions into industrial automation and
1107 control systems may include:
1108 a) unauthorized access, theft, or misuse of confidential information
1109 b) publication of information to unauthorized destinations
1110 c) loss of integrity or reliability of process data and production information
1111 d) loss of system availability
1112 e) process upsets leading to compromised process functionality, inferior product quality,
1113 lost production capacity, compromised process safety, or environmental releases
1114 f) equipment damage
1115 g) personal injury
1116 h) violation of legal and regulatory requirements
1117 i) risk to public health and confidence
1118 j) threats to a nations security.
1119 5.6 Impact of Countermeasures
1120 Security countermeasures applied in an IACS environment should not have the potential to
1121 cause loss of essential services and functions, including emergency procedures. IACS
1122 security goals focus on control system availability, plant protection, plant operations (even in
1123 a degraded mode) and time-critical system response. General purpose security goals often do
1124 not place the same emphasis on these factors and may be more concerned with protecting
1125 information rather than physical assets. These different goals need to be clearly stated as
1126 security objectives regardless of the degree of plant integration achieved.
1127 A key step in risk assessment, as required by ISA62443-2-1, is the identification of which
1128 services and functions are truly essential for operations. (For example, in some facilities
1129 engineering support may be determined to be a non-essential service or function.) It may be
1130 acceptable for a security action to cause temporary loss of a non -essential service or function,
1131 unlike an essential service or function that should not be adversely affected.
1132 5.7 Common Constraints

1133 There are a number of common constraints that shall be adhered to in the application of
1134 security to an IACS. This clause and subsequent normative clauses furnish the material
1135 necessary to build extensions to existing enterprise security to support the rigorous integrity
1136 and availability requirements needed by IACS.
1137 5.7.1 GEN 1.0 Support of Essential Functions

1138 5.7.1.1 Requirement
1139 Security measures shall not adversely affect essential functions of a high availability IACS
1140 unless supported by a risk assessment.
1141 NOTE: Refer to ISA62443-2-1 regarding the documentation requirements associated with the risk assessment
1142 required to support instances where security measures may affect essential functions.
1143 5.7.1.2 Rationale
1144 When reading, specifying and implementing the normative requirements in this standard,
1145 implementation of security measures should not cause loss of protection, loss of control, loss
1146 of view or loss of other essential functions. After a risk analysis, some facilities may determine
1147 certain types of security measures may halt continuous operations, but security measures
1148 shall not result in loss of protection that could result in health, safety and environmental (HSE)
1149 consequences. Specifically;
1150 Access Controls (IAC and UC) shall not prevent the operation of essential functions,
1151 including:
1152 Accounts used for essential functions shall not be locked out, even temporarily.
1153 Verifying and recording operator actions to enforce non -repudiation shall not add
1154 significant delay to system response time.
1155 For high availability control systems, the failure of the certificate authority shall not
1156 interrupt essential functions.
1157 Identification and authentication shall not prevent the initiation of the SIF. Similarly for
1158 authorization enforcement.
1159 Incorrectly time stamped audit records shall not adversely affect essential functions.
1160 Essential functions of an IACS shall be maintained if zone boundary protection goes into
1161 fail-close and/or island mode.
1162 A denial of service (DoS) event on the control system or safety instr umented system (SIS)
1163 network shall not prevent the SIF from acting.
1164 5.7.2 GEN 2.0 Compensating countermeasures
1166 As used in this document, they shall adhere to the guidelines described in ISA62443-3-2.
1167 5.7.2.2 Rationale

1168 In this standard, normative language may state that the control system shall provide the
1169 capability to support some specific security requirement. The control system shall provide the
1170 capability, but it might be performed by an external component. In such a case, the control
1171 system shall provide an interface to that external component. Some examples of
1172 compensating countermeasures include user identification (including centralized versus
1173 distributed), password strength enforcement, signature validit y checking, security event
1174 correlation and device decommissioning (information persistence).
1175 NOTE 1 The control system security requirements detailed in this document pertain to all technical functions
1176 relevant to a control system including tools and applications. However, as noted here, some of these functions can
1177 be handled by an external resource.
1178 NOTE 2 In some high resource availability applications (high SL -T(RA,control system)), compensating
1179 countermeasures external to the control system (such as a dditional physical security measures and/or enhanced
1180 personnel background checks) will be needed. In these cases, it may be possible to see a normally high resource
1181 availability SL control system at a lower IAC SL 1 or 2 rating, depending upon the compensa ting countermeasures.
1182 Lockout or loss of control due to security measures is increased, not decreased for very high availability SL control
1183 system. Thus higher SLs are not always better, even where cost is not a significant factor.
1184 6 Security Elements

1185 6.1 Introduction
1186 The analysis of a complex system often leads to the breakdown of its elements into three
1187 broad categories; people, processes, and technology. This has also been referred to as
1188 the people-process-technology triad or triangle. Although this approach has been applied to
1189 many types of business and technical processes its application to cyber security can be
1190 summarized in the following figure.
Te
s
ch
s
ce
no
o
Pr
log
Security
y
People
1191
1192 Figure 2 Security Elements Grouping
1193 Strong processes can often help to overcome potential vulnerabilities in a security product,
1194 while poor implementation can render good technologies ineffective. Often, human
1195 weaknesses can diminish the effectiveness of technology. A prime example is the IACS
1196 devices that have unnecessary Internet and networking services running simply because
1197 users are unaware that these services are running by default and could contain vulnerabilities.
1198 6.2 People

1199 People in the context of IACS cyber security includes the management, s taff, contractors, and
1200 other personnel who develop, follow, implement, enforce, and manage all components of the
1201 IACS cyber security program. It is important that all stakeholders and participants positively
1202 support and promote security, they understand th eir roles and responsibilities, and there are
1203 sufficient resources in place.
1204 The following topic areas fall under people:
1205 Relationships - Make a concerted effort to break down the traditional relationship barriers
1206 between the Control and IT groups from the technical all the way up to the management
1207 levels of the organization. The goal is to have cooperative relationships across the
1208 different functional areas of the company, and organizational levels. This also applies to
1209 the relationship between the Asset Owner and the Vendor/Integrator responsible for
1210 installing and maintaining the IACS.
1211 Intent, Buy-In, Support - Ensure that all personnel have the intent and motivation to uphold
1212 cyber security policies, practices, and ensure continual improvement. People co uld be
1213 defiant or entirely supportive of the security program and is measured as a scale of
1214 individual participation.
1215 Resourcing - Having the appropriate staffing levels and time commitment to perform the
1216 tasks associated with the IACS Security Management System (e.g. log reviews, patching,
1217 risk assessment).
1218 Roles & Responsibilities - Define who owns the process, who supports the process, what
1219 are their roles, are they committed to improving the program and working together. There
1220 is a commonly used method for assigning those Responsible, Accountable, Consulted, and
1221 Informed (RACI) for each task of the process.
1222 Training and Capability - Ensure that existing personnel are adequately qualified to
1223 perform the duties associated with IACS security. As well, ensur e that new capabilities are
1224 developed where they may not have existed in the organization before (e.g. risk analysis,
1225 security intelligence, vulnerability management).
1226 -Awareness and Influenced Decision Making - Ensure that personnel have sufficient
1227 awareness and understanding of security policies and security processes as it will
1228 influence their decision making and voluntary use of these processes.
1229 A measurement of success for effectively addressing these issues is a culture of security
1230 within the organization with people motivated and active promoting adherence with security
1231 requirements.
1232 At this time, guidance on addressing social and organizational behaviors within an
1233 organization are not part of the ISA62443 series of documents and may be reconsidered in
1234 the future.
1235 6.3 Processes

1236 Processes in the context of IACS cyber security are the policies, procedures, forms, business
1237 processes, and other documentation associated with the IACS Security Management System.
1238 The objective is to establish a business process and task to be completed in relation to the
1239 IACS Security Management System such change control, access management, patching,
1240 inventory management, security testing, etc.
1241 Processes can be implemented in several ways, but are built upon smaller components of
1242 documentation.
1243 Policy - A policy is a formal, brief, and high-level statement or plan that embraces an
1244 organization's general beliefs, goals, objectives, and acceptable procedures for a specified
1245 subject area.
1246 Standard, Procedures - A standard is a formal document that establishes mandatory
1247 requirements, engineering, technical criteria, methods, etc. A standard is meant to convey
1248 a mandatory action or rule and is written in conjunction with a policy. A process or
1249 procedure document may also be called a standard, which typically describes the act of
1250 taking something through an established and usually routine set of procedures or steps to
1251 convert it from one form to another, such as processing paperwork to grant p hysical or
1252 cyber access, or converting computer data from one form to another.
1253 Guideline - Guidelines are not required as part of a policy framework; however, they can
1254 play an important role in conveying best practice information to the user community.
1255 Guidelines are meant to guide users to adopt behaviors which increase the security
1256 posture of a network, but are not yet required (or in some cases, my never be required).
1257 In the context of the ISA62443 series, the specific structure and content of policies,
1258 standards, and guidelines are left to the IACS asset owner. However, the series organizes the
1259 subject areas associated with IACS processes in the following clauses, categories and
1260 domains:
1261 Security Policy

1262 Organization of Security
1263 Asset Management
1264 Human Resources Security
1265 Physical and Environmental Security
1266 Communications and Operations Management
1267 Access Control
1268 Systems acquisition, development and maintenance
1269 Incident Management
1270 Business Continuity Management
1271 Compliance
1272 For a traditional information system, requirements and detail for the clauses above can be
1273 found in ISO/IEC 27002 Code of Practice for Information Security Management. For an IACS
1274 Security Management System, the unique requirements and enhanceme nts can be found in
1275 ISA62443-2-1 (Requirements for an IACS Security Management System ).
1276 6.4 Technology

1277 Technology in the context of IACS cyber security are all the technical security controls in
1278 place to uphold its availability, integrity, and confidentiality. This would include traditional
1279 solutions for authentication, access control, encryption, as those technical measures are
1280 applied to reduce the security risks to the IACS. The objective of technology relative to IACS
1281 is to ensure that security risks are reduced and security-related business processes could be
1282 automated where feasible.
1283 In the context of the ISA62443 series, the organization of the technical security controls are
1284 grouped in to the following categories:
1285 Identification, Authentication and Access Control (AC)
1286 Use Control (UC)
1287 System Integrity (SI)
1288 Data Confidentiality (DC)
1289 Restrict Data Flow (RDF)
1290 Timely Response to Event (TRE)
1291 Resource Availability (RA)
1292 For more information on the seven (7) subjects above, refer to the clause on Foundational
1293 Requirements. Additional detail is provided in ISA62443-3-3 (System Security Requirements
1294 and Security Levels). These foundational requirements are expressed in terms of IACS, and
1295 are robust enough categories to allow any security control or setting (e.g. , firewall rules,
1296 running services) to have an appropriate category.
1297 6.5 Use Cases

1298 Antivirus software is a good example of how people-process-technology all have roles in its
1299 effectiveness.
1300 Antivirus Technology Once deployed, it is important that antivirus software is correctly
1301 configured to fulfill its expected responsibility to deter and prevent malicious code. Antivirus
1302 software should also be regularly updated to ensure it has the latest detection signatures.
1303 Lastly, antivirus software technology on its own is not a panacea and other technical security
1304 controls are also recommended.
1305 Antivirus Processes A policy must exist to require the use and maintenance of antivirus
1306 software, as well as procedures for its correct deployment, operations and maintenance. A
1307 failure in a business process would be that a malicious code detection goes unnoticed as
1308 there are no requirements to monitor alerts or respond to these incidents.
1309 Antivirus People (Personnel) Trained individuals must be assigned the responsibility of
1310 managing the antivirus technologies and accountable for its correct operation. If staff are
1311 insufficient trained it leads to configuration errors, if there are insufficient staff this leads to
1312 incomplete system maintenance, and if accountability is not clearly communicated it leads to
1313 overall disregard and disrepair of this technology investment.
1314 The antivirus example helps illustrate how the people-process-technology triad applies to
1315 cyber security controls. If any part of the triad is neglected it will lead to poor performance
1316 and/or failure of the IACS security program.
1317 Consider the roles of people-process-technology similar to a table with three legs. If attention
1318 and resources is lacking to any of them, the table will fall over similar to the challenges faced
1319 by an IACS security program.
Proc
ess
le
op
ity
ur
Pe
c
Se gy
olo
c hn
Te
1320
1321
Figure 3 Three-Legged Table
1322 Change control and configuration management is particularly important to assuring the
1323 security integrity, trust and confidence of the IACS. The seemingly subtle configuration
1324 changes within the control systems components could be excluded from change control
1325 processes because they are quick to perform and are assumed to have limited, controllable
1326 effects. However, these same changes can have drastic effects on the operability, reliability,
1327 and vulnerabilities associated with the IACS. Using the people -process-technology triad as a
1328 methodology to resolve this problem, the following strategies and solutions could be applied.
1329 Table 1 Elements Applied to Change Control and Configuration Management
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 acco untable for ensuring 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 control 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 the this new program and adjust as need ed.
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.
1330
1331 The example above is not a detailed plan for improving change control and configuration
1332 management processes, but it effectively summarizes the importance of the people -process-
1333 technology triad. In reality, the three aspects people -process-technology must be addressed
1334 simultaneously in order to have the greatest success.
1335 In the following sections each of the principles of people, process and technology are further
1336 defined and their subjects identified.
1337 6.6 Summary

1338 Now that the concepts of people, processes, and technology are clearly defined; they can now
1339 be visualized with their respective subject areas. The core and foundational principle of the
1340 IACS Security Management System is the people -process-technology triad.
C)
o l (A
ontr
sC
Fo
s
cce
un
da
A
nd
tio
a
na
t ion
lR
es
Or tica
us
eq
ga Se en
uth
Cla
cu
uir
niz rity ,A
em
Co ati
mm Ph o n Po ion
en
ysi Hu As
s of licy
ficat
ts
un m et Se
Sy ica ca
l an M cu nti C)
tio an Re an rity Ide l (U
ste d
ms ns E so ag tro
ac an n vir u rce e me on ( SI)
qu dO on sS nt eC ri ty
isit pe me ec Us eg )
ion rat nta uri Int DC
ion l ty y(
,d
ev sM S ec ste
m alit
elo an u rity Sy nti F)
pm ag nf ide RD
Te
Ac em E)
en ce en Co w( (TR
s
ta
Bu ss t ta Flo
ch
nd Da nt
sin
es
sC
I nc
ide ma
int
C o ntr
ol
es tD
ata
oE
ve
no
oc
nt en ic t
on Ma an str on
se
tin Re A)
Pr
ce
lo
uit na p (R
yM g em R es ty
bili
gy
an en Security ely
ag t Tim aila
Co
em
en e Av
mp t rc
lian s ou
ce Re
People
Resourcing
Relationships
Intent, Buy-In, Support
Training and Capability
Decisions and Awareness

Roles & Responsibilities
1341 Not part of ISA-62443 series of documents
1342 Figure 4 Implementation of People, Process, and Technology
1343 The technical requirements associated with IACS security are prescribed by the ISA62443
1344 standards commensurate with the Security Level (SL) assigned to each zone and conduit. The
1345 Foundation Requirements defined in ISA62443-1-1 are the categories used to organize these
1346 technical security controls, and set the foundation for other ISA62443 normative
1347 requirements.
1348 The policy and procedure (process) requirements build off of ISO/IEC 27002 with specific
1349 requirements unique to IACS. The clauses in ISA62443-2-1 are the categories used to
1350 organize security processes.
1351 The personnel and resource (people) requirements associated with an IACS Security
1352 Management System are outside the scope of ISA62443. Although it is considered extremely
1353 important, the outputs of ISA62443 shall continue to be focused on technical and process
1354 requirements. Readers are advised to research and study topics such as organizational
1355 behavior, instituting change, and other business sociology and leadership materials.
1356 Each of these essential elements are reflected in a description of cyber security related
1357 concepts. These concepts in turn are broken into two groups. The first group includes the
1358 concepts that are applicable to virtually any cyber security response, while the second group
1359 includes concepts that are specific or unique to the industrial automation and control systems
1360 environment. Each of these groups are described in subsequent clauses.
1361 7 Principal Roles

1362 7.1 General
1363 The People element of a cybersecurity management system shall be addressed through the
1364 definition and consistent application of a set of common role descriptions. These descriptions
1365 shall define the specific accountability and responsibilities of each role, as well as the
1366 relationships and dependencies between roles.
1367 As a minimum the roles described shall include the following:

1368 Asset Owner This is the person or organization that has primary accountability for the IACS
1369 and its security. Responsibilities include the identification of the consequence compo nent of
1370 risk, and the consistent operation of the cybersecurity management system.
1371 Asset Operator This is the person or organization that is accountable for the operation of
1372 the system under consideration. This may or may not be the same entity as the As set Owner.
1373 For example, the Asset Owner may be different in situations involving some sorts of joint
1374 ventures or similar business structures.
1375 System Integrator It is common for an IACS to be designed and configured by an

1376 independent or external system integrator, according to specifications and requirements
1377 provided by the asset owner.
1378 Product Supplier The principal responsibility of the product supplier is to design and
1379 provide the specific components that are used to assemble the IACS.
1380 Service Provider Ensuring the security of an IACS also requires services throughout the
1381 life cycle, including regular maintenance and system updates.
1382 Compliance Authority Organizations in this role include government agencies and
1383 regulators with the legal authority to perform audits to verify compliance with governing laws
1384 and regulations.
1385 More details about the contributions of each of these roles is provided in the description of the
1386 Life Cycle fundamental concept.
1387 8 IACS Definition
1388 In order to fully articulate the systems and components the ISA62443 standards address, the
1389 range of coverage may be described from several perspectives, including:
1390 1) range of functionality included

1391 2) systems and interfaces
1392 3) criteria for selecting included activities
1393 4) criteria for selecting included assets
1394 5) consequence based criteria
1395 Each of these is described in the following paragraphs.
1396 8.1 Functionality Included

1397 The scope of IACS security can be described in terms of the range of functionali ty within an
1398 organizations information and automation systems. This functionality is typically described in
1399 terms of one or more models.
1400 This standard is focused primarily on industrial automation and control, as described in a
1401 reference model (see page 38). Industrial automation and control includes the supervisory
1402 control components typically found in process industries, as well as SCADA (supervisory
1403 control and data acquisition) systems that are commonly used by organizations that operate in
1404 critical infrastructure industries. These include:
1405 a) electricity transmission and distribution

1406 b) gas and water distribution networks
1407 c) oil and gas production operations
1408 d) gas and liquid transmission pipelines
1409 This is not an exclusive list. SCADA systems may also be found in other critical and non-
1410 critical infrastructure industries.
1411 While business planning and logistics systems are not explicitly addressed within the scope of
1412 this standard, the integrity of data exchanged between business and indus trial systems is
1413 considered.
1414 8.2 Systems and Interfaces

1415 It is also possible to describe the IACS in terms of connectivity to associated systems. In
1416 encompassing all industrial automation and control systems, this standard covers systems
1417 that can affect or influence the safe, secure, and reliable operation of industrial processes.
1418 They include, but are not limited to:
1419 a) Industrial control systems and their associated communications networks, including
1420 distributed control systems (DCSs), programmable logic contro llers (PLCs), remote
1421 terminal units (RTUs), intelligent electronic devices, SCADA systems, networked
1422 electronic sensing and control, metering and custody transfer systems, and monitoring
1423 and diagnostic systems. In this context, industrial control systems include basic
1424 process control system and safety-instrumented system (SIS) functions, whether they
1425 are physically separate or integrated.
1426 b) Associated systems at level 3 or below of the Reference Model. Examples include
1427 advanced or multivariable control, online optimizers, dedicated equipment monitors,
1428 graphical interfaces, process historians, manufacturing execution systems, pipeline
1429 leak detection systems, work management, outage management, and electricity energy
1430 management systems.
1431 c) Associated internal, human, network, software, machine or device interfaces used to
1432 provide control, safety, manufacturing, or remote operations functionality to
1433 continuous, batch, discrete, and other processes.
1434 8.3 Activity-Based Criteria
1435 ANSI/ISA-95.00.03 [5] defines a set of criteria for defining activities associated with
1436 manufacturing operations. A similar list has been developed for determining the scope of this
1437 standard. A system should be considered to be within the range of coverage of these
1438 standards if the activity it performs is necessary for any of the following:
1439 a) predictable operation of the process

1440 b) process or personnel safety
1441 c) process reliability or availability
1442 d) process efficiency
1443 e) process operability
1444 f) product quality
1445 g) environmental protection
1446 h) compliance with relevant regulations
1447 i) product sales or custody transfer affecting or influencing industrial processes.
1448 8.4 Asset-Based Criteria
1449 The coverage of this standard includes those systems in assets that meet any of the following
1450 criteria, or whose security is essential to the prot ection of other assets that meet these
1451 criteria:
1452 a) The asset is necessary to maintain the economic value of a manufacturing or operating
1453 process.
1454 b) The asset performs a function necessary to operation of a manufacturing or operating
1455 process.
1456 c) The asset represents intellectual property of a manufacturing or operating process.
1457 d) The asset is necessary to operate and maintain security for a manufacturing or
1458 operating process.
1459 e) The asset is necessary to protect personnel, contractors, and visitors involved in a
1460 manufacturing or operating process.
1461 f) The asset is necessary to protect the environment.
1462 g) The asset is necessary to protect the public from events caused by a manufacturing or
1464 h) The asset is a legal requirement, especially for security purpo ses of a manufacturing or
1466 i) The asset is needed for disaster recovery.
1467 j) The asset is needed for logging security events.
1468 This range of coverage includes systems whose compromise could result in the endangerment
1469 of public or employee health or safety, loss of public confidence, violation of regulatory
1470 requirements, loss or invalidation of proprietary or confidential information, environmental
1471 contamination, and/or economic loss or impact on an entity or on local or national security.
1472 8.5 Consequence-Based Criteria

1473 During all phases of the systems life cycle, cybersecurity risk assessments shall include a
1474 determination of where and what could go wrong to disrupt IACS operations, what is the
1475 likelihood that a cyber-attack could initiate such a disruption, and what are the consequences
1476 that could result. The output from this determination shall include sufficient information to help
1477 the ordinary user (not necessarily security-conscious ones) to identify and determine the
1478 relevant security properties.
1479 The method of determination shall include a decomposition of a system under consideration in
1480 accordance with the specifications in ISA62443-3-2 and make visible the interaction between
1481 individual components. Functional relationships and the models used to translate the security
1482 strength of lower level components into aggregated measures shall be delineated to the
1483 degree necessary to determine the response action in accordance with the specifications in
1484 ISA62443-1-3.
1485 9 Models
1486 9.1 General
1487 A set of models shall be developed as the basis for identifying the security needs and
1488 important characteristics of the environment at a level of detail necessary to address security
1489 issues with a common understanding of the framework and vocabulary.
1490 Specific models that shall be used include:
1491 a) a reference model that provides the overall conceptual basis for the more detailed
1492 models that follow.
1493 b) a reference architecture that describes the configuration of assets. A reference
1494 architecture can be unique for each enterprise or subset of the enterprise. It is unique
1495 for each situation depending on the scope of the industrial automation and control
1496 system under review.
1497 c) a zone model that groups reference architecture components according to defined
1498 characteristics. This provides a context for the definition of policies, procedures, and
1499 guidelines, which in turn are applied to the assets.
1500 All of this information is used to develop a detailed program for managing the security of an
1501 industrial automation and control system.
1502 Each of these models is described in more detail in the following pages.
1503 9.2 Reference Model

1504 A reference model establishes a frame of reference for the more detailed information that
1505 follows. The term reference model became popular with the success of the ISO Seven
1506 Layer model for Open Systems Interconnection (OSI).
1507 A reference model describes a generic view of an integrated manufacturing or production

1508 system, expressed as a series of logical levels. The reference model used by the ISA62443
1509 series of standards appears in figure 5. This model is derived from the general model used in
1510 ANSI/ISA-95.00.01-2000, Enterprise-Control System Integration Part 1: Models and
1511 Terminology [4].
Level 4 Enterprise Systems
(Engineering, Business Planning & Logistics)
Operations / Systems
Level 3
Management
Supervisory Control
Site Monitoring & Local

Level 2 Display
Industrial
Automation
and Control
Systems
Basic Control
Level 1
Safety and Protection
Process
Level 0 (Equipment Under Control)
1512
1513 Figure 5 Reference Model
1514 Detailed descriptions of each of the levels in this model are provided in ANSI/ISA-95.00.01-
1515 2000, Enterprise-Control System Integration Part 1: Models and Terminology, and
1516 summarized in the following paragraphs.
1517 9.2.1 Level 4 Enterprise Business Systems

1518 This level (also described as Business Planning and Lo gistics) is defined as including the
1519 functions involved in the business-related activities needed to manage a manufacturing
1520 organization. Functions include enterprise or regional financial systems and other enterprise
1521 infrastructure components such as production scheduling, operational management, and
1522 maintenance management for an individual plant or site in an enterprise. For the purposes of
1523 this standard, engineering systems are also considered to be in this level.
1524 9.2.2 Level 3 - Operations Management

1525 This level includes the functions involved in managing the work flows to produce the desired
1526 end products. Examples include dispatching production, detailed production scheduling,
1527 reliability assurance, and site-wide control optimization.
1528 9.2.3 Level 2 Supervisory Control

1529 This level includes the functions involved in monitoring and controlling the physical process.
1530 There are typically multiple production areas in a plant such as distillation, conversion,
1531 blending in a refinery or the turbine deck, and coal processing facilities in a utility power plant.
1532 9.2.4 Level 1 Local or Basic Control

1533 This level includes the functions involved in sensing and manipulating the physical process.
1534 Process monitoring equipment reads data from sensors, executes algorithms if necessary,
1535 and maintains process history. Examples of process monitoring systems include tank gauging
1536 systems, continuous emission monitors, rotating equipment monitoring systems, and
1537 temperature indicating systems. Process control equipment is similar. It reads data fro m
1538 sensors, executes a control algorithm, and sends an output to a final element (e.g., control
1539 valves or damper drives). Level 1 controllers are directly connected to the sensors and
1540 actuators of the process.
1541 Level 1 includes continuous control, sequence c ontrol, batch control, and discrete control.
1542 Many modern controllers include all types of control in a single device.
1543 Also included in Level 1 are safety and protection systems 2 that monitor the process and
1544 automatically return the process to a safe state if it exceeds safe limits. This category also
1545 includes systems that monitor the process and alert an operator of impending unsafe
1546 conditions.
1547 Safety and protection systems have traditionally been implemented using physically separate
1548 controllers, but more recently it has become possible to implement them using a method
1549 known as logical separation, within a common infrastructure. The depiction shown in this
1550 reference model was chosen to emphasize the need for this separation (logical or physical) to
1551 ensure the integrity of the safety functions.
1552 Level 1 equipment includes, but is not limited to:
1553 d) DCS controllers

1554 e) PLCs
1555 f) RTUs.
1556 Safety and protection systems often have additional safety requirements that may not be
1557 consistent or relevant to cyber security requirem ents. These systems include the safety
1558 systems in use in chemical and petrochemical plants as identified in the ANSI/ISA -84 series of
1559 standards, nuclear plant safety or safety-related systems as identified in the ANSI/ISA-67
1560 series, and protective functions as identified in IEEE Power Engineering Society standards.
1561 9.2.5 Level 0 Process

1562 This level is the actual physical process. The process includes a number of different types of
1563 production facilities in all sectors including, but not limited to, discrete parts manufacturing,
1564 hydrocarbon processing, product distribution, pharmaceuticals, pulp and paper, and electric
1565 power. Level 0 includes the sensors and actuators directly connected to the process and
1566 process equipment.
1567 9.3 Reference Architecture Model

1568 The reference architecture model shall be used to describe the various operational
1569 components and how they are connected. The details are specific to each individual system
1570 under consideration. Each organization shall create one or more physical architecture mode ls
1571 depending on the business functions performed, as well as the functions under review.
1572 It would be common for an organization to have a single generic model that has been
1573 generalized to cover all operating facilities. An example of a simplified referenc e architecture
1574 model for a manufacturing function is shown in Figure 6.

2 These systems are referred to as safety instrumented systems in standards such as the ANSI/ISA-84 series.
Enterprise
Laptop computer Workstation Mainframe
Server Server
Plant A Plant B Plant C
Router Router Router
Laptop computer Workstation Laptop computer Workstation Laptop computer Workstation
File/Print App. Data File/Print App. Data File/Print App. Data
Server Server Server Server Server Server Server Server Server
Plant A Control System Plant B Control System Plant C Control System
Firewall Firewall Firewall
App. Data Maint. App. Data Maint. App. Data Maint.

Controller Controller Controller Controller Controller Controller
1575 I/O I/O I/O I/O I/O I/O
1576 Figure 6 Physical Architecture Model Example
1577 9.4 Zone Model

1578 A zone model shall be developed from the physical architecture model. It shall be used to
1579 describe the logical groupings of assets within an enterprise or a subset of the enterprise.
1580 The assets shall be grouped into entities (e.g., business, facility, site, or IACS) that can then
1581 be analyzed for security policies and hence requirements. The model provide the context for
1582 assessing common threats, vulnerabilities, and the corresponding countermeasures needed to
1583 attain the level of security required to protect the grouped assets. After grouping assets in this
1584 manner, a security policy shall be defined for all assets that are members of the zone. This
1585 analysis shall be used to determine the appropriate protection required based on the activities
1586 performed in the zone.
1587 10 General Concepts

1588 There are several general concepts that are important in the field of cyber security,
1589 irrespective of the scope of application. The purpose of this clause is to provide a n informative
1590 overview of those concepts.
1591 10.1 Security Context

1592 The security context forms the basis for the interpretation of terminology and concepts and
1593 shows how the various elements of security relate to each other. The term security is
1594 considered here to mean the prevention of illegal or unwanted penetration of or interference
1595 with the proper and intended operation of an industrial aut omation and control system.
1596 Electronic security includes computer, network, or other programmable components of the
1597 system.
1598 The context of security is based on the concepts of threats, risks, and countermeasures, as
1599 well as the relationships between them. The relationship between these concepts can be
1600 shown in a simple model. One such model is described in the international standard ISO/IEC
1601 15408-1 (Common Criteria) [15]. It is reproduced in Figure 7.
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

1602
1603 Figure 7 Context Element Relationships
1604 A different view of the relationship is shown in Figure 8, which shows how an expanded set of
1605 concepts are related within the two interconnected processes of information security
1606 assurance 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
1607
1608 Figure 8 Context Model
1609 10.2 Security Objectives

1610 Information security has traditionally focused on achieving three objectives, confidentiality,
1611 integrity, and availability, which are often abbreviated by th e acronym CIA. An information
1612 technology security strategy for typical back office or business systems may place the
1613 primary focus on confidentiality and the necessary access controls needed to achieve it.
1614 Integrity might fall to the second priority, with availability as the lowest.
1615 In the industrial automation and control systems environment, the general priority of these
1616 objectives is often different. Security in these systems is primarily concerned with maintaining
1617 the availability of all system components. There are inherent risks associated with industrial
1618 machinery that is controlled, monitored, or otherwise affected by industrial automation and
1619 control systems. Therefore, integrity is often second in importance. Usually confidentiality is of
1620 lesser importance, because often the data is raw in form and must be analyzed within context
1621 to have any value.
1622 The facet of time responsiveness is significant. Control systems can have requirements of
1623 system responsiveness in the 1 millisecond range, whereas traditional business systems are
1624 able to successfully operate with single or multiple second response times.
1625 10.3 Least Privilege

1626 The principle of least privilege means giving a user or application only those privileges which
1627 are essential to complete the necessary tasks. When applied to users, the terms least user
1628 access or least-privileged user account (LUA) are also used, referring to the concept that all
1629 user accounts at all times should run with as few privileges as possible, and also launch
1630 applications with as few privileges as possible.
1631 10.4 Defense in Depth
1632 It is typically not possible to achieve the security objectives through the use of a single
1633 countermeasure or technique. A superior approach is to use the concept of defense in depth,
1634 which involves applying multiple countermeasures in a layered or stepwise manner. For
1635 example, intrusion detection systems can be used to signal the penetration of a firewall.
1636 10.5 Threat-Risk Assessment

1637 Within the threat-risk assessment process, assets are subject to risks. These risks are in turn
1638 minimized through the use of countermeasures, which are applied to address vulnerabilities
1639 that are used or exploited by various threats. Each of these elements is described in more
1640 detail in this clause.
1641 10.6 Policies and Procedures

1642 10.6.1 General
1643 Security policies enable an organization to follow a consistent program for maintaining an
1644 acceptable level of security. Policies are defined at different levels in an organization, ranging
1645 from governance or management policies established at the enterprise level to operation
1646 policies defining the details of security administration. Policies at the most specific level are
1647 the organization's standard against which security audits can measure compliance.
1648 A security policy is a formal, brief, and high-level statement or plan that embraces an
1649 organizations general beliefs, goals, objectives, and acceptable procedures that specify or
1650 regulate how an organization protects sensitive and critical system resources. Policies
1651 unambiguously state what is mandatory. Because policies are mandatory and unambiguous,
1652 they make audits possible. The organization's security policies also take into account legal,
1653 regulatory, and contractual obligations. They are the measuring stick against which audits test
1654 the actual practices of the organization.
1655 Complementing policies are standards and procedures. A standard is a formal document that
1656 establishes mandatory requirements, engineering, technical criteria, methods, etc. A standard
1657 is meant to convey a mandatory action or r ule and is written in conjunction with a policy. A
1658 process or procedure document may also be called a standard, which typically describes the
1659 act of taking something through an established and usually routine set of procedures or steps
1660 to convert it from one form to another, such as processing paperwork to grant physical or
1661 cyber access, or converting computer data from one form to another. Security procedures
1662 define in detail the sequence of steps necessary to provide a certain security measure.
1663 Contrasting with policies, standards and procedures are guidelines. Guidelines are not
1664 mandatory. They are intended to describe a way to do something that is desirable but not
1665 mandatory and are not a required element of a policy framework; however, they can play an
1666 important role in conveying best practice information to the user community. Guidelines are
1667 meant to guide users to adopt behaviors which increase the security posture of a network,
1668 but are not yet required (or in some cases, my never be required). Beca use guidelines are not
1669 mandatory and may be ambiguous, practices cannot be audited against guidelines. Guidelines
1670 are sometimes written by a group that does not have the authority to require them to be
1671 followed. Guidelines are inappropriate to describe pra ctices that are mandatory.
1672 Because the policies, standards and procedures for different parts of an organization are
1673 often different, it is important that they be adequately coordinated. Specifically, the security
1674 policy for IACS must be coordinated with similar policies for general purpose IT security. The
1675 security program will work more successfully if there are good working relationships among
1676 the parties, and a well-coordinated set of policies can support good relationships.
1677 Some consistency to the structure of the various policies, standards and procedures increases
1678 the coherence of the overall set of policies and procedures. Each policy or procedure
1679 document has a short but precise statement of its purpose. It also has a statement of scope
1680 that defines where the document applies. It has a description of the risks that it is intended to
1681 reduce and of the key principles of the document. These common items guide the reader by
1682 providing more information about the intention of the policy or procedure. They also describe
1683 the intent of the document to provide guidance, which is useful when the document needs to
1684 be revised.
1685 Different phases in a systems life cycle have different profiles of security issues. Security
1686 policies and procedures may address only certain life cycle phases. Some policies and
1687 procedures may specify that they only pertain to certain phases. All of the security concerns
1688 from all of the various phases are addressed in corresponding places in the set of security
1689 policies and procedures.
1690 Security policies, standards and procedures contain instructions on how the organization will
1691 measure compliance and update the policies. Organizations often recognize that policies need
1692 to be updated when performing or evaluating audits. Audits may i dentify ambiguities in
1693 policies and procedures as well as parts of policies and procedures that do not make the
1694 required process or outcome clear. Audits can identify issues that should be added to policies
1695 and procedures. Audits may also identify requirem ents that should be reevaluated and
1696 adjusted or possibly retracted.
1697 Policies, standards and procedures should allow for unforeseen circumstances that make it
1698 infeasible to follow them. Policies should also state how to document and approve exceptions
1699 to policies and procedures. Documenting approved exceptions leads to a clearer state of
1700 security than leaving imprecision and ambiguity in the policies and procedures.
1701 In addition, organizations should be unambiguous about what is a requirement versus what is
1702 optional advice in a policy or standard. Precise use of words like shall, must, may, and
1703 is removes the ambiguity. Policy statements can define these words in their introduction
1704 sections to be more precise. Shall and must are used for requiremen ts. May is used for
1705 advice that is optional, and therefore is not used in the mainstream of policies and
1706 procedures. It can be appropriate to provide options for addressing a requirement. Phrases
1707 like when possible or unless necessary introduce ambig uity unless the statement also
1708 describes how to determine whether the case is possible or necessary.
1709 Policies, standards and procedures identify who is responsible for what. Is the process control
1710 staff responsible for the control network? Is it responsible for a demilitarized zone (DMZ)
1711 between the control network and the enterprise network? If an enterprise information systems
1712 department is responsible for conditions that require the process control staff to perform
1713 certain operations, then these operations should be described.
1714 For an organization that is just starting to create its security program, policies and standards
1715 are a good place to begin. Initially, they can be written to cover the set of security practices
1716 that the organization is equipped to handle in the near term. Over time they can be revised
1717 and tightened as the organization's capability grows. They can be put in place without the lead
1718 time of procuring and installing systems and devices.
1719 10.6.2 Enterprise Level

1720 The policy at the enterprise level mandates the security program and sets the direction. It
1721 states the organization's overall security objectives.
1722 The policy statement of top management should be circumspect enough to remain pertinent
1723 and accurate through changes in the struc ture of the organization, changes in system and
1724 security technology, and changes in the kinds of security threats. By being circumspect, the
1725 policy can be stable and will need to be rewritten only when the organization's basic position
1726 on security changes. However, the policy statement is also unambiguous; it clearly identifies
1727 what is required.
1728 The enterprise level policy identifies areas of responsibility and assigns accountability for
1729 those areas. The policy can define the relationship between the enterp rise IT department and
1730 plant operations and identify their different responsibilities. The policy can differentiate
1731 security objectives of the control system from those of the enterprise network. For example,
1732 maintaining confidentiality may be a top consid eration of security for the enterprise network,
1733 whereas maintaining continuous operation may be a top consideration for the control system.
1734 In addition, the policy identifies particular standards and regulations that apply to the
1735 organization. It may identify training as an important component of the security program. The
1736 policy may also indicate the consequences for policy violations.
1737 Management should communicate the policy throughout the organization so that all
1738 employees understand it.
1739 10.6.3 Operational Level

1740 Operational policies, standards and procedures are developed at lower levels of the
1741 organization to specify how the enterprise level policy is implemented in a specific set of
1742 circumstances. Security standards and procedures put the policy into effect. They define what
1743 the organization will do to achieve the objectives and to meet the requirements of the policy.
1744 The procedures establish processes that will address all the concerns of the policy.
1745 The standards and procedures address all components needed in a security program,
1746 including:
1747 a) system design

1748 b) procurement
1749 c) installation
1750 d) process operation
1751 e) system maintenance
1752 f) personnel
1753 g) audit
1754 h) training
1755 The standards and procedures identify specific activities, who is accountable for their
1756 performance, and when activities will be performed.
1757 The written procedures describe the process by which they will be changed when the situation
1758 changes. Each policy, standard or procedure has an identified owner responsible for
1759 recognizing when updates are needed and for ensuring they a re made.
1760 The effectiveness of policies, standards and procedures should be measured to check
1761 whether they serve their intended purpose. The cost to the organization should also be
1762 measured, so the organization can determine whether the balance of risk redu ction aligns with
1763 the cost to implement the policies. If the balance is unacceptable, the policy and procedures
1764 may have to be adjusted. Procedures also have to be updated to reflect changes in
1765 technology.
1766 Procedures are able to support audits. A security audit compares the observed actions of the
1767 organization against the written procedures.
1768 10.7 Topics Covered by Policies and Procedures

1769 There are several topics that policies and procedures can cover. Every organization is
1770 different and should determine the appropriate policies and procedures that are applicable for
1771 its industrial automation and control systems. Possible topics include:
1772 Risk Management Risk management is vital to developing a cost-effective security program
1773 that provides a uniform layer of adequate security, but that does not require equipment or
1774 procedures that are too costly and significantly beyond the range of adequate security.
1775 However, risk management is complex and needs to be tailored to the organization. The
1776 policy on risk management defines how an acceptable level of risk is determined and how to
1777 control the risk. This level varies depending upon the goals and circumstances for a particular
1778 organization. The process for determining risk level should be repeated periodically in order to
1779 accommodate changes to the environment.
1780 Access Management Security is improved in a system by restricting access to only those
1781 users who need and are trusted with the access. Access management policy identifies
1782 different roles of users and what kind of access each role needs to each class of asset
1783 (physical or logical). It specifies the responsibilities of employees to protect the assets and of
1784 administrators to maintain access management procedures. Authorization for these access
1785 privileges should have well-documented approval by management and be periodically
1786 reviewed. Access management may be as important or even more important to system
1787 integrity and availability as the need to protect data confidentiality.
1788 Availability and Continuity Planning Policies in this area provide the necessary framework
1789 and requirements expectations for backup and recovery, as well as business continuity and
1790 disaster recovery planning. They also define archiving characteristics (e.g., how long must
1791 data be retained).
1792 Physical Security The security of the control system depends upon the physical security of
1793 the space that contains the control system. The plant site may already have a physical
1794 security policy before the security policy is written for the control system. H owever, policies
1795 related to systems physical access may differ from those involving non -systems assets. For
1796 instance, all oil refinery personnel may have general access to almost all facilities within the
1797 plant fences, but IT infrastructure rooms may need to have access limited to only IT-related
1798 personnel if for no other reason than to prevent accidental damage. The control system
1799 security policy should include a reference to the physical security policy and state its
1800 dependency. The security policy for the control system must contain enough specifics on
1801 physical security to make any specific application of the site physical security policy to the
1802 control system. For example, some equipment must be in locked cabinets, and the keys must
1803 be kept in a restricted place.
1804 Architecture Policies and procedures describe secure configurations of control systems
1805 including such issues as:
1806 a) recommended network designs

1807 b) recommended firewall configuration
1808 c) user authorization and authentication
1809 d) interconnecting different process control networks
1810 e) use of wireless communications
1811 f) domains and trust relationships
1812 g) patch management (including authentication)
1813 h) anti-virus management
1814 i) system hardening in terms of closing software ports, disabling or avoiding unused or
1815 dangerous services, and disabling the use of removable storage devices
1816 j) access to external networks (i.e., the internet)
1817 k) appropriate use of e-mail.
1818 Portable Devices Portable devices pose all the security risks of stationary equipment, but
1819 their mobility makes it less likely that they will be covered by the normal security procedures
1820 from installation to audit. Their portability provides additional opportunities for corruption while
1821 outside physical security zones or for interception of information while connecting to secure
1822 zones. Thus, a special policy is often needed to cover portable devices. The policy should
1823 require the same security protection as a stationary device, but the technical and
1824 administrative mechanisms that provide this protection may differ.
1825 Wireless Devices and Sensors Control equipment using radio frequency transmission in
1826 place of wires has been widely used in certain control system applications for many years. As
1827 costs decrease and new standards emerge, potential applications in automation and control
1828 systems continue to expand, in part due to lower installation costs. A key difference between
1829 wired and wireless devices is that in the latter case signals are not confined within a physical
1830 security boundary, making them more prone to interception and co rruption. Therefore, a
1831 security policy specific to wireless devices is appropriate for organizations that currently use
1832 or may in the future deploy wireless devices or sensors in their operations. The policy may
1833 specify which applications can use wireless devices, what protection and administrative
1834 methods are required, and how wired and wireless networks are interconnected.
1835 Remote Access Remote access bypasses the local physical security controls of the
1836 boundaries of the system. It extends access to the trusted zone to a completely different
1837 geographic location and includes a computer that may not have undergone the security
1838 checks of the computers that are physically in the area of the trusted zone. Different
1839 mechanisms are required to provide the same level of security as the trusted zone.
1840 Personnel Personnel issues are likely to be defined in the enterprise personnel and IT
1841 security policies. The control system security policy provides specifics, whereas the more
1842 general policies do not include control system aspects. For example, the control system
1843 security policies coordinate control system access roles with personnel screening and
1844 monitoring practices.
1845 Subcontractor Policy Security issues include work that may involve subcontractors in roles
1846 such as supplier, integrator, maintenance service provider, or consultant. A security policy
1847 that covers subcontractors addresses the interactions with the subcontractor that could open
1848 vulnerabilities. The policy identifies the responsibilities of the differen t parties. It addresses
1849 the changing responsibilities as projects progress through their phases and as materials and
1850 systems are delivered. The policy may require certain terms to be written into contracts with
1851 subcontractors.
1852 Without proper management of contract programmers, application integrity may be

1853 compromised or programming code may not be maintainable. It is important to find well -
1854 qualified contract programmers who will follow your programming and documentation
1855 standards and perform adequate testing, as well as being trustworthy and timely.
1856 Auditing The security of the system is audited regularly to measure the degree of
1857 compliance with the security policies and practices. The security policy addresses the need
1858 for audits and specifies the respons ibility, the regularity, and the requirement for corrective
1859 action. A comprehensive auditing process may address aspects other than security, such as
1860 process efficiency and effectiveness, and regulatory compliance.
1861 Security Policy Updating The security policy is monitored to determine changes needed in
1862 the policies themselves. Monitoring security policy is a part of each policy and procedure
1863 document, and the enterprise security policy sets forth the overall approach. Each operational
1864 policy and procedure document contains a statement of when and by whom the policy or
1865 procedure itself is to be reviewed and updated.
1866 Training Training programs should be in place for new hires, operations, maintenance,
1867 upgrades and succession planning. Training programs sh ould be well documented, structured,
1868 and updated at regular intervals to incorporate changes in the operating environment.
1869 10.8 Key Management

1870 10.8.1 Introduction
1871 Understanding key management first requires an insight into the life cycle for the keys that are
1872 part of a key management schema. Fundamentally, a key is a piece of auxiliary information
1873 that changes the detailed operation of an encryption algorithm. A key should be selected
1874 before using an encryption algorithm to encrypt an IACS message or piece of informati on.
1875 Without knowledge of the key, it should be difficult, if not impossible, to decrypt the resulting
1876 ciphertext into human or machine readable plaintext.
1877 A life cycle may begin with a cryptoperiod for the keys which describes the life stages (key
1878 states) from creation to revocation and disposal. IACS operations run 24/7 which depends on
1879 continuous availability of critical communication resources. For this reason, special attention
1880 needs to be given to the requirements for timely disposition of keys describ ed by the system
1881 triggers shown in Figure 9.
1882
1883 This document may not be copied, distributed to others, or offered for further reproduction or for sale.
1884 Figure 9 Key management life cycle
1885 10.8.2 Generation and distribution of keys

1886 Generation and distribution of keys that maintain the secret value afforded the key is prov ided
1887 in a timely manner to support 24/7 P&C operations. A key management schema or system is
1888 only effective if something (usually the key but could be an encryption algorithm) is secret.
1889 How to maintain the secret across widely geographically dispersed IAC S operational entities
1890 and unknown entities becomes the challenge for a key management design. So, generating a
1891 key for which that key may have a wide breath of use or a very narrow use leads to defining
1892 an effective distribution channel. The channel can b e a physical channel such as a courier or
1893 equivalent, the channel can be an electronic channel such as the Internet which should not be
1894 trusted. The means used to distribute the keys is largely determined by the timeliness
1895 requirements imposed by critical IACS operations that require high security.
1896 Except in simple IACS operations where key components remain fixed for all time,
1897 cryptoperiods are needed for keys, and these keys need to be updated periodically. The time
1898 frame for a key to be used varies. The cryptoperiod of a key is the time period during which
1899 the key is valid for use by legitimate human and non -human entities. Cryptoperiods serve to:
1900 Limit the information (related to a specific key) available for cryptanalysis;
1901 Limit exposure in the case of compromise of a single key;
1902 Limit the use of a particular technology to its estimated effective lifetime; and
1903 Limit the time available for computationally intensive cryptanalytic attacks (in IACS
1904 applications where long-term key protection is not required).
1905 10.8.3 Key State Phases
1906 IACS operation requires secure management of the keying material in all ke y state phases
1907 shown in Figure 9: pre-operational, operational, post-operational, and destruction.
1908 Furthermore, the key management s ystem should provide a secure method to account for how
1909 the keys are maintained. Backup key management and key recovery becomes extremely
1910 important to maintain 24/7 operations when the primary key management system fails or is
1911 disconnected.
1912 11 Fundamental Concepts

1913 There are several fundamental concepts that are essential to the formulation and execution of
1914 an Industrial Automation and Control Systems security program.
1915 k) Security Life Cycle This life cycle is focused on the security level of a portion of the
1916 system over time. A change to a physical asset may trigger a set of security level
1917 activities, or a change in security vulnerabilities or an asset may trigger a change in
1918 the physical asset.
1919 l) Security Program Maturity A mature security program integrates all aspects of cyber
1920 security, incorporating desktop and business computing systems with industrial
1921 automation and control systems. The development of a program shall recognize that
1922 there are steps and milestones in achieving this maturity
1923 m) Zone and Conduits Segmenting or dividing a system under consideration for the
1924 purpose of assigning security levels and associated measures is an essential step in
1925 the development of the program.
1926 n) Security Levels Assets that make up the system under consideration shall be
1927 assigned desired security levels using the mechanism defined in ISA62443-3-2.
1928 o) Foundational Requirements The full scope of detailed technical and program
1929 requirements shall be derived from a small set of founda tional requirements.
1930 p) Safety and Security In an IACS context the subjects of Security and Safety are
1931 closely linked. A failure to secure an IACS can in turn result in a potentially unsafe
1932 System under Control.
1933 Each of these concepts is introduced in subsequent clauses and addressed in more detail in
1934 one or more standards in the ISA62443 series.
1935 11.1 Security Life Cycle

1937 This section explains the different security aspects in the relevant life cycles of an IACS and
1938 outlines which parts of the ISA62443 series provide guidance for the security aspects of the
1939 respective life cycle. The entities of these relevant life cycles and the respective main
1940 responsible role are shown in table 2.
1941 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
1942 For each entity and the associated life cycle, the security aspects are defined and
1943 implemented in a security process model, often referred to as the Plan -Do-Check-Act (PDCA)
1944 cycle. For each of these PDCA cycles, a different role is mainly responsible to ensure that all
1945 the cyber security aspects are properly addressed. These PDCA cycles are shown in Error!
1946 Reference source not found..
1947
1948 Figure 10 Security aspects in relevant life cycles
1949 As also shown in Error! Reference source not found., there are a number of
1950 interdependencies between these PDCA cycles. While Error! Reference source not found.
1951 shows a role centric view on the security aspects in IACS environments, Error! Reference
1952 source not found. shows a life cycle centric view.
1953 The product life cycle must address the security aspects of the product. Product development
1954 is usually done independent of any specific project instead products are developed for a
1955 perceived market. Therefore the product PDCA cycle is fairly decoupled from the others.
1956 However, past and current project requirements and feedback from the installed base are a
1957 source for market requirements. After a product is released into the market, it needs to be
1958 maintained. At the same time, the product PDCA cycle needs to continuously support projects
1959 and the installed base throughout the life cycle of the product with product security
1960 documentation and operational guidelines. Eventually the product will be taken off the mar ket.
1961 The IACS life cycle addresses the security aspects of the project in which an automation
1962 solution is designed and commissioned as well as the continuous operation and maintenance
1963 of the solution and its eventual decommissioning. Integration projects a re dependent on
1964 information from the various product suppliers feeding into the project and in return provide
1965 requirements and feedback for consideration in future updates and new products. At the same
1966 time, based on the project requirements and in particu lar the security targets specified by the
1967 asset owner, the design of the automation solution done in the integration project largely
1968 determines how the IACS will be operated. Therefore the integration projects PDCA cycle
1969 must supply appropriate information in particular the solution security documentation to the
1970 operations PDCA cycle.
1971 Asset owners operations teams provide requirements both to integration projects as well as
1972 to product suppliers. In return they depend on initial documentation and continuo us support
1973 throughout the solutions lifecycle. Hence it is obvious that the life cycle of the integration
1974 project and the operations are tightly intertwined. In fact, usually the integration project
1975 activity is not started unless the eventual asset owner issued a request for bids.
1976
1977 Figure 11 Interdependencies in product and IACS lifecycles
1978 The following subsections provide more detail on the PDCA cycles shown in Error! Reference
1979 source not found. and the corresponding security aspects and explain how the different parts
1980 of the ISA62443 series correlate to them.
1981 11.1.2 Product life cycle

1982 Although some products are specifically developed for a given project, in general the aim of
1983 the product supplier is to offer components and systems with a reasonable level of confidence
1984 that they are free from vulnerabilities and meet the required security requirements of their
1985 intended target markets. It is recommended to conduct several PDCA cycles during the
1986 product development cycle. The first cycle should take place in the specification phase and
1987 should be focused on the expected threats coming from the operating environment of the
1988 product. In the design phase PDCA cycles should be applied to product architecture and data
1989 flow aspects. During commercialization and maintenance the product supplier has to take care
1990 of vulnerability handling and to issue security patches and updates as necessary. Finally in
1991 the phase out early announcement of the termination of support and security updates is
1992 important. Beside the security relevant technical documentation the product suppl ier should
1993 also document the security recommendations for integration and operation of the product as
1994 well as the description of the continuous support during the whole life cycle.
1995 On one side the product suppliers organization should establish a product development
1996 process ensuring that all measures to avoid the creation of vulnerabilities are addressed. In
1997 ISA62443-4-1 the product supplier will find process requirements which help him to
1998 systematically address the security issues from specification phase throughout design,
1999 implementation, verification and validation and release until phase out. The purpose of this
2000 part is to improve the quality of product development process and to include security specific
2001 measures in the organizational as well in the techn ical area. On the other side ISA62443-3-3
2002 and ISA62443-4-2 specify security capabilities which should be fulfilled by th e control system
2003 or components of the control system to support a defense in depth strategy when deploying
2004 an automation solution. A product supplier may choose to integrate a given set of
2005 functionalities depending on the security level expected in the tar get industries of the product.
2006 To achieve the required security level of the automation solution additional compensating
2007 countermeasures may be necessary.
2008 In addition product suppliers should consider ISATR62443-2-3 for the patch management
2009 process. ISATR62443-3-1 provides assessments of current cyber security tools, mitigation
2010 counter-measures, and technologies that may be applied to products and solutions.
2011 11.1.3 IACS Life Cycle
2012 11.1.3.1 Specification Phase
2013 Usually the functional and design specification is a first phase of a new project. In some cases
2014 the specification uses some material from previous projects that might be applicable or
2015 reusable, e.g. a set of user needs. Based on t hat, the asset owner then begins work on
2016 identifying the relevant security targets and the corresponding risks. This part is also known
2017 as a high level risk assessment. Hence the risk identification as part of the overall system
2018 specification takes into account lessons learned, existing checklists and brainstorming to
2019 identify known or new risks. Furthermore it includes also the determination of the currently
2020 assumed likelihood of risk occurring and impact.
2021 The asset owner describes the security related req uirements for the construction and
2022 operation of the plant (target security level, SLT) in the form of the tender requirements
2023 specification of the potential integrators The asset owner also describes which strategic or
2024 company internal requirements have to be considered (e.g., security policies, physical
2025 constrains) during the overall project. System integrators responding to the tender create the
2026 functional specifications of the automation solution as part of their offer based on the tender
2027 specification and mainly the external technical documentation of all the eligible solutions/
2028 components from one or more product suppliers. The asset owner has to check this functional
2029 specification to ensure, that all requirements will be addressed by the automation so lution. If
2030 the functional specification is accepted by the asset owner, a contract will be negotiated and
2031 the collaborative project will be started.
2032 ISA62443-2-1 defines the requirements for an industrial automat ion and control system
2033 (IACS) security management system (IACS-SMS) and provides guidance on how to develop it.
2034 Specifically for the patch management aspect of an IACS-SMS, ISATR62443-2-3 provides
2035 detailed guidance. Finally, ISA62443-3-2 establishes requirements for defining the zones and
2036 conduits of the system under consideration, assessing risk, establishing a target security level
2037 (SL-T), providing informal guidance on how to verify these requirements.
2038 11.1.3.2 Integration and Commissioning Phase

2039 The integration and commissioning phase is an iterative process of the system integrator,
2040 mainly used for designing and implementing the appropriate secure automation solution
2041 requested by the asset owner (and its security targets). The solution of the system integrator
2042 is characterized by:
2043 using the zone and conduit model to design a secure automation infrastructure,
2044 selecting and integrating products from the product supplier( s) according their security
2045 capabilities (taking into account the product security documentation/ guidelines/
2046 support),
2047 configuration and parameterization of all products (not limited to products with
2048 dedicated security capabilities),
2049 providing evidence during the commissioning, and in the final application of the asset
2050 owner, that the final integrated solution fulfils all requirements appropriately,
2051 supporting the final integrated solution along the asset owners life cycle (operation,
2052 maintenance, decommissioning),
2053 In the end of the integration and commissioning phase the system integrator must ensure that
2054 all the measures implemented for the achieved Security Level (SL -A) are efficient, suitable
2055 and match the target Security Level (SL-T).
2056 As part of the result of the project the system integrator should provide the asset owner with
2057 external technical documentation and support such that the asset owner will then:
2058 be able to operate, maintain and decommission the automation solution securely within
2059 its specification,
2060 be able to find all IT security-relevant information necessary for future changes of the
2061 solution,
2062 be able to regularly check the implemented countermeasures for their effectiveness,
2063 and
2064 be able to adapt the implemented countermeasures when the threat situation changes
2065 Furthermore the documentation should also provide information concerning the operating and
2066 maintenance of the overall automation solution which is also a basis for the training the asset
2067 owners personnel.
2068 ISA62443-2-4 specifies capabilities for IACS Solution Suppliers, especially system
2069 integration service providers. ISA62443-3-2 provides requirements how to determine the
2070 achieved security level (SL-A) of the overall solution and to validate that it matches the
2071 previously defined security target level (SL-T). ISA62443-1-3 defines system cyber security
2072 conformance metrics for an industrial automation and control system (IACS). Finally,
2073 ISATR62443-3-1 provides an overview of security technologies and their appropriate use in
2074 IACS environments.
2075 11.1.3.3 Operations & Maintenance Phase

2076 It is one of his major responsibilities of the owner or operator of an IACS to ensure during the
2077 operation and maintenance phase the security capabilities of the IACS will be kept on the
2078 achieved and approved security levels in all of its zones and conduits. He has to keep the risk
2079 of security breaches and associated consequences at an acceptable level.
2080 In general the security properties of each IACS will change over time due to the following
2081 changes in the primary or initial security milieu. Those changes can be the following:
2082 The confidence in the security capabilities of the ICAS components is reduced due to
2083 discovered vulnerabilities.
2084 The security requirements of the IACS are changed e.g. due to changes of the threat
2085 situation.
2086 Technical, organizational and/or operational changes impa cting the secure operation of
2087 the IACS.
2088 The security properties relevant to the IACS must be audited and/or tested at regular intervals
2089 or whenever a new vulnerability is discovered to ensure that SL(Achieved) matches
2090 SL(Target). The product supplier and the system integrator have to inform the asset owner or
2091 operator whenever they have discovered any change in the security capabilities of their
2092 products or systems leading to a degradation of their associated security capabilities.
2093 The central document in the standardization series ISA62443 describing the process of
2094 operating and maintaining the achieved security ca pabilities is the part ISA62443-2-1:
2095 Industrial automation and control system security management system. That document
2096 describes among other topics also the maintenance and improvement steps of a cyber
2097 security management system (CSMS) following the outline of the ISO standard 27001 and
2098 27002. The asset owner should continuously monitor, review and audit the selected security
2099 controls and measures and their effectiveness. It should implement decided upon
2100 improvements and adjustments and communicate those actions to all involved parties.
2101 Further attention should be given the technical report on patch management (ISATR62443-2-
2102 3), one of the important tasks to keep the level of security (SL achieved) of implemented SW
2103 applications to its originally implemented level. The asset owner should specifically monitor
2104 and assess maintenance providers development in respect to the defined maturity levels
2105 during his involvement with the IACS (see ISA62443-2-4), possibly involving IACS service
2106 providers. Re-assessing previous risk assessments can have an impact on the design of the
2107 security zones and conduits (ISA62443-3-2) and the choice of mitigation measures to meet
2108 the selected technical or organizational setup of an IACS the system (ISA62443-3-3).
2109 11.1.3.4 Decommissioning Phase

2110 When decommissioning an automation solution or parts thereof, there is a risk of
2111 compromising the security of the surrounding enviro nment (e.g. the asset owners
2112 organization) or the remaining automation solution. Decommissioning may range from
2113 discontinuing the entire automation solution (with or without replacement) to removal of
2114 individual assets (with or without replacement). The r isk of security compromise stems from
2115 the potential disclosure of data or information which may be left on the assets in a format that
2116 may be useful for an attacker (e.g. encryption keys, authentication credentials, architecture
2117 information). It is the responsibility of the asset owner to ensure to an appropriate level that
2118 such information is removed or otherwise rendered useless during the decommissioning. To
2119 live up to this responsibility, the asset owner depends on documentation from the system
2120 integrator and the product suppliers on where such information may be located and how to
2121 properly remove it or render it unusable otherwise. ISA62443-2-1 has requirements and
2122 guidance on security aspects of decommissioning such as disposal or reuse of information,
2123 media as well as equipment.
2124 11.2 Maturity Levels

2125 Driven by increasing cyber security risks, many organizations have taken a proactive
2126 approach towards addressing the security risks of their information technology sys tems and
2127 networks. They are beginning to realize that addressing cyber security is a continuous activity
2128 or process and not a project with an identified start and stop.
2129 Historically organizations providing and supporting business information systems and
2130 industrial automation and control systems operated in two mutually exclusive areas. The
2131 expertise and requirements of each organization were not understood or appreciated by the
2132 other. Issues arose as organizations tried to employ common IT security practice s to industrial
2133 automation and control systems.
2134 In some cases, the security practices were in opposition to normal production practices
2135 designed to maximize safety and continuity of production. Because todays open information
2136 technologies are used extensively in industrial automation and control systems, additional
2137 knowledge is required to safely employ these technologies. The IT and manufacturing or
2138 production organizations should work together and bring their knowledge and skills together to
2139 tackle security issues. In industries with a high potential for health, safety, and environmental
2140 incidents, it is important to involve Process Safety Management (PSM) and physical security
2141 personnel as well.
2142 The goal is a mature security program that integrates all aspects of cyber security,
2143 incorporating desktop and business computing systems with industrial automation and control
2144 systems. Many organizations have fairly detailed and complete cyber security programs for
2145 their business computer systems, but cyber sec urity management practices are not as fully
2146 developed for IACS.
2147 A common mistake is to address cyber security as a project with a start and end date. When
2148 this occurs, the security level often declines over time. Cyber security risks constantly change
2149 as new threats and vulnerabilities surface along with ever -changing technology
2150 implementations. A different approach is needed to sustain the security gains and hold risk to
2151 an acceptable level.
2152 The recommendation is to develop and implement an organization -wide cyber security
2153 management system (CSMS) that includes provisions to reassess risk and take corrective
2154 actions to eliminate the tendency for security levels to decline over time. An in -depth
2155 description of the key components of a cyber security managemen t system is provided in the
2156 second standard in this series. [1]
2157 Every organizations journey to implement a cyber security management system will be
2158 different based on the organizations objectives and tolerance for risk. Integrating cyber
2159 security into an organizations standard practices is a cultural change that takes time and
2160 resources. As the figures suggest, it cannot be achieved in one step. It is an evolutionary
2161 process that standardizes on the approach to cyber security. The security practices to b e
2162 implemented must be proportionate to the risk level and will vary from one organization to
2163 another, and may even be different for various operations within the same organization based
2164 on global needs and requirements. Individual policies and procedures m ay also be different
2165 for each class of system within an organization because the level of risk and security
2166 requirements may be different. A cyber security management system establishes the overall
2167 program that accommodates these differences.
2168 Education and awareness are critical for successfully addressing IACS cyber security risks as
2169 noted above. There are several options to consider:
2170 a) Training the IACS personnel to understand the current information technology and
2171 cyber security issues.
2172 b) Training IT personnel to understand IACS technologies, along with the Process Safety
2173 Management processes and methods.
2174 c) Developing practices that join the skill sets of all the organizations to deal with cyber
2175 security collaboratively.
2176 For the cyber security program to be successful, it is necessary to assemble the right mix of
2177 people on both the mitigation projects and the overall CSMS program development.
2178 Contributing groups include:
2179 IT and Telecom support

2180 IT security
2181 Suppliers
2182 Operations and Maintenance
2183 IACS Support
2184 Process Safety
2185 11.2.1 Maturity Phases
2186 It is possible to describe the relative maturity of a cyber security program in terms of a life
2187 cycle that consists of several phases. Each of these phases consists of one or more steps.
2188 Portions of the industrial automation and con trol system, or control zones within a control
2189 system can be at different phases of maturity. There are several reasons for this situation,
2190 including budgetary constraints, vulnerability and threat assessments, schedules placed
2191 against risk analysis results, automation upgrades, plans for dissolution or replacement, plans
2192 to sell a segment of the facility or business, or availability of other resources to upgrade the
2193 security systems to a more mature phase.
2194 Organizations can achieve a more detailed evaluation of security maturity by assessing
2195 achievements within portions of the industrial automation and control system in terms of the
2196 phases and steps shown in the following table.
2197 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
2198 The tables that follow provide general descriptions for each of the phases and steps in the
2199 maturity life cycle.
2200 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
2201 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
2202 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 read y for
acceptance by operations and maintenance personnel
2203 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
2204 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
2205
2206 11.3 Zones and Conduits
2208 Every situation has a different acceptable level of security. For large or complex systems it
2209 may not be practical or necessary to apply the same level of security to all components.
2210 Differences can be addressed by using the co ncept of a security zone, defined as a logical or
2211 physical grouping of physical, informational, and application assets sharing common security
2212 requirements. This concept can be applied in an exclusive manner where some systems are
2213 included in the security zone and all others are outside the zone.
2214 A conduit is a particular type of security zone that groups communications that can be
2215 logically organized into a grouping of information flows within and also external to a zone.
2216 Channels are the specific communication links established within a communication conduit.
2217 11.3.2 Zones

2218 A security zone has a border, which is the boundary between included and excluded
2219 components. The concept of a zone also implies the need to access the assets in a zone from
2220 both within and without. This defines the communication and access required to allow
2221 information and people to move within and between the security zones. Zones may be
2222 considered to be trusted or untrusted.
2223 Security zones can be defined in physical terms (i.e., a physical zone), in logical terms (i.e.,
2224 virtual zone), or in some combination. Physical zones are defined by grouping assets by
2225 physical location. In this type of zone it is easy to determine which assets are within each
2226 zone. Virtual zones are defined by grouping assets, or parts of physical assets, into security
2227 zones based on functionality or other characteristics, rather than the actual location of the
2228 assets.
2229 There can also be zones within zones that provide layered security, giving defense in depth
2230 and addressing multiple levels of security requirements. Defense in depth can also be
2231 accomplished by assigning different properties to security zones.

2233 <Requirement Statement>
2234 11.3.2.2 Rationale

2235 <Rationale>
2236 11.3.3 Conduits

2237 Information must flow into, out of, and within a security zone. Even in a non-networked
2238 system, some communication exists (e.g., intermittent connection of programming devices to
2239 create and maintain the systems). To cover the security aspects of communication and to
2240 provide a construct to encompass the unique requirements of communications, this standard
2241 is defining a special type of security zone: a communications conduit.
2242 A conduit can be a single service (i.e., a single Ethernet network) or can be made up of
2243 multiple data carriers (multiple network cables and direct physical accesses). As with zones, it
2244 can be made of both physical and logical constructs. Conduits may connect entities within a
2245 zone or may connect different zones.
2246 As with zones, conduits may be either trusted or untrusted. Conduits tha t do not cross zone
2247 boundaries are typically trusted by the communicating processes within the zone. Trusted
2248 conduits crossing zone boundaries must use an end-to-end secure process.
2249 Untrusted conduits are those that are not at the same level of security as the zone endpoint.
2250 In this case the security of the communication becomes the responsibility of the individual
2251 channel. Further information on this scenario is available in the Annex.

2254 11.3.3.2 Rationale
2255 <Rationale>
2256 11.3.4 Channels

2257 Channels inherit the security properties of the conduit used as the communication media (i.e.,
2258 a channel within a secured conduit will maintain the security level of the secured conduit).
2259 Channels may be trusted or untrusted.
2260 Trusted channels are communication links that allow secure communication with other
2261 security zones. A trusted channel can be used to extend a virtual security zone to include
2262 entities outside the physical security zone.
2263 Untrusted channels are communication paths that are not at the same level of security as the
2264 security zone under study. The communications to and from the reference zone (the zone that
2265 defines the communication as non-secure) must be validated before accepting the
2266 information.
2267 11.3.5 Determining Requirements

2268 When organizing a system into zones and conduits an organization must first assess the
2269 security requirements (security goals) and then determine the positioning of asset within the
2270 zone structure. The security requirements can be broken down into the following types:
2271 Communications Access For a group of assets within a security border to provide value,
2272 there must be links to assets outside the security zone. This access can be in many forms,
2273 including physical movement of assets (products) and people (employees and v endors) or
2274 electronic communication with entities outside the security zone.
2275 Remote communication is the transfer of information to and from entities that are not in
2276 proximity to each other. For purposes of this document, remote access is defined as
2277 communication with assets that are outside the perimeter of the security zone being
2278 addressed.
2279 Local access is usually considered communication between assets within a single security
2280 zone.
2281 Physical Access and Proximity Physical security zones are used to limit access to a
2282 particular area because all the systems in that area require the same level of trust of their
2283 human operators, maintainers, and developers. This does not preclude having a higher -level
2284 physical security zone embedded within a lower-level physical security zone or a higher-level
2285 communication access zone within a lower-level physical security zone. For physical zones,
2286 locks on doors or other physical means protect against unauthorized access. The boundary is
2287 the wall or cabinet that restricts access. Physical zones should have physical boundaries
2288 commensurate with the level of security desired, and aligned with other asset security plans.
2289 One example of a physical security zone is a typical manufacturing plant. Authorized people
2290 are allowed into the plant by an authorizing agent (security guard or ID), and unauthorized
2291 people are restricted from entering by the same authorizing agent and by fences.
2292 Assets that are within the security border are those that must be protected to a given security
2293 level, or policy. All devices that are within the border must share the same minimum level of
2294 security requirements. In other terms, they must be protected to meet the same security
2295 policy. Protection mechanisms can differ depending on the asset being protect ed.
2296 Assets that are outside the security zone are by definition at a lesser or different security
2297 level. They are not protected to the same security level, and by definition cannot be trusted to
2298 the same security level or policy.

2301 11.3.5.2 Rationale
2302 <Rationale>
2303 11.3.6 Defining Zones

2304 In building a security program, zones are one of the most important tools for program
2305 success, and proper definition of the zones is the most important aspect of the process. When
2306 defining the zones, organizations must be sure to use both the reference architecture and the
2307 asset model to develop the proper security zones and security levels to meet the security
2308 goals established in the industrial automation and control systems security policy.
2309 When different level activities are performed within one physical device, an organization can
2310 either map the physical device to the more stringent security requirements, or create a
2311 separate zone with a separate zone security policy that is a blended policy between the two
2312 zones. A typical example of this occurs in process historian servers. To be effective, the
2313 server needs access to the critical control devices that are the source of the data to be
2314 collected. However, to meet the business need of presenting that data to s upervisors and
2315 process optimization teams, a more liberal access to the device is required than typical
2316 control system security requirements allow.
2317 If multiple applications involving different levels of activities are running on a single physical
2318 device, a logical zone boundary can also be created. In this case, access to a particular
2319 application is restricted to persons having privileges for that level of application. An example
2320 is a single machine running an OPC server and OPC client -based analysis tools. Access to
2321 the OPC server is restricted to persons having higher level privileges while access to
2322 spreadsheets using OPC client plug-in is available to all employees.

2325 11.3.6.2 Rationale

2326 <Rationale>
2327 11.3.7 Zone Identification

2328 Zones can be a grouping of independent assets, a grouping of subzones, or a combination of
2329 both independent assets and assets that are also grouped into subzones contained within the
2330 major zone. Zones have the characteristic of inheritance, which means a child zone ( or
2331 subzone) must meet all the requirements of the parent zone.
2332 11.3.7.1 Zone Characteristics

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

2336 b) Asset Inventory
2337 c) Access Requirements and Controls
2338 d) Threats and Vulnerabilities
2339 e) Consequences of a Security Breach
2340 f) Authorized Technology
2341 g) Change Management Process.
2342 Each of these attributes is described in more detail in the following paragraphs.
2343 11.3.7.1.1 Security Attributes

2344 Each zone has a controlling document that describes the overall security goals and how to
2345 ensure the Target Security Level is met. This includes:
2346 a) the zone scope
2347 b) the zone security level (Target security levels, SL -T)
2348 c) the organizational structure and responsibilities to enforce the security policy
2349 d) the risks associated with the zone
2350 e) the security strategy to meet the required goals
2351 f) the security policies to be enforced
2352 g) the types of activities that are permitted within the zone
2353 h) the types of communication allowed access to the zone
2354 i) documentation of the zone attributes.
2355 All of the above are documented and combined into the zone security policy, which is used to
2356 guide and measure the construction and maintenance of the assets contained within the zone.
2357 11.3.7.1.2 Asset Inventory

2358 To maintain security within a zone, an organization must maintain a list of all of the assets
2359 (physical and logical). This list is used to assess risk and vulnerabilities and to determine and
2360 maintain the appropriate security measures required to meet the goals of the security policy.
2361 Inventory accuracy is a key factor in meeting the security goals set forth in the security policy.
2362 The list must be updated when assets within the zone change, or their electronic connections
2363 change, as well as when new assets are added to the zone to ensure that the security goals
2364 are met.
2365 Physical assets and components are the physical devices contained within the zone. Some
2366 examples include:
2367 a) computer hardware (e.g., workstations, servers, instruments, controls, power supplies,
2368 disk drives, or tape backups)
2369 b) network equipment (e.g., routers, switches, hubs, firewalls, or physical cables)
2370 c) communications links (e.g., buses, links, modems, and other network interfaces,
2371 antennas)
2372 d) access authentication and authorization equipment (e.g., domain controllers, radius
2373 servers, readers, and scanners)
2374 e) development system hardware
2375 f) simulation and training system hardware
2376 g) external system hardware
2377 h) spare parts inventories
2378 i) monitoring and control devices (e.g., sensors, sw itches, and controllers)
2379 j) reference manuals and information.
2380 Logical assets include all the software and data used in the zone. Some examples are:
2381 a) computer system software (e.g., applications, operating systems, communication

2382 interfaces, configuration tables, development tools, analysis tools, and utilities)
2383 b) patches and upgrades for operating systems and application tool sets
2384 c) databases
2385 d) data archives
2386 e) equipment configuration files
2387 f) copies of software and data maintained for backup and recovery purposes
2388 g) design basis documentation (e.g., functional requirements including information and
2389 assets, security classification and levels of protection, physical and software design,
2390 vulnerability assessment, security perimeter, benchmark tests, assembly, and
2391 installation documents)
2392 h) supplier resources (e.g., product updates, patches, service packs, utilities, and
2393 validation tests).
2394 11.3.7.1.3 Access Requirements and Controls
2395 By its nature, a zone implies that access is limited to a small set of all the possible entities
2396 that could have access. A security policy for a zone must then articulate the access required
2397 for the zone to meet its business objectives, and how this access is controlled.
2398
11.3.7.1.4 Threat and Vulnerability Assessment
2399 Threats and corresponding vulnerabilities exist within a giv en zone. Organizations must
2400 identify and evaluate these threats and vulnerabilities to determine their risk of causing the
2401 assets within the zone to fail to meet their business objectives. The process of documenting
2402 the threats and vulnerabilities happens in the threat and vulnerability assessment that is part
2403 of the zone security policy.
2404 Many possible countermeasures exist to reduce the risk of a threat exploiting a given
2405 vulnerability within a zone. The security policy should outline what types of counter measures
2406 are appropriate to meet the Target Security Level for the zone, within the cost versus risk
2407 trade-off.
2408 11.3.7.1.5 Authorized Technology

2409 As industrial automation and control systems evolve to meet changing business needs, the
2410 technology used to implement the changes needs to be controlled. Each of the technologies
2411 used in these systems brings with it a set of vulnerabilities and corresponding risks. To
2412 minimize the risks to a given zone, the zone security policy needs to have a dynamic list of
2413 technologies allowed in the zone, as well as those not allowed.
2414 11.3.7.1.6 Change Management Process

2415 A formal and accurate process is required to maintain the accuracy of a given zones asset
2416 inventory and how changes to the zone security policy are made. A formal process ensures
2417 that changes and additions to the zone do not compromise the security goals. In addition, a
2418 way to adapt to changing security threats and goals is required. Threats and vulnerabilities,
2419 with their associated risks, will change over time.
2420 11.3.8 Defining Conduits

2421 Conduits are security zones that apply to specific communications processes. As security
2422 zones they are a logical and/or physical grouping of assets (communication assets in this
2423 case). A security conduit protects the security of the channels that it conta ins in the same way
2424 that the physical conduit protects cables from physical damage. Conduits can be thought of as
2425 pipes that connect zones or that are used for communication within a zone. Internal (within
2426 the zone) and external (outside the zone) conduits enclose or protect the communications
2427 channels (conceptually cables) that provide the links between assets. Most often in an IACS
2428 environment the conduit is the same as the network. That is, the conduit is the wiring, routers,
2429 switches, and network management devices that make up the communications under study.
2430 Conduits can be groupings of dissimilar networking technologies, as well as the
2431 communications channels that can occur within a single computer. Conduits are used to
2432 analyze the communication threats and vulnerabilities that can exist in the communications
2433 within and between zones.
2434 Conduits can be considered pipes that contain data and/or provide physical connections for
2435 communication between zones. A conduit can have subconduits to provide a one -to-one or
2436 one-to-many zone communication. Providing secure communication for the conduit can be
2437 accomplished by implementing the appropriate zone security policy.
2438 11.3.8.1 Conduits Characteristics

2439 Physically a conduit can be a cable that connects zones for comm unication purposes.
2440 A conduit is a type of zone that cannot have subzones; that is, a conduit is not made up of
2441 subconduits. Conduits are defined by the list of all zones that share the given communication
2442 channels. Both physical devices and applications that use the channels contained in a conduit
2443 define the conduit end points.
2444 Like a zone, each conduit has a set of characteristics and security requirements that are its
2445 attributes. These take the form of:
2446 a) Security attributes
2447 b) Asset Inventory
2448 c) Access Requirements and Controls
2449 d) Threats and Vulnerabilities
2450 e) Consequences of a Security Breach
2451 f) Authorized Technologies
2452 g) Change Management Process
2453 h) Connected Zones.
2454 11.3.8.1.1 Security Attributes
2455 Each conduit has a controlling document that describes the overall security goals and ho w to
2456 ensure the Target Security Level is met. This document includes:
2457 a) the conduit scope

2458 b) the conduit security level (SL-T)
2459 c) the organizational structure and responsibilities to enforce the conduit security policy
2460 d) the risks associated with the conduit
2461 e) the security strategy to meet the required goals
2462 f) the security policies to be enforced
2463 g) the types of channels that are permitted within the conduit
2464 h) documentation of the conduit attributes.
2465 All of the above are documented and combined into the conduit security po licy, which is used
2466 to guide and measure the construction and maintenance of the assets contained within the
2467 conduit.
2468 11.3.8.1.2 Asset Inventory

2469 As with the zone inventory, an accurate list of the communications assets is required.
2470 11.3.8.1.3 Access Requirements and Controls

2471 By its nature, a conduit implies that access is restricted to a limited set of all the possible
2472 entities that could have access. A security policy for a conduit must then articulate the access
2473 required for the conduit to meet its business objectives, and how this access is controlled.
2474 11.3.8.1.4 Threat and Vulnerability Assessment

2475 Threats and corresponding vulnerabilities exist for a given conduit. Organizations must
2476 identify and evaluate these threats and vulnerabilities to determine their risk of causing the
2477 assets within the conduit to fail to meet their business objectives. The process of documenting
2478 the threats and vulnerabilities happens in the threat and vulnerability assessment that is part
2479 of the conduit security policy.
2480 Many possible countermeasures exist to reduce the risk of a threat exploiting a given
2481 vulnerability within a conduit. The security policy should outline what types of
2482 countermeasures are appropriate within the cost versus risk trade -off.
2483 11.3.8.1.5 Authorized Technology

2484 As industrial automation and control systems evolve to meet changing business needs, the
2485 technology used to implement the changes needs to be controlled. Each of the technologies
2486 used in these systems brings with it a set of vulnerabilities and corresponding risks. To
2487 minimize the risks to a given conduit, the conduit security policy needs to have a dynamic list
2488 of technologies allowed in the conduit.
2489 11.3.8.1.6 Change Management of Process
2490 A formal and accurate process is required to maintain the accuracy of a given conduits policy
2491 and how changes are made. A formal process ensures that changes and additions to the
2492 conduit do not compromise the security goals. In addition, a way to adapt to changing security
2493 threats and goals is required. Threats and vulnerabilities, with their associated risks, will
2494 change over time.
2495 11.3.8.1.7 Connected Zones
2496 A conduit may also be described in terms of the zones to which it is connected.
2497 11.4 Security Levels

2499 Safety systems have used the concept of safety integrity levels (SIL) for almost two decades.
2500 This allows the safety integrity capability of a component or the safety integrity level of a
2501 deployed system to be represented by a single number that defines a protection factor
2502 required to ensure the health and safety of people or the environment based on the probabil ity
2503 of failure of that component or system. The process to determine the required protection
2504 factor for a safety system, while complex, is manageable since the probability of a component
2505 or system failure due to random hardware failures can be measured in quantitative terms. The
2506 overall risk can be calculated based on the consequences that those failures could potentially
2507 have on Health, Safety and Environmental (HSE).
2508 Security systems have much broader application, a much broader set of consequences and a
2509 much broader set of possible circumstances leading up to a possible event. Security systems
2510 are still meant to protect HSE, but they are also meant to protect the industrial process itself,
2511 company-proprietary information, public confidence and national se curity among other things
2512 in situations where random hardware failures may not be or are not (refer to preceding
2513 comments and to 5.2 the root cause. In some cases, it may be a well -meaning employee
2514 that makes a mistake, and in other cases it may be a devious attacker bent on causing an
2515 event and hiding the evidence. The increased complexity of security systems makes
2516 compressing the protection factor down to a single number much more difficult.
2517 11.4.2 Definition

2518 Security levels provide a qualitative approach to addressing security for a zone. As a
2519 qualitative method, security level definition has applicability for comparing and managing the
2520 security of zones within an organization. As more data becomes available and the
2521 mathematical representations of risk, threats, and security incidents are developed, this
2522 concept will move to a quantitative approach for selection and verification of Security Levels
2523 (SL). It will have applicability to both end user companies, and vendors of IACS and security
2524 products. It will be used to select IACS devices and countermeasures to be used within a
2525 zone and to identify and compare security of zones in different organizations across industry
2526 segments.
2527 In the first phase of development, the ISA62443 series of standards tends to use qualitative
2528 Security Levels, using terms such as low, medium, and high. The asset owner will be
2529 required to come up with their own definition of what those classifications mean for their
2530 particular application. The long-term goal is to move as many of the security levels and
2531 requirements to quantitative descriptions, requirements and metrics as possible to establish
2532 repeatable applications of the standard across multiple companies and industries. Achieving
2533 this goal will take time, since more experience in applying the standards and data on industrial
2534 security systems will need to be acquired to justify the quantitative approach.
2535 When mapping requirements to the different Security Levels, standard developers need some
2536 frame of reference describing what the different Security Levels mean and how they differ
2537 from each other. The goal is to propose such a frame of reference.
2538 11.4.3 Types of Security Levels

2539 Security Levels have been broken down into three different types : target, achieved and
2540 capability. These types, while they all are related have to do with different aspects of the
2541 security life cycle.
2542 Target Security Levels (SL-T) are the desired level of security for a particular system.
2543 This is usually determined by performing a risk assessment on a system and
2544 determining that it needs a particular level of security to ensure its correct operation.
2545 Achieved Security Levels (SL-A) are the actual level of security for a particular system.
2546 These are measured after a system design is available or when a system is in place.
2547 They are used to establish that a security system is meeting the goals that were
2548 originally set out in the target Security Levels.
2549 Capability Security Levels (SL-C) are the security levels that component or systems
2550 can provide when properly configured. These levels state that a particular component
2551 or system or component is capable of meeting the target Security Levels natively
2552 without additional compensating controls when properly configured and integrat ed.
2553 Each of these Security Levels is intended to be used in different phases of the security life
2554 cycle according the ISA62443 series of standards. Starting with a target for a particular
2555 system, an organization would need to build a design that included the capabilities to achieve
2556 the desired result. In other words, the design team would first develop the target Security
2557 Level necessary for a particular system. They would then design the system to meet those
2558 targets, usually in an iterative process where after each iteration the achieved Security Levels
2559 of the proposed design are measured and compared to the target Security Levels. As part of
2560 that design process, the designers would select systems and components with the necessary
2561 capability Security Levels to meet the target Security Level requirements or where such
2562 systems and components are not available, complement the available ones with compensating
2563 security controls. After the system went into operation, the actual Security Level would be
2564 measured as the achieved Security Level and compared to the target SAL.
2565 11.4.4 Using Security Levels

2566 When designing a new system (green field) or revising the security of an existing system
2567 (brown field), the first step is to break the system into different zones and define conduits
2568 connecting these zones where necessary. Details on how to accomplish this are given in
2569 ISA62443-3-2. Once a zone model of the system is established each zone and conduit is
2570 assigned a target SAL, based on a risk analysis, which describes the desired security for the
2571 respective zone or conduit. During this initial zone and conduit analysis, it is not necessary to
2572 have completed a detailed system design. It is sufficient to describe the functionality that
2573 should be provided by assets in a zone and the connections between zones in order to meet
2574 the security objectives.
2575 Figure 12 and Figure 13 show high-level examples of systems broken down into zones
2576 connected by conduits. Figure 12 is a graphical representation of a control system for a
2577 chlorine truck loading station. The full use-case that accompanies this figure will be disc ussed
2578 in ISA-TR62443-1-4. It has five zones shown: the basic process control system (BPCS), the
2579 SIS, the control center, the plant DMZ, and the enterprise. The BPCS and the SIS both use
2580 PLCs to operate different aspects of the loading station with the SIS using a special functional
2581 safety PLC (FS-PLC) rated for use in safety systems. The two PLCs are connected via a non -
2582 routable serial or Ethernet connection using a boundary protection device. Each of the PLCs
2583 is connected to a local switch with an engineering workstation for programming and HMI for
2584 operating. The BPCS and SIS zones also contain an instrument asset management system
2585 (IAMS) to measure and test the instruments. A control center containing multiple wor kstations
2586 and the BPCS are both connected to the plant DMZ. A plant DMZ can house a variety of
2587 components and systems, for example a data historian and a maintenance workstation as
2588 shown in the figure. The plant DMZ is shown connected to the enterprise sys tems, which
2589 contain the corporate wireless local area network (WLAN) and web server. Multiple domain
2590 controllers and boundary protection devices are shown in the figure to indicate some of the
2591 countermeasures that may be applied to improve security.
2592
2593 Figure 12 High-level process-industry example showing zones and conduits
2594 Figure 13 is a graphical representation of a manufacturing plant. It has four zones defined: the
2595 enterprise network, the industrial/enterpr ise DMZ, and two industrial networks. The enterprise
2596 infrastructure has a wireless local area network (WLAN) and a connection to the Internet.
2597 Many companies use a DMZ between important parts of their systems to isolate the network
2598 traffic. In this particular example, each industrial network operates relatively independent of
2599 each other with its own PLC, field devices, and HMI.
2600
2601 Figure 13 High-level manufacturing example showing zones and conduits
2602 After determining the target Security Levels, the system can be designed (green field) or
2603 redesigned (brown field) to try to meet those target Security Levels. The design process is
2604 usually an iterative approach where the system design is checked against the target multiple
2605 times throughout the process. Multiple parts of the ISA62443 series of standards contain
2606 guidance on different aspects of the programmatic and technical requirements that go into the
2607 design process. ISA62443-2-1 provides guidance on the programmatic aspects of the design
2608 process while ISA62443-3-3 and ISA62443-4-2 define system-level and component-level
2609 technical security requirements and relate them to different capability Security Levels.
2610 During the design process for a system, it is necessary to evaluate the security capabilities of
2611 different components and subsystems. Product suppliers will have to pro vide these as
2612 capability Security Levels for their components or systems by comparing product features and
2613 capabilities with the requirements defined in the ISA62443 series for the different capability
2614 Security Levels. These capability Security Levels can be used to determine whether a given
2615 component or system is capable of meeting the target Security Level for the system. The
2616 product supplier or system integrator will also have to provide guidance on how to con figure
2617 the component or subsystem to meet the claimed Security Levels.
2618 It is likely that in a particular design there will be some components or systems that cannot
2619 fully meet the target SAL. Where the capability Security Level of a component or system is
2620 lower than the target SAL, compensating controls need to be considered to meet the desired
2621 target SAL. Compensating controls may include changing the design of the component or
2622 system to increase its capabilities, choosing another component or system to me et the target
2623 Security Level or adding additional components or systems to meet the target SAL. After each
2624 iteration in the design process, the system designs achieved Security Levels should be
2625 reevaluated to see how they compare to the target Security Le vels for the system.
2626 Once the system design is approved and implemented, the system needs to be evaluated to
2627 prevent or mitigate deterioration of the systems security level. It should be evaluated during
2628 or after system modifications and on a regular sche dule. ISA62443-2-1 and ISA62443-2-2
2629 provide guidance on the steps necessary to operate the security program and how to evaluate
2630 its effectiveness. After the achieved Security Levels have been determined, it will be
2631 necessary to evaluate whether the system is still meeting the original target Security Levels
2632 (for example, using the system requirements from ISA62443-3-3). If the system is not
2633 meeting those requirements, there may be multiple reasons including the lack of maintenance
2634 of the program or the need to redesign parts of the system.
2635 In essence, the control system security capabilities are determined independent from a giv en
2636 use context, but are used in a given context in order to achieve the target SL of the respective
2637 system architecture, zones and/or conduits (see Figure refernce).
2638
2640 11.4.5 Security Level Vector

2641
2642 11.4.6 Foundational Requirements

2643 Security Levels are based on the seven Foundational Requirements for security, as defined
2644 on page Error! Bookmark not defined..
2645 1) Identification and authentication control (IAC),

2646 2) Use control (UC),
2647 3) System integrity (SI),
2648 4) Data confidentiality (DC),
2649 5) Restricted data flow (RDF),
2650 6) Timely response to events (TRE), and
2651 7) Resource availability (RA).
2652 Instead of compressing Security Levels down to a single number, it is possible to use a vector
2653 of Security Levels that uses the seven FRs above instead of a single protection factor. This
2654 vector of Security Levels allows definable separations between Security Levels for the
2655 different FRs using language.
2656 This language can be based on the additional consequences associated with se curity systems
2657 or different attacks against the security objectives addressed by the FRs. The language used
2658 in the Security Level definitions can contain practical explanations of how one system is more
2659 secure than another without having to relate everythi ng to HSE consequences.
2660 11.4.7 Level Definitions

2661 The ISA62443 series define SLs in terms of five different levels (0, 1, 2, 3 and 4), each with
2662 an increasing level of security. The current model for defining SLs depend s on protecting
2663 against an increasingly more complex threat and differs slightly depending on what type of SL
2664 it is applied to. For SL-C, this means that a particular component or system is capable of
2665 being configured by an asset owner or system integrator to protect against an increasingly
2666 complex type of threat. For SL-T, this means that the asset owner or system integrator has
2667 determined through a risk assessment that they need to protect this particular zone, system or
2668 component against this level of threat. For SL-A, this means that the asset owner, system
2669 integrator, product supplier and/or any combination of these has configured the zone, system
2670 or component to meet the particular security requirements defined for that SL.
2671 The language used for each of the Security Levels uses terms like casual, coincidental,
2672 simple, sophisticated, and extended. This language is intentionally vague to allow the same
2673 basic language to be used for all of the standards in the ISA62443. Each of the individual
2674 standards in the series will define the requirements for the Security Levels that apply to their
2675 particular purpose.
2676 While the requirements for each of the Security Levels will be different throughout the
2677 ISA62443 series, there needs to be a general understanding of what each of the Security
2678 Levels should protect against. The following sections will provide some guidance on how to
2679 differentiate between the Security Levels.
2680 Security Level 0: No specific requirements or security protection necessary

2681 SL 0 has multiple meanings depending on the situation in which it is applied. In defining SL -C
2682 it would mean that the component or system fails to meet some of the SL 1 requirements for
2683 that particular FR. This would most likely be for components or systems that would be part of
2684 a larger zone where other components or systems would provide compensating
2685 countermeasures. In defining SL-T for a particular zone it means that the asset owner has
2686 determined that the results of their risk analysis indicate that less than the full SL 1 specific
2687 requirements are necessary for that particular FR on that component or system. This would
2688 more likely happen for individual components within a system or zon e that do not contribute in
2689 any way to the FR-specific requirements. In defining SL-A it would mean that the particular
2690 zone fails to meet some of the SL 1 requirements for that particular FR
2691 Security Level 1: Protection against casual or coincidental viol ation

2692 Casual or coincidental violations of security are usually through the lax application of security
2693 policies. These can be caused by well-meaning employees just as easily as they can be by an
2694 outsider threat. Many of these violations will be security p rogram related and will be handled
2695 by enforcing policies and procedures.
2696 Using Figure 3, a simple example would be an operator able to change a set point on the
2697 engineering station in the BPCS zone to a value outside certain conditions determined by the
2698 engineering staff. The system did not enforce the proper authentication and use control
2699 restrictions to disallow the change by the operator. Also using Figure 3, another example
2700 would be a password being sent in clear text over the conduit between the BPCS z one and
2701 the DMZ zone, allowing a network engineer to view the password while troubleshooting the
2702 system. The system did not enforce proper data confidentiality and authenticator protection to
2703 protect the password. Using Figure 4, a third example would be a n engineer that means to
2704 access the PLC in Industrial Network #1 but actually accesses the PLC in Industrial Network
2705 #2. The system did not enforce the proper restriction of data flow preventing the engineer
2706 from accessing the wrong system.
2707 Security Level 2: Protection against intentional violation using simple means with low
2708 resources, generic skills and low motivation
2709 Simple means do not require much knowledge on the part of the attacker. The attacker does
2710 not need detailed knowledge of security, the domain or the particular system under attack.
2711 These attack vectors are well known and there may be automated tools for aiding the
2712 attacker. They are also designed to attack a wide range of systems instead of targeting a
2713 specific system, so an attacker does not need a significant level of motivation or resources at
2714 hand.
2715 Using Figure 3, an example would be a virus that infects the maintenance workstation in the
2716 Plant DMZ zone spreading to the BPCS engineering workstation since they both use the same
2717 general purpose operating system. Using Figure 4, another example would be an attacker
2718 compromising a web server in the enterprise network by an exploit downloaded from the
2719 Internet for a publicly known vulnerability in the general purpose operating system of the web
2720 server. The attacker uses the web server as a pivot point in an attack against other systems in
2721 the enterprise network as well as the industrial network. Also using Figure 4, a third example
2722 would be an operator that views a website on the HMI located in I ndustrial Network #1 which
2723 downloads a Trojan that opens a hole in the routers and firewalls to the Internet.
2724 Security Level 3: Protection against intentional violation using sophisticated means with
2725 moderate resources, IACS specific skills and moderate mo tivation
2726 Sophisticated means require advanced security knowledge, advanced domain knowledge,
2727 advanced knowledge of the target system or any combination of these. An attacker going after
2728 a Security Level 3 system will likely be using attack vectors that hav e been customized for the
2729 specific target system. The attacker may use exploits in operating systems that are not well
2730 known, weaknesses in industrial protocols, specific information about a particular target to
2731 violate the security of the system or other means that require a greater motivation as well as
2732 skill and knowledge set than are required for Security Level 1 or 2.
2733 An example of sophisticated means could be password or key cracking tools based on hash
2734 tables. These tools are available for download, but applying them takes knowledge of the
2735 system (such as the hash of a password to crack). Using Figure 3, another example would be
2736 an attacker that gains access to the FS- PLC through the serial conduit after gaining access
2737 to the control PLC through a vulnerability in the Ethernet controller. Using Figure 4, a third
2738 example would be an attacker that gains access to the data historian by using a brute -force
2739 attack through the industrial/enterprise DMZ firewall initiated from the enterprise wireless
2740 network.
2741 Security Level 4: Protection against intentional violation using sophisticated means with
2742 extended resources, IACS specific skills and high motivation
2743 Security Level 3 and Security Level 4 are very similar in that they both involve sophisticated
2744 means used to violate the security requirements of the system. The difference comes from the
2745 attacker being even more motivated and having extended resources at their disposal. These
2746 may involve high-performance computing resources, large numbers of computers or e xtended
2747 periods of time.
2748 An example of sophisticated means with extended resources would be using super computers
2749 or computer clusters to conduct brute-force password cracking using large hash tables.
2750 Another example would be a botnet used to attack a syst em using multiple attack vectors at
2751 once. A third example would be an organized crime organization that has the motivation and
2752 resources to spend weeks attempting to analyze a system and develop custom zero -day
2753 exploits.
2754 11.4.8 Security Level Vector Format

2755 A vector can be used to describe the security requirements for a zone, conduit, component or
2756 system better than a single number. This vector may contain either a specific Security Level
2757 requirement or a zero value for each of the foundational requirements (see 10.3.6).
2758 FORMAT SL-?([FR,]domain) = { AC UC DI DC RDF TRE RA }
2759 Where;
2760 SL-? = (Required) The Security Level type (see 10.3.3). The possible formats are:
2761 SL-T = Target SAL
2762 SL-A = Achieved SAL
2763 SL-C = Capabilities SAL
2764 [FR,] = (Optional) Field indicating the FR that the Security Level value applies. The
2765 FRs are written out in abbreviated form instead of numerical form to aid in readability.
2766 domain = (Required) The applicable domain that the Security Level applies.Domains
2767 can refer to zones, control systems, subsystems or components. Some examples of
2768 different domains from Figure A.1 are SIS zone, BPCS zone, BPCS HMI, Plant DMZ
2769 domain controller, Plant DMZ to Control Center conduit and SIS to BPCS serial
2770 conduit. In this particular standard, all req uirements refer to a control system, so the
2771 domain term is not used as it would be by other documents in the ISA62443.
2772 EXAMPLE 1 SL-T(BPCS Zone) = { 2 2 0 1 3 1 3}
2773 EXAMPLE 2 SL-C(SIS Engineering Workstation) = { 3 3 2 3 0 0 1}
2774 EXAMPLE 3 SL-C(RA, FS- PLC) = 4

2775 NOTE The last example specifies only the RA component of a 7 -dimension SL-C.
2776 11.5 Foundational Requirements
2777 As noted in the discussion of fundamental concepts (see n.n), there are basic or Foundational
2778 Requirements (FRs) that form the basis for subsequent requirements in this standard as well
2779 as other standards in the ISA62443 series. All aspects associated with meeting a desired
2780 IACS security level (people, processes and technology) are derived through meeting the
2781 requirements associated with the following Foundational Requirements:
2782 1) Identification and authentication control (IAC),

2783 2) Use control (UC),
2784 3) System integrity (SI),
2785 4) Data confidentiality (DC),
2786 5) Restricted data flow (RDF),
2787 6) Timely response to events (TRE), and
2788 7) Resource availability (RA).
2789 As an example, the system requirements (SRs) and associated capability security levels (SL -
2790 C) defined in ISA62443-3-3 are organized and numbered by FR. Rather than compressing
2791 security levels down to a single number, a vector is used to express the nuances associated
2792 with an often complex security or protection level. This vector of security levels al lows
2793 definable separations between security levels on a requirement by requirement basis.
2794 11.5.1 FR 1 Identification and authentication control (IAC)

2796 Based on the target security level (SL-T) determined, and using the processes defined in
2797 ISA62443-3-2, the IACS shall provide the necessary capabilities to reliably identify and
2798 authenticate all users (humans, software processes and devices) attempting to access the
2799 ICS.
2800 11.5.1.2 Rationale

2801 Asset owners will have to develop a list of all valid users (humans, software processes and
2802 devices) and to determine for each zone the required level of identification and authentication
2803 control (IAC) protection. The goal is to protect the ICS from unauthenticated access by
2804 verifying the identity of any user requesting access to the ICS before activating the
2805 communication. Recommendations and guidelines should include mechanisms that will
2806 operate in mixed modes. For example, some zones and individual ICS components require
2807 strong IAC, such as strong authentication mechanisms, and others do not.
2808
11.5.2 FR 2 Use control (UC)
2810 Based on the target security level (SL-T) determined using the processes defined in
2811 ISA62443-3-2, the IACS shall provide the necessary capabilities to enforce the assigned
2812 privileges of an authenticated user (human, software process or device) to perform the
2813 requested action on the system or assets and monitor the use of these privileges.
2814
11.5.2.2 Rationale
2815 Once the user is identified and authenticated, the control system has to restrict the allowed
2816 actions to the authorized use of the control system. Asset owners and system integrators will
2817 have to assign to each user (human, software process or device), group, role, etc. the
2818 privileges defining the authorized use of the IACS. The goal of UC is to protect against
2819 unauthorized actions on ICS resources by verifying that the necessary privileges have been
2820 granted before allowing a user to perform the actions. Examples of actions a re reading or
2821 writing data, downloading programs and setting configurations. Recommendations and
2822 guidelines should include mechanisms that will operate in mixed modes. For example, some
2823 ICS resources require strong use control protection, such as restricti ve privileges, and others
2824 do not. By extension, use control requirements need to be extended to data at rest. User
2825 privileges may vary based on time-of-day/date, location and means by which access is made.
2826 11.5.3 FR 3 System integrity (SI)

2829 ISA62443-3-2, the IACS shall provide the necessary capabilities to ensure the integrity of the
2830 IACS to prevent unauthorized manipulation.
2831 11.5.3.2 Rationale

2832 An IACS will often go through multiple testing cycles (unit testing, factory acceptance testing
2833 (FAT), site acceptance testing (SAT), certification, commissioning, etc.) to establish that the
2834 systems will perform as intended before they even begin production. Once operational, asset
2835 owners are responsible for maintaining the integrity of the IACS. Using their risk assessment
2836 methodology, asset owners may assign different levels of integrity protection to different
2837 systems, communication channels and information in their IACS. The integrity of physical
2838 assets should be maintained in both operational and non -operational states, such as during
2839 production, when in storage or during a maintenance shutdown. The integrity of logical assets
2840 should be maintained while in transit and at rest, such as being transmitted over a network or
2841 when residing in a data repository.
2842 11.5.4 FR 4 Data confidentiality (DC)

2845 ISA62443-3-2, the IACS shall provide the necessary capabilities to ensure the confidentiality
2846 of information on communication channels and in data repositories to prevent unauthorized
2847 disclosure.
2848 11.5.4.2 Rationale

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

2855 ISA62443-3-2, the IACS shall provide the necessary capabilities to segment the control
2856 system via zones and conduits to limit the unnecessary flow of data.
2857 11.5.5.2 Rationale
2858 Using their risk assessment methodology, asset owners need to determine necessary
2859 information flow restrictions and thus, by extension, determine the configuration of the
2860 conduits used to deliver this information. Derived prescriptive recommendations and
2861 guidelines should include mechanisms that range from disconnecting control system networks
2862 from business or public networks to using unidirectional gateways, stateful firewalls and
2863 demilitarized zones (DMZs) to manage the flow of information.
2864 11.5.6 FR 6 Timely response to events (TRE)
2867 ISA62443-3-2, the IACS shall provide the necessary capabilities to respond to security
2868 violations by notifying the proper authority, reporting needed evidence of the violation and
2869 taking timely corrective action when incidents are discovered.
2870 11.5.6.2 Rationale

2871 Using their risk assessment methodology, asset owners should establish security policies and
2872 procedures and proper lines of communication and control needed to respond to security
2873 violations. Derived prescriptive recommendations and guidelines should include mechanisms
2874 that collect, report, preserve and automatically correlate the forensic evidence to ensure
2875 timely corrective action. The use of monitoring tools and techniques should not adversely
2876 affect the operational performance of the control system.
2877 11.5.7 FR 7 Resource availability (RA)

2880 ISA62443-3-2, the IACS shall provide the necessary capabilities to ensure the availability of
2881 the control system against the degradation or denial of essential services.
2882 11.5.7.2 Rationale and supplemental guidance

2883 The aim of this FR is to ensure that the control system is resilient against various types of
2884 denial of service events. This includes the partial or total unavailability of system functionality
2885 at various levels. In particular, security incidents in the control system should not affect SIS or
2886 other safety-related functions.
2887 11.6 Safety and Security

2888 Safety Instrumented Systems (SIS), represent one layer of protection that may be
2889 implemented in order to reduce risks associated with Industrial Automation Control Systems.
2890 Traditional risk assessment methodologies in the past, have generally excluded the potential
2891 for cyber related attacks to cause safety related incidents. Given tha t targeted attacks on
2892 Industrial Automation Control Systems have occurred and these systems are increasingly
2893 being connected to other business systems, they represent a significant potential for common
2894 mode failure. As a result, it is necessary in today's world to include cyber security in the
2895 overall Risk Assessment.
2896 Without addressing cyber security throughout the entire safety lifecycle, it is impossible to
2897 adequately understand the relative integrity of the various layers of protection that involve
2898 instrumented systems, including the SIS.
2899 The underlying premise of this standard is that the means to implement, operate, and maintain
2900 system security should not compromise the performance of the safety instrumented systems
2901 (SIS). It should also be understood that achieving higher security levels may result in less
2902 convenience to the end user.
2903 Note- the ISA84 Technical Report would like to use a modified version of the first 2 paragraphs that is specific to
2904 the process industry, but probably not the Rationale section. I also have reservations about including the Rationale
2905 section. We can discuss if the first 2 paragraphs have enough content for the Foundational Clause, or if the
2906 Rationale section should also be included and/or edited down.
2907 Note update Jun 06, 2015. The wording of the first 2 paragraphs has been modified, and a third paragraph has
2908 been added. These changes align with the ISA84 Technical Report, yet maintains a generic approach to safety &
2909 security (in contrast to ISA84's process specific approach ).
2910 11.6.1 Rationale
2911 To take advantage of digital advances, Industrial Control Systems have changed dramatically
2912 in the last two decades. Once isolated and proprietary, ICS today are part of a converged
2913 network that connects plant operations to the administrative environment. The migration from
2914 single-purpose supervisory control and data acquisition (SCADA) systems to industry
2915 standard, network-based systems provided numerous benefits, including increased
2916 information-sharing across the operation, and remote (Internet and wireless) access to
2917 Industrial Control Systems.
2918 But those advances also created security gaps. By connecting to the larger web of networks,
2919 water-control systems are exposed to the myriad threats that lurk in cyber space, including
2920 viruses, worms and trojans. Poor control-system architecture, unfettered user access, and lax
2921 oversight of security policies and procedures have all combined to heighten the risk.
2922 Meanwhile, manuals and training videos on ICS are publicly available, and many hacker tools
2923 can be downloaded or purchased on the Internet. Cyber criminals need little systems
2924 knowledge to infiltrate ICS operations. For all these reasons, the number of control -system
2925 cyber-security incidents has escalated sharply.
2926 According to RISI, almost half of all cyber incidents across all industries were caused by
2927 malware, including viruses, worms and trojans. But unauthorized access or sabotage by
2928 internal sources, such as disgruntled workers or contractors using access privileges to cause
2929 harm, rose considerably at the same time. Network anomalies also triggered failures in
2930 control-system equipment.
2931 The increasing inter-connectivity of control systems is equally important to industry since new
2932 benefits also bring new challenges. Open industrial networks that seamlessly coexist in
2933 broader Ethernet systems are being used to link various plant -wide control systems together
2934 and connect these systems into expansive, enterprise-level systems via the Internet. As the
2935 pace of control system and enterprise network arc hitecture convergence quickens, industrial
2936 security depends on staying both flexible and vigilant and successfully controlling the space.
2937 What may be considered adequate protection today should evolve as vulnerabilities are
2938 identified and new threats emerge.
2939 The discovery of malware that specifically targets industrial control systems brought industrial
2940 security to the forefront in manufacturing. As a result, there is growing recognition of the risks
2941 and real-world threats that are capable of disrupting control system operation and adversely
2942 affecting safety.
2943 12 Compliance Metrics

2944 NOTE: This clause is reserved for a discussion of the role of compliance metrics in the application of the
2945 standards.
2946
2947 Annex A Zones and Conduits Examples

2948 A.1 Introduction
2949
2950 A.2 Untrusted Conduits
2951 Untrusted conduits are those that are not at the same level of security as the zone endpoint.
2952 In this case the security of the communication becomes the responsibility of the individual
2953 channel. This is illustrated in Figure Error! Bookmark not defined..
Enterprise Zone
Laptop computer Workstation Mainframe Server Server
Enterprise Conduit
Plant A Zone Plant B Zone Plant C Zone

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
I/O I/O I/O I/O I/O I/O

2954
2955 Figure 15 Conduit Example
2956 This figure represents a three-plant organization with a separate corporate headquarters. The
2957 three plants are connected to the enterprise network to allow communications to headquarters
2958 and the other plants. Four possible conduits are defined in the drawing (others would also be
2959 defined, but are skipped for brevity). The first is the enterprise conduit, shown at the top of the
2960 figure. It connects multiple plants at different locations to the corporate data center. If the
2961 wide area network (WAN) is constructed using leased or private communications, then it could
2962 be considered a trusted conduit. If it uses both public and private networks, then it may be
2963 classified as untrusted. Included in the conduit is all of the communications equipment and
2964 firewalls that make up the plant links.
2965 Instances of the second conduit class are shown in each plant. Here each of the plants has its
2966 own trusted conduit to allow control communication.
2967 A.3 Multi-Plant Model

2968 A simplified multiplant zone model is shown in Figure Error! Bookmark not defined.. Here the
2969 plant zone are the parents, and each plant control zone is a child contained within the plant
2970 subzone.
2971 NOTE: There is a distinct advantage to aligning security zones with physical areas or zones in a facility for
2972 example, aligning a control center with a control security zone.
Enterprise Zone
Server Server

2973
2974 Figure 16 Multiplant Zone Example
2975 A.4 (Description)

2976 The same enterprise architecture could be grouped into separate zones a s in Figure Error!
2977 Bookmark not defined.. In this model, the zone policies would be independent, and each zone
2978 could have totally different security policies.
Enterprise Zone



2979
2980 Figure 17 Separate Zones Example
2981 A.5 SCADA Applications

2982 Similar models can be constructed for SCADA applications, as shown in Figures Error!
2983 Bookmark not defined. and Error! Bookmark not defined. .
Enterprise Zone
Server Server
Control Center Backup Control Center
Firewall
WAN
App. SCADA SCADA App. SCADA
SCADA
Server Server Server 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
2984
2985 Figure 18 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
2986
2987 Figure 19 SCADA Separate Zones Example
2988 The enterprise conduit is highlighted in Figure Error! Bookmark not defined..
Enterprise Zone



I/O I/O I/O I/O

2989
I/O I/O
2990 Figure 20 Enterprise Conduit

2995
2994
2993
2992
2991
ISA-62443-1-1, D5E4, August 2015
80
example is shown in Figure Error! Bookmark not defined..
Figure 21 SCADA Conduit Example

Just as with zones, a similar view can be constructed for use in SCADA applications. An
ISA99, WG03
2996 Annex B Truck Loading Description

2997 B.1 Introduction
2998 (Excerpt 1)
2999 The example system is a control system for a chemical truck loading facility. The facility is a
3000 self-service loading station where drivers of chemical tanker trucks can drive in, connect a
3001 dispensing arm to the tanker inlet, and initiate the filling of th e truck through a local operator
3002 panel. There is a central control room for the facility where full time operators can also
3003 monitor and control the process. However, the primary role of the operators is to operate the
3004 chemical manufacturing process.
3005 A system architecture diagram is shown below in Figure 3. The architecture selected is mean
3006 to represent a fairly modern design that is typical of what is found in many plants today.
3007 There are some cybersecurity controls in place but there are intention ally several
3008 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
3009
3010 Figure 22 Chemical Truck Loading Control System Architecture Diagram
3011 The first step in the process is to identify the System -under-Consideration (SuC).
3012 Figure 18 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
3013
3014 Figure 23 Chemical Truck Loading System with Definition of SUT Boundary
3015 The organization shall perform a high-level risk assessment of the assets within the SuC (per
3016 ISA99.02.01: 2009 Clause 4.2.3.1-4) to determine financial and health, safety and
3017 environmental (HSE) impact based on function, location, and potential consequences.
3018 Based upon the risk assessment (HAZOP) performed on the chemical truck loading facility,
3019 the worst-case credible scenario is that the system attempts to fill a truck when there is not
3020 one present which would result is a large release of hazardous and flammable material.
3021 Under certain conditions, it is possible for the vapor cloud to ignite and explode. Fire
3022 suppression systems in the facility may be able to prevent the explosion and mitigate the
3023 damage if they react in time. While there are several interlocks in place designed to prevent
3024 this scenario, they are all capable of being bypassed by the control or safety system. A local
3025 operator or truck driver has the ability to initiate an emergency -stop that is hard-wired to
3026 interrupt power to the system. However, there are several scenarios where the local operator
3027 or truck driver fails or is unable to react in time to preven t the worst case consequence.
3028 There are several more scenarios that can result in lower category consequences such as:
3029 A small spill

3030 Theft
3031 Inability to load tanker
3032 Under-filling
3033 Incorrect record keeping (or loss of record)

3034 Using the following tables (Table A.1, A.2) we will perform a cybersecurity risk assessment on
3035 the control system.
3036
3037
3038 Figure 1 shows a diagram of the major components of a chemical truck loading station to
3039 illustrate how the requirements related to the zones and conduits concepts can be used for
3040 doing risk assessments or consequence analyses. This figure also is intended to clarify some
3041 of the terminology used.
3042
3043
3044 Figure 24 Diagram of major components for chemical truck loading example
3045 We start by creating a table of the assets in the control system
Consequence Likelihood
IACS Device Asset Risk Rating
Rating Rating
DCS Eng Workstation B H High
SIS Eng Workstation A M High
Data Historian B M Med

Maintenance
B M Med
Workstation
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
3046
3047
3048
3049 NOTE: The External Network shown in the diagram above represents all networks external to the SuC, so could
3050 be a companys enterprise network, which in turn would be connected to external networks, including the Internet.
3051 The SuC shown here encompasses all parts of the plant that are to be modeled using zones and conduits.
3052 In order to provide clearer descriptions of concepts and boundaries that are significant for
3053 explaining security issues and areas of responsibility, the following hierarchy is proposed.
3054 Significant networks in a company can be arranged with the enterprise network at the highes t
3055 level. This network serves the entire company and includes office automation support and
3056 communications needed for the business side and managed by the Information Technology
3057 (IT) Department. The business side includes financial, procurement, legal, an d administrative
3058 activities. An Office Automation Network (OAN) supports these office automation activities.
3059 The technical operations part of the company includes the industrial automation and control
3060 systems (IACS) support, most of which is managed by an Industrial Automation (IA)
3061 Department or control systems group. The IACS includes the system under consideration
3062 (SuC) and technical support for it. Both the SuC and additional organizational support
3063 (policies, guidelines, operator training activities, etc.) which all combine to make up the IACS
3064 are also connected to the enterprise network through a firewall.
3065 As a practical matter the IACS should include all assets needed to maintain normal plant
3066 operations in stand-alone mode should it be necessary to disconnect the IACS from all
3067 external networks during a sustained cyber attack (a period of time that could last weeks).
3068 The system under consideration (SuC) consists of the control system security zone and
3069 everything contained in it, the router/firewall conduit separating the control system security
3070 zone and plant network security zone, the plant network security zone, and the router/firewall
3071 separating the plant network from the company enterprise network. The SuC in this example
3072 shows a hierarchy of zones contained in zones (zone nesting is allowed) and conduits within
3073 zones.
3074 An initial high level risk assessment identifies the most significant vulnerabilities at the SuC
3075 level affecting the station as a whole such as a large catastrophic release of chlorine gas (a
3076 very bad leak), physical damage from a large explosion or major rupture of a tank, and access
3077 restrictions to support maintaining the physical integrity of the station and its operation.
3078 The control system (PLC) network is isolated from the plant network by a router/firewall, even
3079 though both are part of the SuC, in order to reduce risks associated with a potentially very
3080 hazardous operation (transfer of chlorine gas).
3081 In the example considered here activities supported on the plant network are modeled using
3082 zones and conduits and are included in the consequence assessment (risk analysis) with
3083 associated assignment of security assurance levels (SALs) that must be met. Once the
3084 facility is in operation, management of the plant network activit ies could be done either by the
3085 IT or IA parts of the organization. A major IT objective is usually protection of information
3086 while a major objective for an industrial automation application (control system) is protection
3087 of and availability of the plant (in this example the ability at all times to control operation of
3088 the loading station). A control system often has hazardous energy sources which are not part
3089 of an office automation environment.
3090 It will be important to have IT participation at some level in the zones and conduits modeling
3091 and consequence assessment activities. Roles and responsibilities of plant personnel in both
3092 areas (IT and IA) need to be clearly defined. Network monitoring and management goals may
3093 be different, so need to be defined. Likewise, things like patch management, system testing,
3094 and upgrades to software and operating systems.
3095 Step 3: Identify Zones & Conduits

3101
3100
3099
3098
3097
3096
Name and/or unique identifier

ISA-62443-1-1, D5E4, August 2015
Step 4: Document Security Requirements

86
Figure 25 Zone and Conduit Identification

ISA99, WG03
3102 Logical boundary
3103 Physical boundary, if applicable
3104 List of all access points and associated boundary devices
3105 List of data flows associated with each access point
3106 Connected zones or conduits
3107 List of assets and associated consequences
3108 Security Level Target
3109 Applicable security policies
3110 Assumptions and external dependencies
3111 Table 9 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 Logical Access Points:
boundary devices 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 Process Safety / Process Control Conduit:
Logical Access 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 DCS Servers B (Medium)
consequences
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
3112 Figure 2 and Figure 3 show high-level examples of systems broken down into zones
3113 connected by conduits. Figure 2 is a graphical representation of a control system for a
3114 chlorine truck loading station. It has three security zones defined: the control system, the
3115 safety integrated system (SIS), and the plant network. The control system and SIS both use
3116 programmable logic controllers (PLCs) to operate different aspects of the loading station. The
3117 two PLCs are connected via a non-routable serial Modbus network. Figure 3 is a graphical
3118 representation of a manufacturing plant. It has four zones defined: the enterprise network, the
3119 industrial/enterprise demilitarized zone (DMZ), and two industrial netw orks. The enterprise
3120 infrastructure has a wireless local area network (WLAN) and a connection to the Internet.
3121 Many companies use a DMZ between important parts of their systems to isolate the network
3122 traffic. In this particular example, each industrial net work operates relatively independent of
3123 each other with its own PLC, field devices, and human -machine interface (HMI).
3124
3125 Figure 26 High-level process-industry example showing zones and conduits
3126
3128 After determining the target SALs, the system can be designed (green field) or redesigned
3129 (brown field) to try to meet those target SALs. The design process is usually an iterative
3130 approach where the system design is checked against the target multiple times throughout the
3131 process. Multiple parts of the ISA99 series of standards contain guidance on different aspects
3132 of the programmatic and technical requirements that go into the design process. ISA 99.02.01
3133 [2] provides guidance on the programmatic aspects of the design process while ISA 99.03.03
3134 [5] and the ISA 99.04.## series define system -level and component-level technical security
3135 requirements and relate them to different capability SALs.
3136 During the design process for a system, it is necessary to evaluate the security capabilities of
3137 different components and subsystems. Vendors will have to provide these as capability SALs
3138 for their products by comparing product features and capabilities with the requirements
3139 defined in the ISA99 series for the different capability SALs. These capability SALs can be
3140 used to determine whether a given system or component is capable of meeting the target SAL
3141 for the system. The vendor or system integrator will also have to provide guid ance on how to
3142 configure the component or subsystem to meet the claimed SALs.
3143 It is likely that in a particular design there will be some components or systems that cannot
3144 fully meet the target SAL. Where the capability SAL of a component or system is lowe r than
3145 the target SAL, compensating controls need to be considered to meet the desired target SAL.
3146 Compensating controls may include changing the design of the component or system to
3147 increase its capabilities, choosing another component or system to meet t he target SAL, or
3148 adding additional components or systems to meet the target SAL. After each iteration, the
3149 system design SALs should be reevaluated to see how they compare to the target SALs for
3150 the system.
3151 Once the system design is approved and implement ed, the system needs to be evaluated to
3152 prevent or mitigate deterioration of the systems security level. It should be evaluated during
3153 or after system modifications and on a regular schedule. ISA 99.02.01 and ISA 99.02.02 [3]
3154 provide guidance on the steps necessary to operate the security program and how to evaluate
3155 its effectiveness. After the achieved SALs have been determined, it will be necessary to
3156 evaluate whether the system is still meeting the original target SALs (e.g. using the system
3157 requirements from ISA 99.03.03). If the system is not meeting those requirements, there may
3158 be multiple reasons including the lack of maintenance of the program or the need to redesign
3159 parts of the system.
3160 B.2 Safety and Security

3161 Annex Error! Reference source not found. discusses the truck loading control system. The
3162 specific area of interest from the safety prospective is facilitated by interlocks on the
3163 connections to the truck that assures recirculation of air via two separate hoses. The pumps
3164 cannot be turned ON unless there is a positive confirmation that the hoses are connected. If
3165 a hose is removed, it would automatically shut off the pumps. There is also a high -level
3166 protection switch that assures that if the chemical tank is at a certain level that is automatic
3167 shuts off the pumps. There is also gas detection a truck unloading area and any place along
3168 the injection lines to the equipment that will use the chemical. If there is an alert, it will
3169 automatically shut down the pumps and signal the operator. In some pr ocesses where the
3170 chemical is being injected into a burning process for example, the emissions are monitored.
3171 This would be the case when a hazardous chemical is being used as part of any part of a
3172 process.
3173 The safety system must be tested prior to commissioning of the system by circulation and
3174 injection of water to determine if there are any leaks. Otherwise, the hazardous chemical or
3175 gases could escape and create a unsafe condition for personnel the system should also have
3176 a flush cycle to inject water once again to flush the hazardous chemical out of the lines. This
3177 system must all be tested to assure proper operation. Emissions monitoring is extremely
3178 important in these types of applications where the gases can be released into the air, into the
3179 ground, or nearby bodies of water. This would put the plant at risk for OSHA or MSHA
3180 violation including EPA emissions violation, which all would be punishable by fines. Personal
3181 injury prevention is important so if any action has consequence that would expose p ersonnel
3182 or if release into the air or water it may affect people many miles from the facility. Spill control
3183 is also important safety relevant condition so run off monitor and positioning of eyewash
3184 stations must be monitored and provide alerts to operati ons, which may include key
3185 personnel. Personal training is done for safety conditions including lockout and wearing
3186 proper safety gear but there is no explanation of security concerns other than potential
3187 limitation of use of cell phones and other radios i n a particular area. There is always a need to
3188 have an emergency shutdown and those conditions must be evaluated since immediate
3189 shutdown of a control system must be able to recover form unexpected or an emergency
3190 shutdown.
3191 In some process these alerts may extend to monitor when the take is low since a hazardous
3192 chemical may be an integral part of a production process to reduce NOX emissions for
3193 example. In these situations, the monitoring of a 30 -day average may be important to maintain
3194 EPA compliance. Process operation many need to be changed to assure the long -term
3195 accumulation of release of toxic gases into the air many mean that there will be an even wider
3196 effect related to use of hazardous chemicals, which are needed as part of a productions
3197 process. There may be other instruments including sensors that may exist to detect unsafe
3198 conditions and can provide notification to operator.
3199 The use of hazardous chemicals in a process requires that all aspects of a system must
3200 operate perfectly since they cannot be allowed to operate in a reduced capacity.
3201 Consequently, the system will have interlocks that prevent startup and will force a shutdown if
3202 those permissive are lost or changed. There are other conditions such as power and water
3203 supplies that now become critical which under normal operation they could be operated at a
3204 reduced capability.
3205 The backup power systems should be monitored. Sufficient water and air for pneumatic
3206 devices must be monitored and frequently checked to assure that they are opera ting properly.
3207 There is limited leeway and having an ample supply of power, water, and air are essential for
3208 plant operations especially if used in safety operations. Generally, physical security was the
3209 only consideration and there is no requirement or st andard to provide assurance that
3210 restriction of packets that could adversely affect operations and impact safety of those
3211 systems.
3212 It is important to define the safety aspects to recognize what can be the impact. The security
3213 aspects need to provide protection against intrusion and alteration of operations. This may
3214 include confidentiality if knowledge of those conditions or restriction to access of that system
3215 needs further restriction. The end devices are generally vulnerable since the protection
3216 against cyber infringement due not exists. Consequently, new capabilities are need to isolate
3217 those operations yet providing a means to facilitate a dialog with other devices, user, and
3218 applications that are trusted to view or control operations of security -safety related systems.
3219 Annex C Example: Procedure to apply foundational requirements

3220 C.1 Overview
3221 C.1.1 Description of example system under consideration
3222 Figure C-1 shows a chemical truck loading station, where a Programmable Logic Controller
3223 (PLC) is used to control the loading of liquid chlorine, a hazardous chemical, from a storage
3224 tank to a tank truck. For the purpose of this example, this is the system under consideration
3225 (SuC).
3226
3227 Figure 28 Example application - Chemical truck loading station
3228 Components of the IACS include:
3229 Field instruments such as flow sensors and transmitters, valves, motor control for
3230 pumps.
3231 PLC system including power supplies, CPU, and interface modules for field signals.
3232 Workstations for operation, supervision, maintenance and enginee ring.
3233 Communication infrastructure including switches and firewalls.
3234 C.1.2 Technical Approach
3235 Objective
3236 The objective of this example is show how the foundational requirements are applied to an
3237 example problem - in this case, the chemical loading truck station.
3238 Assumptions
3239 It was assumed that ISA62443-3-3 is applied throughout the life-cycle of the security
3240 architecture. Therefore, the target, design, achieved and measured system security assurance
3241 level needed to be addressed. At each stage in the life-cycle, all 4 levels are included to
3242 provide a comparison and basis for system security assurance level selection.
3243 In C.1.2.3, the selection is based on reviewing company policy and the AC guideline
3244 provided in ISA62443-3-3.
3245 In C.2.1 the selection is based on FR1 AC3 and the added security strength
3246 requirements to discriminate between system security assurance levels. System security
3247 assurance is designated design because t he additional detail provides information needed
3248
for the build-to decision.
3249 In C.2.2 and C.3 the selection is based on the same information described previously,
3250 but now given an installed security architecture which has been validated after site
3251 acceptance testing and commissioning. This is designated time t0 and the system security
3252 assurance is now labeled achieved.
3253 In C.4, the maintenance life-cycle phase includes comments regarding system security
3254 compliance metrics and the designation is labeled measured based on assessment of
3255 measured performance.
3256 Consequence analysis
3257 It is interesting to note that the selected requirements from does not mention consequence
3258 analysis per se. This example assumes that consequence analysis occurs throughout the life -
3259 cycle. It is not a one-time analysis. Each time it is performed the parameters of the
3260 consequence analysis are somewhat different.
3261 For example when developing a company policy, a consequence analysis of sufficient depth is
3262 needed to establish the policies and procedures and provided sufficient guidance to establish
3263 the target security assurance level for the SuC.
3264 When the security architecture is selected (design), a consequence analysis is repeated with
3265 parameters that reflect the capability of enabling security mechanisms.
3266 When installed and commissioned (achieved) at time t0, a consequence analysis is repeated
3267 to account for any variance between design expectations and real capability that has been
3268 verified by testing & analysis for commissioning.
3269 Lastly, during maintenance of the installed security architecture, a consequence analysis is
3270 repeated based on collected measurements of performance a nd other reports required by
3271 ISA62443-1-3. Practical experience has shown that deviations from the norm (what was
3272 expected) may or may not have an impact on the assessed consequence.
3273 Selected application of ISA62443-3-3 to the system under consideration
3274 ISA62443-3-33 defines the guidelines to apply assessment criteria. For this example (Figure
3275 C-1), tailored for IACS application, the AC-3 guideline is prescribed in terms of control with
3276 supplemental guidance.
3277 Control: The Industrial Automation Control System shall provide the capability to enforce
3278 assigned authorizations for controlling access to the system in accordance with applicable
3279 policy.
3280 Supplemental guidance: Access control policies (e.g., identity-based policies, role-based
3281 policies, rule-based policies) and associated access enforcement mechanisms (e.g., access
3282 control lists, access control matrices, cryptography) are employed by organizations to control
3283 access between users (or processes acting on behalf of users) and objects (e.g., devices,
3284 files, records, processes, programs, domains) in the IACS. In addition to controlling access at
3285 the information system level, access enforcement mechanisms are employed at the
3286 application level, when necessary, to provide increased information security for the
3287 organization. Consideration is given to the implementation of a controlled, audited, and
3288 manual override of automated mechanisms in the event of emergencies or other serious
3289 events. If encryption of stored information is employed as an access enforcement mechanism,
3290 the cryptography used is FIPS 140-2 (as amended) compliant.
3291 For this example a review of company policies and procedures determined that the
3292 organization explicitly defines privileged functions and security -relevant information for the
3293 IACS. Furthermore, the organization explicitly authorizes personnel access to privileged
3294 functions and security-relevant information in accordance with organizational policy. And, the
3295 IACS restricts access to privileged functions (deployed in hardware, software, and firmware)
3296 and security-relevant information to explicitly authorized personnel (e.g., security
3297 administrators). Lastly, automated test mechanism implementing access enforcement policies
3298 are widely deployed.
3299 For these reasons, access enforcement requires security assurance which is constrained by
3300 the need to ensure IACS operational availability, comply with the need to ensure public and
3301 environmental safety, guard against total system failure and to guard against the possibility of
3302 loss of life. Based on the installed operational concept, the asse t owners senior management

3303 states that for this example, the following target system security assurance levels ( )
3304 which are subject to verification by the system integrator; and if required, a recognized
3305 certification authority:

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

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

3310 = 3: IACS security functions are mission critical, are the target of
3311 adversarial threats, do not require immediate response, but disruption could result
3312 in significant performance and financial impact resulting from the total fail ure of
3313 IACS operating capability.

3314 = 4: IACS functions are mission critical, are the target of adversarial threats,
3315 but require immediate response to ensure public and environmental safety resulting
3316 from the total failure of IACS operating capability or loss of life.
3317 Focus on Access Enforcement
3318 Design (build-to) security assurance level
3319 An example of mapping this methodology to the IACS security requirements for Figure C -1 is
3320 described in this clause. For the purpose of this exampl e, the design security assurance
3321 levels S_system^design are based on selected (build -to) security architecture.
3322 FR 1: Access Control (AC)
3323 ISA62443-3-3 AC-3: Access Enforcement (AE)
3324 Requirement: The IACS shall provide the capability to enforce assigned authorizations for
3325 controlling access to the system in accordance with applicable policy.
3326 Rationale/Supplemental Guidance: Access control policies (e.g., identity -based policies, role-
3327 based policies, rule-based policies) and associated access enforcement mechanisms (e.g.,
3328 access control lists, access control matrices, cryptography) are employed by organizations to
3329 control access between users (or processes acting on behalf of users) and objects (e.g.,
3330 devices, files, records, processes, programs, domains) in the IACS. In addition to controlling
3331 access at the system level, access enforcement mechanisms are employed at the application
3332 level, when necessary, to provide increased information security for the organization.
3333 Consideration is given to the implementation of a controlled, audited and manual override of
3334 automated mechanisms in event of emergencies or other serious events. The organization
3335 ensures that access enforcement mechanisms do not adversely impact the oper ation
3336 performance of the IACS.
3337 Requirement Enhancement (RE-1): The IACS shall provide the capability to restrict access to
3338 privileged functions (deployed in hardware, software, and firmware) and security -relevant
3339 information to explicitly authorized person nel.
3340 Enhancement Rationale/Supplemental Guidance: Explicitly authorized personnel must

3341 include, for example, IACS operators, security administrators, system and communication
3342 network administrators, and other privileged users. Privileged users are individu als who have
3343 access to system control, monitoring, or administration functions (e.g., systems
3344 administrators, SAS security officers, maintainers, system programmers).
3345 Requirement Enhancement (RE-2): The IACS shall provide the capability for dual
3346 authorization, based on approved organization procedures, to privileged functions that have
3347 impacts on facility, human, and environmental safety.
3348 RE-2 Security Strength 0: No explicit security strength is mandated.
3349 RE-2 Security Strength 1: Organization with functional responsibility shall sign-off (approval)
3350 on access privileges.
3351 RE-2 Security Strength 2: Senior management with oversight responsibility of the functional
3352 organization responsible shall sign-off (approval) on access privileges.
3353 Enhancement Rationale/Supplemental Guidance: The organization does not employ dual -
3354 approved mechanisms when an immediate response is necessary to ensure human and
3355 environmental safety.
3356 Design System Security Assurance Levels:

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

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

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

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

3364 sufficient discrimination to differentiate between assignments. Furthermore, the

3365 aggregation of =1, 2, 3 or 4 contributed by each zone, conduit, or class of device
3366 shown above depends on the implementation of ISA-99.03.02 (security assurance levels for
3367 zones and conduits), ISA-99.01.03 (system security compliance metrics), ISA-99.03.04, ISA-
3368 99.04.01.. 04 (derived requirements for classes of components). Is important to remember
3369 that allocation of system security assurance to zones, conduits and classes of components, as
3370 well as aggregation of security assurance provide by elements of the SuC are not within the
3371 scope of ISA-99.03.03.
3372 C.1.3 Achieved security assurance level

3373 Based on a review of company policies and procedures it was determined that the
3374 organization explicitly defines privileged functions and security -relevant information for the
3375 IACS. Furthermore, the organization explicitly authorizes personnel access to privileged
3376 functions and security-relevant information in accordance with organizational policy. And, the
3377 IACS restricts access to privileged functions (deployed in hardware, software, and firmware)
3378 and security-relevant information to explicitly authorized personnel (e.g., security
3379 administrators). Lastly, automated test mechanism implementing access enforcement policies
3380 are widely deployed.
3381 For these reasons, access enforcement requires security assurance which is constrained by
3382 the need to ensure IACS operational availability, comply with the need to ensure public and
3383 environmental safety, guard against total system failure and to guard against the possibility of
3384 loss of life. Based on the installed security architecture, the asset owner now states for the
3385 example, the following achieved system target security levels (

) which are subject to
3386 verification:
3387
= 1: IACS security functions are not mission critical and are not the target of
3389
= 2: IACS security functions are not mission critical, but are the target of
3391
= 3: IACS security functions are mission critical, are the target of
3392 adversarial threats, do not require immediate response, but disrup tion could result
3393 in significant performance and financial impact resulting from the total failure of
3394 IACS operating capability.
3395
= 4: IACS functions are mission critical, are the target of adversarial threats,
3396 but require immediate response to ensure public and environmental safety resulting
3397 from the total failure of IACS operating capability or loss of life.
3398 Furthermore, the asset owner states that all metrics for this example are subject to the
3399 following considerations:
3400 All

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

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

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

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

3408 Subject to all conditions described in C.1.3, when the security architecture has been
3409 implemented and all site acceptance testing is com plete, the achieved system security
3410 assurance level is

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

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

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

3418 If security is maintained in accordance with ISA-99.02.02 and quantitative metrics described
3419 in ISA-99.01.03 are collected and automatically processed in a timely manner, the measured
3420 system security assurance can be assessed on a regular basis using the same procedures
3421 described in C.2. The result should be labelled

(t) = f(processed metrics). When
3422 (t) degrades to an unacceptable level (a value determined by the Asset Owner),

3423 corrective action is required to plus-up the system security assurance. Guidance for plus -up
3424 action is described in ISA-99.01.03 for each system metric.
3425
3426 Annex D
3427 (informative)
3428 Understanding how to use the ISA99 adaptation of the IEC styleguide
3429 D.1 Overview
3430 Annex D contains some notes that have been collected while going through the process of
3431 converting documents from the older ISA format to the newer IEC format. Please read through
3432 them to understand the basic style and formatting that should be applied to documen ts as
3433 they are being developed for the ISA99 committee.
3434 ISA has adopted the IEC styleguide [15] to format its documents from now on. ISA99 has
3435 found that not all of the appropriate formatting and text guidelines necessary to avoid editorial
3436 comments from IEC members are included in the styleguide. The following sub-clauses
3437 include discussions of different general practices that should be applied to all current and
3438 future ISA99 documents.
3439 D.2 Document and page formatting
3440 ALWAYS, ALWAYS, ALWAYS use styles to format text. Avoid using simple font formatting
3441 unless it is for a single word or a couple words. Use the IEC styles for their correctly
3442 named purpose. If you need another style that uses the same format as an existing style,
3443 but for another purpose, then use Words feature to create a new style based on another
3444 style. Do not modify the IEC styles unless you know what you are doing.
3445 Blocks of text should be positioned with textboxes and not with returns/line breaks. This
3446 ensures that text appear correctly on each persons computer regardless of the differences
3447 related to fonts.
3448 Document properties should be used for many of the standard items. The document items
3449 should utilize non-breaking spaces and non-breaking dashes. Microsoft Word doesnt
3450 seem to allow you to copy these non-breaking characters into the document properties, so
3451 you will have to type them in directly.
3452 The following is a list of the recommended list of p roperties:
3453 Title Security for industrial automation and control systems
3454 Subject Specific name of the document
3455 Author Editors name and affiliation
3456 Company ISA
3457 VerNo Version number (if there are multiple versions)
3458 DraftNo Draft number (reved for each voting draft)
3459 EditNo Edit number (reved periodically as edits and comments are incorporated)
3460 Date completed Date the version/draft/edit was completed (minimum month and
3461 year)
3462 Publisher ISA
3463 StdNo Currently 99, but will need to change to 62443 soon
3464 ComNo 99
3465 WrkGrpNo 2-digit version of working group number
3466 TskGrpNo 2-digit version of task group number (if applicable)
3467 SeriesNo Document series number (For example, ISA-99.02.01, where 02 is the
3468 SeriesNo)
3469 PartNo Document part number within the series (For example, ISA-99.02.01, where
3470 01 is the PartNo)
3471 DOC-01-01 ISA-99.01.01
3472
3473 DOC-XX-YY ISA-99.XX.YY

3474 DOC-Series ISA-99
3475 Document draft and edit numbers should be used .
3476 Draft numbers represent the voting version of the document. Each time a voting draft
3477 goes out for comment/vote, the draft number of the next version should be
3478 incremented.
3479 Edit numbers are incremented as significant cha nges are made to the document. This
3480 could be periodically or it could be based on the amount of content added. It allows the
3481 document to be tracked without too much difficulty. The significant period or content
3482 amount is left up to the working/task group, but should allow someone new to the
3483 group to understand most of the current state of the document without having too much
3484 additional material to absorb.
3485 The Table of Contents should be added using the pre-defined IEC macro. This will
3486 automatically populate the table of contents, table of figures, and table of tables. Some
3487 documents do not include any figures or tables, so when the document goes for
3488 voting/comment drafts, it may be necessary to delete the unused table (for the ISA
3489 version).
3490 D.3 Sectioning
3491 These items come out of the IEC styleguide, but arent always very o bvious when
3492 generating a document.
3493 All text paragraphs need to have some way to reference them. This means that there can
3494 be no hanging paragraphs. This includes things like emphasizing the base requirements or
3495 requirement enhancements by making them bold/underline instead of giving them their
3496 own heading designation.
INCORRECT EXAMPLE
4. Section title
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Etiam faucibus arcu
in lorem dapibus bibendum.
4.1 Subsection title

In augue sem, tincidunt in, tristique quis, dapibus eget, neque. Suspendisse
potenti. In suscipit lacus molestie odio.
CORRECT EXAMPLE
4. Section title
4.1 Overview

3497
3498 Section headings cannot go 3 deep in a single series.
INCORRECT EXAMPLE
4. Section title
4.1.1 Sub-subsection title
CORRECT EXAMPLE
4. Section title
4.1 Overview

3499 IEC limits section numbering to 6 levels deep, although we have generally tried to sti ck to
3500 at most 5 levels (a remnant of the original ISA document styleguide).
3501 D.4 Figures
3502 Figures should always be generated at 100% scaling with all fonts at 8pt.
3503 ISA99 generally uses Microsoft Visio 2003 or newer to generate graphics, although other
3504 programs are acceptable.
3505 For Visio graphics, save the graphic as a Windows Meta File (WMF) first, then insert it into
3506 the Microsoft Word file. This seems to be more stable and less prone to conversion issues
3507 than inserting a Microsoft Visio object directly.
3508 Avoid generating bitmap files (PNG, JPG, GIF, etc.) for line -art graphics unless absolutely
3509 necessary. These file formats rasterize the line art graphics, so they cant be blown up or
3510 zoomed properly in print copies or PDFs of the document.
3511 D.5 Tables
3512 Tables should always use the pre-defined IEC styles for tables unless absolutely
3513 necessary.
3514 Large tables may need to have the page rotated to view properly. There is an IEC macro
3515 to rotate the page to landscape. Try this first. If that doesnt work properly, generate a new
3516 section and add in a textbox to display the page numbering and other header information.
3517 Tables that extend over more than 2 pages need to have a title on the top of each page
3518 reflecting the table name and the table title. There are multiple ways to acco mplish this.
3519 You can break the table itself at the page break and then add table headers for each new
3520 table. The preferred way would be to break the table after the first page, add in an
3521 additional header row to the second page with the (continued) line in the title, and then
3522 repeat the title and normal header rows from then on. This will auto -populate the title on
3523 each subsequent page.
3524 Dont allow rows to break across pages. This is not an absolute requirement, but annoys
3525 many people when reading documents. It is an easy fix and keeps all the content for a
3526 particular item easily viewable.
3527 D.6 Wording and language recommendations
3528 Use a single space between sentences.

3529 Do not use contractions. Use should not instead of shouldnt.
3530 Use formal language. Do not use informal or colloquial sayings, unless necessary.
3531 Do not use first or second person terms like I, we, us, you, etc. It is improper in some
3532 cultures to speak to others that you do not know using these types of terms.
3533 Use standard-eeze, requirement-style language in both the normative requirements and in
3534 supplemental guidance.
3535 The word must connotes an absolute necessity like the law of gravity. It should only
3536 be used as such.
3537 Terms like shall, should, and may are the recommended forms of requ irement-
3538 style language. Needs to is also another one that seems to be acceptable.
3539 Statements like this person is going to do that action should not be used. It should be
3540 rephrased as this person needs to do that action or this person should perform that
3541 action.
3542 Dont use e.g. or i.e. Use terms like for example and such as instead.
3543 Once an acronym has been defined in the normative sections of the document (starting
3544 with clause 1), avoid reusing the text form of the term again. Also, dont redefin e the term
3545 again. Terms defined in the preface, forward, or clause 0 should still be defined in clauses
3546 and annexes that follow.
3547 Dont over-capitalize words. There is a tendency to capitalize words to connote emphasis.
3548 Words should not be capitalized unless they are names or specific terms used in industry.
3549 ISA99 references the committee, ISA-99 references the document series. Be careful when
3550 using these in the document and in communications.
3551
3552 BIBLIOGRAPHY
3553 NOTE This bibliography includes references to sources used in the creation of this standard as well as references
3554 to sources that may aid the reader in developing a greater understanding of cyber security as a whole and
3555 developing a management system. Not all references in this bibliography are referred to throughout the text of this
3556 standard. The references have been broken down into different categories depending on the type of source they
3557 are.
3558 References to other parts, both existing and anticipated, of the ISA62443 series:
3559 NOTE Some of these references are normative references (see Clause 2), published documents, in development,
3560 or anticipated. They are all listed here for completeness of the anticipated parts of the ISA62443 series.
3561 SKELETON NOTE For the reference to this document below, change the document reference to a note stating
3562 This standard is . You cant have a circular reference from a document to itself.
3563 [1] ANSI/ISA62443-1-1-2007, Security for industrial automation and control systems:
3564 Terminology, concepts and models
3565 [2] ANSI/ISATR62443-1-2, Security for industrial automation and control systems:
3566 Master glossary of terms and abbreviations
3567 [3] ANSI/ISA62443-1-3, Security for industrial automation and control systems: System
3568 security compliance metrics
3569 [4] ANSI/ISA62443-2-1-2009, Security for industrial automation and control systems:
3570 Establishing an industrial automation and control system security program
3571 [5] ANSI/ISA62443-2-2, Security for industrial automation and control systems:
3572 Operating an industrial automation and control system security program
3573 [6] ANSI/ISATR62443-2-3, Security for industrial automation and control systems: Patch
3574 management in the IACS environment
3575 [7] ANSI/ISATR62443-3-1-2007, Security for industrial automation and control systems:
3576 Security technologies for industrial automation and control systems
3577 [8] ANSI/ISA62443-3-2, Security for industrial automation and control systems: Targe t
3578 security assurance levels for zones and conduits
3579 [9] ANSI/ISA62443-3-3, Security for industrial automation and control systems: System
3580 security requirements and security assurance levels
3581 [10] ANSI/ISA62443-3-4, Security for industrial automation and control systems: Product
3582 development requirements
3584 Embedded devices
3585 [12] ANSI/ISA62443-4-2, Security for industrial automation and control systems: Host
3586 devices
3587 [13] ANSI/ISA62443-4-3, Security for industrial automation and control systems: Network
3588 devices
3590 Application, data and functions
3591 Other standards references:
3592 [15] ISO/IEC Directives, Part 2, Rules for the structure and drafting of International
3593 Standards
3594
3595 SKELETON NOTE Anything that can have an ISO/IEC, NATO, etc. number should be included in the Other
3596 standards references section. For ISA documents, these should receive their ISA numbers if they have them,
3597 otherwise, use the international numbering. For IEC versions of the documents, these numbers should be replaced
3598 with their international number equivalents. (For example, ANSI/ISA -95.00.01-2000 would be replaced by
3599 IEC 62264-1 in the IEC version.)
3600 In addition to the two sections of references above, you can also have other sections like:
3601 Industry-specific and sector-specific references Trade organization documents and such.
3602 Other documents and published sources National/government documents or any other published
3603 resources. NIST FIPS/SP documents fall into this category.
3604 Websites Full sites or pages within specific sites containing reference material.
3605
3606 Developing and promulgating technically sound consensus standards and recommended
3607 practices is one of ISA's primary goals. To achieve this goal the Standards and Practices
3608 Department relies on the technical expertise and efforts of volunteer committee members,
3609 chairmen, and reviewers.
3610 ISA is an American National Standards Institute (ANSI) accredited organization. ISA
3611 administers United States Technical Advisory Groups (USTAGs) and provides secretariat
3612 support for International Electrotechnical Commission (IEC) and International Organization for
3613 Standardization (ISO) committees that develop process measurement and contr ol standards.
3614 To obtain additional information on the Society's standards program, please write:
3615
3616 ISA
3617 Attn: Standards Department
3618 67 Alexander Drive
3619 P.O. Box 12277
3620 Research Triangle Park, NC 27709
3621
3622 ISBN: -to-be-assigned-
3623
3624
3625
3626
3627
3628

ISA 62443 1 1 Draft

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

ISA 62443 1 1 Draft

Transféré par

Droits d'auteur :

Formats disponibles

FOR REVIEW PURPOSES ONLY!

IT IS PROVIDED SOLELY FOR THE PURPOSE OF REVIEW IN SUPPORT OF FURTHER DEVELOPMENT

Models and Concepts

Research Triangle Park, NC 27709 USA

Security for industrial automation and control systems

Name Company Contributor Reviewer

107 9.4 Zone Model ........................................................................................................... 41

155 11.5.7 FR 7 Resource availability (RA) .............................................................. 73

201 Figure 17 Separate Zones Example ................................................................................... 77

263 2 Normative references

274 ANSI/ISA-95.00.01-2000, Enterprise-Control System Integration Models and Terminology,

276 ISO/IEC 27001 Information technology Security techniques Information security

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

908 3.2 Abbreviated terms and acronyms

ANSI American National Standards Institute

910 3.3 Conventions

915 3.3.1 Reserved terms

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

1005 5 The Situation

1011 5.2 Business Environment

1033 5.3 Current Systems

1070 a) who is authorized to access electronic information.

1078 a) Businesses have reported more unauthorized attempts (either intentional or

1132 5.7 Common Constraints

1137 5.7.1 GEN 1.0 Support of Essential Functions

1167 5.7.2.2 Rationale

1184 6 Security Elements

1198 6.2 People

1204 The following topic areas fall under people:

1235 6.3 Processes

1261 Security Policy

1276 6.4 Technology

1285 Identification, Authentication and Access Control (AC)

1297 6.5 Use Cases

1329 Table 1 Elements Applied to Change Control and Configuration Management

1337 6.6 Summary

Intent, Buy-In, Support

Training and Capability

Decisions and Awareness

1341 Not part of ISA-62443 series of documents

1342 Figure 4 Implementation of People, Process, and Technology

1361 7 Principal Roles

1367 As a minimum the roles described shall include the following:

1375 System Integrator It is common for an IACS to be designed and configured by an

1387 8 IACS Definition

1390 1) range of functionality included

1396 8.1 Functionality Included

1405 a) electricity transmission and distribution

1414 8.2 Systems and Interfaces

1439 a) predictable operation of the process

1472 8.5 Consequence-Based Criteria

1490 Specific models that shall be used include:

1503 9.2 Reference Model

1507 A reference model describes a generic view of an integrated manufacturing or production

Site Monitoring & Local

1517 9.2.1 Level 4 Enterprise Business Systems

1524 9.2.2 Level 3 - Operations Management

1528 9.2.3 Level 2 Supervisory Control

1532 9.2.4 Level 1 Local or Basic Control

1552 Level 1 equipment includes, but is not limited to:

1553 d) DCS controllers

1561 9.2.5 Level 0 Process

1567 9.3 Reference Architecture Model