ISA-62443-1-1-draft

FOR REVIEW PURPOSES ONLY!

THIS DOCUMENT IS A WORKING DRAFT OF AN ISA99 COMMITTEE WORK PRODUCT. IT MAY NOT . BE ACCURATE OF COMPLETE AND IS SUBJECT TO CHANGE WITHOUT NOTICE IT IS PROVIDED SOLELY FOR THE PURPOSE OF REVIEW IN SUPPORT OF FURTHER DEVELOPMENT OF COMMITTEE WORK PRODUCTS. THIS DOCUMENT MAY NOT BE COPIED, DISTRIBUTED TO OTHERS, OR OFFERED FOR FURTHER REPRODUCTION OR FOR SALE.

Copyright © by the International Society of Automation. All rights reserved. Not for resale. Printed in the United States of America. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), without the prior written permission of the Publisher.

ISA 67 Alexander Drive P. O. Box 12277 Research Triangle Park, North Carolina 27709 USA

This page intentionally left blank

1 2

ISA-62443-1-1 Security for industrial automation and control systems Models and Concepts Draft 5, Edit 4 August 2015

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA-62443-1-1, D5E4, August 2015

–2 –

ISA99, WG03

3 4 5 . e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

ISA Security for industrial automation and control systems Models and Concepts ISBN: -to-be-assigned-

Copyright © 2015 by ISA. All rights reserved. Not for resale. Printed in the United States of Am eri ca .

ISA 67 Alexander Drive P. O. Box 12277 Research Triangle Park, NC 27709 USA

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA99, WG03

ISA-62443-1-1, D5E4, August 2015

PREFACE

6 7 8

–3 –

This preface, as well as all footnotes and annexes, is included for information purposes and is not part of ISA-62443-1-1.

9 10 11 12 13 14

This document has been prepared as part of the service of ISA, the International Society of Automa tio n, to war d a goal of uniformity in th e fiel d of ins trumentatio n. To be of re al 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:

15

[email protected].

16 17 18 19 20 21 22 23 24 25 26

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 th e 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 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 Am erican Society for Testing and Materials as IEE E/ASTM SI 10-97, and future revisions, will be the reference guide for definitions, symbols, abbreviations, and conversion factors.

27 28 29 30 31

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.

32 33 34 35 36

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.

37 38 39 40 41 42 43 44

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 carefully investigate relevant patents before using the standard for the user’s intended application.

45 46 47

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.

48 49 50 51 52 53 54

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 exercise sound professional judgment concerning its use and applicability under the user’s particular circumstances. The user must also consid er the applicability of any governmental regulatory limitations and established safety and health practices before implementing this standard.

55

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA-62443-1-1, D5E4, August 2015 56 57

–4 –

ISA99, WG03

The following people served as active members of ISA99, Working Group 03, Task Group 0 for the preparation of this document:

58 Name

Company

C ontributor 

Eric Cosman

OIT Concepts LLC



Jim Gilsinn

Kenexis



Tom Good Evan Hand

DuPont Conagra Foods

 

Dennis Holstein

OPUS Consulting Group



Eric Hopp

Rockwe ll Automation



Pierre Kobes

Siemens



Jeff Potter

Emerson Process Management



Ragnar Schierholz

ABB



Leon Steinocher

Consultan t

Chris Stephens

Fluor



Bradley Taylor

The George Washingto n University/ NAVSEA



Donovan Tindill

Honeyw ell



Rich Weekly

Barr-Tho rp Electric Co., Inc.





Jean-Pierr e Hauet

59 60

Reviewer

Maverick Technologie s

Bruce Billedeaux



. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA99, WG03

–5 –

ISA-62443-1-1, D5E4, August 2015

CONTENTS

61 62 63

PREFACE ................. ................. ................ ................. ................. ................ ................. .......... 3

64

FOREWORD ................ ................. ................ ................. ................ ................. ................ ........ 9

65

INTRODUCTION ............... ................. ................. ................. ................ ................. ................ 10

66

1

Scope ................. ................. ................ ................. ................. ................ ................. ........ 11

67

2

Normative references ................ ................ ................ ................. ................. ................. ..11

68

3

Terms, definitions, abbreviated

terms, acronyms, and conventions ... ................ .............. 12

69

3.1

Terms and definitions ............... ................ ................. ................. ................ ........... 12

70

3.2

Abbreviated t erm s a nd acron yms ... ..... ... ... ..... ... ..... ... ... ... ... ..... ... ... ..... ... ... ..... ... ... ... 24

3.3

Conventions .............. ................. ................. ................. ................ ................. ........ 24

71 72

4

The ISA ‑ 62443 standards ............... ................ ................. ................. ................ ..............25

73

5

The Situation ................. ................. ................ ................. ................. ................. .............27

74

5.1

Overview ................. ................. ................ ................. ................ .................. .......... 27

75

5.2

Business Environment ................. ................ ................. ................ ................. ........27

76

5.3

Current Systems ............... ................ ................ ................. ................. ................. ..27

77

5.4

Current Trends ................. ................ ................ ................. ................. ................. ..28

78

5.5

Potential Consequences ................ ................. ................. ................ ................. .....29

79

5.6

Impact of Countermeasures .................

80

5.7

Common Constraints ................ ................. ................ ................. ................ ...........29

81 82 83

5.7.1 6

................. ................ ................. ................ 29

Support of Essential Functions ................ ................. ................. ................ 29

5.7.2 Compensating countermeasures............................ ................. ................ ...30 Security Elements ............... ................. ................. ................. ................ ................. ........30

84

6.1

Introduction ............... ................. ................. ................. ................ ................. ........ 30

85

6.2

People ............... ................. ................. ................. ................ ................. ................ 31

86

6.3

Processes ............... ................ ................. ................. ................. ................. .......... 32

87

6.4

Technology ................ ................. ................. ................. ................ ................. ........ 32

88

6.5

Use Cases ............... ................ ................. ................. ................. ................. ..........33

89

6.6

Summary ................. ................. ................ ................. ................ .................. .......... 35

90

7

91 92

Roles and Responsibilities .............. 7.1

8

................ ................. ................. ................ .............. 35

General ................ ................. ................ ................. ................. ................. ............. 35

IACS Definition ................. ................. ................ ................. ................ .................. ..........36

93

8.1

Functionality Included ............... ................ ................. ................. ................ ...........36

94

8.2

Systems and Interfaces ............... ................ ................. ................ ................. ........ 37

95

8.3

Act ivi ty-Based Crite ria ..... ... ..... ... ... ..... ... ..... ... ... ... ... ..... ... ... ..... ... ... ..... ... ... ..... ... ..... . 37

96

8.4

Ass et- Base d Crite ri a ... ... ... ... ... ... ..... ... ... ..... ... ... ... ... ..... ... ... ..... ... ... ..... ... ... ..... ... ..... . 37

97

8.5

Consequence-Based

98

9

Criteria ............... ................ ................. ................. ................38

Models ............... ................ ................. ................. ................. ................ ................. ........ 38

99

9.1

General ................ ................. ................ ................. ................. ................. ............. 38

100

9.2

Reference Model ................ ................. ................ ................. ................. ................38

101

9.2.1

Level 4 – Enterprise Business Systems ............... ................ ................. ..... 39

102

9.2.2

Level 3 - Operations Management .........................

103

9.2.3

Level 2 – Supervisory Control .....................

104

9.2.4

Level 1 – Local or Basic Control ............................

105

9.2.5

Level 0 – Process .............. ................. ................. ................ ................. .....40

106

9.3

................. ................ ... 39

................. ................ .............. 39 ................. ................ ... 39

Reference Architecture Model ................ ................ ................. ................. ............. 40

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA-62443-1-1, D5E4, August 2015 107

9.4

–6 –

ISA99, WG03

Zone Model ............... ................. ................. ................. ................ ................. ........41

108

10 General Concepts ............... ................. ................. ................. ................ ................. ........41

109

10.1 Security Context ............... ................ ................ ................. ................. ................. ..41

110

10.2 Security Objectives..............................

111

10.3 Least Privilege ................. ................ ................ ................. ................. ................. .. 43

112

10.4 Defense in Depth................ ................. ................ ................. ................. ................ 43

113

10.5 Threat-Risk Assessment ................ ................. ................. ................ ................. .....43

114

10.6 Policies and Procedures ...........................

................ ................. ................. ................42

................. ................. ................ ........... 43

115

10.6.1 General ................ ................ ................ ................. ................. ................. .. 43

116

10.6.2 Enterprise Level ................ ................. ................. ................ ................. ..... 44

117

10.6.3 Operational Level .............. ................. ................. ................ ................. ..... 45

118

10.7 Topics Covered by Policies and Procedures .................

119

10.8 Key Management......................

................ ................. ........ 45

................ ................. ................. ................ ...........47

120

10.8.1 Introduction ............... ................ ................. ................. ................ ..............47

121

10.8.2 Generation and distribution of keys ................ ................. ................ ........... 48

122 123 124

10.8.3 Key State Phases .............. ................. ................. ................ ................. ..... 49 11 Fundamental Concepts ................ ................. ................ ................. ................. ................49 11.1 Security Life Cycle ................ ................ ................. ................. ................ .............. 49

125

11.1.1 Introduction ............... ................ ................. ................. ................ ..............49

126

11.1.2 Product life cycle ............... ................. ................. ................ ................. ..... 51

127

11.1.3 IACS Life Cycle ............... ................ ................. ................ ................. ........ 52

128

11.2 Maturity Levels ................. ................ ................ ................. ................. ................. ..54

129

11.2.1 Maturity Phases ............... ................ ................. ................ ................. ........55

130 131

11.3 Zones and Conduits ................. ................. ................ ................. ................ ........... 58 11.3.1 Introduction ............... ................ ................. ................. ................ ..............58

132

11.3.2 Zones ............... ................. ................. ................. ................ ................. ..... 58

133

11.3.3 Conduits ............... ................ ................ ................. ................. ................. .. 58

134

11.3.4 Channels ................ ................. ................ ................. ................. ................ 59

135

11.3.5 Determining Requirements ................. ................. ................ ................. ..... 59

136

11.3.6 Defining Zones ................ ................ ................. ................ ................. ........60

137

11.3.7 Zone Identification ................ ................. ................ ................. ................. ..60

138

11.3.8 Defining Conduits .............. ................. ................. ................ ................. .....62

139

11.4 Security Levels ................. ................ ................ ................. ................. ................. ..64

140

11.4.1 Introduction ............... ................ ................. ................. ................ ..............64

141

11.4.2 Definition ................ ................. ................ ................. ................. ................ 64

142

11.4.3 Types of Security Levels .... ................. ................. ................ ................. ..... 65

143

11.4.4 Using Security Levels ................. ................ ................. ................. ............. 65

144

11.4.5 Security Level Vector ............ ................ ................. ................. ................. .. 68

145 146

11.4.6 Foundational Requirements ................ ................. ................ ................. ..... 68 11.4.7 Level Definitions ................ ................. ................. ................ ................. .....69

147 148

11.4.8 Security Level Vector Format ........ ................. ................. ................ ........... 70 11.5 Foundational Requirements ................. ................. ................ ................. ................71

149

11.5.1 FR 1 – Iden tification and authentication control

150

11.5.2 FR 2 – Use control (UC) ............... ................. ................. ................. .......... 72

(IAC) ...........................

..... 71

151

11.5.3 FR 3 – System integrity (SI) ........ ................ ................. ................ .............. 72

152

11.5.4 FR 4 – Data confidentiality (DC) .............. ................. ................. ................ 72

153

11.5.5 FR 5 – Restricted data flow (RDF) .......................

154

11.5.6 FR 6 – Timely response to events ( TRE) .............................

................ ................. ..... 73 ................. ..... 73

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA99, WG03

–7 –

ISA-62443-1-1, D5E4, August 2015

155

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

156

11.6 Safety and Security ............... ................ ................. ................. ................ .............. 73

157

11.6.1 Rationale ................ ................. ................ ................. ................. ................ 74

158

12 Compliance Metrics ............... ................. ................. ................. ................ ................. .....74

159

Annex A – Zones and Conduits Examples ..... ................. ................. ................ ................. ..... 75

160

A.1

Introduction ............... ................. ................. ................. ................ ................. ........ 75

161

A.2

Untrusted Conduits ................ ................ ................. ................. ................ ..............75

162

A.3

Multi-Plant Model................ ................. ................ ................. ................. ................75

163 164

A.4 A.5

(Description) .............. ................. ................. ................. ................ ................. ........ 76 SCADA Applications ................. ................. ................ ................. ................ ...........77

165 166 167 168 169

Annex B – Truck Loading Description.......................

................. ................. ................. .......... 81

B.1

Introduction ............... ................. ................. ................. ................ ................. ........ 81

B.2

Safety and Security ............... ................ ................. ................. ................ .............. 90

Annex C – Example: Pr ocedure to apply f oundational req uirements .. ................. ................. .. 92 C.1

Overview ................. ................. ................ ................. ................ .................. .......... 92

170

C.1.1

Description of example system under consideration ................ ................. .. 92

171

C.1.2

Technical Approach ................. ................. ................ ................. ................92

172

C.1.3

Achie ved s ecu ri ty ass urance lev el .... ... ... ... ... ... ... ... ..... ... ... ..... ... ... ..... ... ... ... 95

173 174 175 176

C.2

System security assurance when commissioned ... ................ ................. ................ 96

C.3

System security assurance

during after c ommissioning ..............................

........... 96

Annex D (inform ative) Un der st anding ho w t o use the ISA99 adaptation of the IEC styleguide ................ ................. ................. ................. ................ ................. ................ ... 97

177

D.1

Overview ................. ................. ................ ................. ................ .................. .......... 97

178 179

D.2 D.3

Document and page formatting ................. ................. ................. ................. .......... 97 Sectioning ............... ................ ................. ................. ................. ................. .......... 98

180

D.4

Figures ................. ................. ................ ................. ................. ................. ............. 99

181

D.5

Tables ............... ................. ................. ................. ................ ................. ................ 99

182

D.6

Wording and language recommendations ............... ................. ................ ............ 100

183

BIBLIOGRAPHY ............... ................. ................. ................. ................ ................. .............. 101

184 185

Figure 1 – ISA ‑ 62443 Work Products ............... ................ ................. ................. ................. .. 26

186

Figure 2 – Security Elements Grouping ....................

187

Figure 3 – Three-Legged Table .....................

188

Figure 4 – Implementation of People, Process, and Technology ................. ................. .......... 35

189

Figure 5 – Reference Model .......................

190

Figure 6 – Physical Architecture Model Example .... ................ ................. ................ .............. 41

191

Figure 7 – Context Element Relationships ... ................ ................. ................ ................. ........ 42

192

Figure 8 – Context Model .........................

193

Figure 9 – Key management life cycle ................. ................. ................ ................. ................ 48

194

Figure 10 – Security aspects in relevant life cycles .....................

195

Figure 11 – Interdepende ncies in product and IAC S lifecycles ................ ................. ............. 51

196

Figure 12 – High-level process-industry

197

Figure 13 – High-level manufacturing exam ple showing zones and conduits ........... .............. 67

198

Figure 14 – High-level manufacturing exam ple showing zones and conduits ........... .............. 68

199

Figure 15 – Conduit Example ...........................

200

Figure 16 – Multiplant Zone Example .......................

................. ................. ................. .......... 31

................. ................. ................ ................ ...... 34

................. ................ ................. ................. ........ 39

................ ................. ................. ................ ........... 42

................. ................. ........ 50

example showing zones and conduits......................

66

................ ................. ................. ................ ... 75 ................. ................. ................. .......... 76

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA-62443-1-1, D5E4, August 2015

–8 –

ISA99, WG03

201

Figure 17 – Separate Zones Example ................. ................. ................ ................. ................ 77

202

Figure 18 – SCADA Zone Example ............... ................. ................. ................ ................. ..... 78

203

Figure 19 – SCADA Separate Zones Example ................ ................. ................ ................. ..... 79

204

Figure 20 – Enterprise Conduit ................ ................. ................ ................. ................ ........... 79

205

Figure 21 – SCADA Conduit Example ................. ................. ................ ................. ................ 80

206

Figure 22 – Chemical Truck

207

Figure 23 – Chemical Truck Loading System with Definition of SUT Boundar y ...... ................ 82

208

Figure 24 – Diagram o f major components for chemical truck loading example .....................

209

Figure 25 – Zone and Conduit Identification .............

210

Figure 26 – High-level process-industry

211

Figure 27 – High-level manufacturing exam ple show ing zones and conduits .............. ........... 89

212

Figure 28 – Examp le application - Chemical truck loading station ................ ................. ........ 92

Loading Control System Architecture

Diagram ............... ........... 81

83

................. ................. ................ ........... 86

example showing zones and conduits......................

88

213 214

Table 1 – E lements App lied to Change Contro l and Configuration Managem ent ............... ..... 34

215

Table 2 – Entities with relevant life cycles and the respective m ain responsible role

216

Table 3 – Security Maturity Phases ............... ................. ................. ................ ................. ..... 56

217

Table 4 – Concept Phase .........................

218

Table 5 – Functional Analysis Phase .. ................. ................. ................ ................. ................ 56

219

Table 6 – Implementation Phase ..............................

220

Table 7 – Operations Phase .................. ................ ................. ................. ................ .............. 57

221

Table 8 – Recycle and Disposal Phase ............... ................ ................. ................. ................ 57

222

Table 9 – Zone Characteristics ................ ................. ................ ................. ................ ........... 87

223 224

............. 50

................ ................. ................. ................ ........... 56

................. ................. ................ ........... 57

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA99, WG03 225

–9 –

ISA-62443-1-1, D5E4, August 2015

FOREWORD

226 227 228

This document is part of a multipart standard th at addresses the issue of security for industrial automation and control systems (IACS). It has been developed by working group 03 of the ISA99 committee in cooperation with IEC TC65/WG10.

229 230 231

This document describes the concepts and models that form the foundation of all standards in the series. Many of these topics are addressed in more detail in one or more related standards. It supersedes the srcinal version of this standard (ISA-99.00.01-2007).

232 233

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA-62443-1-1, D5E4, August 2015

– 10 –

ISA99, WG03

234

INTRODUCTION

235 236 237 238

NOTE The format of this document fol lows the ISO/IEC re quirements disc ussed in ISO/IEC Di rectives, Part 2. [15] 1 The ISO/IEC Directives specify the format of this document as well as the use of terms like “shall”, “should”, and “may”. The use of those terms for the requirements specified in Clause 4 of this document use the conventions discussed in the ISO/IEC Directives, Appendix H.

239 240

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

————————— 1 Numbers in square brackets refer to the

Bibliography .

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA99, WG03

– 11 –

ISA-62443-1-1, D5E4, August 2015

241

1

242 243 244

This document is the first in the ISA ‑ 62443 series of standards that addresses various aspects of IACS security. It introduces concepts and models that are described and applied in more detail in subsequent standards in the series.

245 246 247 248

The content of this document includes both general purpose cyber security elements that are applicable in the IACS environment, as well as a small set of concepts and models that are specific or unique to IACS. Normative content is limited to what required to define essential concepts that must be consistently applied across all aspects of and IACS security response.

249 250 251 252 253

The intended audience for this specification is the IACS community, including asset owners, system integrators, product suppliers, service providers and, where appropriate, compliance authorities. Compliance authorities include but are not limited to government agencies and regulators with the legal authority to perform audits to verify compliance with governing laws and regulations.

254 255 256 257 258 259

System integrators, product suppliers and service providers will use this document to evaluate whether their products and services can provide the functional security capability to meet the asset owner’s target security level requirements. As with the assignment of these requirements, applicability of individual control system requirements and requirement enhancements must be based on an asset owner’s security policies, procedures and risk assessment in the context of their specific site.

260 261 262

There is insufficient detail in this document to design and build a comprehensive security architecture. That requires additional system-level analysis and development of derived requirements that are the subject of other documents in the ISA ‑ 62443 series.

263

2

264 265 266

The following referenced for the application document. For dated references, onlydocuments the edition are citedindispensable applies. For undated references,of thethis latest edition of the referenced document (including any amendments) applies.

267

ISA ‑ TR62443-1-2, Security for Industrial Automation and Control Systems

268 269

ISA ‑ 62443-2-1, Security for industrial automation and control systems Industrial automation and control system security management system

270 271

ISA ‑ 62443-3-2, Security for Industrial Automation and Control Systems Assessment and System Des ign

272 273

ISA ‑ 62443-3-3, Security for Industrial Automation and Control Systems Requirements and Security Levels

274 275

ANSI/I SA-95.00.0 1-2000, Enterp rise -C ontro l Sys tem Int egr ation – Models and Terminology, Clause 5 (Hierarchy Models)

276 277

ISO/IEC 27001 – Information technology management systems – Requirements

278 279

ISO/IEC 27002, Information technology information security management

280

Scope

Normative references

– Security techniques

– Security techniques

– Master Glossary – Requirements for an

– Security Risk

– System Security

– Information security

– Code of practice for

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA-62443-1-1, D5E4, August 2015

– 12 –

ISA99, WG03

281

3

Terms, definitions, abbreviated terms, acronyms, and conventions

282

3.1

283 284

For the purposes of this document, the terms and definitions given in ISA following apply.

285 286 287 288

3.1.1 access ability and means to communicate with or otherwise interact with a system in order to use system resources

289 290 291

Note to entry: Access may involve physical access (authorization to be allowed physically in an area, possession of a physical key lock, PIN code, or access card or biometric attributes that allow access) or logical access (authorizati on to log in to a system and application, through a combination of logical and physical means)

292 293 294 295 296

3.1.2 access control protection of system resources against unauthorized access; a process by which use of system resources is regulated according to a security policy and is permitted by only authorized entities (users, programs, processes, or other systems) according to that policy

297 298 299 300 301

3.1.3 accountability property of a system (including all of its system resources) that ensures that the actions of a system entity may be traced uniquely to that entity, which can be held responsible for its actions

302 303 304

3.1.4 actuator actuating element connected to process equipment and to the control system

305 306 307 308 309

3.1.5 application software program that performs specific functions initiated by a user command or a process event and that can be executed without access to system control, monitoring, or administrative privileges

310 311 312

3.1.6 area subset of a site’s physical, geographic, or

313 314 315

Note to entry: An area may contain manufacturing lines, process cells, and production units. Areas may be connected to each other by a site local area network and may contain systems related to the operations performed in that area.

316 317 318 319

3.1.7 asset physical or logical object owned by or under the custodial duties of an organization, having either a perceived or actual value to the organization

320 321

Note to entry: In the case of industrial automation and control systems the physical assets that have the largest directly measurabl e value may be the equipment under control.

322 323 324

3.1.8 asset operator individual or organization responsible for the operation of the IACS

325 326 327

3.1.9 asset owner individual or organization that owns the IACS assets

Terms and definitions

‑ 62443-1-1 and the

logical group of assets

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA99, WG03

– 13 –

ISA-62443-1-1, D5E4, August 2015

328 329 330 331 332

3.1.10 attack assault on a system that derives from an intelligent threat — i.e., 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

333

Note to entry: There are different commonly recognized classes of attack:

334 335

An “ac ti ve att ack ” att em pts to alt er sys tem res our ces or aff ect the ir op era ti on. A “pa ssi ve at tac k” at tem pt s to lea rn or make use of information from the system but does not affect system resource s.

336 337

An “in sid e att ack ” is an att ack ini tia te d by an entity inside the security perimeter (an “insider” ) – i.e., an entity that is authorized to access system resources but uses them in a way not approved by those who granted the

338 339 340

authorization . An “outside attack”attacking is initiatedfrom fromoutside outsidethe the security perimet er, by an unauthorized illegitimate user of the system (including an insider perimeter). Potential outsideorattackers range from amateur pranksters to organized criminals, international terrorists, and hostile governments.

341 342 343 344 345 346

3.1.11 audit independent review and examination of records and activities to assess the adequacy of system controls, to ensure compliance with established policies and operational procedures, and to recommend necessary changes in controls, policies, or proc edures (See “security audit”)

347 348 349 350

Note to entry: There are three forms of audit. (1) External audits are conducted by parties who are not employees or contractors of the organization. (2) Internal audit are conducted by a separate organizational unit dedicated to internal auditing. (3) Controls self assessments are conducted by peer members of the process automation function.

351 352 353 354

3.1.12 authenticate verify the identity of a user, user device, or other entity, or to establish the validity of a transmission

355 356 357 358 359

3.1.13 authentication security measure designed to establish the validity of a transmission, message, or srcinator, or a means of verifying an individual's authorization to receive specific categories of information

360 361 362

3.1.14 authorization right or a permission that is granted to a system entity to access a system resource

363 364 365 366 367

3.1.15 availability probability that an asset, under the combined influence of its reliability, maintainability, and security, will be able to fulfill its required function over a stated period of time, or at a given point in time

368 369 370

3.1.16 border edge or boundary of a physical or logical security zone

371 372 373

3.1.17 botnet collection of software robots, or bots, which run autonomously

374

Note to entry: A botnet's srcinator can control the

375 376 377

3.1.18 boundary software, hardware, or other physical barrier that limits access to a system or part of a system

group remotely, possibly for nefarious purpo

ses.

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA-62443-1-1, D5E4, August 2015

– 14 –

ISA99, WG03

378 379 380 381 382

3.1.19 business system collection of information technology elements (i.e., hardware, software and services) installed with the intent to facilitate an organiza tion’s business process or processes (administrative or project)

383 384 385 386

3.1.20 cell lower-level element of a manufacturing process that performs manufacturing, field device control, or vehicle functions

387 388

Note to entry: Entities at this may be connected by an area control network and may contain information systems relate d tolevel the operations performedtogether in that entity.

389 390 391

3.1.21 channel specific communication path established within a communication conduit (

392 393 394

3.1.22 client device or application receiving or requesting services or information from a server application

395 396 397 398

3.1.23 communication path logical connection between a source and one or more destinations, which could be devices, physical processes, data items, commands, or programmatic interfaces

399 400

Note to entry: The communication path is not limited to wired or wireless networks, but includes other means of communication such as memory, procedure calls , state of physical plant, portable media, and human interactions.

401 402

3.1.24 communication system

403 404

arrangement of hardware, software, and propagation media to allow the transfer of messages (ISO/IEC 7498 application layer service data units) from one application to another

405 406 407 408

3.1.25 compromise unauthorized disclosure, modification, substitution, or use of information (including plaintext cryptographic keys and other critical security parameters)

409 410 411

3.1.26 conduit logical grouping of communication assets that protects the security of the channels it contains

412

Note to entry: This is analogous to

413 414 415

3.1.27 confidentiality assurance that information is not disclosed to unauthorized individuals, processes, or devices

416 417

3.1.28 control center

418 419 420 421 422

central location used to operate a set of assets

423

Note 2 to entry:

424 425 426 427 428

3.1.29 control equipment class that includes distributed control systems, programmable logic controllers, SCADA systems, associated operator interface consoles, and field sensing and control devices used to manage and control the process

See “conduit”).

the way that a physical conduit protects cables from physical damage.

Note 1 to entry: Infrastructu re industr ies typicall y use one o r more control c enters to su pervise or coordinate the ir operations. If there are multiple control centers (for example, a backup center at a separate site), they are typically connected together via a wide area network. The control center contains the SCADA host computers and associated operator display devices plus ancillary information systems such as a historian. In some industries the term “control room” may be mor

e commonly used.

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA99, WG03

– 15 –

ISA-62443-1-1, D5E4, August 2015

429 430 431

Note to entry: The term also includes field bus networks where control logic and algorithms are executed on intelligent electronic devices that coordinate actions with each other, as well as systems used to monitor the process and the systems used to maintain the process.

432 433 434

3.1.30 control network time-critical network that is typically connected to

435 436

Note to entry: The control network can be subdivided into zones, and there can be multiple separate control networks within one company or site.

437 438

3.1.31 cost

439

value of impact to an organization or person that can be m

440 441 442 443 444

3.1.32 countermeasure action, device, procedure, or technique that reduces a threat, a vulnerability, or an attack by eliminating or preventing it, by minimizing the harm it can cause, or by discovering and reporting it so that corrective action can be taken

445 446

Note to entry: The term “Control” is also used to describe this concept in some contexts. The term countermeasure has been chosen for this standard to avoid confusion with the word control in the cont ext of “process control.”

447 448

3.1.33 cryptographic algorithm

449 450

algorithm based upon the science of cryptography, including encryption algorithms, cryptographic hash algorithms, digital signature algorithms, and key agreement algorithms

451 452 453

3.1.34 cryptographic key input parameter that varies the transformation performed by a

454 455 456 457 458

Note to entry: Usually shortened to just “key.”

459 460 461 462

3.1.36 data integrity property that data has not been changed, destroyed, or lost in an unauthorized or accidental manner

463 464

Note to entry: This term deals with constancy of and confidence in data values, not with the information that the values represent or the trustworthiness of the source of the values.

465 466 467 468

3.1.37 decryption process of changing cipher text into plaintext using a cryptographic algorithm and key (See “encryption”)

469 470 471 472

3.1.38 defense in depth provision of multiple security protections, especially in layers, with the intent to delay if not prevent an attack

473 474

Note to entry: Defense in depth implies layers of following features:

equipment that controls physical processes

easured

cryptographic algorithm

3.1.35 data confidentiality property that information is not made available or disclosed to any unauthorized system entity, including unauthorized individuals, entities, or processes

security and detection, even on single systems, and provides the

475

a)

attackers are faced with brea king through or bypassing each layer w ithout being detected

476

b)

flaw i n one layer c an be mitigated by capabilities in other layers

477

c)

system security becomes a set of layers w ithin the overall network security.

478 479 480

3.1.39 demilitarized zone perimeter network segment that is logically between internal and external networks

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA-62443-1-1, D5E4, August 2015

– 16 –

ISA99, WG03

481 482 483

Note 1 to entry: The purpose of a demilitarized zone is to enforce the internal network’s policy for external information exchange and to provide external, untrusted sources with restricted access to releasable information while shielding the internal network from outside attacks.

484 485 486

Note 2 to entry: In the context of industrial automation and control systems, the term “internal network” is typically applied to the network or segment that is the primary focus of protection. For example, a control network could be considered “internal” when connected to an “external” business network.

487 488 489 490

3.1.40 denial of service prevention or interruption of authorized access to operations and functions

491 492

Note to entry: In the context of industrial automation and control systems, denial of service can refer to loss of process function, not just loss of data communications.

493 494 495 496

3.1.41 digital signature result of a cryptographic transformation of data which, when properly implemented, provides the services of srcin authentication, data integrity, and signer non-repudiation

497 498 499 500

3.1.42 distributed control system type of control system in which the system elements are dispersed but operated in a coupled manner

501 502

Note 1 to entry: Distribu ted control syste ms may have shorter in SCADA systems.

503 504 505

Note 2 to entry: Distributed control systems are commonly associated with continuous processes such as electric power generation; oil and gas refining; chemical, pharmaceutical and paper manufacture, as well as discrete processes such as automobile and other goods manufacture, packaging, and warehousing .

506 507

3.1.43 domain

508 509 510

environment context thatof is defined by a security security model, security architecture toorinclude a set system resources and the policy, set of system entities thatorhave the right to access the resources

511 512 513

3.1.44 eavesdropping monitoring or recording of communicated information by unauthorized parties

514 515 516 517

3.1.45 electronic security actions required to preclude unauthorized use of, denial of service to, modifications to, disclosure of, loss of revenue from, or destruction of critical systems or informational assets

518 519 520 521 522 523 524

Note to entry: The objective is to reduce the risk of causing personal injury or endangering public health, losing public or consumer confidence, disclosing sensitive assets, failing to protect business assets or failing to comply with regulations. These concepts are applied to any system in the production process and include both stand and networked components. Communica tions between systems may be either through internal messaging or b human or machine interfaces that authenticate, operate, control, or exchange data with any of these control systems. Electronic security includes the concepts of identification, authentication, accountability, authorization, availability , and privacy.

525 526 527 528

3.1.46 encryption cryptographic transformation of plaintext into ciphertext that conceals the data’s srcinal meaning to prevent it from being known or u sed (See “decryption”)

529 530

Note to entry: If the transformation is reversible, the corresponding reversal process is called “decryption,” which is a transformation that restores encrypted data to its srcinal state.

531 532 533 534

3.1.47 enterprise business entity that produces or transports products or operates and maintains infrastructure services

a system resource or the delaying of system

coupling time cons tants than those typi cally found

-alone y any

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA99, WG03

– 17 –

ISA-62443-1-1, D5E4, August 2015

535 536 537 538

3.1.48 equipment under control equipment, machinery, apparatus or plant used for manufacturing, process, transportation, medical or other activities

539 540 541 542

3.1.49 essential function function or capability that is required to maintain health, safety, the environment and availability for the equipment under control

543 544 545 546

Note to entry: Essential function s include, but are not limited to, the safe ty instrumented functio n (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.

547 548 549 550

3.1.50 firewall inter-network connection device that restricts data communication traffic between two connected networks

551 552 553

Note to entry: A firewall may be either an application installed on a general-purpose computer or a dedicated platform (appliance) that forwards or rejects/dro ps packets on a network. Typical ly firewalls are used to d efine zone borders. Firewal ls generally have rules restricti ng which ports are open.

554 555 556 557 558

3.1.51 gateway relay mechanism that attaches to two (or more) computer networks that have similar functions but dissimilar implementations and that enables host computers on one network to communicate with hosts on the other

559 560

Note to entry: Also described as an intermediate system that is the translation interface between two computer networks.

561 562 563

3.1.52 geographic site subset of an enterprise’s physical, geographic, or logical group of assets

564 565

Note to entry: A geographic site may contain areas, manufacturing lines, process cells, process units, control centers, and vehicles and may be connected to other sites by a wide area network.

566 567 568 569

3.1.53 host computer that is attached to a communication subnetwork or inter-network and can use services provided by the network to exchange data with other attached systems

570 571 572 573

3.1.54 industrial automation and control systems collection of personnel, hardware, and software that can affect or influence the safe, secure, and reliable operation of an industrial process

574

Note to entry: These systems include, but are not limited to:

575 576 577 578 579 580 581 582

a) industrial control systems, including distributed control systems (DCSs), programmable logic controllers (PLCs), remote terminal units (RTUs), intelligent electronic devices, supervisory control and data acquisition (SCADA), networked electron ic sensing and control, and monitoring and diagnostic systems. ( In this context, process control systems include basic process control system and safety-instrumented system [SIS] functions, whether they are physically separate or integrated.)

583 584

c) associated internal, human, network, or machine interfaces used to provide control, safety, and manufacturing operations functionali ty to continuous, batch, discrete, and other processes.

585 586 587 588

3.1.55 insider “trusted” person, employee, contractor, or supplier who has information that is not generally known to the public (See “outsider”)

b) associated information systems such as advanced or multivariable control, online optimizers, dedicated equipment monitors, graphical interfaces, process historians, manufacturing execution systems, and plant information management systems.

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA-62443-1-1, D5E4, August 2015

– 18 –

ISA99, WG03

589 590 591 592 593

3.1.56 integrity quality of a system reflecting the logical correctness and reliability of the operating system, the logical completeness of the hardware and software implementing the protection mechanisms, and the consistency of the data structures and occurrence of the stored data

594 595

Note to entry: In a formal security mode, integrity is often interpreted more narrowly to mean protection against unauthorized modificatio n or destruction of information.

596 597 598

3.1.57 interception capture and disclosure of message contents or use of traffic analysis to compromise the

599 600

confidentiality of a communication system based on message destination or srcin, frequency or length of transmission, and other communication attributes

601 602 603

3.1.58 interface logical entry or exit point that provides access to the module for logical inform

604 605 606

3.1.59 intrusion unauthorized act of compromising a system (See “attack”).

607 608 609 610 611

3.1.60 intrusion detection security service that monitors and analyzes system events for the purpose of finding, and providing real-time or near real-time warning of, attempts to access system resources in an unauthorized manner

612 613

3.1.61 ISO

614

International Organization for Standardization

615 616 617 618 619 620

3.1.62 key management process of handling and controlling cryptographic keys and related material (such as initialization values) during their life cycle in a cryptographic system, including ordering, generating, distributing, storing, loading, escrowing, archiving, auditing, and destroying the keys and related material

621 622 623 624

3.1.63 line lower-level element of a manufacturing process that performs manufacturing, field device control, or vehicle functions

625

Note to entry: See “Cell”

626 627 628 629

3.1.64 local area network communications network designed to connect computers and other intelligent devices in a limited geographic area (typically less than 10 kilometers)

630 631 632 633 634 635

3.1.65 malicious code programs or code written for the purpose of gathering information about systems or users, destroying system data, providing a foothold for further intrusion into a system, falsifying system data and reports, or providing time-consuming irritation to system operations and maintenance personnel

636 637

Note 1 to entry: Malicious code attacks can take the form of viruses, worms, Trojan Horses, or other automated exploits.

638

Note 2 to entry: Malicious code is also often referred to as “malware.”

ation flows

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA99, WG03

– 19 –

ISA-62443-1-1, D5E4, August 2015

639 640 641 642

3.1.66 manufacturing operations collection of production, maintenance, and quality assurance operations and their relationship to other activities of a production facility

643

Note to entry: Manufacturing operations include:

644 645

a) manufacturing or processing facility activities that coordinate the conversion of raw materials or parts into products.

646

b) functions that may be

647 648

c) managing information about the schedules, use, capability, definition, history, and status of all resources (personnel , equipment, and material) within the manufacturing facility.

649 650 651

3.1.67 OPC set of specifications for the exchange of information in a process control environment

652 653

Note to entry: The abbrevi ation “OPC” srcinally came from “OLE for Process Control”, where “OLE” was short for “Object Linking and Embedding.”

654 655 656 657

3.1.68 outsider person or group not “trusted” with inside access, who may or may not be known to the targeted organization (See “insider”)

658

Note to entry: Outsiders may or may not have been insiders at one time.

659 660 661

3.1.69 penetration successful unauthorized access to a protected system resource

662 663

3.1.70 plaintext

664 665

unencoded that is input to and transformed by an encryption process, or that is output by a decryptiondata process

666 667 668 669

3.1.71 privilege authorization or set of authorizations to perform specific functions, especially in the context of a computer operating system

670 671

Note to entry: Examples of functions that are controlled through the use of changing setpoints, modifying control algorithms.

672 673 674 675

3.1.72 process series of operations performed in the making, treatment or transportation of a product or material

676 677

Note to entry: This standard makes extensive use of the term “process” to describ the industrial automation and control system.

678 679

3.1.73 protocol

680 681

set of communication) rules (i.e., formats and procedures) (e.g., between systems to implement and control some type of association

682 683 684 685 686

3.1.74 reference model framework for understanding significant relationships among the entities of some environment, and for the development of consistent standards or specifications supporting that environment.

687 688

Note: A reference model is based on a small number of unifying concepts and may be used as a basis for education and explaining standards to a non-specialist.

the personnel, equipment, and material involved in

performed by physical equipment, human effort, and information systems.

privilege include acknowledging alarms,

e the equipment under control of

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA-62443-1-1, D5E4, August 2015

– 20 –

ISA99, WG03

689 690 691 692

3.1.75 reliability ability of a system to perform a required function under stated conditions for a specified period of time

693 694 695 696

3.1.76 remote access use of systems that are inside the perimeter of the security zone being addressed from a different geographical location with the same rights as when physically present at the location

697 698 699 700

Note to entry: The exact definition of “remote” can vary according to situation. For example, access may come from a location that is remote to the specific zone, but still within the boundaries of a company or organization. This might represent a lower risk than access that srcinates from a location that is remote and outside of a company’s boundaries.

701 702 703 704

3.1.77 repudiation denial by one of the entities involved in a communication of having participated in all or part of the communication

705 706 707 708

3.1.78 risk expectation of loss expressed as the probability that a particular threat will exploit a particular vulnerability with a particular consequence

709 710 711 712 713 714

3.1.79 risk assessment process that systematically identifies potential vulnerabilities to valuable system resources and threats to those resources, quantifies loss exposures and consequences based on probability of occurrence, and (optionally) recommends how to allocate resources to countermeasures to minimize total exposure

715 716 717 718

Note 1 to entry: Types of

719 720 721 722

3.1.80 risk management process of identifying and applying countermeasures commensurate with the value of the assets protected based on a risk assessment

723 724 725 726 727

3.1.81 router gateway between two networks at OSI layer 3 and that relays and directs data packets through that inter-network. The most common form of router passes Internet Protocol (IP) packets

728 729 730

3.1.82 safety freedom from unacceptable risk

731 732 733

3.1.83 safety-instrumented system system used to implement one or more safety-instrumented functions

734 735

Note to entry: A safety-instrumented system is composed of any combination of sensor(s), logic solver(s), and actuator(s).

736 737 738 739

3.1.84 safety integrity level discrete level (one out of four) for specifying the safety integrity requirements of the safetyinstrumented functions to be allocated to the safety-instrumented systems

740

Note to entry: Safety integrity level 4 has the highest level of safety integrity; safety integ

resources include physic

al, logical and human.

Note 2 to entry: Risk assessments are often combined with vulnerability assessments to identify vulnerab ilities and quantify the associated risk. They are carried out initially and periodically to reflect changes in the organization's risk tolerance, vulnerabilities, procedure s, personnel and technological changes.

rity level 1 has the lowest.

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA99, WG03

– 21 –

ISA-62443-1-1, D5E4, August 2015

741 742 743 744

3.1.85 secret condition of information being protected from being known by any system entities except those intended to know it

745 746 747

3.1.86 security 1. measures taken to protect a system

748 749

2.

condition of a system that results from the establishment and maintenance of measures to protect the system

750 751

3.

condition of system resources being free from unauthorized or accidental change, destruction, or loss

752 753 754 755

4.

capability o f a computer-based system to provide adequate confidence that unauthorized persons and systems can neither modify the software and its data nor gain access to the system functions, and yet to ensure that this is not denied to authorized persons and systems

756 757

5.

prevention of illegal or u nwanted penetration of or interference w intended operation of an industrial automation and control system

758 759

Note to entry: Measures can be controls related to physical security (controlling physical access to computing assets) or logical security (capabi lity to login to a given system and application.)

760 761 762 763 764

3.1.87 security architecture plan and set of principles that describe the security services that a system is required to provide to meet the needs of its users, the system elements required to implement the services, and the performance levels required in the elements to deal with the threat

765 766 767

environment

768 769 770 771 772 773

3.1.88 security audit independent review and examination of a system's records and activities to determine the adequacy of system controls, ensure compliance with established security policy and procedures, detect breaches in security services, and recommend any changes that are indicated for countermeasures

774 775 776

3.1.89 security control See “countermeasure”

777 778 779

3.1.90 security event occurrence in a system that is relevant to the security of the system

780 781 782

3.1.91 security incident adverse event in a system or network or the threat of the occurrence of such an event

783 784

Note to entry: The term “near miss” is sometimes used to describe an event that could have been an incident under slightly different circumstanc es.

785 786 787 788 789

3.1.92 security level level corresponding to the required effectiveness of countermeasures and inherent security properties of devices and systems for a zone or conduit based on assessment of risk for the zone or conduit

access and from unauthorized

ith the proper and

Note to entry: In this context, security architecture would be an architecture to protect the control network from intentional or unintentional security events.

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA-62443-1-1, D5E4, August 2015

– 22 –

ISA99, WG03

790 791 792 793 794

3.1.93 security objective aspect of security which to achieve is the purpose and objective of using certain mitigation measures, such as confidentiality, integrity, availability, user authenticity, access authorization, accountability

795 796 797 798

3.1.94 security perimeter boundary (logical or physical) of the domain in which a security policy or security architecture applies, i.e., the boundary of the space in which security services protect system resources

799 800 801 802

3.1.95 security policy set of rules that specify or regu protect its assets

803 804 805

3.1.96 security procedures definitions of exactly how practices are implemented and executed

806 807 808 809 810

3.1.97 security program a combination of all aspects of managing security, ranging from the definition and communication of policies through implementation of best industry practices and ongoing operation and auditing

811 812 813 814

3.1.98 security services mechanisms used to provide confidentiality, data integrity, authentication, or no repudiation of information

815 816 817 818

3.1.99 security violation act or event that disobeys or otherwise breaches security policy through an intrusion or the actions of a well-meaning insider

819 820 821

3.1.100 security zone grouping of logical or physical assets that share common security requirements

822 823

Note 1 to entry: All unqualified uses of the word “zone” in this standard should be assumed to zone.

824 825 826

Note 2 to entry: A zone has a clear border with other zones. The security policy of a zone is typically enforced by a combination of mechanisms both at the zone edge and within the zone. Zones can be hierarchic al in the sense that they can be comprised of a collection of subzones.

827 828 829

3.1.101 sensor measuring element connected to process equipment and to the control system

830 831 832

3.1.102 server device or application that provides information or services to client applications and devices

833 834 835 836 837

3.1.103 supervisory control and data acquisition (SCADA) system type of loosely coupled distributed monitoring and control system commonly associated with electric power transmission and distribution systems, oil and gas pipelines, and water and sewage systems

838 839

Note to entry: Supervisory control systems are also used within batch, continuous, and discrete manufacturing plants to centralize monitoring and control activities for these sites.

late how a system or organization provides securit

y services to

refer to a security

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA99, WG03

– 23 –

ISA-62443-1-1, D5E4, August 2015

840 841 842

3.1.104 system interacting, interrelated, or interdependent elements forming a complex whole

843 844 845 846 847

3.1.105 system software special software designed for a specific computer system or family of computer systems to facilitate the operation and maintenance of the computer system and associated programs and data

848

3.1.106

849 850 851

threat potential for violation of security, which exists when there is a circum or event that could breach security and cause harm

852 853 854 855 856

3.1.107 traffic analysis inference of information from observable characteristics of data flow(s), even when the data are encrypted or otherwise not directly available, including the identities and locations of source(s) and destination(s) and the presence, amount, frequency, and duration of occurrence

857 858 859 860 861

3.1.108 trojan horse computer program that appears to have a useful function, but also has a hidden and potentially malicious function that evades security mechanisms, sometimes by exploiting legitimate authorizations of a system entity that invokes the program

862 863 864

3.1.109 unit lower-level element of a manufacturing process that performs manufacturing, field device

865 866

control, or vehicle functions

867 868 869 870 871

3.1.110 use case technique for capturing potential functional requirements that employs the use of one or more scenarios that convey how the system should interact with the end user or another system to achieve a specific goal

872 873 874 875

Note to entry: Typically use cases treat the system as a black box, and the interactions with the system, including system responses, are as perceived from outside of the system. Use cases are popular because they simplify the description of requirements, and avoid the problem of making assumptions about how this functionality will be accomplished.

876 877 878 879

3.1.111 user person, organization entity, or automated process that accesses a system, whether authorized to do so or not

880 881 882 883

3.1.112 virus self-replicating or self-reproducing program that spreads by inserting copies of itself into other executable code or documents

884 885 886 887

3.1.113 vulnerability flaw or weakness in a system's design, implementation, or operation and management that could be exploited to violate the system's integrity or security policy

888 889 890 891

3.1.114 wide area network communications network designed to connect computers, networks and other devices over a large distance, such as across the country or world

stance, capability, action,

Note to entry: See “Cell”

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA-62443-1-1, D5E4, August 2015

– 24 –

ISA99, WG03

892 893 894 895

3.1.115 wiretapping attack that intercepts and accesses data and other information contained in a flow in a communication system

896 897 898

Note 1 to entry: Although the term srcinally referred to making a mechanical connection to an electrical conductor that links two nodes, it is now used to refer to reading information from any sort of medium u sed for a link or directly from a node, such as a gateway or subnetwork switch.

899 900

Note 2 to entry: “Active wiretapping” attempts to alter the data or otherwise affect the flow; “passive wiretapping” only attempts to observe the flow and gain knowledge of information it contains.

901

3.1.116

902 903 904

worm computer program that can run independently, can propagate a complete working version of itself onto other hosts on a network, and may consume computer resources destructively

905 906 907

3.1.117 zone See “security zone”

908

3.2

909

The following abbreviated terms and acronyms are used in this document.

even

Abbreviated terms and acronyms

ANSI

Am erica n Nat ion al Stan dards Inst itute

CIA

Confidentiality, Integrity, and Availability

CN

Control Network

COTS

Commercial Off The Shelf

IACS

Industrial Automation and Control System

IEC

International Electrotechnical Commission

ISA

International Society of Automation

ISO

International Organization for Standardization

SUC

System Under Consideration

TR

Technical Report

910

3.3

911 912 913 914

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

Conventions

915

3.3.1

916

The following terms are reserved for

917 918

shall: The word “shall ”, equivalent to "is required to", is used to indicate mandatory requirements, to be followed strictly in order to conform to the standard and from which no

919 920 921

deviation is permitted. must: The use of the word “must ” is depreciated and shall not be used when stating mandatory requirements. The word “must ” is only used to describe unavoidable situations.

922

should: The word “should ”, equivalent to "is recommended that", is used to indicate

Reserv ed terms normative clauses.

923 924

 Among several possibilities one is recommended as mentioning or excluding others.

925



That a certain course of action is preferred b ut not required.

926



That (in the negative form) a certain course of action i s depreciated but not prohibited.

927 928

particularly suitable,

without

may: The word “ma y”, equivalent to "is permitted", is used to indicate a course of action permissible within the limits of this standard.

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA99, WG03

– 25 –

ISA-62443-1-1, D5E4, August 2015

929 930

can: The word “ca n”, equivalent to "is able to", is used to indicate possibility and capability, whether material or physical.

931

3.3.2

932 933

Commensurate with ISA ‑ 62443 ‑ 2 ‑ 4, the term “Solution” is used as a proper noun (and therefore capitalized) in this document to prevent confusion with other uses of the term.

934

4

935 936

ISA ‑ 62443 is a multi-part standard designed to address the need to design cybersecurity robustness and resilience into industrial automation control systems (IACS). Robustness

937 938 939 940 941 942 943

provides the capabilities for the system under consideration (SuC) to operate under a range of cyber-induced perturbations and disturbances. Resilience provides the capabilities to restore the SuC under unexpected and rare cyber-induced events. Robustness and resilience are not general properties of IACS but a relative to specific classes of cyber-induced perturbations. A SuC that is resilient or robust to a certain type of cyber -induced perturbations may be brittle or fragile to another. Such a trade-off is the subject of profiles, which others can derive from the ISA ‑ 62443 requirements and guidelines.

944 945 946 947 948 949 950

The goal in developing the ISA ‑ 62443 series is to improve the availability, integrity and confidentiality of components or systems used for industrial automation and control, and to provide criteria for procuring and implementing secure industrial automation and control ‑ 62443 is intended to improve electronic systems. Conformance with the guidance in ISA security and help identify and address vulnerabilities, reducing the risk of compromising confidential information or causing degradation or failure of the equipment (hardware and software) of processes under control.

951 952 953

The concept of industrial automation and control systems electronic security is applied in the broadest possible sense, encompassing all types of plants, facilities, and systems in all industries. Manufacturing and control systems include, but are not limited to:

954 955

– hardware and software systems such as DCS, PLC, SCADA, sensing, and monitoring and diagnostic systems

956 957 958

–

959 960 961

Guidance is directed towards those responsible for designing, implementing, or managing industrial automation and control systems. This guidance also applies to users, system integrators, security practitioners, and control systems manufacturers and vendors.

962 963 964 965 966 967

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

968

The structure and organization of the ISA

Prope r noun s

The ISA 62443 standards

networked electronic

associated int ernal, human, network, or machine interfaces used to provide control, safety, and manufacturing operations functionality to continuous, batch, discrete, and other processes.

‑ 62443 series of work products is shown in Figure 1.

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA-62443-1-1, D5E4, August 2015

– 26 –

ISA99, WG03

969 970

Figure 1 – I SA 62443 Work Products

971 972

The standards and reports in the series are arranged in four groups or tiers, corresponding to the primary focus and intended audience.

973 974

The first of general tier includes documents that address topics that are common to the entire series. These include:

975 976

–

ISA ‑ 62443-1-1 (This document) introduces the concepts and models used throughout the series.

977 978

–

ISA ‑ TR62443-1-2 is a master glossary of terms and abbreviations used throughout the series.

979 980

–

ISA ‑ 62443-1-3 describes a series of quantitative metrics derived from the foundational requirements, system requirements and associated.

981 982

–

ISA-TR62443-1-4 provides a more detailed de scription of the underlying life cy cle for IACS security, as well as several use cases that illustrate various applications.

983 984

Documents in the second tier focus on the policies and procedures associated with IACS security. These include:

985 986

–

ISA ‑ 62443-2-1 describes what is required to define and implement an effective IACS cyber security management system.

987 988

–

ISA ‑ 62443-2-2 provides specific guidance on what is required to operate an effective IACS cyber security management system.

989 990

–

ISA ‑ TR62443-2-3 provides guidance on the specific subject of patch management for IACS.

991

–

ISA ‑ 62443-2-4 (adopted from IEC 62433-2-4) specifies requirements for suppliers of IACS.

992

Documents in the third tier address requirements at the system level. These include:

993 994

–

ISA ‑ TR62443-3-1 describes the application of various security technologies to an IACS environment.

995

–

ISA ‑ 62443-3-2 addresses security risk assessment and system design for IACS.

996 997

–

ISA ‑ 62443-3-3 describes the foundational system security requirements and security assurance levels.

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA99, WG03 998 999

– 27 –

ISA-62443-1-1, D5E4, August 2015

The fourth and final tier includes information about the more specific and detailed requirements associated with the development of IACS products. These include:

1000 1001

–

ISA ‑ 62443-4-1 describes the derived requirements that are applicable to the development of products.

1002 1003 1004

–

ISA ‑ 62443-4-2 contains sets of derived requirements that provide a detailed mapping of the system requirements to subsystems and components of the system under consideration.

1005

5

The Situation

1006

5.1

1007 1008 1009 1010

Industrial automation and control systems operate within a complex environment. Appreciation of the nature of this environment is an essential prerequisite to ensuring its security. This includes understanding the business environment, current systems and trends, and potential consequences.

1011

5.2

1012 1013 1014 1015

Organizations are increasingly sharing information between business and industrial automation systems, and partners in one business venture may be competitors in another. At the same time new technology enables more advanced capabilities in support of business needs.

1016 1017 1018

Alth oug h techno log y ch anges an d partner rela tions hip s ma y be go od for bus in ess , they increase the potential risk of compromising security. As the threats to businesses increase, so does the need for security.

1019 1020

Because industrial automation and control systems equipment connects directly to a process, loss of sensitive information or interruption in the flow of information are not the only

1021 1022 1023 1024

consequences of a security breach. The potential loss of life or production, environment damage, regulatory violation, and compromise to operational safety are far more serious consequences. These may have ramifications beyond the targeted organization; they may grievously damage the infrastructure of the host region or nation.

1025 1026 1027 1028 1029 1030 1031 1032

External threats are not the only concern; knowledgeable insiders with malicious intent or even an innocent unintended act can pose a serious security risk. Additionally, industrial automation and control systems are often integrated with other business systems. Modif or testing operational systems has led to unintended effects on system operations. Personnel from outside the control systems area increasingly perform security testing on the systems, exacerbating the number and consequence of these effects. Combining all these factors, it is easy to see that the potential of someone gaining unauthorized or damaging access to an industrial process is not trivial.

1033

5.3

1034 1035 1036 1037 1038 1039

Industrial automation and control systems have evolved from individual, i solated computers with proprietary operating systems and networks to interconnected systems and applications employing commercial off the shelf (COTS) technology (i.e., operating systems and protocols). These control systems are increasingly being integrated with non-IACS systems and applications through various communication networks. This increased level of integration provides significant business benefits, including:

1040 1041 1042 1043

a) Increased visibility of industrial control system activities (work in process, equipment status, production schedules) and integrated processing systems from the business level, contributing to the improved ability to conduct analyses to drive down production costs and improve productivity.

1044 1045

b) Integrated manufacturing a nd production systems have more di rect access to business level information, enabling a more responsive enterprise.

1046 1047

c) Common interfaces that reduce ove production processes.

Overview

Business Environment

al

ying

Current Systems

rall support costs and permit remote su

pport of

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA-62443-1-1, D5E4, August 2015 1048 1049

– 28 –

ISA99, WG03

d) Remote monitoring of the process control systems that reduces support costs and allows problems to be solved more quickly.

1050

There are definite security related considerations

associated with each of these benefits.

1051 1052 1053 1054

Devices, open networking technologies and increased connectivity provide increased opportunities 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.

1055 1056 1057 1058 1059 1060 1061

Organizations deploying general commodity information technology (IT) cyber security solutions to address IACS security may not fully comprehend the results of this 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.

1062 1063 1064 1065 1066

It is possible to define standards for models and information exchanges that allow the industrial automation and control systems community to share information in a consistent way. However, this ability to exchange information increases vulnerability to misuse and attack by individuals with malicious intent and introduces potential risks to the enterprise using industrial automation and control systems.

1067 1068 1069

Industrial automation and control systems configurations can be very complex in terms of physical hardware, programming, and communications. This complexity can often make it difficult to determine:

1070

a) who is authorized to a ccess electronic information.

1071

b) when a user can have access to the i nformation.

1072 1073

c) what data or functions a user should be able to access. d) where the access request srcin ates.

1074

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

e) how the access is requested.

1075

5.4

1076 1077

Several trends contribute to the increased emphasis on the security of industrial automation and control systems:

Current Trends

1078 1079

a) Businesses have reported more unauthorized attempts (either intentional unintentional) to access electronic information each year than in the previous year.

1080 1081 1082 1083

b) Industrial automation and control systems include more COTS software components (e.g., operating systems and protocols) and are interconnecting with business networks, making these systems susceptible to the same software attacks as are present in business and desktop devices.

1084 1085 1086

c) The use of jo int ventures, alliance p artners, and outsourced services i n the industrial sector has led to a more complex situation with respect to the number of organizations and groups contributing to security of the industrial automation and control system.

1087 1088 1089

d) Tools to automate atta cks are commonly available . The potential threat from the use of these tools now includes cyber criminals and cyber terrorists who may have more resources and knowledge to attack an industrial automation and control system.

1090 1091 1092

e) The focus on unauthorized access has broadened from amateur attackers or disgruntled employees to deliberate criminal or terrorist activities aimed at impacting large groups and facilities.

1093 1094 1095 1096

f)

The adoption of industry standard protocols such as Internet Protocol (IP) for communication between industrial automation and control systems and field devices exposes these systems to the same vulnerabilities as business systems at the network layer.

or

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA99, WG03

– 29 –

ISA-62443-1-1, D5E4, August 2015

1097 1098 1099 1100 1101 1102

These and other trends have combined to significantly increase organization’s risks associated with the design and operation of their industrial automation and control systems. At th e sam e tim e, electronic sec urity of indus trial contro l sys tem s ha s bec om e a mo re significant and widely acknowledged concern. This shift requires more structured guidelines and procedures to define electronic security applicable to industrial automation and control systems, as well as the respective connectivity to other systems.

1103

5.5

1104 1105 1106 1107

People who know the features and weaknesses of open operating systems and networks could potentially intrude into console devices, remote devices, databases, and, in some cases, control platforms. The consequences of intrusions into industrial automation and control systems may include:

Potential Consequences

1108

a) unauthorized access,

theft, or misuse of confidential information

1109

b) publication of information to unau thorized destinations

1110

c) loss of integrity or reliability of process data and production information

1111

d) loss of system availability

1112 1113

e) process upsets leading to compromised process functionali ty, inferior product quality, lost production capacity, compromised process safety, or environmental releases

1114

f)

1115

g) personal injury

1116

h) violation of legal and regulatory requirements

1117

i)

1118

j)

equipment damage

risk to public health and confidence threats to a nation’s security.

1119

5.6

Impact of Countermeasures

1120 1121 1122 1123 1124 1125 1126

Security countermeasures applied in an IACS environment should not have the potential to cause loss of essential services and functions, including emergency procedures. IACS security goals focus on control system availability, plant protection, plant operations (even in a degraded mode) and time-critical system response. General purpose security goals often do not place the same emphasis on these factors and 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 achieved.

1127 1128 1129 1130 1131

A ke y step in ris k ass es sm ent , as requ ired by ISA ‑ 62443-2-1, is 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.) 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.

1132

5.7

1133 1134 1135

There are a number of common constraints that shall be adhered to in the application of security to an IACS. This clause and subsequent normative clauses furnish the material necessary to build extensions to existing enterprise security to support the rigorous integrity

1136

and availability requirements needed by IACS.

1137

5.7.1

1138

5.7.1.1

1139 1140

Security measures shall not adversely affect essential functions of a high availability IACS unless supported by a risk assessment.

1141 1142

NOTE: Refer to ISA ‑62443-2-1 regarding the documentation requirements associated with the risk assessment required to support instances where security measures may affect essential functions.

1143

5.7.1.2

1144 1145

When reading, specifying and implementing the normative requirements in this standard, implementation of security measures should not cause loss of protection, loss of control, loss

Common Constraints

GEN 1.0 – Support of Essential Functions Requirement

Rationale

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA-62443-1-1, D5E4, August 2015

– 30 –

ISA99, WG03

1146 1147 1148 1149

of view or loss of other essential functions. After a risk analysis, some facilities may determine certain types of security measures may halt continuous operations, but security measures shall not result in loss of protection that could result in health, safety and environmental (HSE) consequences. Specifically;

1150 1151

– Access Controls including:

(IAC and UC ) shall not prevent the operation of e ssential functions,

1152

–

1153 1154

– Verifying and recording operator a ctions to enforce non-repudiation shall not significant delay to system response time.

1155 1156

– For high availability control systems, the interrupt essential functions.

1157 1158

–

Identification and authentication shall authorization enforcement.

–

Incorrectly time stamped audit records shall not adversely affect essential functions.

1159

Accounts used for essential functions shall not be locked out, even temporarily. add

failure of the certificate authority s hall not

not prevent the initiation of the SIF. Similarly for

1160 1161

–

Essential functions of an IACS shall be maintained i f zone boundary protection fail-close and/or island mode.

goes into

1162 1163

–

A denial of service (DoS) event on the control system or safety instr umented system (SIS) network shall not prevent the SIF from acting.

1164

5.7.2

1165

5.7.2.1

1166

As used in th is doc um ent , t he y s ha ll adh ere to the gu ide lin es des cribe d in ISA ‑ 62443-3-2.

1167

5.7.2.2

1168

In this standard, normative language may state that the control system shall provide the

1169 1170 1171 1172 1173 1174

capability to support some specific security requirement. The control system shall provide the capability, but it might be performed by an external component. In such a case, the control system shall provide an ‘interface’ to that external component. Some examples of compensating countermeasures include user identification (including centralized versus distributed), password strength enforcement, signature validity checking, security event correlation and device decommissioning (information persistence).

1175 1176 1177

NOTE 1 The control system security requirements detailed in this document pertain to all technical functions relevant to a control system including tools and app lications. Howev er, as noted here, some of these functions can be handled by an external resource.

1178 1179 1180 1181 1182 1183

NOTE 2 In some high resource availability applications (high SL-T(RA,control system)), compensating countermeasures external to the control system (such as additional physical security measures and/or enhanced personnel background checks) will be needed. In these cases, it may be possible to see a normally high resource availability SL control syste m at a lower IAC SL 1 or 2 rating, depending upon the compensating countermeasur es. Lockout or loss of control due to security measures is increased, not decreased for very high availabili ty SL control system. Thus higher SLs are not always “better”, even where cost is not a significant factor.

1184

6

1185

6.1

1186 1187 1188 1189 1190

The analysis of a complex system often leads to the breakdown of its elements into three broad categories; “people ”, “processes ”, and “technology ”. This has also been referred to as the people-process-technology triad or triangle. Although this approach has been applied to many types of business and technical processes its application to cyber security can be summarized in the following figure.

GEN 2.0 – Compensating countermeasures Requirement

Rationale

Security Elements Introduction

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA99, WG03

– 31 –

P

c ro

s s e

T e ch

ISA-62443-1-1, D5E4, August 2015

n

Security

o

lo

g

y

People 1191 1192

Figure 2 – Security Elements Grouping

1193 1194 1195 1196 1197

Strong processes can often help to overcome potential vulnerabilities in a security product, while poor implementation can render good technologies ineffective. Often, human weaknesses can diminish the effectiveness of technology. A prime example is the IACS devices that have unnecessary Internet and networking services running simply because users are unaware that these services are running by default and could contain vulnerabilities.

1198

6.2

1199 1200 1201 1202 1203

People in the context of IACS cyber security includes the management, staff, contractors, and other personnel who develop, follow, implement, enforce, and manage all components of the IACS cyber security program. It is important that all stakeholders and participants positively support and promote security, they understand their roles and responsibilities, and there are sufficient resources in place.

1204

The following topic areas fall under people:

1205 1206 1207 1208 1209 1210

–

1211 1212 1213 1214

–

Intent, Buy-In, Support - Ensure that all personnel have the intent and motivation to uphold cyber security policies, practices, and ensure continual improvement. People could be defiant or entirely supportive of the security program and is measured as a scale of individual participation.

1215 1216 1217

–

Resourcing - Having the appropriate staffing levels and time commitment to perform the tasks associated with the IACS Security Management System (e.g. log reviews, patching, risk assessment).

1218 1219 1220 1221

–

Roles & Responsibilities - D efine who owns the process, who supports the process, what are their roles, are they committed to improving the program and working together. There is a commonly used method for assigning those Responsible, Accountable, Consulted, and Informed (RACI) for each task of the process.

1222 1223 1224 1225

– Training and C apability - Ensure that existing personnel are adequately qualified to perform the duties associated with IACS security. As well, ensure that new capabilities are developed where they may not have existed in the organization before (e.g. risk analysis, security intelligence, vulnerability management).

1226 1227 1228

– -Awareness and I nfluenced Decision Making - Ensure that personnel have sufficient awareness and understanding of security policies and security processes as it will influence their decision making and voluntary use of these processes.

1229 1230 1231

A measurem ent of suc cess for effec ti vel y add re ssing these iss ues is a culture of sec urit y within the organization with people motivated and active promoting adherence with security requirements.

People

Relationships - Make a concerted effort to break down the traditional relationship barriers between the Control and IT groups from the technical all the way up to the management levels of the organization. The goal is to have cooperative relationships across the different functional areas of the company, and organizational levels. This also applies to the relationship between the Asset Owner and the Vendor/Integrator responsible for installing and maintaining the IACS.

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA-62443-1-1, D5E4, August 2015

– 32 –

ISA99, WG03

1232 1233 1234

At th is tim e, guidanc e on address ing social and organ iza tional behaviors wit hi n an organization are not part of the ISA ‑ 62443 series of documents and may be reconsidered in the future.

1235

6.3

1236 1237 1238 1239 1240

Processes in the context of IACS cyber security are the policies, procedures, forms, business processes, and other documentation associated with the IACS Security Management System. The objective is to establish a business process and task to be completed in relation to the IACS Security Management System such change control, access management, patching, inventory management, security testing, etc.

1241 1242

Processes can be implemented in several ways, but are built upon smaller components of documentation.

1243 1244 1245

– Policy - A policy is a formal, b rief, and high-level sta tement or plan that embraces an organization's general beliefs, goals, objectives, and acceptable procedures for a specified subject area.

1246 1247 1248 1249 1250 1251 1252

– Standard, Procedures - A standard is a formal document that establishes mandatory requirements, engineering, technical criteria, methods, etc. A standard is meant to convey a mandatory action or rule and is written in conjunction with a policy. A process or procedure document may also be called a standard, which typically describes the act of taking something through an established and usually routine set of procedures or steps to convert it from one form to another, such as processing paperwork to grant physical or cyber access, or converting computer data from one form to another.

1253 1254 1255 1256

–

1257 1258 1259 1260

In the context of the ISA ‑ 62443 series, the specific structure and content of policies, standards, and guidelines are left to the IACS asset owner. However, the series organizes the subject areas associated with IACS processes in the following clauses, categories and domains:

1261

– Security Policy

1262

– Organization of Security

1263

– Asset Management

1264

– Human Resources Security

1265

– Physical and Environmental Security

1266

– Communications and Operations Management

1267

– Access Control

1268

–

1269

– Incident Management

1270

– Business Continuity Management

1271

–

1272 1273 1274 1275

For a traditional information system, requirements and detail for the clauses above can be found in ISO/IEC 27002 Code of Practice for Information Security Management. For an IACS Security Management System, the unique requirements and enhancements can be found in ISA ‑ 62443-2-1 (Requirements for an IACS Security Management System).

1276

6.4

1277 1278 1279 1280

Technology in the context of IACS cyber security are all the technical security controls in place to uphold its availability, integrity, and confidentiality. This would include traditional solutions for authentication, access control, encryption, as those technical measures are applied to reduce the security risks to the IACS. The objective of technology relative to IACS

Processes

Guideline - G uidelines are not required as part of a policy framework; however, they can play an important role in conveying best practice information to the user community. Guidelines are meant to “guide” users to adopt behaviors which increase the security posture of a network, but are not yet required (or in some cases, my never be required).

Systems acquisition, development and maintenance

Compliance

Technology

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA99, WG03

– 33 –

ISA-62443-1-1, D5E4, August 2015

1281 1282

is to ensure that security risks are reduced and security-related business processes could be automated where feasible.

1283 1284

In the context of the ISA ‑ 62443 series, the organization of the technical security controls are grouped in to the following categories:

1285

–

1286

– Use Control (UC)

1287

– System Integrity (SI)

1288

– Data Confidentiality (DC)

1289

– Restrict Data Flow (RDF)

1290

–

1291

– Resource Availability (RA)

1292 1293 1294 1295 1296

For more information on the seven (7) subjects above, refer to the clause on Foundational Requirements. Additional detail is provided in ISA ‑ 62443-3-3 (System Security Requirements and Security Levels). These foundational requirements are expressed in terms of IACS, and are robust enough categories to allow any security control or setting (e.g., firewall rules, running services) to have an appropriate category.

1297

6.5

1298 1299

Anti vir us soft war e is a good exa mp le of ho w people-p roces s- technology all have ro les in its effectiveness.

1300 1301 1302 1303 1304

Antivirus Technology – Once deployed, it is important that antivirus software is correctly configured to fulfill its expected responsibility to deter and prevent malicious code. Antivirus software should also be regularly updated to ensure it has the latest detection signatures. Lastly, antivirus software technology on its own is not a panacea and other technical security controls are also recommended.

1305 1306 1307 1308

Antivirus Processes – A policy must exist to require the use and maintenance of antivirus software, as well as procedures for its correct deployment, operations and maintenance. A failure in a business process would be that a malicious code detection goes unnoticed as there are no requirements to monitor alerts or respond to these incidents.

1309 1310 1311 1312 1313

Antivirus People (Personnel) – Trained individuals must be assigned the responsibility of managing the antivirus technologies and accountable for its correct operation. If staff are insufficient trained it leads to configuration errors, if there are insufficient staff this leads to incomplete system maintenance, and if accountability is not clearly communicated it leads to overall disregard and disrepair of this technology investment.

1314 1315 1316

The antivirus example helps illustrate how the people-process-technology triad applies to cyber security controls. If any part of the triad is neglected it will lead to poor performance and/or failure of the IACS security program.

1317 1318

Consider the roles of people-process-technology similar to a table with three legs. If attention and resources is lacking to any of them, the table will fall over similar to the challenges faced

1319

by an IACS security program.

Identification, Authentication and Access Control (AC)

Timely Response to Event (TRE)

Use Cases

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA-62443-1-1, D5E4, August 2015

– 34 –

e P

le p o

ISA99, WG03

Pr oc es s

rity cu y Se log

o chn Te

1320 1321 1322 1323 1324 1325 1326 1327 1328 1329

Figure 3 – Three-Legged Table Change control and configuration management is particularly important to assuring the security integrity, trust and confidence of the IACS. The seemingly subtle configuration changes within the control systems components could be excluded from change control processes because they are quick to perform and are assumed to have limited, controllable effects. However, these same changes can have drastic effects on the operability, reliability, and vulnerabilities associated with the IACS. Using the people-process-technology triad as a methodology to resolve this problem, the following strategies and solutions could be applied. Table 1 – Elements Applied to Change Control and Configuration Management People

Processes

Technology

It is recommended that this

subject is started first to have th

e greatest success.

-

Obtain Senior Management support that all IA CS changes must be authorized and th e adoption of security risk assessment into the change control process is required.

-

Identify those individuals in the or ganization who are accountable for ensuring their

-

business unit adheres to the change control process. Identify those responsib le in the o rganization for supporting the change control process and their respective roles.

-

Communicate to and provide training to all participants of the change control process.

This subject is started once strategies for

“people ” are in progress.

-

Document the appropriate policy that all staff and contractors must follow change control standards and procedures.

-

Identify and update a ll exis ting cha nge c ontrol processes to in clude review of all IACS changes, and evaluation of its security risks.

-

Develop training programs and sessions on the new processes and procedures .

-

Monitor and audit the success the this new program and adjust as needed.

Technology may be considered to improve productivity, efficiency, and process consistency.

-

Develop technical requirements for the submission of change requests, evaluation, approval, and evidence retention.

-

Migrate proven change control procedure s and forms into the technology platform. Verify consistency with paper-based methods.

-

Implement technology to identify and track configuration changes of all IACS components, hardware , and software.

1330 1331 1332 1333 1334

The example above is not a detailed plan for improving change control and configuration management processes, but it effectively summarizes the importance of the people-processtechnology triad. In reality, the three aspects people-process-technology must be addressed simultaneously in order to have the greatest success.

1335 1336

In the following sections each of the principles of people, process and technology are further defined and their subjects identified.

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA99, WG03

– 35 –

ISA-62443-1-1, D5E4, August 2015

1337

6.6

1338 1339 1340

Now that the concepts of people, processes, and technology are cl early defined; they can now be visualized with their respective subject areas. The core and foundational principle of the IACS Security Management System is the people-process-technology triad.

Summary

s e s u la

Or Se ga cur ni Ph Hu As zation of ity Polic mu ysi y s m Se et ca nic an cu M l Sy a a R a tion rity nd ste es na ou En ge sa ms rce me vir nd acq o s n Op nm t Se uis era en cu itio tal rity tio n, ns Se de cu Ma ve rity lop na ge Ac me me s ces nt Bu nt s an sC sin dm e Inc on ess ain tro ide c l Co ten nt o nti Ma an r nu c na e P ity ge Ma me na nt ge me Co nt mp lian ce C

Au

Com

n Ide

tific

Us

T e

ation,

eC

( rol ont

st Sy

ch n

Security

n the

e

ta Da

s e ti lii ib s n o p s e R & s le o R

s p i h s n io t a l e R

tr o p p u S , n Iy u B t, n e t n I

b a p a C d n a g n i n i ra T

Co

F ou nd at io na l

e nfid Co

Re

R

eq ui re m ents

nti

ct D stri e Tim

C) y (D alit

ata

Flo

e ly R

Re y t lii

e ss

I) y (S grit

People

g n i rc u o s e R

tio

A cc

)

) UC

nte mI

o lo g y

tica

nd na

C l (A ntro

RD w(

sp o

so u

rc

n se

v eA

F)

to E

aila

ve n

ty bili

) RE t (T

) (RA

s s e n re a w A d n a s n io is c e D

Not part of ISA-62443 series of documents

1341 1342

Figure 4 – Implementation of People, Process, and Technology

1343 1344 1345 1346 1347

‑ 62443 The technical requirements associated with IACS security are prescribed by the ISA standards commensurate with the Security Level (SL) assigned to each zone and con duit. The Foundation Requirements defined in ISA ‑ 62443-1-1 are the categories used to organize these technical security controls, and set the foundation for other ISA ‑ 62443 normative requirements.

1348 1349 1350

The policy and procedure (process) requirements build off of ISO/IEC 27002 with specific requirements unique to IACS. The clauses in ISA ‑ 62443-2-1 are the categories used to organize security processes.

1351 1352 1353 1354 1355

The personnel and resource (people) requirements associated with an IACS Security Management System are outside the scope of ISA ‑ 62443. Although it is considered extremely important, the outputs of ISA ‑ 62443 shall continue to be focused on technical and process requirements. Readers are advised to research and study topics such as organizational behavior, instituting change, and other business sociology and leadership materials.

1356 1357 1358

Each of these essential elements are reflected in a description of cyber security related concepts. These concepts in turn are broken into two groups. The first group includes the concepts that are applicable to virtually any cyber security response, while the second group

1359 1360

includes concepts that are specific or unique to the industrial automation and control systems environment. Each of these groups are described in subsequent clauses.

1361

7

1362

7.1

1363 1364 1365 1366

The People element of a cybersecurity management system shall be addressed through the definition and consistent application of a set of common role descriptions. These descriptions shall define the specific accountability and responsibilities of each role, as well as the relationships and dependencies between roles.

1367

As a minimum the roles described s hall inc lude the follo win g:

Principal Roles General

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA-62443-1-1, D5E4, August 2015

– 36 –

ISA99, WG03

1368 1369 1370

Asset Owner – This is the person or organization that has primary accountability for the IACS and its security. Responsibilities include the identification of the consequence component of risk, and the consistent operation of the cybersecurity management system.

1371 1372 1373 1374

Asset Operator – This is the person or organization that is accountable for the operation of the system under consideration. This may or may not be the same entity as the Asset Owner. For example, the Asset Owner may be different in situations involving some sorts of joint ventures or similar business structures.

1375 1376

System Integrator – It is common for an IACS to be designed and configured by an independent or external system integrator, according to specifications and requirements

1377

provided by the asset owner.

1378 1379

Product Supplier – The principal responsibility of the product supplier is to design and provide the specific components that are used to assemble the IACS.

1380 1381

Service Provider – Ensuring the security of an IACS also requires services throughout the life cycle, including regular maintenance and system updates.

1382 1383 1384

Compliance Authority – Organizations in this role include government agencies and regulators with the legal authority to perform audits to verify compliance with governing laws and regulations.

1385 1386

More details about the contributions of each of these r Life Cycle fundamental concept.

1387

8

1388 1389

In order to fully articulate the systems and components the ISA ‑ 62443 standards address, the range of coverage may be described from several perspectives, including:

IACS Definition

1390

1) range of functionality included

1391

2) systems and interfaces

1392

3) criteria for sele cting included activities

1393

4) criteria for selecting included assets

1394

oles is provided in the description of the

5) consequence based criteria

1395

Each of these is described in the following paragraphs.

1396

8.1

1397 1398 1399

The scope of IACS security can be described in terms of the range of functionality within an organization’s information and automation systems. This functionality is typically described in terms of one or more models.

1400 1401 1402 1403

This standard is focused primarily on industrial automation and control, as described in a reference model (see page 38). Industrial automation and control includes the supervisory control components typically found in process industries, as well as SCADA (supervisory control and data acquisition) systems that are commonly used by organizations that operate in

1404

critical infrastructure industries. These include:

Functionality Included

1405

a) electricity transmission and distribution

1406

b) gas and water distribution networks

1407

c) oil and gas production operations

1408 1409 1410

d) gas and liquid transmission pipelines This is not an exclusive list. SCADA systems may also be found in other critical and noncritical infrastructure industries.

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA99, WG03

– 37 –

ISA-62443-1-1, D5E4, August 2015

1411 1412 1413

While business planning and logistics s ystems are not explicitly addressed within the scope of this standard, the integrity of data exchanged between business and industrial systems is considered.

1414

8.2

1415 1416 1417 1418

It is also possible to describe the IACS in terms of connectivity to associated systems. In encompassing all industrial automation and control systems, this standard covers systems that can affect or influence the safe, secure, and reliable operation of industrial processes. They include, but are not limited to:

Systems and Interfaces

1419 1420 1421 1422 1423 1424 1425

a) Industrial control systems and their associated communications networks, including distributed control systems (DCS’s), programmable logic controllers (PLC’s), remote terminal units (RTU’s), intelligent electronic devices, SCADA systems, networked electronic sensing and control, metering and custody transfer systems, and monitoring and diagnostic systems. In this context, industrial control systems include basic process control system and safety-instrumented system (SIS) functions, whether they are physically separate or integrated.

1426 1427 1428 1429 1430

b) Associated systems at level 3 or below of the Reference Model. Examples include advanced or multivariable control, online optimizers, dedicated equipment monitors, graphical interfaces, process historians, manufacturing execution systems, pipeline leak detection systems, work management, outage m anagement, and electricity energy management systems.

1431 1432 1433

c) Associated internal, human, network, software, machine or device interfaces used provide control, safety, manufacturing, or remote operations functionality to continuous, batch, discrete, and other processes.

to

1434

8.3

1435 1436 1437 1438

ANSI/I SA-95.00.0 3 [5] def ine s a set of crit eria for definin g activit ies ass ociat ed wit h manufacturing operations. A similar list has been developed for determining the scope of this standard. A system should be considered to be within the range of coverage of these standards if the activity it performs is necessary for any of the following:

Activity-Based Criteria

1439

a) predictable o peration of the process

1440

b) process or personnel safety

1441

c) process reliability or availability

1442

d) process efficiency

1443

e) process operability

1444

f)

1445

g) environmental protection

1446

h) compliance with relevant re gulations

1447

i)

product quality

product sales or custody transfer affecting or influencing industrial processes.

1448

8.4

Asset-Based Criteria

1449

The coverage of this standard includes those systems in assets that meet any of the following

1450 1451

criteria, or whose security is essential to the protection of other assets that meet these criteria:

1452 1453

a) The asset is necessary to process.

maintain the economic value of

1454 1455

b) The asset performs a process.

1456

c) The asset represents intellectual

1457 1458

d) The asset is necessary to operate and maintain security for a manufacturing or operating process.

function necessary to operation

a manufacturing or operating

of a manufacturing or o perating

property of a manufacturing or operating pro cess.

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA-62443-1-1, D5E4, August 2015

– 38 –

ISA99, WG03

1459 1460

e) The asset is necessary t o protect personnel, contractors, and visitors involv manufacturing or operating process.

1461

f)

1462 1463

g) The asset is necessary to protect the operating process.

1464 1465

h) The asset is a legal requirement, especially operating process.

1466

i)

The asset is needed for disaster recovery.

1467

j)

The ass et is needed fo r log gi ng sec urit y e ven ts.

ed in a

The asset is necessary to protect the environment. public from events caused by a manufacturing or for security purposes of a manufacturing or

1468 1469 1470 1471

This range of coverage includes systems whose compromise could result in the endangerment of public or employee health or safety, loss of public confidence, violation of regulatory requirements, loss or invalidation of proprietary or confidential information, environmental contamination, and/or economic loss or impact on an entity or on local or national security.

1472

8.5

1473 1474 1475 1476 1477 1478

During all phases of the system’s life cycle, cybersecurity risk assessments shall include a determination of where and what could go wrong to disrupt IACS operations, what is the likelihood that a cyber-attack could initiate such a disruption, and what are the consequences that could result. The output from this determination shall include sufficient information to help the ordinary user (not necessarily security-conscious ones) to identify and determine the relevant security properties.

1479 1480 1481 1482 1483 1484

The method of determination shall include a decom position of a system under consideration in accordance with the specifications in ISA ‑ 62443-3-2 and make visible the interaction between individual components. Functional relationships and the models used to translate the security strength of lower level components into aggregated measures shall be delineated to the degree necessary to determine the response action in accordance with the specifications in ISA ‑ 62443-1-3.

1485

9

1486

9.1

1487 1488 1489

A set of mo de ls sh all be deve lop ed as th e basis for id ent ifyin g th e sec urit y needs and important characteristics of the environment at a level of detail necessary to address security issues with a common understanding of the framework and vocabulary.

1490

Specific models that shall be used include:

Consequence-Based

Criteria

Models General

1491 1492

a) a reference model that provides the overall conceptual basis for the more detailed models that follow.

1493 1494 1495 1496

b) a reference architecture that describes the configuration of assets. A reference architecture can be unique for each enterprise or subset of the enterprise. It is unique for each situation depending on the scope of the industrial automation and control system under review.

1497 1498 1499

c) a zone model that groups reference architecture components according to defined characteristics. This provides a context for the definition of policies, procedures, and guidelines, which in turn are applied to the assets.

1500 1501

Al l of th is inf orm ation is used to de vel op a det ailed program for ma naging th e sec urity of an industrial automation and control system.

1502

Each of these models is described in more detail in the following pages.

1503

9.2

1504 1505 1506

A ref erence mo del est ab lis hes a fram e of ref erenc e for the mo re det ailed inf orm ati on that follows. The term “reference model” became popular with the success of the ISO “Seven Layer” model for Open Systems Interconnection (OSI).

Reference Model

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA99, WG03 1507 1508 1509 1510 1511

– 39 –

ISA-62443-1-1, D5E4, August 2015

A refere nce mo del des cribe s a generic view of an int egr ated ma nufac turing or pro duction system, expressed as a series of logical levels. The reference model used by the ISA ‑ 62443 series of standards appears in figure 5. This model is derived from the general model used in ANSI/I SA-95.00.0 1-2000, Enterp rise -C ontro l Sy ste m Integration Part 1: Mode ls and Terminology [4].

Level 4

Enterprise Systems (Engineering, Business Planning & Logistics)

Operations / Systems Management

Level 3

Supervisory Control

Site Monitoring & Local Display

Level 2

Industrial Automation and Control Systems Basic Control

Level 1 Safety and Protection

Level 0

Process (Equipment Under Control)

1512 1513

Figure 5 – Reference Model

1514 1515 1516

Detailed descriptions of each of the levels in this model are provided in ANSI/ISA-95.00.012000, Enterprise-Control System Integration Part 1: Models and Terminology, and summarized in the following paragraphs.

1517

9.2.1

1518 1519 1520 1521 1522 1523

This level (also described as “Business Planning and Logistics”) is defined as including the functions involved in the business-related activities needed to manage a manufacturing organization. Functions include enterprise or regional financial systems and other enterprise infrastructure components such as production scheduling, operational management, and maintenance management for an individual plant or site in an enterprise. For the purposes of this standard, engineering systems are also considered to be in this level.

1524

9.2.2

1525 1526 1527

This level includes the functions involved in managing the work flows to produce the desired end products. Examples include dispatching production, detailed production scheduling, reliability assurance, and site-wide control optimization.

1528

9.2.3

1529 1530 1531

This level includes the functions involved in monitoring and controlling the physical process. There are typically multiple production areas in a plant such as distillation, conversion, blending in a refinery or the turbine deck, and coal processing f acilities in a utility power plant.

1532

9.2.4

1533 1534

This level includes the functions involved in sensing and manipulating the physical process. Process monitoring equipment reads data from sensors, executes algorithms if necessary,

Level 4 – Enterprise Business Systems

Level 3 - Operations Management

Level 2 – Supervisory Control

Level 1 – Local or Basic Control

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA-62443-1-1, D5E4, August 2015

– 40 –

ISA99, WG03

1535 1536 1537 1538 1539 1540

and maintains process history. Examples of process monitoring systems include tank gauging systems, continuous emission monitors, rotating equipment monitoring systems, and temperature indicating systems. Process control equipment is similar. It reads data from sensors, executes a control algorithm, and sends an output to a final element (e.g., control valves or damper drives). Level 1 controllers are directly connected to the sensors and actuators of the process.

1541 1542

Level 1 includes continuous control, sequence control, batch control, and discrete control. Many modern controllers include all types of control in a single device.

1543

Also inc lud ed in Le vel 1 are safety and protection system s 2 that monitor the process and

1544 1545 1546

automatically return the process to a safe state if it exceeds safe limits. This category also includes systems that monitor the process and alert an operator of impending unsafe conditions.

1547 1548 1549 1550 1551

Safety and protection systems have traditionally been implemented using physically separate controllers, but more recently it has become possible to implement them using a method known as “logical separation,” within a common infrastructure. The depiction shown in this reference model was chosen to emphasize the need for this separation (logical or physical) to ensure the integrity of the safety functions.

1552

Level 1 equipment includes, but is not

1553

d) DCS controllers

1554

e) PLCs

1555

f)

limited to:

RTUs.

1556 1557 1558

Safety and protection systems often have additional safety requirements that may not be consistent or relevant to cyber security requirements. These systems include the safety systems in use in chemical and petrochemical plants as identified in the ANSI/ISA -84 series of

1559 1560

standards, nuclear plant safety or safety-related systems as identified in the ANSI/ISA-67 series, and protective functions as identified in IEEE Power Engineering Society standards.

1561

9.2.5

1562 1563 1564 1565 1566

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

1567

9.3

1568 1569 1570 1571

The reference architecture model shall be used to describe the various operational components and how they are connected. The details are specific to each individual system under consideration. Each organization shall create one or more physical architecture mode depending on the business functions performed, as well as the functions under review.

1572 1573

It would be common for an organization to have a single generic model that has been generalized to cover all operating facilities. An example of a simplified reference architecture

1574

model for a manufacturing function is shown in Figure 6.

Level 0 – Process

Reference Architecture Model

————————— 2 These systems are referred to as

“safety instrumented systems

” in standards such as the

ANSI/ISA-84 series.

ls

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA99, WG03

– 41 –

ISA-62443-1-1, D5E4, August 2015

Enterprise Laptop computer

Workstation

Mainframe Server

Plant A

Plant B

Plant C

Router Laptop computer Workstation

File/Print App. Server Server

Router Laptop computer Workstation

Data Server

File/Print Server

Plant A Control System

App. Server

Data Server

Controller

I/O

1575

Maint. Server

Data Server

Data Server

Controller

I/O

1576

File/Print Server

App. Server

Data Server

Plant C Control System Firewall

App. Server

Controller

Router Laptop computer Workstation

Plant B Control System Firewall

App. Server

Server

I/O

Maint. Server

Controller

I/O

Firewall

App. Server

Data Server

Controller

I/O

Maint. Server

Controller

I/O

Figure 6 – Physical Architecture Model Example

1577

9.4

1578 1579

A zon e mo del shal l be develop ed from the ph ysical arc hit ect ure model. It shall be used to describe the logical groupings of assets within an enterprise or a subset of the enterprise.

Zone Model

1580 1581 1582 1583 1584 1585 1586

The assets shall be grouped into entities (e.g., business, facility, site, or IACS) that can then be analyzed for security policies and hence requirements. The model provide the context for assessing common threats, vulnerabilities, and the corresponding countermeasures needed attain the level of security required to protect t he grouped assets. After grouping assets in t manner, a security policy shall be defined for all assets that are members of the zone. This analysis shall be used to determine the appropriate protection required based on the activities performed in the zone.

1587

10 General Concepts

1588 1589 1590

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

1591

10.1

1592 1593

The security context forms the basis for the interpretation of terminology and concepts and shows how the various elements of security relate to each other. The term security is

1594 1595 1596 1597

considered here to mean the prevention illegal or unwanted penetration or interference with the proper and intended operationof of an industrial automation andof control system. Electronic security includes computer, network, or other programmable components of the system.

1598 1599 1600 1601

The context of security is based on the concepts of threats, risks, and countermeasures, as well as the relationships between them. The relationship between these concepts can be shown in a simple model. One such model is described in the international standard ISO/IEC 15408-1 (Common Criteria) [15]. It is reproduced in Figure 7.

Security Context

to his

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA-62443-1-1, D5E4, August 2015

– 42 –

ISA99, WG03

value Owners

wish to minimize

impose Countermeasures

To reduce

Threat Agents

Risk

to that increase Threats

Assets

to

give rise to wish to abuse and/or may damage

1602 1603 1604 1605 1606

Figure 7 – Context Element Relationships A different vie w of the re lations hip is sh own in Figur e 8, which show s how an ex panded set of concepts are related within the two interconnected processes of information security assurance and threat-risk assessment. Information Security Assurance

Assurance Techniques

Evaluation

produce

Threat-Risk Assessment

gives evidence of Assurance

Owners require

Threats Confidence

using Vulnerabilities

in

require Countermeasures

to minimize Risk

to Assets

1607 1608

Figure 8 – Context Model

1609

10.2

1610 1611 1612 1613 1614

Information security has traditionally focused on achieving three objectives, confidentiality, integrity, and availability, which are often abbreviated by th e acronym “CIA.” An information technology security strategy for typical “back office” or business systems may place the primary focus on confidentiality and the necessary access controls needed to achieve it. Integrity might fall to the second priority, with availability as the lowest.

Security Objectives

1615 1616 1617 1618 1619 1620 1621

In the industrial automation and control systems environment, the general priority of these objectives is often different. Security in these systems is primarily concerned with maintaining the availability of all system components. There are inherent risks associated with industrial machinery that is controlled, monitored, or otherwise affected by industrial automation and control systems. Therefore, integrity is often second in importance. Usually confidentiality is of lesser importance, because often the data is raw in form and must be analyzed within context to have any value.

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA99, WG03

– 43 –

ISA-62443-1-1, D5E4, August 2015

1622 1623 1624

The facet of time responsiveness is significant. Control systems can have requirements of system responsiveness in the 1 millisecond range, whereas traditional business systems are able to successfully operate with single or multiple second response times.

1625

10.3

1626 1627 1628 1629 1630

The principle of least privilege means giving a user or application only those privileges which are essential to complete the necessary tasks. When applied to users, the terms least user access or least-privileged user account (LUA) are also used, referring to the concept that all user accounts at all times should run with as few privileges as possible, and also launch applications with as few privileges as possible.

1631

10.4

1632 1633 1634 1635

It is typically not possible to achieve the security objectives through the use of a single countermeasure or technique. A superior approach is to use the concept of defense in depth, which involves applying multiple countermeasures in a layered or stepwise manner. For example, intrusion detection systems can be used to signal the penetration of a firewall.

1636

10.5

1637 1638 1639 1640

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

1641

10.6

1642

10.6.1

1643 1644 1645

Security policies enable an organization to follow a consistent program for maintaining an acceptable level of security. Policies are defined at different levels in an organization, ranging from governance or management policies established at the enterprise level to operation

1646 1647

policies defining the details of security administration. Policies at the most specific level are the organization's standard against which security audits can measure compliance.

1648 1649 1650 1651 1652 1653 1654

A security po lic y is a for ma l, brief , and high -l eve l statem ent or pl an that embraces an organization’s general beliefs, goals, objectives, and acceptable procedures that specify or regulate how an organization protects sensitive and critical system resources. Policies unambiguously state what is mandatory. Because policies are mandatory and unambiguous, they make audits possible. The organization's security policies also take into account legal, regulatory, and contractual obligations. They are the measuring stick against which audits test the actual practices of the organization.

1655 1656 1657 1658 1659 1660 1661 1662

Complementing policies are standards and procedures. A standard is a formal document that establishes mandatory requirements, engineering, technical criteria, methods, etc. A standard is meant to convey a mandatory action or rule and is written in conjunction with a policy. A process or procedure document may also be called a standard, which typically describes the act of taking something through an established and usually routine set of procedures or steps to convert it from one form to another, such as processing paperwork to grant physical or cyber access, or converting computer data from one form to another. Security procedures define in detail the sequence of steps necessary to provide a certain security measure.

1663 1664 1665 1666 1667 1668 1669 1670 1671

Contrasting with policies, standards and procedures are guidelines. Guidelines are not mandatory. They are intended to describe a way to do something that is desirable but not mandatory and are not a required element of a policy framework; however, t hey can play an important role in conveying best practice information to the user community. Guidelines are meant to “guide” users to adopt behaviors which increase the security posture of a network, but are not yet required (or in some cases, my never be required). Because guidelines are not mandatory and may be ambiguous, practices cannot be audited against guidelines. Guidelines are sometimes written by a group that does not have the authority to require them to be followed. Guidelines are inappropriate to describe practices that are mandatory.

1672 1673

Because the policies, standards and procedures for different parts of an organization are often different, it is important that they be adequately coordinated. Specifically, the security

Least Privilege

Defens e in Depth

Threat-Risk Assessment

Policies and Procedures General

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA-62443-1-1, D5E4, August 2015

– 44 –

ISA99, WG03

1674 1675 1676

policy for IACS must be coordinated with similar policies for general purpose IT security. The security program will work more successfully if there are good working relationships among the parties, and a well-coordinated set of policies can support good relationships.

1677 1678 1679 1680 1681 1682 1683

Some consistency to the structure of the various policies, standards and procedures increases the coherence of the overall set of policies and procedures. Each policy or procedure document has a short but precise statement of its purpose. It also has a statement of scope that defines where the document applies. It has a description of the risks that it is intended to reduce and of the key principles of the document. These common items guide the reader by providing more information about the intention of the policy or procedure. They also describe the intent of the document to provide guidance, which is useful when the document needs to

1684

be revised.

1685 1686 1687 1688 1689

Different phases in a system’s life cycle have different profiles of security issues. Security policies and procedures may address only certain life cycle phases. Some policies and procedures may specify that they only pertain to certain phases. All of the security concerns from all of the various phases are addressed in corresponding places in the set of security policies and procedures.

1690 1691 1692 1693 1694 1695 1696

Security policies, standards and procedures contain instructions on how the organization will measure compliance and update the policies. Organizations often recognize that policies need to be updated when performing or evaluating audits. Audits may identify ambiguities in policies and procedures as well as parts of policies and procedures that do not make the required process or outcome clear. Audits can identify issues that should be added to policies and procedures. Audits may also identify requirements that should be reevaluated and adjusted or possibly retracted.

1697 1698 1699

Policies, standards and procedures should allow for unforeseen circumstances that make it infeasible to follow them. Policies should also state how to document and approve exceptions to policies and procedures. Documenting approved exceptions leads to a clearer state of

1700

security than leaving imprecision and ambiguity in the policies and procedures.

1701 1702 1703 1704 1705 1706 1707 1708

In addition, organizations should be unambiguous about what is a requirement versus what is optional advice in a policy or standard. Precise use of words like “shall,” “must,” “may,” and “is” removes the ambiguity. Policy statements can define these words in their introduction sections to be more precise. “Shall” and “must” are used for requirements. “May” is used for advice that is optional, and therefore is not used in the mainstream of policies and procedures. It can be appropriate to provide options for addressing a requirement. Phrases like “when possible” or “unless necessary” introduce ambig uity unless the statement also describes how to determine whether the case is possible or necessary.

1709 1710 1711 1712 1713

Policies, standards and procedures identify who is resp onsible for what. Is the process control staff responsible for the control network? Is it responsible for a “demilitarized zone” (DMZ) between the control network and the enterprise network? If an enterprise information systems department is responsible for conditions that require the process control staff to perform certain operations, then these operations should be described.

1714 1715

For an organization that is just starting to create its security program, policies and standards are a good place to begin. Initially, they can be written to cover the set of security practices

1716 1717 1718

that tightened the organization is equipped tocapability handle ingrows. the near Over they without can bethe revised and as the organization's Theyterm. can be puttime in place lead time of procuring and installing systems and devices.

1719

10.6.2

1720 1721

The policy at the enterprise level mandates the security program and sets the direction. It states the organization's overall security objectives.

1722 1723 1724 1725

The policy statement of top management should be circumspect enough to remain pertinent and accurate through changes in the structure of the organization, changes in system and security technology, and changes in the kinds of security threats. By being circumspect, the policy can be stable and will need to be rewritten only when the organization's basic position

Enter prise Level

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA99, WG03

– 45 –

ISA-62443-1-1, D5E4, August 2015

1726 1727

on security changes. However, the policy statement is also unambiguous; it clearly identifies what is required.

1728 1729 1730 1731 1732 1733

The enterprise level policy identifies areas of responsibility and assigns accountability for those areas. The policy can define the relationship between the enterprise IT department and plant operations and identify their different responsibilities. The policy can differentiate security objectives of the control system from those of the enterprise network. For example, maintaining confidentiality may be a top consideration of security for the enterprise network, whereas maintaining continuous operation may be a top consideration for the control system.

1734

In addition, the policy identifies particular standards and regulations that apply to the

1735 1736

organization. It may identify training as an important component of the security program. The policy may also indicate the consequences for policy violations.

1737 1738

Management should communicate the policy throughout the organization so that all employees understand it.

1739

10.6.3

1740 1741 1742 1743 1744

Operational policies, standards and procedures are developed at lower levels of the organization to specify how the enterprise level policy is implemented in a specific set of circumstances. Security standards and procedures put the policy into effect. They define what the organization will do to achieve the objectives and to meet the requirements of the policy. The procedures establish processes that will address all the concerns of the policy.

1745 1746

The standards and procedures address all components needed in a security program, including:

Operat ional Level

1747

a) system design

1748

b) procurement

1749 1750

c) installation d) process operation

1751

e) system maintenance

1752

f)

1753

g) audit

1754

personnel

h) training

1755 1756

The standards and procedures identify specific activities, who is accountable for their performance, and when activities will be performed.

1757 1758 1759

The written procedures describe the process by which they will be changed when the situation changes. Each policy, standard or procedure has an identified owner responsible for recognizing when updates are needed and for ensuring they are made.

1760 1761 1762 1763 1764 1765

The effectiveness of policies, standards and procedures should be measured to check whether they serve their intended purpose. The cost to the organization should also be measured, so the organization can determine whether the balance of risk redu ction aligns with the cost to implement the policies. If the balance is unacceptable, the policy and procedures may have to be adjusted. Procedures also have to be updated to reflect changes in technology.

1766 1767

Procedures are able to support audits. A security audit compares the observed actions of the organization against the written procedures.

1768

10.7

1769 1770 1771

There are several topics that policies and procedures can cover. Every organization is different and should determine the appropriate policies and procedures that are applicable for its industrial automation and control systems. Possible topics include:

Topics Covered by Policies and Procedures

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA-62443-1-1, D5E4, August 2015

– 46 –

ISA99, WG03

1772 1773 1774 1775 1776 1777 1778 1779

Risk Management – Risk management is vital to developing a cost-effective security program that provides a uniform layer of adequate security, but that does not require equipment or procedures that are too costly and significantly beyond the range of adequate security. However, risk management is complex and needs to be tailored to the organization. The policy on risk management defines how an acceptable level of risk is determined and how to control the risk. This level varies depending upon the goals and circumstances for a particular organization. The process for determining risk level should be repeated periodically in order to accommodate changes to the environment.

1780 1781

Access Manag em ent – Security is improved in a system by restricting access to only those users who need and are trusted with the access. Access management policy identifies

1782 1783 1784 1785 1786 1787

different roles of users and what kind of access each role needs to each class of asset (physical or logical). It specifies the responsibilities of employees to protect the assets and of administrators to maintain access management procedures. Authorization for these access privileges should have well-documented approval by management and be periodically reviewed. Access management may be as important or even more important to system integrity and availability as the need to protect data confidentiality.

1788 1789 1790 1791

Av ail ab ili ty and Co ntinu it y Pl ann ing – Policies in this area provide the necessary framework and requirements expectations for backup and recovery, as well as business continuity and disaster recovery planning. They also define archiving characteristics (e.g., how long must data be retained).

1792 1793 1794 1795 1796 1797 1798

Physical Security – The security of the control system depends upon the physical security of the space that contains the control system. The plant site may already have a physical security policy before the security policy is written for the control system. However, policies related to systems’ physical access may differ from those involving non -systems assets. For instance, all oil refinery personnel may have general access to almost all facilities within the plant fences, but IT infrastructure rooms may need to have access limited to only IT-related personnel – if for no other reason than to prevent accidental damage. The control system

1799 1800 1801 1802 1803

security policy should include a reference to the physical security policy and state its dependency. The security policy for the control system must contain enough specifics on physical security to make any specific application of the site physical security policy to the control system. For example, some equipment must be in locked cabinets, and the keys must be kept in a restricted place.

1804 1805

Arch itect ure – Policies and procedures describe secure configurations of control systems including such issues as:

1806

a) recommended network designs

1807

b) recommended firewall configuration

1808

c) user authorization and authentication

1809

d) interconnecting different process control networks

1810

e) use of wireless communications

1811

f)

1812

g) patch management (including authentication)

1813 1814 1815

h) anti-virus management i) system hardening in terms of closing softwa re ports, disabling or avoiding unused or dangerous services, and disabling the use of removable storage devices

1816

j)

1817

k) appropriate use of e-mail.

1818 1819 1820 1821 1822

domains and trust relationships

acc ess to exter nal netwo rks (i. e., the inter net)

Portable Devices – Portable devices pose all the security risks of stationary equipment, but their mobility makes it less likely that they will be covered by the normal security procedures from installation to audit. Their portability provides additional opportu nities for corruption while outside physical security zones or for interception of information while connecting to secure zones. Thus, a special policy is often needed to cover portable devices. The policy should

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA99, WG03

– 47 –

ISA-62443-1-1, D5E4, August 2015

1823 1824

require the same security protection as a stationary device, but the technical and administrative mechanisms that provide this protection may differ.

1825 1826 1827 1828 1829 1830 1831 1832

Wireless Devices and Sensors – Control equipment using radio frequency transmission in place of wires has been widely used in certain control system applications for many years. As costs decrease and new standards emerge, potential applications in automation and control systems continue to expand, in part due to lower installation costs. A key difference between wired and wireless devices is that in the latter case signals are not confined within a physical security boundary, making them more prone to interception and corruption. Therefore, a security policy specific to wireless devices is appropriate for organizations that currently use or may in the future deploy wireless devices or sensors in their operations. The policy may

1833 1834

specify which applications can use wireless devices, what protection and administrative methods are required, and how wired and wireless networks are interconnected.

1835 1836 1837 1838 1839

Remote Access – Remote access bypasses the local physical security controls of the boundaries of the system. It extends access to the trusted zone to a completely different geographic location and includes a computer that may not have undergone the security checks of the computers that are physically in the area of the trusted zone. Different mechanisms are required to provide the same level of security as the trusted zone.

1840 1841 1842 1843 1844

Personnel – Personnel issues are likely to be defined in the enterprise personnel and IT security policies. The control system security policy provides specifics, whereas the more general policies do not include control system aspects. For example, the control system security policies coordinate control system access roles with personnel screening and monitoring practices.

1845 1846 1847 1848

Subcontractor Policy – Security issues include work that may involve subcontractors in roles such as supplier, integrator, maintenance service provider, or consultant. A security policy that covers subcontractors addresses the interactions with the subcontractor that could open vulnerabilities. The policy identifies the responsibilities of the different parties. It addresses

1849 1850 1851

the changing responsibilities as projects progress through their phases and as materials and systems are delivered. The policy may require certain terms to be written into contracts with subcontractors.

1852 1853 1854 1855

Without proper management of contract programmers, application integrity may be compromised or programming code may not be maintainable. It is important to find wellqualified contract programmers who will follow your programming and documentation standards and perform adequate testing, as well as being trustworthy and timely.

1856 1857 1858 1859 1860

Audi tin g – The security of the system is audited regularly to measure the degree of compliance with the security policies and practices. The security policy addresses the need for audits and specifies the responsibility, the regularity, and the requirement for corrective action. A comprehensive auditing process may address aspects other than security, such as process efficiency and effectiveness, and regulatory compliance.

1861 1862 1863 1864

Security Policy Updating – The security policy is monitored to determine changes needed in the policies themselves. Monitoring security policy is a part of each policy and procedure document, and the enterprise security policy sets forth the overall approach. Each operational policy and procedure document contains a statement of when and by whom the policy or

1865

procedure itself is to be reviewed and updated.

1866 1867 1868

Training – Training programs should be in place for new hires, operations, maintenance, upgrades and succession planning. Training programs should be well documented, structured, and updated at regular intervals to incorporate changes in the operating environment.

1869

10.8

1870

10.8.1

1871 1872 1873 1874

Understanding key management first requires a n insight into the life cycle for the keys that are part of a key management schema. Fundamentally, a key is a piece of auxiliary information that changes the detailed operation of an encryption algorithm. A key should be selected before using an encryption algorithm to encrypt an IACS message or piece of information.

Key Management Introduction

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA-62443-1-1, D5E4, August 2015

– 48 –

ISA99, WG03

1875 1876

Without knowledge of the key, it should be difficult, if not impossible, to decrypt the resulting ciphertext into human or machine readable plaintext.

1877 1878 1879 1880 1881

A lif e cycle ma y begin wit h a cr ypt ope ri od for the ke ys which des cribes the lif e st age s (k ey states) from creation to revocation and disposal. IACS operations run 24/7 which depends on continuous availability of critical communication resources. For this reason, special attention needs to be given to the requirements for timely disposition of keys described by the system triggers shown in Figure 9.

1882

1883 1884

Figure 9 – Key management life cycle

1885

10.8.2

1886 1887 1888 1889 1890 1891 1892 1893 1894 1895

Generation and distribution of keys that maintain the secret value afforded the key is prov in a timely manner to support 24/7 P&C operations. A key management schema or system is only effective if something (usually the key but could be an encryption algorithm) is secret. How to maintain the secret across widely geographically dispersed IACS operational entities and unknown entities becomes the challenge for a key management design. So, generating a key for which that key may have a wide breath of use or a very narrow use leads to defining an effective distribution channel. The channel can be a physical channel such as a courier or equivalent, the channel can be an electronic channel such as the Internet which should not be trusted. The means used to distribute the keys is largely determined by the timeliness requirements imposed by critical IACS operations that require high security.

Generation and distribution of keys

1896 1897

Except in simple IACS operations where key components remain fixed for all time, cryptoperiods are needed for keys, and these keys need to be updated periodically. The time

ided

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA99, WG03

– 49 –

ISA-62443-1-1, D5E4, August 2015

1898 1899

frame for a key to be used varies. The cryptoperiod of a key is the time period during which the key is valid for use by legitimate human and non-human entities. Cryptoperiods serve to:

1900

–

Limit t he information (related to a specifi c key) available for cryptanalysis ;

1901

–

Limit e xposure in the case of compromise of a single key ;

1902

–

Limit t he use of a particular technology to its estimated effectiv e lifeti me; and

1903 1904

– Limit the time available for computationally intensive cryptanalytic applications where long-term key protection is not required).

1905

10.8.3

1906 1907 1908 1909 1910 1911

IACS operation requires secure management of the keying material in all key state phases shown in Figure 9: pre-operational, operational, post-operational, and destruction. Furthermore, the key management s ystem should provide a secure method to account for how the keys are maintained. Backup key management and key recovery becomes extremely important to maintain 24/7 operations when the primary key management system fails or is disconnected.

1912

11 Fundamental Concepts

1913 1914

There are several fundamental concepts that are essential to the formulation and execution of an Industrial Automation and Control Systems security program.

attacks (in IACS

Key Stat e Phas es

1915 1916 1917 1918

k) Security Life Cycle – This life cycle is focused on the security level of a portion of the system over time. A change to a physical asset may trigger a set of security level activities, or a change in security vulnerabilities or an asset may trigger a change in the physical asset.

1919 1920

l)

1921 1922

Security Program Maturity – A mature security program integrates all aspects of cyber security, incorporating desktop and business computing systems with industrial automation andand control systems. The development of a program shall recognize that there are steps milestones in achieving this maturity

1923 1924 1925

m) Zone and Conduits – Segmenting or dividing a system under consideration for the purpose of assigning security levels and associated measures is an essential step in the development of the program.

1926 1927

n) Security Levels – Assets that make up the system under consideration shall be assigned desired security levels using the mechanism defined in ISA ‑ 62443-3-2.

1928 1929

o) Foundational Requirements – The full scope of detailed technical and program requirements shall be derived from a small set of foundational requirements.

1930 1931 1932

p) Safety and Security – In an IACS context the subjects of Security and Safety are closely linked. A failure to secure an IACS can in turn result in a potentially unsafe System under Control.

1933 1934

Each of these concepts is introduced in subsequent clauses and addressed in more detail in one or more standards in the ISA ‑ 62443 series.

1935

11.1

1936

11.1.1

1937 1938 1939 1940

This section explains the different security aspects in the relevant life cycles of an IACS and outlines which parts of the ISA ‑ 62443 series provide guidance for the security aspects of the respective life cycle. The entities of these relevant life cycles and the respective main responsible role are shown in table 2.

Security Life Cycle Introduction

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA-62443-1-1, D5E4, August 2015 1941

1942 1943 1944 1945 1946

– 50 –

ISA99, WG03

Table 2 – Entities with relevant life cycles and the respective main responsible role Entity

Responsible role

Product used in the IACS

Product Supplier

Project integrating various products into a solution

System Integrator

Solution as operated, maintained and eventually decommissioned

Asset Owner

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

For each entity and the associated life cycle, the security aspects are defined and implemented in a security process model, often referred to as the Plan-Do-Check-Act (PDCA) cycle. For each of these PDCA cycles, a different role is mainly responsible to ensure that all the cyber security aspects are properly addressed. These PDCA cycles are shown in Error! Reference source not found..

1947 1948

Figure 10 – Security aspects in relevant life cycles

1949 1950 1951 1952

As als o shown in Error ! Ref erenc e source not fo un d., the re are a num ber interdependencies between these PDCA cycles. While Error! Reference source not found. shows a role centric view on the security aspects in IACS environments, Error! Reference source not found. shows a life cycle centric view.

1953 1954 1955 1956 1957 1958 1959 1960

The product life cycle must address the security aspects of the product. Product development is usually done independent of any specific project – instead products are developed for a perceived market. Therefore the product PDCA cycle is fairly decoupled from the others. However, past and current project requirements and feedback from the installed base are a source for market requirements. After a product is released into the market, it needs to be maintained. At the same time, the product PDCA cycle needs to continuously support projects and the installed base throughout the life cycle of the product with product security documentation and operational guidelines. Eventually the product will be taken off the market.

1961 1962 1963 1964

The IACS life cycle addresses the security aspects of the project in which an automation solution is designed and commissioned as well as the continuous operation and maintenance of the solution and its eventual decommissioning. Integration projects are dependent on information from the various product suppliers feeding into the project and in return provide

of

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA99, WG03

– 51 –

ISA-62443-1-1, D5E4, August 2015

1965 1966 1967 1968 1969 1970

requirements and feedback for consideration in future updates and new products. At the same time, based on the project requirements and in particular the security targets specified by the asset owner, the design of the automation solution done in the integration project largely determines how the IACS will be operated. Therefore the integration project’s PDCA cycle must supply appropriate information in particular the solution security documentation to the operations PDCA cycle.

1971 1972 1973 1974

Asset owner s’ operations team s pro vid e requ irem ent s bot h to int egr atio n proj ect s as wel l as to product suppliers. In return they depend on initial documentation and continuous support throughout the solution’s lifecycle. Hence it is obvious that the life cycle of the integration project and the operations are tightly intertwined. In fact, usually the integration project

1975

activity is not started unless the eventual asset owner issued a request for bids.

1976 1977

Figure 11 – Interdependencies in product and IACS lifecycles

1978 1979 1980

The following subsections provide more detail on the PDCA cycles shown in Error! Reference source not found. and the corresponding security aspects and explain how the different parts of the ISA ‑ 62443 series correlate to them.

1981

11.1.2

1982 1983 1984 1985 1986 1987 1988 1989 1990 1991 1992 1993 1994

Alth oug h som e products are sp eci fi call y developed for a gi ven proje ct , in general the aim of the product supplier is to offer components and systems with a reasonable level of confidence that they are free from vulnerabilities and meet the required security requirements of their intended target markets. It is recommended to conduct several PDCA cycles during the product development cycle. The first cycle should take place in the specification phase and should be focused on the expected threats coming from the operating environment of the product. In the design phase PDCA cycles should be applied to product architecture and data flow aspects. During commercialization and maintenance the product supplier has to take care of vulnerability handling and to issue security patches and updates as necessary. Finally in the phase out early announcement of the termination of support and security updates is important. Beside the security relevant technical documentation the product supplier should also document the security recommendations for integration and operation of the product as well as the description of the continuous support during the whole life cycle.

1995 1996 1997

On one side the product supplier’s organization should establish a product development process ensuring that all measures to avoid the creation of vulnerabilities are addressed. In ISA ‑ 62443-4-1 the product supplier will find process requirements which help him to

Produ ct life cycle

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA-62443-1-1, D5E4, August 2015

– 52 –

ISA99, WG03

1998 1999 2000 2001 2002 2003 2004 2005 2006 2007

systematically address the security issues from specification phase throughout design, implementation, verification and validation and release until phase out. The purpose of this part is to improve the quality of product development process and to include security specific measures in the organizational as well in the technical area. On the other side ISA ‑ 62443-3-3 and ISA ‑ 62443-4-2 specify security capabilities which should be fulfilled by the control system or components of the control system to support a defense in depth strategy when deploying an automation solution. A product supplier may choose to integrate a given set of functionalities depending on the security level expected in the target industries of the product. To achieve the required security level of the automation solution additional compensating countermeasures may be necessary.

2008 2009 2010

‑ TR62443-2-3 for the patch management In addition product suppliers should consider ISA process. ISA ‑ TR62443-3-1 provides assessments of current cyber security tools, mitigation counter-measures, and technologies that may be applied to products and solutions.

2011

11.1.3

2012

11.1.3.1

2013 2014 2015 2016 2017 2018 2019 2020

Usually the functional and design specification is a first phase of a new project. In some cases the specification uses some material from previous projects that might be applicable or reusable, e.g. a set of user needs. Based on that, the asset owner then begins work on identifying the relevant security targets and the corresponding risks. This part is also known as a high level risk assessment. Hence the risk identification as part of the overall system specification takes into account lessons learned, existing checklists and brainstorming to identify known or new risks. Furthermore it includes also the determination of the currently assumed likelihood of risk occurring and impact.

2021 2022 2023

The asset owner describes the security related requirements for the construction and operation of the plant (target security level, SL ‑ T) in the form of the tender requirements specification of the potential integrators The asset owner also describes which strategic or

2024 2025 2026 2027 2028 2029 2030 2031

company internal requirements have to be considered (e.g., security policies, physical constrains) during the overall project. System integrators responding to the tender create the functional specifications of the automation solution as part of their offer based on the tender specification and mainly the external technical documentation of all the eligible solutions/ components from one or more product suppliers. The asset owner has to check this functional specification to ensure, that all requirements will be addressed by the automation solution. If the functional specification is accepted by the asset owner, a contract will be negotiated and the collaborative project will be started.

2032 2033 2034 2035 2036 2037

ISA ‑ 62443-2-1 defines the requirements for an industrial automation and control system (IACS) security management system (IACS -SMS) and provides guidance on how to develop it. Specifically for the patch management aspect of an IACS-SMS, ISA ‑ TR62443-2-3 provides detailed guidance. Finally, ISA ‑ 62443-3-2 establishes requirements for defining the zones and conduits of the system under consideration, assessing risk, establishing a target security level (SL-T), providing informal guidance on how to verify these requirements.

2038

11.1.3.2

2039 2040 2041 2042

The integration and commissioning phase is an iterative process of the system integrator, mainly used for designing and implementing the appropriate secure automation solution requested by the asset owner (and its security targets). The solution of the system integrator is characterized by:

IACS Life Cycl e Specification Phase

Integration and Commissioning Phase

2043

–

using the zone and conduit model to design a secure auto mation infrastructure,

2044 2045 2046

–

selecting and integ rating products from the product suppli er( s) according their security capabilities (taking into account the product security documentation/ guidelines/ support),

2047 2048

– configuration and parameterization dedicated security capabilities),

2049 2050

–

of all products

(not limited to

products with

providing evidence during the commissioning, and in the final application of the asset owner, that the final integrated solution fulfils all requirements appropriately,

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA99, WG03 2051 2052

– 53 –

ISA-62443-1-1, D5E4, August 2015

– supporting the final integrated solution along the asset owners life cycle (operation, maintenance, decommissioning),

2053 2054 2055

In the end of the integration and commissioning phase the system integrator must ensure that all the measures implemented for the achieved Security Level (SL-A) are efficient, suitable and match the target Security Level (SL-T).

2056 2057

As par t of the re su lt of the project th e system int egr ator shou ld provide th e ass et owner with external technical documentation and support such that the asset owner will then:

2058 2059

–

be able to operate, maintain and decommission the automation solution its specification,

2060 2061

–

be able to find all IT security-relevant information necessary solution,

2062 2063

– be able to regularly check the implemented countermeasures and

2064

–

be able to adapt the implemented countermeasures when the

securely wit hin

for future cha nges of the for their effectiveness, threat situation changes

2065 2066 2067

Furthermore the documentation should also provide information concerning the operating and maintenance of the overall automation solution which is also a basis for the training the asset owners personnel.

2068 2069 2070 2071 2072 2073 2074

ISA ‑ 62443-2-4 specifies capabilities for IACS Solution Suppliers, especially system integration service providers. ISA ‑ 62443-3-2 provides requirements how to determine the achieved security level (SL-A) of the overall solution and to validate that it matches the previously defined security target level (SL-T). ISA ‑ 62443-1-3 defines system cyber security conformance metrics for an industrial automation and control system (IACS). Finally, ISA ‑ TR62443-3-1 provides an overview of security technologies and their appropriate use in IACS environments.

2075 2076 2077 2078 2079

11.1.3.3 Operations & Maintenance Phase It is one of his major responsibilities of the owner or operator of an IACS to ensure during the operation and maintenance phase the security capabilities of the IACS will be kept on the achieved and approved security levels in all of its zones and conduits. He has to keep the risk of security breaches and associated consequences a t an acceptable level.

2080 2081

In general the security properties of each IACS will change over time due to the following changes in the primary or in itial security milieu. Those changes can be the following:

2082 2083

–

The confidence in the security capabilities discovered vulnerabilities.

of the ICAS components is reduced due to

2084 2085

–

The security requirements of t he IACS are changed e.g. due to changes of the threat situation.

2086 2087

–

Technical, organizational and/o r operational changes i mpa cting the secure operation of the IACS.

2088 2089

The security properties relevant to the IACS must be audited and/or tested at regular intervals or whenever a new vulnerability is discovered to ensure that SL(Achieved) matches

2090 2091 2092

SL(Target). The product supplier and the system integrator have to inform the asset owner or operator whenever they have discovered any change in the security capabilities of their products or systems leading to a de gradation of their associated security capabilities.

2093 2094 2095 2096 2097 2098 2099 2100

The central document in the standardization series ISA ‑ 62443 describing the process of operating and maintaining the achieved security capabilities is the part ISA ‑ 62443-2-1: Industrial automation and control system security management system. That document describes among other topics also the maintenance and improvement steps of a cyber security management system (CSMS) following the outline of the ISO standard 27001 and 27002. The asset owner should continuously monitor, review and audit the selected security controls and measures and their effectiveness. It should implement decided upon improvements and adjustments and communicate those actions to all involved parties.

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA-62443-1-1, D5E4, August 2015

– 54 –

ISA99, WG03

2101 2102 2103 2104 2105 2106 2107 2108

Further attention should be given the technical report on patch management (ISA ‑ TR62443-23), one of the important tasks to keep the level of security (SL achieved) of implemented SW applications to its srcinally implemented level. The asset owner should specifically monitor and assess maintenance provider’s development in respect to the defined maturity levels during his involvement with the IACS (see ISA ‑ 62443-2-4), possibly involving IACS service providers. Re-assessing previous risk assessments can have an impact on the design of the security zones and conduits (ISA ‑ 62443-3-2) and the choice of mitigation measures to meet ‑ 62443-3-3). the selected technical or organizational setup of an IACS the system (ISA

2109

11.1.3.4

2110 2111 2112 2113 2114 2115 2116 2117 2118 2119 2120 2121 2122 2123

When decommissioning an of automation solution enviro or parts thereof, there the is a risk owner’s of compromising the security the surrounding nment (e.g. asset organization) or the remaining automation solution. Decommissioning may range from discontinuing the entire automation solution (with or without replacement) to removal of individual assets (with or without replacement). The risk of security compromise stems from the potential disclosure of data or information which may be left on the assets in a format that may be useful for an attacker (e.g. encryption keys, authentication credentials, architecture information). It is the responsibility of the asset owner to ensure to an appropriate level that such information is removed or otherwise rendered useless during the decommissioning. To live up to this responsibility, the asset owner depends on documentation from the system integrator and the product suppliers on where such information may be located and how to properly remove it or render it unusable otherwise. ISA ‑ 62443-2-1 has requirements and guidance on security aspects of decommissioning such as disposal or reuse of information, media as well as equipment.

2124

11.2

2125 2126 2127

Driven by increasing cyber security risks, many organizations have taken a proactive approach towards addressing the security risks of their information technology systems and networks. They are beginning to realize that addressing cyber security is a continuous activity

2128

or process and not a project with an identified start and stop.

2129 2130 2131 2132 2133

Historically organizations providing and supporting business information systems and industrial automation and control systems operated in two mutually exclusive areas. The expertise and requirements of each organization were not understood or appreciated by the other. Issues arose as organizations tried to employ common IT security practice s to industrial automation and control systems.

2134 2135 2136 2137 2138 2139 2140 2141

In some cases, the security practices were in opposition to normal production practices designed to maximize safety and continuity of production. Because today’s open information technologies are used extensively in industrial automation and control systems, additional knowledge is required to safely employ these technologies. The IT and manufacturing or production organizations should work together and bring their knowledge and skills together to tackle security issues. In industries with a high potential for health, safety, and environmental incidents, it is important to involve Process Safety Management (PSM) and physical security personnel as well.

2142 2143

The goal is a “mature” security program that integrates all aspects of cyber security, incorporating desktop and business computing systems with industrial automation and control

2144 2145 2146

systems. Many organizations have fairly detailed and complete cyber security programs for their business computer systems, but cyber security management practices are not as fully developed for IACS.

2147 2148 2149 2150 2151

A com mo n mista ke is to add ress cyber secur it y as a proje ct wit h a start and end date. When this occurs, the security level often declines over time. Cyber security risks constantly change as new threats and vulnerabilities surface along with ever-changing technology implementations. A different approach is needed to sustain the security gains and hold risk to an acceptable level.

2152 2153 2154

The recommendation is to develop and implement an organization-wide cyber security management system (CSMS) that includes provisions to reassess risk and take corrective actions to eliminate the tendency for security levels to decline over time. An in-depth

Decommissioning Phase

Maturity Levels

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA99, WG03

– 55 –

ISA-62443-1-1, D5E4, August 2015

2155 2156

description of the key components of a cyber security management system is provided in the second standard in this series. [1]

2157 2158 2159 2160 2161 2162 2163 2164

Every organization’s journey to implement a cyber security management system will be different based on the organization’s objectives and tolerance for risk. Integrating cyber security into an organization’s standard practices is a cultural change that takes time and resources. As the figures suggest, it cannot be achieved in one step. It is an evolutionary process that standardizes on the approach to cyber security. The security practices to be implemented must be proportionate to the risk level and will vary from one organization to another, and may even be different for various operations within the same organization based on global needs and requirements. Individual policies and procedures may also be different

2165 2166 2167

for each class of system within an organization because the level of risk and security requirements may be different. A cyber security management system establishes the overall program that accommodates these differences.

2168 2169

Education and awareness are critical for successfully addressing IACS cyber security risks as noted above. There are several options to consider:

2170 2171

a) Training the IACS personnel to understand the current information technology and cyber security issues.

2172 2173

b) Training IT personnel to u nderstand IACS technologies, along Management processes and methods.

2174 2175

c) Developing practices that join the s security collaboratively.

2176 2177 2178

kill sets of all the organizations to d

eal with cyber

For the cyber security program to be successful, it is necessary to assemble the right mix of people on both the mitigation projects and the overall CSMS program development. Contributing groups include:

2179

– IT and Telecom support

2180

– IT security

2181

–

2182

– Operations and Maintenance

2183

– IACS Support

2184

with the Process Safety

Suppliers

– Process Safety

2185

11.2.1

2186 2187

It is possible to describe the relative maturity of a cyber security program in terms of a life cycle that consists of several phases. Each of these phases consists of one or more steps.

Matur ity Phase s

2188 2189 2190 2191 2192 2193

Portions of the industrial automation and control system, or control zones within a control system can be at different phases of maturity. There are several reasons for this situation, including budgetary constraints, vulnerability and threat assessments, schedules placed against risk analysis results, automation upgrades, plans for dissolution or replacement, plans to sell a segment of the facility or business, or availability of other resources to upgrade the security systems to a more mature phase.

2194 2195 2196

Organizations can achieve a more detailed evaluation of security maturity by assessing achievements within portions of the industrial automation and control system in terms of the phases and steps shown in the following table.

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA-62443-1-1, D5E4, August 2015 2197

– 56 –

ISA99, WG03

Table 3 – Security Maturity Phases Phase

Concept

Step

Identification Concept

Functional Analysis

Definition

Implementation

Functional Design Detailed Design Construction

Operations

Operations Compliance Monitoring

Recycle and Disposal

Disposal Dissolution

2198 2199

The tables that follow provide general descriptions for each of the phases and steps in the maturity life cycle.

2200

Table 4 – Concept Phase Step

Identification

Concept

Description



Recognize need for protection of property, assets, services, or personnel



Start developing the security program



Continue developing the security program



Document assets, services, and personnel needing some level of protection

 Document enterprise potential internal and external threats to the

2201



Establish security mission, visions, and values



Develop security policies for industrial automation and control systems and equipment, information systems and personnel

Table 5 – Functional Analysis Phase Step

Definition

Description



Continue developing the security program



Establish security functional requirements for industrial automation and control systems and equipment, production systems , information systems, and personnel



Perform vulnerability assessment of facilities and associated services against the list of potential threats



Discover and determine legal requirements for industrial automation and control systems



Perform a risk analysis of potential vulnerabilities and threats



Categorize risks, potential impacts to the enterprise, and



potential mitigations Segment security work into controllable tasks and modules for development of functional designs



Establish network functional definitions for security portions of industrial automation and control systems

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA99, WG03

– 57 –

2202

ISA-62443-1-1, D5E4, August 2015

Table 6 – Implementation Phase Step

Functional Design

Description



Development of the security program is completed in this phase



Define functional security requirements for enterprise zones, plant zones, and control zones. Potential activities and events are defined and documented to perform the functional requirements and implement plans for a secured enterprise.



Define functional security organization and structure



Define functions required in the implementation plan



Define portals and publish security zones, borders, and access control Complete and issue security policies, and procedures

 Detailed Design

Construction



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



Conduct training programs



The implementation plan is fully developed



Initiate asset management and change management programs



Design borders and access control portals for protected zones



Implementation plan is executed. Physical security equipment, logical applications, configurations, personnel procedures are installed to complete the secured zones and borders within the enterprise.



Access control portal attributes are activated and maintained



Training programs are completed



Asset management and change management programs are functional and operating



Security system turnover packages are completed and ready for acceptance by operations and maintenance personnel

2203

Table 7 – Operations Phase Step

Operations

Compliance Monitoring

2204

Description



Security equipment, services, applications and configurations are completed and accepted by operations and maintenance



Personnel are trained, and continued training is provided on security matters



Maintenance monitors security portions of enterprise, plant, or control zones and keeps them functioning properly



Asset management and change management is operational and maintained

 Internal audits  Risk reviews  External audits

Table 8 – Recycle and Disposal Phase Step

Disposal

Description



Obsolete security systems are properly disassembled and disposed of



Security borders are updated or recreated for zone protection



Access control portals are created, redefined, reconfigured, or closed



Personnel are briefed about changes in the security systems and items along with the impact to associated security sys tems

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA-62443-1-1, D5E4, August 2015 Dissolution

– 58 –

ISA99, WG03



Intellectual property is properly collected, documented, and securely archived or destroyed



Access control portals and respective links are closed



Personnel are briefed about dissolution of the security systems and items along with the impact to remaining security system s

2205 2206

11.3

2207

11.3.1

Zones and Conduits

2208 2209 2210 2211 2212 2213

Every situation has a different acceptable level of security. For large or complex systems it may not be practical or necessary to apply the same level of security to all components. Differences can be addressed by using the concept of a security zone, defined as a logical or physical grouping of physical, informational, and application assets sharing common security requirements. This concept can be applied in an exclusive manner where some systems are included in the security zone and all others are outside the zone.

2214 2215 2216

A cond uit is a part icu la r typ e of sec urity zon e that groups comm uni cati ons that can be logically organized into a grouping of information flows within and also external to a zone. Channels are the specific communication links established within a communication conduit.

2217

11.3.2

2218 2219 2220 2221 2222

A security zon e has a border, whi ch is the boundary between inc luded and excluded components. The concept of a zone also implies the need to access the assets in a zone from both within and without. This defines the communication and access required to allow information and people to move within and between the security zones. Zones may be considered to be trusted or untrusted.

2223

Security zones can be defined in physical terms (i.e., a physical zone), in logical terms (i.e.,

2224 2225 2226 2227 2228

virtual zone), or in some combination. Physical zones are defined by grouping assets by physical location. In this type of zone it is easy to determine which assets are within each zone. Virtual zones are defined by grouping assets, or parts of physical assets, into security zones based on functionality or other characteristics, rather than the actual location of the assets.

2229 2230 2231

There can also be zones within zones that provide layered security, giving defense in depth and addressing multiple levels of security requirements. Defense in depth can also be accomplished by assigning different properties to security zones.

2232

11.3.2.1

2233



2234

11.3.2.2

2235



2236

11.3.3

2237

Information must flow into, out of, and within a security zone. Even in a non-networked

2238 2239 2240 2241

system, some communication exists (e.g., intermittent connection of programming devices to create and maintain the systems). To cover the security aspects of communication and to provide a construct to encompass the unique requirements of communications, this standard is defining a special type of security zone: a communications conduit.

2242 2243 2244 2245

A co nduit can be a si ng le ser vic e (i .e., a sin gle Ethern et network ) or can be ma de up of multiple data carriers (multiple network cables and direct physical accesses). As with zones, it can be made of both physical and logical constructs. Conduits may connect entities within a zone or may connect different zones.

2246 2247 2248

As with zones , co ndu its ma y be either trust ed or untrusted. Conduit s th a t do not cross zon e boundaries are typically trusted by the communicating processes within the zone. Trusted conduits crossing zone boundaries must use an end-to-end secure process.

Introduction

Zones

Requirement

Rationale

Conduits

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA99, WG03

– 59 –

ISA-62443-1-1, D5E4, August 2015

2249 2250 2251

Untrusted conduits are those that are not at the same level of security as the zone endpoint. In this case the security of the communication becomes the responsibility of the individual channel. Further information on this scenario is available in the Annex.

2252

11.3.3.1

2253



2254

11.3.3.2

2255



2256 2257 2258 2259

11.3.4 Channels Channels inherit the security properties of the conduit used as the communication media (i.e., a channel within a secured conduit will maintain the security level of the secured conduit). Channels may be trusted or untrusted.

2260 2261 2262

Trusted channels are communication links that allow secure communication with other security zones. A trusted channel can be used to extend a virtual security zone to include entities outside the physical security zone.

2263 2264 2265 2266

Untrusted channels are communication paths that are not at the same level of security as the security zone under study. The communications to and from the reference zone (the zone that defines the communication as non-secure) must be validated before accepting the information.

2267

11.3.5

2268 2269 2270

When organizing a system into zones and conduits an organization must first assess the security requirements (security goals) and then determine the positioning of asset within the zone structure. The security requirements can be broken down into the following types:

2271 2272 2273 2274

Communications Access – For a group of assets within a security border to provide value, there must be links to assets outside the security zone. This access can be in many forms, including physical movement of assets (products) and people (employees and vendors) or electronic communication with entities outside the security zone.

2275 2276 2277 2278

Remote communication is the transfer of information to and from entities that are not in proximity to each other. For purposes of this document, remote access is defined as communication with assets that are outside the perimeter of the security zone being addressed.

2279 2280

Local access is usually considered communication between assets within a single security zone.

2281 2282 2283 2284 2285 2286

Physical Access and Proximity – Physical security zones are used to limit access to a particular area because all the systems in that area require the same level of trust of their human operators, maintainers, and developers. This does not preclude having a higher-level physical security zone embedded within a lower-level physical security zone or a higher-level communication access zone within a lower-level physical security zone. For physical zones, locks on doors or other physical means protect against unauthorized access. The boundary is

2287 2288

the wall or cabinet that restricts access. Physical zones should have physical boundaries commensurate with the level of security desired, and aligned with other asset security plans.

2289 2290 2291

One example of a physical security zone is a typical manufacturing plant. Authorized people are allowed into the plant by an authorizing agent (security guard or ID), and unauthorized people are restricted from entering by the same authorizing agent and by fences.

2292 2293 2294 2295

Assets that are withi n the secur it y bor der are thos e th at mu st be protected to a gi ven securi ty level, or policy. All devices that are within the border must share the same minimum level of security requirements. In other terms, they must be protected to meet the same security policy. Protection mechanisms can differ depending on the asset being protected.

Requirement

Rationale

Determining Requirements

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA-62443-1-1, D5E4, August 2015

– 60 –

ISA99, WG03

2296 2297 2298

Assets that are outside the security zon e are by defi nition at a les ser or dif fer ent sec urit y level. They are not protected to the same security level, and by definition cannot be trusted to the same security level or policy.

2299

11.3.5.1

2300



2301

11.3.5.2

2302



2303 2304 2305 2306 2307 2308

11.3.6 Defini ng Zone s In building a security program, zones are one of the most important tools for program success, and proper definition of the zones is the most important aspect of the process. When defining the zones, organizations must be sure to use both the reference architecture and the asset model to develop the proper security zones and security levels to meet the security goals established in the industrial automation and control systems security policy.

2309 2310 2311 2312 2313 2314 2315 2316

When different level activities are performed within one physical device, an organization can either map the physical device to the more stringent security requirements, or create a separate zone with a separate zone security policy that is a blended policy between the two zones. A typical example of this occurs in process historian servers. To be effective, the server needs access to the critical control devices that are the source of the data to be collected. However, to meet the business need of presenting that data to supervisors and process optimization teams, a more liberal access to the device is required than typical control system security requirements allow.

2317 2318 2319

If multiple applications involving different levels of activities are running on a single physical device, a logical zone boundary can also be created. In this case, access to a particular application is restricted to persons having privileges for that level of application. An example

2320 2321 2322

is a single machine running an OPC server and OPC client-based analysis tools. Access to the OPC server is restricted to persons having higher level privileges while access to spreadsheets using OPC client plug-in is available to all employees.

2323

11.3.6.1

2324



2325

11.3.6.2

2326



2327

11.3.7

2328 2329 2330 2331

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

2332

11.3.7.1

2333 2334

Each zone has a set of characteristics and security requirements that are its attributes. These take the form of:

Requirement

Rationale

Requirement

Rationale

Zone Ident ificat ion

Zone Characteristics

2335

a) Security attributes (security policie s and security levels)

2336

b) Asset Inventory

2337

c) Access Requirements and Controls

2338

d) Threats and Vulnerabilities

2339

e) Consequences of a Security Breach

2340

f)

2341

g) Change Management Process.

Authorized Technology

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA99, WG03

– 61 –

ISA-62443-1-1, D5E4, August 2015

2342

Each of these attributes is described in more detail in the following paragraphs.

2343

11.3.7.1.1

2344 2345

Each zone has a controlling document that describes the overall security goals and how to ensure the Target Security Level is met. This includes:

Security Attributes

2346

a) the zone scope

2347

b) the zone security level (Target security levels, SL- T)

2348

c) the organizational structure and responsibilities

2349 2350

d) the risks associated with the zone e) the security strategy to meet the required goals

2351

f)

2352

g) the types of activities that are pe rmitted within the zone

2353

h) the types of communication allowed

2354

i)

to enforce the security policy

the security policies to be enforced

access to the zone

documentation of the zone attributes.

2355 2356

Al l of the above are docu me nte d and com bin ed into the zon e security po lic y, which is use d to guide and measure the construction and maintenance of the assets contained within the zone.

2357

11.3.7.1.2

2358 2359 2360 2361 2362 2363

To maintain security within a zone, an organization must maintain a list of all of the assets (physical and logical). This list is used to assess risk and vulnerabilities and to determine and maintain the appropriate security measures required to meet the goals of the security policy. Inventory accuracy is a key factor in meeting the security goals set forth in the security policy. The list must be updated when assets within the zone change, or their electronic connections change, as well as when new assets are added to the zone to ensure that the security goals

2364

are met.

2365 2366

Physical assets and components are the physical devices contained within the zone. Some examples include:

Asset Inventory

2367 2368

a) computer hardware (e.g., workstations, disk drives, or tape backups)

2369

b) network equipment (e.g., routers, swit ches, hubs, firewalls, or physical cables)

2370 2371

c) communications links (e.g., buses, links, modems, and other network interfaces, antennas)

2372 2373

d) access authentication and authorization equipment (e.g., domain controllers, radius servers, readers, and scanners)

2374

e) development system hardware

2375

f)

2376

g) external system hardware

2377

h) spare parts inventories

2378

i)

monitoring and control devi ces (e.g., sensors, swi tches, and controllers)

2379

j)

ref erenc e manuals and infor mation.

2380

servers, instruments, controls, power supplies,

simulation and training system hardware

Logical assets include all the software and data used in the zone. Some examples are:

2381 2382

a) computer system software (e.g., applications, operating systems, communication interfaces, configuration tables, development tools, analysis tools, and utilities)

2383

b) patches and upgrades for operating

2384

c) databases

2385

d) data archives

2386

e) equipment configuration files

systems and application tool sets

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA-62443-1-1, D5E4, August 2015

– 62 –

ISA99, WG03

2387

f)

2388 2389 2390 2391

g) design basis documentation (e.g., functional requirements including information and assets, security classification and levels of protection, physical and software design, vulnerability assessment, security perimeter, benchmark tests, assembly, and installation documents)

copies of software and data maintained for backup and recovery purposes

2392 2393

h) supplier resources (e.g., product updates, patches, service packs, utilities, and validation tests).

2394

11.3.7.1.3

2395

By its nature, a zone implies that access is limited to a small set of all the possible entities

Access Requirements and Controls

2396 2397

that could have access. A security policy for a zone must then articulate the access required for the zone to meet its business objectives, and how this access is controlled.

2398

11.3.7.1.4

2399 2400 2401 2402 2403

Threats and corresponding vulnerabilities exist within a given zone. Organizations must identify and evaluate these threats and vulnerabilities to determine their risk of causing the assets within the zone to fail to meet their business objectives. The process of documenting the threats and vulnerabilities happens in the threat and vulnerability assessment that is part of the zone security policy.

2404 2405 2406 2407

Many possible countermeasures exist to reduce the risk of a threat exploiting a given vulnerability within a zone. The security policy should outline what types of countermeasures are appropriate to meet the Target Security Level for the zone, within the cost versus risk trade-off.

2408

11.3.7.1.5

2409 2410

As ind ust rial automa tio n and control sys tems evolve to me et changing business needs , the technology used to implement the changes needs to be controlled. Each of the technologies

2411 2412 2413

used in these systems brings withthe it azone set security of vulnerabilities andtocorresponding risks. minimize the risks to a given zone, policy needs have a dynamic list To of technologies allowed in the zone, as well as those not allowed.

2414

11.3.7.1.6

2415 2416 2417 2418 2419

A for ma l and acc urate process is requ ire d to mainta in the acc urac y of a gi ven zon e’s ass et inventory and how changes to the zone security policy are made. A formal process ensures that changes and additions to the zone do not compromise the security goals. In addition, a way to adapt to changing security threats and goals is required. Threats and vulnerabilities, with their associated risks, will change over time.

2420

11.3.8

2421 2422 2423 2424 2425 2426 2427 2428 2429 2430 2431 2432 2433

Conduits are security zones that apply to specific communications processes. As security zones they are a logical and/or physical grouping of assets (communication assets in this case). A security conduit protects the security of the channels that it contains in the same way that the physical conduit protects cables from physical damage. Conduits can be thought of as “pipes” that connect zones or that are used for communication within a zone. Internal (within the zone) and external (outside the zone) conduits enclose or protect the communications “channels” (conceptually cables) that provide the links between assets. Most often in an IACS environment the conduit is the same as the network. That is, the conduit is the wiring, routers, switches, and network management devices that make up the communications under study. Conduits can be groupings of dissimilar networking technologies, as well as the communications channels that can occur within a single computer. Conduits are used to analyze the communication threats and vulnerabilities that can exist in the communications within and between zones.

2434 2435 2436 2437

Conduits can be considered pipes that contain data and/or provide physical connections for communication between zones. A conduit can have subconduits to provide a one-to-one or one-to-many zone communication. Providing secure communication for the conduit can be accomplished by implementing the appropriate zone security policy.

Threat and Vulnerability Assessment

Authorized Technology

Change Management Process

Defini ng Condui ts

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA99, WG03

– 63 –

ISA-62443-1-1, D5E4, August 2015

2438

11.3.8.1

2439

Physically a conduit can be a cable that connects zones for communication purposes.

Conduits Characteristics

2440 2441 2442 2443

A co nduit is a typ e of zone th at cannot have su bzo nes; th at is, a conduit is not made up of subconduits. Conduits are defined by the list of all zones that share the given communication channels. Both physical devices and applications that use the channels contained in a conduit define the conduit end points.

2444 2445

Like a zone, each conduit has a set of characteristics and security requirements that are its attributes. These take the form of:

2446

a) Security attributes

2447

b) Asset Inventory

2448

c) Access Requirements and Controls

2449

d) Threats and Vulnerabilities

2450

e) Consequences of a Security Breach

2451

f)

2452

g) Change Management Process

2453

Authorized Technologies

h) Connected Zones.

2454

11.3.8.1.1

2455 2456

Each conduit has a controlling document that describes the overall security goals and ho ensure the Target Security Level is met. This document includes:

Security Attributes

2457

a) the conduit scope

2458

b) the conduit secu rity lev el (SL-T)

2459 2460

c) the organizational structure and responsibilitie d) the risks associated with the conduit

2461

e) the security strategy to meet the required goals

2462

f)

2463

g) the types of channels that are p ermitted within the conduit

2464

w to

s to en force the conduit security policy

the security policies to be enforced

h) documentation of the conduit a ttributes.

2465 2466 2467

Al l of the above are doc um ent ed and com bined into the co nduit security po lic y, whi ch is used to guide and measure the construction and maintenance of the assets contained within the conduit.

2468

11.3.8.1.2

2469

As wit h the zone inven tor y, an acc urate lis t of th e com mu nic ations ass ets is required.

2470

11.3.8.1.3

2471

By its nature, a conduit implies that access is restricted to a limited set of all the possible

2472 2473

entities that could have to access. A security for a conduit must articulate the access required for the conduit meet its businesspolicy objectives, and how thisthen access is controlled.

2474

11.3.8.1.4

2475 2476 2477 2478 2479

Threats and corresponding vulnerabilities exist for a given conduit. Organizations must identify and evaluate these threats and vulnerabilities to determine their risk of causing the assets within the conduit to fail to meet their business objectives. The process of documenting the threats and vulnerabilities happens in the threat and vulnerability assessment that is part of the conduit security policy.

2480 2481 2482

Many possible countermeasures exist to reduce the risk of a threat exploiting a given vulnerability within a conduit. The security policy should outline what types of countermeasures are appropriate within the cost versus risk trade-off.

Asset Inventory

Access Requirements and Controls

Threat and Vulnerability Assessment

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA-62443-1-1, D5E4, August 2015

– 64 –

ISA99, WG03

2483

11.3.8.1.5

2484 2485 2486 2487 2488

As ind ust rial automa tio n and control system s evo lve to me et ch ang ing busin ess ne eds , the technology used to implement the changes needs to be controlled. Each of the technologies used in these systems brings with it a set of vulnerabilities and corresponding risks. To minimize the risks to a given conduit, the conduit security policy needs to have a dynamic list of technologies allowed in the conduit.

Authorized Technology

2489

11.3.8.1.6

2490 2491

A fo rm al an d accur ate proce ss is re quired to ma intain the accuracy of a given cond uit ’s polic y and how changes are made. A formal process ensures that changes and additions to the

2492 2493 2494

conduit do not compromise the security goals. I n addition, a way to adapt to changing security threats and goals is required. Threats and vulnerabilities, with their associated risks, will change over time.

2495

11.3.8.1.7

2496

A c ondu it ma y a lso be de scr ibed in term s o f th e z on es to which it is co nnected .

2497

11.4

2498

11.4.1

2499 2500 2501 2502 2503 2504 2505 2506 2507

Safety systems have used the concept of safety integrity levels (SIL) for almost two decades. This allows the safety integrity capability of a component or the safety integrity level of a deployed system to be represented by a single number that defines a protection factor required to ensure the health and safety of people or the environment based on the probabil ity of failure of that component or system. The process to determine the required protection factor for a safety system, while complex, is manageable since the probability of a component or system failure due to random hardware failures can be measured in quantitative terms. The overall risk can be calculated based on the consequences that those failures could potentially have on Health, Safety and Environmental (HSE).

2508 2509 2510 2511 2512 2513 2514 2515 2516

Security systems have much broader application, a much broader set of consequences and a much broader set of possible circumstances leading up to a possible event. Security systems are still meant to protect HSE, but they are also meant to protect the industrial process itself, company-proprietary information, public confidence and national security among other things in situations where random hardware failures may not be or “are not” (refer to preceding comments and to § 5.2 the root cause. In some cases, it may be a well-meaning employee that makes a mistake, and in other cases it may be a devious attacker bent on causing an event and hiding the evidence. The increased complexity of security systems makes compressing the protection factor down to a single number much more difficult.

2517

11.4.2

2518 2519 2520 2521 2522 2523

Security levels provide a qualitative approach to addressing security for a zone. As a qualitative method, security level definition has applicability for comparing and managing the security of zones within an organization. As more data becomes available and the mathematical representations of risk, threats, and security incidents are developed, this concept will move to a quantitative approach for selection and verification of Security Levels (SL). It will have applicability to both end user companies, and vendors of IACS and security

2524 2525 2526

products. It will be used to selectsecurity IACS devices and countermeasures to beacross used industry within a zone and to identify and compare of zones in different organizations segments.

2527 2528 2529 2530 2531 2532 2533 2534

In the first phase of development, the ISA ‑ 62443 series of standards tends to use qualitative Security Levels, using terms such as “low”, “medium”, and “high”. The asset owner will be required to come up with their own definition of what those classifications mean for their particular application. The long-term goal is to move as many of the security levels and requirements to quantitative descriptions, requirements and metrics as possible to establish repeatable applications of the standard across multiple companies and industries. Achieving this goal will take time, since more exper ience in applying the standards and data on industrial security systems will need to be acquired to justify the quantitative approach.

Change Management of Process

Connected Zones

Security Levels Introduction

Definition

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA99, WG03

– 65 –

ISA-62443-1-1, D5E4, August 2015

2535 2536 2537

When mapping requirements to the different Security Levels, standard developers need some frame of reference describing what the different Security Levels mean and how they differ from each other. The goal is to propose such a frame of reference.

2538

11.4.3

2539 2540 2541

Security Levels have been broken down into three different types: target, achieved and capability. These types, while they all are related have to do with different aspects of the security life cycle.

Types of Security Levels

2542 2543 2544

–

Target Security Levels (SL-T) are the desired level of security for a particular system. This is usually determined by performing a risk assessment on a system and determining that it needs a particular level of security to ensure its correct operation.

2545 2546 2547 2548

–

Achieved Security Levels (SL-A) are the actual level of security for a particular system. These are measured after a system design is available or when a system is in place. They are used to establish that a security system is meeting the goals that were srcinally set out in the target Security Levels.

2549 2550 2551 2552

– Capability Security Levels (SL-C) are the security levels that component or systems can provide when properly configured. These levels state that a particular component or system or component is capable of meeting the target Security Levels natively without additional compensating controls when properly configured and integrated.

2553 2554 2555 2556 2557 2558 2559 2560

Each of these Security Levels is intended to be used in different phases of the security life cycle according the ISA ‑ 62443 series of standards. Starting with a target for a particular system, an organization would need to build a design that included the capabilities to achieve the desired result. In other words, the design team would first develop the target Security Level necessary for a particular system. They would then design the system to meet those targets, usually in an iterative process where after each iteration the achieved Security Levels of the proposed design are measured and compared to the target Security Levels. As part of that design process, the designers would select systems and components with the necessary

2561 2562 2563 2564

capability Security Levels to meet the target Security Level requirements – or where such systems and components are not a vailable, complement the available ones with compensating security controls. After the system went into operation, the actual Security Level would be measured as the achieved Security Level and compared to the target SAL.

2565

11.4.4

2566 2567 2568 2569 2570 2571 2572 2573 2574

When designing a new system (green field) or revising the security of an existing system (brown field), the first step is to break the system into different zones and define conduits connecting these zones where necessary. Details on how to accomplish this are given in ISA ‑ 62443-3-2. Once a zone model of the system is established each zone and conduit is assigned a target SAL, based on a risk analysis, which describes the desired security for the respective zone or conduit. During this initial zone and conduit analysis, it is not necessary to have completed a detailed system design. It is sufficient to describe the functionality that should be provided by assets in a zone and the connections between zones in order to meet the security objectives.

2575 2576 2577 2578 2579 2580 2581 2582 2583 2584 2585 2586 2587 2588 2589

Figure 12 and Figure 13 show high-level examples of systems broken down into zones connected by conduits. Figure 12 is a graphical representation of a control system for a chlorine truck loading station. The full use-case that accompanies this figure will be discussed in ISA-TR62443-1-4. It has five zones shown: the basic process control system (BPCS), the SIS, the control center, the plant DMZ, and the enterprise. The BPCS and the SIS both use PLCs to operate different aspects of the loading station with the SIS using a special functional safety PLC (FS-PLC) rated for use in safety systems. The two PLCs are connected via a nonroutable serial or Ethernet connection using a boundary protection device. Each of the PLCs is connected to a local switch with an engineering workstation for programming and HMI for operating. The BPCS and SIS zones also contain an instrument asset management system (IAMS) to measure and test the instruments. A control center containing multiple workstations and the BPCS are both connected to the plant DMZ. A plant DMZ can house a variety of components and systems, for example a data historian and a maintenance workstation as shown in the figure. The plant DMZ is shown connected to the enterprise systems, which contain the corporate wireless local area network (WLAN) and web server. Multiple domain

Using Security Levels

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA-62443-1-1, D5E4, August 2015 2590 2591

– 66 –

ISA99, WG03

controllers and boundary protection devices are shown in the figure to indicate some of the countermeasures that may be applied to improve security.

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

2592 2593 2594 2595 2596 2597 2598 2599

Figure 12 – High-level process-industry example showing zones and conduits Figure 13 is a graphical representation of a manufacturing plant. It has four zones defined: the enterprise network, the industrial/enterprise DMZ, and two industrial networks. The enterprise infrastructure has a wireless local area network (WLAN) and a connection to the Internet. Many companies use a DMZ between important parts of their systems to isolate the network traffic. In this particular example, each industrial network operates relatively independent of each other with its own PLC, field devices, and HMI.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA99, WG03

– 67 –

ISA-62443-1-1, D5E4, August 2015

2600 2601

Figure 13 – High-level manufacturing example showing zones and conduits

2602 2603

After de ter mi nin g th e ta rge t Secur it y Le vels , the sys tem can be design ed (gre en field) or redesigned (brown field) to try to meet those target Security Levels. The design process is

2604 2605 2606 2607 2608 2609

usually an iterativethe approach where the system is checked against theoftarget multiple ‑ 62443 times throughout process. Multiple parts ofdesign the ISA series standards contain guidance on different aspects of the programmatic and technical requirements that go into the design process. ISA ‑ 62443-2-1 provides guidance on the programmatic aspects of the design process while ISA ‑ 62443-3-3 and ISA ‑ 62443-4-2 define system-level and component-level technical security requirements and relate them to different capability Security Levels.

2610 2611 2612 2613 2614 2615 2616 2617

During the design process for a system, it is necessary to evaluate the security capabilities of different components and subsystems. Product suppliers will have to provide these as capability Security Levels for their components or systems by comparing product features and capabilities with the requirements defined in the ISA ‑ 62443 series for the different capability Security Levels. These capability Security Levels can be used to determine whether a given component or system is capable of meeting the target Security Level for the system. The product supplier or system integrator will also have to provide guidance on how to configure the component or subsystem to meet the claimed Security Levels.

2618 2619 2620

It is likely that in a particular design there will be some components or systems that cannot fully meet the target SAL. Where the capability Security Level of a component or system is lower than the target SAL, compensating controls need to be considered to meet the desired

2621 2622 2623 2624 2625

target Compensating controlschoosing may include changing the design of the component or systemSAL. to increase its capabilities, another component or system to meet the target Security Level or adding additional components or systems to meet the target SAL. After each iteration in the design process, the system design’s achieved Security Levels should be reevaluated to see how they compare to the target Security Levels for the system.

2626 2627 2628 2629 2630 2631 2632

Once the system design is approved and implemented, the system needs to be evaluated to prevent or mitigate deterioration of the system’s security level. It should be evaluated during or after system modifications and on a regular schedule. ISA ‑ 62443-2-1 and ISA ‑ 62443-2-2 provide guidance on the steps necessary to operate the security program and how to evaluate its effectiveness. After the achieved Security Levels have been determined, it will be necessary to evaluate whether the system is still meeting the srcinal target Security Levels (for example, using the system requirements from ISA ‑ 62443-3-3). If the system is not

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA-62443-1-1, D5E4, August 2015

– 68 –

ISA99, WG03

2633 2634

meeting those requirements, there may be multiple reasons including the lack of maintenance of the program or the need to redesign parts of the system.

2635 2636 2637

In essence, the control system security capabilities a re determined independent from a giv en use context, but are used in a given context in order to achieve the target SL of the respective system architecture, zones and/or conduits (see Figure refernce).

2638 2639 2640

Figure 14 – High-level manufacturing example showing zones and conduits 11.4.5

Security Level Vector

2642

11.4.6

Foundational Requirements

2643

Security Levels are based on the seven Foundational Requirements for security, as defined

2644 2645

on page Error! Bookmark not defined.. 1) Identification and authentication control (IAC),

2641

2646

2) Use control (UC),

2647

3) System integrity (SI),

2648

4) Data confidentiality (DC),

2649

5) Restricted data flow (RDF),

2650

6) Timely response to events (TRE), an d

2651

7) Resource availability (RA).

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA99, WG03

– 69 –

ISA-62443-1-1, D5E4, August 2015

2652 2653 2654 2655

Instead of compressing Security Levels down to a single number, it is possible to use a vector of Security Levels that uses the seven FRs above instead of a single protection factor. This vector of Security Levels allows definable separations between Security Levels for the different FRs using language.

2656 2657 2658 2659

This language can be based on the additional consequences associated with security systems or different attacks against the security objectives addressed by the FRs. The language used in the Security Level definitions can contain practical explanations of how one system is more secure than another without having to relate everything to HSE consequences.

2660

11.4.7

2661 2662 2663 2664 2665 2666 2667 2668 2669 2670

The ISA ‑ 62443 series define SLs in terms of five different levels (0, 1, 2, 3 and 4), each with an increasing level of security. The current model for defining SLs depends on protecting against an increasingly more complex threat and differs slightly depending on what type of SL it is applied to. For SL-C, this means that a particular component or system is capable of being configured by an asset owner or system integrator to protect against an increasingly complex type of threat. For SL-T, this means that the asset owner or system integrator has determined through a risk assessment that they need to protect this p articular zone, system or component against this level of threat. For SL-A, this means that the asset owner, system integrator, product supplier and/or any combination of these has configured the zone, system or component to meet the particular security requirements defined for that SL.

2671 2672 2673 2674 2675

The language used for each of the Security Levels uses terms simple, sophisticated, and extended. This language is intentionally basic language to be used for all of the standards in the ISA standards in the series will define the requirements for the Security particular purpose.

2676 2677 2678 2679

While the requirements for each of the Security Levels will be different throughout the ISA ‑ 62443 series, there needs to be a general understanding of what each of the Security Levels should protect against. The following sections will provide some guidance on how to differentiate between the Security Levels.

2680

–

2681 2682 2683 2684 2685 2686 2687 2688 2689 2690

SL 0 has multiple meanings depending on the situation in which it is applied. In defining SL it would mean that the component or system fails to meet some of the SL 1 requirements for that particular FR. This would most likely be for components or systems that would be part of a larger zone where other components or systems would provide compensating countermeasures. In defining SL-T for a particular zone it means that the asset owner has determined that the results of their risk analysis indicate that less than the full SL 1 specific requirements are necessary for that particular FR on that component or system. This would more likely happen for individual components within a system or zone that do not contribute in any way to the FR-specific requirements. In defining SL-A it would mean that the particular zone fails to meet some of the SL 1 requirements for that particular FR

2691

–

2692 2693 2694 2695

Casual or coincidental violations of security are usually through the lax application of security policies. These can be caused by well-meaning employees just as easily as they can be by an outsider threat. Many of these violations will be security program related and will be handled by enforcing policies and procedures.

2696 2697 2698 2699 2700 2701 2702 2703 2704

Using Figure 3, a simple example would be an operator able to change a set point on the engineering station in the BPCS zone to a value outside certain conditions determined by the engineering staff. The system did not enforce the proper authentication and use control restrictions to disallow the change by the operator. Also using Figure 3, another example would be a password being sent in clear text over the conduit between the BPCS zone and the DMZ zone, allowing a network engineer to view the password while troubleshooting the system. The system did not enforce proper data confidentiality and authenticator protection to protect the password. Using Figure 4, a third example would be an engineer that means to access the PLC in Industrial Network #1 but actually accesses the PLC in Industrial Network

Level Defini tions

like casual, coincidental, vague to allow the same ‑ 62443. Each of the individual Levels that apply to their

Security Level 0: No specific requirements or security protection necessary

Security Level 1: Protection against casual or coincidental viola tion

-C

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA-62443-1-1, D5E4, August 2015

– 70 –

ISA99, WG03

2705 2706

#2. The system did not enforce the proper restriction of data flow preventing the engineer from accessing the wrong system.

2707 2708

– Security Level 2: Protection against intentional resources, generic skills and low motivation

2709 2710 2711 2712 2713 2714

Simple means do not require much knowledge on the part of the attacker. The attacker does not need detailed knowledge of security, the domain or the particular system under attack. These attack vectors are well known and there may be automated tools for aiding the attacker. They are also designed to attack a wide range of systems instead of targeting a specific system, so an attacker does not need a significant level of motivation or resources at hand.

2715 2716 2717 2718 2719 2720 2721 2722 2723

Using Figure 3, an example would be a virus that infects the maintenance workstation in the Plant DMZ zone spreading to the BPC S engineering workstation since they both use the same general purpose operating system. Using Figure 4, another example would be an attacker compromising a web server in the enterprise network by an exploit downloaded from the Internet for a publicly known vulnerability in the general purpose operating system of the web server. The attacker uses the web server as a pivot point in an attack against other systems in the enterprise network as well as the industrial network. Also using Figure 4, a third example would be an operator that views a website on the HMI located in Industrial Network #1 which downloads a Trojan that opens a hole in the routers and firewalls to the Internet.

2724 2725

– Security Level 3: Protection against intentional violation using sophisticated means moderate resources, IACS specific skills and moderate motivation

2726 2727 2728 2729 2730

Sophisticated means require advanced security knowledge, advanced domain knowledge, advanced knowledge of the target system or any combination of these. An attacker going after a Security Level 3 system will likely be using attack vectors that have been customized for the specific target system. The attacker may use exploits in operating systems that are not well known, weaknesses in industrial protocols, specific information about a particular target to

2731 2732

violate the security of the system or other means that require a greater motivation as well as skill and knowledge set than are required for Security Level 1 or 2.

2733 2734 2735 2736 2737 2738 2739 2740

An exa mp le of soph ist icated means could be pa sswor d or ke y cracking tools based on has h tables. These tools are available for download, but applying them takes knowledge of the system (such as the hash of a password to crack). Using Figure 3, another example would be an attacker that gains access to the FS- PLC through the serial conduit after gaining access to the control PLC through a vulnerability in the Ethernet controller. Using Figure 4, a third example would be an attacker that gains access to the data historian by using a brute-force attack through the industrial/enterprise DMZ firewall initiated from the enterprise wireless network.

2741 2742

– Security Level 4: Protection against intentional violation using sophisticated means extended resources, IACS specific skills and high motivation

2743 2744 2745 2746 2747

Security Level 3 and Security Level 4 are very similar in that they both involve sophisticated means used to violate the security req uirements of the system. The difference com es from the attacker being even more motivated and having extended resources at their disposal. These may involve high-performance computing resources, large numbers of computers or extended periods of time.

2748 2749 2750 2751 2752 2753

An example of sophist ica ted me ans wit h extended resourc es wou ld be usin g super com puter s or computer clusters to conduct brute-force password cracking using large hash tables. Another exam ple wou ld be a botnet used to attack a sys t em using mu lti ple attack vec tors at once. A third example would be an organized crime organization that has the motivation and resources to spend weeks attempting to analyze a system and develop custom “zero -day” exploits.

2754

11.4.8

2755 2756 2757

A vector ca n be us ed to des crib e th e secur it y requ ire ments for a zon e, co nduit , comp onent or system better than a single number. This vector may contain either a specific Security Level requirement or a zero value for each of the foundational requirements (see 10.3.6).

violation using

simple means with

low

with

with

Security Level Vector Format

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA99, WG03 2758 2759

– 71 –

FORMAT → SL -?([FR,]domain) = { AC

ISA-62443-1-1, D5E4, August 2015 UC

DI

DC

RDF

TRE

RA }

Where;

2760

SL-? = (Required) The Security Level type (see 10.3.3). The possible formats are:

2761

– SL-T = Target SAL

2762

– SL-A = Achieved SAL

2763

– SL-C = Capabilities SAL

2764

[FR,] = (Optional) Field indicating the FR that the Security Level value applies. The

2765

FRs are written out in abbreviated form instead of numerical form to aid in readability.

2766 2767 2768 2769 2770 2771

domain = (Required) The applicable domain that the Security Level applies.Domains can refer to zones, control systems, subsystems or components. Some examples of different domains from Figure A.1 are SIS zone, BPCS zone, BPCS HMI, Plant DMZ domain controller, Plant DMZ to Control Center conduit and SIS to BPCS serial conduit. In this particular standard, all requirements refer to a control system, so the domain term is not used as it would be by other documents in the ISA ‑ 62443.

2772

EXAMPLE 1 → SL -T(BPCS Zone) = { 2

2

0

1

3

1

2773

EXAMPLE 2 → SL -C(SIS Engineering Workstation) = { 3

2774

EXAMPLE 3 → SL -C(RA, FS- PLC) = 4

2775

NOTE

The last ex ample specifie s only the R A component of a 7-dimension

2776

11.5

Foundational Requirements

2777 2778 2779 2780 2781

As noted in the dis cussion of funda me ntal concepts (see n.n), there are basic or Fo undational Requirements (FRs) that form the basis for subsequent requirements in this standard as well as other standards in the ISA ‑ 62443 series. All aspects associated with meeting a desired IACS security level (people, processes and technology) are derived through meeting the requirements associated with the following Foundational Requirements:

2782

1) Identification and authentication control (IAC),

2783

2) Use control (UC),

2784

3) System integrity (SI),

2785

4) Data confidentiality (DC),

2786

5) Restricted data flow (RDF),

2787

6) Timely response to events (TRE), an d

2788

3} 3

2

3

0

0

1}

SL-C.

7) Resource availability (RA).

2789 2790 2791 2792

As an exam ple , the syst em req uir em ents (SRs) and ass ociated ca pabilit y sec urit y lev els (S L C) defined in ISA ‑ 62443-3-3 are organized and numbered by FR. Rather than compressing security levels down to a single number, a vector is used to express the nuances associated with an often complex security or protection level. This vector of security levels allows

2793 2794

definable separations between security levels on a requirement by requirement basis. 11.5.1 FR 1 – Identification and authentication control (IAC)

2795

11.5.1.1

2796 2797 2798 2799

Based on the target security level (SL-T) determined, and using the processes defined in ISA ‑ 62443-3-2, the IACS shall provide the necessary capabilities to reliably identify and authenticate all users (humans, software processes and devices) attempting to access the ICS.

2800

11.5.1.2

2801 2802

Asset owner s wil l have to develo p a lis t of all valid users (h um ans , soft war e process es and devices) and to determine for each zone the required level of identification and authentication

Requirement

Rationale

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA-62443-1-1, D5E4, August 2015

– 72 –

ISA99, WG03

2803 2804 2805 2806 2807

control (IAC) protection. The goal is to protect the ICS from unauthenticated access by verifying the identity of any user requesting access to the ICS before activating the communication. Recommendations and guidelines should include mechanisms that will operate in mixed modes. For example, some zones and individual ICS components require strong IAC, such as strong authentication mechanisms, and others do not.

2808

11.5.2

2809

11.5.2.1

2810 2811

Based on the target security level (SL-T) determined using the processes defined in ISA ‑ 62443-3-2, the IACS shall provide the necessary capabilities to enforce the assigned

2812 2813

privileges of an authenticated user (human, software process or device) to perform the requested action on the system or assets and monitor the use of these privileges.

2814

11.5.2.2

2815 2816 2817 2818 2819 2820 2821 2822 2823 2824 2825

Once the user is identified and authenticated, the control system has to restrict the allowed actions to the authorized use of the control system. Asset owners and system integrators will have to assign to each user (human, software process or device), group, role, etc. the privileges defining the authorized use of the IACS. The goal of UC is to protect against unauthorized actions on ICS 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 ICS 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.

2826

11.5.3

2827

11.5.3.1

2828 2829 2830

Based on the target security level (SL-T) determined using the processes defined in ISA ‑ 62443-3-2, the IACS shall provide the necessary capabilities to ensure the integrity of the IACS to prevent unauthorized manipulation.

2831

11.5.3.2

2832 2833 2834 2835 2836 2837 2838 2839 2840 2841

An IACS wil l often go throug h mu ltiple testing cycles (unit tes tin g, fact or y acc ep tance tes tin g (FAT), site acceptance testing (SAT), certification, commissioning, etc.) to establish that the systems will perform as intended before they even begin production. Once operational, asset owners are responsible for maintaining the integrity of the IACS. 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 integrity 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 as being transmitted over a network or when residing in a data repository.

2842

11.5.4

2843

11.5.4.1

2844 2845 2846 2847

Based on the target security level (SL-T) determined using the processes defined in ISA ‑ 62443-3-2, the IACS shall provide the necessary capabilities to ensure the confidentiality of information on communication channels and in data repositories to prevent unauthorized disclosure.

2848

11.5.4.2

2849 2850 2851

Some control system-generated information, whether at rest or in transit, is of a confidential or sensitive nature. This implies that some communication channels and data-stores require protection against eavesdropping and unauthorized access.

FR 2 – Use control (UC) Requirement

Rationale

FR 3 – System integrity (SI) Requirement

Rationale

FR 4 – Data confidentiality (DC) Requirement

Rationale

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA99, WG03

– 73 –

ISA-62443-1-1, D5E4, August 2015

2852

11.5.5

2853

11.5.5.1

FR 5 – Restricted data flow (RDF)

2854 2855 2856

Based on the target security level (SL-T) determined using the processes defined in ISA ‑ 62443-3-2, the IACS shall provide the necessary capabilities to segment the control system via zones and conduits to limit the unnecessary flow of data.

2857

11.5.5.2

2858 2859 2860 2861 2862 2863

Using their risk assessment methodology, 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 demilitarized zones (DMZs) to manage the flow of information.

2864

11.5.6

2865

11.5.6.1

2866 2867 2868 2869

Based on the target security level (SL-T) determined using the processes defined in ISA ‑ 62443-3-2, the IACS shall provide the necessary capabilities to respond to security violations by notifying the proper authority, reporting needed evidence of the violation and taking timely corrective action when incidents are discovered.

2870

11.5.6.2

2871 2872 2873 2874 2875

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 timely corrective action. The use of monitoring tools and techniques should not adversely

2876 2877

affect the operational performance of the control system. 11.5.7 FR 7 – Resource availability (RA)

2878

11.5.7.1

2879 2880 2881

Based on the target security level (SL-T) determined using the processes defined in ISA ‑ 62443-3-2, the IACS shall provide the necessary capabilities to ensure the availability of the control system against the degradation or denial of essential services.

2882

11.5.7.2

2883 2884 2885 2886

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

2887

11.6

2888 2889 2890 2891 2892 2893 2894 2895

Safety Instrumented Systems (SIS), represent one layer of protection that may be implemented in order to reduce risks associated with Industrial Automation Control Systems. Traditional risk assessment methodologies in the past, have generally excluded the potential for cyber related attacks to cause safety related incidents. Given that targeted attacks on Industrial Automation Control Systems have occurred and these systems are increasingly being connected to other business systems, they represent a significant potential for common mode failure. As a result, it is necessary in today's world to include cyber security in the overall Risk Assessment.

2896 2897 2898

Without addressing cyber security throughout the entire safety lifecycle, it is impossible to adequately understand the relative integrity of the various layers of protection that involve instrumented systems, including the SIS.

2899 2900

The underlying premise of this standard is that the means to implement, operate, and maintain system security should not compromise the performance of the safety instrumented systems

Requirement

Rationale

FR 6 – Timely response to events (TRE) Requirement

Rationale

Requirement

Rationale and supplemental guidance

Safety and Security

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA-62443-1-1, D5E4, August 2015

– 74 –

ISA99, WG03

2901 2902

(SIS). It should also be understood that achieving higher security levels may result in less convenience to the end user.

2903 2904 2905 2906

Note- the ISA84 Technical Report would like to use a modified version of the first 2 paragraphs that is specific to the process industry, but probably not the Rationale section. I also have reservations about including the Rationale section. We can discuss if the first 2 paragraphs have enough content for the Foundational Clause, or if the Rationale section should also be included and/or edited down.

2907 2908 2909

Note update Jun 06, 2015. The wording of the first 2 paragraphs has been modified, and a third paragraph has been added. These changes align with the ISA84 Technical Report, yet maintains a generic approach to safety & security (in contrast to ISA84's process specific approach).

2910

11.6.1

2911 2912 2913 2914 2915 2916 2917

To take advantage of digital advances, Industrial Control Systems have changed dramatically in the last two decades. Once isolated and proprietary, ICS today are part of a converged network that connects plant operations to the administrative environment. The migration from single-purpose supervisory control and data acquisition (SCADA) systems to industry standard, network-based systems provided numerous benefits, including increased information-sharing across the operation, and remote (Internet and wireless) access to Industrial Control Systems.

2918 2919 2920 2921

But those advances also created security gaps. By connecting to the larger web of networks, water-control systems are exposed to the myriad threats that lurk in cyber space, including viruses, worms and trojans. Poor control-system architecture, unfettered user access, and lax oversight of security policies and procedures have all combined to heighten the risk.

2922 2923 2924 2925

Meanwhile, manuals and training videos on ICS are publicly available, and many hacker tools can be downloaded or purchased on the Internet. Cyber criminals need little systems knowledge to infiltrate ICS operations. For all these reasons, the number of control-system cyber-security incidents has escalated sharply.

2926

Accordin g to RIS I, alm ost ha lf of all cybe r inc idents acr oss al l industries wer e ca use d by

2927 2928 2929 2930

malware, including viruses, worms and trojans. But unauthorized access or sabotage by internal sources, such as disgruntled workers or contractors using access privileges to cause harm, rose considerably at the same time. Network anomalies also triggered failures in control-system equipment.

2931 2932 2933 2934 2935 2936 2937 2938

The increasing inter-connectivity of control systems is equally important to industry since new benefits also bring new challenges. Open industrial networks that seamlessly coexist in broader Ethernet systems are being used to link various plant-wide control systems together and connect these systems into expansive, enterprise-level systems via the Internet. As the pace of control system and enterprise network architecture convergence quickens, industrial security depends on staying both flexible and vigilant and successfully controlling the space. What may be considered adequate protection today should evolve as vulnerabilities are identified and new threats emerge.

2939 2940 2941 2942

The discovery of malware that specifically targets industrial control systems brought industrial security to the forefront in manufacturing. As a result, there is growing recognition of the risks and real-world threats that are capable of disrupting control system operation and adversely affecting safety.

2943 2944 2945

12 Compliance Metrics

2946

Rationale

NOTE: This clause is reserved for a discussion of standards.

the role of compliance metrics in the application of the

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA99, WG03

– 75 –

Annex A – Zones and Conduits Examples

2947 2948

ISA-62443-1-1, D5E4, August 2015

A.1 Introduction

2949 2950

A.2 Un trusted Conduits

2951 2952 2953

Untrusted conduits are those that are not at the same level of security as the zone endpoint. In this case the security of the communication becomes the responsibility of the individual channel. This is illustrated in Figure Error! Bookmark not defined..

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

Enterprise Zone Laptopcomputer

Workstation

Mainframe

Server

Server

Enterprise Conduit

Plant A Zone

Plant B Zone Router

Laptop computer Workstation

File/Print Server

App. Server

Plant C Zone Router

Laptop computer Workstation

Data Server

File/Print App. Server Server

Plant A Control Zone

Data Server

File/Print Server

Data Server

Maint. Server

Firewall

Plant Control Conduit

Controller

2954

I/O

Controller I/O

2955

App. Server

Data Server

Plant C Control Zone

Plant B Control Zone Firewall

App. Server

Router Laptop computer Workstation

Firewall

Firewall

App. Server

Data Server

Maint. Server

Firewall

Plant Control Conduit

Controller I/O

Controller I/O

App. Server

Data Server

Maint. Server

Firewall

Plant Control Conduit

Controller I/O

Controller I/O

Figure 15 – Conduit Example

2956 2957 2958 2959 2960 2961 2962 2963

This figure represents a three-plant organization with a separate corporate headquarters. The three plants are connected to the enterprise network to allow communications to headquarters and the other plants. Four possible conduits are defined in the drawing (others would also be defined, but are skipped for brevity). The first is the enterprise conduit, shown at the top of the figure. It connects multiple plants at different locations to the corporate data center. If the wide area network (WAN) is constructed using leased or pr ivate communications, then it could be considered a trusted conduit. If it uses both public and private networks, then it may be classified as untrusted. Included in the conduit is all of the communications equipment and

2964 2965 2966

firewalls that make up the plant links. Instances of the second conduit class are shown in each plant. Here own trusted conduit to allow control communication.

2967

A.3 Mu lti-Plant Model

2968 2969 2970

A simp lif ied mu ltiplan t zone mo del is sh own in Fi gure Error! Bookma rk not def ined. . Her e the plant zone are the parents, and each plant control zone is a child contained within the plant subzone.

2971 2972

NOTE: There is a distinct advantage to aligning security zones with physical areas example, aligning a control center with a control security zone.

each of the plants has its

or zones in a facility

— for

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA-62443-1-1, D5E4, August 2015

– 76 –

ISA99, WG03

Enterprise Zone Laptop computer

Workstation

Mainframe Server

Plant A Zone

Plant B Zone Router

Laptop computer Workstation

File/Print Server

App. Server

Data Server

File/Print Server

App. Server

Controller

I/O

Maint. Server

Controller

I/O

Router Laptop computer Workstation

Data Server

File/Print Server

Plant B Control Zone Firewall

Data Server

Plant C Zone Router

Laptop computer Workstation

Plant A Control Zone

App. Server

Server

App. Server

Data Server

Plant C Control Zone Firewall

App. Server

Data Server

Controller

I/O

Maint. Server

Controller

I/O

Firewall

App. Server

Data Server

Controller

I/O

Maint. Server

Controller

I/O

2973 2974

Figure 16 – Multiplant Zone Example

2975

A.4 (Description)

2976 2977 2978

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

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA99, WG03

– 77 –

ISA-62443-1-1, D5E4, August 2015

Enterprise Zone Laptopcomputer

Workstation

Mainframe

Plant A Zone

Server

Server

Plant B Zone Router

Laptop computer Workstation

Plant C Zone Router

Laptop computer Workstation

Router Laptop computer Workstation

File/Print Server

App. Server

Data Server

File/Print Server

Plant A Control Zone

App. Server

Data Server

Plant B Control Zone Firewall

App. Server

Data Server

Controller

2979

I/O

File/Print Server

Maint. Server

Controller

I/O

2980

App. Server

Data Server

Plant C Control Zone Firewall

App. Server

Data Server

Controller

I/O

Maint. Server

Controller

I/O

Firewall

App. Server

Data Server

Controller

I/O

Maint. Server

Controller

I/O

Figure 17 – Separate Zones Example

2981

A.5 SCA DA Applications

2982 2983

Similar models can be constructed for SCADA applications, as shown in Figures Error! Bookmark not defined. and Error! Bookmark not defined..

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA-62443-1-1, D5E4, August 2015

– 78 –

ISA99, WG03

Enterprise Zone Laptop computer

Workstation

Mainframe Server

Server

Control Center

Backup Control Center Firewall

WAN App. Server

SCADA Server

SCADA Server

App. Server

SCADA Server

SCADA Server

SCADA System Zone Communications Processor

Communications Processor

Serial orf IP SCADA Network WAN Radio / Microwave / Cellular Network

Local HMI

2984 2985

Network Interface

Local HMI

Network Interface

Public /Private Telephone Network

Local HMI

Satellite Network

Network Interface

RTU or PLC

RTU or PLC

RTU or PLC

I/O

I/O

I/O

Site A Control Zone

Site B Control Zone

Site X Control Zone

Figure 18 – SCADA Zone Example

Local HMI

Network Interface

RTU or PLC I/O

Site Y Control Zone

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA-62443-1-1, D5E4, August 2015 2991 2992

– 80 –

ISA99, WG03

Just as with zones, a similar view can be constructed for use in SCADA applications. An example is shown in Figure Error! Bookmark not defined..

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

2993 2994 2995

Figure 21 – SCADA Conduit Example

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA99, WG03

– 81 –

ISA-62443-1-1, D5E4, August 2015

Annex B – Truck Loading Description

2996 2997

B.1 Introduction

2998

(Excerpt 1)

2999 3000 3001 3002 3003

The example system is a control system for a ch emical truck loading facility . The facility is a self-service loading station where drivers of chemical tanker trucks can drive in, connect a dispensing arm to the tanker inlet, and initiate the filling of the truck through a local operator panel. There is a central control room for the facility where full time operators can also monitor and control the process. However, the primary role of the operators is to operate the

3004

chemical manufacturing process.

3005 3006 3007 3008

A system arch ite cture diagr am is sh own be low in Figure 3. Th e arch ite cture se lec ted is me an to represent a fairly modern design that is typical of what is found in many plants today. There are some cybersecurity controls in place but there are intentionally several vulnerabilities in the design. IT Data Center

Corporate WAN

Domain Controller

Data Historian

Enterprise Firewall

Business LAN

Business LAN

Control Room

Operator Consoles

Operator Consoles

PCN

Equipment Room

SIS Engineering Workstation

DCS Server DCS Server BPCS Engineering Workstation

PCN `

`

PCN

FS-PES

Control PES

Field BPCS HMI

3009 3010

Figure 22 – Chemical Truck Loading Control System Architecture Diagram

3011

The first step in the process is to identify the System-under-Consideration (SuC).

3012

Figure 18 is an illustration of the system delineating the boundary of the SUT.

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA-62443-1-1, D5E4, August 2015

– 82 –

ISA99, WG03

IT Data Center

Corporate WAN

Domain Controller

Data Historian

Enterprise Firewall

Business LAN

Business LAN

Control Room

Operator Consoles

Operator Consoles

PCN

Equipment Room

SIS Engineering Workstation

DCS Server

DCS Server BPCS Engineering Workstation

PCN `

`

PCN

FS-PES

Control PES

Field BPCS HMI

3013 3014

Figure 23 – Chemical Truck Loading System with Definition of SUT Boundary

3015 3016 3017

The organization shall perform a high-level risk assessment of the assets within the SuC (per ISA99.02.01: 2009 Clause 4.2.3.1-4) to determine financial and health, safety and environmental (HSE) impact based on function, location, and potential consequences.

3018 3019 3020 3021 3022 3023

Based upon the risk assessment (HAZOP) performed on the chemical truck loading facility, the worst-case credible scenario is that the system attempts to fill a truck when there is not one present which would result is a large release of hazardous and flammable material. Under certain c onditions, it i s possible for the vapor cloud to ignite and explode. Fire suppression systems in the facility may be able to prevent the explosion and mitigate the damage if they react in time. While there are several interlocks in place designed to prevent

3024 3025 3026 3027

this scenario, they are all capable of being bypassed by the control or safety system. A local operator or truck driver has the ability to initiate an emergency-stop that is hard-wired to interrupt power to t he system. However, there are several scenarios where the local operator or truck driver fails or is unable to react in time to prevent the worst case consequence.

3028

There are several more scenarios that can result in lower category consequences such as:

3029

– A small spill

3030

–

3031

– Inability to load tanker

3032

–

Theft

Under-filling

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA99, WG03 3033 3034 3035

–

– 83 –

ISA-62443-1-1, D5E4, August 2015

Incorrect record keeping (or loss of record)

Using the following tables (Table A.1, A.2) we will perform a cybersecurity risk assessment on the control system. . e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

3036

3037 3038 3039 3040 3041

Figure 1 shows a diagram of the major components of a chemical truck loading station to illustrate how the requirements related to the zones and conduits concepts can be used for doing risk assessments or consequence analyses. This figure also is intended to clarify some of the terminology used.

3042

3043 3044 3045

Figure 24 – Diagram of major components for chemical truck loading example We start by creating a table of the assets in the control system IACS Device Asset

Consequence Rating

Likelihood Rating

Risk Rating

DCS Eng Workstat ion

B

H

High

SIS Eng Workstation

A

M

High

Data Historian

B

M

Med

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA-62443-1-1, D5E4, August 2015 Maintenance Workstation

– 84 – B

ISA99, WG03 M

Med

FS-PES

A

L

Med

Domain Controller

B

M

Med

Firewal l

B

M

Med

Operator Stations

B

M

Med

Control PES

B

L

Med

DCS Servers

B

M

Med

DMZ Switch

B

L

Low

BPCS HMI

C

L

Low

PCN Switch(es)

B

L

Low

3046

3047

3048 3049 3050 3051

NOTE: The “External Network” shown in the diagram above represents all networks external to the SuC, so could be a company’s enterprise netwo rk, which in turn would be connected to external networks, incl uding the Internet. The SuC shown here encompasse s all parts of the plant that are to be modeled using zones and conduits.

3052 3053 3054 3055 3056 3057 3058

In order to provide clearer descriptions of concepts and boundaries that are significant for explaining security issues and areas of responsibility, the following hierarchy is proposed. Significant networks in a company can be arranged with the enterprise network at the highes t level. This network s erves the enti re company and includes office automation support and communications needed for the business side and managed by the Information Technology (IT) Department. The business side includes financial, procurement, legal, and administrative activities. An Office Automation Network (OAN) supports these office automation act ivities.

3059 3060

The technical operations part of the company includes the industrial automation and control systems (IACS) support, most of which is managed by an Industrial Automation (IA)

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA99, WG03

– 85 –

ISA-62443-1-1, D5E4, August 2015

3061 3062 3063 3064

Department or control systems group. The IACS includes the system u nder consideration (SuC) and technical support for it. Both the SuC and additional organizational support (policies, guidelines, operator training activities, etc.) which all combine to make up the IACS are also connected to the enterprise network through a firewall.

3065 3066 3067

As a practic al ma tter the IACS should inc lude all ass ets neede d to ma int ain norm al pla nt operations in stand-alone mode should it be necessary to disconnect the IACS from all external networks during a sustained cyber attack (a period of time that could last weeks).

3068 3069

The system under consideration (SuC) consists of the control system security zone and everything contained in it, the router/firewall conduit separating the control system security

3070 3071 3072 3073

zone and plant network se curity zone, the plant netwo rk security zone, and the router/firewall separating the plant network from the company enterprise network. The SuC in thi s example shows a hierarchy of zones contained in zones (zone “nesting” is allowed) and conduits within zones.

3074 3075 3076 3077

An initial high le vel risk ass ess me nt ident ifi es th e mo st sig nif ica nt vulnerabiliti es at th e SuC level affecting the station as a whole such as a large catastrophic release of chlorine gas (a very bad leak), physical damage from a large explosion or m ajor rupture of a tank, and access restrictions to support maintaining the physical integrity of the station and its operation.

3078 3079 3080

The control system (PLC) network is isolated from the plant network by a router/firewall, even though both are part of the SuC, in order to reduce risks associated with a potentially very hazardous operation (transfer of chlorine gas).

3081 3082 3083 3084 3085

In the example considered here activities supported on the plant network are modeled using zones and conduits and are included in the consequence assessment (risk analysis) with associated assignment of security assurance levels (SALs) that must be met. Once the facility is in operation, management of the plant network activities could be done either by the IT or IA pa rts of the orga nization. A major IT obje ctive is usually protection of information

3086 3087 3088 3089

while major objective an industrial automation application protection of anda availability of thefor plant (in this example the ability at all (control times tosystem) control is operation of the loading station). A control system often has hazardous energy sources whi ch are not part of an office automation environment.

3090 3091 3092 3093 3094

It will be important to have IT participation at some level in the zones and conduits modeling and consequence assessment ac tivities. Roles and responsibilities of plant personnel in both areas (IT and IA) n eed to be clea rly defined. Network monitoring and management goals may be different, so need to be defined. Likewise, things li ke patch management, system t esting, and upgrades to software and operating systems.

3095

Step 3: Identify Zones & Conduits

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA-62443-1-1, D5E4, August 2015

– 86 –

ISA99, WG03

3096

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

3097 3098 3099

Figure 25 – Zone and Conduit Identification Step 4: Document Security Requirements

3100 3101

Name and/or unique identifier

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA99, WG03

– 87 –

3102

Logical boundary

3103

Physical boundary, if applicable

3104

List of all access points and associated boundary devices

3105

List of data flows associated with each access point

3106

Connected zones or conduits

3107

List of assets and associated consequences

3108

Security Level Target

3109

Appl ica ble s ecurit y p olicies

3110

Assump tio ns and external depe nde ncies

3111

ISA-62443-1-1, D5E4, August 2015

Table 9 – Zone Characteristics Name and/or unique identifier Logical boundary

Physical boundary, if applicable List of all access points and associated boundary devices

List of data flows associated with each Logical Access point

Process Control Zone This zone interfaces with the Process Information Zone, Process Safety Zone and Process Measurement Zone through 3 distinct conduits The Process Control Zone is physically located within the equipment room Logical Access Points:  Process Safety / Process Control Conduit  Process Operations / Process Control Conduit  Process Control / Process Measurement Conduit Physical Access Points  Door to Equipment Room Process Safety / Process Control Conduit:  Read-only status of safety system variables to Control System Servers for display on Operator Stations Process Operations / Process Control Conduit:  Read-only status of Control PES variables for display on Operator Stations  Data writes from Operator Stations to Control PES (e.g. setpoint changes) Process Control / Process Measurement Conduit  Two-way flow of data between Control PES and field HMI panel and remote I/O.

Connected zones

List of assets consequences

and

associated

 Process Operations Zone  Process Safety Zone  Process Measurement Zone  DCS Servers – B (Medium)

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA-62443-1-1, D5E4, August 2015

– 88 –

ISA99, WG03



Security Level Target Appl ica ble security po lic ies

DCS Engineering Workstation - B (Medium)  CLAN-2 Switch - B (Medium)  Control PES - B (Medium) Medium

Assump tio ns and external depe nde ncies 3112 3113 3114 3115 3116 3117 3118 3119 3120 3121 3122 3123

Figure 2 and Figure 3 show high-level examples of systems broken down into zones connected by conduits. Figure 2 is a graphical representation of a control system for a chlorine truck loading station. It has three security zones defined: the control system, the safety integrated system (SIS), and the plant network. The control system and SIS both use programmable logic controllers (PLCs) to operate different aspects of the loading station. The two PLCs are connected via a non-routable serial Modbus network. Figure 3 is a graphical representation of a manufacturing plant. It has four zones defined: the enterprise network, the industrial/enterprise demilitarized zone (DMZ), and two industrial networks. The enterprise infrastructure has a wireless local area network (WLAN) and a connection to the Internet. Many companies use a DMZ between important parts of their systems to isolate the network traffic. In this particular example, each industrial network operates relatively independent of each other with its own PLC, field devices, and human-machine interface (HMI).

3124 3125

Figure 26 – High-level process-industry example showing zones and conduits

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA99, WG03

– 89 –

ISA-62443-1-1, D5E4, August 2015

3126 3127

Figure 27 – High-level manufacturing example showing zones and conduits

3128

After det erm ini ng the tar get SALs, the system can be des ig ned (g reen fi eld ) or redes igned

3129 3130 3131 3132 3133 3134 3135

(brown field) to the try to meetdesign those is target SALs. against The design process is usually an iterative the approach where system checked the target multiple tim es throughout process. Multiple parts of the ISA99 series of standards contain guidance on different aspects of the programmatic and technical requirements that go into the design process. ISA 99.02.01 [2] provides guidance on the programmatic aspects of the design process while ISA 99.03.03 [5] and the ISA 99.04.## series define system-level and component-level technical security requirements and relate them to different capability SALs.

3136 3137 3138 3139 3140 3141 3142

During the design process for a system, it is necessary to evaluate the security capabilities of different components and subsystems. Vendors will have to provide these as capability SALs for their products by comparing product features and capabilities with the requirements defined in the ISA99 series for the different capability SALs. These capability SALs can be used to determine whether a given system or component is capable of meeting the target SAL for the system. The vendor or system integrator will also have to provide guidance on how to configure the component or subsystem to meet the claimed SALs.

3143 3144 3145

It is likely that in a particular design there will be some components or systems that cannot fully meet the target SAL. Where the capability SAL of a component or system is lower than the target SAL, compensating controls need to be considered to meet the desired target SAL.

3146 3147 3148 3149 3150

Compensating controls may include changing the design of thetocomponent or system to increase its capabilities, choosing another component or system meet the target SAL, or adding additional components or systems to meet the target SAL. After each iteration, the system design SALs should be reevaluated to see how they compare to the target SALs for the system.

3151 3152 3153 3154 3155 3156 3157

Once the system design is approved and implemented, the system needs to be evaluated to prevent or mitigate deterioration of the system’s security level. It should be evaluated during or after system modifications and on a regular schedule. ISA 99.02.01 and ISA 99.02.02 [3] provide guidance on the steps necessary to operate the security program and how to evaluate its effectiveness. After the achieved SALs have been determined, it will be necessary to evaluate whether the system is still meeting the srcinal target SALs (e.g. using the system requirements from ISA 99.03.03). If the system is not meeting those requirements, there may

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA-62443-1-1, D5E4, August 2015

– 90 –

ISA99, WG03

3158 3159

be multiple reasons including the lack of maintenance of the program or the need to redesign parts of the system.

3160

B.2 Safety and Security

3161 3162 3163 3164 3165 3166

Annex Error! Ref erenc e sou rc e not fo und. dis cusses th e truck loading co ntrol system . Th e specific area of interest from the safety prospective is facilitated by interlocks on the connections to the truck that assures recirculation of air via two separate hoses. The pumps cannot be turned ON unless there is a po sitive confirmation that the hoses are connected. If a hose i s removed, i t would automatically shut off the pumps. There is also a high- level protection switch that assures that if the chemical tank is at a certain level that is automatic

3167 3168 3169 3170 3171 3172

shuts off the pumps. There is also gas detection a truck unloading area and any place along the injection lines to the equipment that will use the chemical. If there is an alert, it will automatically shut down the pumps and signal the operator. In some processes where the chemical is being injected into a burning process for example, the emissions are monitored. This would be the case when a hazardous chemical is being used as part of any part of a process.

3173 3174 3175 3176 3177 3178 3179 3180 3181 3182 3183 3184

The safety system must be tested prior to commissioning of the system by circulation and injection of water to determine if there are any leaks. Otherwise, the hazardous chemical or gases could escape and create a unsafe condition for personnel the system should also have a flush cycle to inject water once again to flush the hazardous chemical out of the lines. This system must all be tested to assure proper operation. Emissions monitoring is extremely important in these types of applications where the gases can be released into the air, into the ground, or nearby bodies of water. This would put the plant at risk for OSHA or MSHA violation including EPA emissions violation, which all would be punishable by fines. Personal injury prevention is important so if any action has consequence that would expose personnel or if release into the air or water it may affect people many miles from the facility. Spill control is also important safety relevant condition so run off monitor and positioning of eyewash stations must be monitored and provide alerts to operations, which may include key

3185 3186 3187 3188 3189 3190

personnel. Personal training is done for safety conditions including lockout and wearing proper safety gear but there is no explanation of security concerns other than potential limitation of use of cell phones and other radios i n a particular area. There is always a need to have an emergency shutdown and those conditions must be evaluated since immediate shutdown of a control system must be able to recover form unexpected or an emergency shutdown.

3191 3192 3193 3194 3195 3196 3197 3198

In some process these alerts may extend to monitor when the take is low since a hazardous chemical may be an integral part of a production process to reduce NOX emissions for example. In these situations, the monitoring of a 30 -day average may be important to m aintain EPA compliance. Process operation many need to be changed to assure the long-term accumulation of release of toxic gases into the air many mean that there will be an even wider effect related to use of hazardous chemicals, which are needed as part of a productions process. There may be other instruments including sensors that may exist to detect unsafe conditions and can provide notification to opera tor.

3199 3200 3201

The use of hazardous chemicals in a process requires that all aspects of a system must operate perfectly since they cannot be allowed to operate in a reduced capacity. Consequently, the system will have interlocks that prevent startup and will force a shutdown if

3202 3203 3204

those permissive are lo st or changed. There are other conditions such as power and water supplies that now become critical which under normal operation they could be operated at a reduced capability.

3205 3206 3207 3208 3209 3210 3211

The backup power systems should be monitored. Sufficient water and air for pneumatic devices must be monitored and frequently checked to assure that they are operating properly. There is limited leeway and having an ample supply of power, water, and air are essential for plant operations especially if used in safety operations. Generally, physical security was the only consideration and there is no requirement or standard to provide assurance that restriction of packets that could adversely affect operations and impact safety of those systems.

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA99, WG03 3212 3213 3214 3215 3216 3217 3218

– 91 –

ISA-62443-1-1, D5E4, August 2015

It is important to define the safety aspects to recognize what can be the impact. The security aspects need to provide protection against intrusion and alteration of operations. This may include confidentiality if knowledge of those conditions or restriction to access of that system needs further restriction. The end devi ces are generally vulnerable since the protection against cyber infringement due not exists. Consequently, new capabilitie s are need to i solate those operations yet providing a means to facilitate a dialog with other devices, user, and applications that are trusted to view or control operations of security-safety related systems.

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA-62443-1-1, D5E4, August 2015

– 92 –

ISA99, WG03

Annex C – Example: Procedure to apply foundational requirements

3219 3220

C.1 Overview

3221

C.1.1

3222 3223 3224 3225

Figure C-1 shows a chemical truck loading station, where a Programmable Logic Controller (PLC) is used to control the loading of liquid chlorine, a hazardous chemical, from a storage tank to a tank truck. For the purpose of this example, this is the system under consideration (SuC).

Description of example system under consideration

3226 3227 3228

Figure 28 – Example application - Chemical truck loading station Components of the IACS include:

3229 3230

– Field instruments pumps.

such as flow sensors

and transmitters,

valves, motor

control for

3231

–

PLC syste m including power supplie s, CPU, and in terface modules for field signals.

3232

–

Workstations for operation, supervision, maintenance and enginee ring.

3233

–

Communication infrastructure including switches and firewalls.

3234

C.1.2

3235

Objective

3236 3237

The objective of this example is show how the foundational requirements are applied to an example problem - in this case, the chemical loading truck station.

3238

Assump tio ns

3239 3240 3241 3242

It was assumed that ISA ‑ 62443-3-3 is applied throughout the life-cycle of the security architecture. Therefore, the target, design, achieved and measured system security assurance level needed to be addressed. At each stage in the life-cycle, all 4 levels are included to provide a comparison and basis for system security assurance level selection.

Technical Approach

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA99, WG03

– 93 –

ISA-62443-1-1, D5E4, August 2015

3243 3244

In C.1.2.3, the selection is based on reviewing company policy and the AC guideline provided in ISA ‑ 62443-3-3.

3245 3246 3247 3248

In C.2.1 the selection is based on FR1 AC3 and the added “security strength” requirements to discriminate between system security assurance levels. System security assurance is designated “design” because t he additional detail provides information needed for the “build -to” decision.

3249 3250 3251

In C.2.2 and C.3 the selection is based on the same information described previously, but now given an installed security architecture which has been validated after site accept ance testing and commissioning. This is designated time “t0” and the system security

3252

assurance is now labeled “achieved.”

3253 3254 3255

In C.4, the maintenance life-cycle phase includes comments regarding system security compliance metrics and the designation is label ed “measured” based on assessment of measured performance.

3256

Consequence analysis

3257 3258 3259 3260

It is interesting to note that the selected requirements from does not mention “consequence analysis” per se. This example assumes that consequence analysis occurs throughout the life cycle. It is not a one-time analysis. Each time it is performed the parameters of the consequence analysis are somewhat different.

3261 3262 3263

For example when developing a company policy, a consequence analysis of sufficient depth needed to establish the policies and procedures and provided sufficient guidance to establish the “target” security assurance level for the SuC.

3264 3265

When the security architecture is selected (“design”), a consequence ana parameters that reflect the capability of enabling security mechanisms.

3266 3267 3268

When installed and commissioned (“achieved”) at time t0, a consequence analysis is repeated to account for any variance between design expectations and real capability that has been verified by testing & analysis for c ommissioning.

3269 3270 3271 3272

Lastly, during maintenance of the installed security architecture, a consequence analysis is repeated based on collected measurements of performance and other reports required by ISA ‑ 62443-1-3. Practical experience has shown that deviations from the norm (what was expected) may or may not have an impact on the assessed consequence.

3273

Selected application of ISA

3274 3275 3276

ISA ‑ 62443-3-33 defines the guidelines to apply assessment criteria. For this example (Figure C-1), tailored for IACS application, the AC-3 guideline is prescribed in terms of control with supplemental guidance.

3277 3278 3279

Control: The Industrial Automation Control System shall provide the capability to enforce assigned authorizations for controlling access to the system in accordance with applicable policy.

3280 3281 3282 3283 3284 3285 3286 3287 3288 3289 3290

Supplemental guidance: Access control policies (e.g., identity-based policies, role-based policies, rule-based policies) and associated access enforcement mechanisms (e.g., access control lists, access control matrices, cryptography) are employed by organizations to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, domains) in the IACS. In addition to controlling access at the information system level, access enforcement mechanisms are employed at the application level, when necessary, to provide increased information security for the organization. Consideration is given to the implementation of a controlled, audited, and manual override of automated mechanisms in the event of emergencies or other serious events. If encryption of stored information is employed as an access enforcement mechanism, the cryptography used is FIPS 140-2 (as amended) compliant.

-

is

lysis is repeated with

‑ 62443-3-3 to the system under consideration

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA-62443-1-1, D5E4, August 2015

– 94 –

ISA99, WG03

3291 3292 3293 3294 3295 3296 3297 3298

For this example a review of company policies and procedures determined that the organization explicitly defines privileged functions and security-relevant information for the IACS. Furthermore, the organization explicitly authorizes personnel access to privileged functions and security-relevant information in accordance with organizational policy. And, the IACS restricts access to privileged functions (deployed in hardware, software, and firmware) and security-relevant information to explicitly authorized personnel (e.g., security administrators). Lastly, automated test mechanism implementing access enforcement policies are widely deployed.

3299 3300

For these reasons, access enforcement requires security assurance which is constrained by the need to ensure IACS operational availability, comply with the need to ensure public and

3301 3302 3303 3304 3305

environmental safety, guard against total system failure and to guard against the possibility of loss of life. Based on the installed operational concept, the asse t owner’s senior management  states that for this example, the following target system security assurance levels (  ) which are subject to verification by the system integrator; and if required, a recognized certification authority: 

3306 3307

 = 1:

IACS security functions are not mission critical and are not the target of adversarial threats.

3308 3309

 = 2:

3310 3311 3312 3313

 = 3:

3314 3315

 = 4:



IACS security functions are not mission critical, but are the target of adversarial threats.



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

of



IACS functions are mission critical, are the target of adversarial threats, but require immediate response to ensur e public and environmental safety resulting

3316 3317

from the total failure of IACS operating capability or loss of life. Focus on Access Enforcement

3318

Design (build-to) security assurance level

3319 3320 3321

An example of ma pping th is me thodo logy to the IACS security re quiremen ts for Figure C -1 is described in this clause. For the purpose of this example, the design security assurance levels S_system^design are based on selected (build-to) security architecture.

3322

FR 1: Access Control (AC)

3323

ISA ‑ 62443-3-3 AC-3: Access Enforcement (AE)

3324 3325

Requirement: The IACS shall provide the capability to enforce assigned authorizations for controlling access to the system in accordance with applicable policy.

3326 3327 3328

Rationale/Supplemental Guidance: Access control policies (e.g., identity-based policies, rolebased policies, rule-based policies) and associated access enforcement mechanisms (e.g., access control lists, access control matrices, cryptography) are employed by organizations to

3329 3330 3331 3332 3333 3334 3335 3336

control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, domains) in the IACS. In addition to controlling access at the system level, access enforcement mechanisms are employed at the application level, when necessary, to provide increased information security for the organization. Consideration is given to the implementation of a controlled, audited and manual override of automated mechanisms in event of emergencies or other serious events. The organization ensures that access enforcement mechanisms do not adversely impact the operation performance of the IACS.

3337 3338 3339

Requirement Enhancement (RE-1): The IACS shall provide the capability to restrict access to privileged functions (deployed in hardware, software, and firmware) and security-relevant information to explicitly authorized personnel.

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA99, WG03

– 95 –

ISA-62443-1-1, D5E4, August 2015

3340 3341 3342 3343 3344

Enhancement Rationale/Supplemental Guidance: Explicitly authorized personnel must include, for example, IACS operators, security administrators, system and communication network administrators, and other privileged users. Privileged users are individuals who have access to system control, monitoring, or administration functions (e.g., systems administrators, SAS security officers, maintainers, system programmers).

3345 3346 3347

Requirement Enhancement (RE-2): The IACS shall provide the capability for dual authorization, based on approved organization procedures, to privileged functions that have impacts on facility, human, and environmental safety.

3348

RE-2 Security Strength 0: No explicit security strength is mandated.

3349 3350

RE-2 Security Strength 1: Organization with functional responsibility shall sign-off (approval) on access privileges.

3351 3352

RE-2 Security Strength 2: Senior management with oversight responsibility of the functional organization responsible shall sign-off (approval) on access privileges.

3353 3354 3355

Enhancement Rationale/Supplemental Guidance: The organization does not employ dualapproved mechanisms when an immediate response is necessary to ensure human and environmental safety.

3356

Design System Security Assurance Levels: 

3357

 = 1: FR-1, 800-53 AC-3 with security strength 0

3358

 = 2: FR-1, 800-53 AC-3, RE-1 and RE-2 with security strength 0

3359 3360

 = 3: FR-1, 800-53 AC-3, RE-1 and RE-2 with security strength 1 (note, reserved

 

for possible total system failure)  

3361 3362

= 4: FR-1, 800-53 AC-3, RE-1 and RE-2 with security strength 2 (note, reserved for possible total system failure or loss of life)

3363 3364

This example illustrates the caveat which states that RE-1 and RE-2 may not provide  sufficient discrimination to differentiate between  assignments. Furthermore, the

3365 3366 3367 3368 3369 3370 3371

aggregation of  =1, 2, 3 or 4 contributed by each zone, conduit, or class of device shown above depends on the implementation of ISA-99.03.02 (security assurance levels for zones and conduits), ISA-99.01.03 (system security compliance metrics), ISA-99.03.04, ISA99.04.01.. 04 (derived requirements for classes of components). Is important to remember that allocation of system security assurance to zones, conduits and classes of components, as well as aggregation of security assurance provide by elements of the SuC are not within the scope of ISA-99.03.03.

3372

C.1.3

3373 3374 3375 3376

Based on a review of company policies and procedures it was determined that the organization explicitly defines privileged functions and security-relevant information for the IACS. Furthermore, the organization explicitly authorizes personnel access to privileged functions and security-relevant information in accordance with organizational policy. And, the

3377 3378 3379 3380

IACS restricts access to privileged functions (deployed in hardware, software, and firmware) and security-relevant information to explicitly authorized personnel (e.g., security administrators). Lastly, automated test mechanism implementing access enforcement policies are widely deployed.

3381 3382 3383 3384 3385 3386

For these reasons, access enforcement requires security assurance which is constrained by the need to ensure IACS operational availability, comply with the need to ensure public and environmental safety, guard against total system failure and to guard against the possibility of loss of life. Based on the installed security architecture, the asset owner now states for the ℎ example, the following achieved system target security levels (  ) which are subject to verification:



Achieved security assurance level

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA-62443-1-1, D5E4, August 2015 3387 3388

ℎ  = 1:

3389 3390

ℎ  = 2:

3391 3392 3393 3394

ℎ  = 3:

3395

ℎ  = 4:

3396 3397 3398 3399

– 96 –

ISA99, WG03

IACS security functions are not mission critical and are not the target of adversarial threats. IACS security functions a re not mission critical, but are the target of adversarial threats. IACS security functions are mission critical, are the target adversarial threats, do not require immediate response, but disruption could result in significant performance and financial impact resulting from the total failure of IACS operating capability.

of

IACS functions are mission critical, are the target of adversarial threats,

but require immediate response to ensure public and environmental safety resulting from the total failure of IACS operating capability or loss of life. Furthermore, the asset owner states that all metrics for this example are subject to the following considerations:

3400 3401

ℎ Al l  = 1 metrics are limited to applications related to protection of company data.

3402

ℎ Al l  = 2 metrics are limited to applications subject to threat.

3403 3404

ℎ Al l  = 3 metrics are applicable to performance constrained mission critical applications that can result in total system failure.

3405 3406

ℎ Al l  = 4 metrics are applicable to mission critical applications that can result in loss of life.

3407

C.2 System security assurance

when commission ed

3408

Subject to all conditions described in

3409 3410

ℎ implemented and site acceptance testing is complete, the achieved system security assurance level is all  (t 0 ) = 4.

3411 3412 3413 3414 3415 3416

In retrospect, the Asset Owner’s senior management could have stated that their goal was to  design and install a security architecture that could be rated  (t 0 ) = 4. Then, when the design was complete, by analysis the system integrator could state that the build-to system  security assurance is  (t 0 ) = 4. As a cross check the system integrator could sum the contribution of each zone and conduit security assurance using the calculation procedure specified in ISA-99.03.02.

3417

C.3 System security assurance during after

3418 3419 3420 3421 3422 3423

If security is maintained in accordance with ISA-99.02.02 and quantitative metrics described in ISA-99.01.03 are collected and automatically processed in a timely manner, the measured system security assurance can be assessed on a regular basis using the same procedures  described in C.2. The result should be labelled  (t) = f(processed metrics). When   (t) degrades to an unacceptable level (a value determined by the Asset Owner), corrective action is required to plus-up the system security assurance. Guidance for plus-up

3424 3425

action is described in ISA-99.01.03 for each system metric.

C.1.3, when the security architecture has been

commissioning

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA99, WG03

– 97 –

ISA-62443-1-1, D5E4, August 2015

Annex D (informative) Understanding ho w to use the IS A99 adaptation of the IEC styleguide

3426 3427 3428

Overview

3429

D.1

3430 3431 3432 3433

Annex D contains some notes that have been collected while going through the process of converting documents from the older ISA format to the newer IEC format. Please read through them to understand the basic style and formatting that should be applied to documents as they are being developed for the ISA99 committee.

3434 3435 3436 3437 3438

ISA has adopted the IEC styleguide [15] to format its documents from now on. ISA99 has found that not all of the appropriate formatting and text guidelines necessary to avoid editorial comments from IEC members are included in the styleguide. The following sub-clauses include discussions of different general practices that should be applied to all current and future ISA99 documents.

3439

D.2

3440 3441 3442 3443 3444



ALWAYS, ALWAYS, ALWAYS use styles to format text. Avoid u sing simple font formatting unless it is for a single word or a couple words. Use the IEC styles for their correctly named purpose. If you need another style that uses the same format as an existing style, but for another purpose, then use Word’s feature to create a new style based on another style. Do not modify the IEC styles unless you know what you are doing.

3445 3446 3447



Blocks of text should be positio ned with textboxes and not with returns/line breaks. This ensures that text appear correctly on each person’s computer regardless of the differences related to fonts.

3448



Document p roperties should be used for many of the standard items. The document items

Document and page formatting

3449 3450 3451

should non-breaking spaces and non-breaking Microsoft Word so doesn’t seem toutilize allow you to copy these non-breaking charactersdashes. into the document properties, you will have to type them in directly.

3452

The following is a list of the recommended list of properties:

3453

–

Title

3454

–

Subject

3455

–

Author

3456

–

Company

3457

–

VerNo

3458

–

DraftNo

3459

–

EditNo

3460 3461

– Date completed year)

3462

–



“Security for industrial automation and control systems” 







Draft number (rev’e d for each voting draft)

Edit number (rev’ed periodically as edits and comments are incorporated)

Publisher 

“ISA”

Version number (if there are multiple versions)



StdNo ComNo

Specific name of the document

Editor’s name and affiliation







Date the version/draft/edit was completed (minimum month and

“ISA”

3463 3464

– –

Currently “99”, but will need to change “99”

3465

–

WrkGrpNo



2-digit version of working group number

3466

–

TskGrpNo



2-digit version of task group number (if applicable)

3467 3468

–

SeriesNo SeriesNo)

3469 3470

–

PartNo  Document part number within the series (For example, ISA-99.02.01, where 01 is the PartNo)

3471

–

DOC-01-01

3472

–

…





to “62443 ” soon

Document series number (For example, ISA-99.02.01, where 02 is the



ISA-99.01.01

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA-62443-1-1, D5E4, August 2015 3473

–

DOC-XX-YY



ISA-99.XX.YY

3474

–

DOC-Series



“ISA -9 9”

3475



– 98 –

ISA99, WG03

Document draft and edit numbers should be used.

3476 3477 3478

–

3479 3480 3481

–

3482 3483 3484

Draft numbers represent the voting version of the document. Each time a voting draft goes out for comment/vote, the draft number of the next version should be incremented. Edit numbers are incremented as “significant” cha nges are made to the document. This could be periodically or it could be based on the amount of content added. It allows the document to be tracked without too much difficulty. The “significant” period or content amount is left up to the working/task group, but should allow someone new to the group to understand most of the current state of the document without having too much additional material to absorb.

3485 3486 3487 3488 3489

 The Table of Contents should be added using the pre-defined IEC macro. This will automatically populate the table of contents, table of figures, and table of tables. Some documents do not include any figures or tables, so when the document goes for voting/comment drafts, it may be necessary to delete the unused table (for the ISA version).

3490

D.3

3491 3492



These items come out of the IEC styleguide, but aren’t always very o generating a document.

3493 3494 3495 3496



All text paragraphs need to have some way to reference them. This means that there c an be no hanging paragraphs. This includes things like emphasizing the base requirements or requirement enhancements by making them bold/underline instead of giving them their own heading designation.

Sectioning

INCORRECT

4.

EXAMPL

E

Section title

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Etiam faucibus arcu in lorem dapibus bibendum. 4.1

Subsection title

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

4.

Section title

4.1

Overview

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Etiam faucibus arcu in lorem dapibus bibendum. 4.2 Subsection title In augue sem, tincidunt in, tristique quis, dapibus eget, neque. Suspendisse potenti. In suscipit lacus molestie odio.

3497

bvious when

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA99, WG03 3498



– 99 –

ISA-62443-1-1, D5E4, August 2015

Section headings cannot g o 3 deep in a single series. INCORRECT

EXAMPL

E

4.

Section title

4.1

Subsection title

4.1.1

Sub-subsection title

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

4.

Section title

4.1

Overview

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Etiam faucibus arcu in lorem dapibus bibendum. 4.2

Subsection title

In augue sem, tincidunt in, tristique quis, dapibus eget, neque. Suspendisse potenti. In suscipit lacus molestie odio.

3499 3500



3501

D.4

3502



Figures should always b e gene rated at 100% s caling wit h all fonts at 8pt.

3503 3504



ISA99 generally uses Microso ft Visio 2003 or newer to generate graphics, although programs are acceptable.

3505 3506 3507



For Visio graphics, save the graphic as a Windows Meta File (WMF) first, then insert it into the Microsoft Word file. This seems to be more stable and less prone to conversion issues than inserting a Microsoft Visio object directly.

3508 3509 3510



Avoid generating bitmap fi les (PNG, JPG, G IF, etc.) for li ne- art graphics unless a bsolutely necessary. These file formats rasterize the line art graphics, so they can’t be blown up or zoomed properly in print copies or PDFs of the document.

3511

D.5

3512 3513

 Tables should always u se the pre-defined IEC sty les for tables unle ss absolutely necessary.

3514



3515 3516

IEC limits section numbering to 6 levels deep, although we have generally tried to sti ck to at most 5 levels (a remnant of the srcinal ISA document styleguide).

Figures other

Tables

Large tables may need to have the page rotated to v iew properly. There is an IEC macro to rotate the page to landscape . Try this first. If that doesn’t work pro perly, generate a new section and add in a textbox to display the page numbering and other header information.

3517 3518 3519 3520 3521 3522 3523



Tables that e xtend over more than 2 page s need to have a title on the top of each page reflecting the table name and the table title. There are multiple ways to accomplish this. You can break the table itself at the page break and then add table headers for each new table. The preferred way would be to break the table after the first page, add in an additional header row to the second page with the “(continued)” line in the title, and then repeat the title and normal header rows from then on. This will auto-populate the title on each subsequent page.

3524 3525 3526



Don’t allow rows to break across pages. This is not an absolute requirement, but annoys many people when reading documents. It is an easy fix and keeps all the content for a particular item easily viewable.

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA-62443-1-1, D5E4, August 2015

– 100 –

ISA99, WG03

3527

D.6

Wording and language recomme ndations

3528



3529



Do not use contractions. Use should not

3530



Use formal l anguage. Do not use informal o r colloquial sayings, u nless necessary.

3531 3532



Do not u se first or second person terms like I, we, us, y ou, etc. It is improper in some cultures to speak to others that you do not know using these types of terms.

3533 3534



Use standard-eeze, requirement-style supplemental guidance.

Use a single space between sentences. instead of shouldn’t.

language in both the normative requirements and in

3535 3536

–

The word “must” connotes an absolute necessity like the law of gravity. be used as such.

3537 3538

–

Terms like “shall”, “should”, and “may” are the recommended forms of requ style language. “Needs to” is also another one that seems to be acceptable.

It should only irement-

3539 3540 3541



3542



Don’t use e.g. or i.e. Use t

3543 3544 3545 3546



Once an acronym has been defined in the normative sections of the document (starting with clause 1), avoid reusing the text form of the term again. Also, don’t redefin e the term again. Terms defined in the preface, forward, or clause 0 should still be defined in clauses and annexes that follow.

3547 3548



Don’t over -capitalize words. There is a tendency to capitalize words to connote emphasis. Words should not be capitalized unless they are names or specific terms used in industry.

3549



ISA99 references the committee, ISA-99 references

3550 3551

Statements like “this person is going to do that action” should not be used. It should be rephrased as “this person needs to do that action” or “this person should perform action”. erms like “for example” and “such

using these in the document and in communications.

that

as” instead.

the docu ment series. Be care ful when

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA99, WG03

– 101 –

ISA-62443-1-1, D5E4, August 2015

3552

BIBLIOGRAPHY

3553 3554 3555 3556 3557

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 referen ces 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.

3558

References to other parts, both existing and anticipated, of the ISA

3559 3560

NOTE Some of these references are normative references (see Clause 2 ), published documents, in development, or anticipated. They are all listed here for comple teness of the anticipated parts of the ISA ‑ 62443 series.

3561 3562

SKELETON N OTE reference thi s reference documentfrom below, change the documen “This standard is …”.For Youthe can’t have ato circular a document to itself.

3563 3564

[1]

ANSI/ISA ‑ 62443-1-1-2007, Security for industrial automation and control systems: Terminology, concepts and models

3565 3566

[2]

ANSI/ISA ‑ TR62443-1-2, Security for industrial automation and control systems: Master glossary of terms and abbreviations

3567 3568

[3]

ANSI/ISA ‑ 62443-1-3, Security for industrial automation and control systems: System security compliance metrics

3569 3570

[4]

ANSI/ISA ‑ 62443-2-1-2009, Security for industrial automation and control systems: Establishing an industrial automation and control system security program

3571 3572

[5]

ANSI/ISA ‑ 62443-2-2, Security for industrial automation and control Operating an industrial automation and control system security program

3573 3574

[6]

ANSI/ISA ‑ TR62443-2-3, Security for industrial automation and control systems: Patch management in the IACS environment

3575 3576

[7]

ANSI/ISA ‑ TR62443-3-1-2007, Security for industrial automation and control systems: Security technologies for industrial automation and control systems

3577 3578

[8]

ANSI/ISA ‑ 62443-3-2, Security for industrial automation and control systems: Target security assurance levels for zones and conduits

3579 3580

[9]

ANSI/ISA ‑ 62443-3-3, Security for industrial automation and control systems: System security requirements and security assurance levels

3581 3582

[10]

ANSI/ISA ‑ 62443-3-4, Security for industrial automation and control systems: Product development requirements

3583 3584

[11]

ANSI/ISA ‑ 62443-4-1, Embedded devices

3585 3586

[12]

ANSI/ISA ‑ 62443-4-2, Security for industrial automation and control systems: Host devices

3587 3588

[13]

ANSI/ISA ‑ 62443-4-3, Security for industrial automation and control systems: Network devices

3589 3590

[14]

ANSI/ISA ‑ 62443-4-4, Security for Application , dat a and fu nctions

3591

Other standards references:

3592 3593

[15]

3594

ISO/IEC Directives, Standards

Security

Part 2,

for

industrial

industrial

automation

automation

62443 series:

t reference to a note stating

and

and

control

control

systems:

systems:

systems:

Rules for the structure and drafting of International

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA-62443-1-1, D5E4, August 2015

– 102 –

ISA99, WG03

3595 3596 3597 3598 3599

SKELETON NOTE Any th ing tha t can hav e an ISO /I EC, NATO, etc . num ber sho ul d be inc lud ed in th e “Ot he r standards references” section. For ISA documents, these should receive their ISA numbers if they have them, otherwise , use the international numbering. For IEC versions of the documents, these numbers should be replaced with their international number equivalents. (For example, ANSI/ISA-95.00.01-2000 would be replaced by IEC 62264-1 in the IEC version.)

3600

In addition to the two sections of references above, you can also have other sections like:

3601



Industry-spe cific and sector-sp ecific references

3602 3603



Other documents and published sources  National/government documents or any other published resources . NIST FIPS/SP documents fall into this category.

3604



3605

Websites



Full sites or pages



Trade organization documents and such.

within specific sites containi

ng reference material.

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T

ISA99, WG03

– 103 –

ISA-62443-1-1, D5E4, August 2015

3606 3607 3608 3609

Developing and promulgating technically sound consensus standards and recommended practices is one of ISA's primary goals. To achieve this goal the Standards and Practices Department relies on the technical expertise and efforts of volunteer committee members, chairmen, and reviewers.

3610 3611 3612 3613 3614

ISA is an American National Standards Institute (ANSI) accredited organization. ISA administers United States Technical Advisory Groups (USTAGs) and provides secretariat support for International Electrotechnical Commission (IEC) and International Organization for Standardization (ISO) committees that develop process measurement and control standards. To obtain additional information on the Society's standards program, please write:

3615 3616 3617 3618 3619 3620

ISA Attn: St andards Departm ent 67 Alexander Drive P.O. Box 12277 Research Triangle Park, NC 27709

3621 3622 3623 3624 3625 3626 3627 3628

ISBN: -to-be-assigned-

. e ict o n t u o th i w e g n a h c to tc je b su is d n a te e l p m o c f o te a r u cc a e b t o n y a m It tc.

. tcs u d o r p kr o w e e tit m m o c f o t n e m p lo e v e d r e h rt fu f o tr o p p u su d ro in p kr w i o e w vre e f e tti o e m so mp r o c u 9 p 9 e A h t IS r n fo a Y f o L E T L F O A S R d D e iv Gd IN ro K p R s O tiI W a si t n e m cu o d si h T

. e l a s r fo r o n o tci u d ro p re r e trh u f r o f d e r e ff o r o , rs e h t o to d te u ib trs i d , d ie p o c e b t o n y a m t n e m u c o d si h T