FOR USE AND REVIEW ONLY BY MEMBERS OF ISA99 AND APPROVED PARTIES:
This is a draft of an ISA99 committee work product. It is to be used solely for the purpose of supporting
the further development of ISA-62443 standards. New versions will be generated periodically as
individual documents are revised. It may not be reproduced or distributed to others, offered for sale, or
used for commercial purposes.
Copyright © by the International Society of Automaton. All rights reserved. Not for resale. Printed in
the United States of America. No part of this publication may be reproduced, stored in a retrieval
system, or transmitted, in any form or by any means (electronic, mechanical, photocopying, recording, or
otherwise), without the prior written permission of the Publisher.
ISA
67 Alexander Drive
P. O. Box 12277
Research Triangle Park, North Carolina 27709
USA
This page intentionally left blank
ISA 62443 4 2
Security for industrial automation and control systems
Technical security requirements for IACS components
Draft 4, Edit 1
January 12, 2017
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
1
2
ISA-62443-4-2, D4E1
2
January 12, 2017
3
4
ISA
Security for industrial automation and control systems
Technical Security Requirements for IACS Components
ISBN: -to-be-assigned-
Copyright © 2017 by ISA. All rights reserved. Not for resale. Printed in the United State s of
America.
ISA
67 Alexander Drive
P. O. Box 12277
Research Triangle Park, NC 27709 USA
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
5
3
ISA-62443-4-2, D4E1
6
PREFACE
7
8
This preface, as well as all footnotes and annexes, is included for information purposes and is not
part of ISA 62443 4 2.
9
10
11
12
13
14
This document has been prepared as part of the service of ISA, the International Society of
Automation, toward a goal of uniformity in the field of instrumentation. To be of real value, this
document should not be static but should be subject to periodic review. Toward this end, the Society
welcomes all comments and criticisms and asks that they be addressed to the Secretary, Standards
and Practices Board; ISA; 67 Alexander Drive; P. O. Box 12277; Research Triangle Park, NC
27709; Telephone (919) 549-8411; Fax (919) 549-8288; E-mail: standards@isa.org.
15
16
17
18
19
20
21
22
23
24
The ISA Standards and Practices Department is aware of the growing need for attention to the
metric system of units in general and the International System of Units (SI) in particular, in the
preparation of instrumentation standards. The Department is further aware of the benefits to USA
users of ISA standards of incorporating suitable references to the SI (and the metric system) in
their business and professional dealings with other countries. Tow ard this end, this Department will
endeavor to introduce SI-acceptable metric units in all new and revised standards, recommended
practices and technical reports to the greatest extent possible. Standard for Use of the International
System of Units (SI): The Modern Metric System, published by the American Society for Testing
and Materials as IEEE/ASTM SI 10-97, and future revisions, will be the reference guide for
definitions, symbols, abbreviations, and conversion factors.
25
26
27
28
29
It is the policy of ISA to encourage and welcome the participation of all concerned individuals and
interests in the development of ISA standards, recommended practices and technical reports.
Participation in the ISA standards-making process by an individual in no way constitutes
endorsement by the employer of that individual, of ISA or of any of the standards, recommended
practices and technical reports that ISA develops.
30
31
32
33
34
CAUTION
ISA adheres to the policy of the American National Standards Institute with
regard to patents. If ISA is informed of an existing patent that is required for use of the
standard, it will require the owner of the patent to either grant a royalty -free license for use
of the patent by users complying with the standard or a license on reasonable terms and
conditions that are free from unfair discrimination.
35
36
37
38
39
40
41
42
Even if ISA is unaware of any patent covering this Standard, the user is cautioned that
implementation of the standard may require use of techniques, processes or materials
covered by patent rights. ISA takes no position on the existence or validity of any patent
rights that may be involved in implementing the standard. ISA is not responsible for
identifying all patents that may require a license before implementation of the standard or
for investigating the validity or scope of any patents brought to its attention. The user should
43
44
45
However, ISA asks that anyone reviewing this standard who is aware of any patents that may
impact implementation of the standard notify the ISA Standards and Practices Department
of the patent and its owner.
46
47
48
49
50
51
52
Additionally, the use of this standard may involve hazardous materials, operations or
equipment. The standard cannot anticipate all possible applications or address all possible
safety issues associated with use in hazardous conditions. The user of this standard must
53
application.
particular circumstances. The user must also consider the applicability of any governmental
regulatory limitations and established safety and health practices before implementing this
standard.
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
January 12, 2017
ISA-62443-4-2, D4E1
January 12, 2017
The following people served as active members of ISA99 Working Group 04, Task Group 4 in the
preparation of this document:
Name
Company
Contributor
Reviewer
Kevin Staggs, TG Chair
Honeywell
Dennis Brandl
BR&L Consulting
X
X
Khaled Brown
Intel Security
X
Eric Byres
Byres Security Consulting.
X
Eric Cosman
OIT Concepts, LLC
X
William Cotter
3M Company
X
Ed Crawford
Chevron Energy Technology Co
X
John Cusimano
AE Solutions
Maarten de Caluwé
Dow Benelux BV
Michael Dransfield
NSA
Mark Fabro
Lofty Perch Inc.
X
Forrest Automation & Technology
Solutions LLC
X
Ronald Forrest
Dirk Gebert
Siemens
X
Jim Gilsinn
Kenexis
X
Thomas Good
ICS Security Consultant
X
Evan Hand
Conagra Foods
X
Vic Hammond
Argonne National Laboratory
X
Mark Heard
TMD Consulting
X
Dennis Holstein
OPUS Consulting Group
X
Bruce Honda
City of Federal Way
X
Charles Hoover
Rockwell Automation
Eric Hopp
Rockwell Automation
X
Bob Huba
Consultant
X
Andrew Kling
Schneider Electric
X
Pierre Kobes
Siemens
X
Nate Kube
Consultant
X
Joel Langill
AECOM
X
Suzanne Lightman
NIST
X
Charles Mastromonico
Westinghouse Savannah River Co.
X
Mike Medoff
Exida
X
Jason Moore
Xilinx
Ajay Mishra
Invensys
X
Alex Nicoll
Rockwell Automation
X
Johan Nye
Exxon Mobil
X
Bryan Owen
OSISoft Inc
X
Tom Phinney
Consultant
X
Jeff Potter
Emerson
Tom Phinney
Consultant
X
X
X
X
X
X
X
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
54
55
4
56
5
ISA-62443-4-2, D4E1
Bob Radvanovsky
Infracritical
X
Ragnar Schierholz
ABB
Omar Sherin
Q-Cert
X
Leon Steinocher
Redstone Investors
X
Herman Storey
Herman Storey Consulting
X
Michele Struvay
NXP Semiconductors
Tatsuaki Takebe
KPMG Consulting Co, Ltd
X
Bradley Taylor
University of the District of Columbia
X
Zachary Tudor
SRI International
X
Joseph Weiss
Applied Control Solutions LLC
X
Ludwig Winkel
Siemens AG
X
X
X
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
January 12, 2017
ISA-62443-4-2, D4E1
6
January 12, 2017
CONTENTS
57
59
0
Introduction ....................................................................................................................10
60
61
62
1
0.1
Overview ..............................................................................................................10
0.2
Purpose and intended audience ...........................................................................10
Scope .............................................................................................................................13
63
2
Normative references .....................................................................................................13
64
3
Terms, definitions, abbreviated terms, acronyms, and conventions .................................13
4
3.1 Terms and definitions ............................................................................................13
3.2 Abbreviated terms and acronyms ...........................................................................19
3.3 Conventions ..........................................................................................................22
Common control system security constraints ..................................................................22
5
4.1
4.2
4.3
4.4
4.5
FR 1
Overview ...............................................................................................................22
Support of essential functions ................................................................................23
Compensating countermeasures............................................................................23
Least privilege .......................................................................................................23
Overarching constraints .........................................................................................23
Identification and authentication control ..............................................................24
6
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.9
5.10
5.11
5.12
5.13
5.14
5.15
5.16
FR 2
Purpose and SL-C(IAC) descriptions .....................................................................24
Rationale ...............................................................................................................24
CR 1.1 Human user identification and authentication ..........................................25
CR 1.2 Software process and device identification and authentication ................25
CR 1.3 Account management .............................................................................27
CR 1.4 Identifier management ............................................................................27
CR 1.5 Authenticator management .....................................................................28
CR 1.6 Wireless access management .................................................................29
CR 1.7 Strength of password-based authentication.............................................29
CR 1.8 Public key infrastructure certificates .......................................................30
CR 1.9 Strength of public key-based authentication ............................................30
CR 1.10 Authenticator feedback .........................................................................32
CR 1.11 Unsuccessful login attempts .................................................................32
CR 1.12 System use notification .........................................................................33
CR 1.13 Access via untrusted networks ..............................................................33
CR 1.14 Strength of symmetric key-based authentication ...................................33
Use control..........................................................................................................34
6.1
6.2
6.3
6.4
6.5
6.6
6.7
6.8
Purpose and SL-C(UC) descriptions ......................................................................34
Rationale ...............................................................................................................35
CR 2.1 Authorization enforcement ......................................................................35
CR 2.2 Wireless use control ...............................................................................36
CR 2.3 Use control for portable and mobile devices ............................................36
CR 2.4 Mobile code ............................................................................................37
CR 2.5 Session lock ...........................................................................................37
CR 2.6 Remote session termination ....................................................................37
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
58
100
101
102
103
104
105
106
107
7
ISA-62443-4-2, D4E1
7
6.9
6.10
6.11
6.12
6.13
6.14
6.15
FR 3
CR 2.7
CR 2.8
CR 2.9
CR 2.10
CR 2.11
CR 2.12
CR 2.13
System
8
7.1
7.2
7.3
7.4
7.5
7.6
7.7
7.8
7.9
7.10
7.11
7.12
7.13
7.14
7.15
7.16
FR 4
Purpose and SL-C(SI) descriptions ........................................................................42
Rationale ...............................................................................................................42
CR 3.1 Communication integrity .........................................................................42
CR 3.2 Protection from malicious code ...............................................................43
CR 3.3 Security functionality verification .............................................................43
CR 3.4 Software and information integrity ...........................................................44
CR 3.5 Input validation .......................................................................................45
CR 3.6 Deterministic output ................................................................................45
CR 3.7 Error handling .........................................................................................46
CR 3.8 Session integrity .....................................................................................46
CR 3.9 Protection of audit information ................................................................47
CR 3.10 Support for updates ..............................................................................48
CR 3.11 Physical tamper resistance and detection .............................................48
CR 3.12 Provisioning product supplier roots of trust ...........................................48
CR 3.13 Provisioning asset owner roots of trust .................................................48
CR 3.14 Integrity of the boot process ..................................................................48
Data confidentiality..............................................................................................48
125
126
127
128
129
130
9
8.1
8.2
8.3
8.4
8.5
FR 5
Purpose and SL-C(DC) descriptions ......................................................................48
Rationale ...............................................................................................................48
CR 4.1 Information confidentiality .......................................................................48
CR 4.2 Information persistence ..........................................................................49
CR 4.3 Use of cryptography................................................................................50
Restricted data flow ............................................................................................51
131
132
133
134
135
136
9.1
9.2
9.3
9.4
9.5
10 FR 6
Purpose and SL-C(RDF) descriptions ....................................................................51
Rationale ...............................................................................................................51
CR 5.1 Network segmentation ............................................................................51
CR 5.2 Zone boundary protection .......................................................................51
CR 5.3 General purpose person-to-person communication restrictions ...............51
Timely response to events...................................................................................52
137
138
139
140
141
10.1
10.2
10.3
10.4
11 FR 7
Purpose and SL-C(TRE) descriptions ....................................................................52
Rationale ...............................................................................................................52
CR 6.1 Audit log accessibility .............................................................................52
CR 6.2 Continuous monitoring ............................................................................53
Resource availability ...........................................................................................53
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
142
143
144
Concurrent session control .....................................................................38
Auditable events .....................................................................................38
Audit storage capacity ............................................................................39
Response to audit processing failures ...................................................40
Timestamps ..........................................................................................40
Non-repudiation ....................................................................................41
Use of physical diagnostic and test interfaces .......................................42
integrity ..................................................................................................42
11.1 Purpose and SL-C(RA) descriptions ......................................................................53
11.2 Rationale ...............................................................................................................54
11.3 CR 7.1 Denial of service protection.....................................................................54
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
January 12, 2017
8
January 12, 2017
145
146
147
148
149
150
151
11.4 CR 7.2 Resource management ...........................................................................54
11.5 CR 7.3 Control system backup ...........................................................................55
11.6 CR 7.4 Control system recovery and reconstitution .............................................55
11.7 CR 7.6 Network and security configuration settings ............................................56
11.8 CR 7.7 Least functionality ...................................................................................56
11.9 CR 7.8 Control system component inventory ......................................................57
12 Software application requirements ..................................................................................57
152
153
154
155
12.1 Purpose.................................................................................................................57
12.2 SAR 2.4 Mobile code ..........................................................................................57
12.3 SAR 3.2 Protection from malicious code .............................................................58
13 Embedded device requirements ......................................................................................58
156
157
158
159
160
161
162
163
164
165
13.1
13.2
13.3
13.4
13.5
13.6
13.7
13.8
13.9
14 Host
166
167
168
169
170
171
172
173
174
175
14.1 Purpose.................................................................................................................64
14.2 HDR 2.4 Mobile code..........................................................................................64
14.3 HDR 2.13 Use of physical diagnostic and test interfaces ....................................64
14.4 HDR 3.2 Protection from malicious code .............................................................65
14.5 HDR 3.10 Support for updates ............................................................................65
14.6 HDR 3.11 Physical tamper resistance and detection ...........................................66
14.7 HDR 3.12 Provisioning product supplier roots of trust .........................................67
14.8 HDR 3.13 Provisioning asset owner roots of trust ...............................................67
14.9 HDR 3.14 Integrity of the boot process ...............................................................68
15 Network device requirements ..........................................................................................69
176
177
178
179
180
181
182
183
184
185
186
187
188
189
15.1 Purpose.................................................................................................................69
15.2 NDR 1.6 Wireless access management ..............................................................69
15.3 NDR 1.13 Access via untrusted networks ...........................................................69
15.4 NDR 2.4 Mobile code..........................................................................................70
15.5 NDR 2.13 Use of physical diagnostic and test interfaces ....................................70
15.6 NDR 3.2 Protection from malicious code .............................................................71
15.7 NDR 3.10 Support for updates ............................................................................71
15.8 NDR 3.11 Physical tamper resistance and detection ...........................................72
15.9 NDR 3.12 Provisioning product supplier roots of trust .........................................72
15.10 NDR 3.13 Provisioning asset owner roots of trust ...............................................73
15.11 NDR 3.14 Integrity of the boot process ...............................................................74
15.12 NDR 5.2 Zone boundary protection .....................................................................74
15.13 NDR 5.3 General purpose, person-to-person communication restrictions ............75
Annex A (informative) Component catagories........................................................................77
Purpose.................................................................................................................58
EDR 2.4 Mobile code ..........................................................................................59
EDR 2.13 Use of physical diagnostic and test interfaces .....................................59
EDR 3.2 Protection from malicious code .............................................................60
EDR 3.10 Support for updates ............................................................................60
EDR 3.11 Physical tamper resistance and detection ...........................................61
EDR 3.12 Provisioning product supplier roots of trust .........................................62
EDR 3.13 Provisioning asset owner roots of trust ...............................................62
EDR 3.14 Integrity of the boot process ...............................................................63
device requirements ...............................................................................................64
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
ISA-62443-4-2, D4E1
January 12, 2017
195
196
197
198
ISA-62443-4-2, D4E1
A.1
Device categories ..................................................................................................77
A.1.1 Device category: embedded device ...........................................................77
A.1.2 Device category: network device................................................................78
A.1.3 Device category: host device/application ...................................................78
Annex B (informative) Mapping of CRs and REs to FR SL levels 1 -4 .....................................80
B.1
B.2
Figure 1
Overview ...............................................................................................................80
SL mapping table ..................................................................................................80
ISA 62443 Work Products....................................................................................12
199
200
FOREWORD
201
202
203
204
205
206
This standard is part of a multipart standard that addresses the issue of security for the components which are contained
in industrial automation and control systems (IACS). It has been developed by working group 04, task group 4 of the
ISA99 committee in cooperation with IEC TC65/WG10.
This standard prescribes the security requirements for the components that are used to build control systems. These
security requirements are derived from the system requirements for IACS defined in ISA 62443 3 3 [1] 1 and as such,
assigns component security levels (SLs) which are based on the system security levels.
1 Numbers in brackets indicate references in the Bibliography.
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
190
191
192
193
194
9
ISA-62443-4-2, D4E1
10
January 12, 2017
207
0
Introduction
208
209
210
211
NOTE
212
0.1
213
214
215
216
217
218
219
Industrial automation and control system (IACS) organizations increasingly use commercial -off-theshelf (COTS) networked devices that are inexpensive, efficient and highly automated. Control
systems are also increasingly interconnected with non -IACS networks for valid business reasons.
These devices, open networking technologies and increased connectivity provide an increased
opportunity for cyber-attack against control system hardware and software. That weakness may
lead to health, safety and environmental (HSE), financial and/or reputational consequences in
deployed control systems.
220
221
222
223
224
225
Organizations choosing to deploy business information technology (IT) cyber security solutions to
address IACS security may not fully comprehend the results of their decision. While many business
IT applications and security solutions can be applied to IACS, they need to be applied in an
appropriate way to eliminate inadvertent consequences. For this reason, the approach used to
define system requirements needs to be based on a combination of functional requirements and
risk assessment, often including an awareness of operational issues as well.
226
227
228
229
230
231
232
233
234
235
236
237
IACS security countermeasures should not have the potential to cause loss of essential services
and functions, including emergency procedures. (IT security countermeasures, as often deployed,
do have this potential.) IACS security goals focus on control system availability, plant protection,
plant operations (even in a degraded mode) and time -critical system response. IT security goals
often do not place the same emphasis on these factors; they may be more concerned with
protecting information rather than physical assets. These different goals need to be clearly stated
as security objectives regardless of the degree of plant integration ach ieved. A key step in the risk
assessment, as required by ISA 62443 2 1 2 [5], should be the identification of which services and
functions are truly essential for operations. (For example, in some facilities engineering support
may be determined to be a non-essential service or function.) In some cases, it may be acceptable
for a security action to cause temporary loss of a non-essential service or function, unlike an
essential service or function that should not be adversely affected.
238
239
240
241
242
243
This standard provides the cyber security technical requirements for the components that make up
an IACS, specifically the embedded devices, network components, host components and software
applications. This standard derives its requirements from the IACS System security requirements
described in ISA 62443 3 3 [11]. The intent of this standard is to specify security capabilities that
enable a component to be integrated into a system environment at a given security level (SL)
without the assistance of compensating countermeasures .
244
245
246
247
248
249
The primary goal of the ISA 62443 series is to provide a flexible framework that facilitates
addressing current and future vulnerabilities in IACS and applying necessary mitiga tions in a
systematic, defensible manner. It is important to understand that the intention of the ISA 62443
series is to build extensions to enterprise security that adapt the requirements for business IT
systems and combines them with the unique requirements for strong integrity and availability
needed by IACS.
250
0.2
251
252
The IACS community audience for this standard is intended to be asset owners, system integrators,
product suppliers, and, where appropriate, compliance authorities. Compliance authorities include
Overview
Purpose and intended audience
2 Many documents in the ISA 62443 series are currently under review or in development.
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
The format of this standard follows the ISO/IEC requirements discussed in ISO/IEC Directives, Part 2 [13]. These
directives specify the format of the standard
requirements specified in normative clauses use the conventions discussed in Appendix H of the Directives
document.
11
ISA-62443-4-2, D4E1
253
254
government agencies and regulators with the legal authority to perform audits to verify compliance
with governing laws and regulations.
255
256
257
258
259
260
261
262
263
System integrators will use this standard to assist them in procuring control system components
that make up an IACS solution. The assistance will be in the form of helping system integrators
specify the appropriate security capability level of the individual components they are procuring .
The primary standards for system integrators are ISA 62443 2 1 [5], ISA 62443 2 4 [8],
ISA 62443 3 2 [10] and ISA 62443 3 3 [11] which provide organizational and operational
requirements for a security management system and guide them through the process of defining
security zones for a system and the target security capability levels (SL-T) for those zones. Once
the SL-T for each zone has been defined, the system integrator will procure components that
provide the necessary capabilities to achieve the SL-T for each zone.
264
265
266
267
268
269
270
271
272
273
Product suppliers will use this standard to understand the requirements placed on control system
components for specific security capability level (SL-C)s of those components. A component may
not provide the capability itself but may be designed to integrate with a higher level entity and thus
- for example an embedded device may not be maintaining a
user directory itself, but may integrate with a system wide authentication and authorization service
and thus still meet the requirements to provide individual user authentication, authorization and
management capabilities. This standard will guide product suppliers as to which requirements can
be allocated and which requirements need to be native in the components . As defined in Practice
8 of ISA 62443 4 1 [12], the product supplier will provide documentation of how to properly
integrate the component into a system to meet a specific SL-T.
274
275
276
277
278
The component requirements (CRs) in this standard are derived from the system requirements
(SRs) in ISA 62443 3 3 [11]. The requirements in ISA 62443 3 3 [11] are referred to as SRs,
which are derived from the overall foundational requirements (FRs) defined in ISA 62443 1 1 [1].
CRs may also include a set of requirement enhancements (REs). The combination of CRs and REs
is what will determine the target security level that a component is capable of .
279
280
281
This standard provides component requirements for four types of components: software application,
embedded device, host device and network device. Thus the CRs for each type of component will
be designated as follows:
282
Software application requirements (SAR);
283
Embedded device requirements (EDR);
284
Host device requirements (HDR); and
285
Network device requirements (NDR).
286
287
288
289
The majority of the requirements in this standard are the same for the four types of components
and are thus designated simply as a CR. When there are unique component-specific requirements
then the generic requirement will state that the requirements are component-specific and are
located in the device-specific requirements clauses of this standard.
290
Figure 1 shows a graphical depiction of the ISA 62443 series when this standard was written.
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
January 12, 2017
292
12
291
Figure 1
ISA 62443 Work Products
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
ISA-62443-4-2, D4E1
January 12, 2017
1
Scope
294
295
296
297
298
299
300
This standard in the ISA 62443 series provides detailed technical control system component
requirements (CRs) associated with the seven foundational requirements (FRs) described in
ISA 62443 1 1 [1] including defining the requirements for control system capability security levels
and their components, SL-C(component). These requirements would be used by various members
of the industrial automation and control system (IACS) community along with the de fined zones
and conduits for the system under consideration (SuC) while developing the appropriate control
system target SL, SL-T(control system), for a specific asset.
301
As defined in ISA 62443 1 1 there are a total of seven FRs:
302
a) Identification and authentication control (IAC),
303
b) Use control (UC),
304
c) System integrity (SI),
305
d) Data confidentiality (DC),
306
e) Restricted data flow (RDF),
307
f) Timely response to events (TRE), and
308
g) Resource availability (RA).
309
310
311
These seven requirements are the foundation for control system capability SLs, SL-C(component).
Defining security capability at the control system component level is the goal and objective of this
standard as opposed to SL-T or achieved SLs (SL-A), which are out of scope.
312
313
NOTE
314
2
315
316
317
The following referenced documents are indispensable for the application of this standard. For
dated references, only the edition cited applies. For undated references, the latest edition of the
referenced document (including any amendments) applies.
318
319
ISA 62443 1 1
models [1]
320
321
ISA 62443 3 3 Security for industrial automation and control systems, Part 3-3: System security
requirements and security levels [11]
322
323
ISO/IEC 19790:2012 Information technology
cryptographic modules [17]
324
3
325
3.1
326
327
For the purposes of this document, the terms and definitions given in the normative references
specified in Clause 2 apply, in addition to the following.
328
329
330
331
NOTE
332
333
334
335
3.1.1
asset
any physical, logical and informational object that have value to the organization and are associated
with the IACS
Refer to ISA 62443 2 1 [5] for an equivalent set of non-technical, program-related, capability SRs necessary for
fully achieving a SL-T(control system).
Normative references
Security for industrial automation and control systems, Part 1-1: Concepts and
Security techniques
Security requirements for
Terms, definitions, abbreviated terms, acronyms, and conventions
Terms and definitions
Many of the following terms and definitions are originally based on relevant International Organization for
Standardization (ISO), International Electrotechnical Commission (IEC) and U.S. National Institute of Standards
and Technology (NIST) sources, sometimes with minor modifications to en hance suitability for control system
security requirements.
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
293
336
337
338
Note 1 to entry: In this specific case, an asset is any item that should be protected as part of the IACS security
management system.
339
340
341
3.1.2
asset owner
individual or company responsible for one or more IACS
342
343
344
Note 1 to entry:
Used in place of the generic term end user to provide differentiation.
Note 2 to entry:
This includes the components that are part of the IACS.
Note 3 to entry:
In the context of this standard, an asset owner also includes the operator of the IACS.
345
346
347
3.1.3
attack
assault on a system that derives from an intelligent threat
348
349
350
351
352
353
354
355
356
357
358
359
Note 1 to entry: For example, an intelligent act that is a deliberate attempt (especially in the sense of a method or
technique) to evade security services and violate the security policy of a system .
360
361
362
3.1.4
authentication
provision of assurance that a claimed characteristic of an identity is correct
363
Note to entry:
364
365
366
3.1.5
authenticator
means used to confirm the identity of a user (human, software process or device)
367
Note to entry:
368
369
370
3.1.6
authenticity
property that an entity is what it claims to be
371
372
Note to entry: Authenticity is typically used in the context of confidence in the identity of an entity, or the validity of a
transmission, a message or message originator.
373
374
375
3.1.7
automatic
process or equipment that, under specified conditions, functions without human intervention
376
377
378
379
3.1.8
availability
property of ensuring timely and reliable access to and use of control system information and
functionality
380
381
382
3.1.9
communication channel
specific logical or physical communication link between IACS assets
383
Note to entry:
Note 2 to entry:
There are different commonly recognized classes of attack:
An "active attack" attempts to alter system resources or affect their operation.
A "passive attack" attempts to learn or make use of information from the system but does not affect system
resources.
An "inside attack" is an attack initiated by an entity inside the security perimeter (an "insider"), for example, an
entity that is authorized to access system res ources but uses them in a way not approved by those who granted
the authorization.
An "outside attack" is initiated from outside the perimeter, by an unauthorized or illegitimate user of the system
(including an insider attacking from outside the security perimeter). Potential outside attackers range from
amateur pranksters to organized criminals, international terrorists and hostile governments.
Authentication is usually a prerequisite to allowing access to resources in a control system.
For example, a password or token may be used as an authenticator.
A channel facilitates the establishment of a connection.
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
Note 2 to entry: An asset is not limited to the IACS alone, but can also include the physical assets under its control
384
385
386
387
3.1.10
compensating countermeasure
countermeasure employed in lieu of or in addition to inherent security capabilities to satisfy one or
more security requirements
388
389
390
391
392
393
394
395
396
Note to entry:
397
398
399
400
3.1.11
conduit
logical grouping of communication channels , connecting two or more zones, that share common
security requirements
401
402
Note to entry: A conduit is allowed to traverse a zone as long as the security of the channels contained within the conduit
is not impacted by the zone.
403
404
405
3.1.12
confidentiality
assurance that information is not disclosed to unauthorized individuals, processes, or devices
406
407
Note to entry: When used in the context of an IACS, refers to protecting IACS data and information from unauthorized
access.
408
409
410
411
3.1.13
connection
association established between two or more endpoints that supports the establishment of a
session
412
413
414
3.1.14
consequence
condition or state that logically or naturally follows from an event
415
416
417
3.1.15
control system
hardware and software components of an IACS
418
419
420
421
422
3.1.16
countermeasure
action, device, procedure or technique that reduces a threat, a vulnerability or the consequences
of an attack by eliminating or preventing it, by m inimizing the harm it can cause or by discovering
and reporting it so that corrective action can be taken
423
424
425
Note to entry:
been chosen for this standard
.
426
427
428
429
3.1.17
degraded mode
mode of operation in the presence of faults that have been anticipated in the design of the control
system
430
431
432
433
Note to entry: Degraded modes allow the control system to continue to provide essential functions despite the deficiency
of one or several system elements, for example, malfunction or outage of control equipment , disruption of
communication due to failure or intentional system isolation in response to identified or suspected compromise
of subsystems.
(control system/zone-level): physical access control (guards, gates and guns) to protect a control room to restrict
access to a group of known personnel to compensate for the technical requirement for personnel to be uniquely
identified by the IACS; and
(component-level): a product supplier programmable logic controller (PLC) cannot meet the access control
capabilities from an asset owner, so the product supplier puts a firewall in front of the PLC and sells it as a
system.
oncept in some contexts. The term countermeasure has
process control and
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
Examples include:
(component-level): locked cabinet around a controller that does not have sufficient cyber access control
countermeasures;
3.1.18
device
asset incorporating one or more processors with the capability of sending or receiving data/control
to or from another asset
438
439
Note to entry: Examples include controllers, human-machine interfaces (HMIs), PLCs, remote terminal units (RTUs),
transmitters, actuators, valves, network switches, etc.
440
441
442
443
3.1.19
embedded device
special purpose device running embedded software designed to d irectly monitor, control or actuate
an industrial process
444
445
446
447
448
Note 1 to entry: Typical attributes limited storage, limited number of exposed services, programmed through an external
interface, embedded operating systems (OSs) or firmware equivalent, real-time scheduler, may have an attached
control panel, and may have a communications interface.
449
450
451
452
3.1.20
environment
surrounding objects, region or circumstances which may influence the behavior of the IACS and/or
may be influenced by the IACS
453
454
455
456
3.1.21
essential function
function or capability that is required to maintain health, safety, the environment (HSE) and
availability for the equipment under control
457
458
459
460
Note to entry: Essential functions include, but are not limited to, the safety instrumented function (SIF), the control
function and the ability of the operator to view and manipulate the equipment under control. The loss of essential
functions is commonly termed loss of protection, loss of control and loss of view respectively. In some industries
additional functions such as history may be considered essential.
461
462
463
3.1.22
event
occurrence of or change to a particular set of circumstances
464
465
466
Note to entry: In an IACS this may be an action taken by an individual (authorized or unauthorized), a change detected
within the control system (normal or abnormal) or an automated response from the control system itself (normal
or abnormal).
467
468
469
3.1.23
firecall
method established to provide emergency access to a secure control system
470
471
472
Note to entry: In an emergency situation, unprivileged users can gain access to key systems to correct the problem.
When a firecall is used, there is usually a review process to ensure that the access was used properly to correct
a problem. These methods generally either provide a one -time use user identifier (ID) or one-time password.
473
474
475
476
477
3.1.24
host device
general purpose device running an operating system (for example Microsoft Windows OS or Linux)
capable of hosting one or more software applications, data stores or functions from one or more
suppliers
478
479
Note to entry: Typical attributes include filesystem(s), programmable services , no real time scheduler and full HMI
(keyboard, mouse, etc.).
480
481
482
483
3.1.25
identifier
symbol, unique within its security domain, that identifies, indicates or names an entity that makes
an assertion or claim of identity
Note 2 to entry: Examples include PLCs, field sensor devices, safety instrumented system (SIS) controllers, distributed
control system (DCS) controllers.
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
434
435
436
437
3.1.26
identify
assert an identity of
487
488
489
3.1.27
impact
evaluated consequence of a particular event
490
491
492
493
3.1.28
incident
event that is not part of the expected operation of a system or service that causes, or may cause,
an interruption to, or a reduction in, the quality of the service provided by the control system
494
495
496
497
3.1.29
industrial automation and control system
collection of personnel, hardware, software and policies involved in the operation of the industrial
process and that can affect or influence its safe, secure and reliable operation
498
499
500
3.1.30
integrity
intended function based on stated requirements under specific operating conditions
501
502
503
504
3.1.31
least privilege
basic principle that holds that users (humans, software processes or devices) should be assigned
the fewest privileges consistent with their assigned duties and f unctions
505
Note to entry:
506
507
508
509
510
3.1.32
mobile code
511
512
Note to entry: Examples of mobile code include JavaScript, VBScript, Java applets, ActiveX controls, Flash animations,
Shockwave movies, and Microsoft Office macros.
513
3.1.33
514
515
516
517
518
519
mobile device
intelligent electronic device intended for use while mobile
Note to entry: Examples of mobile devices include laptop computers (depending on their usage, laptops can also be
-held programmers, tablet computers and personal
digital assistants.
520
521
522
523
3.1.34
network device
device that facilitates data flow between devices, or restricts the flow of data, but does not directly
interact with a control process
524
525
Note to entry: Typical attributes include embedded OS or firmware, no HMI, no real-time scheduler and configured
through an external interface.
526
527
528
3.1.35
non-repudiation
ability to prove the occurrence of a claimed event or action and its originating entities
529
530
Note to entry: The purpose of non-repudiation is to resolve disputes about the occurrence or non -occurrence of the
event or action and involvement of entities in the event.
Least privilege is commonly implemented as a set of roles in an IACS.
removable media that can be executed unchanged on a local system without explicit installation or
execution by the recipient
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
484
485
486
531
3.1.36
532
533
534
535
536
portable device
intelligent electronic device intended to be used in more than one physical location, but not
intended for use while in transport between locations
537
538
539
3.1.37
product supplier
manufacturer of hardware and/or software product
540
Note to entry:
541
542
543
544
3.1.38
remote access
access to a control system by any user (human, software process or device) communicating from
outside the perimeter of the zone being addressed
545
546
547
548
3.1.39
role
set of connected behaviors, privileges and obligations associated with a given user or group of
users (humans, software processes or devices) of an IACS
549
Note to entry:
550
551
552
3.1.40
safety instrumented system
system used to implement one or more safety-related functions
553
554
555
556
3.1.41
security level
measure of confidence that the IACS or a component thereof is free from vulnerabilities and
functions in the intended manner
557
558
559
560
561
Note to entry: Vulnerabilities can either be designed into the IACS, inserted at any time during its lifecycle or result from
changing threats. Designed-in vulnerabilities may be discovered long after the initial deployment of the IACS,
for example an encryption technique has been broken or an improper policy for account management such as
not removing old user accounts. Inserted vulnerabilities may be the result of a patch or a change in policy that
opens up a new vulnerability.
562
563
564
565
3.1.42
session
semi-permanent, stateful and interactive information interchange between two or more
communicating devices
566
Note to entry:
567
568
569
3.1.43
session ID
identifier used to indicate a specific session entry
570
571
572
573
3.1.44
set point
target value identified within a control system that controls one or more actions within the control
system
574
3.1.45
575
576
577
software application
one or more software programs and their dependencies that are used to interface with the process
or the control system itself (for example, configuration software and historian)
Used in place of the generic word
to provide differentiation.
The privileges to perform certain operations are ass igned to specific roles.
Typically a session has clearly defined start and end processes.
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
Note to entry: Examples of portable devices include laptop computers (depending on their usage, laptops can also be
578
579
580
Note 1 to entry: Software applications typically execute on host devices or embedded devices.
581
582
583
584
3.1.46
system integrator
person or company that specializes in bringing together component subsystems into a whole and
ensuring that those subsystems perform in accordance with project specifications
585
586
Note to entry: This may also include other system supplier designations such as General Automation Contractor, Main
Automation Contractor, Main Instrument Vendor, and similar .
587
588
589
590
591
3.1.47
threat
circumstance or event with the potential to adversely affect operations (including mission,
functions, image or reputation), assets, control systems or individuals via unauthorized access,
destruction, disclosure, modification of data and/or denial of service
592
593
594
595
3.1.48
trust
confidence that an operation, data transaction source, network or software process can be relied
upon to behave as expected
596
597
598
Note 1 to entry: Generally, an entity can be said to 'trust' a second entity when it (the first entity) makes the assumption
that the second entity will behave as the first entity expects.
599
600
601
602
3.1.49
unlinkability
assurance that a user may make multiple uses of resources or services without others being able to link
these uses together
603
604
605
3.1.50
untraceability
assurance that information cannot be used to track the time or location of a specific user
606
607
608
3.1.51
untrusted
not meeting predefined requirements to be trusted
609
Note to entry:
610
611
612
613
3.1.52
update
incremental hardware or software change in order to address a security vulnerability, a bug,
reliability or operability issue
614
615
616
3.1.53
upgrade
incremental hardware or software change in order to add a new feature
617
618
619
620
3.1.54
zone
collection of entities that represents partitioning of a System under Conside ration on the basis of
their functional, logical and physical (including location) relationship
621
622
Note to entry: A zone has a clear border. The security policy of a zone is typically enforced by a combination of
mechanisms both at the zone edge and within the zone.
623
3.2
Note 2 to entry:
This trust may apply only for some specific function.
An entity may simply be declared as untrusted.
Abbreviated terms and acronyms
ANSI
American National Standards Institute
API
Application programming interface
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
Note 2 to entry: Dependencies are any software programs that are necessary for the software application to functio n such
as database packages, reporting tools, or any third party or open source software .
Address space layout randomization
AVA_VAN
Common Criteria Class AVA Vulnerability Assessment
CA
Certification authority
CMAC
Cipher-based Message Authentication Code
COTS
Commercial off the shelf
CR
Component requirement
DC
Data confidentiality
DCS
Distributed control system
DEP
Data execution prevention
DMZ
Demilitarized zone
DoS
Denial of service
EAL
Evaluated assurance level
EDR
Embedded device requirement
EICAR
European Institute for Computer Antivirus Research
FAT
Factory acceptance testing
FDA
[US] Food and Drug Administration
FIPS
[US NIST] Federal Information Processing Standard
FR
Foundational requirement
FTP
File transfer protocol
GCM
Galois/Counter mode
GMAC
Galois message authentication c ode
HDR
Host device requirement
HMI
Human-machine interface
HSE
Health, safety and environmental
HTTP
Hypertext transfer protocol
HTTPS
HTTP secure
IAC
Identification and authentication control
IACS
Industrial automation and control system(s)
ID
Identifier
IDS
Intrusion detection system
IED
Intelligent electronic device
IEC
International Electrotechnical Commission
IEEE
Institute of Electrical and Electronics Engineers
IM
Instant messaging
IP
Internet protocol
IPS
Intrusion prevention system
ISA
International Society of Automation
ISO
International Organization for Standardization
IT
Information technology
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
ASLR
Network device requirement
NIST
U.S. National Institute of Standards and Technology
NX
No Execute
OS
Operating system
OWASP
Open Web Application Security Project
PC
Personal computer
PDF
Portable document format
PII
Personally identifiable information
PKI
Public key infrastructure
PLC
Programmable logic controller
PUF
Physically uncloneable function
RA
Resource availability
RADIUS
Remote authentication dial-in user service
RAM
Random access memory
RDF
Restricted data flow
RE
Requirement enhancement
RTOS
Real-time operating system
RTU
Remote terminal unit
SAR
Software application requirements
SAT
Site acceptance testing
SFTP
Secure FTP
SI
System integrity
SIEM
Security information and event management
SIF
Safety instrumented function
SIS
Safety instrumented system
SL
Security level
SL-A
Achieved security level
SL-C
Capability security level
SL-T
Target security level
SNMP
Simple network management protocol
SP
[US NIST] Special Publication
SR
System requirement
SSH
Secure socket shell
SuC
System under consideration
TCP
Transmission control protocol
TPM
Trusted platform module
TRE
Timely response to events
UC
Use control
USB
Universal serial bus
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
NDR
VPN
Virtual private network
3.3
625
626
627
628
629
630
631
632
633
634
635
636
637
638
This standard expands the SRs and REs defined in ISA 62443 3 3 [11] into a series of CRs and
REs for the components contained within an IACS. The types of components of an IACS as defined
in this standard are: software applications, host devices, embedded devices and network devices.
The majority of the SRs and REs are applicable to the four types of components and are combined
into a single Component Requirement (CR). Where there are unique requirements for each type
of component those are covered beginning with clause 12 Software application requirements. To
maintain ease of tracing the CRs to the SRs in ISA 62443 3 3 [11] the CR numbering will match
the associated SR. This will cause some gaps and non -sequential numbering in this standard. To
provide clarity to the reader, rationale and supplemental guidance is provided for each baseline
requirement and notes for any associated REs as is deemed necessary. The baseline requirement
and REs, if present, are then mapped to the component capability security level, SL-C(FR,
component) 1 to 4. The component capability security level, SL-C(FR, component) 1 to 4 is derived
from the control system capability security level defined for the associated SR in ISA 62443 3 3
[11].
639
640
641
642
643
As the security levels are derived from the system security levels defined in ISA 62443 3 3 [11],
these CRs are derived from the seven FRs defined in ISA 62443 1 1 [1]. Each of the seven FRs
has a defined set of four SLs. The control system capability level 0 for a particular FR is implicitly
defined as no requirements. For example, the purpose statement fo r Clause 8 FR 4
Data
confidentiality is:
644
645
Ensure the confidentiality of information on communication channels and in data repositories
to prevent unauthorized disclosure.
646
Conventions
The associated four SLs are defined as:
647
648
SL 1
Prevent the unauthorized disclosure of information via eavesdropping or casual
exposure.
649
650
SL 2 Prevent the unauthorized disclosure of information to an entity actively searching for
it using simple means with low resources, generic skills and low motivation.
651
652
653
SL 3 Prevent the unauthorized disclosure of information to an entity actively searching f or
it using sophisticated means with moderate resources, IACS specific skills and moderate
motivation.
654
655
656
SL 4 Prevent the unauthorized disclosure of information to an entity actively searching for
it using sophisticated means with extended resources, IACS specific skills and high
motivation.
657
658
659
The individual CR and RE assignments are thus based on an incremental increase in overall
component security for that particular FR based on knowledge and expertise from the team creating
this standard.
660
661
662
The SL-C(component), used throughout this standard, signifies a capability required to meet a
given SL rating for a given CR. A complete description of the SL vector concept can be found in
ISA 62443 3 3 [11].
663
4
664
4.1
665
666
667
Per the guidance provided in ISA 62443 3 3 [11], there are a number of system -level common
constraints. These system-level common constraints translate to component-level common
constraints such that the system-level common constraints are satisfied.
Common control system security constraints
Overview
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
624
4.2
Support of essential functions
669
670
As documented in clause 3.1.21
to maintain health,
671
672
Security countermeasures shall not adversely affect essential functions of a high availability
IACS unless supported by a risk assessment.
673
674
675
Thus the component-level CRs, which are derived from the system-level SRs, shall be designed
and implemented such that the essential functions of a high availability IACS are not adversely
affected by security countermeasures.
676
677
678
The components of the system such as software applications, embedded devices, host devices and
network devices shall adhere to specific constraints as described in clause 4 of ISA 62443 3 3
[11], including:
679
680
Access controls (IAC and UC) shall not prevent the operation of essential functions in
software applications and embedded devices with access controls.
681
682
Security countermeasures of embedded devices, host devices or network infrastructure that
provide boundary protection shall not im pact the essential functions of the system.
683
684
A denial of service (DoS) event on the control system or SIS network shall not prevent the
system components that implement the safety instrumented function (SIF) from acting.
685
4.3
Compensating countermeasures
686
687
688
689
690
There will be cases where one or more requirements specified in the document cannot be met the
requirement without the assistance of a compensating countermeasure that is external to the
component. When this is the case the documentation for that component shall describe the
appropriate countermeasures applied by the system to allow the requirement to be met when the
component is integrated into a system.
691
4.4
692
693
694
695
696
When required and appropriate, one or more system components (software applications, embedded
devices, host devices and network devices) shall provide the capability for the system to enforce
the concept of least privilege. Individual system components shall provide the granularity of
permissions and flexibility of mapping those permissions to roles sufficient to support it. Individual
accountability shall be available when required.
697
698
NOTE: Granularity of permissions and assignment is dependent on the type of device and the product documentation for
the device should define this in the product documentation.
699
4.5
700
The following overarching constraints will be referenced by the CR requirements.
701
4.5.1
702
703
All of the components defined in this standard shall be developed and supported following the
secure product development process guidelines described in ISA 62443 4 1 [12].
704
705
706
707
708
Controls described in this document that are not met must be addressed as part of the threat
assessment and mitigation process as described in ISA 62443 4 1 [12].
This includes
documenting security controls which are to be provided by the system into which the component is
installed. This documentation is to be included in the component document as described in
ISA 62443 4 1 [12].
709
4.5.2
710
The critical assets used to provide security shall be protected using hardware security.
Least privilege
Overarching constraints
Software development process
Implementation security
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
668
711
712
risk and threat analysis shows that these
methods are not required, or add no additional protection.
713
4.5.2.1
714
715
716
717
Based on a risk and threat analysis, components shall provide the capability to protect critical
assets via hardware mechanisms according to commonly accepted and proven security practices
and recommendations. This protection involves one or more of the following security objectives:
integrity, authenticity and confidentiality.
718
719
The component security shall match the value of the assets to be protected as part of that software
application/device.
720
721
722
Note: When cryptographic capabilities are required f or higher security level applications and devices t he security design
and implementation of the component a good reference for implementation of the capabilities is ISO/IEC 19790
[17] or FIPS 140-2 [24].
723
724
725
A risk and threat analysis shall be conducted to select the hardware security for the component
and a vulnerability analysis identifying the residual risks shall be conducted once the hardware
security is selected.
726
5
727
5.1
728
729
Identify and authenticate all users (humans, software processes and devices), and allow them
access to the system or assets.
730
731
SL 1
Identify and authenticate all users (humans, software processes and devices) by
mechanisms that protect against casual or coincidental access by unauthenticated entities.
732
733
734
SL 2
Identify and authenticate all users (humans, software processes and devices) by
mechanisms that protect against intentional unauthenticated access by entities using simple
means with low resources, generic skills and low motivation.
735
736
737
SL 3
Identify and authenticate all users (humans, software processes and devices) by
mechanisms that protect against intentional unauthenticated access by entities using
sophisticated means with moderate resources, IACS specific skills and moderate motivation.
738
739
740
SL 4
Identify and authenticate all users (humans, software processes and devices) by
mechanisms that protect against intentional unauthenticated access by entities using
sophisticated means with extended resources, IACS specific skills and high motivation.
FR 1
Identification and authentication control
Purpose and SL-C(IAC) descriptions
741
5.2
Rationale
742
743
744
745
746
747
748
749
750
Suppliers of components will develop a list of roles that are part of the product to enable that
product to securely operate in a system. This is done primarily for software processes and devices.
System integrators will work with end users to define a s et of roles necessary in the system to
support the requirements as specified by the asset owner. The goal of access control is to protect
the component by verifying the identity of any user requesting access to a component before
activating the communication with that component. Recommendations and guidelines should
include mechanisms that will operate in mixed modes. For example, some components on a
communication channel require strong access control, such as strong authentication mechanisms,
and others do not. By extension, access control requirements need to be extended to data at rest.
751
752
753
It is recommended that the number of identification and authentication mechanisms within a single
zone is minimized. The use of multiple identification and authenticati on mechanisms makes the
task of authentication and identification management more difficult to administer.
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
Hardware security
754
5.3
755
5.3.1
756
757
758
759
760
Components shall provide the capability to identify and authenticate all human users according to
ISA 62443 3 3 [11] SR 1.1 on all interfaces capable of human user access . This capability shall
enforce such identification and authentication on all interfaces that provide human user access to
the component to support segregation of duties and least privilege in accordance with applicable
security policies and procedures.
761
Note: Applicable security policies are a local matter.
762
5.3.2
763
764
765
766
767
768
769
All human users need to be identified and authenticated for all access to the component.
Authentication of the identity of these users should be accomplished by using methods such as
passwords, tokens, and biometrics or, in the case of multifactor authentication, some combination
thereof. The geographic location of human users can also be used as part of the authentication
process. This requirement should be applied to both local and remote access to the component.
This requirement comes in addition to the requirement of having such an authentication and
identification at the system level.
770
771
772
773
774
775
776
Interfaces capable of human user access are loca l user interfaces such as touchscreens, push
buttons, keyboards, etc. as well as network protocols designed for human user interactions such
as hypertext transfer protocol (HTTP), secure HTTP (HTTPS), file transfer protocol (FTP), secure
FTP (SFTP), protocols used for device configuration tools (which are sometimes proprietary and
other times use open protocols). User identification and authentication may be role -based or groupbased (such as, for some component interfaces, several users may share the same identity). User
identification and authentication should not hamper fast , local emergency actions.
777
778
779
In order to support IAC policies, as defined according to ISA 62443 2 1 [5], the component should
verify the identity of all human users as a first step. In a second step, the permissions assigned to
the identified human user should be enforced (see 6.3).
780
5.3.3
781
(1) Unique identification and authentication:
783
Human user identification and authentication
Requirement
Rationale and supplemental guidance
Requirement enhancements
Components shall provide the capability to uniquely identify and authenticate all human users.
(2) Multifactor authentication for all interfaces
784
785
Components shall provide the capability to employ multifactor authentication for all human user
access to the component.
786
5.3.4
Security levels
787
The requirements for the four security levels that relate to CR 1.1 are:
788
SL-C(IAC,component) 1: CR 1.1
789
SL-C(IAC,component) 2: CR 1.1 (1)
790
SL-C(IAC,component) 3: CR 1.1 (1)
791
SL-C(IAC,component) 4: CR 1.1 (1) (2)
792
5.4
CR 1.2
Software process and device identification and authentication
793
5.4.1
794
795
796
Components shall provide the capability to identify itself and authenticate with any other component
(software application, embedded devices, host devices and network devices), according to
ISA 62443 3 3 [11] SR1.2.
Requirement
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
782
CR 1.1
797
798
799
If the component is running in the context of a human user, in addition, the identification and
authentication of the human user according to ISA 62443 3 3 [11] SR1.1 may be part of the
component identification and authentication process towards the other components.
800
5.4.2
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
The function of identification and authentication is to map an ID to an unknown software process or device
(henceforth referred to as an entity in this sub-clause) so as to make it known before allowing any data
exchange. Allowing rogue entities to send and receive control system specific data can result in
detrimental behavior of the legitimate control system.
829
830
831
In order to support identification and authentication control policies as defined according to ISA 62443 2 1
(99.02.01) [5], the control system verifies the identity of all entities as a first step. In a second step, the
permissions assigned to the identified entity are enforced (see 6.3, CR 2.1 Authorization enforcement)
832
5.4.3
833
(1) Unique identification and authentication
All entities should be identified and authenticated for all access to the control system. Authentication of the
identity of such entities should be accomplished by using methods such as passwords, tokens or location
(physical or logical). This requirement should be applied to both local and remote access to the control
system. However, in some scenarios where individual entities are used to connect to different target
systems (for example, remote vendor support), it may be technically infeasible for an entity to have
multiple identities. In these cases, compensating countermeasures would have to be applied.
Identification and authentication mechanisms for all entities are needed to protect against attacks such as
man-in-the-middle or message spoofing. In some cases, these mechanisms may involve multiple software
processes running on the same physical server, each having their own identity. In other cases, the identity
may be bound to the physical device, such as all processes running on a given PLC.
Special attention needs to be made when identifying and authenticating portable and mobile devices.
These types of devices are a known method of introducing undesired network traffic, malware and/or
information exposure to control systems, including otherwise isolated networks.
Where entities function as a single group, identification and authentication may be role-based, groupbased or entity-based. It is essential that local emergency actions as well as control system essential
functions not be hampered by identification or authentication requirements (see clause 4 for a more
complete discussion). For example, in common protection and control schemes, a group of devices jointly
execute the protection functions and communicate with multicast messages among the devices in the
group. In these cases, group authentication based on shared accounts or shared symmetric keys are
commonly used.
Requirement enhancements
Components shall provide the capability to uniquely and securely identify and authenticate itself
to any other component.
836
5.4.4
Security levels
837
The requirements for the four security levels that relate to CR 1.2 are:
838
SL-C(IAC,component) 1: Not Selected
839
SL-C(IAC,component) 2: CR 1.2
840
SL-C(IAC,component) 3: CR 1.2 (1)
841
SL-C(IAC,component) 4: CR 1.2 (1)
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
834
835
Rationale and supplemental guidance
842
5.5
CR 1.3
Account management
843
5.5.1
844
845
Components shall provide the capability to support the management of all accounts and/or provide
the management of all accounts directly according to ISA 62443 3 3 [11] SR 1.3.
846
5.5.2
847
848
A component may provide this capability by integrating into a higher level account management
system.
849
850
851
852
A common approach meeting this requirement would be a component that delegates the valuation
of authentication to a directory server (for example, using a protocol like remote authentication dialin user service (RADIUS) or Kerberos) which provides the account management capabilities
required by ISA 62443 3 3 [11] SR 1.3.
853
854
855
When a component integrates into a higher level system to provide the account management
capabilities there needs to be consideration for the impact to the component in the event that the
higher level system capability becomes unavailable.
856
5.5.3
857
None
858
5.5.4
859
The requirements for the four security levels that relate to CR 1.3 are:
Rationale and supplemental guidance
Requirement enhancements
Security levels
860
SL-C(IAC,component) 1: CR 1.3
861
SL-C(IAC,component) 2: CR 1.3
862
SL-C(IAC,component) 3: CR 1.3
863
SL-C(IAC,component) 4: CR 1.3
864
5.6
CR 1.4
Identifier management
865
5.6.1
866
867
868
Components shall provide the capability to integrate into a system that supports the management
of identifiers and/or provide the capability to support the management of identifiers directly
according to ISA 62443 3 3 [11] SR 1.4.
869
5.6.2
870
None
871
5.6.3
872
None
873
5.6.4
874
The requirements for the four security levels that relate to CR 1.4 are:
Requirement
Rationale and supplemental guidance
Requirement enhancements
Security levels
875
SL-C(IAC,component) 1: CR 1.4
876
SL-C(IAC,component) 2: CR 1.4
877
SL-C(IAC,component) 3: CR 1.4
878
SL-C(IAC,component) 4: CR 1.4
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
Requirement
879
5.7
CR 1.5
Authenticator management
880
5.7.1
881
Components shall provide the capability to:
882
a) support the use of initial authenticator content;
883
h) support the recognition of changes to default authenticators made at installation time;
884
i)
function properly with periodic authenticator change/refresh operation; and
885
886
887
888
889
j)
protect authenticators from unauthorized disclosure and modification when stored, us ed and
transmitted.
Note: Lockout or loss of control due to security countermeasures is not acceptable. If the control system is required to
have a high level of availability, measures should be taken to maintain this high level of availability (such as
compensating physical countermeasures, duplicate keys and supervisory override).
890
5.7.2
891
892
893
894
895
896
In addition to an identifier (see 5.6) an authenticator is required to prove identity. Control system
authenticators include, but are not limited to, tokens, symmetric keys, private keys (part of a
public/private key pair), biometrics, passwords, physical keys and key cards. There should be
security policies in place instructing that human users must take reasonable measures to safeguard
authenticators, including maintaining possession of their individual authenticators, not loaning or
sharing authenticators with others and reporting lost or compromised a uthenticators immediately.
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
Authenticators have a lifecycle. When an account is created automatically a new authenticator
needs to be created, in order for the account owner to be able to authenticate. For example, in a
password-based system, the account has a password associated with it. Definition of the initial
authenticator content could be interpreted as the administrator defining the initial password that
the account management system sets for all new accounts. Being able to configure these initial
values makes it harder for an attacker to guess the password between account creation and first
account use (which should involve the setting of a new password by the account owner). Some
control systems are installed with unattended installers that create all necessary accounts with
default passwords and some embedded devices are shipped with default passwords. Over time,
these passwords often become general knowledge and are documented on the Internet. Being able
to change the default passwords protects the system against unauthorized users using default
passwords to gain access. Passwords can be obtained from storage or from transmission when
used in network authentication. The complexity of this can be increased by cryptographic
protections such as encryption or hashing or by handshake protocols that do not require
transmission of the password at all. Still, passwords might be subject to attacks, for example , brute
force guessing or breaking the cryptographic protection of passwords in transit or s torage. The
window of opportunity can be reduced by changing/refreshing the passwords periodically. Similar
considerations apply to authentication systems based on cryptographic keys. Enhanced protection
can be achieved by using hardware mechanisms such as hardware security modules like trusted
platform modules (TPMs).
917
918
919
The management of authenticators should be specified in applicable security policies and
procedures, for example, constraints to change default authenticators, refresh periods,
specification of the protection of authenticators or firecall procedures.
Rationale and supplemental guidance
920
921
922
923
924
925
926
927
Besides the capabilities for authenticator management specified in this requirement, the strength
of the authentication mechanism depends on the strength of the chosen authenticator (for example ,
password complexity or key length in public key authentication) and the policies for validating the
authenticator in the authentication process (for example , how long a password is valid or which
checks are performed in public key certificate validation). For the most common authentication
mechanisms, password-based and public key authentication, 5.9, 5.10 and 5.11 provide further
requirements.
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
Requirement
928
929
930
931
Use of components for some operations may be restricted, requiring addition al authentication (such
as, tokens, keys and certificates) in order to perform some functions . Different measures to
safeguard authenticators may be required for components than what may be required for
processors.
932
5.7.3
933
(1) Hardware security for authenticators
934
935
936
The authenticators on which the component rely shall be protected via hardware mechanisms.
Note: Examples of hardware authentication include: Password protected memory, OTP memory, hardware data integrity
checks, and device security boot mechanism.
937
5.7.4
938
The requirements for the four security levels that relate to CR 1.5 are:
Security levels
939
SL-C(IAC,component) 1: CR 1.5
940
SL-C(IAC,component) 2: CR 1.5
941
SL-C(IAC,component) 3: CR 1.5 (1)
942
SL-C(IAC,component) 4: CR 1.5 (1)
943
5.8
CR 1.6
944
945
The wireless access management requirements are device-specific and can be located as
requirements for each specific device type in Clauses 15.
946
5.9
947
5.9.1
948
949
950
For components that utilize password-based authentication, those components shall provide or
integrate into a system that provides the capability to enforce configurable password strength based
on minimum length and variety of character types.
951
5.9.2
952
953
954
955
956
The ability to enforce configurable password strength, whether it is based on minimum length,
variety of characters, or duration of time (the minimum being a one -time password) is necessary to
assist in increasing the overall security of user chosen passwor ds. Generally accepted practices
and recommendations can be found in documents such as NIST SP800-63-2, Electronic
Authentication Guideline (Augustl 2013) [27].
957
5.9.3
958
(1) Password generation and lifetime restrictions for human users
CR 1.7
Wireless access management
Strength of password-based authentication
Requirement
Rationale and supplemental guidance
Requirement enhancements
959
Components shall provide, or integrate into a system that provides, the capability to prevent
960
any given human user account from reusing a password for a configurable number of
961
generations. In addition, the component shall provide the capability to enforce password
962
minimum and maximum lifetime restrictions for human users . These capabilities shall conform
963
to commonly accepted security industry practices.
964NOTE The component should provide the capability to prompt the user to change their password upon a configurable time
965
prior to expiration.
966
(2) Password lifetime restrictions for all users (human, software process, or device)
967
968
969
Components shall provide, or integrate into a system that provides , the capability to enforce
password minimum and maximum lifetime restrictions for all users.
Note: Examples may be automated data exchange thru SSH, SFTP or certificate passwords keystore.
970
5.9.4
971
The requirements for the four security levels that relate to CR 1.7 are:
Security levels
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
Requirement enhancements
SL-C(IAC,component) 1: CR 1.7
973
SL-C(IAC,component) 2: CR 1.7
974
SL-C(IAC,component) 3: CR 1.7 (1)
975
SL-C(IAC,component) 4: CR 1.7 (1) (2)
976
5.10
CR 1.8
Public key infrastructure certificates
977
5.10.1
978
979
980
When public key infrastructure (PKI) is utilized, the component shall provide or integrate into a
system that provides the capability to interact and operate in accordance with ISA 62443 3 3 [11]
SR1.8.
981
5.10.2
982
983
984
985
986
987
988
The selection of an appropriate PKI should consi der the orga
ate policy which
should be based on the risk associated with a breach of confidentiality of the protected information.
Guidance on the policy definition can be found in commonly accepted standards and guidelines,
such as the Internet Engineering Task Force (IETF) Request for Comment (RFC) 3647 [31] for
X.509-based PKI. For example, the appropriate location of a certification authority (CA), whether
within the control system versus on the Internet, and the list of trusted CAs should be con sidered
in the policy and depends on the network architecture (see also ISA 62443 2 1 [5]).
989
5.10.3
990
None
991
5.10.4
992
The requirements for the four security levels that relate to CR 1.8 are:
Requirement
Rationale and supplemental guidance
Requirement enhancements
Security levels
993
SL-C(IAC,component) 1: Not selected
994
SL-C(IAC,component) 2: CR 1.8
995
SL-C(IAC,component) 3: CR 1.8
996
SL-C(IAC,component) 4: CR 1.8
997
5.11
998
5.11.1
CR 1.9
Strength of public key-based authentication
Requirement
999
1000
1001
For components that utilize public-key-based authentication, those components shall provide
directly or integrate into a system that provides the capability within the same IACS environment
to:
1002
a) validate certificates by checking the validity of the signature of a given certificate;
1003
1004
k) validate the certificate chain or, in the case of self-signed certificates, by deploying leaf
certificates to all hosts that communicate with the subject to which the certificate is issued;
1005
l)
1006
m) establish user (human, software process or device) control of the corresponding private key;
1007
1008
1009
n) map the authenticated identity to a user (human, software process or device) by checking
either subject name, common name or distinguished name against the requested
destination; and
1010
1011
1012
o) ensure that the algorithms and keys used for the symmetric key authentication comply with
8.5 CR 4.3 Use of cryptography.
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
972
5.11.2
1014
1015
1016
1017
To meet the requirements in this clause does not necessarily require a real time connection to a
certificate authority. Alternative out of band methods may be used to meet the requirements in this
clause. For example, a disconnected system could install and update certifications using manual
out-of-band processes.
1018
1019
1020
1021
1022
1023
1024
1025
Rationale and supplemental guidance
and proper handling of the trust relationships. When v erifying a trust between two entities based
on public key authentication, it is essential to trace the public key certificate to a trusted entity. A
signature, but not checking the trust in the signer. In a PKI setting, a signer is trusted if they are a
trusted CA or have a certificate issued by a trusted CA, thus all verifiers need to trace certificates
presented to them back to a trusted CA. If such a chain of trusted CAs cannot be established, the
presented certificate should not be trusted.
1026
1027
1028
1029
1030
1031
1032
1033
If self-signed certificates are used instead of a PKI, the certificate subject itself signed its certificate,
thus there never is a trusted third-party or CA. This should be compensated by deploying the self signed public key certificates to all peers that need to validate them via an otherwise secured
mechanism (for example, configuration of all peers in a trusted environment). Trusted certificates
need to be distributed to peers through secure channels. During the validation process, a self signed certificate should only be trusted if it is already present in the list of trusted certificates of
the validating peer. The set of trusted certificates should be configure d to the minimum necessary
set.
1034
1035
1036
1037
1038
1039
In both cases, validation needs to also consider the possibility that a certificate is revoked. In a PKI
setting this is typically done by maintaining certificate revocation lists (CRLs) or running an online
certificate status protocol (OCSP) server. When revocation checking is not available due to control
system constraints, mechanisms such as a short certificate lifetime can compensate for the lack of
timely revocation information. Note that short lifetime certificates can sometimes create significant
operational issues in a control system environment.
1040
1041
1042
1043
1044
1045
It is expected that most components will integrate into an IACS and leverage the key authentication
mechanisms provided by the underlying IACS. When implementing public key authentication at the
component-level of an IACS, protection of the key becomes a primary concern and objective of key
storage on that component. Care should be taken in the implementation to assure that any private
keys stored within the component cannot be modified or tampered (See 5.7, CR 1.5 Authenticator
management).
1046
1047
NOTE Tamper resistant design methodologies and technologies are available to assist with designing a secure private
key protection mechanism.
1048
5.11.3
1049
(1) Hardware security for public key-based authentication
1050
Requirement enhancements
The control system shall provide the capability to protect the relevant private keys via hardware.
1051
5.11.4
Security levels
1052
The requirements for the four security levels that relate to CR 1.9 are:
1053
SL-C(IAC,component) 1: Not selected
1054
SL-C(IAC,component) 2: CR 1.9
1055
SL-C(IAC,component) 3: CR 1.9 (1)
1056
SL-C(IAC,component) 4: CR 1.9 (1):
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
1013
1057
5.12
CR 1.10
Authenticator feedback
1058
5.12.1
1059
1060
When a component provides an authentication capability, the component shall provide the
capability to obscure feedback of authentication information during the authentication pro cess.
1061
5.12.2
1062
1063
1064
1065
1066
1067
Obscuring feedback protects the information from possible exploitation by unauthorized individuals,
for example, displaying asterisks or other random characters when a human user types in a
username and/or password obscures feedback of authentication information. Other examples
include the entry of secure socket shell (SSH) token entry and one-time passwords. The
authenticating entity should not provide any hint as to the reason for the authentication failu re, such
1068
5.12.3
1069
None
1070
5.12.4
1071
The requirements for the four SL levels that relate to CR 1.10 are:
Rationale and supplemental guidance
Requirement enhancements
Security levels
1072
SL-C(IAC,component) 1: CR 1.10
1073
SL-C(IAC,component) 2: CR 1.10
1074
SL-C(IAC,component) 3: CR 1.10
1075
SL-C(IAC,component) 4: CR 1.10
1076
5.13
CR 1.11
Unsuccessful login attempts
1077
5.13.1
1078
1079
When a component provides an authentication capability, the component shall provide the
capability to:
1080
1081
a) enforce a limit of a configurable number of consecutive invalid access attempts by any user
(human, software process or device) during a configurable time period ; and
1082
1083
1084
b) deny access for a specified period of time or until unlocked by an administrator when this
limit has been reached.
Note: An administrator may unlock an account prior to the expiratio n of the timeout period.
1085
5.13.2
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
Due to the potential for denial of service, the number of consecutive invalid access attempts may
be limited. If enabled, the application or device may automatically reset to zero the number of
access attempts after a predetermined time period established by the applicable security policies
and procedures. Resetting the access attempts to zero will allow users (human, software process
or device) to gain access if they have the correct login identi fier. Automatic denial of access for
control system operator workstations or nodes should not be used when immediate operator
responses are required in emergency situations. All lockout mechanisms should consider functional
requirements for continuous operations so as to mitigate adverse denial of service operating
conditions which could result in total system failure or injury to personnel. Allowing interactive
logins to an account used for critical services could provide a potential for denial of service or other
abuse.
1097
5.13.3
1098
None
Requirement
Rationale and supplemental guidance
Requirement enhancements
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
Requirement
5.13.4
Security levels
1100
The requirements for the four SL levels that relate to CR 1.11 are:
1101
SL-C(IAC,component) 1: CR 1.11
1102
SL-C(IAC,component) 2: CR 1.11
1103
SL-C(IAC,component) 3: CR 1.11
1104
SL-C(IAC,component) 4: CR 1.11
1105
5.14
CR 1.12
System use notification
1106
5.14.1
1107
1108
1109
When a component provides local human user access/HMI, it shall provide the capability to display
a system use notification message before authenticating. The system use notification message
shall be configurable by authorized personnel.
1110
5.14.2
1111
1112
1113
1114
1115
1116
1117
Privacy and security policies and procedures need to be consistent with applicable laws, directives,
policies, regulations, standards and guidance. Often , the main justification for this requirement is
legal prosecution of violators and proving intentional breach. This capability is thus necessary to
support policy requirements, and might improve IACS security because it can be used as a
deterrent. System use notification messages can be implemented in the form of warning banners
displayed when individuals log in to the control system. A warning banner implemented as a posted
physical notice in the control system facility does not prote ct against remote login issues.
1118
Examples of elements for inclusion in the system use notification message are:
1119
a) that the individual is accessing a specific control system;
Requirement
Rationale and supplemental guidance
1120
p) that system usage may be monitored, recorded and subject to audit;
1121
1122
q) that unauthorized use of the system is prohibited and subject to crimi nal and/or civil
penalties; and
1123
r) that use of the system indicates consent to monitoring and recording.
1124
5.14.3
Requirement enhancements
1125
None
1126
5.14.4
1127
The requirements for the four SL levels that relate to CR 1.12 are:
Security levels
1128
SL-C(IAC,component) 1: CR 1.12
1129
SL-C(IAC,component) 2: CR 1.12
1130
SL-C(IAC,component) 3: CR 1.12
1131
SL-C(IAC,component) 4: CR 1.12
1132
5.15
CR 1.13
1133
1134
The access via untrusted networks requirements are device specific and can be located as
requirements for each specific device type in Clauses 12 through 15.
1135
5.16
1136
5.16.1
1137
For components that utilize symmetric keys, the component shall provide the capability to:
1138
a) establish the mutual trust using the symmetric key;
CR 1.14
Access via untrusted networks
Strength of symmetric key-based authentication
Requirement
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
1099
1139
1140
s) store securely the shared secret (the authentication is valid as long as the shared secret
remains secret);
1141
t)
1142
1143
u) ensure that the algorithms and keys used for the symmetric key authenticat ion comply with
CR 4.3 Use of cryptography Section 8.5.
1144
5.16.2
Rationale and supplemental guidance
1145
1146
1147
1148
Means should be defined for installing the keys into the component. This may include installing and
managing the component key using out-of-band methods. This is necessary since a compromise
of any symmetric keys that are stored within the component could lead to a full compromise of the
system using those keys.
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
In practice, there are two basic ways to perform the secure authentication of a device to another :
either using asymmetric cryptography (see 5.11) or by using symmetric cryptography. The choice
between asymmetric and symmetric is dictated by several criteria , like key management, trust
provisioning, legacy support and efficiency. Examples of symmetric key authentication schemes
are Needham-Schröder or Kerberos. When symmetric key authentication is used, the party uses a
secret key they have learned in the past (for example, through trust provisioning). The party proves
their claimed identity by proving knowledge of the secret key ( for example, by answering a
challenge submitted by the other party, the examiner). The examiner has the knowledge of the
same secret (also learned in the past through trust provisioning) and is able to compute the answer
to the challenge performing the same cryptographic operations as the prover. The examiner can
then compare the answer of the prover with its own computation. If they match, the examiner is
convinced that the prover is the one they claim to be and the process can be conducted the other
way around, switching roles, to achieve mutual-authentication. This mechanism is secure only if
the shared secret is only known by the prover and the examiner and if the secret is diversified per
prover. One instance of such a mechanism is the proper use of cipher-based message
authentication code (CMAC) computations or alternatively the Galois counter mode (GCM)/Galois
message authentication code (GMAC) operation modes.
1166
5.16.3
1167
(1) Hardware security for symmetric key-based authentication
1168
1169
The control system shall provide the capability to protect the relevant private keys via hardware
mechanisms.
1170
5.16.4
1171
The requirements for the four SL levels that relate to CR 1.14 are:
Requirement enhancements
Security levels
1172
SL-C(IAC,control system) 1: Not selected
1173
SL-C(IAC,control system) 2: CR 1.14
1174
SL-C(IAC,control system) 3: CR 1.14 (1)
1175
SL-C(IAC,control system) 4: CR 1.14 (1)
1176
6
FR 2
Use control
1177
6.1
1178
1179
Enforce the assigned privileges of an authenticated user (human, software process or device) to
perform the requested action on the component and monitor the use of these privileges.
1180
1181
SL 1 Restrict use of the IACS according to specified privileges to prot ect against casual
or coincidental misuse.
Purpose and SL-C(UC) descriptions
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
restrict access to the shared secret; and
SL 2
Restrict use of the IACS according to specified privileges to protect against
circumvention by entities using simple means with low resources, generic skills and low
motivation.
1185
1186
1187
SL 3
Restrict use of the IACS according to specified privileges to protect against
circumvention by entities using sophisticated means with moderate resources, IACS specific
skills and moderate motivation.
1188
1189
1190
SL 4
Restrict use of the IACS according to specified privileges to protect against
circumvention by entities using sophisticated means with extended resources, IACS specific
skills and high motivation.
1191
6.2
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
Once the user is identified and authenticated, the component has to restrict the allowed actions to
the authorized use of the component. Asset owners and system integrators will have to assign, to
each user (human, software process or device), group, role, etc. (see 4.5) , the privileges defining
the authorized use of the component. The goal of use control is to protect ag ainst unauthorized
actions on the components resources by verifying that the necessary privileges have been granted
before allowing a user to perform the actions. Examples of actions are reading or writing data,
downloading programs and setting configurations. Recommendations and guidelines should
include mechanisms that will operate in mixed modes. For example, some component resources
require strong use control protection, such as restrictive privileges, and others do not. By extension,
use control requirements need to be extended to data at rest. User privileges may vary based on
time-of-day/date, location and means by which access is made.
1203
6.3
1204
6.3.1
1205
1206
Components shall provide an authorization enforcement mechanism for all identified and
authenticated human users based on their assigned responsibilities and least privilege.
1207
6.3.2
1208
1209
There are additional requirements to consider for protection of the authorization information, for
example, 7.3 and 7.6 provide further requirements on integrity protection.
1210
6.3.3
1211
(1) Authorization enforcement for all users (humans, software processes and devices)
1212
1213
1214
1215
1216
1217
1218
1219
1220
Rationale
CR 2.1
Authorization enforcement
Requirement
Rationale and supplemental guidance
Requirement enhancements
Components shall provide an authorization enforcement mechanism for all users based on their
assigned responsibilities and least privilege.
(2) Permission mapping to roles
Components shall, directly or through a compensating security mechanism , provide for an
authorized role to define and modify the mapping of permissions to roles for all human users.
NOTE 1 Roles should not be limited to fixed nested hierarchies in which a higher level role is a super set of a lesser
privileged role. For example, a system administrator should not necessarily encompass operator privileges.
NOTE 2
This RE should be applicable to software processes and devices as well.
(3) Supervisor override
1221
Components shall support a supervisor manual override for a configurable time or sequence of
1222
events.
1223NOTE Implementation of a controlled, audited and manual override of automated mechanisms in the event of emergencies or
1224
other serious events is often needed. This allows a supervisor to enable an operator to quickly react to unusual
1225
conditions without closing the current session and establishing a new session as a higher privilege human user.
1226
1227
1228
(4) Dual approval
Components shall support dual approval when action can result in serious impact on the
industrial process.
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
1182
1183
1184
1229NOTE Dual approval should be limited to actions which require a very high level of confidence that they will be performed
1230
reliably and correctly. Requiring dual approval provides emphasis to the seriousness of consequences that would
1231
result from failure of a correct action. An example of a situation in which dual approval is required would be a change
1232
to a set point of a critical industrial process. Dual approval mechanisms should not be employed when an immediate
1233
response is necessary to safeguard HSE consequences, for example, emergency shutdown of an industrial process.
6.3.4
Security levels
1235
The requirements for the four security levels that relate to CR 2.1 are:
1236
SL-C(UC,component) 1: CR 2.1
1237
SL-C(UC,component) 2: CR 2.1 (1) (2)
1238
SL-C(UC,component) 3: CR 2.1 (1) (2) (3)
1239
SL-C(UC,component) 4: CR 2.1 (1) (2) (3) (4)
1240
6.4
CR 2.2
Wireless use control
1241
6.4.1
1242
1243
1244
If a component supports usage through wireless interfaces it shall provide the capability to
authorize, monitor and enforce usage restrictions according to commonly accepted industry
practices.
1245
6.4.2
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
Wireless use control may be implemented in different devices that make up the system. Network
devices may be one of the devices that assist with use control through controls such as network
admission control. For devices and applications that utilize wireless networks those devices should
be able to properly utilize wireless network protection such as network admission control.
Components may also implement different limitations on access based on whether the access is
from wireless devices or wired devices. This does place a need that the component be able to
distinguish whether the interface is through wireless or not. Some network devices provide the
capability to scan for unauthorized wireless network activity in the wireless spectrum . In order to
prevent a negative impact on the performance of the control sy stem functionality, it is a good
practice to deploy dedicated devices to perform checks for unauthorized network activity.
1256
6.4.3
1257
None
1258
6.4.4
1259
The requirements for the four SL levels that relate to CR 2.2 are:
Requirement
Rationale and supplemental guidance
Requirement enhancements
Security levels
1260
SL-C(UC, component) 1: CR 2.2
1261
SL-C(UC, component) 2: CR 2.2
1262
SL-C(UC, component) 3: CR 2.2
1263
SL-C(UC, component) 4: CR 2.2
1264
6.5
CR 2.3
Use control for portable and mobile devices
1265
6.5.1
1266
1267
Portable and mobile devices intended for use in a control system shall be able to operate in an
environment where use restrictions are enforced by the IACS.
1268
6.5.2
1269
Use control for portable and mobile devices is provided by the IACS.
1270
6.5.3
1271
None
Requirement
Rationale and supplemental guidance
Requirement enhancements
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
1234
6.5.4
Security levels
1273
The requirements for the four SL levels that relate to CR 2.3 are:
1274
SL-C(UC, component) 1: CR 2.3
1275
SL-C(UC, component) 2: CR 2.3
1276
SL-C(UC, component) 3: CR 2.3
1277
SL-C(UC, component) 4: CR 2.3
1278
6.6
CR 2.4
1279
1280
The use control requirements for mobile code are device specific and can be located as
requirements for each specific device type in Clauses 12 through 15.
1281
6.7
1282
6.7.1
1283
1284
If a component provides a human user interface, whether accessed locally or via a network, the
component shall provide the capability
1285
1286
a) to prevent further access by initiating a session lock after a configurable time period of
inactivity or by manual initiation;
1287
1288
1289
b) for the session lock to remain in effect until the human user who owns the session , or
another authorized human user, re-establishes access using appropriate identificati on and
authentication procedures; and
1290
1291
c) to comply with session locks requested by the underlying infrastructure (operating system,
control system).
CR 2.5
Mobile code
Session lock
Requirement
1292
6.7.2
Rationale and supplemental guidance
1293
1294
1295
1296
Session locks are used to prevent access to specified workstations or node s. Components should
activate session lock mechanisms automatically after a configurable time period. In most cases ,
the session locks are configured at the system level and thus applications and devices should be
providing the capability to use those configured session locks.
1297
6.7.3
1298
None
1299
6.7.4
1300
The requirements for the four SL levels that relate to CR 2.5 are:
Requirement enhancements
Security levels
1301
SL-C(UC, component) 1: CR 2.5
1302
SL-C(UC, component) 2: CR 2.5
1303
SL-C(UC, component) 3: CR 2.5
1304
SL-C(UC, component) 4: CR 2.5
1305
6.8
CR 2.6
Remote session termination
1306
6.8.1
1307
1308
1309
1310
If a component supports remote sessions, the component shall provide the capability to terminate
a remote session either automatically after a configurable time period of inactivity , manually by a
local authority, or manually by the user (human, software process or device) who initiated the
session.
Requirement
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
1272
6.8.2
Rationale and supplemental guidance
1312
1313
1314
1315
1316
1317
A remote session is initiated whenever a component is accessed across the boundary of a zone
defined by the asset owner based on their risk assessment. This requirement may be limited to
sessions that are used for component monitoring and maintenance activities (not critical
operations) based on the risk assessment of the control system and security policies and
procedures. Some components may not allow sessions to be terminated as the session might be
part of an essential function of the component .
1318
6.8.3
1319
None
1320
6.8.4
1321
The requirements for the four SL levels that relate to CR 2.6 are:
Requirement enhancements
Security levels
1322
SL-C(UC, component) 1: Not Selected
1323
SL-C(UC, component) 2: CR 2.6
1324
SL-C(UC, component) 3: CR 2.6
1325
SL-C(UC, component) 4: CR 2.6
1326
6.9
CR 2.7
Concurrent session control
1327
6.9.1
1328
1329
Components shall provide the capability to limit the number of concurrent sessions per interf ace
for any given user (human, software process or device) .
1330
6.9.2
1331
1332
1333
1334
A resource starvation DoS might occur if a limit is not imposed. There is a trade -off between
potentially locking out a specific user versus locking out all users and services due to a lack of
resources. Product supplier and/or system integrator guidance is likely required to provide sufficient
information as to how the number of concurrent sessions value should be assigned.
1335
6.9.3
1336
None
1337
6.9.4
1338
The requirements for the four SL levels that relate to CR 2.7 are:
Requirement
Rationale and supplemental guidance
Requirement enhancements
Security levels
1339
SL-C(UC, component) 1: Not Selected
1340
SL-C(UC, component) 2: Not Selected
1341
SL-C(UC, component) 3: CR 2.7
1342
SL-C(UC, component) 4: CR 2.7
1343
6.10
CR 2.8
Auditable events
1344
6.10.1
1345
1346
Components shall provide the capability to generate audit records relevant to securit y for the
following categories:
1347
a) access control;
1348
b) request errors;
1349
c) control system events;
1350
d) backup and restore event;
Requirement
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
1311
1351
e) configuration changes; and
1352
f)
1353
Individual audit records shall include:
1354
a) timestamp;
1355
b) source (originating device, software process or human user account);
1356
c) category;
1357
d) type;
1358
e) event ID; and
1359
f)
1360
6.10.2
1361
1362
1363
Devices may contain either embedded firmware or run an OS. While the intent of the requirement
is to cover categories of events, at least all events from the above categories which can be
generated by the firmware or OS are to be included.
1364
NOTE
1365
6.10.3
1366
None
1367
6.10.4
1368
The requirements for the four security levels that relate to CR 2.8 are:
event result.
Rationale and supplemental guidance
Security event categories are only applicable if functionality itself is pro vided by the component.
Requirement enhancements
Security levels
1369
SL-C(UC,component) 1: CR 2.8
1370
SL-C(UC,component) 2: CR 2.8
1371
SL-C(UC,component) 3: CR 2.8
1372
SL-C(UC,component) 4: CR 2.8
1373
6.11
CR 2.9
Audit storage capacity
1374
6.11.1
1375
Components shall
Requirement
1376
1377
a) provide the capability to allocate audit record storage capacity according to commonly
recognized recommendations for log management ; and
1378
1379
b) provide mechanisms to prevent a failure of the component when it reaches or exceeds the
audit storage capacity.
1380
6.11.2
Rationale and supplemental guidance
1381
1382
1383
1384
1385
Components should provide sufficient audit storage capacity, taking into account retention policy,
the auditing to be performed and the online audit proces sing requirements. Components may rely
on the system into which they are integrated to provide the majority of audit storage capacity.
However, the components should provide enough local storage to buffer audit data until it can be
sent to the system.
1386
1387
1388
Guidelines to be considered may include NIST Special Publication (SP) 800-92 [26]. The audit
storage capacity should be sufficient to retain logs for a period of tim e required by applicable
policies and regulations or business requirements.
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
audit log events.
1389
6.11.3
1390
(1) Warn when audit record storage capacity threshold reached
Components shall provide the capability to issue a warning when the allocated audit record
storage reaches a configurable threshold.
1393
6.11.4
Security levels
1394
The requirements for the four SL levels that relate to CR 2.9 are:
1395
SL-C(UC,component) 1: CR 2.9
1396
SL-C(UC,component) 2: CR 2.9
1397
SL-C(UC,component) 3: CR 2.9 (1)
1398
SL-C(UC,component) 4: CR 2.9 (1)
1399
6.12
CR 2.10
Response to audit processing failures
1400
6.12.1
1401
Components shall
Requirement
1402
1403
a) provide the capability to prevent the loss of essential services and functions in the event of
an audit processing failure; and
1404
1405
b) provide the capability to support appropriate actions in response to an audit processing
failure according to commonly accepted industry practices and recommendations.
1406
6.12.2
Rationale and supplemental guidance
1407
1408
1409
1410
1411
1412
1413
1414
1415
Audit generation typically occurs at the source of the event. Audit processing involves transmission,
possible augmentation (such as, the addition of a timestamp) and persistent storage of the audit
records. Audit processing failures include, for example, software or hardware errors, failures in the
audit capturing mechanisms and audit storage capacity bei ng reached or exceeded. Guidelines to
be considered when designing appropriate response actions may include the NIST SP 800-92,
Guide to Computer Security Log Management [26]. It should be noted that either overwriting the
oldest audit records or halting audit log generation are possible responses to audit storage capacity
being exceeded but imply the loss of potentially essential forensic information. Also alerting
personnel could be an appropriate supporting action in response to an audit processing failure.
1416
6.12.3
1417
None
1418
6.12.4
1419
The requirements for the four SL levels that relate to CR 2.10 are:
Requirement enhancements
Security levels
1420
SL-C(UC,component) 1: CR 2.10
1421
SL-C(UC,component) 2: CR 2.10
1422
SL-C(UC,component) 3: CR 2.10
1423
SL-C(UC,component) 4: CR 2.10
1424
6.13
CR 2.11
Timestamps
1425
6.13.1
1426
1427
Components shall provide the capability to create timestamps (including date and time) for use in
audit records.
Requirement
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
1391
1392
Requirement enhancements
1428
6.13.2
1429
1430
A good reference for the format of timestamps is ISO/IEC 8601:2004, Data elements and
interchange formats Information interchange Representation of dates and times [15].
1431
6.13.3
1432
(1) Time synchronization
1435
1436
1437
Requirement enhancements
Components shall provide the capability to create timestamps that are synchronized with a
system wide time source.
(2) Protection of time source integrity
The time synchronization mechanism shall provide the capability to detect unautho rized
alteration and cause an audit event upon alteration.
1438
6.13.4
Security levels
1439
The requirements for the four security levels that relate to CR 2.11 are:
1440
SL-C(UC,component) 1: CR 2.11
1441
SL-C(UC,component) 2: CR 2.11
1442
SL-C(UC,component) 3: CR 2.11 (1)
1443
SL-C(UC,component) 4: CR 2.11 (1) (2)
1444
6.14
1445
6.14.1
1446
1447
If a component provides a human user interface, the component shall provide the capability to
determine whether a given human user took a particular action.
1448
1449
Control elements that are not able to support such capability shall be l isted in component
documents.
1450
6.14.2
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
Examples of particular actions taken by a user include performing operator actions, changing
control system configurations, creating information , sending a message, approving information
(such as, indicating concurrence) and receiving a message. Non -repudiation protects against later
false claims by a user of not having taken a specific action, by an author of not having authored a
particular document, by a sender of not having transmitted a message, by a receiver of not having
received a message or by a signatory of not having signed a document. Non -repudiation services
can be used to determine if information originated from a user, if a user took specific actions (for
example, sending an email and approving a work order) or received specific information. Non repudiation services are obtained by employing various techniques or mechanisms (for example,
digital signatures, digital message receipts an d timestamps).
1461
6.14.3
1462
(1) Non-repudiation for all users
1463
1464
CR 2.12
Non-repudiation
Requirement
Rationale and supplemental guidance
Requirement enhancements
Components shall provide the capability to determine whether a given user (human, software
process or device) took a particular action.
1465
6.14.4
Security levels
1466
The requirements for the four SL levels that relate to CR 2.12 are:
1467
SL-C(UC,component) 1: Not selected
1468
SL-C(UC,component) 2: Not selected
1469
SL-C(UC,component) 3: CR 2.12
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
1433
1434
Rationale and supplemental guidance
SL-C(UC,component) 4: CR 2.12 (1)
1471
6.15
CR 2.13
1472
1473
The use of physical diagnostic and test interfaces requirements are device specific and can be
located as requirements for each specific device type in Clauses 12 through 15.
1474
7
1475
7.1
1476
Ensure the integrity of the component to prevent unauthorized manipulation.
FR 3
Use of physical diagnostic and test interfaces
System integrity
Purpose and SL-C(SI) descriptions
1477
SL 1
Protect the integrity of the IACS against casual or coincidental manipulation.
1478
1479
SL 2
Protect the integrity of the IACS against manipulation by someone using simple
means with low resources, generic skills and low motivation.
1480
1481
SL 3
Protect the integrity of the IACS against manipulation by someone using
sophisticated means with moderate resources, IACS specific skills and moderate motivation.
1482
1483
SL 4
Protect the integrity of the IACS against manipulation by someone using
sophisticated means with extended resources, IACS specif ic skills and high motivation.
1484
7.2
Rationale
1485
1486
1487
1488
1489
1490
1491
1492
1493
Components often go through multiple testing cycles (unit testing, system testing, etc.) to establish
that the components will perform as intended before they even begin production. Once operational,
asset owners are responsible for maintaining the integrity of the component. Using their risk
assessment methodology, asset owners may assign different levels of integrity protection to
different systems, communication channels and information in their IACS. The integrit y of physical
assets should be maintained in both operational and non -operational states, such as during
production, when in storage or during a maintenance shutdown. The integrity of logical assets
should be maintained while in transit and at rest, such a s being transmitted over a network or when
residing in a data repository.
1494
7.3
1495
7.3.1
1496
Components shall provide the capability to protect integrity of transmitted information.
1497
7.3.2
1498
1499
1500
1501
1502
1503
1504
Many common network attacks are based on the manipulation of data in transmission, for example
manipulation of network packets. Switched or routed networks provide a greater opportunity for
attackers to manipulate packets as undetected access to these networks is gene rally easier and
the switching and routing mechanisms themselves can also be manipulated in order to get more
access to transmitted information. Manipulation in the context of a control system could include the
change of measurement values communicated from a sensor to a receiver or the alteration of
command parameters sent from a control application to an actuator.
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
Depending on the context (for example transmission within a local network segment versus
transmission via untrusted networks) and the network type used in the transmission (for example
transmission control protocol (TCP) / internet protocol (IP) versus loc al serial links), feasible and
appropriate mechanisms will vary. On a small network with direct links (point -to-point), physical
CR 3.1
Communication integrity
Requirement
Rationale and supplemental guidance
protected as well (see 7.6, CR 3.4 Software and information integrity), while on a network
distributed in areas with regular physical presence of staff or on a wide area network physical
access is likely not enforceable. If a commercial service is used to provide communication
services as a commodity item rather than a fully dedicated service (for example a lea sed line
versus a T1 link), it may be more difficult to obtain the necessary assurances regarding the
implementation of needed security controls for communication integrity (for example because of
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
1470
legal restrictions). When it is infeasible or impractical t o meet the necessary security
requirements it may be appropriate to implement either appropriate compensating
countermeasures or explicitly accept the additional risk.
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
Industrial equipment is often subject to environmental conditions that can lead to inte grity issues
and/or false positive incidents. Many times the environment contains particulates, liquids, vibration,
gases, radiation, and electromagnetic interference (EMI) that can cause conditions that affect the
integrity of the communication wiring and signals. The network infrastructure should be designed
to minimize these physical/environmental effects on communication integrity. For example, when
particulate, liquids, and/or gases are an issue, it may be necessary to use a sealed registered jack
45 (RJ-45) or M12 connector instead of a commercial-grade RJ-45 connector on the wire. The cable
itself may need to use a different jacket instead to handle the particulate, liquid, and/or gas as well.
In cases where vibration is an issue, M12 connectors may b e necessary to prevent the spring pins
on an RJ-45 connector from disconnecting during use. In cases where radiation and/or EMI are an
issue, it may be necessary to use shielded twisted pair or fiber cables to prevent any effect on the
communication signals. It may also be necessary to perform a wireless spectrum analysis in these
areas if wireless networking is planned to verify that it is a viable solution.
1532
7.3.3
1533
(1) Communication authentication
Requirement enhancements
1534
1535
Components shall provide the capability to authenticate information during communication.
NOTE: Communication authentication can be achieved with or without communication confidentiality (encryption).
1536
7.3.4
1537
The requirements for the four SL levels that relate to CR 3.1 are:
Security levels
1538
SL-C(SI, component) 1: CR 3.1
1539
SL-C(SI, component) 2: CR 3.1
1540
SL-C(SI, component) 3: CR 3.1 (1)
1541
SL-C(SI, component) 4: CR 3.1 (1)
1542
7.4
1543
1544
The protection from malicious code requirements are device specific and can be located as
requirements for each specific device type in Clauses 12 through 15.
1545
7.5
1546
7.5.1
1547
1548
Components shall provide the capability to verify the intended operation of security functions
according to ISA 62443 3 3 [11] SR3.3.
1549
7.5.2
1550
1551
1552
1553
1554
The product supplier and/or system integrator should provide guidance on how to test the designed
security controls. Asset owners need to be aware of the possible ramifications of running these
verification tests during normal operations. Details of the execution of these verifications need to
be specified with careful consideration of th e requirements for continuous operations (for example,
scheduling or prior notification).
1555
Examples of security verification functions include:
1556
1557
1558
CR 3.2
CR 3.3
Protection from malicious code
Security functionality verification
Requirement
Rationale and supplemental guidance
Verification of antivirus countermeasures by European Institute for Computer Antivirus
Research (EICAR) testing of the control system file system. Antivirus software should detect
this and appropriate incident handling procedures should be triggered.
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
1516
1517
1518
Verification of the identification, authentication and use control countermeasures by
attempting access with an unauthorized account (for some functionality this could be
automated).
1562
1563
1564
1565
Verification of intrusion detection systems (IDSs) as a security control by including a rule in
the IDS that triggers on irregular, but known non-malicious traffic. The test could then be
performed by introducing traffic that triggers this rule and the appropriate IDS monitoring
and incident handling procedures.
1566
1567
Confirmation that audit logging is occurring as required b y security policies and procedures
and has not been disabled by an internal or external entity.
1568
7.5.3
Requirement enhancements
1569
(1) Security functionality verification during normal operation
1570
Components shall provide the capability to support verification of the intended operation of
1571
security functions during normal operations.
1572NOTE This RE needs to be carefully implemented to avoid detrimental effects. It may not be suitable for safety systems.
1573
7.5.4
Security levels
1574
The requirements for the four SL levels that relate to CR 3.3 are:
1575
SL-C(SI, component) 1: CR 3.3
1576
SL-C(SI, component) 2: CR 3.3
1577
SL-C(SI, component) 3: CR 3.3
1578
SL-C(SI, component) 4: CR 3.3 (1)
1579
7.6
1580
7.6.1
1581
1582
1583
Components shall provide the capability to perform or support integrity checks on software,
configuration and other information as well as the recording and reporting of the results of these
checks or be integrated into a system that can perform or support integrity checks.
1584
7.6.2
1585
1586
1587
1588
1589
1590
1591
1592
Unauthorized changes are changes for which the entity attempting the change does not have the
required privileges. This CR complements related CRs from FRs 1 and 2. FRs 1 and 2 involve
enforcing the roles, privileges and use patterns as designed. Integrit y verification methods are
employed to detect, record, report and protect against software and information tampering that may
occur if other protection mechanisms (such as authorization enforcement) have been circumvented.
The control system should employ formal or recommended integrity mechanisms (such as
cryptographic hashes). For example, such mechanisms could be used to monitor field devices for
their latest configuration information to detect security breaches (including unauthorized changes).
1593
7.6.3
1594
(1) Authenticity of software and information
1595
1596
1597
1598
1599
1600
1601
CR 3.4
Software and information integrity
Requirement
Rationale and supplemental guidance
Requirement enhancements
Components shall provide the capability to perform or support authenticity checks on software,
configuration and other information as well as the recording and reporting of the results of these
checks or be integrated into a system that can perform or support authenticity checks.
(2) Automated notification of integrity violations
If the component is performing the integrity check, it shall be capable of automatically providing
notification to a configurable entity upon discovery of an attempt to make an unauthorized
change.
1602
7.6.4
Security levels
1603
The requirements for the four SL levels that relate to CR 3.4 are:
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
1559
1560
1561
SL-C(SI, component) 1: Not Selected
1605
SL-C(SI, component) 2: CR 3.4 (1)
1606
SL-C(SI, component) 3: CR 3.4 (1) (2)
1607
SL-C(SI, component) 4: CR 3.4 (1) (2)
1608
7.7
CR 3.5
Input validation
1609
7.7.1
1610
1611
Components shall validate the syntax and content of any input that is used as an industrial process
control input or input via external interfaces that directly impacts the action of the component.
1612
7.7.2
1613
1614
1615
1616
1617
Rules for checking the valid syntax of input data such as set points should be in place to verify that
this information has not been tampered with and is compliant with the specification. Inputs passed
to interpreters should be pre-screened to prevent the content from being unintentionally interpreted
as commands. Note that this is a security CR, thus it does not address human error, for example
supplying a legitimate integer number which is outside the expected range.
1618
1619
1620
1621
1622
1623
Generally accepted industry practices for input data validation include out -of-range values for a
defined field type, invalid characters in data fields, missing or incomplete data and buffer overflow.
Additional examples where invalid inputs lead to system security issues include SQL injection
attacks, cross-site scripting or malformed packets (as commonly generated by protoco l fuzzers).
Guidelines to be considered should include well-known guidelines such as the Open Web
Application Security Project (OWASP) Code Review Guide [28].
1624
7.7.3
1625
None
1626
7.7.4
1627
The requirements for the four SL levels that relate to CR 3.5 are:
Requirement
Rationale and supplemental guidance
Requirement enhancements
Security levels
1628
SL-C(SI, component) 1: CR 3.5
1629
SL-C(SI, component) 2: CR 3.5
1630
SL-C(SI, component) 3: CR 3.5
1631
SL-C(SI, component) 4: CR 3.5
1632
7.8
CR 3.6
Deterministic output
1633
7.8.1
1634
1635
Components that directly control a process shall provide the capability to set outputs to a
predetermined state if normal operation cannot be maintained as a result of an attack.
1636
7.8.2
1637
1638
1639
1640
1641
1642
The deterministic behavior of control system outputs as a result of threat actions against the control
system devices and software is an important characteristic to ensure the integrity of normal
operations. Ideally, the device continues to operate normally while under attack, but if the control
system cannot maintain normal operation, then the control system outputs need to fail to a
predetermined state. The appropriate predetermined state of contro l system outputs is device
dependent and could be one of the following user configurable options:
Requirement
Rationale and supplemental guidance
1643
Unpowered
1644
Hold
the outputs fail to the unpowered state ;
the outputs fail to the last-known good value; or
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
1604
1645
1646
Fixed
the outputs fail to a fixed value that is determined by the asset owner or an
application; or
1647
Dynamic
the outputs fail to one of the above options based on the current state.
7.8.3
Requirement enhancements
1649
None
1650
7.8.4
1651
The requirements for the four SL levels that relate to CR 3.6 are:
Security levels
1652
SL-C(SI, component) 1: CR 3.6
1653
SL-C(SI, component) 2: CR 3.6
1654
SL-C(SI, component) 3: CR 3.6
1655
SL-C(SI, component) 4: CR 3.6
1656
7.9
CR 3.7
Error handling
1657
7.9.1
1658
1659
1660
1661
Components shall identify and handle error conditions in a manner such that effective remediation
can occur. This shall be done in a manner that does not provide information that could be exploited
by adversaries to attack the IACS unless revealing this information is necessary for the timely
troubleshooting of problems.
1662
7.9.2
1663
1664
1665
1666
1667
1668
The product supplier and/or system integrator should carefully consider the structure and content
of error messages. Error messages generated by the component should provide timely and useful
information without revealing potentially harmful information that could be used by adversaries to
exploit the IACS. Disclosure of this information should be justified by the necessity for timely
resolution of error conditions. Guidelines to be considered could include well-known guidelines
such as the OWASP Code Review Guide.
1669
1670
1671
NOTE: A good example of an error message that could help adversaries attack an IACS would be to provide details of
why authentication with the system failed. For example stating invalid user or invalid password in the feedback
would help an adversary attack the IACS and thus should not be provided.
1672
7.9.3
1673
None
1674
7.9.4
1675
The requirements for the four SL levels that relate to CR 3. 7 are:
Requirement
Rationale and supplemental guidance
Requirement enhancements
Security levels
1676
SL-C(SI, component) 1: CR 3.7
1677
SL-C(SI, component) 2: CR 3.7
1678
SL-C(SI, component) 3: CR 3.7
1679
SL-C(SI, component) 4: CR 3.7
1680
7.10
CR 3.8
Session integrity
1681
7.10.1
1682
Components shall provide mechanisms to protect the integrity of communications sessions.
1683
7.10.2
1684
1685
1686
This control focuses on communications protection at the session, versus packet, level. The intent
of this control is to establish grounds for confidence at each end of a communications session in
the ongoing identity of the other party and in the validity of the information being transmitted. For
Requirement
Rationale and supplemental guidance
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
1648
1687
1688
1689
1690
example, this control addresses man-in-the-middle attacks including session hijacking, insertion of
false information into a session or replay attacks. Use of session integrity mechanisms can have a
significant overhead and therefore their use should be co nsidered in light of requirements for realtime communications.
1691
7.10.3
1692
(1) Invalidation of session IDs after session termination
1695
1696
1697
1698
Components shall provide the capability to invalidate session identifiers upon user logout or
other session termination (including browser sessions).
(2) Unique session ID generation
Components shall provide the capability to generate a unique session identifier for each session
and recognize only session identifiers that are system -generated.
(3) Randomness of session IDs
1699
Components shall provide the capability to generate unique session identifiers with commonly
1700
accepted sources of randomness.
1701NOTE Session hijacking and other man-in-the-middle attacks or injections of false information often take advantage of easy 1702
to-guess session IDs (keys or other shared secrets) or use of session IDs that were not properly invalidated after
1703
session termination. Therefore the validity of a session authenticator should be tightly connected to the lifetime of a
1704
session. Employing randomness in the generation of unique session IDs helps to protect against brute -force attacks
1705
to determine future session IDs.
1706
7.10.4
Security levels
1707
The requirements for the four SL levels that relate to CR 3.8 are:
1708
SL-C(SI, component) 1: Not selected
1709
SL-C(SI, component) 2: CR 3.8
1710
SL-C(SI, component) 3: CR 3.8 (1) (2)
1711
SL-C(SI, component) 4: CR 3.8 (1) (2) (3)
1712
7.11
1713
7.11.1
1714
1715
Components shall protect audit information and audit tools (if present) from unauthorized access,
modification and deletion.
1716
7.11.2
1717
1718
1719
1720
1721
Audit information includes all information (for example, audit records, audit settings and audit
reports) needed to successfully audit control system activity. The audit information is important for
error correction, security breach recovery, investigations and related efforts. Mechanisms for
enhanced protection against modification and deletion include the s torage of audit information to
hardware-enforced write-once media.
1722
7.11.3
1723
(1) Audit records on write-once media
1724
1725
CR 3.9
Protection of audit information
Requirement
Rationale and supplemental guidance
Requirement enhancements
Host devices shall provide the capability to store audit records on hardware -enforced writeonce media.
1726
7.11.4
Security levels
1727
The requirements for the four SL levels that relate to CR 3. 9 are:
1728
SL-C(SI, component) 1: Not selected
1729
SL-C(SI, component) 2: CR 3.9
1730
SL-C(SI, component) 3: CR 3.9
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
1693
1694
Requirement enhancements
1731
SL-C(SI, component) 4: CR 3.9 (1)
1732
7.12
CR 3.10
Support for updates
1734
1735
The support for updates requirements are device specific and can be located as requirements for
each specific device type in Clauses 12 through 15.
1736
7.13
1737
1738
The physical tamper resistance and detection requirements are device specific and can be located
as requirements for each specific device type in Clauses 12 through 15.
1739
7.14
1740
1741
The provisioning product supplier roots of trust requirements are device specific and can be located
as requirements for each specific device type in Clauses 12 through 15.
1742
7.15
1743
1744
The provisioning asset owner roots of trust requirements are device specific and can be located as
requirements for each specific device type in Clauses 12 through 15.
1745
7.16
1746
1747
The integrity of the boot process requirements are device specific and can be located as
requirements for each specific device type in Clauses 12 through 15.
1748
8
1749
8.1
1750
1751
Ensure the confidentiality of information on communication channels and in data repositories to
prevent unauthorized disclosure.
1752
1753
SL 1
Prevent the unauthorized disclosure of information via eavesdropping or casual
exposure.
1754
1755
SL 2 Prevent the unauthorized disclosure of information to an entity actively searching for
it using simple means with low resources, generic skills and low motivation.
1756
1757
1758
SL 3 Prevent the unauthorized disclosure of information to an entity actively searching for
it using sophisticated means with moderate resources, IACS specific skills and moderate
motivation.
1759
1760
1761
SL 4 Prevent the unauthorized disclosure of information to an entity actively searching for
it using sophisticated means with extended resources, IACS specific skills and high
motivation.
CR 3.11
Physical tamper resistance and detection
CR 3.12
Provisioning product supplier roots of trust
CR 3.13
Provisioning asset owner roots of trust
CR 3.14
FR 4
Integrity of the boot process
Data confidentiality
Purpose and SL-C(DC) descriptions
1762
8.2
1763
1764
1765
Some component-generated information, whether at rest or in transit, is of a confi dential or
sensitive nature. This implies that some communication channels and datastores require protection
against eavesdropping and unauthorized access.
1766
8.3
1767
8.3.1
1768
Components shall
1769
1770
Rationale
CR 4.1
Information confidentiality
Requirement
a) provide the capability to protect the confidentiality of information at rest for which explicit
read authorization is supported; and
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
1733
b) support the protection of the confidentiality of information in transit as defined in
ISA 62443 3 3 [11] SR 4.1.
1773
8.3.2
Rationale and supplemental guidance
1774
1775
1776
1777
1778
1779
The decision whether a given information should be protected or not depends on the context and
cannot be made at product design. However, the fact that an organization limits access to
information by configuring explicit read authorizations in the control system is an indicator that this
information should be protected by the organization. Thus, all information for which the component
supports the capability to assign explicit read authorizations should be considered potentially
sensitive and thus the component should also provide the capability to protect its confidentiality.
1780
1781
Confidentiality of information in transit requir es system level capabilities which the component
needs to be able to support.
1782
For confidentiality protection, 8.5 CR 4.3
1783
8.3.3
1784
None
1785
8.3.4
1786
The requirements for the four SL levels that relate to CR 4.1 are:
Use of cryptography provides further requirements.
Requirement enhancements
Security levels
1787
SL-C(DC, component) 1: CR 4.1
1788
SL-C(DC, component) 2: CR 4.1
1789
SL-C(DC, component) 3: CR 4.1
1790
SL-C(DC, component) 4: CR 4.1
1791
8.4
CR 4.2
Information persistence
1792
8.4.1
1793
1794
1795
Components shall provide the capability to erase all information, for which explicit read
authorization is supported, from components to be released from active service and/or
decommissioned.
1796
8.4.2
1797
1798
1799
1800
1801
Removal of a control system component from active service should not provide the opportunity for
unintentional release of information for which explicit read authorization is supported. An example
of
(in the case of some wireless field devices) stored in
non-volatile storage or other cryptographic information that would facilitate unauthorized or
malicious activity.
1802
1803
1804
1805
1806
Information produced by the actions of a user or role (or the actions of a software process acting
on behalf of a user or role) should not be disclosed to a different user or role in an uncontrolled
fashion. Control of control system information or data persistence prevents information stored on
a shared resource from being unintentionally disclosed after that resource has been released back
to the control system.
1807
8.4.3
1808
(1) Erase of shared memory resources
Requirement
Rationale and supplemental guidance
Requirement enhancements
1809
Components shall provide the capability to prevent unauthorized and unintended information
1810
transfer via volatile shared memory resources.
1811NOTE Volatile memory resources are those that generally do not retain information after being released to memory
1812
management. However, there are attacks against random access memory (RAM) which might extract key material
1813
or other confidential data before it is actually over -written. Therefore, when volatile shared memory is released back
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
1771
1772
1814
1815
(2) Erase verification
1817
Components shall provide the capability to verify that the erasure of information occurred.
1818
8.4.4
Security levels
1819
The requirements for the four SL levels that relate to CR 4.2 are:
1820
SL-C(DC, component) 1: Not Selected
1821
SL-C(DC, component) 2: CR 4.2
1822
SL-C(DC, component) 3: CR 4.2 (1) (2)
1823
SL-C(DC, component) 4: CR 4.2 (1) (2)
1824
8.5
CR 4.3
Use of cryptography
1825
8.5.1
1826
1827
If cryptography is required, the component shall use cryptographic security mechanisms according
to internationally recognized and proven security practices and re commendations.
1828
8.5.2
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
The selection of cryptographic protection should match the value of the information being protected,
the consequences of the confidentiality of the information being breached, the time period during
which the information is confidential and control system operating constraints. This can involve
either information at rest, in transit, or both. Note that backups are an example of information at
rest, and should be considered as part of a data confidentiality assessment process. The control
system product supplier should document the practices and procedures relating to cryptographic
key establishment and management. The control system should utilize established and tested
encryption and hash algorithms, such as the advanced encryption standard (AES) and the secure
hash algorithm (SHA) series, and key sizes based on an assigned standard. Key generation needs
to be performed using an effective random number generator. The security policies and procedures
for key management need to address periodic key changes, key destruction, key distribution and
encryption key backup in accordance with defined standards. Generally accepted practices and
recommendations can be found in documents such as NIST SP 800-57, Recommendation for Key
Management, Part 1: General [25]. Implementation requirements can be found for example in FIPS
140-2, Security Requirements for Cryptographic Modules [24] or ISO/IEC 19790:2012, Information
technology Security techniques Security requirements for cryptographic modules [17].
1845
1846
This CR, along with 5.10, CR 1.8 Public key infrastructure certificates may be applicable when
meeting many other requirements defined within this standard.
1847
8.5.3
1848
None
1849
8.5.4
1850
The requirements for the four security levels that relate to CR 4.3 are:
Requirement
Rationale and supplemental guidance
Requirement enhancements
Security levels
1851
SL-C(DC,component) 1: CR 4.3
1852
SL-C(DC,component) 2: CR 4.3
1853
SL-C(DC,component) 3: CR 4.3
1854
SL-C(DC,component) 4: CR 4.3
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
1816
to the control system for use by a different user, all unique data and connections to unique data need to be purged
from the resource so it is not visible or accessible to the new user.
1855
9
FR 5
Restricted data flow
1856
9.1
1857
Segment the control system via zones and conduits to limit the unnecessary flow of data.
1858
SL 1
Prevent the casual or coincidental circumvention of zone and conduit segmentation.
1859
1860
SL 2 Prevent the intended circumvention of zone and conduit segmentation by entities
using simple means with low resources, generic s kills and low motivation.
1861
1862
1863
SL 3 Prevent the intended circumvention of zone and conduit segmentation by entities
using sophisticated means with moderate resources, IACS specific skills and moderate
motivation.
1864
1865
1866
SL 4 Prevent the intended circumvention of zone and conduit segmentation by entities
using sophisticated means with extended resources, IACS specific skills and high
motivation.
1867
9.2
Rationale
1868
1869
1870
1871
1872
1873
Using their risk assessment methodology defined in ISA 62443 3 2, asset owners need to
determine necessary information flow restrictions and thus, by extension, determine the
configuration of the conduits used to deliver this information. Derived prescriptive
recommendations and guidelines should include mechanisms that range from disconnecting control
system networks from business or public networks to using unidirectional gateways, stateful
firewalls and DMZs to manage the flow of information.
1874
9.3
1875
9.3.1
1876
1877
Components shall support a segmented network as defined in ISA 62443 3 2 [10], as needed, to
support the broader network architecture based on logical segm entation and criticality.
1878
9.3.2
1879
None
1880
9.3.3
1881
None
1882
9.3.4
1883
The requirements for the four SL levels that relate to CR 5.1 are:
CR 5.1
Network segmentation
Requirement
Rationale and supplemental guidance
Requirement enhancements
Security levels
1884
SL-C(RDF, component) 1: CR 5.1
1885
SL-C(RDF, component) 2: CR 5.1
1886
SL-C(RDF, component) 3: CR 5.1
1887
SL-C(RDF, component) 4: CR 5.1
1888
9.4
CR 5.2
1889
1890
The zone boundary protection requirements are network device specific and can be located as
requirements for network devices in Clause 15.
1891
9.5
1892
1893
The general purpose person-to-person communication restriction requirements are network device
specific and can be located as requirements for network devices later in Clause 15.
CR 5.3
Zone boundary protection
General purpose person-to-person communication restrictions
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
Purpose and SL-C(RDF) descriptions
1894
10 FR 6
Timely response to events
1895
10.1
1896
1897
Respond to security violations by notifying the proper authority, reporting needed evidence of the
violation and taking timely corrective action when incidents are discover ed.
1898
1899
SL 1 Monitor the operation of the IACS, and respond to incidents when discovered , by
collecting and providing the forensic evidence when queried.
1900
1901
SL 2 Monitor the operation of the IACS, and respond to incidents when discovered , by
actively collecting and periodically reporting forensic evidence.
1902
1903
SL 3 Monitor the operation of the IACS, and respond to incidents when discovered , by
actively collecting and pushing forensic evidence to the proper authority.
1904
1905
SL 4 Monitor the operation of the IACS, and respond to incidents when discovered, by
actively collecting and pushing forensic evidence to the proper authority in near real -time.
1906
10.2
1907
1908
1909
1910
1911
1912
Using their risk assessment methodology, asset owners should establish security policies and
procedures and proper lines of communication and control needed to respond to security violations.
Derived prescriptive recommendations and guidelines should include mechanisms that collect,
report, preserve and automatically correlate the forensic evidence to ensure tim ely corrective
action. The use of monitoring tools and techniques should not adversely affect the operational
performance of the control system.
1913
10.3
1914
10.3.1
1915
1916
Components shall provide the capability for authorized humans and/ or tools to access audit logs
on a read-only basis.
1917
10.3.2
1918
1919
1920
1921
1922
1923
1924
1925
1926
The applications and devices may generate audit records about events occurring in that application
or device (see 6.10). Access to these audit logs is necessary to support filtering audit logs,
identifying and removing information that is redundant, reviewing and reporting activity during after the-fact investigations of security incidents. In general, audit reduction and report generation should
be performed on a separate information system. Manual access to the audit records (such as ,
screen views or printouts) is sufficient for meeting the base requirement, but is insufficient for
higher SLs. Programmatic access is commonly used to provide the audit log information to analysis
mechanisms such as security information and event management ( SIEM). See relevant SRs in
Clauses 5, 6 and 9 regarding the creation of, protection of and access to audit logs.
1927
10.3.3
1928
(1) Programmatic access to audit logs
1929
1930
Rationale
CR 6.1
Audit log accessibility
Requirement
Rationale and supplemental guidance
Requirement enhancements
Components shall provide programmatic access to audit records by either using an application
programming interface (API) or sending the audit logs to a cen tralized system
1931
10.3.4
Security levels
1932
The requirements for the four SL levels that relate to CR 6.1 are:
1933
SL-C(TRE, component) 1: CR 6.1
1934
SL-C(TRE, component) 2: CR 6.1
1935
SL-C(TRE, component) 3: CR 6.1 (1)
1936
SL-C(TRE, component) 4: CR 6.1 (1)
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
Purpose and SL-C(TRE) descriptions
1937
10.4
CR 6.2
Continuous monitoring
1938
10.4.1
1939
1940
1941
When a component provides a security mechanism, that component shall provide the capability to
be continuously monitored using commonly accepted security industry practices and
recommendations to detect, characterize and report secur ity breached in a timely manner.
1942
10.4.2
1943
1944
1945
1946
1947
Control system monitoring capability can be achieved through a variety of tools and techniques (for
example, IDS, intrusion prevention system (IPS), protection from malicious code mechanisms and
network monitoring mechanisms). As attacks become more sophisticated, these monitoring tools
and techniques will need to become more sophisticated as well, including for example behavior based IDS/IPS.
1948
1949
1950
1951
Monitoring devices should be strategically deployed within the control system (for example, at
selected perimeter locations and near server farms supporting critical applications) to collect
essential information. Monitoring mechanisms may also be deployed at ad hoc locations within the
control system to track specific transactions.
1952
1953
1954
1955
1956
Monitoring should include appropriate reporting mechanisms to allow for a timely response to
events. To keep the reporting focused and the amount of reported information to a level that can
be processed by the recipients, mechanisms such as SIEM are commonly applied to correlate
individual events into aggregate reports that establish a larger context in which the raw events
occurred.
1957
10.4.3
1958
None
1959
10.4.4
1960
The requirements for the four SL levels that relate to CR 6.2 are:
Rationale and supplemental guidance
Requirement enhancements
Security levels
1961
SL-C(TRE, component) 1: Not Selected
1962
SL-C(TRE, component) 2: CR 6.2
1963
SL-C(TRE, component) 3: CR 6.2
1964
SL-C(TRE, component) 4: CR 6.2
1965
11 FR 7
Resource availability
1966
11.1
1967
1968
Ensure the availability of the application or device against the degradation or denial of essential
services.
1969
1970
1971
SL 1 Ensure that the control system operates reliably under normal production conditions
and prevents denial-of-service situations caused by the casual or coincidental actions of an
entity.
1972
1973
1974
SL 2
Ensure that the control system operates reliably under normal and abnormal
production conditions and prevents denial-of-service situations by entities using simple
means with low resources, generic skills and low motivation.
1975
1976
1977
SL 3
Ensure that the control system operates reliably under normal, abnormal, and
extreme production conditions and prevents denial -of-service situations by entities using
sophisticated means with moderate resources, IACS specific skills and moderate motivation.
Purpose and SL-C(RA) descriptions
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
Requirement
SL 4
Ensure that the control system operates reliably under normal, abnormal, and
extreme production conditions and prevents denial -of-service situations by entities using
sophisticated means with extended resources, IACS specific skills and high motivat ion.
1981
11.2
1982
1983
1984
1985
The aim of this series of CRs is to ensure that the component is resilient against various types of
DoS events. This includes the partial or total unavailability of component functionality at various
levels. In particular, security incidents in the component should not affect the essential functions
of SIS or other safety-related functions.
1986
11.3
1987
11.3.1
1988
1989
Components shall provide the capability to maintain essential functions in a degraded mode during
a DoS event.
1990
11.3.2
1991
1992
1993
Components may be subjected to different forms of DoS situations. When these occur the
component should be designed in such a manner that it maintains essential functions necessary
for continued safe operations while in a degraded mode.
1994
11.3.3
1995
(1) Manage communication load from component
1996
1997
Rationale
CR 7.1
Denial of service protection
Requirement
Rationale and supplemental guidance
Requirement enhancements
Components shall provide the capability to manage communication loads (such as using rate
limiting) to mitigate the effects of information and/or message flooding types of DoS events.
1998
11.3.4
Security levels
1999
The requirements for the four SL levels that relate to CR 7.1 are:
2000
SL-C(RA, component) 1: CR 7.1
2001
SL-C(RA, component) 2: CR 7.1 (1)
2002
SL-C(RA, component) 3: CR 7.1 (1)
2003
SL-C(RA, component) 4: CR 7.1 (1)
2004
11.4
2005
11.4.1
2006
2007
Components shall provide the capability to limit the use of resources by security functions to
prevent resource exhaustion.
2008
11.4.2
2009
2010
2011
2012
2013
Resource management (for example, network segmentation or priori ty schemes) prevents a lowerpriority software process from delaying or interfering with the control system servicing any higher priority software process. For example, initiating network scans, patching and/or antivirus checks
on an operating system can cause severe disruption to normal operations. Traffic rate limiting
schemes should be considered as a mitigation technique.
2014
11.4.3
2015
None
2016
11.4.4
2017
The requirements for the four SL levels that relate to CR 7.2 are:
2018
CR 7.2
Resource management
Requirement
Rationale and supplemental guidance
Requirement enhancements
Security levels
SL-C(RA, component) 1: CR 7.2
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
1978
1979
1980
2019
SL-C(RA, component) 2: CR 7.2
2020
SL-C(RA, component) 3: CR 7.2
2021
SL-C(RA, component) 4: CR 7.2
11.5
2023
11.5.1
2024
2025
2026
Components shall provide the capability to participate in system level backup operations in order
to safeguard the component state (user- and system-level information). The backup process shall
not affect the normal component operations.
2027
11.5.2
2028
2029
2030
The availability of up-to-date backups is essential for recovery from a control system failure and/or
mis-configuration. Automating this function ensures that all required files are captured, reducing
operator overhead.
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
When designing to support a backup capability, consideration should be given to information that
will be stored in backups. Some of this information may contain personally identifiable information
(PII), cryptographic keys and other information that is protected through security controls while part
of the system. Once the information is placed into a backup it most like ly will not have the same
controls in place to protect it. Thus the component backup ability needs to include the mechanisms
to support the necessary protection of the information that is contained in the backup . This may
include encryption of the backup, encryption of the sensitive data as part of the backup procedure
or not including the sensitive information as part of the backup . If the backup is encrypted it is
important not to include the cryptographic keys as part of the backup but to backup the
cryptographic keys as part of a separate more secure backup procedure.
2041
11.5.3
2042
(1) Backup integrity verification
2043
2044
2045
2046
2047
CR 7.3
Control system backup
Requirement
Rationale and supplemental guidance
Requirement enhancements
Components shall provide the capability to validate the integrity of backed up information prior
to the initiation of a restore of that information.
(2) Local backup
Components shall provide the capability to perform a local backup independent of system
functionality.
2048
11.5.4
Security levels
2049
The requirements for the four SL levels that relate to CR 7.3 are:
2050
SL-C(RA, component) 1: CR 7.3
2051
SL-C(RA, component) 2: CR 7.3 (1)
2052
SL-C(RA, component) 3: CR 7.3 (1) (2)
2053
SL-C(RA, component) 4: CR 7.3 (1) (2)
2054
11.6
CR 7.4
Control system recovery and reconstitution
2055
11.6.1
2056
2057
Components shall provide the capability to recover and reconstitute to a known secure state after
a disruption or failure.
2058
11.6.2
2059
2060
2061
2062
Control system recovery and reconstitution to a known secure state means that all system
parameters (either default or configurable) are set to secure values, security-critical patches are
reinstalled, security-related configuration settings are reestablished, system documentation and
operating procedures are available, components are reinstalled and configured with estab lished
Requirement
Rationale and supplemental guidance
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
2022
2063
2064
settings, information from the most recent, known secure backups is loaded and the system is fully
tested and functional.
2065
11.6.3
2066
None
2067
11.6.4
2068
The requirements for the four SL levels that relate to CR 7.4 are:
Security levels
2069
SL-C(RA, component) 1: CR 7.4
2070
SL-C(RA, component) 2: CR 7.4
2071
SL-C(RA, component) 3: CR 7.4
2072
SL-C(RA, component) 4: CR 7.4
2073
11.7
2074
11.7.1
2075
2076
2077
2078
Components shall provide the capability to be configured according to recommended network and
security configurations as described in guidelines provided by the control system supplier. The
component shall provide an interface to the currently deployed network and securit y configuration
settings.
2079
11.7.2
2080
2081
2082
2083
2084
These configuration settings are the adjustable parameters of the control system components . By
default the component should be configured to the recommended settings . In order for a component
to detect and correct any deviations from the approved and/or recommended configuration settings,
the component needs to support monitoring and control of changes to the configuration settings in
accordance with security policies and procedures.
2085
11.7.3
2086
(1) Machine-readable reporting of current security settings
2087
2088
CR 7.6
Network and security configuration settings
Requirement
Rationale and supplemental guidance
Requirement enhancements
Components shall provide the capability to generate a report listing the currently deployed
security settings in a machine-readable format.
2089
11.7.4
Security levels
2090
The requirements for the four SL levels that relate to CR 7.6 are:
2091
SL-C(RA, component) 1: CR 7.6
2092
SL-C(RA, component) 2: CR 7.6
2093
SL-C(RA, component) 3: CR 7.6 (1)
2094
SL-C(RA, component) 4: CR 7.6 (1)
2095
11.8
CR 7.7
Least functionality
2096
11.8.1
2097
2098
Components shall provide the capability to specifically restrict the use of unnecessary functions,
ports, protocols and/or services.
2099
11.8.2
2100
2101
2102
2103
2104
Applications and devices are capable of providing a wide variety of functions and services. Some
of the functions and services provided may not be necessary to support IACS functionality.
Therefore, by default, functions beyond a baseline configuration should be disabled. Additionally,
it is sometimes convenient to provide multiple services from a single co mponent of a control system,
but doing so increases the risk compared to limiting the services provided by any one component.
Requirement
Rationale and supplemental guidance
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
Requirement enhancements
2105
11.8.3
Requirement enhancements
2106
None
2107
11.8.4
2108
The requirements for the four SL levels that relate to CR 7.7 are:
2109
SL-C(RA, component) 1: CR 7.7
2110
SL-C(RA, component) 2: CR 7.7
2111
SL-C(RA, component) 3: CR 7.7
2112
SL-C(RA, component) 4: CR 7.7
2113
11.9
CR 7.8
Control system component inventory
2114
11.9.1
2115
2116
Components shall provide the capability to support a control system component inventory according
to ISA 62443 3 3 [11] SR 7.8.
2117
11.9.2
2118
2119
2120
Applications and devices may bring their own set of components into the overall control system .
When this is the case then those applications and devices need to provide a mechanism to augment
the overall component inventory which is compatible with ISA 62443 2 4 [8] SP.06.02.
2121
11.9.3
2122
None
2123
11.9.4
2124
The requirements for the four SL levels that relate to CR 7.8 are:
Requirement
Rationale and supplemental guidance
Requirement enhancements
Security levels
2125
SL-C(RA, component) 1: Not Selected
2126
SL-C(RA, component) 2: CR 7.8
2127
SL-C(RA, component) 3: CR 7.8
2128
SL-C(RA, component) 4: CR 7.8
2129
12 Software application requirements
2130
12.1
2131
2132
The purpose of this set of requirements is to document requirements that are specific to software
applications.
2133
12.2
2134
12.2.1
2135
2136
2137
2138
In the event that a software application utilizes mobile code technologies , that application shall
provide the capability to enforce a security policy for the usage of mobile code technologies. The
security policy must allow, at a minimum, the following a ctions for each mobile code technology
used on the software application:
Purpose
SAR 2.4
Mobile code
Requirement
2139
a) Control execution of mobile code;
2140
2141
b) Define which users (human, software process, or device) are allowed to transfer mobile
code to/from the application;
2142
c) Perform integrity checks on mobile code prior to the code being executed; and
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
Security levels
d) Perform authenticity checks to verify the origin of the mobile code prior to the code being
executed.
2145
12.2.2
2146
2147
2148
2149
2150
2151
2152
2153
Mobile code technologies include, but are not limited to, Java, JavaScript, ActiveX, portable
document format (PDF), Postscript, Shockwave movies, Flash animations and VBScript. Usage
restrictions apply to both the selection and use of mobile code installe d on servers and mobile code
downloaded and executed on individual workstations. Control procedures should prevent the
development, acquisition or introduction of unacceptable mobile code within the control system in
which the component resides. For example, mobile code exchanges may be disallowed directly
within the control system, but may be allowed in a controlled adjacent environment maintained by
IACS personnel.
2154
12.2.3
2155
(1) Mobile code integrity check
2156
2157
Rationale and supplemental guidance
Requirement enhancements
The application shall provide the capability to verify the integrity of the mobile code before
allowing code execution.
2158
12.2.4
Security levels
2159
The requirements for the four SL levels that relate to SAR 2.4 are:
2160
SL-C(UC, component) 1: SAR 2.4
2161
SL-C(UC, component) 2: SAR 2.4
2162
SL-C(UC, component) 3: SAR 2.4 (1)
2163
SL-C(UC, component) 4: SAR 2.4 (1)
2164
12.3
SAR 3.2
Protection from malicious code
2165
12.3.1
2166
2167
The application product supplier shall qualify and document which protection from malicious code
mechanisms are compatible with the application and note any special configuration requirements.
2168
12.3.2
2169
2170
2171
The control system application itself may not perform malicious code (for example, viruses, worms,
Trojan horses and spyware) protection. However, control system applications need to be
compatible with mechanisms designed to protect it from malicious code.
2172
12.3.3
2173
None
2174
12.3.4
2175
The requirements for the four SL levels that relate to SAR 3.2 are:
Requirement
Rationale and supplemental guidance
Requirement enhancements
Security levels
2176
SL-C(SI, component) 1: SAR 3.2
2177
SL-C(SI, component) 2: SAR 3.2
2178
SL-C(SI, component) 3: SAR 3.2
2179
SL-C(SI, component) 4: SAR 3.2
2180
13 Embedded device requirements
2181
13.1
2182
2183
The purpose of this set of requirements is to document requirements that are specific to embedded
devices.
Purpose
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
2143
2144
2184
13.2
EDR 2.4
Mobile code
2185
13.2.1
2186
2187
2188
2189
In the event that an embedded device utilizes mobile code technologies , the embedded device shall
provide the capability to enforce a security policy for the usage of mobile code technologies. The
security policy must allow, at a minimum, the following actions for each mob ile code technology
used on the embedded device:
2190
a) Control execution of mobile code;
2191
2192
b) Define which users (human, software process, or device) are allowed to upload mobile code
to the device;
2193
c) Perform integrity checks on mobile code prior to the code being exec uted; and
2194
2195
d) Perform authenticity checks to verify the origin of the mobile code prior to the code being
executed.
2196
13.2.2
2197
2198
2199
2200
2201
2202
2203
Mobile code technologies include, but are not limited to, Java, JavaScript, ActiveX, PDF, Postscript,
Shockwave movies, Flash animations and VBScript. Usage restrictions apply to both the selection
and use of mobile code installed on servers and mobile code downloaded and executed on
individual workstations. Control procedures should prevent the development, ac quisition or
introduction of unacceptable mobile code within the control system in which the component resides.
For example, mobile code exchanges may be disallowed directly with in the control system, but may
be allowed in a controlled adjacent environment maintained by IACS personnel.
2204
13.2.3
2205
(1) Mobile code integrity check
2206
2207
Rationale and supplemental guidance
Requirement enhancements
The embedded device shall provide the capability to verify the integrity of the mobile code
before allowing code execution.
2208
13.2.4
Security levels
2209
The requirements for the four SL levels that relate to EDR 2.4 are:
2210
SL-C(UC, component) 1: EDR 2.4
2211
SL-C(UC, component) 2: EDR 2.4
2212
SL-C(UC, component) 3: EDR 2.4 (1)
2213
SL-C(UC, component) 4: EDR 2.4 (1)
2214
13.3
EDR 2.13
Use of physical diagnostic and test interfaces
2215
13.3.1
2216
2217
Embedded devices shall prevent unauthorized use of the physical factory diagnostic and test
interface(s) (e.g. JTAG).
2218
13.3.2
2219
2220
2221
2222
2223
Factory diagnostic and test interface(s) are created at various locations within the component to
2224
2225
2226
There may be cases where the factory diagnostic and test interface(s) use network communi cations
with the device. When this is the case those interfaces are to be subjected to all of the requirements
of this standard.
Requirement
Rationale and supplemental guidance
implementation, and when errors are discovered to subsequently remove them from the component.
However, these same interfaces must be carefully protected from access by unauthorized entities
to protect the essential functionality provided by the component to the IACS.
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
Requirement
2227
13.3.3
2228
(1) Active monitoring
Embedded devices shall provide active monitoring of the
diagnostic and test
interface(s) and generate a log entry when attempts to access these interface(s) are detected.
2231
13.3.4
Security levels
2232
The requirements for the four SL levels that relate to EDR 2.13 are:
2233
SL-C(SI, component) 1: Not Selected
2234
SL-C(SI, component) 2: EDR 2.13
2235
SL-C(SI, component) 3: EDR 2.13 (1)
2236
SL-C(SI, component) 3: EDR 2.13 (1)
2237
13.4
EDR 3.2
Protection from malicious code
2238
13.4.1
2239
2240
The embedded device shall provide the capability to protect from installation, execution of malicious
code or unauthorized software.
2241
13.4.2
2242
2243
2244
2245
If an embedded device is able to utilize a compensating control, it need not directly support
protection from malicious code. It is assumed that the IACS will be responsible for providing the
required safeguards. However, for scenarios such as having a local universal serial bus (USB) host
access, the need for protection from malicious code should be determined by a risk assessment.
2246
2247
2248
Detection mechanisms should be able to detect integrity violations of application binaries and data
files. Techniques may include, but are not limited to, binary integrity and attributes monitoring,
hashing and signature techniques.
2249
2250
2251
2252
2253
Prevention techniques may include, but are not limited to, removable media control, sandbox
techniques and specific computing platforms mechanisms such as restricted firmware update
capabilities, No Execute (NX) bit, data execution prevention (DEP), addres s space layout
randomization (ASLR), stack corruption detection and mandatory access controls. See 10.4 for an
associated requirement involving control system monitoring tools and techniques.
2254
13.4.3
2255
None
2256
13.4.4
2257
The requirements for the four SL levels that relate to EDR 3.2 are:
Requirement
Rationale and supplemental guidance
Requirement enhancements
Security levels
2258
SL-C(SI, component) 1: EDR 3.2
2259
SL-C(SI, component) 2: EDR 3.2
2260
SL-C(SI, component) 3: EDR 3.2
2261
SL-C(SI, component) 4: EDR 3.2
2262
13.5
EDR 3.10
Support for updates
2263
13.5.1
2264
The embedded device shall support the ability to be updated and upgraded once installed.
2265
13.5.2
2266
2267
Embedded devices over their installed lifetime may have the need for installation of updates and
upgrades. There will be cases where embedded devices are supporting or executing essential
Requirement
Rationale and supplemental guidance
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
2229
2230
Requirement enhancements
2268
2269
2270
2271
functions as well. When this is the case the embedded device needs to have mechanisms in place
to support patching and updating without impacting the essential function (see 4.2 Support of
essential functions). One example for providing this capability would be to support redundancy
within the embedded device.
2272
13.5.3
2273
(1) Update authenticity and integrity
The embedded device shall validate the authenticity and integrity of any update prior to
installation.
2276
13.5.4
Security levels
2277
The requirements for the four SL levels that relate to E DR 3.10 are:
2278
SL-C(SI, component) 1: EDR 3.10
2279
SL-C(SI, component) 2: EDR 3.10
2280
SL-C(SI, component) 3: EDR 3.10 (1)
2281
SL-C(SI, component) 4: EDR 3.10 (1)
2282
13.6
2283
13.6.1
2284
2285
The embedded device shall provide anti-tamper resistance and detection mechanisms for
unauthorized physical access into the device
2286
13.6.2
2287
2288
2289
The purpose of tamper resistance mechanisms is to prevent an attempt by an attacker to execute
an unauthorized physical action against an IACS device. Secondary to prevention, detection and
response are essential should a tampering event occur.
2290
2291
2292
2293
2294
Tamper resistance mechanisms are most effectively used in combinations to prevent access to any
critical components. Tamper resistance consists of using specialized materials to make tampering
of a device or module difficult. This can include such features as hardened enclosures, locks,
encapsulation, or security screws. Putting in place tight airflow paths will increase the difficulty of
probing the product internals.
2295
2296
2297
2298
The purpose of tamper evidence is to ensure that visible or electronic evidence remains when a
tampering event occurs. Many simple evidence techniques are comprised of seals and tapes to
make it obvious that there has been physical tampering . More sophisticated techniques include
switches.
2299
13.6.3
2300
(1) Notification of a tampering attempt
2301
2302
2303
EDR 3.11
Physical tamper resistance and detection
Requirement
Rationale and supplemental guidance
Requirement enhancements
The embedded device shall be capable of automatically providing notification to a configurable
set of recipients upon discovery of an attempt to make an unauthorized physical access. All
notifications of tampering shall be logged as part of the overall audit logging function .
2304
13.6.4
Security levels
2305
The requirements for the four SL levels that relate to EDR 3.11 are:
2306
SL-C(SI, component) 1: Not Selected
2307
SL-C(SI, component) 2: EDR 3.11
2308
SL-C(SI, component) 3: EDR 3.11 (1)
2309
SL-C(SI, component) 4: EDR 3.11 (1)
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
2274
2275
Requirement enhancements
2310
13.7
EDR 3.12
Provisioning product supplier roots of trust
2311
13.7.1
2312
2313
2314
Embedded devices shall provide the capability to provision and protect the confidentiality, integrity,
and authenticity of product supplier keys and
at the
time of manufacture of the device.
2315
13.7.2
2316
2317
2318
2319
2320
2321
2322
2323
2324
2325
2326
2327
2328
2329
2330
In order for a component to be able to validate the authenticity and integrity of the hardware,
software, and data provided by the product supplier, it must possess a trusted source of data t o
2331
13.7.3
2332
None
2333
13.7.4
2334
The requirements for the four SL levels that relate to EDR 3.12 are:
Rationale and supplemental guidance
software, or it may be the public portion of an asymmetri c cryptographic key pair to be used in the
validation of cryptographic signatures. This trusted data is often used to validate critical software,
firmware, and data prior to booting the firmware or operating system of a component, in order to
validate tha
hardware mechanisms, preventing any modification of the data during normal oper ations of the
component. Modification of product supplier root of trust data is typically limited to the product
provisioning of the data. Instead, information to be validated against the root of trust is submitted
to the validation process through a hardware or software API which performs the validation and
returns the results without exposing the protected data.
Requirement Enhancements
Security levels
2335
SL-C(SI, component) 1: Not Selected
2336
SL-C(SI, component) 2: EDR 3.12
2337
SL-C(SI, component) 3: EDR 3.12
2338
SL-C(SI, component) 3: EDR 3.12
2339
13.8
EDR 3.13
Provisioning asset owner roots of trust
2340
13.8.1
2341
Embedded devices shall
Requirement
2342
2343
a) provide the capability to provision and protect the confidentiality, integrity, and authenticity
of asset owner keys and
; and
2344
2345
b) support the capability to provision without reliance on components that may be outside of
the device s security zone.
2346
13.8.2
Rationale and supplemental guidance
2347
2348
2349
2350
2351
2352
2353
2354
Product suppliers have established mechanisms to ensure that the software and firmware on their
components is authentic, and the integrity of that software and firmware has not been compromised.
to operate. However, many product suppliers also provide mechanisms for asset owners to extend
the functionality of their devices through the use of mobile code, user programs, or other such
means. In order to protect the security of the component, it is important that these extensions to
ed, and that the
asset owner has approved of their origins.
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
Requirement
In order perform these validations the component must contain data that provides a way to
differentiate between valid and invalid origins. The list of valid and invalid origins will differ from
asset owner to asset owner, and it is unlikely that a product supplier will have a complete list of
every possible valid origin at time of manufacture. Therefore it is important that the product supplier
provide a way for the asset owner to securely provis
2363
2364
2365
2366
Requirements such as EDR 2.4
Mobile code require the component to complete authenticity
checks on mobile code prior to the execution of mobile code. The roots of trust provided by this
requirement provide the data necessary to validate the origin and integrity of mobile code, allowing
the component to independently determine if the code is allowed to execute.
2367
13.8.3
2368
None
2369
13.8.4
2370
The requirements for the four SL levels that relate to EDR 3.13 are:
actors cannot add additional roots of trust that grant them the ability to operate on the component.
Requirement Enhancements
Security levels
2371
SL-C(SI, component) 1: Not Selected
2372
SL-C(SI, component) 2: EDR 3.13
2373
SL-C(SI, component) 3: EDR 3.13
2374
SL-C(SI, component) 4: EDR 3.13
2375
13.9
2376
13.9.1
2377
2378
Embedded devices shall verify the integrity of the firmware, software, and configuration data
boot process prior to it being used in the boot process.
2379
13.9.2
2380
2381
2382
2383
2384
2385
2386
been compromised, it is necessary to ensure that
firmware has not
been tampered with, and that the software and firmware is valid to execute on the component.
Therefore the component must perform checks to validate the integrity and authenticity of the
boot process, to ensure that the component does
not boot into an insecure or invalid operating state that could damage the component or provide a
path for a malicious actor to gain access to additional components, assets, or data.
2387
13.9.3
2388
(1) Authenticity of the boot process
2389
2390
2391
EDR 3.14
Integrity of the boot process
Requirement
Rationale and supplemental guidance
Requirement enhancements
process prior to it being used in the boot process.
2392
13.9.4
Security levels
2393
The requirements for the four SL levels that relate to EDR 3.14 are:
2394
SL-C(SI, component) 1: EDR 3.14
2395
SL-C(SI, component) 2: EDR 3.14 (1)
2396
SL-C(SI, component) 3: EDR 3.14 (1)
2397
SL-C(SI, component) 4: EDR 3.14 (1)
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
2355
2356
2357
2358
2359
2360
2361
2362
2398
14 Host device requirements
2399
14.1
2400
2401
The purpose of this set of requirements is to document requirements that are specific to host
devices.
2402
14.2
2403
14.2.1
2404
2405
2406
2407
In the event that a host device utilizes mobile code technologies, that host device shall provide the
capability to enforce a security policy for the usage of mobile code technologies. The security
policy must allow, at a minimum, the following actions for each mobile code technology used on
the host device:
HDR 2.4
Mobile code
Requirement
2408
a) Control execution of mobile code;
2409
2410
b) Define which users (human, software process, or device) are allowed to transfer mobile
code to/from the host device;
2411
c) Perform integrity checks on mobile code prior to the code being executed; and
2412
2413
d) Perform authenticity checks to verify the origin of the mobile code prior to the code being
executed.
2414
14.2.2
Rationale and supplemental guidance
2415
2416
2417
2418
2419
2420
2421
Mobile code technologies include, but are not limited to, Java, JavaScript, ActiveX, PDF, Postscript,
Shockwave movies, Flash animations and VBScript. Usage restrictions apply to both the selection
and use of mobile code installed on servers and mobile code downloaded and executed on
individual workstations. Control procedures should prevent the development, acquisition or
introduction of unacceptable mobile code within the control system in which the component resides.
For example, mobile code exchanges may be disallowed directly with the control system, but may
be allowed in a controlled adjacent environment maintained by IACS personnel.
2422
14.2.3
2423
None
2424
14.2.4
2425
The requirements for the four SL levels that relate to HDR 2.4 are:
Requirement enhancements
Security levels
2426
SL-C(UC, component) 1: HDR 2.4
2427
SL-C(UC, component) 2: HDR 2.4
2428
SL-C(UC, component) 3: HDR 2.4
2429
SL-C(UC, component) 4: HDR 2.4
2430
14.3
HDR 2.13
Use of physical diagnostic and test interfaces
2431
14.3.1
2432
2433
Host devices shall prevent unauthorized use of the physical factory diagnostic and test interface(s)
(e.g. JTAG).
2434
14.3.2
2435
2436
2437
Factory diagnostic and test interface(s) are created at various locations within t he component to
Requirement
Rationale and supplemental guidance
implementation, and when errors are discovered to subsequently remove them from the component.
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
Purpose
However, these same interfaces must be carefully protected fr om access by unauthorized entities
to protect the essential functionality provided by the component to the IACS.
2440
2441
2442
There may be cases where the factory diagnostic and test interface(s) use network communications
with the device. When this is the case those interfaces are to be subjected to all of the requirements
of this standard.
2443
14.3.3
2444
(1) Active monitoring
2445
2446
Requirement enhancements
generate a log entry when attempts to access these interface(s) are detected.
2447
14.3.4
Security levels
2448
The requirements for the four SL levels that relate to HDR 2.13 are:
2449
SL-C(SI, component) 1: Not Selected
2450
SL-C(SI, component) 2: HDR 2.13
2451
SL-C(SI, component) 3: HDR 2.13 (1)
2452
SL-C(SI, component) 3: HDR 2.13 (1)
2453
14.4
2454
14.4.1
2455
2456
2457
There shall be mechanisms on host devices that are qualified by the IACS product supplier to
provide protection from malicious code. The IACS product supplier shall document any special
configuration requirements related to protection from malicious code.
2458
14.4.2
2459
2460
2461
2462
Host devices need to support the use of malicious code (for example, viruses, worms, Trojan horses
and spyware) protection. The product supplier should qualify and document the configuration of
protection from malicious code mechanisms so that the primary mission of t he control system is
maintained.
2463
14.4.3
2464
(1) Report version of code protection
2465
2466
HDR 3.2
Protection from malicious code
Requirement
Rationale and supplemental guidance
Requirement enhancements
The host device shall automatically report th e version of protection from malicious code in use
(as part of overall logging function).
2467
14.4.4
Security levels
2468
The requirements for the four SL levels that relate to HDR 3.2 are:
2469
SL-C(SI, component) 1: HDR 3.2
2470
SL-C(SI, component) 2: HDR 3.2 (1)
2471
SL-C(SI, component) 3: HDR 3.2 (1)
2472
SL-C(SI, component) 4: HDR 3.2 (1)
2473
14.5
HDR 3.10
Support for updates
2474
14.5.1
2475
Host devices shall support the ability to be updated and upgraded once installed.
2476
14.5.2
2477
2478
Host devices over their installed lifetime may have the need for installation of updates and
upgrades. There will be cases where host devices are supporting or executing essential functions
Requirement
Rationale and supplemental guidance
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
2438
2439
2479
2480
2481
2482
as well. When this is the case the host device needs to have mechanisms in place to support
patching and updating without impacting the essential function (see 4.2 Support of essential
functions). One example for providing this capability would be to support redundancy within the
host device.
2483
14.5.3
2484
(1) Update authenticity and integrity
Host devices shall validate the authenticity and integrity of any update prior to installation.
2486
14.5.4
Security levels
2487
The requirements for the four SL levels that relate to HDR 3.10 are:
2488
SL-C(SI, component) 1: HDR 3.10
2489
SL-C(SI, component) 2: HDR 3.10
2490
SL-C(SI, component) 3: HDR 3.10 (1)
2491
SL-C(SI, component) 4: HDR 3.10 (1)
2492
14.6
2493
14.6.1
2494
2495
Host devices shall provide anti-tamper resistance and detection mechanisms for unauthorized
physical access into the device
2496
14.6.2
2497
2498
2499
The purpose of tamper resistance mechanisms is to prevent an attempt by an attacker to execute
an unauthorized physical action against an IACS device. Secondary to prevention, detection and
response are essential should a tampering event occur.
2500
2501
2502
2503
2504
Tamper resistance mechanisms are most effectively used in combinations to prevent access to any
critical components. Tamper resistance consists of using specialized materials to make tampering
of a device or module difficult. This can include such features as hardened enclosures, locks,
encapsulation, or security screws. Putting in place tight airflow paths will increase the difficulty of
probing the product internals.
2505
2506
2507
2508
The purpose of tamper evidence is to ensure that visible or electronic evidence remains when a
tampering event occurs. Many simple evidence techniques are comprised of seals and tapes to
make it obvious that there has been physical tampering . More sophisticated techniques include
switches.
2509
14.6.3
2510
(1) Notification of a tampering attempt
2511
2512
2513
HDR 3.11
Physical tamper resistance and detection
Requirement
Rationale and supplemental guidance
Requirement enhancements
Host devices shall be capable of automatically providing notification to a configurable set of
recipients upon discovery of an attempt to make an unauthorized physical access. All
notifications of tampering shall be logged as part of the overall audit logging function.
2514
14.6.4
Security levels
2515
The requirements for the four SL levels that relate to HDR 3.11 are:
2516
SL-C(SI, component) 1: Not Selected
2517
SL-C(SI, component) 2: HDR 3.11
2518
SL-C(SI, component) 3: HDR 3.11 (1)
2519
SL-C(SI, component) 4: HDR 3.11 (1)
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
2485
Requirement enhancements
2520
14.7
HDR 3.12
Provisioning product supplier roots of trust
2521
14.7.1
2522
2523
2524
Host devices shall provide the capability to provision and protect the confidentiality, integrity, and
2525
14.7.2
2526
2527
2528
2529
2530
2531
2532
2533
2534
2535
2536
2537
2538
2539
2540
In order for a component to be able to validate the authenticity and integrity of the hardware,
software, and data provided by the product supplier, it must possess a trusted source of data to
perform the validation proc
2541
14.7.3
2542
None
2543
14.7.4
2544
The requirements for the four SL levels that relate to HDR 3.12 are:
Requirement
Rationale and supplemental guidance
software, or it may be the public portion of an asymmetric cryptographic key pair to b e used in the
validation of cryptographic signatures. This trusted data is often used to validate critical software,
firmware, and data prior to booting the firmware or operating system of a component, in order to
validate that the component will boot int
hardware mechanisms, preventing any modification of the data during normal operations of the
component. Modification of product supplier root of trust data is typically limited to the product
provisioning of the data. Instead, information to be validated against th e root of trust is submitted
to the validation process through a hardware or software API which performs the validation and
returns the results without exposing the protected data.
Requirement Enhancements
Security levels
2545
SL-C(SI, component) 1: Not Selected
2546
SL-C(SI, component) 2: HDR 3.12
2547
SL-C(SI, component) 3: HDR 3.12
2548
SL-C(SI, component) 3: HDR 3.12
2549
14.8
HDR 3.13
2550
14.8.1
2551
Host devices shall
Provisioning asset owner roots of trust
Requirement
2552
2553
c) provide the capability to provision and protect the confidentiality, integrity, and authenticity
2554
2555
d) support the capability to provision without reliance on components that m ay be outside of
2556
14.8.2
Rationale and supplemental guidance
2557
2558
2559
2560
2561
2562
2563
2564
Product suppliers have established mechanisms to ensure that the software and firmware on their
components is authentic, and the integrity of that software and firmware has n ot been compromised.
to operate. However, many product suppliers also provide mechanisms for asset owners to extend
the functionality of their devices through the use of mobile code, user programs, or other such
means. In order to protect the security of the component, it is important that these extensions to
asset owner has approved of their origins.
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
of manufacture of the device.
In order perform these validations the component must contain data that provides a way to
differentiate between valid and invalid origins. The list of valid and invalid origins will differ from
asset owner to asset owner, and it is unlikely that a product supplier will have a complete list of
every possible valid origin at time of manufacture. Therefore it is important that the product supplier
2573
2574
2575
2576
Requirements such as HDR 2.4
Mobile code require the component to complete authentic ity
checks on mobile code prior to the execution of mobile code. The roots of trust provided by this
requirement provide the data necessary to validate the origin and integrity of mobile code, allowing
the component to independently determine if the code is allowed to execute.
2577
14.8.3
2578
None
2579
14.8.4
2580
The requirements for the four SL levels that relate to HDR 3.13 are:
actors cannot add additional roots of trust that grant them the ability to operate on the component.
Requirement Enhancements
Security levels
2581
SL-C(SI, component) 1: Not Selected
2582
SL-C(SI, component) 2: HDR 3.13
2583
SL-C(SI, component) 3: HDR 3.13
2584
SL-C(SI, component) 4: HDR 3.13
2585
14.9
2586
14.9.1
2587
2588
Host devices shall verify the integrity of the firmware, software, and configuration data needed for
2589
14.9.2
2590
2591
2592
2593
2594
2595
2596
HDR 3.14
Integrity of the boot process
Requirement
Rationale and supplemental guidance
been tampered with, and that the software and firmware is valid to execute on the component.
Therefore the component must perform checks to validate the integrity and authenticity of the
not boot into an insecure or invalid operating state that could damage the component or provide a
path for a malicious actor to gain access to additional components, assets, or data.
2597
14.9.3
2598
(1) Authenticity of the boot process
2599
2600
2601
Requirement enhancements
Host devices shall
it being used in the boot process.
2602
14.9.4
Security levels
2603
The requirements for the four SL levels that relate to HDR 3.14 are:
2604
SL-C(SI, component) 1: HDR 3.14
2605
SL-C(SI, component) 2: HDR 3.14 (1)
2606
SL-C(SI, component) 3: HDR 3.14 (1)
2607
SL-C(SI, component) 4: HDR 3.14 (1)
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
2565
2566
2567
2568
2569
2570
2571
2572
2608
15 Network device requirements
2609
15.1
2610
2611
The purpose of this set of requirements is to document requirements that are specific to network
components.
2612
15.2
2613
15.2.1
2614
2615
2616
A network device supporting wireless access management shall provide the capability to identify
and authenticate all users (humans, software processes or devices) engaged in wireless
communication.
2617
15.2.2
2618
2619
2620
2621
2622
Any wireless technology can, and in most cases should, be considered just another com munication
protocol option. Thus, it should be subject to the same IACS security requirements as any other
communication type utilized by the IACS. However, from a security point of view, there is at least
one significant difference between wired and wireless communications. Physical security
countermeasures are typically less effective when using wireless.
2623
15.2.3
2624
(1) Unique identification and authentication
NDR 1.6
Wireless access management
Requirement
Rationale and supplemental guidance
Requirement enhancements
The network device shall provide the capability to uniquely identify and authenticate all users
(humans, software processes or devices) engaged in wireles s communication.
2627
15.2.4
Security levels
2628
The requirements for the four SL levels that relate to NDR 1.6 are:
2629
SL-C(UC, component) 1: NDR 1.6
2630
SL-C(UC, component) 2: NDR 1.6 (1)
2631
SL-C(UC, component) 3: NDR 1.6 (1)
2632
SL-C(UC, component) 4: NDR 1.6 (1)
2633
15.3
2634
15.3.1
2635
2636
The network device supporting device access into a network shall provide the capability to monitor
and control all methods of access to the network device via untrusted networks.
2637
15.3.2
2638
2639
2640
2641
2642
2643
Examples of access to the network device via untrusted networks typically include remote access
methods (such as, dial(non-control system) network. The network device should restrict acc ess achieved through dial-up
connections (for example, limiting dial-up access based upon the source of the request) or protect
against unauthorized connections or subversion of authorized connections (for example, using
virtual private network technology) .
2644
15.3.3
2645
(1) Explicit access request approval
2646
2647
NDR 1.13
Access via untrusted networks
Requirement
Rationale and supplemental guidance
Requirement enhancements
The network device shall provide the capability to deny access requests via untrusted networks
unless explicitly approved by an assigned role.
2648
15.3.4
Security levels
2649
The requirements for the four SL levels that relate to NDR 1.13 are:
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
2625
2626
Purpose
SL-C(UC, component) 1: NDR 1.13
2651
SL-C(UC, component) 2: NDR 1.13
2652
SL-C(UC, component) 3: NDR 1.13 (1)
2653
SL-C(UC, component) 4: NDR 1.13 (1)
2654
15.4
NDR 2.4
Mobile code
2655
15.4.1
2656
2657
2658
2659
In the event that a network device utilizes mobile code technologies , the network device shall
provide the capability to enforce a security policy for the usage of mobile code technologies. The
security policy must allow, at a minimum, the following actions for each mobile code technology
used on the network device:
Requirement
2660
a) Control execution of mobile code;
2661
2662
b) Define which users (human, software process, or device) are allowed to transfer mobile
code to/from the network device;
2663
c) Perform integrity checks on mobile code prior to the code being executed; and
2664
2665
d) Perform authenticity checks to verify the origin of the mobile code prior to the code being
executed.
2666
15.4.2
Rationale and supplemental guidance
2667
2668
2669
2670
2671
2672
2673
Mobile code technologies include, but are not limited to, Java, JavaScript, ActiveX, PDF, Postscript,
Shockwave movies, Flash animations and VBScript. Usage restrictions apply to both the selection
and use of mobile code installed on servers and mobile code downloaded and executed on
individual workstations. Control procedures should prevent the development, acquisition or
introduction of unacceptable mobile code within the control system in which the component resides.
For example, mobile code exchanges may be disallowed directly with in the control system, but may
be allowed in a controlled adjacent environment maintained by IACS personnel.
2674
15.4.3
2675
None
2676
15.4.4
2677
The requirements for the four SL levels that relate to NDR 2.4 are:
Requirement enhancements
Security levels
2678
SL-C(UC, component) 1: NDR 2.4
2679
SL-C(UC, component) 2: NDR 2.4
2680
SL-C(UC, component) 3: NDR 2.4
2681
SL-C(UC, component) 4: NDR 2.4
2682
15.5
NDR 2.13
Use of physical diagnostic and test interfaces
2683
15.5.1
2684
2685
Network devices shall prevent unauthorized use of the physical factory diagnostic and test
interface(s) (e.g. JTAG).
2686
15.5.2
2687
2688
2689
2690
2691
Factory diagnostic and test interface(s) are created at various locations within the component to
Requirement
Rationale and supplemental guidance
implementation, and when errors are discovered to subsequently remove them from the component.
However, these same interfaces must be carefully protected from access by unauthorized entities
to protect the essential functionality provided by the component to the IACS.
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
2650
2692
2693
2694
There may be cases where the factory diagnostic and test interface(s) use network communi cations
with the device. When this is the case those interfaces are to be subjected to all of the requirements
of this standard.
2695
15.5.3
2696
(1) Active monitoring
Network devices shall provide active monitoring of the
diagnostic and test interface(s)
and generate a log entry when attempts to access these interface(s) are detected.
2699
15.5.4
Security levels
2700
The requirements for the four SL levels that relate to NDR 2.13 are:
2701
SL-C(SI, component) 1: Not Selected
2702
SL-C(SI, component) 2: NDR 2.13
2703
SL-C(SI, component) 3: NDR 2.13 (1)
2704
SL-C(SI, component) 3: NDR 2.13 (1)
2705
15.6
NDR 3.2
Protection from malicious code
2706
15.6.1
2707
The network device shall provide for protection from malicious code.
2708
15.6.2
2709
2710
2711
2712
2713
If a network device is able to utilize a compensating control, it need not directly support protection
from malicious code. One such possible compensating control would be the use of network packet
filtering devices to identify and remove malicious code while in transit. It is assumed that the IACS
will be responsible for providing the required safeguards. However, for scenarios such as having a
local USB host access, the need for protection from malicious code should be evaluated.
2714
15.6.3
2715
None
2716
15.6.4
2717
The requirements for the four SL levels that relate to NDR 3.2 are:
Requirement
Rationale and supplemental guidance
Requirement enhancements
Security levels
2718
SL-C(SI, component) 1: NDR 3.2
2719
SL-C(SI, component) 2: NDR 3.2
2720
SL-C(SI, component) 3: NDR 3.2
2721
SL-C(SI, component) 4: NDR 3.2
2722
15.7
NDR 3.10
Support for updates
2723
15.7.1
2724
Network devices shall support the ability to be updated and upgraded once installed.
2725
15.7.2
2726
2727
2728
2729
2730
2731
Network devices over their installed lifetime may have the need for installation of updates and
upgrades. There will be cases where network devices are supporting or executing essential
functions as well. When this is the case the network device needs to have mechanisms in place to
support patching and updating without impacting the essential function (see 4.2 Support of
essential functions). One example for providing this capability would be to support redu ndancy
within the network device.
Requirement
Rationale and supplemental guidance
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
2697
2698
Requirement enhancements
2732
15.7.3
2733
(1) Update authenticity and integrity
Network devices shall validate the authenticity and integrity of any update prior to installation.
2735
15.7.4
Security levels
2736
The requirements for the four SL levels that relate to NDR 3.10 are:
2737
SL-C(SI, component) 1: NDR 3.10
2738
SL-C(SI, component) 2: NDR 3.10
2739
SL-C(SI, component) 3: NDR 3.10 (1)
2740
SL-C(SI, component) 4: NDR 3.10 (1)
2741
15.8
2742
15.8.1
2743
2744
Network devices shall provide anti-tamper resistance and detection mechanisms for unauthorized
physical access into the device
2745
15.8.2
2746
2747
2748
The purpose of tamper resistance mechanisms is to prevent an attempt by an attacker to execute
an unauthorized physical action against an IACS device. Secondary to prevention, detection and
response are essential should a tampering event occur.
2749
2750
2751
2752
2753
Tamper resistance mechanisms are most effectively used in combinations to prevent access to any
critical components. Tamper resistance consists of using specialized materials to make tampering
of a device or module difficult. This can include such features as hardened enclosures, locks,
encapsulation, or security screws. Putting in place tight airflow paths will increase the difficulty of
probing the product internals.
2754
2755
2756
2757
The purpose of tamper evidence is to ensure that visible or electronic evidence remains when a
tampering event occurs. Many simple evidence techniques are comprised of seals and tapes to
make it obvious that there has been physical tampering. More sophisticated techniques include
switches.
2758
15.8.3
2759
(1) Notification of a tampering attempt
2760
2761
2762
NDR 3.11
Physical tamper resistance and detection
Requirement
Rationale and supplemental guidance
Requirement enhancements
Network devices shall be capable of automatically providing notification to a configurable set of
recipients upon discovery of an attempt to make an unauthorized physical access. All
notifications of tampering shall be logged as part of the overall audit logging function.
2763
15.8.4
Security levels
2764
The requirements for the four SL levels that relate to NDR 3.11 are:
2765
SL-C(SI, component) 1: Not Selected
2766
SL-C(SI, component) 2: NDR 3.11
2767
SL-C(SI, component) 3: NDR 3.11 (1)
2768
SL-C(SI, component) 4: NDR 3.11 (1)
2769
15.9
NDR 3.12
Provisioning product supplier roots of trust
2770
15.9.1
2771
2772
2773
Network devices shall provide the capability to prov ision and protect the confidentiality, integrity,
Requirement
time of manufacture of the device.
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
2734
Requirement enhancements
15.9.2
Rationale and supplemental guidance
2775
2776
2777
2778
2779
2780
2781
2782
2783
2784
2785
2786
2787
2788
2789
In order for a component to be able to validate the authenticity and integrity of the hardware,
software, and data provided by the product supplier, it must possess a trusted source of data to
2790
15.9.3
2791
None
2792
15.9.4
2793
The requirements for the four SL levels that relate to NDR 3.12 are:
software, or it may be the public portion of an asymmetric cryptographic key pair to be used in the
validation of cryptographic signatures. This trusted data is often used to validate critical software,
firmware, and data prior to booting the firmware or operating system of a component, in order to
are known t
hardware mechanisms, preventing any modification of the data during normal operations of the
component. Modification of product supplier root of trust data is typically limit ed to the product
provisioning of the data. Instead, information to be validated against the root of trust is submitted
to the validation process through a hardware or software API which performs the validation and
returns the results without exposing the protected data.
Requirement Enhancements
Security levels
2794
SL-C(SI, component) 1: Not Selected
2795
SL-C(SI, component) 2: NDR 3.12
2796
SL-C(SI, component) 3: NDR 3.12
2797
SL-C(SI, component) 3: NDR 3.12
2798
15.10 NDR 3.13
Provisioning asset owner roots of trust
2799
15.10.1 Requirement
2800
Network devices shall
2801
2802
a) provide the capability to provision and protect the confidentiality, integrity, and authenticity
2803
2804
b) support the capability to provision without reliance on components that may be outside of
the
2805
15.10.2 Rationale and supplemental guidance
2806
2807
2808
2809
2810
2811
2812
2813
Product suppliers have established mechanisms to ensure that the software and firmware on their
components is authentic, and the integrity of that software and firmware has not been compromised.
2814
2815
2816
2817
2818
2819
In order perform these validations the component must contain data that provides a way to
differentiate between valid and invalid origins. The list of valid and invalid origins will differ from
asset owner to asset owner, and it is unlik ely that a product supplier will have a complete list of
every possible valid origin at time of manufacture. Therefore it is important that the product supplier
de the
to operate. However, many product suppliers also provide mechanisms for asset owners to extend
the functionality of their devices through the use of mobile c ode, user programs, or other such
means. In order to protect the security of the component, it is important that these extensions to
asset owner has approved of their origins.
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
2774
actors cannot add additional roots of trust th at grant them the ability to operate on the component.
2822
2823
2824
2825
Requirements such as NDR 2.4
Mobile coderequire the component to complete authenticity
checks on mobile code prior to the execution of mobile code. The roots of trust provided by this
requirement provide the data necessary to validate the origin and integrity of mobile code, allowing
the component to independently determine if the code is allowed to execute .
2826
15.10.3 Requirement Enhancements
2827
None
2828
15.10.4 Security levels
2829
The requirements for the four SL levels that relate to NDR 3.13 are:
2830
SL-C(SI, component) 1: Not Selected
2831
SL-C(SI, component) 2: NDR 3.13
2832
SL-C(SI, component) 3: NDR 3.13
2833
SL-C(SI, component) 4: NDR 3.13
2834
15.11 NDR 3.14
2835
15.11.1 Requirement
2836
2837
Network devices shall verify the integrity of the firmware, software, and configuration data needed
2838
15.11.2 Rationale and supplemental guidance
2839
2840
2841
2842
2843
2844
2845
Integrity of the boot process
been tampered with, and that the software and firmware is valid to execute on the component.
Therefore the component must perform checks to validate the integrity and authenticity of the
not boot into an insecure or invalid operating state that could damage the component or provide a
path for a malicious actor to gain access to additional components, assets, or data.
2846
15.11.3 Requirement enhancements
2847
(1) Authenticity of the boot process
2848
2849
2850
s product supplier roots of trust to verity the
process prior to it being used in the boot process.
2851
15.11.4 Security levels
2852
The requirements for the four SL levels that relate to NDR 3.14 are:
2853
SL-C(SI, component) 1: NDR 3.14
2854
SL-C(SI, component) 2: NDR 3.14 (1)
2855
SL-C(SI, component) 3: NDR 3.14 (1)
2856
SL-C(SI, component) 4: NDR 3.14 (1)
2857
15.12 NDR 5.2
Zone boundary protection
2858
15.12.1 Requirement
2859
2860
2861
A network device at a zone boundary shall provide the capability to monitor and control
communications at zone boundaries to enforce the compartmentalization defined in the risk -based
zones and conduits model.
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
2820
2821
15.12.2 Rationale and supplemental guidance
2863
2864
2865
2866
2867
2868
Any connections to outside each security zone should occur through managed interfaces consisting
of appropriate boundary protection devices (for example, proxies, gateways, routers, firewalls,
unidirectional gateways, guards and encrypted tunnels) arranged in an effective architecture (for
example, firewalls protecting application gateways residing in a DMZ). Control system boundary
protections at any designated alternate processing sites should provide the same levels of
protection as that of the primary site.
2869
15.12.3 Requirement enhancements
2870
(1) Deny all, permit by exception
2871
2872
2873
The network component shall provide the capability to deny network traffic by default and allow
network traffic by exception (also termed deny all, permit by exception).
(2) Island mode
2874
The network component shall provide the capability to prevent any communication through the
2875
control system boundary (also termed island mode).
2876NOTE Examples of when this capability may be used include where a security violation and/or breach has been detected
2877
within the control system, or an attack is occurring at the enterprise level.
2878
(3) Fail close
2879
The network component shall provide the capability to prevent any communication through the
2880
control system boundary when there is an operational failure of the boundary prote ction
2881
mechanisms (also termed fail close).
2882NOTE Examples of when this capability may be used include scenarios where a hardware failure or power failure causes
2883
boundary protection devices to function in a degraded mode or fail entirely.
2884
15.12.4 Security levels
2885
The requirements for the four SL levels that relate to NDR 5.2 are:
2886
SL-C(SI, component) 1: NDR 5.2
2887
SL-C(SI, component) 2: NDR 5.2 (1)
2888
SL-C(SI, component) 3: NDR 5.2 (1) (2) (3)
2889
SL-C(SI, component) 4: NDR 5.2 (1) (2) (3)
2890
15.13 NDR 5.3
General purpose, person-to-person communication restrictions
2891
15.13.1 Requirement
2892
2893
2894
A network device at a zone boundary shall provide the capability to prevent general purpose ,
person-to-person messages from being received from users or systems external to the control
system.
2895
15.13.2 Rationale and supplemental guidance
2896
2897
2898
2899
2900
General purpose, person-to-person communications systems include but are not limited to: email
systems, forms of social media (Twitter, Facebook, picture galleries, etc.) or any message systems
that permit the transmission of any type of executable file. These systems are usually utilized for
private purposes that are not related to control system operations, and therefore the risks imposed
by these systems normally outweigh any perceived benefit.
2901
2902
2903
2904
These types of general purpose communications systems are commonly used as attack vectors to
introduce malware to the control system, pass information for which read authorization exists to
locations external to the control system and introduce excessive network loading that can be use d
to create security problems or launch attacks on the control system.
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
2862
Network devices could realize such restrictions, for example, by blocking specific communications
based on port numbers and source and/or target address as well as more in depth checks by
application layer firewalls.
2908
15.13.3 Requirement enhancements
2909
None
2910
15.13.4 Security levels
2911
The requirements for the four SL levels that relate to NDR 5.3 are:
2912
SL-C(SI, component) 1: NDR 5.3
2913
SL-C(SI, component) 2: NDR 5.3
2914
SL-C(SI, component) 3: NDR 5.3
2915
SL-C(SI, component) 4: NDR 5.3
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
2905
2906
2907
Annex A
(informative)
Component catagories
2916
2917
2918
A.1
Device categories
2920
A.1.1
2921
2922
A.1.1.1
2923
2924
2925
2926
2927
2928
2929
2930
2931
2932
2933
2934
2935
2936
2937
2938
2939
2940
2941
2942
2943
The term PLC is commonly used in the process and discrete manufacturing industries. A PLC is a
device that typically resides on the lower levels of the automation system ( such as level 1 and 2 of
the Purdue Enterprise Reference Architecture in ANSI/ISA-95.00.01 [22]). PLCs commonly use
ruggedized hardware to allow for operation in industrial environments and are commonly base d on
commercial real-time operating systems (RTOS). PLCs are programmed to execute control logic
based on inputs from the process (obtained from instrumentation like temperature sensors,
pressure sensors, vibration sensors, etc.). The control logic's output is used to control the industrial
process (through actuators such as valves, pumps, etc.). The programming is usually done using
engineering software commonly run on host devices ( for example, laptops or PC workstations). A
common programming language for control logic is IEC 61131-3, Programmable controllers Part
3: Programming languages [20]. In larger systems, PLCs often also communicate the process
conditions as obtained from sensors to higher-level servers and/or operator workstations and
receive instructions from higher-level control functions or operator workstati ons, which are
translated into or forwarded as commands to actuators. For the communication to higher -level
functions such as control servers or operator worksta tions, modern PLCs use Ethernet and
Transmission Control Protocol (TCP)/Internet Protocol (IP)-based protocols, while for the
communication to the instrumentation commonly industry standard fieldbuses are used (some of
which are also available on Ethernet carriers, but usually don't use the TCP/IP stack). Special PLCs
are used in SIS which ensure that the process under control remains within the bounds of sa fe
operation at all times. PLCs, especially in SIS, should meet hard real-time and high integrity and
availability requirements.
2944
2945
2946
A.1.1.2
2947
2948
2949
2950
2951
2952
2953
2954
2955
2956
2957
2958
2959
2960
2961
2962
2963
2964
An intelligent electronic device (IED) is conceptually very similar to a PLC, but the term is more
commonly used in power systems (specifically substation automation). An IED receives
measurements from the power equipment (for example, transformers, switches and circuit
breakers) and executes control logic or protection functions. Similar to PLCs, IEDs are commonly
programmed and parameterized using engineering software commonly run on host devices ( for
example laptops and PC workstations). A modern standard way of describing the configuration of
IEDs and their functions is defined in the IEC 61850 standard. The output of the logic executed by
IEDs is transmitted to actuators (switches, circuit breakers , etc.). As opposed to PLCs, IEDs
commonly also have a HMI which allows a human user standing in front of the IED to use the IED's
functionality (often a subset necessary to support essential functions). Also, substations , and
therefore the IEDs used therein, have to be able to operate in complete isolation ( such as without
any communication to higher-level systems outside the substation or even without any
communication to other IEDs or station-level workstations or servers). Modern IEDs usually use
Ethernet and TCP/IP-based protocols to communicate to higher-level components, while
communication to other IEDs may be done using Ethernet -based protocols (in some cases TCP/IPbased, often directly on Ethernet) or fieldbuses (some of which are available also on Ethernet
carriers, but don't use the TCP/IP stack). Similar to PLCs, IEDs should meet hard real-time and
high integrity and availability requirements.
Device category: embedded device
Programmable Logic Controller (PLC) (expanded from the Electropedia
definition 351-32-34 [19])
Intelligent electronic device (expanded from the definition in
IEC TR 61850-1:2013, Communication networks and systems for power utility
automation Part 1: Introduction and overview [21])
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
2919
2965
A.1.2
Device category: network device
2966
A.1.2.1
2967
2968
2969
2970
2971
2972
2973
A switch is a device in computer networks that links multiple network segments or network nodes
together. A switch typically is located at layer 2 (data link layer) of the OSI model ( see ISO/IEC
7498-1 [14]). Modern switches, especially those designed for use in larger networks, typically
provide interfaces for configuration management and network management. These interfaces may
support the configuration of the switch (for example web-based via HTTP/HTTPS, file-based via
FTP/SFTP, command-line-based via SSH or via simple network management protocol ( SNMP)) as
well as log and event management (for example via syslog).
2974
2975
A.1.2.2
2976
2977
2978
2979
2980
2981
2982
2983
2984
2985
2986
2987
2988
2989
2990
Virtual private networks are logical networks that allow for the extension of private networks across
distances that are bridged by public networks. The use of the public network to co ver the distance
is transparent/invisible to the VPN users. VPNs are established by creating a logical tunnel at the
border of the two segments of the private network. The tunnel is established by VPN terminators,
which are devices located at the network border. The data packets from one segment are
encapsulated (commonly also encrypted) at the VPN terminator at then sent through a public
network to the peer VPN terminator. There, the encapsulation is removed (usually involving
decryption) and the original packet is recovered and forwarded into the local network segment.
VPNs are also often used to allow roaming users secure access to resources on their home
network. In this scenario, a client software on the roaming device acts as a local VPN terminator,
encapsulating (and usually encrypting) all data packets and forwarding them to the VPN terminator
on the home network border. Establishment of the tunnel between VPN terminators should be
authenticated, which, in the scenario of roaming users , typically is a user-based authentication.
Hence, VPN terminators may be used to collect data about roaming users , which may allow tracing
their location and other privacy related data.
2991
A.1.3
2992
A.1.3.1
2993
2994
2995
2996
2997
2998
2999
3000
3001
3002
3003
3004
3005
Operator workstations are used in control systems to displa y process information to human users
or operators and to allow them to interact with the control system ( for example initiate operational
actions on the process, such as opening a valve, closing a switch, modifying process set points ,
etc.). Depending on the respective operational requirements, operator workstations are often
required to be continuously available (at least a minimum set of workstations out of all installed
ones) to allow for an uninterrupted view of the process conditions and the opportunit y to interact
with the process immediately, if necessary. In order to obtain the data to be displayed and to send
the commands issued by the human user, operator workstations typically communicate with control
servers and connectivity servers in the control systems, sometimes they also directly communicate
with PLCs. This communication is commonly using Ethernet and TCP/IP-based protocols. Operator
workstations typically do not have to meet hard-real time requirements, but have high integrity and
(at least as a set of operator workstations) high availability requirements. They are typically built
from COTS PC hardware and run COTS client operating systems.
3006
A.1.3.2
3007
3008
3009
3010
3011
3012
3013
3014
3015
Data historians are used in control systems to collect and maintain long -term process history data.
This data is commonly collected from control servers or directly from PLCs using protocols based
on Ethernet and TCP/IP. The data may be used in a variety of analyses, for example, for process
optimization or performance reporting but may also be used in reporting to regulatory entities such
as emission reporting or documentation of the product's production process integrity ( for example,
as required by the US Food and Drug Administration ( FDA) regulations for pharmaceutical
products). They are typically built from COTS PC/server hardware and run COTS client/server
operating systems. Data is commonly stored using COTS database products. Communication to
data access clients and data sources is commonly using TCP/IP-based protocols. Depending on
Virtual Private Network (VPN) terminator (expanded from Electropedia definition
732-01-10)
Device category: host device/application
Operator workstation
Data historian
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
Switch (expanded from Electropedia definition 732-01-22)
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
3016
3017
the criticality of the process history from a business perspective, data historians have moderate
availability and integrity requirements and typically no hard real -time requirements.
Annex B
(informative)
Mapping of CRs and REs to FR SL levels 1-4
3018
3019
3020
B.1
Overview
3022
3023
This annex is intended to provide overall guidance to the reader as to how SL levels 0 to 4 are
differentiated on an FR-by-FR basis via the defined CRs and their associated REs.
3024
B.2
3025
3026
3027
3028
3029
3030
3031
3032
3033
3034
Table B.1 indicates which component level requirements apply to which FRs for a given component
security level capability SL SL-C(xx, component). For a given FR, the required comp onent level
requirements to meet a given SL-C are denoted by a check mark. Thus, as an example, the SL=1
component security capabilities for FR 5 (or SL-C(RDF, component)=1), would include the base
requirements of all four defined CRs. A component unable t o meet all four of these CRs would have
an SL-C(RDF, component)=0. To meeting SL-C(RDF, component)=2, a system needs to support
the four CR base requirements plus RE(1) of CR 5.1 and CR 5.2. As another example, only the CR
6.1 base requirement is required to meet SL-C(TRE, component)=1, but both SRs defined are
required in order to meet SL-C(TRE, component)=2. Refer to ISA 62443 3 3 Annex A for how a
full SL vector would be denoted.
3035
For clarification the following acronyms are used in the table:
SL mapping table
3036
CR
3037
SAR
Software application requirement
3038
EDR
Embedded device requirement
3039
HDR
Host device requirement
3040
NDR
Network device requirement
3041
Component requirement which is common to all types of components
Table B.1
Mapping of CRs and REs to FR SL levels 1-4
SRs and Res
FR 1
CR 1.1
Identification and authentication control (IAC)
Human user identification and
authentication
RE (1) Unique identification and authentication:
RE (2) Multifactor authentication for all
interfaces
CR 1.2
Software process and device identification
and authentication
RE (1) Unique identification and authentication
CR 1.3
Account management
CR 1.4
Identifier management
CR 1.5
Authenticator management
SL 1
SL 2
SL 3
SL 4
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
3021
RE (1) Hardware security for authenticators
NDR 1.6
Wireless access management
3042
Table B.1
Mapping of SRs and REs to FR SL levels 1-4
SRs and Res
CR 1.7
Strength of password-based
authentication
RE (1) Password generation and lifetime
restrictions for human users
RE (2) Password lifetime restrictions for all
users (human, software process, or
device)
CR 1.8
Public key infrastructure certificates
CR 1.9
Strength of public key-based
authentication
RE (1) Hardware security for public key-based
authentication
CR 1.10
Authenticator feedback
CR 1.11
Unsuccessful login attempts
CR 1.12
System use notification
NDR 1.13
Access via untrusted networks
RE (1) Explicit access request approval
CR 1.14
Strength of symmetric key-based
authentication
RE (1) Hardware security for symmetric keybased authentication
FR 2
CR 2.1
Use control (UC)
Authorization enforcement
RE (1) Authorization enforcement for all users
(humans, software processes and
devices)
RE (2) Permission mapping to roles
RE (3) Supervisor override
RE (4) Dual approval
CR 2.2
Wireless use control
CR 2.3
Use control for portable and mobile
devices
SL 1
SL 2
SL 3
SL 4
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
RE (1) Unique identification and authentication
Table B.1
Mapping of SRs and REs to FR SL levels 1-4
SRs and Res
Mobile code
RE (1) Mobile code integrity check
HDR 2.4
Mobile code
NDR 2.4
Mobile code
CR 2.5
Session lock
CR 2.6
Remote session termination
CR 2.7
Concurrent session control
CR 2.8
Auditable events
CR 2.9
Audit storage capacity
RE (1) Warn when audit record storage
capacity threshold reached
CR 2.10
Response to audit processing failures
CR 2.11
Timestamps
RE (1) Time synchronization
RE (2) Protection of time source integrity
CR 2.12
Non-repudiation
RE (1) Non-repudiation for all users
EDR 2.13 Use of physical diagnostic and test
interfaces
RE (1) Active monitoring
HDR 2.13 Use of physical diagnostic and test
interfaces
RE (1) Active monitoring
NDR 2.13 Use of physical diagnostic and test
interfaces
RE (1) Active monitoring
FR 3
SL 3
SL 4
Mobile code
RE (1) Mobile code integrity check
EDR 2.4
SL 2
System integrity (SI)
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
SAR 2.4
SL 1
Table B.1
Mapping of SRs and REs to FR SL levels 1-4
SRs and Res
SAR 3.2
Protection from malicious code
EDR 3.2
Protection from malicious code
HDR 3.2
Protection from malicious code
RE (1) Report version of code protection
NDR 3.2
Protection from malicious code
Security functionality verification
RE (1) Security functionality verification during
normal operation
CR 3.4
Software and information integrity
RE (1) Authenticity of software and information
RE (2) Automated notification of integrity
violations
CR 3.5
Input validation
CR 3.6
Deterministic output
CR 3.7
Error handling
CR 3.8
Session integrity
RE (1) Invalidation of session IDs after session
termination
RE (2) Unique session ID generation
RE (3) Randomness of session IDs
CR 3.9
SL 3
SL 4
Communication integrity
RE (1) Communication authentication
CR 3.3
SL 2
Protection of audit information
RE (1) Audit records on write-once media
EDR 3.10
Support for updates
RE (1) Update authenticity and integrity
HDR 3.10
Support for updates
RE (1) Update authenticity and integrity
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
CR 3.1
SL 1
Table B.1
Mapping of SRs and REs to FR SL levels 1-4
SRs and Res
EDR 3.11 Physical tamper resistance and
detection
RE (1) Notification of a tampering attempt
HDR 3.11 Physical tamper resistance and
detection
RE (1) Notification of a tampering attempt
NDR 3.11 Physical tamper resistance and
detection
RE (1) Notification of a tampering attempt
EDR 3.12 Provisioning product supplier roots of
trust
HDR 3.12 Provisioning product supplier roots of
trust
NDR 3.12 Provisioning product supplier roots of
trust
EDR 3.13
Provisioning asset owner roots of trust
HDR 3.13
Provisioning asset owner roots of trust
NDR 3.13
Provisioning asset owner roots of trust
EDR 3.14
Integrity of the boot process
RE (1) Authenticity of the boot process
Integrity of the boot process
RE (1) Authenticity of the boot process
NDR 3.14
Integrity of the boot process
RE (1) Authenticity of the boot process
FR 4
SL 3
SL 4
Support for updates
RE (1) Update authenticity and integrity
HDR 3.14
SL 2
Data confidentiality (DC)
CR 4.1
Information confidentiality
CR 4.2
Information persistence
RE (1) Erase of shared memory resources
RE (2) Erase verification
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
NDR 3.10
SL 1
Table B.1
Mapping of SRs and REs to FR SL levels 1-4
SRs and Res
FR 5
Restricted data flow (RDF)
Network segmentation
NDR 5.2
Zone boundary protection
RE (1) Deny all, permit by exception
RE (2) Island mode
RE (3) Fail close
NDR 5.3 General purpose, person-to-person
communication restrictions
CR 6.1
Timely response to events (TRE)
Audit log accessibility
RE (1) Programmatic access to audit logs
CR 6.2
FR 7
CR 7.1
Continuous monitoring
Resource availability (RA)
Denial of service protection
RE (1) Manage communication load from
component
CR 7.2
Resource management
CR 7.3
Control system backup
RE (1) Backup integrity verification
RE (2) Local backup
CR 7.4
Control system recovery and
reconstitution
CR 7.6
Network and security configuration
settings
RE (1) Machine-readable reporting of current
security settings
3043
SL 3
SL 4
Use of cryptography
CR 5.1
FR 6
SL 2
CR 7.7
Least functionality
CR 7.8
Control system component inventory
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
CR 4.3
SL 1
3045
3046
3047
3048
3049
NOTE
3050
References to other parts, both existing and anticipated, of the ISA 62443 series:
3051
3052
NOTE
Some of these references are normative references (see Clause 2), published documents, in development, or
anticipated. They are all listed here for completeness of the currently authorized parts of the ISA 62443 series.
3053
3054
[1]
ANSI/ISA 62443 1 1 (99.01.01), Security for industrial automation and control systems,
Part 1-1: Concepts and models 3
3055
3056
[2]
ANSI/ISA TR62443 1 2 (TR99.01.02), Security for industrial automation and control
systems, Part 1-2: Master glossary of terms and abbreviations
3057
3058
[3]
ANSI/ISA 62443 1 3 (99.01.03), Security for industrial automation and control systems,
Part 1-3: System security conformance metrics
3059
3060
[4]
ANSI/ISA TR62443 1 4 (TR99.01.04), Security for industrial automation and control
systems, Part 1-4: IACS security life-cycle and use-cases
3061
3062
[5]
ANSI/ISA 62443 2 1 (99.02.01), Security for industrial automation and control systems,
Part 2-1: Requirements for an IACS security management system 3
3063
3064
[6]
ANSI/ISA TR62443 2 2 (TR99.02.02), Security for industrial automation and control
systems, Part 2-2: Implementation guidance for an IACS security management system
3065
3066
[7]
ANSI/ISA TR62443 2 3 (TR99.02.03), Security for industrial automation and control
systems, Part 2-3: Patch management in the IACS environment
3067
3068
[8]
ANSI/ISA 62443 2 4 (99.02.04), Security for industrial automation and control systems,
Part 2-4: Requirements for IACS solution suppliers
3069
3070
[9]
ANSI/ISA TR62443 3 1 (TR99.03.01), Security for industrial automation and control
systems, Part 3-1: Security technologies for IACS3
3071
3072
[10]
ANSI/ISA 62443 3 2 (99.03.02), Security for industrial automation and control systems,
Part 3-2: Security risk assessment and system design
3073
3074
[11]
ANSI/ISA 62443 3 3 (99.03.03), Security for industrial automation and control systems,
Part 3-3: System security requirements and security levels
3075
3076
[12]
ANSI/ISA 62443 4 1 (99.04.01), Security for industrial automation and control systems,
Part 4-1: Product development requirements
3077
3078
NOTE
This standard is ANSI/ISA 62443 4 2 (99.04.02), Security for industrial automation and control systems:
Part 4-2, Technical security requirements and for IACS components
3079
Other standards references:
3080
[13]
This bibliography includes references to sources used in the creation of this standard as well as references to
sources that may aid the reader in developing a greater understanding of cyber security as a whole and
developing a management system. Not all references in this bibliography are referred to throughout the text of
this standard. The references have been broken down into different categories depending on the type of source
they are.
ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards
3 Currently under revision.
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
BIBLIOGRAPHY
3044
3081
3082
[14]
ISO/IEC 7498-1:1994, Information technology
Reference Model: The Basic Model
Open Systems Interconnection
Basic
3083
3084
[15]
ISO/IEC 8601:2004, Data elements and interchange formats
Representation of dates and times
3085
3086
[16]
ISO/IEC 15408-1:2009, Information technology Security techniques
for IT security Part 1: Introduction and general model
3087
3088
[17]
ISO/IEC 19790:2012, Information technology
requirements for cryptographic modules
Security techniques
Security
3089
3090
[18]
ISO/IEC 27002:2013, Information technology
information security management
Security techniques
Code of practice for
3091
[19]
IEC 60050, International Electrotechnical Vocabulary , or Electropedia
3092
[20]
IEC 61131-3, Programmable controllers
3093
3094
[21]
IEC TR 61850-1:2013, Communication networks and systems for power utility automation
Part 1: Introduction and overview
3095
3096
[22]
ANSI/ISA-95.00.01-2010 (IEC 62264-1 Mod) Enterprise-Control System Integration
Part 1: Models and Terminology
3097
[23]
ISO/IEC 11889-1:2015, Trusted platform module library
Evaluation criteria
Part 3: Programming languages
Part1: Architecture
3098
3099
Other documents and published resources:
3100
[24]
FIPS 140-2, Security Requirements for Cryptographic Modules
3101
[25]
NIST SP 800-57, Recommendation for Key Management, Part 1: General
3102
[26]
NIST SP 800-92, Guide to Computer Security Log Management
3103
[27]
NIST SP800-63-2, Electronic Authentication Guideline (A ugustl 2013)
3104
Websites:
3105
3106
[28]
OWASP Code Review Guide, available at <
https://www.owasp.org/index.php/Code_Review_Guide >>
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.
Information interchange
This information is to be used solely for the purpose of supporting the further development of ISA-62443 standards.
It is subject to change without notice. It may not be reproduced or distributed to others, offered for sale, or used for commercial purposes.