The following sub-clauses 5.1.2 through 5.1.15 reconcile the threats that were described in 4.3 against the OPC UA functions. Compared to the reconciliation with the objectives that will be given in 5.2, this is a more specific reconciliation that relates OPC UA security functions to specific threats. A summary of the reconciliation is available in Table 1. Only eavesdropping and Server profiling require SignAndEncrypt while all other are mitigated with SignOnly. [ (X) indicates indirectly].

Table 1 – Security Reconciliation Threats Summary

Attacks	Authentication	Authorization	Confidentiality	Integrity	Auditability	Availability	Non-Repudiation
Denial of Service						X
Eaves Dropping	X	X	X
Message Spoofing		X
Message Alteration	X	X		X	X		X
Message Replay	X	X
Malformed Messages						X
Server Profiling	(X)	(X)	(X)	(X)	(X)	(X)	(X)
Session Hijacking	X	X	X	X	X	X	X
Rogue Server	X	X	X		X	X
Rogue Publisher	X		X		X	X
Rogue Local Discovery	X	X	X		X	X
Compromising User Credentials	X	X	X
Repudiation							X
Message Suppression				X		X
Downgrade Attack	X	X

See 4.3.2 for a description of this threat. For discussion purposes denial of service is broken into three major categories message flooding, resource exhaustion and application crashes.

OPC UA minimizes the loss of Availability caused by Message flooding by minimizing the amount of processing done with a Message before the Message is authenticated. This prevents an attacker from leveraging a small amount of effort to cause the legitimate OPC UA Application to spend a large amount of time responding, thus taking away processing resources from legitimate activities.

GetEndpoints (specified in OPC 10000-4) and OpenSecureChannel (specified in OPC 10000-4) are the only services that the Server handles before the Client is authenticated. The response to GetEndpoints is only a set of static information so the Server does not need to do much processing. The response to OpenSecureChannel consumes significant Server resources because of the signature and encryption processing. OPC UA has minimized this processing, but it cannot be eliminated.

The Server implementation could protect itself from floods of OpenSecureChannel Messages in two ways.

First, the Server could intentionally delay its processing of OpenSecureChannel requests once it receives more than some minimum number of bad OpenSecureChannel requests. It should also issue an alarm to alert plant personnel that an attack is underway that could be blocking new legitimate OpenSecureChannel calls.

Second, when an OpenSecureChannel request attempts to exceed the Server’s specified maximum number of concurrent channels the Server replies with an error response without performing the signature and encryption processing. Certified OPC UA Servers are required to specify their maximum number of concurrent channels in their product documentation as specified in OPC 10000-7.

OPC UA user and Client Authentication reduce the risk of a legitimate Client being used to mount a flooding attack. See the reconciliation of Authentication in 5.2.3.

The Client protects itself from floods by have a max message size limit, automatically closing connections where the limit is exceeded. The Clients also ignore extra responses that could be received and closes the connection.

In PubSub, the Subscriber filters messages that it processes based on header information, allowing it to quickly discard any messages that do not conform to its required filter. In addition, the message signature is checked to eliminate any message that is well formed, but not from the desired SecurityGroup. PubSub can also be configured for unicast instead of multicast, which allows the network infrastructure to block multicast flooding attacks.

OPC UA Auditing functionality provides the site with evidence that can help the site discover that flooding attacks are being mounted and find ways to prevent similar future attacks (see 4.14). As a best practice, Audit Events should be monitored for excessive connection requests.

OPC UA relies upon the site CSMS to prevent attacks such as Message flooding at protocol layers and systems that support OPC UA.

OPC UA user and Client Authentication reduce the risk of a legitimate Client being used to mount a resource exhaustion attack. Additionally, Server Auditing allows the detection of the Client if a resource exhaustion attack was carried out by a legitimate Client. Servers are also required to recycle OpenSecureChannel request that have not been completed (specified in OPC 10000-4), this will eliminate attacks from non-legitimate Clients. Resource exhaustion attacks do not apply to PubSub Systems, since no sessions or resources are allocated.

OPC UA provides certification of OPC UA Applications. The lab testing and certification includes testing by injecting error and junk commands which could discover common faults. OPC Foundation stacks are also fuzz tested to ensure they are resilient to errors. Although a certified OPC UA Application does not guarantee fault free operation, the certified OPC UA Application is more likely to be resilient to application crashes caused by denial of service attacks.

See 4.3.3 for a description of this threat.

OPC UA provides encryption to protect against eavesdropping as described in 5.2.5.

See 4.3.4 for a description of this threat.

As specified in OPC 10000-4 and OPC 10000-6, OPC UA counters Message spoofing threats by providing the ability to sign Messages. Additionally, Messages will always contain a valid SessionId, SecureChannelId, RequestId and Timestamp as well as the correct sequence number. OPC UA when operating as part of a Session, restricts user spoofing in the same manner since the user information is provided as part of the Session establishment. It is important that when a device starts up that the SessionId that is initially assigned to the first Session is a random number or a continuation of the last Session number used and is not always reset to 0 or a predictable number.

As specified in OPC 10000-14, OPC UA PubSub counters Message spoofing threats by providing the ability to sign messages. Messages can also contain a valid PublisherId, DataSetClassId, timestamp information, network message number and sequence number, which further restricts Message spoofing.

In session-less communication, to counter message spoofing Clients and Server should restrict session-less communication to be over SecureChannels. See 4.5.2.5 and for additional session-less security related information.

See 4.3.5 for a description of this threat.

OPC UA counters Message alteration by the signing of Messages that are specified in OPC 10000-4 and OPC 10000-14. If Messages are altered, checking the signature will reveal any changes and allow the recipient to discard the Message. This check can also prevent unintentional Message alteration due to communication transport errors.

See 4.3.6 for a description of this threat.

OPC UA uses SessionIds, SecureChannelIds, Timestamps, sequence numbers and RequestIds for every request and response Message. Messages are signed and cannot be changed without detection, therefore it would not be possible to replay a Message without it being detected and rejected. The establishment of a SecureChannel or Session includes the same signature, timestamps and sequence number that are part of all messages and thus cannot be replayed.

OPC UA PubSub uses PublisherIds, DataSetWriterIds, Timestamps, network message numbers and sequence numbers in published messages. When Messages are optionally signed they cannot be changed without detection, therefore it can be configured that replay of a message is not possible. It is worth noting that PubSub does allow the disabling of fields in a message. The disabling of the Timestamp, network message number and sequence number, could allow replay attacks. If a replay attack is of concern in a CSMS, then these fields need to be enabled.

For session-less communication, OPC UA uses Timestamps, sequence numbers and RequestIds for every request and response Message. Messages are signed and cannot be changed without detection therefore it would not be possible to replay a Message.

See 4.3.7 for a description of this threat.

Implementations of OPC UA Applications counter threats of malformed Messages by checking that Messages have the proper form and that parameters of Messages are within their legal range. Invalid Messages are discarded. This is specified in OPC 10000-4, OPC 10000-6 and OPC 10000-14.

See 4.3.8 for a description of this threat.

OPC UA limits the amount of information that Servers provide to Clients that have not yet been identified. This information is the response to the GetEndpoints service specified in OPC 10000-4.

See 4.3.9 for a description of this threat.

OPC UA counters Session hijacking by assigning a security context (i.e. SecureChannel) with each Session as specified in the CreateSession Service in OPC 10000-4. Hijacking a Session would thus first require compromising the security context.

See 4.3.10 and 4.3.11 for a description of this threat.

OPC UA Client applications counter the use of rogue Servers by validating Server ApplicationInstanceCertificates. There would still be the possibility that a rogue Server provides a Certificate from a trusted OPC UA Server, but since it does not possess the appropriate Private Key (because this will never be distributed) to decrypt Messages secured with the correct Public Key the rogue Server would never be able to read and misuse secured data sent by a Client. Also, without the Private Key the Server would never be able to sign a response message to a Client.

If communication is secured using ECC, then the Client would refuse to establish a SecureChannel with the rogue Server. If a rogue server attempted to hijack a running connection, it would not be able to generate signed messages to the Client. OPC UA Subscriber applications counter the effect of a rogue Publisher by validating the signature on the published messages.

See 4.3.12 for a description of this threat.

OPC UA Client can counter a rogue Discovery Server, by only connecting to Servers that are trusted. This protects the Client against malicious Server. The use of a GDS can also mitigate the effect of a compromised Local Discovery Server.

A GDS, that aggregates information from Local Discovery Servers does not trust the input from the Local Discovery Servers, until it is confirmed. Confirmation can occur by the Server application registration for certificate services or other secure access to the GDS. It can also be confirmed by administrative personnel.

See 4.3.11 for a description of this threat.

OPC UA protects user credentials sent over the network by encryption as described in 5.2.5.

When using an AuthorizationService for identity verification then securing the user identity is out of scope for OPC UA. It is essential that the CSMS take AuthorizationServices into account. OPC UA depends upon the site CSMS to protect against other attacks to gain user credentials, such as password guessing or social engineering.

The risk from a compromised AuthorizationService can be minimized by restricting Server access in additional manners, such as from specific applications (Clients) or at specific times.

See 4.3.15 for a description of this threat.

OPC UA Client and Server applications counter Repudiation by the signing of Messages that are specified in OPC 10000-4. A signed message within a secure channel indicates that the message originated from the owner of the private key. During OpenSecureChannel and Session establishment the communicating parties are clearly identified and confirmed. Lastly Auditing as described in OPC 10000-4 will track the information associated with the message.

See 4.3.16 for a description of this threat. A Client and Server can counter message suppression by using checking the SequenceNumber in the sequence header. A SecureChannel is required to be closed if a SequenceNumber is missed. This allows both a Server and a Client to detect if a message is supressed. Both the Server and Client are required to report the error (Bad_SequenceNumberInvalid).

See 4.3.17 for a description of this threat. A Client can counter a downgrade attack, by verifying the available communication options once a secure connection is established to the Server. If the list of secure connection provided in activate Session is different from the list provided in discovery, the Client disconnects and reports an error (see OPC 10000-4). Downgrade attacks can also be countered by not enabling lower security options system wide.

The following sub clauses reconcile the objectives that were described in 4.2 with the OPC UA functions. Compared to the reconciliation against the threats of 5.1, this reconciliation justifies the completeness of the OPC UA security architecture.

OPC UA Applications support Authentication of the entities with which they are communicating. As specified in the GetEndpoints and OpenSecureChannel services in OPC 10000-4, OPC UA Client and Server applications identify and authenticate themselves with X.509 v3 Certificates and associated private keys (X.509 v3 Certificates are defined in [X509]). Some choices of the communication stack require these Certificates to represent the machine or user instead of the application.

For publish subscribe communications Client Server communications is required to obtain the shared keys from a SecurityKeyService (SKS). Although the application authentication is not directly between the Subscriber and the Publisher, the SKS ensures that only authenticated applications can obtain the keys used by the Publisher and Subscriber.

OPC UA Applications support Authentication of users by providing the necessary Authentication credentials to the other entities. As described in the ActivateSession service in OPC 10000-4, the OPC UA Client accepts a UserIdentityToken from the user and passes it to the OPC UA Server. The OPC UA Server authenticates the user token. OPC UA Applications accept tokens in any of the following forms: username/password, X.509 v3 Certificate (see [X509]), or JSON Web Token (JWT).

As specified in the CreateSession and ActivateSession Services in OPC 10000-4, if the UserIdentityToken is a Certificate then this token is validated with a challenge-response process. The Server provides a Nonce and signing algorithm as the challenge in its CreateSession response. The Client responds to the challenge by signing the Server’s Nonce and providing it as an argument in its subsequent ActivateSession call.

For session-less services User Authentication can be accomplished using an AccessToken which is obtained from an AuthorizationService (see OPC 10000-6 for details). This does require that an encrypted communication channel be used (see OPC 10000-4 for a general overview).

Authorization could be provided via Roles (4.12) and supplied by a Authorization Server in a GDS. In an environment of mixed vendor products, the GDS can provide a consistent Authorization management. OPC UA Applications that are part of a larger industrial automation product can manage Authorizations consistent with the Authorization management of that product. Identification and Authentication of users is specified in OPC UA so that Client and Server applications can recognize the user in order to determine the Authorization level of the user.

OPC UA Servers respond with the Bad_UserAccessDenied error code to indicate an Authorization or Authentication error as specified in the status codes defined in OPC 10000-4.

In PubSub interactions user Authorization can be used as part of the key distribution (SKS). This allows the Publisher and SKS to restrict access to specific users

OPC UA uses Symmetric and Asymmetric Encryption to protect Confidentiality as a security objective. Thereby Asymmetric Encryption is used for key agreement and Symmetric Encryption for securing all other Messages sent between OPC UA Applications. Encryption mechanisms are specified in OPC 10000-6 and OPC 10000-14.

OPC UA relies upon the site CSMS to protect Confidentiality on the network and system infrastructure. OPC UA relies upon the PKI(public key infrastructure) to manage keys used for Asymmetric Encryption which is then used to establish symmetric session keys. The length of the certificate chain is defined by the site CSMS (only local TrustList with self-signed Certificates or a full CA/CRL infrastructure).

OPC UA uses Symmetric and Asymmetric Signatures to address Integrity as a security objective. The Asymmetric Signatures are used in the key agreement phase during the SecureChannel establishment. The Symmetric Signatures are applied to all other Messages including PubSub messages.

OPC UA relies upon the site CSMS to protect Integrity on the network and system infrastructure. OPC UA relies upon the PKI to manage keys used for Asymmetric Signatures which is then used to establish symmetric session keys.

As specified in the UA Auditing description in OPC 10000-4, OPC UA supports Audit logging by providing traceability of activities through the log entries of the multiple Clients and Servers that initiate, forward, and handle the activity. OPC UA depends upon OPC UA Application products to provide an effective Audit logging scheme or an efficient manner of collecting the Audit Events of all nodes. This scheme can be part of a larger industrial automation product of which the OPC UA Applications are a part.

OPC UA minimizes the impact of Message flooding as described in 5.1.2.

Some attacks on Availability involve opening more Sessions than a Server can handle thereby causing the Server to fail or operate poorly. Servers reject Sessions that exceed their specified maximum number. Other aspects of OPC UA such as OPC UA Secure Conversation can also affect availability and are discussed in OPC 10000-6.