5 Security reconciliation
5.1 Reconciliation of threats with OPC UA security mechanisms
5.1.1 Overview
The sub-clauses 5.1.2, 5.1.3, 5.1.4, 5.1.5, 5.1.6, 5.1.7, 5.1.8, 5.1.9, 5.1.10, and 5.1.11 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.
5.1.2 Message flooding
See 4.3.2 for a description of this threat.
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 Part 4) and OpenSecureChannel (specified in Part 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 Part 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.
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.12). 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.
5.1.3 Eavesdropping
See 4.3.3 for a description of this threat.
OPC UA provides encryption to protect against eavesdropping as described in 5.2.5.
5.1.4 Message spoofing
See 4.3.4 for a description of this threat.
As specified in Part 4 and Part 6, OPC UA counters Message spoofing threats by providing the ability to sign Messages. Additionally Messages will always contain a valid Session ID, Secure Channel ID, Request ID, Timestamp as well as the correct sequence number.
5.1.5 Message alteration
See 4.3.5 for a description of this threat.
OPC UA counters Message alteration by the signing of Messages that are specified in Part 4. 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.
5.1.6 Message replay
See 4.3.6 for a description of this threat.
OPC UA uses Session IDs, Secure Channel IDs, Timestamps, Sequence Numbers and Request IDs for 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 Message would have a valid Session ID, Secure Channel ID, Timestamp, Sequence Numbers and Request ID. (All of which are specified in Part 4 and Part 6).
5.1.7 Malformed Messages
See 4.3.7 for a description of this threat.
Implementations of OPC UA Client and Server products 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 Part 4 and Part 6.
5.1.8 Server profiling
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 Part 4.
5.1.9 Session hijacking
See 4.3.9 for 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 Service in Part 4. Hijacking a Session would thus first require compromising the security context.
5.1.10 Rogue Server
See 4.3.10 for a description of this threat.
OPC UA Client applications counter the use of rogue Servers by validating Server Application Instance Certificates. There would still be the possibility that a rogue Server provides a Certificate from a certified OPC UA Server, but since it does not possess the appropriate Private Key (because this will never be distributed) to decrypt and verify Messages secured with the correct Public Key the rogue Server would never be able to read and misuse secured data sent by a Client.
5.1.11 Compromising user credentials
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.
OPC UA depends upon the site CSMS to protect against other attacks to gain user credentials, such as password guessing or social engineering.
5.2 Reconciliation of objectives with OPC UA security mechanisms
5.2.1 Overview
The sub clauses 5.2.2, 5.2.3, 5.2.4, 5.2.5, 5.2.6, 5.2.7 and 5.2.8 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.
5.2.2 Application Authentication
OPC UA Applications support Authentication of the entities with which they are communicating. As specified in the GetEndpoints and OpenSecureChannel services in Part 4, OPC UA Client and Server applications identify and authenticate themselves with X.509 Certificates (see [X509]). Some choices of the Communication Stack require these Certificates to represent the machine or user instead of the application.
5.2.3 User Authentication
OPC UA Applications support Authentication of users by providing the necessary Authentication credentials to the other entities. As described in the OpenSecureChannel service in Part 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 three forms: username/password, an X.509v3 Certificate (see [X509]) or a WS-SecurityToken.
As specified in the CreateSession and ActivateSession Services in Part 4, if the UserIdentityToken is a Digital 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.
5.2.4 Authorization
OPC UA does not specify how user or Client Authorization is to be provided. OPC UA Applications that are part of a larger industrial automation product may 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 Part 4.
5.2.5 Confidentiality
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 Part 6. OPC UA relies upon the site CSMS to protect Confidentiality on the network and system infrastructure. OPC UA relies upon the PKI to manage keys used for Symmetric and Asymmetric Encryption.
5.2.6 Integrity
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 Secure Channel establishment. The Symmetric Signatures are applied to all other 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 Symmetric and Asymmetric Signatures.
5.2.7 Auditability
As specified in the UA Auditing description in Part 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 may be part of a larger industrial automation product of which the OPC UA Applications are a part.
5.2.8 Availability
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 or WS Secure Conversation can also affect availability and are discussed in Part 6