Evaluation Copy

The Open Group Preliminary Standard

O-PAS™ Standard, Version 2.0

Part 2 – Security

Copyright © 2020 The Open Group, All Rights Reserved

Evaluation Copy. Not for redistribution
 Evaluation Copy

Copyright © 2020, The Open Group

No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic,
mechanical, photocopying, recording or otherwise, without the prior permission of the copyright owners.
Any use of this publication for commercial purposes is subject to the terms of the Annual Commercial License relating to it. For
further information, see www.opengroup.org/legal/licensing.

The Open Group Preliminary Standard

O-PAS™ Standard, Version 2.0: Part 2 – Security
Document Number: P201-2

Published by The Open Group, February 2020.

Comments relating to the material contained in this document may be submitted to:
The Open Group, Apex Plaza, Forbury Road, Reading, Berkshire, RG1 1AX, United Kingdom
or by electronic mail to:
[email protected]

ii The Open Group Preliminary Standard (2020)

Copyright © 2020 The Open Group, All Rights Reserved
Evaluation Copy. Not for redistribution
 Evaluation Copy

Contents
1 Introduction ............................................................................................................... 1
1.1 Objective ......................................................................................................... 1
1.2 Overview......................................................................................................... 1
1.3 Conformance................................................................................................... 2
1.4 Normative References..................................................................................... 2
1.5 Terminology ................................................................................................... 3
1.6 Future Directions ............................................................................................ 3
2 Terms and Definitions ............................................................................................... 4
2.1 Terms .............................................................................................................. 4
3 Security Architecture Framework ............................................................................. 5
3.1 Context ............................................................................................................ 5
3.2 Security Objectives ......................................................................................... 5
3.3 Security Controls ............................................................................................ 6
3.4 Overarching Reference Security Standard ...................................................... 6
3.5 Security Scope ................................................................................................ 8
3.6 Security Level ............................................................................................... 10
3.7 Conformance................................................................................................. 11
4 Evaluation of Security Functionality ...................................................................... 13
4.1 Overview....................................................................................................... 13
4.2 O-PAS Part 4 – O-PAS Connectivity Framework (OCF) ............................ 13
4.2.1 Mapping of OPC UA Parts to the ANSI/ISA 62443
Series ............................................................................................. 13
4.2.2 OPC UA Security Conformance Units .......................................... 13
4.2.3 Time Synchronization Profiles and Timing Security .................... 14
4.2.4 Gap Assessment ............................................................................ 14
4.3 O-PAS Part 5 – System Management ........................................................... 14
4.3.1 Mapping of Redfish to the ANSI/ISA 62443 Series ..................... 14
4.3.2 Assessment of Redfish Schema Security Functionality ................ 15
4.3.3 Gap Assessment ............................................................................ 16
4.4 O-PAS Part 6 – Information and Exchange Models ..................................... 17
4.4.1 Mapping Download/Upload and Import/Export
Models to ANSI/ISA 62443 .......................................................... 17
4.4.2 Gap Assessment ............................................................................ 18
4.5 O-PAS Part 7 – Physical Platform ................................................................ 18
4.5.1 Mapping of Physical Platform to ANSI/ISA-62443-4-2 ............... 18
4.5.2 Gap Assessment ............................................................................ 19
A SEC-001 Security Profile – ANSI/ISA-62443-4-2 SL2 Applicable Security
Requirements for the O-PAS Standard, Version 2.0............................................... 21
B Assessment of OPC UA and Redfish Security Functionality Compared with
ANSI/ISA-62443-4-2 Security Requirements ........................................................ 25
C Abbreviations .......................................................................................................... 29

O-PAS™ Standard, Version 2.0: Part 2 – Security iii

Copyright © 2020 The Open Group, All Rights Reserved
Evaluation Copy. Not for redistribution
 Evaluation Copy

Preface
The Open Group

The Open Group is a global consortium that enables the achievement of business objectives
through technology standards. Our diverse membership of more than 700 organizations includes
customers, systems and solutions suppliers, tools vendors, integrators, academics, and
consultants across multiple industries.

The mission of The Open Group is to drive the creation of Boundaryless Information Flow™
achieved by:
 Working with customers to capture, understand, and address current and emerging
requirements, establish policies, and share best practices
 Working with suppliers, consortia, and standards bodies to develop consensus and
facilitate interoperability, to evolve and integrate specifications and open source
technologies
 Offering a comprehensive set of services to enhance the operational efficiency of
consortia
 Developing and operating the industry’s premier certification service and encouraging
procurement of certified products

Further information on The Open Group is available at www.opengroup.org.

The Open Group publishes a wide range of technical documentation, most of which is focused
on development of Standards and Guides, but which also includes white papers, technical
studies, certification and testing documentation, and business titles. Full details and a catalog are
available at www.opengroup.org/library.

This Document

This document is Part 2 of the O-PAS™ Standard, Version 2.0, a Preliminary Standard of The
Open Group. It has been developed and approved by The Open Group.

The O-PAS Standard consists of the following 12 parts (of the anticipated 13 parts):
 O-PAS Part 1 – Technical Architecture Overview (Informative)
 O-PAS Part 2 – Security (this document)
 O-PAS Part 3 – Profiles (Informative)
 O-PAS Part 4 – O-PAS Connectivity Framework (OCF)
 O-PAS Part 5 – System Management
 O-PAS Part 6.1 – Information and Exchange Models: Overview and Interfaces

iv The Open Group Preliminary Standard (2020)

Copyright © 2020 The Open Group, All Rights Reserved
Evaluation Copy. Not for redistribution
 Evaluation Copy

 O-PAS Part 6.2 – Information and Exchange Models: Basic Configuration

 O-PAS Part 6.3 – Information and Exchange Models: Alarm and Events Configuration
(planned for Version 2.1)
 O-PAS Part 6.4 – Information and Exchange Models: Function Blocks
 O-PAS Part 6.5 – Information and Exchange Models: IEC 61499 Distributed Function
Blocks (planned for Version 2.1)
 O-PAS Part 6.6 – Information and Exchange Models: IEC 61131-3 Programs (planned for
Version 2.1)
 O-PAS Part 7 – Physical Platform

The parts listed above will each be a separate document that can be updated and re-versioned as
required as we move forward with the O-PAS Standard.

The O-PAS Standard, Version 2.0 is being published initially as a Preliminary Standard since it
addresses an emerging area of technology; therefore, it may change before being published as a
full Standard of The Open Group. In such a case it will be made as upwards-compatible as
possible with the corresponding Preliminary Standard, but complete upwards-compatibility is
not guaranteed.

Once this document becomes a full standard, it will supersede the O-PAS Standard, Version 1.0
published in December 2019.

Conventions

A Glossary and Abbreviations reference is available. If a term is not defined in that document
then the common English definition, as defined in Merriam-Webster’s Collegiate Dictionary,
applies.

O-PAS™ Standard, Version 2.0: Part 2 – Security v

Copyright © 2020 The Open Group, All Rights Reserved
Evaluation Copy. Not for redistribution
 Evaluation Copy

Trademarks
ArchiMate®, DirecNet®, Making Standards Work®, Open O® logo, Open O and Check®
Certification logo, OpenPegasus®, Platform 3.0®, The Open Group®, TOGAF®, UNIX®,
UNIXWARE®, and the Open Brand X® logo are registered trademarks and Agile Architecture
Framework™, Boundaryless Information Flow™, Build with Integrity Buy with Confidence™,
Dependability Through Assuredness™, Digital Practitioner Body of Knowledge™, DPBoK™,
EMMM™, FACE™, the FACE™ logo, IT4IT™, the IT4IT™ logo, O-AAF™, O-DEF™, O-
HERA™, O-PAS™, Open FAIR™, Open Platform 3.0™, Open Process Automation™, Open
Subsurface Data Universe™, Open Trusted Technology Provider™, O-SDU™, Sensor
Integration Simplified™, SOSA™, and the SOSA™ logo are trademarks of The Open Group.

JavaScript™ is a trademark of Oracle Corporation and/or its affiliates.

Redfish® is a registered trademark of Distributed Management Task Force, Inc.

All other brands, company, and product names are used for identification purposes only and may
be trademarks that are the sole property of their respective owners.

vi The Open Group Preliminary Standard (2020)

Copyright © 2020 The Open Group, All Rights Reserved
Evaluation Copy. Not for redistribution
 Evaluation Copy

Acknowledgements
The Open Group gratefully acknowledges the International Society of Automation for use of the
ISA copyrighted ANSI/ISA 62443 series of standards. Visit www.isa.org.

The Open Group acknowledges DMTF as copyright owner of the Redfish® standard, which is
used in the O-PAS Standard. DMTF is a not-for-profit association of industry members
dedicated to promoting enterprise and systems management and interoperability. Members and
non-members may reproduce DMTF specifications and documents for uses consistent with this
purpose, provided that correct attribution is given. Additional information is available at:
www.dmtf.org/about/policies/copyright.

The Open Group gratefully acknowledges and thanks the OPC Foundation for the template used
to develop an OPC UA Companion Specification that is included in this O-PAS Standard.

The Open Group is also thankful and acknowledges the International Society of Automation for
use of the ISA copyrighted ANSI/ISA 62443 series of standards.

The Open Group gratefully acknowledges the contribution of the following people in the
development of this document:

Lead Contributors

 Ron Breault – Wind River

 Camilo Gomez – Yokogawa Electric Corporation
 Timothy Mirth – Rockwell Automation

Additional Contributors

 Mark Bush – Avistar Consulting

 Sean Conley – Raytheon Company
 Luis Duran – ABB Automation GmbH
 David Fort – Rockwell Automation
 Craig Griffin – Wind River
 Sung Lee – Intel
 Sølve Raaen – Kongsberg Maritime
 Santosh Suryawanshi – Tata Consultancy Services

O-PAS™ Standard, Version 2.0: Part 2 – Security vii

Copyright © 2020 The Open Group, All Rights Reserved
Evaluation Copy. Not for redistribution
 Evaluation Copy

Referenced Documents
The following documents are referenced in Part 2 of the O-PAS Standard.

The documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this part. For dated references, only the version cited applies. For
undated references, the latest version of the referenced document (including any amendments)
applies.

(Please note that the links below are good at the time of writing but cannot be guaranteed for the
future.)

Normative References

Normative references for Part 2 of the O-PAS Standard are defined in Section 1.4.

Informative References

 ANSI/ISA-62443-1-1:2007: Security for Industrial Automation and Control Systems –

Part 1-1: Terminology, Concepts, and Models (adopted by IEC as IEC 62443-1-1)
 ANSI/ISA-62443-2-1:2009: Security for Industrial Automation and Control Systems –
Part 2-1: Establishing an Industrial Automation and Control Systems Security Program
(adopted by IEC as IEC 62443-2-1)
 ANSI/ISA-TR62443-2-3:2015: Security for Industrial Automation and Control Systems –
Part 2-3: Patch Management in the IACS Environment (adopted by IEC as IEC TR
62443-2-3)
 ANSI/ISA-62443-2-4:2018: Security for Industrial Automation and Control Systems –
Part 2-4: Security Program Requirements for IACS Service Providers (adopted from IEC
62443-2-4)
 ANSI/ISA-TR99.00.01-2007: Industrial Communication Networks – Network and System
Security – Part 3-1: Security Technologies for Industrial Automation and Control Systems
(adopted as IEC TR 62443-3-1:2009)
 Industrial Internet Consortium: IIC Endpoint Security Best Practices,
IIC:WHT:IN17:V1.0:PB:20180312
 Industrial Internet Consortium: Industrial Internet of Things Volume G4: Security
Framework, IIC:PUB:G4:V1.0:PB:20160926
 Industrial Internet Consortium: IoT Security Maturity Model: Description and Intended
Use, IIC:PUB:IN15:V1.0:PB:20180409
 ISO/IEC 27002:2013: Information Technology – Security Techniques – Code of Practice
for Information Security Controls

viii The Open Group Preliminary Standard (2020)

Copyright © 2020 The Open Group, All Rights Reserved
Evaluation Copy. Not for redistribution
 Evaluation Copy

 NIST Federal Information Processing Standard (FIPS) Publication 140-2 (FIPS PUB
140-2): Security Requirements for Cryptographic Modules, May 2001
 NIST Special Publication (SP) 800-53 Rev. 5 (DRAFT): Security and Privacy Controls
for Information Systems and Organizations, August 2017
 NIST Special Publication (SP) 800-82 Rev. 2: Guide to Industrial Control Systems (ICS)
Security, May 2015
 NIST White Paper: Framework for Improving Critical Infrastructure Cybersecurity,
Version 1.1, April 2018
 O-PAS Standard, Version 2.0: Part 4 – O-PAS Connectivity Framework (OCF), The Open
Group Preliminary Standard (P201-4), February 2020, published by The Open Group;
refer to: www.opengroup.org/library/p201
 O-PAS Standard, Version 2.0: Part 5 – System Management, The Open Group
Preliminary Standard (P201-5), February 2020, published by The Open Group; refer to:
www.opengroup.org/library/p201
 O-PAS Standard, Version 2.0: Part 6.1 – Information and Exchange Models: Overview
and Interfaces, The Open Group Preliminary Standard (P201-6a), February 2020,
published by The Open Group; refer to: www.opengroup.org/library/p201
 O-PAS Standard, Version 2.0: Part 7 – Physical Platform, The Open Group Preliminary
Standard (P201-7), February 2020, published by The Open Group; refer to:
www.opengroup.org/library/p201
 Redfish®, DMTF; refer to: https://www.dmtf.org/standards/redfish
 Requirements for an Open Process Automation™ Standard, White Paper (W184), May
2018, published by The Open Group; refer to: www.opengroup.org/library/w184
 The Open Process Automation™ Business Guide, The Open Group Guide (G182),
January 2018, published by The Open Group; refer to: www.opengroup.org/library/g182

O-PAS™ Standard, Version 2.0: Part 2 – Security ix

Copyright © 2020 The Open Group, All Rights Reserved
Evaluation Copy. Not for redistribution
 Evaluation Copy

x The Open Group Preliminary Standard (2020)

Copyright © 2020 The Open Group, All Rights Reserved
Evaluation Copy. Not for redistribution
 Evaluation Copy

1 Introduction

1.1 Objective
The objective of Part 2 of the O-PAS Standard is to define the Security Architecture Framework
for the O-PAS Standard, including:
 Identification of the overarching cybersecurity reference standard for industrial
automation and control systems in alignment with the Open Process Automation™ Forum
(OPAF) member requirements and industry best practices
 Identification of relevant security requirements in the overarching cybersecurity reference
standard applicable to the O-PAS functionality defined in O-PAS Part 4 – O-PAS
Connectivity Framework (OCF), O-PAS Part 5 – System Management, O-PAS Part 6 –
Information and Exchange Models, and O-PAS Part 7 – Physical Platform
 Evaluation of the security functionality of the standards defined in O-PAS Part 4 – O-PAS
Connectivity Framework (OCF) and O-PAS Part 5 – System Management in reference to
the overarching cybersecurity standard and the overall Security Architecture
 Evaluation of embedded security functionality in the reference standards defined and used
in O-PAS Part 4 – O-PAS Connectivity Framework (OCF), O-PAS Part 5 – System
Management, O-PAS Part 6 – Information and Exchange Models, and O-PAS Part 7 –
Physical Platform in relation to the overarching cybersecurity standard and the overall
Security Architecture

This document expands from cybersecurity in support of the interoperability of components,

which was the main objective of the O-PAS Standard, Version 1.0, to cybersecurity in support of
configuration portability which is the main objective of the O-PAS Standard, Version 2.0.

1.2 Overview
Cybersecurity is an O-PAS imperative and of upmost importance to OPAF stakeholders. Until
now, cybersecurity for the Operations Technology (OT) space has been largely focused on the
protection of existing (brownfield) and new (greenfield) implementations characterized by add-
on procedural and technical countermeasures to mitigate security risk and prevent impact to the
safety and operation of industrial environments.

An O-PAS environment may be composed of thousands of O-PAS conformant components from

multiple vendors. Thus, managing security in a highly distributed environment, such as the
O-PAS environment, requires security to be considered in all elements of the Technical
Architecture – from the hardware platform to the applications, passing through the operating
system, the communications platform, configuration information, and system management
services.

O-PAS™ Standard, Version 2.0: Part 2 – Security 1

Copyright © 2020 The Open Group, All Rights Reserved
Evaluation Copy. Not for redistribution
 Evaluation Copy

It is important to note that an O-PAS conformant product can be a Distributed Control Node
(DCN) device and its internal components, or it can be just an O-PAS conformant application in
the form of a software program that can be installed on a DCN from any vendor. An O-PAS
application is a core element subject to security control.

The O-PAS Standard aims to integrate and maintain security throughout the lifecycle of
conformant components.

The use of certified components does not guarantee that the automation system or the installation
will be secure. It is the responsibility of the system integrator and/or end user to assess whether
the target security level (as defined in the ANSI/ISA 62443 standards) of the implementation is
met.

1.3 Conformance
Conformance requirements related to aspects of the Security Architecture Framework are
described in Section 3.7 of this document.

Conformance requirements related to integrated security, functionality, or security features

defined in the standards used in O-PAS Part 4 – O-PAS Connectivity Framework (OCF) and O-
PAS Part 5 – System Management are defined directly in those documents.
Conformance requirements related to O-PAS Part 6 – Information and Data Exchange Model
and O-PAS Part 7 – Physical Platform are defined in Section 4.5 of this document considering
that the reference standards used in those parts do not define security functions or interfaces.

1.4 Normative References

The following standards contain provisions which, through references in this document,
constitute provisions of Part 2 of the O-PAS Standard. At the time of publication, the editions
indicated were valid. All standards are subject to revision, and parties to agreements based on
this document are encouraged to investigate the possibility of applying the most recent editions
of the standards listed below.
 ANSI/ISA-62443-3-3:2013: Security for Industrial Automation and Control Systems –
Part 3-3: System Security Requirements and Security Levels (adopted by IEC as IEC
62443-3-3)
 ANSI/ISA-62443-4-1:2018: Security for Industrial Automation and Control Systems –
Part 4-1: Product Security Development Lifecycle Requirements (adopted by IEC as IEC
62443-4-1)
 ANSI/ISA-62443-4-2:2018: Security for Industrial Automation and Control Systems –
Part 4-2: Technical Security Requirements for IACS Components (adopted by IEC as IEC
62443-4-2)
 IEEE 1588-2008: IEEE Standard for a Precision Clock Synchronization Protocol for
Networked Measurement and Control Systems; refer to:
https://standards.ieee.org/standard/1588-2008.html
 Redfish® Scalable Platforms Management API Specification, DSP0266 V1.6.0, DMTF

2 The Open Group Preliminary Standard (2020)

Copyright © 2020 The Open Group, All Rights Reserved
Evaluation Copy. Not for redistribution
 Evaluation Copy

 Redfish® Scalable Interoperability Profiles Specification, DSP0272 V1.0.1, DMTF

 Redfish® Resource and Schema Guide, DSP8010 V2018.2, DMTF
 Unified Architecture (UA) Specification, Part 2: Security Model (also IEC 62541-2:2016),
OPC Foundation; refer to: http://www.opcfoundation.org/UA/Part2/
 Unified Architecture (UA) Specification, Part 4: Services (also IEC 62541-4:2015), OPC
Foundation; refer to: http://www.opcfoundation.org/UA/Part4/
 Unified Architecture (UA) Specification, Part 5: Information Model (also IEC 62541-
5:2015), OPC Foundation; refer to: http://www.opcfoundation.org/UA/Part5/
 Unified Architecture (UA) Specification, Part 6: Mappings (also IEC 62541-6:2015), OPC
Foundation; refer to: http://www.opcfoundation.org/UA/Part6/
 Unified Architecture (UA) Specification, Part 7: Profiles (also IEC 62541-7:2015), OPC
Foundation; refer to: http://www.opcfoundation.org/UA/Part7/
 Unified Architecture (UA) Specification, Part 12: Discovery and Global Services (also
IEC 62541-12), OPC Foundation; refer to: http://www.opcfoundation.org/UA/Part12/
 Unified Architecture (UA) Specification, Part 14: PubSub (also IEC 62541-14), OPC
Foundation; refer to: https://opcfoundation.org/developer-tools/specifications-unified-
architecture/part-14-pubsub

1.5 Terminology
For the purposes of the O-PAS Standard, the following terminology definitions apply:

Can Describes a possible feature or behavior available to the user or application.

May Describes a feature or behavior that is optional. To avoid ambiguity, the opposite of
“may” is expressed as “need not”, instead of “may not”.

Shall Describes a feature or behavior that is a requirement. To avoid ambiguity, do not

use “must” as an alternative to “shall”.

Shall not Describes a feature or behavior that is an absolute prohibition.

Should Describes a feature or behavior that is recommended but not required.

Will Same meaning as “shall”; “shall” is the preferred term.

1.6 Future Directions

The contents and security scope of Part 2 of the O-PAS Standard are directly related to the scope
and overall functional objectives of the O-PAS Standard, Version 2.0.

A future version of the O-PAS Standard will address additional functionality such as software
portability, software application management, and extended physical platform functionality
among possible others. At that time, Part 2 will be revised and updated accordingly.

O-PAS™ Standard, Version 2.0: Part 2 – Security 3

Copyright © 2020 The Open Group, All Rights Reserved
Evaluation Copy. Not for redistribution
 Evaluation Copy

2 Terms and Definitions

For the purposes of the O-PAS Standard, the following terms and definitions apply. Merriam-
Webster’s Collegiate Dictionary should be referenced for terms not defined in this section.

2.1 Terms
For the glossary of terms, see the O-PAS definitions here.

4 The Open Group Preliminary Standard (2020)

Copyright © 2020 The Open Group, All Rights Reserved
Evaluation Copy. Not for redistribution
 Evaluation Copy

3 Security Architecture Framework

3.1 Context
A principle of the O-PAS Technical Architecture is that it will not compromise the safety,
resilience, reliability, maintainability, and security of process automation systems. With the
potential of tens of thousands of nodes and applications in an O-PAS conformant environment,
security should be done without extensive manual intervention, through secure communication
between elements and ensuring that only valid and authorized commands are executed. Thus,
security should be designed in all aspects.

The purpose of this Security Architecture Framework is to describe the overarching security
concepts and elements that product suppliers need to integrate and address when developing
O-PAS conformant products.

3.2 Security Objectives

As threats to critical infrastructure are becoming more prevalent it is imperative for these
systems to achieve a certain level of security by utilizing components that have the following
security objectives designed into them:
 Availability is the property of ensuring timely and reliable access to and use of control
system information and functionality
Availability against security-related outages can be achieved through implementation of
Denial of Service (DoS) mitigations, redundant communication paths, and unauthorized
access mitigations.
 Integrity is the property of protecting the accuracy and completeness of assets, and the
guarding against improper modification or destruction of data
Integrity is usually implemented by comparing hashes of the data at different points in
time to ensure nothing has changed.
 Confidentiality is the assurance that information is not disclosed to unauthorized
individuals, processes, or devices
Confidentiality is typically achieved through encryption such that only authorized parties
have the information needed to decrypt and access the data.
 Identification, Authentication, and Authorization are all inter-related aspects:
— Identification refers to the ability to uniquely identify each entity acting on a system
for the purposes of authentication, authorization, and auditability
— Authentication is the ability to prove that a system actor is who they claim to be
— Authorization defines which operations an actor is allowed to perform on a given
resource

O-PAS™ Standard, Version 2.0: Part 2 – Security 5

Copyright © 2020 The Open Group, All Rights Reserved
Evaluation Copy. Not for redistribution
 Evaluation Copy

 Non-repudiation is a security service that provides protection against false denial of

involvement in a communication, the ability to prove the occurrence of a claimed event or
action and its originating entities, and assurance that the sender of information is provided
with proof of delivery and the recipient is provided with proof of the sender’s identity, so
neither can later deny having processed the information
 Auditability and Accountability are the acts of logging which actions are taken on a
system to ensure that the actions of a system entity may be traced uniquely to that entity,
which can be held responsible for its actions
The resulting logs can be used to detect anomalies and perform root-cause analysis after
an incident occurs. They are also used in proving adherence to standards and regulations
during audits.

3.3 Security Controls

Some of the controls used to implement the security objectives, outside of the component
specifications defined in the O-PAS Standard, include:
 Segmentation is the act of dividing the system network into different sections or zones
based on trust levels and other security attributes in order to place access restrictions, or to
define different security objectives, security targets, or security levels on each zone
The benefit of this network segmentation is to limit the damage a malicious actor can do
once they have breached a system. Network segmentation is typically accomplished with
firewalls and Virtual Local Area Networks (VLANs).
 Anomaly Detection involves monitoring the system for behavior or data that is
significantly different from the desired or normal state and events of the system
These anomalies often indicate some sort of problem within the system. Anomaly
detection is typically done by applications built for this specific purpose.
 Incident Response is the process for managing the aftermath of a security breach or
cyber-attack with the goal of limiting damage and reducing recovery time and cost
This can include some automated components, but typically involves a manual process for
assessing the situation and determining the best strategic course of action.

Cybersecurity is an important consideration for any type of organization to protect against loss
of revenue and reputation from a security breach. In an Industrial Automation and Control
System (IACS) it plays an especially critical role in preventing product and equipment damage
or even potential disasters ranging from food and water contamination to nuclear meltdowns.
These systems will need to take advantage of future state technologies based on Industrial
Internet of Things (IIoT) connectivity and off-premise cloud services. This is the motivation for
the secure by design vision.

3.4 Overarching Reference Security Standard

The O-PAS Standard defers to the ANSI/ISA 62443 standards as the overarching reference
standard for security. The ANSI/ISA 62443 standards are known as the global standard for
security of IACS. It is a robust series of standards that covers all aspects of securing an IACS at
both the component and system level throughout its lifecycle.

6 The Open Group Preliminary Standard (2020)

Copyright © 2020 The Open Group, All Rights Reserved
Evaluation Copy. Not for redistribution
 Evaluation Copy

Figure 1 shows that at a high-level the ANSI/ISA 62443 standards map to all of the O-PAS
objectives, making it a good choice of reference standard on what shall be required for securing
an O-PAS component. The columns identify the ANSI/ISA 62443 foundational requirements,
mapped against the rows of the O-PAS objectives. The blue dots indicate where the ANSI/ISA
62443 requirements map to the O-PAS objectives.

ANSI/ISA 62443 Series

Foundational Requirements

ol
ntr
Co
on

ts
ati

en
ntic

Ev
the

i lity
to
lity
F lo
Au

il ab
se
tia
y

ta
on
t
n&

i
en

va
r

a
eg

sp
Ti m ed D
ol

fi d

eA
tio

In t

Re
r

n
t
fica

on

urc
Co

ict
m

el y
eC

ste
nti

str

so
ta
Id e

Da

Re

Re
Us

Sy
O-PAS Objectives FR1 FR2 FR3
UseFR4
control
FR5 FR6 FR7

Identification ●
Authentication ●
Non-repudiation ● ●
Authorization ●
Integrity ●
Anomaly Detection ●
Confidentiality ●
Segmentation ●
Auditability/Accountability ●
Availability ●
Incident Response ●
Figure 1: Mapping to ANSI/ISA 62443 Foundational Requirements

In addition, the O-PAS Standard was developed using the following key end-user security-
related requirements:
 The O-PAS architecture shall take advantage of existing industry standards whenever
possible and practical and consistent with achieving the goals of the O-PAS Standard
 O-PAS components shall meet or exceed the Security Levels (SLs) defined in industry
standards, as determined by the system owner
 The O-PAS Standard shall allow for the development of O-PAS components using secure
programming practices and restrictions

The ANSI/ISA 62443 standards meet all of these requirements. When this document refers to an
ANSI/ISA 62443 requirement it is the reader’s responsibility to refer to ANSI/ISA 62443 for

O-PAS™ Standard, Version 2.0: Part 2 – Security 7

Copyright © 2020 The Open Group, All Rights Reserved
Evaluation Copy. Not for redistribution
 Evaluation Copy

details. Those interested in participating in development of O-PAS components are responsible

for referring to ANSI/ISA 62443 for the content of the requirements included therein.

3.5 Security Scope

As illustrated in Figure 2, the ANSI/ISA 62443 series is a comprehensive collection of parts
intended to address the security needs of the different stakeholders in an IACS environment and
supply chain. Stakeholders include asset owners, service providers, system integrators, and
product suppliers.

IACS Environment and/or Project-specific Industrial Automation and Control System (IACS)
Relevant Parts
ANSI/ISA-62443-2-3
Asset Owner Operates and Operational Maintenance ANSI/ISA-62443-2-4
Service Provider Maintains Policies and Policies and
Procedures Procedures

Automation Solution Relevant Parts

System Designs ANSI/ISA-62443-2-3
and Deploys Control Safety Complementary
Integrator ANSI/ISA-62443-2-4
Functions Functions Functions
ANSI/ISA-62443-3-3

Independent of the IACS Environment

Control Embedded Host Relevant Parts
Systems Devices Devices ANSI/ISA-62443-3-3
Product Develops
ANSI/ISA-62443-4-1
Supplier Network
Applications ANSI/ISA-62443-4-2
Components

Figure 2: Grouping of ANSI/ISA 62443 Parts

As shown in Figure 3, the purpose of the O-PAS architecture is to define, build, and maintain
IACS components in the form of O-PAS conformant DCN devices and software applications,
independently of any specific IACS environment or project. Refer to the Open Process
Automation Business Guide for details on the lifecycle stages.

8 The Open Group Preliminary Standard (2020)

Copyright © 2020 The Open Group, All Rights Reserved
Evaluation Copy. Not for redistribution
 Evaluation Copy

Scope of O-PAS Security Specification

ANSI/ISA-62443-4-2

Role Hardware Software Subsystem System Service

End User
Lifecycle Supplier Supplier Integrator Integrator Supplier
Stage

Greenfield/Brownfield
Define Upgrade or Replace

Design & Design & Design & Design & Define

Define Requirements
Acquire Acquire Acquire Acquire

Build Build & Test Build & Test Build & Test Build & Test

Install Install

Deploy
Assure Assure

Operate

Maintain Maintain Maintain

Update Update Update Update Update

12/13/2019
Replace Decommission
or Replace

Figure 3: O-PAS Lifecycle and Security Scope

In consequence, the ANSI/ISA 62443-relevant part in scope for the O-PAS Security
Architecture Framework is:
 ANSI/ISA-62443-4-2:2018: Security for Industrial Automation and Control Systems –
Part 4-2: Technical Security Requirements for IACS Components (adopted by IEC as IEC
62443-4-2)

Notice, however, as illustrated in Figure 2, that there are two other ANSI/ISA-62443 parts
related to the Product Supplier associated with the ANSI/ISA-62443-4-2 component security
part that are indirectly relevant:
 ANSI/ISA-62443-3-3:2013: Security for Industrial Automation and Control Systems –
Part 3-3: System Security Requirements and Security Levels (adopted by IEC as IEC
62443-3-3)
 ANSI/ISA-62443-4-1:2018: Security for Industrial Automation and Control Systems –
Part 4-1: Product Security Development Lifecycle Requirements (adopted by IEC as IEC
62443-4-1)
The first is related to requirements for lifecycle product security development and maintenance
applicable to organizations developing components, and a prerequisite of ANSI/ISA-62443-4-2;
and the second is related to requirements for system security applicable to organizations
developing systems and subsystems as a product with direct mapping to component security
requirements in ANSI/ISA-62443-4-2.

O-PAS™ Standard, Version 2.0: Part 2 – Security 9

Copyright © 2020 The Open Group, All Rights Reserved
Evaluation Copy. Not for redistribution
 Evaluation Copy

3.6 Security Level

Security Level (SL) is a key concept for the O-PAS Standard, as it has to do with the level of
cybersecurity protection that a component is capable of compared to the level of cybersecurity
protection desired by the asset owner for a particular industrial automation solution.

As defined in ANSI/ISA-62443-3-3, there are three different types of SL:

1. Target SL (SL-T): Desired level of security for a particular automation solution. Defined
by the asset owner, or defined by the system integrator/service provider in conjunction
with the asset owner based on risk assessment.
2. Capability SL (SL-C): Security level that a component can provide when properly
configured. Defined by the product supplier. Demonstrable through conformance testing
or certification.
3. Achieved SL (SL-A): Actual level of security for a particular automation solution after
implementation. Demonstrable by the system integrator/service provider to the asset
owner.

Notice the difference between the three. For the purpose of the O-PAS Standard, Security Level
(SL) refers to Capability SL (SL-C).

The ANSI/ISA 62443 series defines five security levels: the higher the number, the higher the
level of protection. They are defined as follows:
 SL0: no security protection necessary/provided
 SL1: capable of protecting against casual or coincidental violation
 SL2: capable of protecting against intentional violation using simple means with low
resources, generic skills, and low motivation
 SL3: capable of protecting against intentional violation using sophisticated means with
moderate resources, IACS-specific skills, and moderate motivation
 SL4: capable of protecting against intentional violation using sophisticated means with
extended resources, IACS-specific skills, and high motivation

In order to meet the interoperability and configuration portability requirements targeted for the
O-PAS Standard, Version 2.0, components need to meet ANSI/ISA-62443-4-2 SL2 capability as
a minimum. This is because there are certain requirements for SL2 and above that are not able to
interoperate with SL1-only capability. For example, SL2 and above require that the system
under test rejects any usage of invalid session IDs. A session meeting only SL1 requirements
might use a session ID that would be deemed invalid for SL2 and above. See Appendix A for a
list of applicable SL2 requirements.

The fact that O-PAS products must meet SL2 does not limit product suppliers to SL2. Product
suppliers can build products with higher SL capability as required by asset owners. Higher
security capability levels (above SL2) are not in the scope of the O-PAS Standard.

Asset owners who choose to incorporate components with less than SL2 capability in an
otherwise O-PAS conformant system must accept the risks that these components may not

10 The Open Group Preliminary Standard (2020)

Copyright © 2020 The Open Group, All Rights Reserved
Evaluation Copy. Not for redistribution
 Evaluation Copy

function technically and that the as-built system’s capability and achieved security levels will be
less than SL2.

Notice that, based on the O-PAS interoperability and configuration portability functionality
specified in Version 2.0, not all ANSI/ISA-62443-4-2 SL2 applicable requirements are in scope
(see Appendix for a list of applicable requirements for Version 2.0).

3.7 Conformance
The aim of this Security Architecture Framework is to ensure:
 Security functionality is integrated in O-PAS components (i.e., devices and applications)
 Security is designed in all stages of the product lifecycle
 Specification of interfaces that provide the necessary security controls to meet both
O-PAS functionality and security requirements in ANSI/ISA-62443-4-2

Regarding cybersecurity conformance for the O-PAS Standard, Version 2.0, product suppliers
developing O-PAS conformant products shall implement the applicable ANSI/ISA-62443-4-2
component security requirements identified in the security profile of this document (see
Appendix A). Product suppliers should also plan to address in the future any not-yet-in-scope
applicable ANSI/ISA-62443-4-2 SL2 requirements, as well as ANSI/ISA-62443-4-2 prerequisite
requirements such as conformance with ANS/ISA-62443-4-1 Product Security Development
Lifecycle Requirements applicable to the Product Supplier organization (see Appendix A for a
list of applicable requirements for Version 2.0).

The Open Group is in the process of executing an agreement with the ISASecure1 organization
whereby ISASecure will have the ability and authority to execute security testing on the
elements of the subset of ANSI/ISA-62443-4-2 required by OPAF (see Figure 4). Companies
who desire to demonstrate their O-PAS security requirements conformance must commercially
engage The Open Group and ISASecure – or any other accredited verification authority that may
be so designated by The Open Group – for this effort.

1
See www.isasecure.org.

O-PAS™ Standard, Version 2.0: Part 2 – Security 11

Copyright © 2020 The Open Group, All Rights Reserved
Evaluation Copy. Not for redistribution
 Evaluation Copy

Set of O-PAS
Standard,
The O-PAS Version 2.0
Full ANSI/ISA-
Standard, Security
62443-4-2
Version 2.0 Requirements
Requirements
Requirements in scope for
ISASecure
testing

Figure 4: The O-PAS Standard, Version 2.0 Security Requirements in Testing Scope

Upon successful completion of testing (100% conformance to the required O-PAS Standard,
Version 2.0 security requirements), ISASecure would convey conformance to The Open Group.
To be clear, this is not an ISASecure certification, but a statement of formal conformance to the
applicable O-PAS security requirements. The Open Group would then take this security
conformance into consideration for formal O-PAS certification (together with any other
conformance requirements, depending on the selected profile).

Note For product suppliers considering more broad certification (e.g., ANSI/ISA-62443-4-
2), it should be noted that the ANSI/ISA-62443-4-1 standard is a prerequisite to
ANSI/ISA-62443-4-2 certification. To be clear, neither ANSI/ISA-62443-4-1 nor
ANSI/ISA-62443-4-2 certification is required by the O-PAS Standard, Version 2.0 but
both are considered desirable.

12 The Open Group Preliminary Standard (2020)

Copyright © 2020 The Open Group, All Rights Reserved
Evaluation Copy. Not for redistribution
 Evaluation Copy

4 Evaluation of Security Functionality

4.1 Overview
This section contains a summary of the assessment of the security-related functionality (and/or
any gaps) defined in O-PAS Part 4 – O-PAS Connectivity Framework (OCF), O-PAS Part 5 –
System Management, O-PAS Part 6 – Information and Exchange Models, and O-PAS Part 7 –
Physical Platform, against relevant requirements in the ANSI/ISA-62443-4-2 cybersecurity
reference standard.

Sections 4.2 and 4.3 provide details on the mapping of security features in the OPC Unified
Architecture (UA), the reference standard used in O-PAS Part 4 – O-PAS Connectivity
Framework (OCF), and the Redfish® standard, the reference standard used in O-PAS Part 5 –
System Management, against requirements in the ANSI/ISA-62443-4-2 cybersecurity reference
standard.

Section 4.4 provides details of relevant security requirements necessary to protect configuration
data while in motion and at rest as required by the import/export and download/upload models
described in O-PAS Part 6 – Information and Exchange Models.

Section 4.5 provides details of relevant security requirements applicable to O-PAS Part 7 –
Physical Platform.

4.2 O-PAS Part 4 – O-PAS Connectivity Framework (OCF)

4.2.1 Mapping of OPC UA Parts to the ANSI/ISA 62443 Series
The Unified Architecture (UA) specification is published by the OPC Foundation and is
composed of 14 parts. The OPC UA Specification: Part 2 – Security Model defines the security
model for securing communications between OPC UA applications. However, detailed
descriptions of security features are distributed throughout other parts of the specification.

Implementations of OPC UA client/server and pub/sub software will be common in O-PAS

components, thus security vulnerabilities in this software layer could affect an entire automation
solution. The OPC UA specification has a rich set of security features that can be utilized to
mitigate this risk. A mapping of these features was performed against ANSI/ISA-62443-4-2 to
determine gaps against the set of SL2 requirements.

Appendix B provides mapping of OPC UA security functionality described in O-PAS Part 4 –

O-PAS Connectivity Framework (OCF) with ANSI/ISA-62443-4-2 SL2 requirements.

4.2.2 OPC UA Security Conformance Units

Individual OPC UA security features are grouped into conformance units which are further
grouped into facets and profiles. A conformance unit is a specific set of OPC UA features that
can be tested as a single entity.

O-PAS™ Standard, Version 2.0: Part 2 – Security 13

Copyright © 2020 The Open Group, All Rights Reserved
Evaluation Copy. Not for redistribution
 Evaluation Copy

Refer to O-PAS Part 4 – O-PAS Connectivity Framework (OCF) for the set of OPC UA security
facets and profiles with the associated conformance units required by the functionality described
in that part.

4.2.3 Time Synchronization Profiles and Timing Security

There are two time synchronization profiles defined in O-PAS Part 4 – O-PAS Connectivity
Framework (OCF). These profiles identify IEEE 1588-2008 as the mandatory standard for non-
Time-Sensitive Networking (TSN)-based profiles: the Media-independent Time Synchronization
Profile, and the Ethernet-based Time Synchronization Profile. IEEE 1588-2008 includes an
optional (informative) Annex K, which identifies a security protocol. This protocol is tagged as
“experimental”.

4.2.4 Gap Assessment

Most OPC UA specification security features map with the applicable set of ANSI/ISA-62443-4-
2 SL2 requirements (see Appendix B for a comparison of OPC UA functionality in O-PAS Part
4 – O-PAS Connectivity Framework (OCF) with ANSI/ISA-62443-4-2-relevant requirements).

While IEEE 1588-2008 establishes an important base for time synchronization, the security
aspects of the specification have less emphasis. Based on research and industry consultation, the
IEEE committee responsible for IEEE 1588-2008 decided to deprecate the experimental Annex
K security protocol. Since that decision, the committee has been at work on a revised version of
the standard. This revised specification will include new optional clauses which will better
address security requirements on time synchronization. Areas of coverage are said to include
source authentication, message integrity, and reply attack protection. At the time of development
of this document, the revised IEEE 1588 specification was not yet published or available for
external comment.

Until such time as the new IEEE 1588 specification is released (and this document updated),
organizations developing products which follow the two aforementioned O-PAS synchronization
profiles should research the security aspects of IEEE 1588-2008 and mitigate potential risks
through other means (network segregation, firewalls, etc.). More specific security
recommendations for IEEE 1588-2008 are beyond the scope of this document.

4.3 O-PAS Part 5 – System Management

4.3.1 Mapping of Redfish to the ANSI/ISA 62443 Series
The Redfish standard is comprised of a set of specifications maintained by the Distributed
Management Task Force (DMTF). The standard defines a protocol to provide access to data and
operations associated with the management of systems and networks. Redfish was designed as
an open industry standard for secure system management in multi-vendor deployments which
can scale to large numbers of systems. The Redfish standard API easily integrates with
commonly used tools, uses RESTful interfaces to perform operations, and uses JavaScript™
Object Notation (JSON) and OData formats for data payloads.

Delivering IACS security for system management depends on both external security service
capabilities (such as identity management applications, network firewalls, etc.) and the system
management security requirements embedded in the interface standard (in this case, Redfish).

14 The Open Group Preliminary Standard (2020)

Copyright © 2020 The Open Group, All Rights Reserved
Evaluation Copy. Not for redistribution
 Evaluation Copy

The Redfish standard security requirements are driven from the IT industry which has many
common requirements with IACS systems, making it a good candidate for this assessment.

As previously discussed, the O-PAS Standard frames security requirements and capabilities for
IACS using the ANSI/ISA 62443 series as a reference standard. While the ANSI/ISA 62443
standards provide a solid foundation for what the security requirements are, they do not specify
how these requirements should be implemented. The Redfish standard API provides an
implementation of a set of the security requirements that pertain to system management.

4.3.2 Assessment of Redfish Schema Security Functionality

Table 1 provides an overview of the security control foundational requirement areas of the
ANSI/ISA 62443 series and how they can be addressed with the Redfish API capabilities, as
follows:
 The first column lists the ANSI/ISA 62443 requirement area
 The second column provides external service dependencies that would be required to
interact with Redfish in order to fully meet the requirement
 The third column contains the Redfish API capabilities that are used in meeting the
requirement
 The last column contains additional comments on Redfish capabilities

The normative control profile is out of scope for this document and is described in O-PAS Part 5
– System Management.
Table 1: Assessment of Redfish Security Functionality

ANSI/ISA 62443
Foundational External Service Redfish Compatibility
Requirement Dependency Redfish API Capability Comment

Identification and Identity, authentication, Accounts, roles, events,

authentication control certificates, credential other commands
services

Use control Authorization, auditing, Accounts, logs, Network Several controls are
time, endpoint security Time Protocol (NTP), delivered from endpoint
services sessions, events, other security services.
commands

System integrity Intrusion detection, Protocols, logs, sessions, Several controls are
identity, audit services, and other commands delivered from endpoint
endpoint security security services.
services

Data confidentiality Encryption services Protocols, logs, sessions,

and other commands

O-PAS™ Standard, Version 2.0: Part 2 – Security 15

Copyright © 2020 The Open Group, All Rights Reserved
Evaluation Copy. Not for redistribution
 Evaluation Copy

ANSI/ISA 62443
Foundational External Service Redfish Compatibility
Requirement Dependency Redfish API Capability Comment

Restricted data flow Enable/disable specific Enable/disable HTTP, Redfish only addresses
management protocols HTTPS, SSDP, SSH, management protocols.
Telnet, SNMP, RDP,
NTP, KVMIP, IPMI,
DHCP, DHCPv6

Timely response to Audit, event monitoring Events, logs

events

Resource availability Backup, DDoS Port, role, power, and

protection, emergency other commands
power

Appendix B contains a mapping of the Redfish security functionality documented in O-PAS Part
5 – System Management compared to ANSI/ISA-62443-4-2 SL2 requirements.

4.3.3 Gap Assessment

Table 1 shows that Redfish provides a good basis for implementing the security requirements
related to system management. However, there are some gaps in coverage. Redfish is focused on
system management, and thus security requirements related to network management are out of
scope in the O-PAS Standard, Version 2.0. Redfish provides an API which relies on the presence
of several external services which also need to be secure. Additional gaps may include:
 Audit process failure notifications
 Protection of audit information
 Resource limits by security functions

Protection of audit information and resource limits are outside the scope and capability of the
system management interface. Regarding audit failure notifications, Redfish itself is only a
protocol and data model so it cannot detect audit failures, but it does expose log and event
functionality that can generate configuration change events.

The Redfish specification allows to enable/disable management protocols such as HTTP, Telnet,
NTP, and older versions of SNMP which do not meet the security requirements in ANSI/ISA-
62443-4-2. Product suppliers must follow the requirements in Part 5 – System Management
related to non-secure management protocols. End users need to be aware that if such
management protocols are present and enabled, that will result in non-conformance with SL2
capability required in this document.

Similarly, while BMCs are out of scope for this document, product suppliers and end users
should be aware that commercial hardware platforms, largely developed for IT (versus OT)
application use, may contain BMCs which have the potential to negatively impact deployment
security. For example, a hardware BMC may contain functionality to support services which
have been excluded from the O-PAS Standard; e.g., HTTP (versus HTTPS), TFTP, Telnet.
Wherever possible, mitigation actions should be employed to isolate, limit the scope of, and/or

16 The Open Group Preliminary Standard (2020)

Copyright © 2020 The Open Group, All Rights Reserved
Evaluation Copy. Not for redistribution
 Evaluation Copy

disable such undesirable BMC services. Specific recommendations would be platform-specific

and are out of scope for this document.

See O-PAS Part 5 – System Management for details on gaps.

4.4 O-PAS Part 6 – Information and Exchange Models

4.4.1 Mapping Download/Upload and Import/Export Models to ANSI/ISA 62443
The import/export and download/upload models defined in O-PAS Part 6.1 – Overview and
Interfaces rely on the creation and maintenance of configuration portability zip files in a form
described by the Automation Markup Language (AutomationML2) standard referenced in that
part. Since configuration data is of upmost importance for the operation of industrial control
systems and in many cases considered Intellectual Property (IP) by end users, it should be
protected at all times, both in motion and at rest.

Considering that the configuration management tools required to implement the import/export
model are outside the scope of this document, the security requirements defined hereafter apply
to the mechanisms to download/upload configuration data from/to the DCN, and to protect
configuration data at rest while stored at the DCN. However, it is strongly recommended to
equally apply the security requirements defined in this section to the configuration management
tools supporting the functionality described in O-PAS Part 6 – Information and Data Exchange
Models.

AutomationML is an open standard maintained by the AutomationML Association designed to

provide a common data format based on XML for the exchange and storage of engineering data
used in industrial control systems. AutomationML has defined ways to work with the OPC UA
that will be in place for use within the O-PAS Standard. For the security of AutomationML data
in transit, the OPC UA security facet and profiles listed in O-PAS Part 4 – O-PAS Connectivity
Framework (OCF) define the security mechanisms for secure transport of data.

Table 2 provides a list of security requirements contained in ANSI/ISA-62443-4-2 required to

comply with the security needs of protecting data in motion and at rest.
Table 2: Data in Motion and At Rest ANSI/ISA-62443-4-2 SL2 Requirements

Title Section Description Requirement

FR 1 – Identification and 5.2 Rationale By extension, access control Required

authentication control requirements need to be extended to data
at rest.

FR 2 – Use control 6.2 Rationale By extension, use control requirements Required

must be extended to data at rest.

FR 3 – System integrity 7.2 Rationale The integrity of logical assets should be Recommended
maintained while in transit and at rest,
such as being transmitted over a network
or when residing in a data repository.

2
See www.automationml.org.

O-PAS™ Standard, Version 2.0: Part 2 – Security 17

Copyright © 2020 The Open Group, All Rights Reserved
Evaluation Copy. Not for redistribution
 Evaluation Copy

Title Section Description Requirement

FR 4 – Data 8.2 Rationale Some component-generated information, Required

confidentiality whether at rest or in transit, is of a
confidential or sensitive nature. This
implies that some communication
channels and data stores require
protection against eavesdropping and
unauthorized access.

CR 4.1 – Information 8.3.1 Requirement Components shall: Required

confidentiality  Provide the capability to protect the
confidentiality of information at rest
for which explicit read
authorization is supported
 Support the protection of the
confidentiality of information in
transit as defined in ANSI/ISA-
62443-3-3, System Requirement 4.1

CR 4.2 – Information 8.4.1 Requirement Components shall provide the capability Required
persistence to erase all information, for which
explicit read authorization is supported,
from components to be released from
active service and/or decommissioned.

CR 4.3 – Use of 8.5.1 Requirement If cryptography is required, the Required

cryptography component shall use cryptographic
security mechanisms according to
internationally recognized and proven
security practices and recommendations.

4.4.2 Gap Assessment

For the case of the download/upload model, following the best practices established in the OPC
UA specification for secure communications meets the intent of the ANSI/ISA-62443-4-2
requirements for data in motion.

The AutomationML standard was not designed to address the needs for security of data at rest.
ANSI/ISA-62443-4-2 requires protection of data from unauthorized export or copy. It is
understood that proprietary information could be at risk with the use of AutomationML exports
and countermeasures need to be implemented by product suppliers and end users.

4.5 O-PAS Part 7 – Physical Platform

4.5.1 Mapping of Physical Platform to ANSI/ISA-62443-4-2
An O-PAS physical platform will follow a typical device lifecycle, which involves procurement,
provisioning, deployment, and decommissioning. Table 3 shows the applicable ANSI/ISA-
62443-4-2 requirements.

18 The Open Group Preliminary Standard (2020)

Copyright © 2020 The Open Group, All Rights Reserved
Evaluation Copy. Not for redistribution
 Evaluation Copy

Table 3: ANSI/ISA-62443-4-2 Requirements Applicable to Device Lifecycle

Device Lifecycle Requirements

Procurement (V2.0) EDR 2.13 & HDR 2.13 – Use of physical diagnostic and test interfaces

EDR 3.11 & HDR 3.11 – Physical tamper resistance and detection

EDR 3.12 & HDR 3.12 – Provisioning product supplier roots of trust

EDR 3.13 & HDR 3.13 – Provisioning asset owner roots of trust

EDR 3.14 & HDR 3.14 – Boot integrity

CR 5.1 – Network segmentation

Provisioning (Future) CR 7.6 – Network and security configuration settings

CR 7.7 – Least functionality

Deployment (Future) EDR 3.2 & HDR 3.2 – Protection from malicious code

EDR 3.10 & HDR 3.10 – Support for updates

CR 3.9 – Protection of audit information

CR 6.2 – Continuous monitoring

CR 7.3 – Control system backup

CR 7.4 – Control system recovery and reconstitution

In order to support the above requirements, there are additional security features needed. The
following table captures those requirements that are not specific to any phase of device lifecycle,
but fundamental to supporting the above requirements.

Device Lifecycle Requirements

Authenticated access CR 1.5 – Authenticator management

Cryptography CR 1.9 – Strength of public key-based authentication

CR 1.14 – Strength of symmetric key-based authentication

4.5.2 Gap Assessment

ANSI/ISA-62443-4-2 specifies a requirement regarding information persistence (CR 4.2) when
decommissioned. In addition, it is desired to reset the device to a factory image (default OEM
configuration) when decommissioned. When this is not possible, all stored contents (including
software installed post-manufacturing, configuration information, and key material) must be
wiped clean.

O-PAS™ Standard, Version 2.0: Part 2 – Security 19

Copyright © 2020 The Open Group, All Rights Reserved
Evaluation Copy. Not for redistribution
 Evaluation Copy

While ANSI/ISA-62443-4-2 does not specifically call out the need for protected storage, it is
implied (for instance, CR 3.9 for protecting log or other protection of configuration and key
material).

20 The Open Group Preliminary Standard (2020)

Copyright © 2020 The Open Group, All Rights Reserved
Evaluation Copy. Not for redistribution
 Evaluation Copy

A SEC-001 Security Profile – ANSI/ISA-62443-4-2 SL2

Applicable Security Requirements for the O-PAS
Standard, Version 2.0

Table 4 contains the set of SL2 requirements relevant to the scope, functionality, and component
types described in the O-PAS Standard. The following categories describe the relevant scope:
 Y: the ANSI/ISA 62443-4-2 SL2 security requirement is applicable to the O-PAS
functional scope defined in Version 2.0
 N/A: the ANSI/ISA 62443-4-2 SL2 security requirement is not applicable to the O-PAS
functional scope defined in Version 2.0
Table 4: Security Profile for the O-PAS Standard, Version 2.0

O-PAS Standard,
ANSI/ISA-62443-4-2 SL2 O-PAS Relevant CRs and REs3 Version 2.0 Scope
FR 1 – Identification and authentication control
CR 1.1 – Human user identification and authentication Y
RE (1) Unique identification and authentication Y
CR 1.2 – Software process and device identification and authentication Y
CR 1.3 – Account management Y
CR 1.4 – Identifier management Y
CR 1.5 – Authenticator management Y
CR 1.7 – Strength of password-based authentication Y
CR 1.8 – Public key infrastructure certificates Y
CR 1.9 – Strength of public key-based authentication Y
CR 1.10 – Authenticator feedback Y
CR 1.11 – Unsuccessful login attempts Y
CR 1.12 – System use notification Y
CR 1.14 – Strength of symmetric key-based authentication Y
FR 2 – Use control
CR 2.1 – Authorization enforcement Y
RE (1) Authorization enforcement for all users (humans, software processes, and
Y
devices)

3
A CR is a Component Requirement which is common to all types of components, and an RE is a Requirement Enhancement which
is an extension of a Component Requirement.

O-PAS™ Standard, Version 2.0: Part 2 – Security 21

Copyright © 2020 The Open Group, All Rights Reserved
Evaluation Copy. Not for redistribution
 Evaluation Copy

O-PAS Standard,
ANSI/ISA-62443-4-2 SL2 O-PAS Relevant CRs and REs3 Version 2.0 Scope
RE (2) Permission mapping to roles Y
SAR 2.4 – Mobile code N/A
RE (1) Mobile code authenticity check N/A
EDR 2.4 – Mobile code N/A
RE (1) Mobile code authenticity check N/A
HDR 2.4 – Mobile code N/A
RE (1) Mobile code authenticity check N/A
CR 2.5 – Session lock Y
CR 2.6 – Remote session termination Y
CR 2.8 – Auditable events Y
CR 2.9 – Audit storage capacity Y
CR 2.10 – Response to audit processing failures Y
CR 2.11 – Timestamps Y
RE (1) Time synchronization Y
CR 2.12 – Non-repudiation Y
EDR 2.13 – Use of physical diagnostic and test interfaces Y
HDR 2.13 – Use of physical diagnostic and test interfaces Y
FR 3 – System integrity
CR 3.1 – Communication integrity Y
RE (1) Communication authentication Y
SAR 3.2 – Protection from malicious code N/A
EDR 3.2 – Protection from malicious code N/A
HDR 3.2 – Protection from malicious code N/A
RE (1) Report version of code protection N/A
CR 3.3 – Security functionality verification Y
CR 3.4 – Software and information integrity Y
RE (1) Authenticity of software and information Y
CR 3.5 – Input validation Y
CR 3.6 – Deterministic output Y
CR 3.7 – Error handling Y
CR 3.8 – Session integrity Y
CR 3.9 – Protection of audit information Y

22 The Open Group Preliminary Standard (2020)

Copyright © 2020 The Open Group, All Rights Reserved
Evaluation Copy. Not for redistribution
 Evaluation Copy

O-PAS Standard,
ANSI/ISA-62443-4-2 SL2 O-PAS Relevant CRs and REs3 Version 2.0 Scope
EDR 3.10 – Support for updates N/A
RE (1) Update authenticity and integrity N/A
HDR 3.10 – Support for updates N/A
RE (1) Update authenticity and integrity N/A
EDR 3.11 – Physical tamper resistance and detection Y
HDR 3.11 – Physical tamper resistance and detection Y
EDR 3.12 – Provisioning product supplier roots of trust Y
HDR 3.12 – Provisioning product supplier roots of trust Y
EDR 3.13 – Provisioning asset owner roots of trust Y
HDR 3.13 – Provisioning asset owner roots of trust Y
EDR 3.14 – Integrity of the boot process Y
RE (1) Authenticity of the boot process Y
HDR 3.14 – Integrity of the boot process Y
RE (1) Authenticity of the boot process Y
FR 4 – Data confidentiality
CR 4.1 – Information confidentiality Y
CR 4.2 – Information persistence Y
CR 4.3 – Use of cryptography Y
FR 5 – Restricted data flow
CR 5.1 – Network segmentation Y
FR 6 – Timely response to events
CR 6.1 – Audit log accessibility Y
CR 6.2 – Continuous monitoring N/A
FR 7 – Resource availability
CR 7.1 – Denial of service protection Y
RE (1) Manage communication load from component Y
CR 7.2 – Resource management Y
CR 7.3 – Control system backup N/A
RE (1) Backup integrity verification N/A
CR 7.4 – Control system recovery and reconstitution N/A
CR 7.6 – Network and security configuration settings N/A
CR 7.7 – Least functionality N/A

O-PAS™ Standard, Version 2.0: Part 2 – Security 23

Copyright © 2020 The Open Group, All Rights Reserved
Evaluation Copy. Not for redistribution
 Evaluation Copy

O-PAS Standard,
ANSI/ISA-62443-4-2 SL2 O-PAS Relevant CRs and REs3 Version 2.0 Scope
CR 7.8 – Control system component inventory N/A

24 The Open Group Preliminary Standard (2020)

Copyright © 2020 The Open Group, All Rights Reserved
Evaluation Copy. Not for redistribution
 Evaluation Copy

B Assessment of OPC UA and Redfish Security

Functionality Compared with ANSI/ISA-62443-4-2
Security Requirements

Table 5 provides an assessment of the security functionality provided by the OPC UA standard
(profiled in O-PAS Part 4 – O-PAS Connectivity Framework (OCF)) and the security
functionality provided by Redfish (documented in O-PAS Part 5 – System Management)
compared to ANSI/ISA-62443-4-2 SL2 requirements. The following categories describe the
results of the assessment:
 Y: the reference standard specifies security feature(s) to meet the ANSI/ISA 62443
requirement
 N: the reference standard does not specify security feature(s) to meet the ANSI/ISA 62443
requirement
 Not Applicable (N/A): the ANSI/ISA 62443 requirement is not applicable when
considering the functional scope of the reference specification
Table 5: ANSI/ISA-62443-4-2 Mapping to OPC UA and Redfish

O-PAS O-PAS O-PAS

Standard, Part 4 Part 5
Version 2.0 Security Security
ANSI/ISA-62443-4-2 SL2 O-PAS Relevant CRs and REs Scope Feature Feature

FR 1 – Identification and authentication control

CR 1.1 – Human user identification and authentication Y Y Y

RE (1) Unique identification and authentication Y Y Y

CR 1.2 – Software process and device identification and

Y Y Y
authentication

CR 1.3 – Account management Y Y Y

CR 1.4 – Identifier management Y Y Y

CR 1.5 – Authenticator management Y Y Y

CR 1.7 – Strength of password-based authentication Y N N

CR 1.8 – Public key infrastructure certificates Y Y Y

CR 1.9 – Strength of public key-based authentication Y Y Y

CR 1.10 – Authenticator feedback Y N/A Y

O-PAS™ Standard, Version 2.0: Part 2 – Security 25

Copyright © 2020 The Open Group, All Rights Reserved
Evaluation Copy. Not for redistribution
 Evaluation Copy

O-PAS O-PAS O-PAS

Standard, Part 4 Part 5
Version 2.0 Security Security
ANSI/ISA-62443-4-2 SL2 O-PAS Relevant CRs and REs Scope Feature Feature

CR 1.11 – Unsuccessful login attempts Y Y Y

CR 1.12 – System use notification Y N/A Y

CR 1.14 – Strength of symmetric key-based authentication Y Y N/A

FR 2 – Use control

CR 2.1 – Authorization enforcement Y Y Y

RE (1) Authorization enforcement for all users (humans,

Y Y Y
software processes, and devices)

RE (2) Permission mapping to roles Y Y Y

SAR 2.4 – Mobile code N N/A N/A

RE (1) Mobile code authenticity check N N/A N/A

EDR 2.4 – Mobile code N N/A N/A

RE (1) Mobile code authenticity check N N/A N/A

HDR 2.4 – Mobile code N N/A N/A

RE (1) Mobile code authenticity check N N/A N/A

CR 2.5 – Session lock Y N/A Y

CR 2.6 – Remote session termination Y Y Y

CR 2.8 – Auditable events Y Y Y

CR 2.9 – Audit storage capacity Y Y Y

CR 2.10 – Response to audit processing failures Y N/A Y

CR 2.11 – Timestamps Y Y Y

RE (1) Time synchronization Y Y Y

CR 2.12 – Non-repudiation Y N/A Y

EDR 2.13 – Use of physical diagnostic and test interfaces Y N/A N/A

HDR 2.13 – Use of physical diagnostic and test interfaces Y N/A N/A

FR 3 – System integrity

26 The Open Group Preliminary Standard (2020)

Copyright © 2020 The Open Group, All Rights Reserved
Evaluation Copy. Not for redistribution
 Evaluation Copy

O-PAS O-PAS O-PAS

Standard, Part 4 Part 5
Version 2.0 Security Security
ANSI/ISA-62443-4-2 SL2 O-PAS Relevant CRs and REs Scope Feature Feature

CR 3.1 – Communication integrity Y Y Y

RE (1) Communication authentication Y Y Y

SAR 3.2 – Protection from malicious code N N/A N/A

EDR 3.2 – Protection from malicious code N N/A N/A

HDR 3.2 – Protection from malicious code N N/A N/A

RE (1) Report version of code protection N N/A N/A

CR 3.3 – Security functionality verification Y Y Y

CR 3.4 – Software and information integrity Y N/A N/A

RE (1) Authenticity of software and information Y N/A N/A

CR 3.5 – Input validation Y N/A N/A

CR 3.6 – Deterministic output Y N/A N/A

CR 3.7 – Error handling Y Y Y

CR 3.8 – Session integrity Y Y Y

CR 3.9 – Protection of audit information Y N N

EDR 3.10 – Support for updates N N/A N/A

RE (1) Update authenticity and integrity N N/A N/A

HDR 3.10 – Support for updates N N/A N/A

RE (1) Update authenticity and integrity N N/A N/A

EDR 3.11 – Physical tamper resistance and detection Y N/A N/A

HDR 3.11 – Physical tamper resistance and detection Y N/A N/A

EDR 3.12 – Provisioning product supplier roots of trust Y N/A N/A

HDR 3.12 – Provisioning product supplier roots of trust Y N/A N/A

EDR 3.13 – Provisioning asset owner roots of trust Y N N/A

HDR 3.13 – Provisioning asset owner roots of trust Y N N/A

O-PAS™ Standard, Version 2.0: Part 2 – Security 27

Copyright © 2020 The Open Group, All Rights Reserved
Evaluation Copy. Not for redistribution
 Evaluation Copy

O-PAS O-PAS O-PAS

Standard, Part 4 Part 5
Version 2.0 Security Security
ANSI/ISA-62443-4-2 SL2 O-PAS Relevant CRs and REs Scope Feature Feature

EDR 3.14 – Integrity of the boot process Y N/A N/A

RE (1) Authenticity of the boot process Y N/A N/A

HDR 3.14 – Integrity of the boot process Y N/A N/A

RE (1) Authenticity of the boot process Y N/A N/A

FR 4 – Data confidentiality

CR 4.1 – Information confidentiality Y Y Y

CR 4.2 – Information persistence Y N/A N

CR 4.3 – Use of cryptography Y Y Y

FR 5 – Restricted data flow

CR 5.1 – Network segmentation Y N/A N/A

FR 6 – Timely response to events

CR 6.1 – Audit log accessibility Y Y N

CR 6.2 – Continuous monitoring N N/A Y

FR 7 – Resource availability

CR 7.1 – Denial of service protection Y Y N

RE (1) Manage communication load from component Y Y N

CR 7.2 – Resource management Y Y Y

CR 7.3 – Control system backup N N/A N

RE (1) Backup integrity verification N N/A N

CR 7.4 – Control system recovery and reconstitution N N/A N

CR 7.6 – Network and security configuration settings N Y N

CR 7.7 – Least functionality N N N

CR 7.8 – Control system component inventory N N/A Y

28 The Open Group Preliminary Standard (2020)

Copyright © 2020 The Open Group, All Rights Reserved
Evaluation Copy. Not for redistribution
 Evaluation Copy

C Abbreviations

For the glossary of abbreviations, see the definitions here.

O-PAS™ Standard, Version 2.0: Part 2 – Security 29

Copyright © 2020 The Open Group, All Rights Reserved
Evaluation Copy. Not for redistribution
 Evaluation Copy

Index
accountability ............................. 6 incident response ........................ 6
anomaly detection....................... 6 integrity ...................................... 5
ANSI/ISA 62443 standards .... 2, 7 JSON ........................................ 15
auditability .................................. 6 non-repudiation .......................... 6
authentication ............................. 5 OData ....................................... 15
authorization ............................... 6 OPC UA ............................. 13, 25
AutomationML ......................... 17 physical platform...................... 19
availability .................................. 5 Redfish ..................................... 16
certification............................... 12 Redfish standard ........... 13, 14, 25
confidentiality............................. 5 RESTful interfaces ................... 14
conformance ................... 2, 11, 12 Security Architecture
cybersecurity .............................. 1 Framework ............................. 1
DCN ........................................... 2 security controls ......................... 6
DMTF ....................................... 14 Security Level .......................... 10
DoS ............................................. 5 security objectives ...................... 5
firewall ....................................... 6 security requirements ............... 25
IACS ........................................... 6 segmentation .............................. 6
identification............................... 5 time synchronization ................ 14
IEEE 1588-2008 ....................... 14 VLAN......................................... 6
IIoT ............................................. 6

30 The Open Group Preliminary Standard (2020)

Copyright © 2020 The Open Group, All Rights Reserved
Evaluation Copy. Not for redistribution