DISCUSSION PAPER

Secure implementation of OPC UA for

operators, integrators and manufacturers
Imprint

Publisher
Federal Ministry for Economic
Affairs and Energy (BMWi)
Public Relations
11019 Berlin
www.bmwi.de
Text and editing
Plattform Industrie 4.0
Bertolt-Brecht-Platz 3
10117 Berlin
Design and production
PRpetuum GmbH, Munich
Status
April 2018
Printed by
MKL Druck GmbH & Co. KG, Ostbevern
Photos and illustrations
BlackJack3D – gettyimages (title), sdecoret – Fotolia (p. 6),
patpongstock – Fotolia (p. 8), zapp2photo – Fotolia (p. 9),
NicoElNino – Fotolia (p. 13), Gorodenkoff – Fotolia (p. 21),
Sikov – Fotolia (p. 23), kras99 – Fotolia (p. 24)
This and other publications are available from:
Federal Ministry for Economic Affairs and Energy
This brochure is published as part of the public relations work Public Relations
of the Federal Ministry for Economic Affairs and Energy. It is E-mail: [email protected]
distributed free of charge and is not intended for sale. The dis- www.bmwi.de
tribution of this brochure at campaign events or at information
stands run by political parties is prohibited. No political party-­ Central procurement service:
related information or advertising may be inserted in, printed Telephone: 030 182722721
on or affixed to this publication. Fax: 030 18102722721
2

Content

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

The importance of OPC UA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

OPC UA in M2M communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Consideration of security requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Content and aim of this discussion paper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Information security management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Threat analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Protection goals and guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Detection and response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Component and system security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Application scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Application of OPC UA in the scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12

Examination over the lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Taking possession . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Commissioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Integrator’s preparation of handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Takeover during commissioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Operation and security maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Decommissioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Disposal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Contingency measures/restoration of operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

 CO N T E N T 3

Solution sketch/discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Anticipating repetitive sketches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Security domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Provision of authentication criteria (e. g. trust lists) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Provision of identities (certificates and key pairs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Authorisation of communication and interaction partners (partners) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Summary and outlook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

List of illustrations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Appendix: Collaborative Factory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Machines in the “Operator Model” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Cloud services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41

Other companies involved . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4

Introduction

The innovative concepts and procedures of the Fourth Consideration of security requirements
Industrial Revolution (Industry 4.0) are creating entirely
new possibilities for cooperation – especially on a technical Software and network communications are already being
level. Systems, machines and products interact, exchange extensively used today for tasks with increasingly more
data and information, communicating with each other all open security domains in automation. That’s why security2
the while. It makes no difference whether communication aspects must also be taken into account in order to meet
takes place with a machine in the same factory hall or with the resulting protection requirements. Although no new
a system in a plant on the other side of the world so that threats are generally expected, the now necessary opening
the boundaries for trust are exceeded. However, this can of perimeter protection, i.e. protection on the perimeter of
only work if technical communication mechanisms ensure the security domain, means a larger attack area. When it
that Industry 4.0 components (assets) can communicate in comes to critical infrastructures, operators are therefore
a secure and interoperable manner (1) and thereby enable now required to take security measures to ensure provi-
trust across company boundaries. sioning. In industrial automation, security awareness also
grows as network-based communication increases. With
the goal of smart production in Industry 4.0 and the associ-
The importance of OPC UA ated communication between IT, production, assets, com-
ponents and products, security is an elementary part of
OPC UA (OPC1 Unified Architecture) is an architecture used concepts, as is also described in the implementation strat-
to describe and exchange machine data. In this respect, egy (2).
OPC UA is more than just a communication protocol – the
architecture also includes data models and interaction con- Established standards and norms describe the technical
cepts. OPC has been successfully used in automation tech- and organisational measures that form the basis for secure
nology for some time now. The further development of use, see the section on “Security”. The requirements of
OPC UA is today widely supported; it has been recom- these standards and guidelines must be implemented in
mended as an important technology in the implementa- practice so that secure application of the OPC UA standard
tion strategy of the Industry 4.0 platform (2) and is part of is possible. The OPC UA standard offers many solution con-
the “Criteria for Industry 4.0 Products” of the ZVEI manu- cepts and ideas. What’s important now is to describe how
facturers’ association (3). This paper focuses accordingly the individual aspects have to interact in order to achieve
on OPC UA. the goal of secure use.

OPC UA in M2M communication Content and aim of this discussion paper

Work to standardise machine-to-machine communication The aim of this discussion paper is to highlight the require-
has been underway for several years and at times parallel at ments for the secure use of OPC UA for communication in
various organisations, such as the OPC Foundation, IETF, Industry 4.0 scenarios, to present implementation options
oneM2M, OASIS, NIST, ITU, to mention but a few. This has and to identify points for discussion. The integration of a
resulted in different architectures, protocols and security machine into an operator’s infrastructure over its lifecycle
concepts with different functionalities. will be used as an example.

1 OPC: Originally “OLE for Process Control”, today “Open Platform Communications”
2 Always short for IT security in this document
 INTRODUCTION 5

The aim is to provide the stakeholders, manufacturers, This paper is based on the OPC UA standard, version 1.04,
integrators and operators involved with specific informa- which offers significant further developments, especially
tion about the necessary functions and measures and to for security. However, it can be assumed that the imple-
describe best practices. At the same time, the analysis mentations and development tools available on the market
should show the extent to which the implementation of are not yet at this level. One aim of this paper is to support
the security measures will lead to even more far-reaching providers and users during the transition.
requirements that call for additions to the OPC UA stand-
ard or to existing toolkits and products. The goal here is to This paper is meant for technically experienced readers,
cover as many aspects as possible with OPC UA only, so ideally with experience in the application of OPC UA.
that no further requirements have to be fulfilled, for
instance, by an additional interface such as web-based
management. Therefore, both configuration and parame-
terisation must have a uniform design across corporate
boundaries. This approach will improve consistency and
interoperability.
6

Security
 SECURITY 7

Security is a holistic issue that can only be achieved when • Integrity: Ensuring the correctness (integrity) of data
all stakeholders work together. The relevant standards for and the correct functioning of systems
industrial automation, IEC 62443 (4) and the German VDI
2182 (5), therefore always consider interaction between • Availability: Services, functions, information can always
operators, integrators and manufacturers. be used as intended

Further protection goals are formulated, for example, based

Information security management on data protection aspects, such as the European General
Data Protection Regulation (EU GDPR). In technical terms,
The security requirements for secure operation must be these requirements can be mapped to the primary protec-
based on the operational framework, see also “IT-Security tion goals. This document restricts itself to the primary
in der Industrie 4.0 – Handlungsfelder für Betreiber” (6). protection goals related to communication processes. It does
Corresponding information security management systems not examine further implementation, for instance, in the
(ISMS) are described in ISO 27000 (7) and IEC 62443-2-1 (4). form of data storage in a device.
Which threats exist for data and systems can only be deter-
mined specifically, depending on the application. To achieve When it comes to selecting and implementing measures,
a multi-stakeholder approach, as discussed later and shown the options available often have to be weighed up.
in Figure 2, the requirements of all stakeholders must be Encrypted communication protects against eavesdropping
taken into account and this can lead to conflicting goals. (protection goal: confidentiality), but makes troubleshoot-
ing (protection goal: availability) and monitoring of com-
munication more difficult. Therefore, security measures
Threat analysis should be selected according to the given requirements.
In an internal automation network with less powerful
Identifying a company’s assets to be protected forms the components, encryption may not be necessary as integrity
basis for the threat analysis. In the case of an operator, protection is technically possible independent of this. Con-
these typically include know-how, system availability, pro- fidentiality is additionally relevant when information is
duction efficiency and product quality. The document exchanged using unprotected networks. Secure communi-
“Integrität von Daten, Systemen und Prozessen” (8) cation protocols typically offer the “Integrity protection”
addresses the frequently underestimated importance of the (with OPC UA: “Sign”) and “Confidentiality Protection +
integrity protection goal as a prerequisite. Once the com- Integrity Protection” (with OPC UA: “Sign and Encrypt”)
pany assets to be protected have been identified, threats, options.
such as loss of know-how or production disruptions, can
then be described.
Detection and response

Protection goals and guidelines In security management, it can be generally assumed that
100% security is simply not possible. In addition, mechanisms
Once the threats have been identified, the protection goals must be in place to detect attacks, such as event logging
are formulated accordingly and measures are taken based and communication inspections, along with emergency
on the severity of impact and the assumed probability. The and recovery concepts.
primary protection goals are:

• Confidentiality: Protection against unauthorised

disclosure of information
8 SECURITY

Component and system security NAMUR recommendation NE 153 (9) concisely describes
the four aspects of component and system security:
Various parts of IEC 62443 (4) describe the requirements for
security functions, such as user management, integrity pro- • Security by Design: Security must be included in the
tection, secure storage of electronic keys and logging, as design stage
well as requirements for processes in the integration and
development of components. The security functions are • Security by Implementation: Security as a feature by
classified as “Security Levels”, from SL-1 to SL-4, which are avoiding errors as far as possible
designed to express the system’s strength of resistance. The
security level is also determined in the threat analysis. It is • Security by Default: A secure status should always be
important to bear in mind that security not only means the the basic setting, no retroactive hardening
existence of functions, but also requires the application of
development and integration processes that have been • Security in Deployment: Secure operations through
designed on the basis of security aspects. security documentation and product maintenance
 9

Application scenario
10 A P P L I C AT I O N S C E N A R I O

The “Collaborative Factory” scenario is used to illustrate Figure 2 shows the logical communication relationships of
such an application. This Industry 4.0 scenario shows the the machine. On the one hand, the machine must be inte-
integration of different machines into a factory with con- grated into the production process and hence interact with
nections to cloud solutions and other external companies the operator’s systems. It must be possible to not only man-
(Figure 1). An overview of the application scenario can be age production orders but also to collect operating data and
found in the appendix. Communication within a compa- handle alarms. This communication relationship, marked
ny-wide network poses a multitude of demands for secure with a green arrow in Figure 2, is the focus of this discussion
design. These requirements and approaches are already paper.
discussed in the technical overview entitled “Sichere unter­
nehmensübergreifende Kommunikation” (10). In an extended examination, interaction between the
machine and an external service provider must be taken
For the purposes of this document, only the integration into account, which is indicated by a red arrow in Figure 2.
of machine A into an operator’s infrastructure is to be This service provider could be the integrator or machine
examined, see box in Figure 1. The machine is seen as a designer himself, who would only access the machine for
unit that must interact with its environment. The machine remote maintenance purposes (“condition monitoring”)
design is irrelevant here. or, in the operator model, could even actively parameterise
the machine.

Figure 1: Overall “Collaborative Factory” scenario

Enterprise
External Cloud

Enterprise Component Manufacturer

Internal Cloud

Internal Cloud

DMZ
Enterprise Operator 2

Internal Cloud

Machine A Maschine B
IoT - Gateway IoT - Gateway

Local Switch Local Switch

Source: Plattform Industrie 4.0

 A P P L I C AT I O N S C E N A R I O 11

Figure 2: Logical interfaces of machine A

Integrator A Component Component

Process data Operator
(Service Provider)
Alarms/events manufacturer 1 manufacturer 2 MES/ERP
Updates
Parameterisation
OPC UA

Production order
Machine A Batch process
IoT-Gateway (recipe)
Alarms/events
OPC UA

Operating data
Local Switch Alarms/events
Updates
Parameterisation
No contractual
relationship between
component manufacturer
and operator
Therefore, the service
provider must be
responsible for
communication

Source: Plattform Industrie 4.0

This document, however, does not examine the special fea- Therefore, OPC UA is to be used in this paper to integrate a
tures that result from this, such as possible requirements new machine into the operator’s systems. The machine is
for monitoring of communications by the operator. Other integrated within a local network controlled by the operator.
options, such as individual communication between indi- This document focuses on this local integration which targets
vidual machine components and their manufacturers, are the operator’s security domain.
not examined either.
The logic connection to the external service provider is a
The discussion in this document refers to the logical com- remote connection. It is possible here that communication
munication relationships, i. e. information exchange. The may run physically through the operator’s network and then
underlying transmission technologies used (wired, wireless, via the Internet to the service provider. This enables efficient
short or long distance) were not considered. use of existing resources. This design also allows the opera-
tor to monitor and influence communication. A dedicated
connection via separate Internet connectivity is also con-
Application of OPC UA in the scenario ceivable, with would reduce interaction in the operator net-
work. In any case, communication is established between
It is widely expected that OPC UA will play a key role in the operator’s security domain and that of the service pro-
the connected industry, since the exchange of parameters, vider. That’s why the security measures of the stakeholders
operating data and alarms is one the main features of must be coordinated and taken into account in the respec-
OPC UA. tive security management system, see technical overview
12 A P P L I C AT I O N S C E N A R I O

entitled “Sichere unternehmensübergreifende Kommu- • Commissioning of the system by the operator

nikation” (10). This communication relationship will be
addressed in a future follow-up paper. • Operation and maintenance

The following section restricts itself to discussing the • Decommissioning of the system or system components
secure use of OPC UA. The quality of the implementation,
for example, through a secure development process • Disposal after final decommissioning
(Security Development Lifecycle, SDL) and other security
functions are not included here. In principle, the analysis is first generic, since the stakeholders’
specific protection goals are not known. All possible require-
ments must therefore be examined at the highest security
Lifecycle level in order to ensure that all the necessary protection
goals can be achieved. In addition, the requirement level is
In order to be able to analyse the stakeholders’ security looked at independent of the technologies used.
requirements for the machine to be integrated, the lifecycle
is examined, beginning with the provision of the necessary An analysis of the first part of the lifecycle, taking possession
components and ending with the decommissioning of the and integration of components into a system, can already
machine (see Figure 3). The phases explored here are: be found in the paper entitled “Security der Verwaltungs­
schale” (11).
• Provision and ownership of a component

• Integration of several components into a system

(e. g. a machine or (sub-)system)

Figure 3: Lifecycle phases

Integrator Operator
Start

Commissioning
Taking possession engineer
Commissioning

Integration

Operation and Contingency measures/

maintenance Restoration

Hand over?
Yes
No
Decommissioning

Continue Yes
use?
Yes Return?

No
No
Disposal
Disposal

Stop
Stop

Source: Plattform Industrie 4.0

 13

Examination over the lifecycle

14 E X A M I N AT I O N O V E R T H E L I F E C YC L E

The security requirements for a component are examined First of all, it must be ensured that the component is an orig-
on the basis of the lifecycle phases described above in addi- inal component and that neither hardware nor software
tion to a section for contingency and restoration measures. (including firmware) have been manipulated. While the
authenticity of hardware can be verified on the basis of its
At the end of each phase, the security requirements identi- physical features, such as holograms, software and firmware
fied in the document are summarised and repeated in can be checked on the basis of code signatures.
abstract form.
In addition or alternatively, the authenticity of the compo-
A solution is subsequently sketched highlighting both the nents and their firmware can also be verified via the network.
requirements that can already be fulfilled with means This enables work processes in which different persons are
according to the OPC UA standard and/or sensibly using responsible for physical assembly and taking possession.
other customary measures as well as the areas where the Each component should have an individual certificate issued
need for discussion becomes apparent. by the manufacturer. By using the pertinent private key,
the device then confirms that its state is the state that has
During the discussion on the lifecycle, the need for identi- been defined as authentic by the manufacturer. There are
ties from different sources already becomes apparent. In two ways to verify whether this certificate is valid: 1.) If the
order for them to be kept apart, the sources are described certificate issued by the manufacturer is issued by a root
here first, i. e.: Certification Authority (root CA), the entire certificate chain
must be checked. 2.) If the certificate is individually self-
1. identities issued by the component manufacturer signed, the manufacturer must provide the certificate finger­
(e. g. ZHN manufacturer certificates), print separately for comparison. This fingerprint must reach
the customer via a different channel than the component
2. identities assigned by the integrator itself, e.g. by publishing the fingerprint on the manufactur-
(e. g. ZIN certificates), er’s HTTPS secured website. Sending the fingerprint in the
instructions for the component or in test software on a CD
3. optional identities valid in the system included in the scope of delivery is not secure enough and
(e. g. ZAN certificates) and an attacker could change both (device and documentation/
test software) during delivery.
4. identities issued by the operator
(e. g. ZBN certificates). Hybrid forms of these two variants are conceivable for veri-
fying the certificate issued by the manufacturer. For exam-
ple, to save costs, the manufacturer himself can operate the
Taking possession root CA for the device certificates issued by him. In this case
and using a separate channel, the manufacturer only needs
Taking possession of a component is understood to be the to provide the fingerprint for the root certificate created by
first-time use by an integrator or directly by the operator. him. The fingerprint is then the same for many devices, for
The integrator takes a generic component and configures example, all the devices of a series or even all of the manu-
it to gain exclusive control over it. This is carried out, for facturer’s devices.
example, by replacing default passwords or uploading inte-
grator certificates. In abstract terms, these are the identity The private key that belongs to the public key of the certifi-
information and authentication criteria used by the com- cate must be kept locked. Ideally, this is carried out using
ponents to verify the identity of their communication part- secure hardware, a so-called “secure element”. All operations
ners. on the private key then take place in the secure environment
of the “secure element”.
First-time use of a component can refer to a brand new
component or to a component that has been reset to fac- To ensure that no manipulation has taken place here, the
tory settings (and is therefore equivalent to a brand new integrity of the “secure element” should be checked, if pos-
component in terms of its configuration). sible, when it is taken into possession. There are also proce-
dures for this that can be carried out via the network.
 E X A M I N AT I O N O V E R T H E L I F E C YC L E 15

Even if there are reasons not to use a secure element, the Integration
use of asymmetric key pairs of public and private keys offers
added security. If a component does not even have the After possession has been taken of the individual compo-
resources to use asymmetric key pairs, other components nents, the integrator combines them to produce an overall
can be used as relays. In a small, relatively separate area, for function. The integrator establishes both a logical and a
instance, a relaying component can use asymmetric key physical relationship between the components and models
pairs and communicate on behalf of the other components the behaviour of the individual components required for
that have no key pairs. In this case, communication with the overall function. The processes in this step are especially
the other components beyond this point should be carried relevant for security, since both the relationships between
out via a medium with suitably restricted access. the individual components and the function of the individ-
ual components are decisive for the resultant secure and
An important part of a component’s security is its secure correct operation of the machine or system. In particular,
configuration. When a component is delivered, its default the following particularly security-critical processes can be
configuration should be parameterised as securely as possi- identified during the integration phase:
ble in order to prevent attacks during taking possession or
insecure subsequent configurations due to operating errors. a. Definition of the digital identities of the respective
This is also known as “Security by Default”. For OPC UA individual components.
communication, for example, the None security policy would
have to be excluded, i.e. it should not be offered. If the highest b. Modelling and implementation of the relationships
security level is not required for an application, the compo- between the component and other entities, such as
nent should ensure that the change in configuration is sub-
ject to authorisation which in turn requires a graded rights 1. other devices and software processes inside and
access control concept. It must also be possible to reset the outside the machine or system and
configuration of the component to (secure) factory settings.
2. persons acting in a certain function.
The security requirements for a component are therefore
as follows for taking possession of a component: c. Setting (parameterisation) of access control mechanisms
according to the model of relationships between the
1. It should be possible to verify the authenticity of the component and other entities.
component on the basis of a certificate from the man-
ufacturer. d. Control of access to internal device features and func-
tions with the aim of protecting business secrets which
2. It should also be possible to reset all component settings the integrator brings to the machine or system.
to the manufacturer’s factory settings.
When relationships are established between individual com-
3. The basic configuration should have a secure design and ponents and other entities, both the functions of the devices
the device should be delivered with a secure configura- and the resulting access rights of individual devices and
tion, making an attack during commissioning unlikely. software components must be defined in relation to each
other. Unambiguous and reliable component identification
4. The integrator should be able to define all of the authen- and referencing is an important basis for modelling com-
tication criteria used by the component to verify other ponent relationships. This can be based on secure digital
identities. These include all passwords and all certificates identities (e. g. digital certificates and hardware support).
that the component trusts, except for a few certificates A digital identity can be assigned to a component either
that are intended by the manufacturer for special pur- via a public key infrastructure (Certification Authority and
poses, such as authentication of firmware updates. issuance of certificates) or by manually configuring certifi-
cate-based identities on the respective components. It should
be noted that the identities are assigned either within the
system itself and/or by the integrator. If the identity of the
manufacturer were used to establish the relationship, this
16 E X A M I N AT I O N O V E R T H E L I F E C YC L E

might enable an attacker to later infiltrate the system by With more complex systems and machines where a large
replacing the device with a device purchased and parame- number of access rights must be configured similarly or
terised by the attacker that also has a valid manufacturer’s identically for other different components or persons, role-
certificate. based or attribute-based assignment of rights makes it easier
to manage these access rights. This means that rights can
Once the devices have been given a secure identity (ZIN be defined for a role (e.g. maintenance staff, operator, mon-
certificate including public/private key), trust relationships itoring, etc.) or for the owner of attributes (e. g. affiliation to
between these devices can be modelled. This is carried out the company and responsibility for maintenance). What’s
by including the identity of one device in the trust list of special here is the implementation of the rights specification
another device. Alternatively, the identity of a Certification without already defining the specific digital identity in the
Authority (CA), which can authenticate other digital identi- integration phase. Role affiliation or attributes must then
ties, can be included in a trust list of a component. In the be assigned to an identity using suitable measures during
latter case, all identities issued by the CA are trusted and operation (e.g. based on a central authentication system in
this reduces the configuration effort needed because the the operator’s environment). The integrator can then provide
certificates to be checked no longer have to be explicitly for certain interaction patterns which the operator later
included by other devices. Direct inclusion of identities in assigns to specific individual identities.
the corresponding trust lists or inclusion of a Certification
Authority determines the components which the integra- The security requirements for integration of a component
tor basically provides for interaction. Each component are therefore as follows:
should be configured to interact with a minimum number
of other components. This reduces the possibilities for an 1. It should be possible to assign an integrator-specific
attacker after a single component has been compromised. identity with a pertinent ZIN certificate to the
component.
After the permitted communication relationships have been
configured, the access rights of the respective components 2. For the purpose of communication in the system,
must be modelled further. The integrator will restrict access the component should:
to individual values of a component for other components
or other users in order to prevent attacks, misuse or disclo- 2.1 be given and be able to use a system-specific identity
sure of the integrator’s company secrets. Access to compo- including a ZAN certificate (which may be, but does
nent functions and data should be designed in such a way not need to be the integrator-specific identity) and
that each user (other component or user) only receives the
minimum level of access rights necessary to perform their 2.2 be given and be able to use a system-specific
function. The integrator sets these access rights and in many trust list.
cases will reserve the exclusive right for himself to adjust
access rights and restrictions and to assign access rights (to 3. For the purpose of communication with the integra-
a component or person). This is necessary because other- tor’s processes and staff, the component should be
wise the integrator cannot impose any restrictions to pro- given and able to use the integrator-specific identity,
tect the function of a machine or to protect his own com- including the ZIN certificate, as well as an integra-
pany secrets (e. g. the exact configuration of components tor-specific trust list.
and their interaction). The integrator can grant further rights
to the future operator, so that he can operate the machine 4. The component should support an access control
as intended or integrate it into his own company infra- mechanism that can be used to define rights indepen­
structure. In this scenario, this means that the integrator dent of specific identities.
gives some of the operator’s users or components read
access to certain values and alarms, so that the machine 5. The rights in the component should be set so that
can be monitored. In addition, the operator can have write certain rights are required in order to change rights.
access to certain machine parameters, so that they can be
adapted to the products to be manufactured. 6. The rights in the component should be set so that cer-
tain rights are required to set the rules for assigning
rights to identities.
 E X A M I N AT I O N O V E R T H E L I F E C YC L E 17

Commissioning Integrator’s preparation of handover

A transfer of risk takes place during commissioning. The Preparation for handover to the operator is carried out by
system created by the integrator moves from the integra- the integrator.
tor’s sphere of responsibility to that of the operator. Com-
missioning can be divided into two phases: In the first phase, For the example scenario, handover is prepared in the fol-
the integrator prepares the takeover by the operator. In the lowing steps and in the following order:
second phase, the operator takes over the system. This part
of the takeover by the operator is often also accompanied by • The integrator defines access rights for maintenance staff
the integrator’s staff. In this case, staff performing the take- and maintenance processes in the form of additional rights
over by, for or with the operator are referred to as “com- and assignment rules. Specific assignments of rights are
missioning engineers.” This happens irrespective of whether also activated, for example, by assigning sets of identities
these staff are now assigned to the operator, are contracted with concrete rules to roles. In some applications, it is
by the operator or whether they are the integrator’s staff necessary that these rights also include the right to update
accompanying the operator’s staff. The integrator prepares the system’s software and firmware at the beginning of
the commissioning of the system and takeover is carried commissioning. Delivery may have taken weeks, so that
out by the commissioning engineer. in the meantime updates may be available for software
and firmware. The resulting complexity of rights – and
It is not just the responsibility for the system that changes how their definition survives a software and firmware
after commissioning. This often also means a change in renewal – is not discussed further in this paper, but re­
possession (in this scenario, however, with no change in mains a task for a successor paper.
ownership). This primarily changes the integration of the
system into the security domains. It ultimately determines • The integrator stores and activates authentication criteria
to a certain extent who or what can accesses the compo- and rights in the components of the system for the
nents and vice versa, and who or what the component can commissioning engineer, so that he is recognised by the
communicate with. Other parts of these rights determine system during takeover.
the access control mechanisms already set during integra-
tion along with options for assigning rights.

Figure 4: Breakdown of commissioning into two phases

Integrator Operator

Commissioning Integrator

engineer Preparation

Commissioning
Commissioning
engineer
Takeover

Operation and maintenance

Source: Plattform Industrie 4.0
18 E X A M I N AT I O N O V E R T H E L I F E C YC L E

• I n many cases, it must be possible for the system to ments and authentication criteria again for the com-
verify these authentication criteria without the need missioning engineer.
for functioning integration into an IT network, because
the system will not yet have been integrated into 3. The integrator should be able to delete unnecessary
such a network at its new location. access paths, authentication criteria and rights from
the system.
•  urthermore, the work of the commissioning engi-
F
neer is once-off and temporary. This work is com-
pleted when the system has been taken over. The Takeover during commissioning
integrator rather than the commissioning engineer
is responsible for maintenance according to the While preparation for commissioning can take place before
model here. shipment of a system, actual takeover in this example will
take place after shipment and physical installation of the
This means that, according to the principle of assign- system on site.
ing need-to-know rights, the special rights assign-
ments for the commissioning engineer can be deac- The commissioning engineer’s task is to take over the system
tivated once the work has been completed. His from the integrator and to commission it at the operator’s
authentication criteria and rights assignments should site in such a manner that the operator can subsequently
therefore only exist temporarily in the system. operate the system for his benefit in regular operating mode
(only to be interrupted by maintenance, if any). For this
• Finally, the integrator removes unnecessary authentica- purpose, the commissioning engineer connects the system
tion criteria as well as access rights and options which to the local environment at the operator’s site. In addition
he no longer needs after handover. to physical connections, this also includes connection to the
operator’s IT, and more importantly, inclusion in certain
• If necessary, the integrator has granted the system and/ security domains:
or its components access possibilities and rights in the
integrator’s security domain which were necessary during • First of all, the commissioning engineer checks the authen-
component integration, for example, for a test operation. ticity and integrity of the system in order to determine
The integrator will therefore block or delete unnecessary whether the system is from the integrator and whether
access paths and rights for the system in his security do­ it is in the state in which it was prepared by the integra-
main. The integrator will not delete the identities and tor. This is particularly necessary if the system or parts
pertinent ZIN certificates issued by him, nor will he of the system were under the control of third parties in
revoke them, instead, their access options will be reduced. the time between preparation and takeover, for example,
These identities could be useful for remote maintenance. by a forwarder and its contractor.

Preparation for commissioning therefore results in the • If the system is trusted, the commissioning engineer brings
following security requirements for a system with Industry identities created by the operator together with ZBN cer-
4.0 components: tificates into the system to enable secure interaction
with the operator’s security domain.
1. It should be possible in the system to adjust the authen-
tication criteria, rights and rights assignments (to roles • The system and its components are incorporated in
or access rules) defined by the integrator for mainte- two stages into the security domain of the operator’s IT.
nance access.
•  uthentication criteria provided by the operator are
A
2. The integrator should be able to activate authentica- incorporated into the system and its components.
tion criteria and rights in the system that are tempo-
rarily needed for the commissioning engineer, so that
the system can authenticate the commissioning engi-
neer, if required even without a network connection,
and it should be possible to remove these rights assign-
 E X A M I N AT I O N O V E R T H E L I F E C YC L E 19

•  he identities of the system and its components are

T • Once the system has been accepted by the operator, the
made known in the operator’s infrastructure by commissioning engineer deletes his access options,
activating the associated certificates. The system is which are now no longer required.
now set up so that it can renew the ZBN certificates
if needed, for instance, in good time before validity Takeover results in the following security requirements for
expires. The system can also receive up-to-date ver- a system with Industry 4.0 components:
sions of the authentication criteria issued by the
operator. From time to time, the operator may have 1. It should be possible to check that the system comes
to introduce new trusted root certificates (root CA from the integrator and is in the state defined by the
certificates) into operations or distribute revocation integrator.
information if other components are taken out of
operation before their certificates expire. 2. The operator’s identities together with the ZBN certifi-
cates issued by the operator can be introduced into the
• The commissioning engineer sets the authentication system, while the previous identities and the pertinent
criteria in the system for the operator’s personnel and certificates (e. g. certificates of the ZIN integrator and
processes. The operator must especially remember that certificates of the ZHN component manufacturers)
roles, attributes and their characteristics may have com- remain in the system.
pletely different names or designations in the operator’s
security domain than anticipated by the integrator. A 3. It should be possible to store authentication criteria for
series machine manufacturer, for instance, may not find identities of different security domains separately and
any common denominator for the designations used by simultaneously in the system.
his customers. This means that it must be possible to
change the designations provided by the integrator within 4. It should be possible to both set and at the same time
the access control mechanisms of the system to the actual activate rights with reference to the authentication cri-
designations. Mapping rules from actual (external) to teria of the identities of a security domain, so that the
logical (internal) designations are useful here (external system can distinguish between the operator and the
means outside the system and internal means inside the integrator (for maintenance) and enforce the correspond-
system). ing rights.

• The commissioning engineer tests remote maintenance 5. It should be possible to map the descriptions actually
access together with the operator and the maintenance used by the operator (external roles, external attributes
staff working remotely. In doing so, he also explains to and their characteristics) for the identities of his per-
the operator the access path and the rights that can be sonnel and his processes to designations defined by
exercised via this path. This does not mean that a perma- the integrator (internal designations).
nent and unobserved maintenance option is activated
here, but that personnel can be authenticated and author- 6. It must be possible to delete the access rights and authen-
ised in the case of maintenance. How maintenance access tication criteria temporarily set in the system regarding
will in fact have to be later enabled by the operator, for the identities for access by the commissioning engineer.
instance, using a key switch, depends on the purpose of
the system. For some systems, permanent monitoring by
the integrator or a service provider may be desired, for Operation and security maintenance
example, as part of predictive maintenance or condition
monitoring. As already mentioned above in the explana- During the operating phase, the private keys and certificates
tion of the application scenario, the auditability of actual for authentication for OPC UA must be changed at regular
maintenance access is an issue for some operators. But intervals in a secure manner, for instance, if technical pro-
its safe implementation will be the subject of discussion gress or attacks constantly impair the security of crypto­
in a later paper. graphic algorithms. A change can be planned when crypto­
graphic ageing of methods and algorithms is foreseeable,
whereas an attack in which private keys, for instance, were
stolen is reason for a fast and unscheduled exchange.
20 E X A M I N AT I O N O V E R T H E L I F E C YC L E

A fundamental distinction must be made when changing When private keys and certificates are exchanged, it must
private keys and certificates: be taken into account that some systems or machines have
only limited maintenance windows. This should therefore
• A component/user receives a new private key and a new be carried out early or it should be possible without inter-
certificate must be generated. rupting system operation.

• A component/user has received a new certificate and the If a connection to the system or its components is estab-
certificate is to be authorised (for example, to communi- lished from the operator’s area or vice versa, the system
cate via OPC UA). In the best-case scenario, the authenti- should prove its affiliation to the operator with a ZBN cer-
cation criteria (trust lists) of the other components do tificate. The system should also check the certificate of the
not have to be updated. In some cases, it is necessary to remote station using the operator’s criteria, for example, a
store the new certificate in repository services or even to trust list containing certificates of the operator. A secure
distribute an associated new issuer certificate (sub-CA connection is not established until mutual verification has
certificate) to other components via a distribution taken place. If the system or its components establish a
mechanism. connection to the integrator or vice versa, for example, for
maintenance purposes, the integrator’s certificates and cri-
• The issuing Certification Authority is changed and all teria must be used analogously. These rules apply especially
components must be informed of this. This means that to connections in which the keys and/or certificates are
certificates from several certification bodies may exist regularly renewed.
during the period of transition. The components must
support and accept this. One principle of security practice is to minimise risks by
using different key pairs for different tasks. For example, if
In the case of certificates for components, a distinction must a key pair with a certificate is used for confidential
also be made between two types of holders. The certificates (encrypted) communication with a component, the same
can come either from the operator or from the integrator. key pair should not be used to authenticate the component
Both are responsible for their respective certificates and or for signatures to be generated by the component, see
must exchange them on the basis of their validity. Access also Table 7, No. 4 in “Sicherheitsanalyse OPC UA” issued by
rights must be defined for the exchange. For this purpose, the Federal Office for Information Security (12). Various
the component must be able to assign rights for certificate risks are thereby reduced, which are justified both in secu-
renewal to different user groups. The same applies to the rity procedures and in organisational applications. For
renewal of the key pairs that belong to the certificates. example, if the same key pair is used for confidential com-
Responsibility for the certificate determines who can initi- munication and authentication, some authentication
ate the renewal of the key pair. methods can cause the key holder, i. e. the component, to
decrypt for others confidential material intended for the
User authorisations can change over time. That’s why it key holder. Some authentication procedures require the
should be possible to change the authorisations used by component to be able to decrypt a random number that is
the components or to change authentication servers. Again, unknown to the component but encrypted with its public
a distinction must be made between the different user key. However, if the attacker does not reinvent an encrypted
groups of the operator and the integrator, because access random number but selects another confidential and en­­
authorisation may not be mutually overwritten. It should crypted message intended as a task for the component,
even be possible to change user group assignments over decryption will then be delivered to the attacker virtually
time, because changes in personnel responsibilities due free of charge during the authentication process.
to changes in organisational structures or changes in the
operator or integrator’s technical infrastructure will neces- In security practice, using different key pairs for authentica-
sitate changes in processes. tion and negotiation of symmetric keys for encrypting
messages would also support the use of so-called middle-
boxes at trust boundaries in such a way that communications
can be read by key deposit measures or sub-CA instances in
a middlebox without this also compromising the authentic-
ity of communications.
 E X A M I N AT I O N O V E R T H E L I F E C YC L E 21

That’s because middleboxes would only require keys or 2. Authentication and authorisation criteria for identities
sub-CA instances which are stored for decryption. They should be
would not have to be trained for authentication and hence
falsification of messages. The auditability of data traffic 2.1 renewed regularly and
across trust boundaries will be the subject of a future paper
which will address this circumstance once again. 2.2 separately for each person responsible (integrator
versus operator).
Regular operations with maintenance results in the follow-
ing security requirements for a system with Industry 4.0 3. When establishing a connection to the system or its
components: components or in the opposite direction, it should be
possible to select
1. In the case of identities and the pertinent certificates as
well as key material, 3.1 which identity and which certificate are relevant
(integrator versus operator) and
1.1 it should be possible to renew them without inter-
ruption and 3.2 which verification criteria are relevant for verify-
ing the remote station and its users.
1.2 depending on the issuer, it should be possible to
renew them on different paths (integrator certifi- 4. Different keys and certificates should be used for encryp-
cate versus operator certificate).. tion and authentication/signing.
22 E X A M I N AT I O N O V E R T H E L I F E C YC L E

Decommissioning Decommissioning results in the following security

requirements:
Industry 4.0 components and systems contain sensitive
data, such as keys, access data and confidential information 1. Components should be able to securely delete sensitive
in log data. Sensitive data therefore includes not only data data.
relevant to security, but also data subject to data protection.
If sensitive data falls into the wrong hands, this will pose a 2. In both the operator and the integrator’s infrastructure,
threat to all communication partners, because the data can it must be possible to disable access partially or com-
be used to trigger actions and other confidential data may pletely for components or entire systems.
be captured and security settings may even be changed. If a
device is compromised or stolen and if its sensitive data has 3. In the case of temporary disabling, it should be possi-
not been protected by special hardware measures, this can ble to activate and revoke disabling in the operator
be even more dangerous. and/or integrator’s infrastructure.

While the identities of lost components must be blocked

in the event of sudden loss (theft), sensitive data must be Disposal
deleted at the time of decommissioning. Both are described
in general terms in a separate security policy: an end-of-life During disposal, it must be ensured that all sensitive data
policy. This policy must be defined in line with the applica- has been effectively deleted from the system parts and
tion. This means that there may be specific guidelines for com­ponents affected during prior decommissioning. This
specific types of systems and/or components. is im­portant not just with a view to IT security, but also in
terms of data protection, especially in light of the EU’s Gen-
Security guidelines and the security procedures derived eral Data Protection Regulation (EU GDPR). If in doubt, the
from them must define the steps to be carried out in order decommissioning procedures to delete sensitive data must
to securely take a device out of service or disable it after it be repeated. Alternatively, physical destruction of the mem-
was lost. Decommissioning or disabling can be either per- ory containing sensitive data can be an option. No further
manent or temporary. It may be designed to securely erase abstract security requirements are laid down for this phase.
all sensitive data from a device in order to recycle it in
another context or to dispose of it in a secure manner.
Furthermore, it must be defined how the device can be Contingency measures/restoration of
replaced in the event of a defect so that system functional- operations
ity can be guaranteed and the information on the device
deleted. From a security perspective, an emergency exists if it is found
that an operating system may not be behaving as usual due
The ability of software to evade attacks decreases over its to unauthorised manipulation of the system. As a rule, this
lifetime as new threats are discovered or emerge due to prevents the operator from using the system securely or
technological progress. When systems or devices are replaced, efficiently. When dealing with security incidents at a pro-
a new risk and hazard assessment should be carried out in duction plant, this leads to a conflict of objectives: On the
order to check whether the security decisions previously one hand, the cause must be investigated in order to deter-
made are still sufficient or whether stronger safeguards mine the extent of damage and to be able to prevent such
may be required. incidents in the future; on the other hand, operations must
be restored quickly in order to minimise consequential
damage (e.g. due to a loss of production). Since unauthor-
ised manipulation is usually unforeseen and therefore ini-
tially goes undetected, the cause can often only be found
on the manipulated object and the investigation requires
time during which restoration of operations will have to
wait. Quick restoration of operations often erases traces
that can be used in the subsequent analysis of the root
cause of such a security incident.
 E X A M I N AT I O N O V E R T H E L I F E C YC L E 23

One proven approach in this case is to take a snapshot of cannot gain possession of them. This also eliminates the
data and the states of the affected system for later analysis above-described need to renew private keys and certificates
and then to bring the data and states of the system back up after an attack. This paper does not take a more detailed
to an operational state before the analysis is completed. look at the requirements for secure elements since they are
This state can be restored from a backup copy of a (pre- not the focus of this discussion. It should be noted, however,
sumably) not yet manipulated state. To be able to do this, that due to the use of several certificates and pertinent key
the operator must also be able to make backup copies and pairs, which has already become apparent in the course of
to reload these again. He must also be able to take a snap- the discussion above, requirements for secure elements
shot as quickly as possible with or without the integrator’s would certainly need to be discussed.
assistance. Sensitive data must be protected both when
making and restoring backup copies and when taking snap- The following security requirements apply to support for
shots. The operator may not gain possession of sensitive restoring operations and contingency measures:
integrator data (e.g. know-how of the plant application) and
vice versa (e.g. private keys to operator’s certificates or log 1. It should be possible to take snapshots of system and
data related to operator’s personnel). component data (log data, temporary data, etc.) for
forensic purposes, so that they do not contain any sen-
Simple restoration of a secure configuration is not always sitive information but still allow an analysis of security
easily possible, since at this point in time the target system incidents.
is in an insecure and perhaps even unknown state. There-
fore, different measures must be selected from case to case 2. It should be possible to make and restore backup copies
(e. g. configuration reset, reload software or replace compo- of systems and components in such a way that sensitive
nents completely). data is still protected in the backup copies and restora-
tion only transfers the sensitive data to components in
Unfortunately, simply restoring a formerly safe state is often a trusted state.
not enough. Unauthorised access could result in the seizure
of private keys to certificates. In this case, it would be even 3. It should be possible to quickly exchange key pairs and
easier than before for the attacker to repeatedly intervene pertinent certificates in the case of components that
and manipulate – this time virtually indistinguishable from have probably been compromised.
authorised access – so that simple restoration would create
a false impression of regular operations whereas in fact 4. For users, components should support certificate
ongoing attacks are still successful. Therefore, if sensitive authentication and/or verify passwords using an
data material, such as private keys, is suspected of being authentication service.
compromised, new key pairs must be generated and new
certificates issued as a precautionary measure. In cases like
these, passwords are much more difficult to replace if their
comparison values (the so-called password hashes) are
stored on the devices.

That’s why in the case of password-based authentication,

the password should be verified using an authentication
service, such as an LDAP server, an Active Directory or a
Kerberos system where passwords for entire areas can be
renewed.

To prevent unauthorised manipulation or copying of private

keys, the keys should be safely kept in hardware security
modules (Secure Elements). In cases like these, private keys
and the pertinent certificates do not have to be renewed as
long as the hardware, i.e. the component including the
secure element, is still intact. That’s because an attacker
24

Solution sketch/discussion
 S O LU T I O N S K E TC H / D I S C U S S I O N 25

The aim of this section is to identify requirements and Security domains

issues yet to be discussed in order to trigger further discus-
sions on the secure application of the OPC UA standard. The sources of identities correspond to the different secu-
The aim is to stimulate discourse on the application of the rity domains. A distinction is made here particularly between
OPC UA standard. Therefore, once a solution to a require- the integrator’s security domain and that of the operator.
ment is found and mentioned, it is deliberately not dis- Figure 5 on the next page shows the different domains and
cussed further here. The document is based on both the their location. For the sake of clarity, the manufacturer’s
published OPC UA standard (13) and subsequent versions security domain is not presented. The illustration shows an
of its parts. The corresponding status is referenced at the “SD-I” security domain for the integrator. “SD-A” is a secu-
respective point. The OPC Foundation has also published rity domain within the system. The domain for the opera-
a recent whitepaper (14) on the topic. tor is “SD-B”.

In the following, solutions are sketched with one table for

each phase of the lifecycle and in each case related to the Provision of authentication criteria (e. g. trust lists)
individual security requirements of the phase explained
above. When describing the solution sketches, two colours Part 12 of the OPC UA standard (15) defines two mechanisms
are selected for the text which should provide a quick over- for the automatic management of certificates (certificate
view: Green text means that at least one solution is sketched management):
based on established standards or common technologies.
Blue text refers to points open for discussion. • With “pull management”, an OPC UA application can
regularly obtain various trust lists from an OPC UA
server, which is referred to in the standard as the Global
Anticipating repetitive sketches Discovery Server (GDS). An information model (collec-
tion of objects, their types and methods) is defined in
Before reference is made to the individual security require- the standard that describes an interface in the GDS via
ments, an overview is used to explain some repetitive solu- which OPC UA applications can perform “pull manage-
tion sketches. ment”. This means that they regularly copy the trust lists.

The security requirements show that digital identities are • The second mechanism is called “push management”
needed from different sources. As a reminder, the terms and defines an information model for OPC UA applica-
used for the sources and identities are repeated here: tions that are an OPC UA server. Via this interface, a
management application can update the trust lists from
1. Identities issued by the component manufacturer the GDS according to a schedule in the target server,
(e. g. ZHN manufacturer certificates) i. e. copy them there. The management application works
in both directions as an OPC UA client, both to the GDS
2. Identities assigned by the integrator and to the target server. The standard does not define
(e. g. ZIN certificates) where the management application runs. It is conceivable
for this application to be located near the GDS, providing
3. Optional identities valid in the system several OPC UA servers with new information for trust
(e. g. ZAN certificates) lists. For a server with “push management” capability,
the standard defines more precisely that the target server
4. Identities issued by the operator must have an object called “ServerConfiguration” under
(e. g. ZBN certificates) which various certificate groups are referenced with each
group representing a trust list.
26 S O LU T I O N S K E TC H / D I S C U S S I O N

Figure 5: Localisation of the security domains using machine A as an example – without the manufacturer’s domain

Integrator MES and

(service provider) ERP operator

SD-I

IoT Gateway

Machine A
Local Switch

SD-A
Component Component
A.1 A.2
SD-B
Component Component Component Component
A.1.1 A.3 A.2.1 A.2.2

Source: Plattform Industrie 4.0

With OPC UA, a trust list contains precisely the informa- The trust lists must be managed accordingly
tion needed to check certificates of a security domain in
the form of trusted certificates, optionally additional certif- • one trust list for devices and software processes issued
icates to complete certificate chains (issuer certificates) and by the pertinent CA, and
optionally revocation information. OPC UA defines two
types of trust lists in the standard (via the certificate • optionally one trust list for user identities, issued by the
groups), i.e. those for checking application certificates and pertinent CA.
those for checking user certificates. This distinction
matches the above security requirements. It is quite possible for this information to also be distrib-
uted in other ways. This approach takes into account the
In the solution sketches described below, the two methods requirement, i.e. to propose as little as possible in addition
of certificate management via OPC UA and Global Discov- to OPC UA, which was already explained in the introduc-
ery Server (GDS) are used, so that all of the components or tion with regard to the significance of OPC UA.
relevant plant parts in each security domain with a GDS
and the underlying Certification Authorities (CAs) receive Instead of using a set of trust lists for each security domain,
copies of the trust lists. Several CAs can play a role here: it is also conceivable to provide the same set of trust lists
for different domains within a GDS. However, this would
• one CA for devices and software processes and raise the question as to who is responsible for maintaining
the security domain. As soon as other security domains are
• optionally one CA for user identities. included in a scenario, for instance, by suppliers, it becomes
clear that, instead of helping, this kind of mixed managed
 S O LU T I O N S K E TC H / D I S C U S S I O N 27

trust list leads to even greater complexity. Similarly, it is Providing the system with different trust lists, own certifi-
possible to include only parts of a certification hierarchy of cates and password check criteria is depicted in Figure 6
another Certification Authority in a trust list, for example, below using the example of the SD-I and SD-B security
in order to declare certain plant parts of another security domains. Every component communicating via OPC UA
domain to be trusted. It is also necessary once again to requires trust lists and own certificates. For more complex
weigh up the complexity of responsibility issues with the systems, it makes sense to regularly copy the trust lists once
technical simplification in the form of a lower number of from one domain to the system and to distribute them
trust lists to be distributed. This paper does not examine from there, for example, with a local OPC UA server that
any further the more complex organisational procedures serves as a GDS proxy with a cache for the components in
but instead the solutions describe in simple terms the the system. This concept is only outlined here and will not
approach with strictly separated trust lists for each security be discussed further. In Figure 6, the SD-I security domain
domain. is the Certification Authority (CA) for the devices and soft-
ware processes shown as CA-ID and for the CAs for the users
Since the release of version 1.04 in November 2017, the shown as CA-IU. The pertinent VL-ID and VL-IU trust lists
OPC UA standard describes in the “Services” (16) and “Map- are provided and distributed via the GDS called “GDS-I”.
pings” (17) sub-documents new possibilities for authenti- For the SD-B domain, this is carried out in the same way
cating users, for instance, using OAuth2 with JSON Web via the GDS-B by the CAs called CA-BD and CA-BU with
Tokens to check passwords with check criteria that can be the VL-BD and VL-BU trust lists.
stored in an LDAP server.

Figure 6: Provision of (copies of) trust lists and password verification information

Integrator Certification Authority CA-IU

LDAP-I MES and
(service provider) Certification Authority CA-ID
ERP operator

SD-I OAuth2 Certification Authority CA-BU

Certification Authority CA-BD

OPC UA VL-ID
GDS-I VL-ID

IoT Gateway OPC UA VL-BU

GDS-B VL-BD
Machine A
VL-IU VL-BU
Local Switch VL-ID VL-BD LDAP-B

SD-A OAuth2
Component Component
A.1 A.2
SD-B
Component Component Component Component
A.1.1 A.3 A.2.1 A.2.2

Source: Plattform Industrie 4.0

28 S O LU T I O N S K E TC H / D I S C U S S I O N

Figure 7: Provision of (copies of) trust lists and password verification information

IoTGateway
Certification Authority CA-AU LDAP-A
Machine A Certification Authority CA-AD

Local Switch
OAuth2
OPC UA VL-AD
GDS-A VL-AD

Component Component
SD-A
A.1 A.2

Component Component Component Component

A.1.1 A.3 A.2.1 A.2.2

Source: Plattform Industrie 4.0

Figure 6 also shows that passwords can be used instead of domain. The password verification information is not repli-
certificates in order to authenticate users. Besides a con- cated, however, communication takes place indirectly with
ventional method, i. e. the use of passwords configured locally the OAuth2 servers.
in components and the pertinent verification criteria (tables
with user names and passwords), as described above, the The fact that a Certification Authority can also distribute
OPC UA standard describes the use of OAuth2 as a network trust lists within a system in the SD-A security domain is
method for authenticating users. Locally configured pass- shown in Figure 7 as an example. The certification authori-
word tables have disadvantages that have already been dis- ties, the LDAP server and the trust lists are named in the
cussed in the examination of the lifecycle. There are also same way as the previous examples.
disadvantages to using OAuth2:

Besides OPC UA, another protocol is required when using Provision of identities (certificates and key pairs)
OAuth2 and this causes user authentication to fail if the
OAuth2 server(s) is/are not available. For pull management and push management, Part 12 of
the OPC UA standard “Discovery” (15) explains not only the
Certificates for users, on the other hand, allow new authen- provision of trust list copies, but also the provision of digi-
tication processes to be performed for an interim period tal identities in the form of asymmetric key pairs and the
without current replication of trust lists. In the main, obso- pertinent certificates. Using both methods, an OPC UA
lete revocation information forms the limit for the interim application can obtain (pull management) or provide (push
period. The Certification Authority usually defines how management) the required number of certificates. It is up
long revocation information can be used. to the application whether it generates the corresponding
key pair itself or whether it receives it from the providing
No security domain must (but can) support both methods end. This is ideal for supporting cryptographically weak
of user authentication, i. e. with certificates and/or OAuth2. devices that do not have sources of good random numbers
Figure 6 shows an example of an LDAP server called for generating keys. At the same time, devices are sup-
“LDAP-I” with an upstream OAuth2 mechanism in the SD-I ported that have a secure element for generating and pro-
domain and an LDAP server called “LDAP-B” in the SD-B tecting key pairs and especially the private key, such as
 S O LU T I O N S K E TC H / D I S C U S S I O N 29

devices with a Trusted Platform Module (TPM), as is already •  erver manufacturers are at liberty to implement a
S
the case with most PC platforms today. different procedure.

The OPC UA standard allows an OPC UA client to choose •  he OPC UA standard not only describes the effect
T
which certificate to use with the server as part of a secure of roles and rights in the OPC UA server, it also
connection setup. An OPC UA server can offer multiple defines
endpoints and define a certificate and key pair for each
endpoint to be used. If an OPC UA server uses several end- • t heir presentation to clients and users who are
points, it is still a single process within an operating system. allowed to view this information,
Internally, the same address space and slightly or com- • extensions of the information model for chang-
pletely different address spaces can be displayed behind ing the assignment of rights and roles to the
each endpoint, i. e. sets of nodes and their references. The individual nodes in the server address space,
OPC UA server remains a single OPC UA application. When • a mechanism (IdentityMappingRuleType) for
a client connects to a server, the client indicates to the mapping identities of OPC UA clients and users
server, through the URL of the endpoint, the endpoint to using
which the client wishes to connect.
—— a ttributes of users from their authentication
The solution sketches here assume that an OPC UA server tokens (e. g. attributes from their JSON Web
offers precisely the same number of endpoints within a Token, such as their group or role affiliation),
system as the number of communication relationships that —— their certificates,
it supports in security domains. A component with an OPC —— the endpoint selected for communication
UA server, which is to be able to communicate both within and
the system, with the operator and the integrator, therefore —— certain combinations thereof.
has three endpoints, one each for the domains: SD-A, SD-I
and SD-B. For each of these endpoints, it uses a certificate • Part 4-1 of IEC 62443 (4) defines for components with
which it has received via the GDS of the respective domain. the CR 2.1 requirement and its RE2 extension that the
enforcement of authorisation for human users must be
Similarly, the OPC UA clients of all of the system compo- based on roles and the assignment of roles to human
nents issue their certificates via the GDS of the respective users must be directly definable or modifiable, or via
domain. The communication relationships needed are compensation mechanisms by IT security.
already shown with illustrations in the previous discussion.
• The IEC/TS 62351-8 (20) standard, which is binding for
the energy sector, stipulates that authorisation must be
Authorisation of communication and interaction partners implemented on a role-based access control system for
(partners) data exchange with devices for the energy sector.

In the above examination of the lifecycle, access control Attribute-based access control systems (ABAC for short), on
mechanisms and authorisation mechanisms, such as roles the other hand, are comparatively new and not yet wide-
and rights, and alternatively attributes and rules, were spread in industry. A technically sound definition can be
addressed rather awkwardly with regard to user authorisa- found, for instance, in NIST SP 800-162, a “Guide to Attrib-
tion. This is due to the fact that different concepts can now ute based Access Control ...” (21). ABAC systems can be seen
be found in different standards. as a superset of RBAC systems, where rule sets can be used
instead of direct assignments between identities and roles
Role-based access control (RBAC) mechanisms, for instance, in order to define complex mapping functions between
attribute values assigned to an identity, objects or environ-
• are described in the OPC UA standard, version 1.04, ment and the roles to which rights are assigned. To some
released in November 2017, in the “Address Space extent, the OPC UA standard already goes in the direction of
Model” (18) and “Information Model” parts (19), as an ABAC, because it already describes mapping rules between
option for OPC UA servers. attributes from an authentication token and assigned roles.
30 S O LU T I O N S K E TC H / D I S C U S S I O N

Due to the spread of RBAC in the relevant industrial stand-

ards, the solution sketches here refer to role-based access
control as described in the OPC UA standard.

Taking possession

Requirement Can be fulfilled by/Point open for discussion

1. It should be possible to verify the authenticity of The Companion standard “Devices” (22) published by the OPC Foundation explains an information
the component on the basis of a certificate from model for describing devices. It does not yet include device authentication.
the manufacturer. A dedicated, always available “endpoint” in the OPC UA server of a component, which is to be
called the manufacturer endpoint here, could use a certificate from manufacturer ZHN directly
to authenticate the server to clients.
Such an endpoint alone cannot prove hardware “authenticity”. However, OPC UA can support
this as a communication protocol and information model with security features.
The “manufacturer endpoint” could be extended using methods and objects that can be requested
using OPC UA and provide proof of the integrity and authenticity of the component’s hardware
and software.
In the field of “trusted computing”, this is referred to as “remote attestation” and is usually based
on hardware security modules (secure elements). Instead of complicated remote attestation,
the device could, for instance, also use the private key for the above endpoint only in the case of
trusted hardware and software, i.e. a secure element releases the private key only if a secure
start procedure (trusted boot/secure boot) has taken place.
For security reasons, the “manufacturer endpoint” should not allow access to the device’s full
functionality. Ideally, this access should be restricted to verifying authenticity and taking posses-
sion of the device, so that the owner is still required to issue a specific certificate.3
2. It should also be possible to reset all component A reset mechanism on the device can allow it to be reset to factory settings.
settings to the manufacturer’s factory settings. An OPC UA standard could (additionally) define a reset method for devices.
Secure components must delete sensitive data when reset to factory settings.
3. The basic configuration should have a secure By applying the “Security by Design” principle during product development, as explained, for
design and the device should be supplied with a instance, in Part 4-1 of IEC 62443 (4) for component manufacturers, the manufacturer knows a
secure configuration. safe basic configuration and can bring the devices to market with settings that comply with the
principle of “Security by Default”.
Only a few of the products currently available have been developed according to the “Security by
Design” principle. The same goes for products supplied according to “Security by Default”. In the
interest of future product security, it is urgently recommended that manufacturers apply both
principles.
4. The integrator should be able to define all of the Using the above-described certificate management via the Global Discovery Server (GDS) accord­
authentication criteria used by the component ing to OPC UA “Discovery” (15), components could be automatically provided with specific
to verify other identities. These include all pass- authentication criteria for each security domain by setting GDS relationships.
words and all certificates that the component User passwords would be automatically set specifically if components supported OAuth2 (for
trusts, except for a few certificates designed by example with underlying LDAP servers).
the manufacturer for special purposes, such as An initial password may have to be defined for an administrative user at the factory, so that a
authentication of firmware updates. component can be put into operation in a secure manner. A procedure commonly used to securely
individualise this password is, for instance, to set the password ex works to suit the individual
device and to print it on the housing at a usually concealed location. Other methods are available,
but are not discussed here. The specific choice depends to a large extent on the component’s
area of application.
An appendix to OPC UA “Discovery” (15) roughly outlines how initial provisioning of an OPC UA
application can be provided with an identity and a certificate. For security reasons, it is recom-
mended that both parties make an explicit and once-off manual announcement. The GDS
should be made known to the application. The application does not yet know the identity of the
GDS. The device must be made known to the GDS. The GDS is not yet able to identify the device
using an identity issued by the GDS. The procedure is only roughly explained in the OPC UA
standard; support for this procedure through standardised parts in the information model
(objects and methods) would be helpful. Although it is possible according to the standard to use
a Local Discovery Server with Multicast Extension (LDS ME) in order to make new OPC UA
applications with corresponding multicast capability known to a GDS, this approach does pose
security problems that should be pointed out in the standard itself.
Source: Plattform Industrie 4.0

3 Failure to do so would mean operating with certificates that cannot be revoked either by the integrator or the operator and accordingly an
attacker could introduce into the communication network devices which are from the same manufacturer but were configured by the attacker.
 S O LU T I O N S K E TC H / D I S C U S S I O N 31

Integration

Requirement Can be fulfilled by/Point open for discussion

1. It should be possible to assign an integrator-­ The OPC UA standard defines ways to set certificates for servers and clients. Examples are already
specific identity with a pertinent ZIN certificate explained above together with certificate management according to OPC UA “Discovery” (15).
to the component.
2. For the purpose of communication in the Part 4 “Services” of the OPC UA standard (16) explains that the same server can have different
system, the component should: endpoints. Each endpoint can be equipped with its own certificate. This means, for instance, that
a component could offer several endpoints in its OPC UA server, for example, one endpoint for
2.1 be given and be able to use a system-specific each identity.
identity including a ZAN certificate OPC UA clients integrated into a system can decide which identity to use with which certificate
(which may be, but does not have to be the vis-à-vis an OPC UA server before establishing the connection. This is possible by individual
integrator-specific identity) and assignment of the “clientCertificate” field in the “OpenSecureChannel” service request, which a
client must access for a server in order to establish a secure connection.
2.2 be given and be able to use a system-specific Part 12 “Discovery” of the OPC UA standard (15) explains how both OPC UA clients and OPC UA
trust list. servers can be provided with trust lists via “Certificate Management” of a “Global Discovery
Server” (GDS). As a rule, first provision takes place with the assignment of the identity and the
corresponding certificate. This can also be implemented for components.
For more complex systems, it makes sense for trust within the system to be autonomously created
and managed using certificates that are valid only within the system.
A “small” edition of a GDS with an integrated Certification Authority can be used for this purpose.
For less complex systems, where using a GDS would be too complex, distribution can be imple-
mented with file system operations. However, the provision paths and access authorisations
must be proprietary.
Instead of automatic certificate management via a GDS, manual distribution via freely available
OPC UA clients with a user interface can also be implemented, for instance, via UaExpert.
3. For the purpose of communication with the The previously outlined distribution of trust lists and identity certificates based on certificate
integrator’s processes and staff, the component management via a Global Discovery Server (GDS) allows specific distribution paths for each
should be given and able to use the integra- security domain.
tor-specific identity, including the ZIN certificate, Since with the “push management” method the trust lists are implemented with their own
as well as an integrator-specific trust list. objects with methods, the RBAC concept according to OPC UA “Address Space Model” (18) and
“Information Model” (19) specifies that these objects can be set so that they can only be modi-
fied from the corresponding domain, for instance, by assigning the rights to a role for which
assignment criteria (IdentityMappingRules) define that this role only applies to communication
via the endpoint that is used for the respective security domain.
OPC UA “Discovery” (15) defines three types of trust lists, one for application certificates, one
for user certificates and one for HTTPS certificates. All types are referenced directly from the
ServerConfiguration object via which the respective push management is implemented. However,
according to the solution sketch already explained above, a set of trust lists is required for each
endpoint of a server. This means that each endpoint would have to implement the set of trust
lists below the ServerConfiguration object differently, which would be possible under the standard.
The only thing missing in the standard is the option of initially establishing the provisioning of
another endpoint via an existing endpoint.
4. The component should support an access con- As explained above in the anticipation of repetitive sketches, the OPC UA “Information Model”
trol mechanism that can be used to define rights (19) explains that, according to the OPC CU standard, rules in the form of IdentityMappingRules
independent of specific identities. for assigning identities to roles can be implemented and set in the OPC UA server.
There are currently no tools available on the market that allow manufacturer-independent man-
agement of IdentityMappingRules.
5. The rights in the component should be set so According to the OPC UA “Address Space Model” (18), one right that can be defined for a node in
that certain rights are required in order to the OPC UA server is permission to change the rights of this node. If this right is not assigned to a
change rights. role, the rights to this node cannot be changed.
6. The rights in the component should be set so According to the OPC UA “Address Space Model” (18), the individual nodes of an OPC UA server
that certain rights are required in order to set can be determined and (given the corresponding rights), if necessary, it can also be determined
the rules for assigning rights to identities.. which role has which right at this node. When clients are connected individually, roles are
assigned to the session. Which role is to be assigned to which client and for which session can
be implemented and set for each role using IdentityMappingRules according to OPC UA “Infor-
mation Model” (19), because the IdentityMappingRules themselves are implemented as nodes
and can be assigned rights. Since the standard also allows methods to be defined for each role
via which the properties of the IdentityMappingRules can be changed, and because these meth-
ods are themselves their own nodes in the address space of the OPC UA server, rights can also
be set for their use.
Source: Plattform Industrie 4.0
32 S O LU T I O N S K E TC H / D I S C U S S I O N

Integrator’s preparation of handover

Requirement Can be fulfilled by/Point open for discussion

1. It should be possible to adjust in the system the As explained above in the anticipation of repetitive sketches, the OPC UA “Information Model”
authentication criteria, rights and rights assign- (19) explains that, according to the OPC CU standard, rules in the form of IdentityMappingRules
ments (to roles or access rules) defined by the for assigning identities to roles can be displayed and set in the OPC UA server.
integrator for maintenance access. There are currently no tools available on the market that allow manufacturer-independent man-
agement of IdentityMappingRules.
2. The integrator should be able to activate in the If user authentication based on user name and password is possible in the system (for example,
system authentication criteria and rights tempo- with password tables or an integrated LDAP server), a user can be temporarily set with a pass-
rarily needed for the commissioning engineer, so word for the commissioning engineer. This user can be removed in the same way as it was set up.
that the system can authenticate the commis- Alternatively, a user certificate for the commissioning engineer can be temporarily included in
sioning engineer, if required, even without a net- the list of trusted certificates in the security domain of the system or in the integrator’s domain.
work connection, and it should be possible to When a self-signed certificate is used, offline use is even possible without the need for up-to-
remove these rights assignments and authenti- date revocation information. Removing this certificate automatically blocks this explicit access
cation criteria for the commissioning engineer path.
again.
3. The integrator should be able to delete unnec- The mechanisms already mentioned for managing authentication criteria, roles and rights can
essary access paths, authentication criteria and also be removed using mechanisms that conform to the OPC UA standard.
rights from the system. The deactivation of access paths, such as endpoints in the OPC UA servers of systems, however,
is so specific to the system that the integrator should define his own paths here.
Source: Plattform Industrie 4.0

Takeover during commissioning

Requirement Can be fulfilled by/Point open for discussion

1. It should be possible to verify that the system The verifiability of the authenticity of the system can be supported via an endpoint in an OPC
comes from the integrator and is in the state UA server of the system, if, for instance, this endpoint is defined precisely for the purpose and
defined by the integrator. always uses the certificate issued by the integrator to OPC UA clients.
It is left to the system manufacturer to define the exact procedure for verification.
It is to be expected that within the operator‘s environment the system uses other DNS names
and/or IP addresses than those used in the integrator‘s environment.
For security reasons, the OPC UA standard also allows clients to search and compare the DNS
names and/or IP addresses of the endpoint URL in the certificates. For these two reasons, an
exception should be made here, for example, either the OPC UA client should ignore the failed
comparison of DNS names and/or IP addresses during verification or the certificate issued by
the integrator for the installation should not contain any DNS names and/or IP addresses at all.
2. It should be possible to introduce the operator’s OPC UA servers and clients can be designed in compliance with the OPC UA standard, so that
identities together with the ZBN certificates they have and can use multiple identities and the pertinent certificates.
issued by the operator into the system, while
retaining the previous identities and pertinent
certificates

(e. g. ZIN integrator certificates and ZHN certifi-

cates of the component manufacturers).
3. It should be possible to store authentication cri- The previously outlined distribution of trust lists and identity certificates based on certificate
teria for identities of different security domains management via a Global Discovery Server (GDS) allows specific distribution paths for each
separately and simultaneously in the system. security domain.
OPC UA “Discovery” (15) defines three types of trust lists, one for application certificates, one
for user certificates and one for HTTPS certificates. All types are referenced directly from the
ServerConfiguration object via which the respective push management is implemented. However,
according to the solution sketch already explained above, a set of trust lists is required for each
endpoint of a server. This means that each endpoint would have to implement the set of trust
lists below the ServerConfiguration object differently, which would be possible under the standard.
The only thing missing in the standard is the option of initially establishing the provisioning of
another endpoint via an existing endpoint. This is a comfort function which could promote
acceptance of the procedure because it avoids work and facilitates the process. What’s more,
this would create a manufacturer-independent option.
→
 S O LU T I O N S K E TC H / D I S C U S S I O N 33

Takeover during commissioning (continued)

Requirement Can be fulfilled by/Point open for discussion

4. It should be possible to both set and at the The OPC UA “Address Space Model” (18) and “Information Model” (19) specifications define roles as
same time activate rights with reference to the full-scales nodes in the OPC UA address space — with an identifier (role name) and the correspond-
authentication criteria of the identities of a ing namespace. The same name combined with different namespaces results in different nodes.
security domain, so that the system can distin- A separate namespace can be defined for each security domain. Because rights according to the
guish between the operator and the integrator OPC UA standard are always defined in relation to roles, it is possible to define roles with the
(for maintenance) and enforce the correspond- same names and pertinent rights in relation to different security domains without overlapping and
ing rights. colliding by making the names unique; this is achieved by combining them with the namespace of
the security domain. From a technical, OPC UA perspective, these roles are different despite the
fact that the names are identical.
The IdentityMappingRules for domain-specific roles can be used to additionally define that these
roles can only be used for certain endpoints. The endpoints are assigned to exactly one security
domain after the above anticipation of repetitive sketches. The requirement can be met in this way.
Because different security domains should use different certificate hierarchies and autonomously
determine which application has which identity (application URI according to the OPC UA
standard), the restrictions or permissions permitted by the OPC UA standard for certain applica-
tions by naming the application URI should not be defined in the IdentityMappingRules. This is
because they have no fixed reference to a security domain and an attacker could exploit this to
extend the rights from one domain to the other. One remedy here is to only ever permit applica-
tion URIs in conjunction with precisely the endpoint for the role that is assigned to the security
domain from which the application URIs originate.
5. It should be possible to map the descriptions The OPC UA standard defines ways to set certificates for servers and clients. Examples are
actually used by the operator (external roles, already explained above together with certificate management according to OPC UA “Discovery”
external attributes and their characteristics) for (15).
the identities of his personnel and his processes
to designations defined by the integrator (inter-
nal designations).
6. I t must be possible to delete the access rights The solutions described above for setting temporarily active access rights and authentication criteria
and authentication criteria temporarily set in the can be reversed.
system regarding the identities for access by the
commissioning engineer.
Source: Plattform Industrie 4.0

Operation and security maintenance

Requirement Can be fulfilled by/Point open for discussion
1. In the case of identities and the pertinent certif- Certificate management via a GDS allows certificates and key material to be renewed. It implies
icates as well as key material, use of the new material the next time a connection is established.
1.1 it should be possible to renew them without Support for certificate management via GDS is not yet widely used in OPC UA applications.
interruption and For many OPC UA applications, the use of renewed key material and/or the pertinent certificate
requires restarting the application.
1.2 depending on the issuer, it should be possi- It is possible for an OPC UA application (client or server) to obtain its certificates from different
ble to renew them on different paths (inte- Global Discovery Servers (GDSs) at the same time, each for a different number of certificates for
grator certificate versus operator certificate). each GDS. One approach is already explained above in anticipating repetitive sketches.
2. Authentication and authorisation criteria for Certificate management via a GDS allows trust lists to be renewed. It implies use of the new →
identities should be material the next time a connection is established.
OPC UA “Information Model” (19) describes an information model with methods for managing
2.1 renewed regularly and
rights and assigning roles in an OPC UA server to identities.
Role and group assignments can also be managed via LDAP servers if user authentication takes
place via OAuth2.
Because the latest version of the OPC UA “Information Model” (19) is so new, there are currently
no known tools for managing the authorisation criteria in OPC UA servers across different
manufacturers.
→
34 S O LU T I O N S K E TC H / D I S C U S S I O N

Operation and security maintenance (continued)

Requirement Can be fulfilled by/Point open for discussion

2.2 separately for each person responsible Different Global Discovery Servers (GDS) can be used for each security domain. This also supports
(integrator versus operator). different certificate validity periods which can be particularly helpful in the case of comparatively
seldom maintenance access.
For each security domain, separate servers can be used for password authentication of users, as
already explained in the anticipation of repetitive sketches.
The current OPC UA standard does not define a path via which password-based authentication
of users can be configured if the password verification criteria are stored directly on the device.
It is therefore recommended that password-based authentication services that enable password
management be used, such as LDAP and OAuth2.
3. When establishing a connection to the system Within the OPC UA standard, it is possible for OPC UA servers to define different endpoints and
or its components or in the opposite direction, to use different certificates for this. This means that different endpoints can be offered for the
it should be possible to select, OPC UA clients of the different security domains. Within the OPC UA standard, an OPC UA client
can decide each time a connection is established which identity (application URI) to use and
3.1 which identity and which certificate are which certificate to use to identify itself.
relevant (integrator versus operator) and
3.2 which verification criteria are relevant for When the connection is established, OPC UA clients can decide which trust list to use to check
verifying the remote station and its users. the certificate of the OPC UA server. For OPC UA servers, the identity of the endpoint and the
respective certificate can be used to define which trust lists are to be used to verify clients and
their users.
4. Different keys and certificates should be used Current software development kits for OPC UA applications do not support the use of different
for encryption and authentication/signing. keys for signature, authentication and encryption; nor is this included in the OPC UA standard.
Since the procedures in the OPC UA protocol are inherently secure and there is no interference
between the methods, the key pairs for the OPC UA applications should only be used for the
OPC UA protocol.
If a component requires certificates beyond the OPC UA protocol, for instance, to establish
secure communication with other protocols, to receive encrypted files or to generate signatures
for files, separate key pairs and pertinent certificates should be used in each case.
As long as OPC UA applications use the same key pair for the authentication and the negotiation
of the symmetric keys for encrypting communication, a communication inspection at trust
boundaries, for example, using a so-called middlebox, will inevitably always also compromise
authenticity. The OPC UA standard could include supporting properties in the protocol part of
OPC UA, which are also not yet included in other protocols, for example, in the form of a recom-
mendation of different key pairs and an explanation of the mechanisms for this.
Source: Plattform Industrie 4.0

Decommissioning

Requirement Can be fulfilled by/Point open for discussion

1. Components should be able to securely delete This requirement is usually addressed by reset mechanisms that reset the devices to their factory
sensitive data. settings. This deletes all data that has been added to the factory settings, including sensitive
data that was introduced into the component by the integrator or operator. A reset button, for
example, is provided for this purpose.
2. In the infrastructure of the operator and of the If, as suggested, trust lists are distributed using “Certificate Management” via a Global Discovery
integrator, it must be possible to disable access Server (GDS), it is possible to disable components and entire systems. Typically, the applications
partially or completely for components or entire of a system or component are de-registered in the GDS and the pertinent certificates are revoked,
systems. so that this revocation information is distributed at the next opportunity.
For more precise disabling, mechanisms can be used which, according to OPC UA “Address Space
Model” (18) and “Information Model” (19), allow the rights and roles of an OPC UA server to be
modified.
3. In the case of temporary disabling, it should be The disabling mechanisms mentioned above can also be used with temporary effect, because it is
possible to activate and cancel disabling in the also possible to reverse disabling in the same way.
operator and/or integrator’s infrastructure. Note: Temporary disabling requires effective time synchronisation. The correct time is generally
important for security, for instance, also for the time stamps of audit data. At this point, reference
is also made to threat number 37 “Manipulating the time” from the “OPC UA security analysis” by
the Federal Office for Information Security (12).
Source: Plattform Industrie 4.0
 S O LU T I O N S K E TC H / D I S C U S S I O N 35

Contingency measures/Restoration

The discussion of contingency measures and restoration in the lifecycle examination already shows that very system-ori-
entated solutions that use the capabilities of the individual components must be provided in both cases. The latter must be
expected for large and small devices with very specific characteristics, so that it is very difficult and too far-reaching to
outline a general solution in the solution discussion. This is therefore not included in this paper. Only individual, selected
security requirements from contingency measures/restoration are dealt with here:

Requirement Can be fulfilled by/Point open for discussion

1. It should be possible to take snapshots of sys- This is not discussed here because it depends too much on the system, especially due to the
tem and component data (log data, temporary system’s general data and the data protection context.
data, etc.) for forensic purposes, so that they do Part 3 of the OPC UA standard “Address Space Model” (18) defines the concept of audit events.
not contain any sensitive information but still They are suitable for reporting security-relevant processes and can be forwarded to central
allow an analysis of security incidents. systems. However, how these events are recorded and their inclusion in a snapshot depend on
the system.
2. It should be possible to make and restore back- This is not discussed here because it is far too system-specific.
up copies of systems and components in such a
way that sensitive data is still protected in the
backup copies and restoration only transfers the
sensitive data to components in a trusted state.
3. It should be possible to quickly exchange key This can be ensured by distribution via OPC UA GDS. If the key of a component is compromised
pairs and the pertinent certificates in the case of due to an emergency, automatic renewal of the certificate via certificate management is not
components that have probably been compro- sufficient. Automatic renewal may only be used for components with keys that have not been
mised. compromised. For compromised keys, the key pair and the pertinent certificate must be renewed
using manually supported paths, as is the case with the first provisioning of this material.
Systems and components should support the above-mentioned push management (15) for
unscheduled initiation of certificate and key renewal or they should offer a special method or
mechanism for initiating a renewal cycle using pull management.
4. For users, components should support certifi- Certificate management according to OPC UA GDS provides separate trust lists for users and
cate authentication and/or check passwords thus also certificates and key pairs separate from applications (devices and software processes).
using an authentication service. These can therefore be distributed separately when using OPC UA GDS.
For distributing other authentication criteria, such as passwords, OPC UA supports token authen-
tication, for instance, via a JSON Web Token issued by an OAuth2 server. Password verification
can take place behind this via the LDAP server. The password verification criteria can be quickly
renewed there accordingly if necessary.
This would have no direct effect on components and systems.
Source: Plattform Industrie 4.0
36

Summary and outlook

This document discusses the secure integration of a machine In a more detailed document, cross-company communica-
into an operator network with OPC UA. By examining the tion with OPC UA will be examined. An operator model will
requirements over the lifetime of the machine, it can be seen serve as an example here where two stakeholders, i. e. a
that the latest version of the OPC UA standard supports the service provider and a factory operator, have to interact in
necessary functions. Based on the results, suppliers of OPC a secure manner with the same machine. Interaction between
UA toolkits as well as component manufacturers and machine the two security domains and the corresponding require-
designer can develop their offerings further in order to ments for integrity, confidentiality and monitoring will
achieve interoperable and efficient use of the security func- have a key role to play in this analysis.
tions of OPC UA.
 37

Glossary

Authentication data – Data with which a communication or interaction partner (in short: partner) proves its identity to
other partners, i.e. authenticates itself. Partners can be individuals, devices and software processes. The other partners use
authentication criteria to verify the identity accordingly. Authentication data can be a user’s user name and password, for
instance, which the user uses when logging on. Authentication data for devices, for instance, can be a certificate and an
asymmetric key pair.

Authentication criteria – Criteria used to verify the identity of communication and interaction partners; these partners can
be individuals, devices or software processes. A table of user names and password hashes, for instance, includes authentica-
tion criteria to verify the passwords of individual users. The user names are the identity in this case. So-called trust lists
can implement authentication criteria. These are lists that include trusted certificates, issuer certificates, and revocation
information to verify certificates. Individual certificates are used as proof of identity for communication partners.

Integrator – A system manufacturer who builds systems using components and lends them to operators or has them leased
by the operator. In this scenario, the integrator takes over the maintenance of the system.

Trust list – Sets of certificates that are used by a component to collect the certificates of communication and interaction
partners (together: partners). See also authentication criteria: Trust lists are therefore a specific type of authentication cri-
teria. In OPC UA “Discovery” (15), the term “Trust List” (also in the TrustList notation) is used for the trust list. There, a trust
list contains a set of certificates that are trusted by definition. Optionally, a trust list can contain a further set of certificates
that can be used to complete certificate paths from the partners’ certificates to the corresponding root certificates (root CA
certificates). In addition, a trust list can contain a set of revoked certificates based on revocation information.

ZIN – Integrator certificates issued by the integrator to identities created by the integrator for the system and its components.
The purpose of these certificates is to establish beyond a doubt during communication with the systems or components
that communication is with a system created by the integrator or with a component installed by the integrator.

ZBN – Certificates issued by the operator to identities created by the operator for the system and its components, so that
when communicating with the system or components it can be established beyond a doubt that communication is with
a system operated by the operator or with components installed in the system.

ZAN – Certificates within a system issued by the system for identities created by the system, for instance, to enable a security
domain within a system for secure communication by its components.

ZHN – Certificates issued by the manufacturer to identities created by the manufacturer for devices also created by the
manufacturer, for instance, in order to be able to determine the origin of the device without a doubt when communicat-
ing with the device.
38

List of illustrations

Figure 1: Overall “Collaborative Factory” scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Figure 2: Logical interfaces of machine A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Figure 3: Lifecycle phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Figure 4: Breakdown of commissioning into two phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Figure 5: Localisation of the security domains using machine A as an example –

without the manufacturer’s domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Figure 6: Provision of (copies of) trust lists and password verification information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Figure 7: Provision of (copies of) trust lists and password verification information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Figure 8: Overall “Collaborative Factory” scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

 39

References

1. Discussion paper “Sichere Kommunikation für Industrie 4.0”. Berlin: Plattform Industrie 4.0, 2017.

2. Umsetzungsstrategie Industrie 4.0. Berlin/Frankfurt: Plattform Industrie 4.0, 2015.

3. Welche Kriterien müssen Industrie 4.0 Produkte erfüllen? Frankfurt/Main: ZVEI, 2016.

4. Industrial Communication Networks – Network and System Security. IEC 62443.

5. Informationssicherheit in der industriellen Automatisierung. VDI/VDE 2182.

6. IT-Security in der Industrie 4.0: Handlungsfelder für Betreiber. Berlin: Plattform Industrie 4.0, 2016.

7. Information technology – Security Techniques – Information Security Management System. ISO/IEC 27000:2014.

8. Integrität von Daten, Systemen und Prozessen als Kernelement der Digitalisierung. Frankfurt: ZVEI, 2018.

9. NE 153: Automation Security 2020 – Anforderungen an Design, Implementierung und Betrieb künftiger industrieller
Automatisierungssysteme. Leverkusen: NAMUR, 2015.

10. Technical overview of “Sichere unternehmensübergreifende Kommunikation”. Berlin: Plattform Industrie 4.0, 2016.

11. Security der Verwaltungsschale. Berlin/Frankfurt: Plattform Industrie 4.0/ZVEI, 2017.

12. Sicherheitsanalyse OPC UA. s.l.: German Federal Office for Information Security (BSI), 25 April 2016.

13. OPC Unified Architectur. IEC 62541.

14. Practical Security Recommendations for building OPC UA Applications. Scottsdale, AZ: OPC Foundation, 2017.

15. OPC Unified Architecture Part 12: Discovery. OPC Unified Architecture Specification Part 12: Discovery Release 1.03.
s.l.: OPC Foundation, 19 July 2015.

16. OPC Unified Architecture Part 4: Services. OPC Unified Architecture Specification Part 4: Services Release 1.04.
s.l.: OPC Foundation, 22 November 2017.

17. OPC Unified Architecture Mappings. OPC Unified Architecture Specifications Part 6: Mappings Release 1.04.
s.l.: OPC Foundation, 22 November 2017.

18. OPC Unified Architecture Part 3: Address Space. OPC Unified Architecture Specification Part 3: Address Space Model
Release 1.04. s.l.: OPC Foundation, 22 November 2017.

19. OPC Unified Architecture Part 5: Information Model. OPC Unified Architecture Specification Part 5: Information Model
Release 1.04. s.l.: OPC Foundation, 22 November 2017.

20. IEC/TS 62351-8. Technical Specification: Power systems management and associated information exxchange – Data and
communications security – Part 8: Role-based access control. s.l.: International Electrotechnical Commission (IEC).

21. NIST Special Publication 800-162. Guide to Attribute Based Access Control (ABAC) Definition and Considerations.
s.l.: National Institute of Standards and Technology (NIST), January 2014.

22. OPC Unified Architecture for Devices. OPC UA Unified Architecture for Devices Companion Specification Release 1.01.
s.l.: OPC Foundation, 25 July 2013.
40

Appendix: Collaborative Factory

Figure 8 shows the overall “Collaborative Factory“ scenario. This scenario describes interaction between the various
stakeholders in connected production.

Figure 8: Overall “Collaborative Factory” scenario

Enterprise Operator 1
External Cloud

Enterprise Component Manufacturer

Internal Cloud

Internal Cloud

DMZ
Enterprise Operator 2

Internal Cloud

Machine A Machine B
IoT - Gateway IoT - Gateway

Local Switch Local Switch

Source: Plattform Industrie 4.0

Operator

A factory operator, “Operator 1” in this case, operates a production facility in which machines from various suppliers are
used. This example uses a tried-and-tested structure. The company’s processes are linked by a central infrastructure, i. e. the
“enterprise” network. A security zone (demilitarized zone “DMZ”) is set up between the enterprise network and the pro-
duction facilities, which securely separates the two parts. The DMZ and the connections passing through it (indirect access
via DMZ systems, direct access by the DMZ, etc.) must be designed on the basis of the requirements for communication
and security.
 A P P E N D I X : CO L L A B O R AT I V E FA C TO RY 41

Machines in the “Operator Model”

In this example, the machines installed in production are to operate in the “operator model”. They do not belong to the
factory operator, but to the specialised service providers or the machine manufacturers themselves. In the related business
model, “pay per use” could be the option. The suppliers take over maintenance and optimisation for the factory operator.
This model is interesting for the present analysis since the given ownership and responsibility relationships mean that the
factory operator does not have full responsibility and control over the machines, so that security domains have to be
examined on a company-spanning basis.

Collaboration

The most important requirement, of course, is that the machines from the various suppliers operated in the factory must
work together in order to achieve the economic goals pursued by the factory operator. This means that full interoperabil-
ity of all systems and assets involved is essential.

Cloud services

The offerings by external companies to optimise business processes are represented by the “External Cloud”. These offerings
include the services of machine suppliers as well as other possible offerings by other providers. In this respect, the “External
Cloud” symbolises external services outside the area of the factory operator and can comprise several independent offerings.

Other companies involved

In this example, the providers of the machines and the corresponding services are the relevant partners. Other offerings
could, for example, come from the manufacturers of the components installed in the machines.

In principle, it should be noted that the service providers will not only look after one factory operator, i. e. “Operator 1”.
Just as the factory operator uses the services of multiple providers, the service providers, for their part, will support other
factory operators. In terms of the model, this means that service providers process data and information from competing
factory operators.

AUTHORS
Carsten Angeli, KUKA Roboter GmbH | André Braunmandl, Bundesamt für Sicherheit in der Informationstechnik | Kai
Fischer, Siemens AG | Torsten Förder, PHOENIX CONTACT Software GmbH | Prof. Dr. Tobias Heer, Hirschmann Automa-
tion & Control GmbH | Dr. Detlef Houdeau, Infineon Technologies AG | Dr. Lutz Jänicke (Leitung), PHOENIX CONTACT
GmbH & Co KG | Dr. Christian Krug, Geschäftsstelle der Plattform Industrie 4.0 | Fabian Mackenthun, NXP Semiconduc-
tors Germany GmbH | Jens Mehrfeld, Bundesamt für Sicherheit in der Informationstechnik | Andreas Pfaff, Mitsubishi
Electric Europe B.V. | Tobias Pfeiffer, Festo AG & Co. KG | Uwe Pohlmann, Fraunhofer-Institut für Entwurfstechnik
Mechatronik | Martin Regen, Microsoft Deutschland GmbH | Andreas Teuscher, SICK AG | Klaus Theuerkauf, Institut für
Automation und Kommunikation e.V. | Dmitry Tikhonov, Assystem Germany GmbH | Thomas Walloschke, Fujitsu Tech-
nology Solutions GmbH

This publication is a joint result of the working groups “Security of Networked Systems”
and “Reference Architectures, Standards and Norms” (Plattform Industrie 4.0).
www.plattform-i40.de