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 TR62443 0-3
Security for industrial automation and control systems:
Gap assessment of ANSI/ISA-99.02.01-2009
Draft 1, Edit 10
June 2012
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
ISA TR62443 0 3 (June 2012)
2
ISA99, WG5, TG2
2
3
ISA TR62443 0 3 (June 2012)
Security for industrial automation and control systems
Gap assessment of ANSI/ISA-99.02.01-2009
Copyright © 2012 by the International Society of Automation (ISA). 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, 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.
4
3
ISA TR62443 0 3 (June 2012)
5
PREFACE
6
7
This preface, as well as all footnotes and annexes, is included for information purposes and is not
part of ISA TR62443 0 3.
8
9
10
11
12
13
This document has been prepared as part of the service of ISA 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) 5498411; Fax (919) 549-8288; E-mail: standards@isa.org.
14
15
16
17
18
19
20
21
22
23
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. Toward this end, this Department
will endeavour 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 & Materials as IEEE/ASTM SI 10-97, and future revisions, will be the
reference guide for definitions, symbols, abbreviations, and conversion factors.
24
25
26
27
28
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.
29
30
31
32
33
CAUTION
ISA does not take any position with respect to the existence or validity of any
patent rights asserted in connection with this document, and ISA disclaims liability for the
infringement of any patent resulting from the use of this document. Users are advised that
determination of the validity of any patent rights, and the risk of infringement of such
rights, is entirely their own responsibility.
34
35
36
37
38
39
nt holders or patent applicants may have
disclosed patents that could be infringed by use of this document and executed a letter of
assurance committing to the granting of a license on a worldwide, non -discriminatory
basis, with a fair and reasonable royalty rate and fair and reasonable terms and conditions.
For more information on such disclosures and letters of assurance, contact ISA or visit
www.isa.org/standardspatents.
40
41
42
43
44
45
Other patents or patent claims may exist for which a disclosure or letter of assurance has
not been received. ISA is not responsible for identifying patents or patent applications for
which a license may be required, for conducting inquiries into the legal validity or scope of
patents, or determining whether any licensing terms or conditions provided in connection
with submission of a letter of assurance, if any, or in any licensing agreements are
reasonable or non-discriminatory.
46
47
48
ISA requests that anyone reviewing this document who is aware of any patents that may
impact implementation of the document notify the ISA standards and practices department
of the patent and its owner.
49
50
51
52
53
Additionally, the use of this document may involve hazardous materials, operations or
equipment. The document cannot anticipate all possible applications or address all
possible safety issues associated with use in hazardous conditions. The user of this
document must exercise sound professional judgment concerning its use and applicability
the applicability 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.
ISA99, WG5, TG2
4
ISA99, WG5, TG2
54
55
any governmental regulatory limitations and established safety and health practices before
implementing this document.
56
57
58
The user of this document should be aware that this document may be impacted by
electronic security issues. The committee has not yet addressed the potential issues in
this version.
59
60
The following people served as active members of ISA99, Working Group 5, Task Group 2 for the
preparation of this document:
Name
Company
Eric Byres, task group Chair
Tofino Security
X
Mike Baldi
Honeywell
X
Thurston Brooks
Ultra Electronics (3eti)
X
Marcelo Branquinho
TI Safe
X
Penny Conklin
Chevron Information Technology
X
John Cusimano
Exida
X
Jean Pierre Dalzon
61
62
Contributor
X
Andrew Ginter
Waterfall Security Solutions
X
Suzanne de Grooth- Verlijsdonk
Actemium
X
Mark Heard
Eastman Chemical
X
Ken Jones
DB Consulting
X
Jan Kaestner
Siemens
X
Ken Keiser
Siemens
X
Joel Langill
ScadaHacker.com
X
John Munro Jr
ORNL
X
Mark Norrell
CH2M Hill
X
Charles Obst
Bechtel
X
Symantec
X
Brian Owen
OSISoft
X
Andy Qin
Cisco
X
Ernie Rakaczky
Invensys
X
Charley Robinson
ISA
X
Rajesh Shah
ERS Consultancy
X
Omar Sherin
ictQATAR
X
Joe Weiss
Applied Control Solutions, LLC
X
Randy Woods
The Dow Chemical Company
X
Reviewer
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 TR62443 0 3 (June 2012)
ISA99, WG5, TG2
5
ISA TR62443 0 3 (June 2012)
CONTENTS-
63
65
PREFACE ...............................................................................................................................3
66
1
67
1.1
Overview.................................................................................................................7
1.2
Background.............................................................................................................7
1.3
Purpose ..................................................................................................................7
1.4
Objectives ...............................................................................................................7
1.5
Assumptions and limitations ....................................................................................8
1.6
Approach ................................................................................................................8
1.7
Terminology substitutions in the following material ..................................................8
2
Review of ANSI/ISA-99.02.01-2009 requirements ............................................................8
68
69
70
71
72
73
74
Introduction .....................................................................................................................7
101
2.1
Organization of this section .....................................................................................8
2.2
Clause 4.2 Category: Risk analysis ......................................................................9
2.3
Clause 4.2.2 Element: Business rationale ............................................................9
2.4
Clause 4.2.3 Element: Risk identification, classification and assessment ...........10
2.5
Clause 4.3 Category: Addressing risk with the CSMS .........................................10
2.6
Clause 4.3.2 Element group: Security policy, organization and awareness .........10
2.7
Clause 4.3.2.2 Element: CSMS scope ................................................................11
2.8
Clause 4.3.2.3 Element: Organizing for security .................................................11
2.9
Clause 4.3.2.4 Element: Staff training and security awareness ...........................12
2.10 Clause 4.3.2.5 Element: Business continuity plan ..............................................12
2.11 Clause 4.3.2.6 Element: Security policies and procedures .................................13
2.12 Clause 4.3.3 Element group: Selected security countermeasures .......................14
2.13 Clause 4.3.3.2 Element: Personnel security .......................................................14
2.14 Clause 4.3.3.3 Element: Physical and environmental sec urity ............................15
2.15 Clause 4.3.3.4 Element: Network segmentation .................................................15
2.16 Clause 4.3.3.5 Element: Access control: Account administration ........................16
2.17 Clause 4.3.3.6 Element: Access control: Authentication .....................................17
2.18 Clause 4.3.3.7 Element: Access control: Authorization .......................................18
2.19 Clause 4.3.4 Element group: Implementation .....................................................18
2.20 Clause 4.3.4.2 Element: Risk management and implementation .........................19
2.21 Clause 4.3.4.3 Element: System development and maintenance ........................19
2.22 Clause 4.3.4.4 Element: Information and document management .......................20
2.23 Clause 4.3.4.5 Element: Incident planning and response ...................................20
2.24 Clause 4.4 Category: Monitoring and improving the CSMS .................................20
2.25 Clause 4.4.2 Element: Conformance ..................................................................21
2.26 Clause 4.4.3 Element: Review, improve and maintain the CSMS ........................21
3
Conclusions and Final Remarks .....................................................................................21
102
4
103
BIBLIOGRAPHY ...................................................................................................................25
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
100
104
105
Revision History ............................................................................................................23
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.
64
6
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 TR62443 0 3 (June 2012)
ISA99, WG5, TG2
106
ISA99, WG5, TG2
7
ISA TR62443 0 3 (June 2012)
107
1
Introduction
108
1.1
109
110
111
112
113
114
115
ISA99 Work Group 5, Task Group 2 (WG5 TG2) was formed in January 2011 to conduct a gap
analysis of the current ISA/IEC 62443 1 standards with respect to the rapidly evolving threat
landscape, as demonstrated by the highly publicized Stuxnet malware. The purpose was to
determine if companies following these standards wo uld have been protected from such
sophisticated attacks and to identify changes needed, if any, to the standards being developed by
the ISA99 committee. This technical report describes the findings of this gap analysis of the
ANSI/ISA-99.02.01-2009 2 [5] standard.
116
1.2
117
118
119
120
121
122
Stuxnet is a highly sophisticated computer worm that was f irst detected in the summer of 2010. It
is the first known malware to have been specifically written with the intent to compromise a
123
124
125
126
127
The ISA-62443 and IEC 62443 standards address the vital issue of cyber security for IACS. The
standards describe the basic concepts and models related to cyber security, as w ell as the
elements contained in an industrial automation and control system security management system
(IACS-SMS) for use in the IACS environment. They also provide guidance on how to meet the
requirements described for each element.
128
129
130
131
132
133
134
135
The ISA-62443 standards form the base documents for the IEC 62443 series of industrial
automation (sometimes generically labelled as supervisory control and data acquisition (SCADA) )
security standards. These standards will become core standards for protecting critical industrial
infrastructures and industrial complexes that directly impact human health, safety and the
environment (HSE). They likely will be extended to other areas of applica tion, even broader than
those generically labelled SCADA. Thus, it is essential that companies with IACS that follow the
62443 standards know they will have a reasonable chance of protecting themselves from Stuxnet like malware and other advanced persistent threats (APTs).
136
1.3
137
138
139
140
141
142
143
Every new worm, virus or hack has evolved from previous ones. Cyber hackers and criminals
learn from their successes and mistakes so they can build more effective attacks. The IACS
community also has to learn from experience or it will be left far behind in the malware arms race.
For this reason, effective cyber security programs must develop a continuous process of
assessment, implementation, validation and correction. Stuxnet provides the perfect opportunity
to learn how the 62443 standards will stand up to the advanced persistent threats that will appear
in the future and how the standards can be improved.
144
1.4
145
146
147
148
149
The objective of the task group in creating this report was to perform a gap analysis of ANSI/ISA99.02.01-2009 using the Stuxnet malware as the adversary to be defended against. The intent
was to determine if there were any requirements of the standard that, if followed, would still leave
a company unprotected from a sophisticated attack. Once identified, these gaps were then used
to recommend improvements in the ISA 62443 2 1 standard to assist in future editions.
Background
documented in the press and some capabilities may migrate or evolve into new threats. Going
forward, industrial automation and control systems (IACS) must be able to not only block, but also
detect and minimize the consequences from advanced Stuxnet -like threats.
Purpose
Objectives
1 The series of standards originally referred to as ISA-99.xx.yy has been renumbered as ISA-62443-xx-yy to better
align with their IEC equivalents.
2 This standard will be retitled as ISA 62443 2 1 with the next edition. For the remainder of this report, it is referred to
under its designation at time of publication, ISA-99.02.01
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.
Overview
ISA TR62443 0 3 (June 2012)
8
ISA99, WG5, TG2
1.5
Assumptions and limitations
151
152
153
The task group assumed during the analysis that the IACS operator following this standard would
fulfil
154
155
156
157
158
It is important to note that this report considers only the ANSI/ISA-99.02.01-2009 standard. Thus
the focus of this report is the IACS-SMS requirements for IACS, which tend to be the people and
process elements of security. The task group is considering conducting gap analysis of other
62443 series documents on areas such as security technology and vendor requirements in the
future.
159
1.6
160
161
162
The task group initially collected independent analysis from the task group members on each
normative requirement in the ANSI/ISA-99.02.01-2009 standard. Assessment information
collected included the following:
163
164
1) Requirements impact on Stuxnet: Describe how this requirement would or would not
have reduced the success or severity of the Stuxnet attack (Text Field)
165
166
167
168
2) Requirements effectiveness: In the context of Stuxnet infecting/attacking an organization
that has met the MINIMUM requirements, score how much this requirement would have
reduced the severity of the attack. In other words, what is the risk reduction factor? (Text
Field)
169
170
171
3) Requirement relevance: In the context of Stuxnet infecting/attacking an organization that
has met the MINIMUM requirements, what aspect of IACS security would this requirement
have addressed? (Check Box)
172
173
174
4) Stuxnet phase affected by requirement: What phase(s) of Stuxnet
organization would this requirement have addressed? (Selection from the following:
Installation, Infection, Propagation, Detection Avoidance, Attack)
175
176
5) Additional comments on this requirement: Add any additional comments about this
requirement, possible gaps and how it might need modification. (Text Field)
177
178
179
180
181
182
In the second stage, the task group reviewed each section of the published ANSI/ISA-99.02.012009 standard, along with the appropriate Annex s ection, to see if that section would have helped
mitigate either Stuxnet or a Stuxnet-like attack. If not, the task group then developed
recommendations on how the standard might be strengthened. In addition, general comments on
the structure and readability of each section were provided in order to assist in future editions of
the standard.
183
1.7
184
185
186
187
188
189
-SMS)
used in the preceding part of this document reflects terminology consistent with the ISO/IEC
27000 series of cyber security standards. The 62443 standards are being revised to use that
consistent terminology. However, ANSI/ISA-99.02.01-2009, which is the subject of this review,
, so that term is used
consistently in the following quoted text.
190
191
NOTE: The next edition of ANSI/ISA-99.02.01-2009
192
2
193
2.1
194
195
The title of each of the following sections indicates the section in the ANSI/ISA-99.02.01-2009
document that was evaluated. Each of the sections are then broken down into four subsections:
Approach
Terminology substitutions in the following material
-SMS.
Review of ANSI/ISA-99.02.01-2009 requirements
Organization of this section
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.
150
ISA99, WG5, TG2
Purpose of this section (from ANSI/ISA-99.02.01-2009)
reader;
ISA TR62443 0 3 (June 2012)
Purpose statement copied from the document to aid the
198
1) Identified gaps
199
200
2) Specific recommendations Specific suggestions from the task group on improving the
requirement to handle a Stuxnet-like attack; and
201
202
203
3) Additional comments and recommendations
Any additional comments and
recommendations by the task group related to the particular section in ANSI/ISA-99.02.012009.
Clause 4.2
Gaps that were identified in the section of ANSI/ISA-99.02.01-2009;
204
2.2
Category: Risk analysis
205
2.2.1
206
207
208
The first main category of the CSMS is risk analysis. This category discusses much of the
background information that feeds into many of the other elements in the CSMS. There are two
elements in this category:
Purpose of this section (from ANSI/ISA-99.02.01-2009)
209
Business rationale
210
Risk identification, classification, and assessment
211
2.2.2
Identified gaps
212
213
214
a) task group discussed that while scope is part of the CSMS design recommendations, there
is no discussion of scope in risk assessment or vulnerability assessment
recommendations.
215
216
217
b) task group observed that many people using the standard do not appear to understand the
difference between a risk assessment and a vulnerability assessment, even though the
requirements are very clear.
218
2.2.3
Specific recommendations
219
220
c) Additional text or a diagram is needed to clarify the difference between a risk assessment and
a vulnerability assessment.
221
2.2.4
Additional comments and recommendations
222
223
224
225
a) The task group agreed that section 4.2 of the standard provides good guidance, but may
not be followed in actual practice. In particular, ANSI/ISA-99.02.01-2009 clearly separates
t in both section 4 and in Annex A.
226
227
228
229
It is the opinion of the task group that in practice, many organizations appear to skip this
risk assessment and go straight to a vulnerability assessment, resulting in a solution of
blanket security controls, rather than the risk-based approach mandated in ANSI/ISA99.02.01-2009.
230
231
b) The task group discussed some editorial issues of the Annex A, and the following concerns
were noted:
232
233
234
235
236
4) Annex A is less formal than is warranted in some places. For example, the risk
analysis section seemed to imply that one should cho ose personnel from the industrial
site and teach them how to do risk assessments, rather than using experienced
professionals combined with a cross functional team from the site consisting of both
internal and external resources.
237
238
5) The examples in Annex A do not consistently describe "worst-case" or "high-threat"
scenarios.
239
2.3
Clause 4.2.2
Element: Business rationale
240
2.3.1
241
Identify and document the unique needs of an organization to address cyber risk for IACS.
Purpose of this section (from ANSI/ISA-99.02.01-2009)
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.
196
197
9
ISA TR62443 0 3 (June 2012)
2.3.2
2.3.3
Specific recommendations
None
246
247
Identified gaps
a) This is a clear prerequisite for all other requirements and is necessary but not sufficient to
secure an IACS. There is likely no gap in this requirement.
243
244
245
ISA99, WG5, TG2
2.3.4
Additional comments and recommendations
a) Additional clarity would be useful in explaining that the business case may change over
time and will need revisiting.
248
249
250
2.4
Clause 4.2.3
Element: Risk identification, classification and assessment
251
2.4.1
252
253
Identify the set of IACS cyber risks that an organization faces and assess the likeliho od and
severity of these risks.
254
2.4.2
Purpose of this section (from ANSI/ISA-99.02.01-2009)
Identified gaps
a) This requirement is a clear prerequisite for all other requirements and is necessary but not
sufficient to secure an IACS. There is likely no gap in this requirement.
255
256
257
2.4.3
258
None
259
2.4.4
Specific recommendations
Additional comments and recommendations
None
260
261
2.5
Clause 4.3
Category: Addressing risk with the CSMS
262
2.5.1
263
264
265
The second main category of the CSMS is addressing risk with the CSMS. This category contains
the bulk of the requirements and information contained in the CSMS. It is divided into three
element groups:
Purpose of this section (from ANSI/ISA-99.02.01-2009)
266
Security policy, organization and awareness
267
Selected security countermeasures
268
Implementation
269
2.5.2
None
270
271
2.5.3
Specific recommendations
None
272
273
Identified gaps
2.5.4
Additional comments and recommendations
None
274
275
2.6
276
2.6.1
277
278
279
The first element group in this category discusses the development of the basic cyber security
policies, the entities responsible for cyber security, and the awareness within the organization of
cyber security issues. The five elements in the element group:
280
Clause 4.3.2
Element group: Security policy, organization and awareness
Purpose of this section (from ANSI/ISA-99.02.01-2009)
CSMS scope
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.
242
10
11
281
Organizing for security
282
Staff training and security awareness
283
Business continuity plan
284
Security policies and procedures
285
2.6.2
2.6.3
Specific recommendations
None
288
289
Identified gaps
None
286
287
ISA TR62443 0 3 (June 2012)
2.6.4
Additional comments and recommendations
None
290
291
2.7
Clause 4.3.2.2
Element: CSMS scope
292
2.7.1
293
294
Identify, assess, and document the systems, processes, and organizat ions to which the CSMS
applies.
295
2.7.2
Purpose of this section (from ANSI/ISA-99.02.01-2009)
Identified gaps
296
297
298
299
300
301
302
a) There is no guidance in these requirements regarding what should be considered in scope
in a CSMS project. As a result, components that are
-of-
303
304
b) The task group observed that Annex A.3.2.2.3 "Developing CSMS scope - Suggested
practices
-scope areas.
305
potential entry points such as connections to government monitoring systems or
contractors are not. These are partially addressed in
Developing CSMS
scope- Suggested practices but these are not normative requirements.
2.7.3
Specific recommendations
306
307
a) Normative guidance is needed to clarify what should be considered in scope in a CSMS
project.
308
309
b) Annex A.3.2.2.3 Developing CSMS scope - Suggested practices should list removable
media and portable devices in its baseline list of in-scope areas.
310
2.7.4
Additional comments and recommendations
None
311
312
2.8
313
2.8.1
314
315
Establish the entities responsible for managing, condu cting, and assessing the overall cyber
security of
316
2.8.2
317
318
319
320
321
Clause 4.3.2.3
Element: Organizing for security
Purpose of this section (from ANSI/ISA-99.02.01-2009)
Identified gaps
a) The task group is concerned that the description in Annex A.3.2.3.3 about a "cross functional team" to oversee a security program is too weak. A consensus -style group
without guidance or facilitation by a security professional did not seem the right way to
create a security program strong enough to deal with advanced threats exemplified by
Stuxnet.
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.
ISA99, WG5, TG2
ISA TR62443 0 3 (June 2012)
2.8.3
ISA99, WG5, TG2
Specific recommendations
323
324
325
a) It is recommended the following text
This
person shall have a high-level understanding of the current state of cyber secur ity
procedures in the company.
326
327
328
The project leader should be a professional who is knowledgeable of IACS security
standards and who can guide and facilitate discussions amongst the core team of
stakeholders.
329
2.8.4
None
330
331
2.9
332
2.9.1
333
334
335
336
337
Additional comments and recommendations
Clause 4.3.2.4
Element: Staff training and security awareness
Purpose of this section (from ANSI/ISA-99.02.01-20099)
Provide all personnel (including employees, contract employees and third -party contractors)
with the information necessary to identify, review, address and, where appropriate, remediate
vulnerabilities and threats to IACS and to help ensure their own work practices are u sing
effective countermeasures.
2.9.2
Identified gaps
338
339
a) The task group noted that the requirement for the security training is not IACS -focused in
any way. Thus it may not be appropriate for IACS security management.
340
341
342
b) The task group noted that Annex A.3.2.4 seems more focused on threat awareness than
on policies, procedures and processes training. The main requirement does not mention
procedures, though sub-requirement 4.3.2.4.2 does mention them.
343
344
2.9.3
Specific recommendations
a) The task group recommends that 4.3.2.4.1 be revised as follows:
345
346
347
appropriate to IACS requirements and conditions, with attention given t o the unique
348
349
b) The task group recommends that 4.3.2.4.1 and Annex A.3.2.4 be revised to place more
focus on policies, procedures and processes training for IACS security.
350
351
2.9.4
None
352
2.10
353
2.10.1
354
355
356
Additional comments and recommendations
Clause 4.3.2.5
Element: Business continuity plan
Purpose of this section (from ANSI/ISA-99.02.01-2009)
Identify procedures for maintaining and/or re -establishing essential business operations while
recovering from a significant disruption.
2.10.2
Identified gaps
357
358
359
360
a) The task group observed that this section was strongly focused on availability rather than
integrity. In considering a Stuxnet-like attack, it is highly possible that standard backups
may also be infected and the requirements and recommended practices would be
ineffective.
361
362
363
364
b) Techniques for ensuring there are non-infected backup media, and for restoring systems
from known-clean backups, system images and media on a known -clean network are
significantly different from conventional "failed hardware" recovery procedures. The
standard does not address this difference.
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.
322
12
13
ISA TR62443 0 3 (June 2012)
365
366
367
c) There are no requirements with regard to forensics and only a passing mention of the
topic in the associated Annex A.3.2.5. It is also briefly mentioned in Annex A.3.4.5.3
phase
practices
368
369
370
371
372
373
d) The task group noted that the discussion of backup and recovery is very data centric.
There is no discussion of a plan to secure a supply of replacement components if an
adversary has destroyed them. For example, attacks on certain PLCs in laboratory
settings have rendered the devices unusable and required that they be returned to the
manufacturer. Damage to writeable firmware images or EEPROM's in both conventional
computers and specialized devices can be irreparable.
374
2.10.3
Specific recommendations
375
376
377
378
a) The task group recommends that, at a minimum, Annex A.3.2.5 should be rewritten to
discuss recovering from a corrupted backup or system whose data integrity has been
compromised. Procedures need to not only protect the integrity of backup data in storage,
but also ensure no re-compromise of equipment during the recovery process.
379
380
b) The task group recommends that there be normative requirements for post-event analysis
and/or forensics and discussion of this topic in the Annex.
381
382
383
c) The task group recommends that the discussion of backup and recovery be expanded
beyond simply data recovery planning. There should be discussion on creating plans to
secure a supply of replacement key components should an adversary destroy them.
384
385
386
387
388
389
d) Consider adding text mandating the replacement of systems or software in system with
high safety or reliability requirements. For example, When system integrity (firmware,
software, configuration) has been compromised in systems demanding high safety or
reliability, the system (firmware, software, configuration) should be restored from
manufacturer-provided system images and not from backup images. If this is not possible,
390
2.10.4
Additional comments and recommendations
391
392
393
a) The task group believes that this section is not correctly locat ed in the standard and would
394
395
396
b) The task group
really a disaster recovery plan rather than a business continuity plan. The task group
recommends that, this section be significantly reviewed and revised.
397
c) Define BCP and mention that a DRP is part of a BCP. Also, add a d efinition for DRP.
398
399
d) The task group would like to see terms with more emphasis than "significant disruption"
be used in A.3.2.5.2.
400
2.11
401
2.11.1
402
403
404
405
406
407
408
409
410
411
412
413
Clause 4.3.2.6
Element: Security policies and procedures
Purpose of this section (from ANSI/ISA-99.02.01-2009)
Address how an organization defines security, operates its security program, defines and
addresses its tolerance for risk, and reviews its progra m to make further improvements.
2.11.2
Identified gaps
a) The task group observed that there are neither requirements nor discussions regarding
addressing acceptable non-conformance to policy. For example, corporate IACS policy
might forbid the use of USB storage devices. However, due to the nature of some
equipment, staff may have no choice but to use USB storage devices, even if policy
forbids them. How this would be resolved in the context of the CSMS needs to be
addressed.
2.11.3
Specific recommendations
a) The task group recommends that requirements and discuss ion of the process for
determining and managing acceptable non-conformance to policy be added.
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.
ISA99, WG5, TG2
ISA TR62443 0 3 (June 2012)
414
415
416
417
b) The task group
418
419
420
421
c) The task group
423
2.12
424
2.12.1
Additional comments and recommendations
Clause 4.3.3
Element group: Selected security countermeasures
Purpose of this section (from ANSI/ISA-99.02.01-2009)
The second element group within this category is selected security countermeasures. The
elements within this group discuss some of the main types of security controls that are part of
a well-designed CSMS. This document does not attempt to describe the full implementation of
any of these selected security countermeasures. It discusses many of the policy, procedure,
and practice issues related to these particular security countermeasures. The six elements in
the element group:
431
Personnel security
432
Physical and environmental security
433
Network segmentation
434
Access control: Account administration
435
Access control: Authentication
436
Access control: Authorization
438
439
440
441
442
2.12.2
None
2.12.3
2.12.4
444
2.13.1
448
449
450
451
452
Additional comments and recommendations
None
2.13
447
Specific recommendations
None
443
445
446
Identified gaps
Clause 4.3.3.2
Element: Personnel security
Purpose of this section (from ANSI/ISA-99.02.01-2009)
Establish the policies and procedures to determine whether personnel will maintain the IACS
security of the organization throughout the lifecycle of their employment.
2.13.2
Identified gaps
None
2.13.3
Specific recommendations
None
2.13.4
Additional comments and recommendations
None
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.
2.11.4
437
ISA99, WG5, TG2
definition of policies and procedures as preceding training and disaster recovery. Thus
this section should precede those requirements in the standard document as well.
422
425
426
427
428
429
430
14
ISA99, WG5, TG2
2.14
454
2.14.1
455
456
457
458
459
460
461
462
463
464
Clause 4.3.3.3
ISA TR62443 0 3 (June 2012)
Element: Physical and environmental security
Purpose of this section (from ANSI/ISA-99.02.01-2009)
Create a secure environment for the protection of IACS assets. An asset is any physical or
logical object owned by or under the custodial duties of an organization, having either a
perceived or actual value to the organization (see ISA 62443 1 1 [2]). IACS assets are those
assets that are a part of the IACS, either physical or cyber or that can affect the operation of
the IACS. Physical security measures ensure that all assets, specifica lly those related to the
IACS of an organization, are protected physically from unauthorized access, loss, damage,
misuse, and the like. Environmental security measures ensure that the assets of an
organization are protected against environmental condition s that would make them unusable
or damage the information they contain.
2.14.2
Identified gaps
465
466
467
468
469
470
a) The task group noted that any discussion managing the movement of mobile media is
environmental security
associated Annex (even in the additional practices section). While mobile assets might be
considered either a data or physical security issue, the control of the movement of mobile
devices such as USB storage devices, CDs and laptops into a facility should be at least
referenced in this section, if not addressed with specific requirements.
471
472
473
474
475
b) The task group noted that a section about infiltration of electronic media into the site is
missing from the standard. Exfiltration of media and assets is speci fically covered in
Annex A.3.3.3, yet infiltration of media and assets is not. This is particularly important in
476
latter could have been transported via almost any form of mobile media.
2.14.3
Specific recommendations
477
478
479
a) The task group recommends that a section for establishing and managing the movement
of mobile media and portable devices should be included, ideally in the requirement
section, but, at a minimum, in the additional practices section of the related Annex.
480
481
b) The task group recommends that a section regarding the infiltration of electronic media
and portable devices into the site be added.
482
483
2.14.4
None
484
2.15
485
2.15.1
486
487
488
Additional comments and recommendations
Clause 4.3.3.4
Element: Network segmentation
Purpose of this section (from ANSI/ISA-99.02.01-2009)
Group and separate key IACS devices into zones with common security levels in order to
manage security risks, and to achieve a desired target secur ity level for each zone.
2.15.2
Identified gaps
489
490
491
492
a) The task group had significant concerns with the requirements in this section. The
absence of sufficient network segmentation was likely a key element of the Stuxnet
attack, and both the requirements and guidance in this section is minimal when compared
to other parts of the standard.
493
494
495
496
b) The absence of sufficient guidance relating to segmentation follows the earlier
497
498
499
c) The standard appears to minimize the need for good architectural design with the
and does not suf
countermeasure employed in conjunction with other layers of defence to reduce the risk
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.
453
15
ISA TR62443 0 3 (June 2012)
d) The task group noted that there was no mention that any allowed communications
represent potential attack channels. For example, t he text seemed to focus on IP-based
network traffic and did not mention other pathways such as mobile media or serial
communications. This is a serious limitation.
2.15.3
Specific recommendations
507
508
509
a) The task group recommends that additional requirements on network s egmentation be
added to ANSI/ISA-99.02.01-2009 or that the standard make reference to requirements in
other documents, such as ISA 62443 3 2 [9].
510
511
b) The task group recommends that ISA 62443 2 1 provide additional guidance on the
definition of essential communications.
512
513
c) The task group believes the segmentation requirements are insufficient with respect to
good segmentation practices. Suggestions for additional requirements include:
514
1) The organization shall identify and document security zones
515
2) The organization shall identify and document all conduits
516
3) The organization shall create an inventory of data flows between all zones
517
4) The organization shall define the assignment of security responsibility for each zone
518
519
d) The task group recommends that requirements regarding the applicability of additional
network controls, such as intrusion detection systems (IDS), be added.
520
521
522
e) The task group recommends that the discussion in A.3.3.4 should be updated to discuss
recent advances such as intrusion detection, unidirectional communications or industrial
protocol-aware filtering technology.
523
2.15.4
Additional comments and recommendations
524
525
526
a) The task group recommends all zone and conduit working groups should also be informed
regarding these recommendations so they can address the segmentation concerns raised
in section 2.15.2 of this document.
527
b) The implications of recommendation d) above should be considered in ISA TR62443 3 1
[8].
528
529
2.16
530
2.16.1
531
532
533
Clause 4.3.3.5
Element: Access control: Account administration
Purpose of this section (from ANSI/ISA-99.02.01-2009)
Ensure, on an ongoing basis, that only appropriate entities have accounts that allow access
and that these accounts provide appropriate access privileges.
2.16.2
Identified gaps
534
535
a) This section seems to be focused on individuals (humans) and not machine -to-machine or
system accounts.
536
537
538
539
b) The task group noted that there is no requirement in the ISA/IEC 62443 series requiring
vendors to disclose all pre-existing accounts, such as backdoor accounts, hidden
accounts, accounts created on installation, etc. Stuxnet made direct use of this type of
540
2.16.3
Specific recommendations
541
542
a) The task group recommends that applicable requirements be restated to refer to
543
544
b) The task group recommends that there should be a r equirement somewhere in the
ISA/IEC 62443 series requiring vendors to disclose all pre-existing or automatically
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.
506
ISA99, WG5, TG2
that may be as
This seems inappropriate in a normative document.
500
501
502
503
504
505
16
ISA99, WG5, TG2
2.16.4
a) The task group note that there is no mention of account password expiry. Even if there is
no expiry needed, the user needs to define this in their policy and procedures.
550
2.17
551
2.17.1
552
553
554
555
Additional comments and recommendations
Clause 4.3.3.6
Element: Access control: Authentication
Purpose of this section (from ANSI/ISA-99.02.01-2009)
Positively identify network users, hosts, applications, services, and resources for
computerized transaction so that they can be given the rights and responsibilities associated
with the accounts they have been granted under account administration.
2.17.2
Identified gaps
556
557
558
559
560
561
a) The task group believes that people are likely to read the "non -applicable" section in
Annex A.3.3.6.2 too literally and assume that this is giving permission for widespread
poor account management. The lessons from the analysis of Stuxnet suggests that these
policies should be applied to all equipment in the IACS and any e xceptions be clearly
justified.
562
563
564
565
b) The task group believes there is a significant risk that users will read this section as a
"one-size-fits-all" solution. For example, handling engineering station authentication in the
same way as HMI station authentication is probably unnecessary a nd is a poor security
practice.
566
567
c) There is no mention that additional measures should be considered for remotely
authenticated users, such as periodic log reviews, versus locally authenticated.
568
Review of the non-authenticated account controls noted the following:
569
570
571
572
573
a) The task group noted that IACS vendors often are not hardening supplied Microsoft
Windows
systems. Nor are the systems hardened by the end-user on acceptance from
the vendor. For example, null sessions and the use of named pipes for remote
communications on Windows computers used in IACS are commonly found during security
audits.
574
b) Requirements for authenticating on a machine with no credentials are not addressed.
575
576
c) This section seems to suggest that all users should be authenticated, but it misses the
question of unauthenticated software.
577
2.17.3
Specific recommendations
578
579
a) The task group recommends that the "non-applicable" section in Annex A.3.3.6.2 be either
removed or rewritten.
580
b) Discussion of role-based controls should be expanded in Annex A.3.3.6.
581
582
583
584
c) A requirement for the confirmation of account hardening should be added to this
document. (Note: while technically out of the scope of this TR, the addition of
requirements for vendors in the product development requirements standard
(ISA 62443 4 1 [11]) are also recommended).
585
586
d) Requirements for the additional measures needed for remotely authenticated users, such
as periodic log reviews, should be added.
587
588
e) Requirements in 4.3.3.6.3 that require strong authentication methods for system
administration and application configuration shoul d be extended to other systems.
589
590
f)
Add requirements or a discussion requiring compensating controls if strong authentication
is not available.
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.
548
549
ISA TR62443 0 3 (June 2012)
created accounts, what the purpose of each account is, and what the authentication
method is for each account.
545
546
547
17
ISA TR62443 0 3 (June 2012)
592
2.17.4
2.18
594
2.18.1
599
Additional comments and recommendations
None
593
595
596
597
598
ISA99, WG5, TG2
Clause 4.3.3.7
Element: Access control: Authorization
Purpose of this section (from ANSI/ISA-99.02.01-2009)
Grant access privileges to resources upon successful authentication of the user and
identification of his or her associated access account. The privileges granted are determined
by the account configuration set up during the account administratio n step in the business
process.
2.18.2
Identified gaps
600
601
602
603
a) The task group
access control for devices and applications. For example, device authentication would
have had a direct impact on Stuxnet propagation. There is a brief mention in A.3.3.6 .2,
but little in the normative sections and nothing in the Annex discussing authorization.
604
605
606
607
b) The separation between remote and local authorization is well covered in the Annex, but
is missing in the normative sections. Also supplemental guidance would help the user
understand and appreciate the range of issues and consequence regarding
authentication.
608
2.18.3
Specific recommendations
609
610
a) The task group recommends that the requirements be expanded to include access contro l
for devices and applications.
611
612
613
614
b) Once a user/application/device is authenticated and authorized, then there should be
limitations on the other applications, devices and services they are authorized to access.
This limitation of rights needs to be discussed in these sections. Specifically the standard
should recommend the concept of
615
616
c) The task group recommends that the requirements be expanded to take into consideration
the significant differences between remote and local authorization.
617
618
2.18.4
None
619
2.19
620
2.19.1
621
622
623
Additional comments and recommendations
Clause 4.3.4
Element group: Implementation
Purpose of this section (from ANSI/ISA-99.02.01-2009)
The third element group in this category is implementation. This element within this gr oup
discusses issues related to implementing the CSMS. The four elements in the element group
are:
624
Risk management and implementation
625
System development and maintenance
626
Information and document management
627
Incident planning and response
628
2.19.2
Identified gaps
629
630
631
a) As noted earlier, there is a gap in the fact that the requirements do little to protect the
backup system or media from attack or infection. There is also no discussion on how to
prevent recontamination during recovery.
632
633
634
635
b) As noted earlier, the task group is concerned that there is a lack of discussion on postevent analysis and/or forensics. It is important to define any processes for identifying the
cause before attempting to recover the system. This is especially critical in this section of
the 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.
591
18
ISA99, WG5, TG2
2.19.3
ISA TR62443 0 3 (June 2012)
Specific recommendations
637
638
a) The task group believes stronger requirements are needed to protect the backup system
or media from attack or infection.
639
640
b) The task group believes there is a need for stronger requirements regarding a provision to
prevent recontamination during recovery.
641
642
c) The task group recommends that the standard needs to clarify that recovering a
compromised system is not the same as recovering a damaged system.
643
644
d) The task group recommends that a discussion on post-event analysis and/or forensics be
added to this section.
645
646
2.19.4
None
647
2.20
648
2.20.1
649
650
651
652
653
654
655
Additional comments and recommendations
Clause 4.3.4.2
Element: Risk management and implementation
Purpose of this section (from ANSI/ISA-99.02.01-2009)
Reduce risk to and maintain risk at an acceptable level in the IACS based upon the
org
2.20.2
Identified gaps
None
2.20.3
Specific recommendations
None
2.20.4
Additional comments and recommendations
656
657
658
659
a) The task group recommends that the ISA99 committee clarify how this section is different
identification,
classification
be merged.
660
661
662
b) The option of independent confirmation of security plan and implementation is important
for many IACS applications and is not mentioned in this section. It should be added to the
discussion.
663
2.21
664
2.21.1
665
666
667
668
669
670
671
672
673
Clause 4.3.4.3
Element: System development and maintenance
Purpose of this section (from ANSI/ISA-99.02.01-2009)
evolve through the maintenance of existing systems and development and procurement of
new systems.
2.21.2
Identified gaps
None
2.21.3
Specific recommendations
None
2.21.4
Additional comments and recommendations
None
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.
636
19
ISA TR62443 0 3 (June 2012)
674
2.22
675
2.22.1
678
679
680
681
682
683
2.22.2
Purpose of this section (from ANSI/ISA-99.02.01-2009)
Identified gaps
None
2.22.3
Specific recommendations
None
2.22.4
Additional comments and recommendations
None
2.23
685
2.23.1
687
Element: Information and document management
Classify, manage, safeguard, and present the information associated with the IACS and
CSMS at the appropriate time to authorized personnel.
684
686
ISA99, WG5, TG2
Clause 4.3.4.5
Element: Incident planning and response
Purpose of this section (from ANSI/ISA-99.02.01-2009)
Predefine how the organization will detect and rea ct to cyber security incidents.
2.23.2
Identified gaps
688
689
690
691
a) The task group believes that system recovery is an important part of any incident planning
and r
continuity plan
erestingly, the
Annex A.3.4.5 does discuss recovery, although with significant gaps.
692
693
694
b) The task group agreed that the focus in the Annex seems to be on backup/restore and
misses the clean-up part of the system recovery. (See also discussion in section 2.10.2 of
this report.)
695
696
697
698
2.23.3
None
2.23.4
Additional comments and recommendations
None
699
2.24
700
2.24.1
701
702
703
Specific recommendations
Clause 4.4
Category: Monitoring and improving the CSMS
Purpose of this section (from ANSI/ISA-99.02.01-2009)
The third main category of the CSMS is monitoring and improving the CSMS. It involves both
ensuring that the CSMS is being used, and reviewing the CSMS itself for effectiveness. The
two elements in this category are:
704
Conformance
705
Review, improve, and maintain the CSMS
706
707
708
709
710
711
712
713
2.24.2
Identified gaps
None
2.24.3
Specific recommendations
None
2.24.4
Additional comments and recommendations
a) The task group
onitoring and improving the CSMS
sufficient, but there needs to be additional work in other (future) documents to further
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.
676
677
Clause 4.3.4.4
20
ISA99, WG5, TG2
714
2.25
715
2.25.1
2.25.3
2.25.4
2.26
724
2.26.1
2.26.2
Clause 4.4.3
Element: Review, improve and maintain the CSMS
Purpose of this section (from ANSI/ISA-99.02.01-2009)
Identified gaps
None
727
2.26.3
Specific recommendations
None
729
2.26.4
Additional comments and recommendations
None
731
732
Additional comments and recommendations
Ensure that the CSMS continues to meet its goals over time.
725
730
Specific recommendations
None
723
728
Identified gaps
None
722
726
Purpose of this section (from ANSI/ISA-99.02.01-2009)
None
720
721
Element: Conformance
3
Conclusions and Final Remarks
733
734
735
736
737
738
739
740
The landscape of cyber security threats has changed after the discovery of the Stuxnet worm.
Not only have IACS operators been informed of the capabilities and potential of the malware,
but so have attackers. Thus it is likely the IACS world will see future cyber-attacks using at
least some of the advanced features shown by Stuxnet, including the use of mobile media,
embedding malware in project files and print jobs and the use of traffic channels required by
the IACS for malicious or covert operations. This means that all standards, policies and plans
should be re-evaluated to see if they would withstand an attack that uses the advanced
persistent threat techniques that Stuxnet highlighted
741
742
743
744
The task group located approximately thirty-five gaps in the ANSI/ISA-99.02.01-2009
standard that would have allowed the Stuxnet worm to operate in a typical IACS environment.
A total of 33 recommendations specifically addressing these gaps were developed by the TG.
Twelve additional comments and recommendations were also generated in the analysis
745
746
747
Many of the gaps and recommendations can be resolved by strengthening the existing
requirements and annex descriptions. However there are several sections that need
significant revision. These include:
748
749
Clarification of requirements on scope in section
classification
identification,
750
751
752
Addition of requirements on both forensics and prevention of recontamination in
section
section
753
754
Addition of requirements on infiltration of mobile media in section
Physical and environmental
:
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.
2.25.2
718
719
ISA TR62443 0 3 (June 2012)
Ensure that the CSMS developed for an organiza tion is followed.
716
717
Clause 4.4.2
21
22
ISA99, WG5, TG2
755
756
Addition of detailed requirements on segmentation practices in section 4.3.3.4
757
758
These four areas represent the most significant issues in the ANSI/ISA-99.02.01-2009
standard and should be the priority for any gro up working on a future edition of the standard.
759
760
761
762
Finally, several areas of the standard should be reorganized or merged for clarity, such as
section
section
-like attacks, but it will
reduce the probability of misinterpretation of the ANSI/ISA-99.02.01-2009 standard.
763
764
765
766
767
768
769
To conclude, if it is assumed that the IACS operator fulfils the requirements of this standard at
the minimum level, then even the above changes to the ANSI/ISA-99.02.01-2009 standard
may not stop future worms that are as sophisticated and multifaceted as Stuxnet. However,
by strengthening the requirements and annexes as recommended, the overall security of
IACS systems will be significantly improved, and they will be more likely to prevent future
task group believes that
this is an important and achievable objective.
770
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 TR62443 0 3 (June 2012)
ISA99, WG5, TG2
4
ISA TR62443 0 3 (June 2012)
Revision History
Revision
Date
Revised By
D1E1
October 2011
E. Byres
D1E2
October 2011
S. de GroothVerlijsdonk
Pasting minutes of meeting in framework
D1E3
October 2011
S. de GroothVerlijsdonk
Convert the minutes until paragraph 2.18
D1E4
November 2011
S. de GroothVerlijsdonk
Convert the minutes until the end and adding the
conclusions and final remarks.
D1E5
February 2012
E. Byres
Comments
Initial framework
Revise text and modify formatting.
J. Langill
D1E6
February 2012
E. Byres
S. de GroothVerlijsdonk
772
Revise text and modify formatting in preparation
for final submission to WG5 TG2.
D1E7
March 2012
E. Byres
Include revisions and comments from TG5
Reviewers.
D1E8
March 2012
E. Byres
Include revisions and comments from additional
TG5 Reviewers.
D1E9
March 2012
E. Byres
Draft version for release to ISA99 committee for
review and comment.
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.
771
23
774
775
24
This page intentionally left blank
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 TR62443 0 3 (June 2012)
ISA99, WG5, TG2
773
25
ISA TR62443 0 3 (June 2012)
776
BIBLIOGRAPHY
777
778
779
780
NOTE: 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.
781
References to other parts, both existing and anticipated, of the ISA IEC 62443 series:
782
[1]
ANSI/ISA TR62443 0 3, Security for industrial automation and control systems: Technical
report 3: Gap assessment of ANSI/ISA-99.02.01-2009
[2]
785
ANSI/ISA 62443 1 1, Security for
Terminology, concepts and models
786
787
NOTE: This document is currently published by ISA as ANSI/ISA -99.00.01-2007. The document will be
renumbered as shown above in the next published edition to remain consistent with its IEC equivalent.
783
784
industrial
automation
and
control
systems:
[3]
ANSI/ISA TR62443 1 2, Security for industrial automation and control systems: Master
glossary of terms and abbreviations
[4]
ANSI/ISA 62443 1 3, Security for industrial automation and control systems: System
security compliance metrics
[5]
793
ANSI/ISA 62443 2 1, Security for industrial automation and control systems: Establishing
an industrial automation and control system security program
794
795
NOTE: This document is currently published by ISA as ANSI/ISA-99.02.01-2009. The document will be
renumbered as shown above in the next published edition to remain consistent with its IEC equivalent.
788
789
790
791
792
[6]
ANSI/ISA TR62443 2 3, Security for industrial automation and control systems: Patch
management in the IACS environment
[7]
ANSI/ISA 62443 2 4, Security for industrial automation and control systems: Certification
of IACS supplier security policies and practices
[8]
801
ANSI/ISA TR62443 3 1, Security for industrial automation and control systems: Security
technologies for industrial automation and control syste ms
802
803
NOTE: This document is currently published by ISA as ANSI/ISA -TR99.00.01-2007. The document will be
renumbered as shown above in the next published edition to remain consistent with its IEC equivalent.
796
797
798
799
800
804
[9]
ANSI/ISA 62443 3 2, Security for industrial automation and control systems: Target
security assurance levels for zones and conduits
[10]
ANSI/ISA 62443 3 3, Security for industrial automation and control systems: System
security requirements and security assurance levels
[11]
ANSI/ISA 62443 4 1, Security for industrial automation and control systems: Embedded
devices
[12]
ANSI/ISA 62443 4 2, Security for industrial automation and control systems: Host
devices
805
806
807
808
809
810
811
812
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.
ISA99, WG5, TG2
ISA TR62443 0 3 (June 2012)
26
ISA99, WG5, TG2
Developing and promulgating sound consensus standards, recommended practices, and
technical reports
To achieve this goal the Standards and
Practices Department relies on the technical expertise and efforts of volunteer committee
members, chairmen and reviewers.
ISA is an American National Standards Institute (ANSI) accredited organization. ISA
administers United States Technical Advisory Groups (USTAGs) and provi des secretariat
support for International Electrotechnical Commission (IEC) and International Organization for
Standardization (ISO) committees that develop process meas urement and control standards.
rds program, please write:
ISA
Attn: Standards Department
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.
813