OPC UA is a protocol used between components in the operation of an industrial facility at multiple levels: from high-level enterprise management to low-level direct process control of a device. The use of OPC UA for enterprise management involves dealings with customers and suppliers. It could be an attractive target for industrial espionage or sabotage and could also be exposed to threats through untargeted malware, such as worms, circulating on public networks. Disruption of communications at the process control could result in financial losses, affect employee and public safety or cause environmental damage.

OPC UA will be deployed in a diverse range of operational environments with varying assumptions about threats and accessibility, and with a variety of security policies and enforcement regimes. OPC UA, therefore, provides a flexible set of security mechanisms. Figure 1 is a composite that shows a combination of such environments. Some OPC UA Applications are on the same host and can be easily protected from external attack. Some OPC UA Applications are on different hosts in the same operations network and could be protected by the security boundary protections that separate the operations network from external connections. Some OPC UA Applications run in relatively open environments where users and applications could be difficult to control. Other OPC UA Applications are embedded in control systems that have no direct electronic connection to external systems. OPC UA also supports multiple protocols and communication technologies, that could require different levels of security and different security infrastructure. For example, both Client - Server and Publisher - Subscriber communication is shown in Figure 1. OPC UA also defines global services such as Certificate management, KeyCredential management, AuthorizationService, and GlobalDiscoveryServer (GDS) to help manage security and other global functionality.

Figure 1 – OPC UA network example

Fundamentally, information system security reduces the risk of damage from attacks. It does this by identifying the threats to the system, identifying the system’s vulnerabilities to these threats, and providing countermeasures. The countermeasures reduce vulnerabilities directly, counteract threats, or recover from successful attacks.

Industrial automation system security is achieved by meeting a set of objectives. These objectives have been refined through many years of experience in providing security for information systems in general and they remain quite constant despite the ever-changing set of threats to systems. They are described in 5.1 and 5.2 reconciles these objectives against the OPC UA functions. Clause 6 offers additional best practice guidelines to Client and Server developers or those that deploy OPC UA Applications.

Entities such as Clients, Servers, and users should prove their identities. Authentication can be based on something the entity is, has, or knows.

The access to read, write, or execute resources should be authorized for only those entities that have a need for that access within the requirements of the system. Authorization can be as coarse-grained as allowing or disallowing a Client to access a Server or it could be much finer grained such as allowing specific actions on specific information items by specific users. The granularity of a system depends in part on the functionality supported by the Server, but in general Authorization should be given based on the need-to-know principle i.e. a user should be granted access only to information they require for the function they are performing.

Data is protected from passive attacks such as eavesdropping, whether the data is being transmitted, in memory, or being stored. To provide Confidentiality, data encryption algorithms using special secrets for securing data are used along with Authentication and Authorization mechanisms for accessing that secret.

Receivers receive the same information that the original sender sent, without the data being changed during transmission.

Repudiation is the rejection or denial of something as valid or true. Non-Repudiation is assuring that something that actually occurred cannot be claimed as having not occurred. A security service that provides this protection can be one of two types:

• One in which the recipient of the data gets and stores information proving that the data came from the originator. This blocks the originator from claiming they never sent the data.
• One in which the sender of the data gets confirmation that the data was received by the recipient as intended.

Actions taken by a system are recorded in order to provide evidence to stakeholders:

• that this system works as intended (successful actions are tracked).
• that identify the initiator of certain actions (user activity is tracked).
• that attempts to compromise the system were denied (unsuccessful actions are tracked).

Availability is impaired when the execution of software that needs to run is turned off or when the software or communication system is overwhelmed by processing input. Impaired Availability in OPC UA can appear as slowing down of Subscription performance or the inability to add Sessions for example.

The inability to discover SymmetricKeys even if the Private Keys used for the key exchange are compromised in the future.

OPC UA provides countermeasures to resist threats to the security of the information that is communicated. 4.3 lists the currently known threats to environments in which OPC UA will be deployed, and 5.1 reconciles these threats against the OPC UA functions.

Denial of service is the prevention of authorized access to a system resource or the delaying of system operations and functions. This can occur from a number of different attack vectors including message flooding, resource exhaustion and application crashes. Each of these are described separately.

Denial of Service impacts Availability.

See 5.1.2 for the reconciliation of this threat.

For Client-Server, an attacker can send a large volume of Messages, or a single Message that contains a large number of requests, with the goal of overwhelming the OPC UA Server or dependent components such as CPU, TCP/IP stack, operating system, or the file system. Flooding attacks can be conducted at multiple layers including OPC UA, HTTP or TCP.

Message flooding attacks can also target a Client, although this is less of a risk, since the Client chooses who to connect to. A Client could receive a flood from a compromised Server which could disrupt the OPC UA Application.

Message flooding attacks can use both well-formed and malformed Messages. In the first scenario, the attacker could be a malicious person using a legitimate Client to flood the Server with requests. Two cases exist, one in which the Client does not have a Session with the Server and one in which it does. Message flooding can impair the ability to establish OPC UA Sessions or terminate an existing Session. In the second scenario, an attacker could use a malicious Client that floods an OPC UA Server with malformed Messages in order to exhaust the Server’s resources.

For PubSub, an attacker can send a large volume of dataset messages with the goal of overwhelming the subscriber, the middleware or dependent components such as CPU, TCP/IP stack, operating system, or the file system. Flooding attacks can be conducted at multiple layers including OPC UA, UDP, AMQP, MQTT.

As in Client-Server, PubSub message flooding attacks can use both well-formed and malformed Messages. For well-formed Messages, the attacker could be one in which the publisher is not a member of the SecurityGroup and one in which it is a member. For malformed Messages, an attacker could use a malicious Publisher that floods a network with malformed Messages in order to exhaust the system’s resources.

In general, Message flooding can impair the ability to communicate with an OPC UA entity and result in denial of service.

An attacker can send a limited number of messages that obtain a resource on the system. The commands are typically valid, but they each use up a resource resulting in a single Client obtaining all resources blocking valid Clients from accessing the Server. For example, on a Server in which only 10 Sessions are available a malicious person using a legitimate Client, could obtain all 10 Sessions. Or a malicious Client could try to open 10 SecureChannels, without actually completing the process.

Resource exhaustion attacks do not occur in the same manner for PubSub communications since no session or resources are allocated. For PubSub communication, the Publisher is not susceptible. In broker-less PubSub communication, the Subscriber can, with the use of filters, bypass any resource exhaustion issues. In broker case, both the Publisher and Subscriber are connected to the broker. Although the Publisher and Subscriber are not directly susceptible (as in the broker-less case), the broker is susceptible. The details for broker communication is not part of this standard but is defined by the broker protocol.

An attacker can send special message that will cause an application to crash. This is usually the result of a known problem in a stack or application. These system bugs can allow a Client to issue a command that would cause the Server to crash, as an alternate it could be a Server that can respond to a legitimate message with a response that would cause the Client to crash. The attacker could also be a Publisher that issues a Message that would cause Subscribers to crash.

Eavesdropping is the unauthorized disclosure of sensitive information that could result directly in a critical security breach or be used in follow-on attacks.

If an attacker has compromised the underlying operating system or the network infrastructure, then the attacker could be able to record and capture Messages. It could be beyond the capability of a Client or Server to recover from a compromised operating system.

Eavesdropping impacts Confidentiality directly and if session establishment is not secured Authentication and Authorization. It also indirectly threatens all other security objectives.

See 5.1.3 for the reconciliation of this threat.

This includes feigning identities (user, application, process etc.). An attacker could forge Messages from a Client or a Server or a Publisher where the messages are forged to attempt to appear to be from an application other that the sending application or process. Spoofing can occur at multiple layers in the protocol stack.

By spoofing Messages from a Client, a Server or Publisher, attackers can perform unauthorized operations and avoid detection of their activities.

Message spoofing impacts Integrity, Authorization and during session / SecureChannel establishment Authentication.

See 5.1.4 for the reconciliation of this threat.

Network traffic and application layer Messages could be captured or modified and forwarded to OPC UA Clients, Servers, and Subscribers. Message alteration could allow illegitimate access to a system.

Message alteration impacts Integrity, Authorization, Auditability, Non-Repudiation and during session / SecureChannel establishment Authentication.

See 5.1.5 for the reconciliation of this threat.

Network traffic and valid application layer Messages could be captured and resent to OPC UA Clients, Servers and Subscribers at a later stage without modification. An attacker could misinform the user or send a valid command such as opening a valve but at an improper time, so as to cause damage or property loss. An attacker could attempt to establish a Session using a recorded Session.

Message replay impacts Authorization and during Session / SecureChannel establishment Authentication. See 5.1.6 for the reconciliation of this threat.

An attacker can craft a variety of Messages with invalid Message structure (malformed XML, UA Binary, etc.) or data values, and send them to OPC UA Clients, Servers or Subscribers.

The OPC UA Client, Server or Subscriber could incorrectly handle certain malformed Messages by performing unauthorized operations or processing unnecessary information. It could result in a denial or degradation of service including termination of the application or, in the case of embedded devices, a complete crash. In a worst-case scenario an attacker could use malformed Messages as a pre-step for a multi-level attack to gain access to the underlying system of an OPC UA Application.

Malformed Messages impacts Integrity and Availability.

See 5.1.7 for the reconciliation of this threat.

An attacker tries to deduce the identity, type, software version, or vendor of the Server or Client in order to apply knowledge about specific vulnerabilities of that product to mount a more intrusive or damaging attack. The attacker could profile the target by sending valid or invalid formatted Messages to the target and try to recognize the type of target by the pattern of its normal and error responses.

Server profiling impacts all of the security objectives indirectly.

See 5.1.8 for the reconciliation of this threat.

An attacker could use information (retrieved by sniffing the communication or by guessing) about a running Session established between two applications to inject manipulated Messages (with valid session information) that allow him or her to take over the Session from the authorized user.

An attacker could gain unauthorized access to data or perform unauthorized operations.

Session hijacking impacts all of the security objectives.

See 5.1.9 for the reconciliation of this threat.

An attacker builds a malicious OPC UA Server or installs an unauthorized instance of a genuine OPC UA Server in a system. The rogue Server can attempt to masquerade as a legitimate UA Server or it can simply appear as a new Server in the system.

The OPC Client could disclose confidential information.

A rogue Server impacts all security objectives except Integrity and Non-Repudiation.

See 5.1.10 for the reconciliation of this threat.

An attacker who builds a malicious OPC UA Publisher or installs an unauthorized instance of a genuine OPC UA Publisher in a system. The rogue Publisher could attempt to masquerade as a legitimate UA Publisher or it could simply appear as a new Publisher in the system.

A rogue Publisher impacts all security objectives except Integrity and Non-Repudiation.

See 5.1.10 for the reconciliation of this threat.

An attacker who builds a malicious Local Discover Server. The malicious Local Discover Server could direct Clients to incorrect Servers, lower the exposed security of listed Servers or hide legitimate Servers. It could also be used to generate incorrect input to a GDS that aggregates information from Local Discovery Servers.

A rogue Discovery Server impacts all security objectives except Integrity and Non-Repudiation.

See 5.1.11for the reconciliation of this threat.

An attacker obtains user credentials such as usernames, passwords, Certificates, or keys by observing them on papers, on screens, or in electronic communications, or by cracking them through guessing or the use of automated tools such as password crackers.

An unauthorized user could launch and access the system to obtain all information and make control and data changes that harm plant operation or information. Once compromised credentials are used, subsequent activities could all appear legitimate.

Compromised user credentials impact Authentication, Authorization and Confidentiality.

See 5.1.12 for the reconciliation of this threat.

An attacker compromises an identity server or provides a rogue identity server. This is similar to 4.3.13, except all credentials are compromised. An unauthorized user could launch and access the system to obtain all information and make control and data changes that harm plant operations or information. Once compromised, invalid users can be used and or granted any roles or rights. Compromised identity services directly impact Authentication and Authorization, but it can indirectly impact all security objectives.

See 5.1.12 for the reconciliation of this threat.

This is not a direct attack, since it is not about communication, but it is the trust following the communication. Repudiation causes trust issues with either the sender or the receiver of the data.

Repudiation impacts Non-Repudiation.

See 5.1.13 for the reconciliation of this threat.

An attacker could try to intercept and block reception of a message. This could be accomplished with a compromised network infrastructure or in other manners. Messages could be blocked in either direction i.e. messages originating from a Client or originating from a Server.

Message suppression impacts Integrity and Availability.

See 5.1.14 for the reconciliation of this threat.

An attacker could attempt to fool a Client into using a less secure connection or deprecated security policy. This could be attempted by modifying a Discovery response to remove security options from the available endpoints.

Message suppression directly impacts Authentication and Authorization, but it can indirectly impact all security objectives.

See 5.1.15 for the reconciliation of this threat.

OPC UA security works within the overall Cyber Security Management System (CSMS) of a site. Sites often have a CSMS that addresses security policy and procedures, personnel, responsibilities, audits, and physical security. A CSMS typically addresses threats that include those that were described in 4.3. They also analyse the security risks and determine what security controls the site needs.

Resulting security controls commonly implement a “defence-in-depth” strategy that provides multiple layers of protection and recognizes that no single layer can protect against all attacks. Boundary protections, shown as abstract examples in Figure 1, can include firewalls, intrusion detection and prevention systems, controls on dial-in connections, and controls on media and computers that are brought into the system. Protections in components of the system can include hardened configuration of the operating systems, security patch management, anti-virus programs, and not allowing email in the control network. Standards that could be followed by a site include NERC CIP and IEC62351 which are referenced in Clause 2.

The security requirements of a site CSMS apply to its OPC UA interfaces. That is, the security requirements of the OPC UA interfaces that are deployed at a site are specified by the site, not by the OPC UA specification. OPC UA specifies features that are intended so that conformant OPC UA Applications can meet the security requirements that are expected to be made by sites where they will be deployed. Those who are responsible for the security at the site should determine how to meet the site requirements with OPC UA conformant products.

The system owner that installs OPC UA Applications should analyse its security risks and provide appropriate mechanisms to mitigate those risks to achieve an acceptable level of security. OPC UA meets the wide variety of security needs that could result from such individual analyses. OPC UA Applications are required to be implemented with certain security features which are available for the system owner’s optional use. Each system owner should be able to tailor a security solution that meets its security and economic requirements using a combination of mechanisms available within the OPC UA specification and external to OPC UA.

The security requirements placed on the OPC UA Applications deployed at a site are specified by the site CSMS, not by the OPC UA specification. The OPC UA security specifications, however, are requirements placed upon OPC UA Applications, and recommendations of how OPC UA should be deployed at a site in order to meet the security requirements that are anticipated to be specified at the site.

OPC UA addresses some threats as described in 4.3. The OPC Foundation recommends that OPC UA Application developers address the remaining threats, as detailed in Clause 6. Threats to infrastructure components that could result in the compromise of operating systems, where OPC UA Applications are running, are not addressed by OPC UA.

The OPC UA security architecture is a generic solution that allows implementation of the required security features at various places in the OPC UA Application architecture. Depending on the different mappings described in OPC 10000-6, the security objectives are addressed at different levels. The OPC UA security architecture, for Client / Server communication is structured in an Application Layer and a Communication Layer atop the Transport Layer as shown in Figure 2.

Figure 2 – OPC UA security architecture – Client / Server

OPC UA also supports a Publish - Subscribe communications architecture (PubSub) and the security architecture for that communication is illustrated in Figure 3.

Figure 3 – OPC UA security architecture- Publisher - Subscriber

Client / Server communication can include both Session and session-less communication. Security in part is provided by the application or by the communications layers. It can also utilize transport layer security. Each of these options provides a different set of security objectives and are described in the following sections.

The routine work of a Client application and a Server application to transmit information, settings, and commands is done in a Session in the Application Layer. The Application Layer also manages the security objectives user Authentication and user Authorization (see 4.11 for more detail on user authorization). The security objectives that are managed by the application layer are addressed by the Session Services that are specified in OPC 10000-4. A Session in the application layer communicates over a SecureChannel that is created in the communication layer and relies upon it for secure communication. All of the Session data is passed to the communication layer for further processing.

Although a Session communicates over a SecureChannel and has to be activated before it can be used, the binding of users, Sessions, and SecureChannels is flexible.

Impersonation allows a user to take ownership of an existing Session.

If a SecureChannel breaks, the Session will remain valid for a period of time allowing the Client to re-establish the connection to the Session via a new SecureChannel. Otherwise, the Session closes after its lifetime expires. The requirements for re-establishing connections are described in OPC 10000-4

The Communication Layer provides security mechanisms to meet Confidentiality, Integrity and application Authentication as security objectives. In some cases, it also meets the Perfect Forward Secrecy security objective. One essential mechanism to meet these security objectives is to establish a SecureChannel (see 4.13) that is used to secure the communication between a Client and a Server. The SecureChannel provides encryption to maintain Confidentiality, Message Signatures to maintain Integrity and Certificates to provide application Authentication. In addition, the SecureChannel provides Perfect Forward Secrecy when the SecureChannel is used with ECC and the Diffie Hellman Key Exchange. The data that comes from the Application Layer is secured and passes the “secured” data to the Transport Layer. The security mechanisms that are managed by the Communication Layer are provided by the SecureChannel Services that are specified in OPC 10000-4.

The security mechanisms provided by the SecureChannel services are implemented by a protocol stack that is chosen for the implementation. Mappings of the services to some of the protocol stack options are specified in OPC 10000-6 which define how functions in the protocol stack are used to meet the OPC UA security objectives. Other details are provided as part of Profiles which are described in OPC 10000-7 (and available on-line at https://profiles.opcfoundation.org).

The Communication Layer can represent an OPC UA connection protocol stack. OPC UA specifies alternative stack mappings that can be used as the Communication Layer. These mappings are described in OPC 10000-6.

If the OPC UA Connection Protocol (UACP) is used, then functionality for Confidentiality, Integrity, application Authentication, and the SecureChannel are similar to the TLS specifications, as described in OPC 10000-6.

Additional communication mappings are described in OPC 10000-6. These mappings can rely on transport protocols to provide Confidentiality and Integrity. One example is Websockets, which utilizes HTTPS transport layer security to provide Confidentiality and Integrity.

The transport layer handles the transmission, reception, and the transport of data that is provided by the communication layer.

To survive the loss of the transport layer connections (e.g. TCP connections) and resume with a new connection, the communication layer is responsible for re-establishing the transport layer connection without interrupting.

The transport layer can also be used to implement Confidentiality and Integrity by using HTTPS (HTTP messages over a TLS connection) as described in OPC 10000-6. It is important to note that HTTPS certificates can be (and often are) shared by multiple applications on a platform and that they can be compromised outside of the OPC UA usage of them. All applications on the platform that use the same shared certificate have the same settings. HTTPS does not require application Authentication, if this is required it can be included as part of Session establishment.

OPC UA provides a session-less Service invocation (defined in OPC 10000-4 overview and see OPC 10000-6 for details). The session-less communication provides User Authentication via an Access Token. The communication channel provides Confidentiality and Integrity. The communication channel could be an OPC UA SecureChannel (without a session). It could be a communication channel, such as HTTPS, which relies on transport protocols to provide security. In addition, User Authentication and/or Application Authentication can also be established by the use of an AccessToken which is obtained from an AuthorizationService (see OPC 10000-6 for details).

Session-less communication is restricted to encrypted communication channels. It could also be restricted to specific endpoints that are dedicated for session-less communication.

The PubSub can be deployed in two environments, one in which a broker exists and one which is broker less. OPC 10000-14 defines the details of this model. The two environments have different security considerations associated with them, and each will be described separately.

The broker-less PubSub communication model provides Confidentiality and Integrity. This is accomplished using Symmetric Encryption and signature algorithms. The required SymmetricKeys are distributed by a Security Key Server (SKS) (see OPC 10000-14 for additional details). The SKS makes use of the standard Client/Server security described in 4.5.2 to establish application Authentication as well as user Authentication. This approach allows all applications (Publishers and/or Subscribers) in a SecurityGroup to share information.

A benefit of using shared SymmetricKeys is the high performance they offer, but a drawback is that for a group of applications that use a shared SymmetricKey, all of the applications in the group have the same rights. All applications must trust all other applications in the group. Any application (Publisher or Subscriber) in the group can publish a message and any application (Publisher or Subscriber) in the group can decode the message.

For example, a system could be composed of a shared symmetric group that is composed of a controller (Publisher) and three Subscribers (say HMI’s). The controller is publishing messages and the HMIs are receiving the messages. If one of the HMIs is compromised, it could start publishing messages also. The other two HMIs will not be able to tell that the message was not sent from the controller. One possible solution to this situation could be if the shared symmetric group is composed of just the controller and one HMI. Additional groups would be created for each HMI, then no HMI could affect the other HMIs. Other possible solutions could also involve the network architecture and services, such as unicast restricted network communication, but these are outside the scope of the OPC UA specification. The configuration of SecurityGroups requires careful consideration when deploying systems to ensure security. The model is illustrated in Figure 4.

Figure 4 - Boker-less communication

When using a Broker in the PubSub model, the same shared SymmetricKey concepts as defined in 4.5.3.2 can be used to provide Confidentiality and Integrity. Furthermore, communication to the Broker can be secured according the rules defined for the Broker. These rules are not defined in the OPC UA specification but are defined by the Middleware. In many cases the Middleware requires the authorization of both the Publishers and the Subscribers before they can interact with the Broker. The Broker interactions can provide security mechanisms to meet Confidentiality, Integrity and application or user Authentication as security objectives. If the published message is not secured using the shared SymmetricKey concepts, the message content is visible to the Broker which creates some risk of man-in-the-middle attacks. The use of the shared SymmetricKeys eliminates this risk. For complete details on share SymmetricKeys (SKS) and securing PubSub message in Broker based transports see OPC 10000-14. The model is illustrated in Figure 5.

Figure 5 - Broker Communication

A SecurityPolicy specifies which security mechanisms are to be used and are derived from a Security Profile (see 4.7 for details). Security policies are used by the Server to announce which mechanisms it supports and by the Client to select which one to use with the SecureChannel it wishes to open or for the session-less connection it wishes to make. SecurityPolicies are also used with PubSub communication. SecurityPolicies include the following information:

• algorithms for signing and encryption
• algorithm for key derivation

The choice of allowed SecurityPolicies is normally made by the administrator typically when the OPC UA Applications are installed. The available security policies are specified in OPC 10000-7. The Administrator can at a later time also change or modify the selection of allowed SecurityPolicies as circumstances dictate.

The announcement of security policies is handled by special discovery services specified in OPC 10000-4. More details about the discovery mechanisms and policy announcement strategies can be found in OPC 10000-12.

In the Client Server communications pattern, each Client can select a policy independent of the policy selected by other Clients.

For the Publish Subscribe communications pattern, the SecurityPolicy is associated with a published DataSet and all Subscribers utilize the same SecurityPolicy.

Since computing power increases every year, specific algorithms that are considered as secure today can become insecure in the future, therefore, it makes sense to support different security policies in an OPC UA Application and to be able to adopt more as they become available. NIST or other agencies even make predictions about the expected lifetime of algorithms (see NIST 800-57). The list of supported security policies will be updated based on recommendation such as those published by NIST. From a deployment point of view it is important that the periodic site-review checks that the currently selected list of security profiles still fulfil the required security objectives and if they do not, then a newer selection of Security Profiles is selected

There is also the case that new security policies are composed to support new algorithms that improve the level of security of OPC UA products. The application architecture of OPC UA Application should be designed in a way that it is possible to update or add additional cryptographic algorithms to the application with little or no coding changes.

OPC 10000-7 specifies several policies which are identified by a specific unique URI. To improve interoperability among vendors’ products, Server and Publisher products implement these policies rather than define their own. Clients and Subscribers support the same policies.

OPC UA Client and Server products are certified against Profiles that are described in OPC 10000-7. Some of the Profiles specify security functions and others specify other functionality that are not related to security. The Profiles impose requirements on the certified products but they do not impose requirements on how the products are used. A consistent minimum level of security is required by the various Profiles. However, different Profiles specify different details such as which encryption algorithms are required for which OPC UA functions. If a problem is found in one encryption algorithm then the OPC Foundation can define a new Profile that is similar, but that specifies a different encryption algorithm that does not have a known problem. OPC 10000-7 is the informative specification of the Profiles, but Profiles are normatively defined in an on-line application (https://profiles.opcfoundation.org) allowing for updating of Profiles, especially security related profiles, in a more timely manner than allowed by documentation publication cycles.

Security policies are a type of Profile that specifies which of the security setting choices to use in the Session. The security policy does not specify the range of choices that the product offers, they are described in the Profiles that it supports.

These security policies are included in certification testing associated with OPC UA Applications. The certification testing ensures that the standard is followed and that the appropriate security algorithms are supported.

Each security mechanism in OPC UA is provided in OPC UA Applications in accordance with the Profiles with which the OPC UA Application complies. At the site, however, the security mechanisms could be deployed optionally. In this way each individual site has all of the OPC UA security functions available and can choose which of them to use to meet its security objectives.

Security Profiles describe a Profile “None” that is used for testing, but if any other more secure Profiles are available this Profile is disabled by default. Profile “None” provides no security.

OPC UA supports the selection of several security modes: “None”, “Sign”, “SignAndEncrypt”. Security mode “None” can only be used with security Profile None. Security mode “none” is disabled for all other security Profiles. Profile None shall be disabled by default. The choice of “Sign” or “SignAndEncrypt” is dependent on the CSMS, in some applications where data confidentiality is not required, “Sign” is sufficient.

User Authentication is achieved when the Client passes user credentials to the Server as specified via Session Services (described in OPC 10000-4). The Server can authenticate the user with these credentials.

The owner (user) of a Session can be changed using the ActivateSession Service in order to meet needs of the application.

User Authentication is not directly part of the Publish-Subscribe communication pattern but is used as part of the SKS associated with this communication pattern.

OPC UA uses a concept conveying Application Authentication to allow applications that intend to communicate to identify each other. Each OPC UA ApplicationInstance has a Certificate (ApplicationInstanceCertificate) assigned that is exchanged during SecureChannel establishment. The receiver of the Certificate checks whether it trusts the Certificate and based on this check it accepts or rejects the request or response Message from the sender. This trust check is accomplished using the concept of TrustLists. TrustLists are implemented as a CertificateStore designated by an administrator. An administrator determines if the Certificate is signed, validated and trustworthy before placing it in a TrustList. A TrustList also stores Certificate Authorities (CA). TrustLists that include CAs, also include Certificate Revocation Lists (CRLs). OPC UA makes use of these industry standard concepts as defined by other organizations.

In OPC UA, HTTPS can be used to create SecureChannels, however, these channels do not provide Application Authentication. If Authentication is required, it is based on user credentials (User Authentication see 4.9). More details on Application Authentication can be found in OPC 10000-4.

OPC UA provides user authorization based on the authenticated user (see 4.9). OPC UA Applications can determine in their own way what data is accessible and what operations are authorized or they can use Roles (see 4.12). Profiles exist to indicate the support of user credentials to restrict or control access to the address space.

OPC UA provides standard approach for implementing role based security. Servers could choose to implement none, part or all of mechanisms defined in OPC 10000-5 and in OPC 10000-18. The OPC UA approach assigns Permissions to Roles illustrated in Figure 6. Clients are then granted Roles based on connection information (Session creation). Roles could be restricted by User Authentication, Application Authentication, SecurityModes, or Transports. The assignment of Roles and restrictions is application specific, but they can be assigned to all Nodes in a Namespace or to specific Nodes.

Figure 6 – Role overview

OPC UA defines a set of standard roles that OPC UA Applications can use, these include SecurityAdmin, ConfigureAdmin, Supervisor, Engineer, Operator, Observer and AuthenticatedUser. They are defined in OPC 10000-3 with recommended permissions. The standard roles are also utilized in various other specification as recommended security setting (e.g. see OPC 10000-12). Roles can be assigned via OAuth2 (see 6.12). Role based security is further defined in OPC 10000-18.

The OPC UA Security Services are a group of abstract service definitions specified in OPC 10000-4 that are used for applying various security mechanisms to communication between OPC UA Clients and Servers. OPC 10000-4 provides an overview of security in the “Service Behaviours” section that includes required behaviours to ensure secure communication.

The Discovery Service Set (specified in OPC 10000-4) defines services used by an OPC UA Client to obtain information about the security policies (see 4.6) and the Certificates of specific OPC UA Servers.

The services of the SecureChannel Service Set (specified in OPC 10000-4) are used to establish a SecureChannel which is responsible for securing Messages sent between a Client and a Server. The challenge of the SecureChannel establishment is that it requires the Client and the Server to securely exchange cryptographic keys and secret information in an insecure environment, therefore a specific Key Exchange Algorithm (similar to TLS Handshake protocol defined in https://www.isa.org/products/ansi-isa-62443-4-2-2018-security-for-industrial-auhttps://www.isa.org/products/ansi-isa-62443-4-2-2018-security-for-industrial-au

TLS) is applied by the communication participants.

Once established, a SecureChannel uses Symmetric Cryptography keys to encrypt and sign all Messages. Symmetric Cryptography requires a shared key. Asymmetric Cryptography is used to create this shared key.

The OPC UA Client retrieves the security policies and Certificates of the OPC UA Server by the previously mentioned discovery services. These Certificates contain the Public Keys of the OPC UA Server.

For RSA the following procedure is used:

• The OPC UA Client sends its Public Key in a Certificate and secret information with the OpenSecureChannel service Message to the Server. This Message is secured by applying Asymmetric Encryption with the Server’s Public Key and by generating Asymmetric Signatures with the Client’s Private Key. However, the Certificate is sent unencrypted so that the receiver can use it to verify the Asymmetric Signature.
• The Server decrypts the Message with its Private Key and verifies the Asymmetric Signature with the Client’s Public Key. The secret information of the OPC UA Client together with the secret information of the OPC UA Server is used to derive a set of cryptographic keys that are used for securing all further Messages. Furthermore, all other service Messages are secured with Symmetric Encryption and Symmetric Signatures instead of the asymmetric equivalents.
• The Server sends its secret information in the service response to the Client so that the Client can derive the same set of SymmetricKeys.

For ECC the following procedure is used:

• The OPC UA Client generates a new temporary key pair and sends the Public Key to the Server.
• The Server verifies the signature on the request, then generates a new temporary key pair and sends the Public Key to the Client.
• Once the Public Keys are exchanged, both the Server and Client derive the SymmetricKeys needed for the secure conversation.

Since Clients and Servers have the same set of cryptographic keys they can communicate securely with each other. The SymmetricKeys used in communication can be deciphered if enough messages using the SymmetricKeys are collected and analysed. These derived cryptographic keys are required to be changed periodically so that attackers do not have unlimited time and unrestricted sequences of Messages to use to determine what the SymmetricKeys are. The time period between changes depends on the number of messages sent using the key. Typically for Client Server communication this would be at least every two hours.

For PubSub communications, the security related definitions are specified in OPC 10000-14 and provide a description of how to secure messages and also how to obtain the security keys required for message security.

The Publisher will utilize the keys provided to secure the message. It will encrypt the body of the message and sign the entire message. Subscribers will utilize the keys to decrypt and verify the signature of the messages. These keys are also SymmetricKeys and follow the same rules with regard to periodically changing them. Since PubSub communication is usually at a higher rate, the time period for between key changes would typically be one hour. But in some case it could be even more often depending on the number of messages secured with the key.

To obtain the required keys, the Publisher or Subscriber make use of Client – Server communication. The keys could also be obtained using session-less method calls.

Clients and Servers generate audit records of successful and unsuccessful connection attempts, results of security option negotiations, configuration changes, system changes, user interactions and Session rejections.

OPC UA provides support for security audit trails through two mechanisms.

First, it provides for traceability between Client and Server audit logs. The Client generates an audit log entry for an operation that includes a request. When the Client issues a service request, it generates an audit log entry and includes the local identifier of the log entry in the request sent to the Server. The Server logs requests that it receives and includes the Client’s entry id in its audit log entry. In this fashion, if a security-related problem is detected at the Server, the associated Client audit log entry can be located and examined. OPC UA does not require the audit entries to be written to disk, but it does require that they be available. OPC UA provides the capability for Servers to generate Event Notifications that report auditable Events to Clients capable of processing and logging them. See OPC 10000-4 for more details on how services in OPC UA are audited.

Second, OPC UA defines audit parameters to be included in audit records. This promotes consistency across audit logs and in Audit Events. OPC 10000-5 defines the data types for these parameters. Other information models can extend the audit definitions. OPC 10000-7 describes Profiles which include the ability to generate Audit Events and use these parameters, including the Client audit record id.

Because the audit logs are used to prove that the system is operating securely, the audit logs themselves should also be secured from unauthorized tampering. If someone without authorization were able to alter or delete log records, this could hide an actual or attempted security breach. Because there are many different ways to generate and store audit logs (e.g. files or database), the mechanisms to secure audit logs are outside the scope of this specification.

In addition, the information in an audit record could contain sensitive or private information, thus the ability to subscribe for Audit Events is restricted to appropriate users and/or applications. As an alternative, the fields with sensitive or private information can instead contain an error code indicating access denied for users that do not have appropriate rights.

The subclauses 4.14.2, 4.14.3, 4.14.4 and 4.14.5 illustrate the behaviour of OPC UA Servers and Clients that support Auditing.

Figure 7 illustrates the simple case of a Client communicating with a Server.

Figure 7 – Simple Servers

In this case, OPC Client “A” executes some auditable operation that includes the invocation of an OPC UA service in Server “D”. It writes its own audit log entry, and includes the identifier of that entry in the service request that it submits to the Server.

The Server receives the request and creates its own audit log entry for it. This entry is identified by its own audit id and contains its own Auditing information. It also includes the name of the Client that issued the service request and the Client audit entry id received in the request.

Using this information, an auditor can inspect the collection of log entries of the Server and relate them back to their associated Client entries.

Figure 8 illustrates the case of a Client accessing services from an aggregating Server. An aggregating Server is a Server that provides its services by accessing services of other OPC UA Servers, referred to as lower layer-Servers.

Figure 8 – Aggregating Servers

In this case, each of the Servers receives requests and creates its own audit log entry for them. Each entry is identified by its own audit id and contains its own Auditing information. It also includes the name of the Client that issued the service request and the Client audit entry id received in the request. The Server then passes the audit id of the entry it just created to the next Server in the chain.

Using this information, an auditor can inspect the Server’s log entries and relate them back to their associated Client entries.

In most cases, the Servers will only generate Audit Events, but these Audit Events will still contain the same information as the audit log records. In the case of aggregating Servers, a Server would also be required to subscribe for Audit Events from the Servers it is aggregating. In this manner, Server “B” would be able to provide all of the Audit Events to Client “A”, including the Events generated by Server “C” and Server “D”.

Figure 9 illustrates the case of a Client accessing services from an aggregating Server that does not support Auditing.

Figure 9 – Aggregation with a non-auditing Server

In this case, each of the Servers receives requests and creates their own audit log entry for them, with the exception of Server “B”, which does not support Auditing. In this case, Server “B” passes the audit id it receives from its Client “A” to the next Server. This creates the required audit chain. Server “B” is not listed as supporting Auditing. In a case where a Server does not support writing audit entries, the entire system can be considered as not supporting Auditing.

In the case of an aggregating Server that does not support Auditing, the Server would still be required to subscribe for Audit Events from the Servers it is aggregating. In this manner, Server “B” would be able to provide all of the Audit Events to Client “A”, including the event generated by Server “C” and Server “D”, even though it did not generate an Audit event.

Figure 10 illustrates the case of a Client that submits a service request to an aggregating Server, and the aggregating service supports that service by submitting multiple service requests to its underlying Servers.

Figure 10 – Aggregating Server with service distribution

In the case of aggregating Servers, a Server would be required to subscribe for Audit Events from the Servers it is aggregating. In this manner, Server “B” would be able to provide all of the Audit Events to Client “A”, including the event generated by Server “C” and Server “D”.