Five Key Considerations for Your Own OPC UA Security Architecture

Summary

Regarding OPC UA security, the OPC UA Specification documentation visualizes the OPC UA security model as having three layers:

1. OPC UA Transport Layer: This is the lowest layer, and the first line of defense. Here we are concerned about the IP address of the machine and the port on which the application is listening. (In most cases, relying on an IP address or port remaining unknown is not really security, just a security incident waiting to happen).

This layer can also include any defenses outside the scope of OPC UA (e.g. firewalls, access control lists, etc.) that could reject a connection before it is ever established.

2. OPC UA Communication Layer: This is where most of the activity occurs. When the OPC UA Client connects to the OPC UA Server, a Secure Channel is established where the certificate exchange occurs. This certificate is then used to not only authenticate the applications and hosts making the connections but also encrypt and sign the messages being sent.

If the certificates that the client and/or server are using are not trusted–then the OPC UA Application can reject the connection attempt as the Secure Channel Is being established. This is significant because insecure connection attempts should be rejected as low on the protocol stack as possible–to avoid denial of service or resource exhaustion type of attacks; where a malicious app simply opens connections to consume server-side resources and drive the server to a point where it is unable to service legitimate connection attempts.

3. OPC UA Application Layer: This where user authentication and OPC UA call/command authentication occurs. By the time we make it to this layer, we already know that the host and application making the call is trusted, the conversation between OPC UA Client and OPC UA Server is secured and, as such, the only thing left to verify is whether the user interacting with the application is authorized to access the resources in question.

The way this typically works is that the user credentials are provided when the session is activated, and if the user is authorized to activate the session (and connect to the UA Server) then the UA Server will return a security ‘token’ that all future calls made by this user must include. By including this ‘token’ on future calls, the server can reject access to specific resource (i.e. cert tags/nodes may not be accessible by every user, some users might have read only access, etc.).

With those three security layers in mind, there are several considerations that should be kept in mind when designing a system that implements OPC UA Clients and Servers.

1. Do not rely on security through obscurity. If the only security implemented on the system is the hope that an attacker cannot figure out the server IP and port, you are a short NMAP scan away from a potentially compromised system. This is especially dangerous on publicly exposed OPC UA Servers or any system.

2. Be conscious of what certificates you are trusting. Given the importance of the Secure Channel and the critical nature of the proper use of the OPC UA Application Certificates, simply accepting and trusting every certificate effectively negates the purpose of having this layer. (i.e. a firewall is not effective if it simply allows every connection) Take care and review certificates before trusting them; things to look for are:

• Is the host one that I trust and want to allow to connect to me?
• Is the application one that I trust and want to allow to connect to me?
• How long is this certificate valid for and does that adhere to my IT best practices to make sure certificates are regularly updated and renewed?

• Is the system going to be exposed publicly or only be accessible on an intranet?
• Is the network going to be accessible by parties that–while authorized to be on the network–should not be able to monitor the OPC UA Communications?
• How many clients will be connecting on this system?
• Are we using any other security (like user authorization or firewalls)?

• And, if yes–what level of granularity does my OPC UA Server support for allowing me to configure user access permissions (i.e. can I restrict read/write access, access to specific tags, etc.)?

5. Are we siloing user access to only those resources the user needs to access? Or is every user a root user with full administrative rights?

The list of considerations to evaluate when planning the design for a secure OPC UA architecture is