The following sub-clauses reconcile the threats that were described in 4.3against 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 Serverprofiling require SignAndEncryptwhile 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

Compromising User Credentials

X

X

X

Repudiation

X

See 4.3.2for 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 Availabilitycaused by Messageflooding by minimizing the amount of processing done with a Messagebefore the Messageis authenticated. This prevents an attacker from leveraging a small amount of effort to cause the legitimate OPC UA Applicationto 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 Serverhandles before the Clientis authenticated. The response to GetEndpoints is only a set of static information so the Serverdoes not need to do much processing. The response to OpenSecureChannel consumes significant Serverresources because of the signature and encryption processing. OPC UA has minimized this processing, but it cannot be eliminated.

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

First, the Servercould 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 Serverreplies with an error response without performing the signature and encryption processing. Certified OPC UA Serversare required to specify their maximum number of concurrent channels in their product documentation as specified in OPC 10000-7.

OPC UA user and Client Authenticationreduce the risk of a legitimate Clientbeing used to mount a flooding attack. See the reconciliation of Authenticationin 5.2.3.

The Clientprotects itself from floods by have a max message size limit, automatically closing connection where the limit is exceeded. The Clientsalso ignore extra responses that might be received and closes the connection.

In PubSub, the Subscriberfilters 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. PubSubcan also be configured for unicast instead of multicast, which allows the network infrastructure to block multicast flooding attacks.

OPC UA Auditingfunctionality 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 CSMSto prevent attacks such as Messageflooding at protocol layers and systems that support OPC UA.

OPC UA user and Client Authenticationreduce the risk of a legitimate Clientbeing used to mount a resource exhaustion attack. Additionally, Server Auditingallows the detection of the Clientif a resource exhaustion attack was carried out by a legitimate Client. Serversare also required to recycle OpenSecureChannelrequest 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 PubSubSystems, 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 might discover common faults. OPC Foundation stacks are also fuzz tested to ensure they are resilient to errors. Although a certified OPC UA Applicationdoes not guarantee fault free operation, the certified OPC UA Applicationis more likely to be resilient to application crashes caused by denial of service attacks.

See 4.3.3for a description of this threat.

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

See 4.3.4for a description of this threat.

As specified in OPC 10000-4and OPC 10000-6, OPC UA counters Messagespoofing threats by providing the ability to sign Messages. Additionally, Messages will always contain a valid SessionId, SecureChannelId, RequestIdand Timestampas 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 Sessionestablishment. It is important that when a device starts up that the SessionIdthat is initially assigned to the first Sessionis a random number or a continuation of the last Sessionnumber used and is not always reset to 0 or a predictable number.

As specified in OPC 10000-14, OPC UA PubSubcounters Messagespoofing threats by providing the ability to sign messages. Messagescan also contain a valid PublisherId, DataSetClassId, timestamp information, network message number and sequence number, which further restricts Messagespoofing.

See 4.3.5for a description of this threat.

OPC UA counters Messagealteration by the signing of Messages that are specified in OPC 10000-4and 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 Messagealteration due to communication transport errors.

See 4.3.6for a description of this threat.

OPC UA uses SessionIds, SecureChannelIds, Timestamps, sequence numbers and RequestIdsfor every request and response Message. Messages are signed and cannot be changed without detection therefore it would be very hard to replay a Message, such that the Messagewould have a valid Session ID, Secure ChannelID, Timestamp, Sequence Numbers and Request ID. (All of which are specified in OPC 10000-4and OPC 10000-6). The establishment of a secure channel / Sessionincludes the same signature, timestamps and sequence number that are part of all messages and thus cannot be replayed.

OPC UA PubSubuses PublishId, DataSetId, and can use Timestamps, network message numbers, sequence numbers for published messages. Messagescan be signed and cannot be changed without detection therefore it would be very hard to replay a message that has all of the fields enabled. It is worth noting that PubSubdoes allow the disabling of fields in a message. The disabling of the Timestamp, network message number and sequence number, would allow replay attacks. If a replay attack is of concern in a CSMS, then these field should be enabled.

See 4.3.7for a description of this threat.

Implementations of OPC UA Applicationscounter 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-6and OPC 10000-14.

See 4.3.8for a description of this threat.

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

See 4.3.9for a description of this threat.

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

See 4.3.10and 4.3.11for a description of this threat.

OPC UA Clientapplications counter the use of rogue Serversby validating Server ApplicationInstanceCertificates. There would still be the possibility that a rogue Serverprovides a Certificatefrom a certified 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 Keythe rogue Serverwould never be able to read and misuse secured data sent by a Client. Also, without the Private Keythe Serverwould never be able to sign a response message to a Client.

OPCUASubscriberapplications counter the effect of a rogue Publisherby validating the signature on the published messages.

See 4.3.11for a description of this threat.

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

OPC UA depends upon the site CSMSto protect against other attacks to gain user credentials, such as password guessing or social engineering.

See 4.3.13for a description of this threat.

OPC UA Client andServer applications counter Repudiationby the signing of Messages that are specified in OPC 10000-4. A signed message indicates that the message originated from the owner of the private key. During OpenSecureChanneland Sessionestablishment the communicating parties are clearly identified and confirmed. Lastly Auditingas described in OPC 10000-4will track the information associated with the message.