Exploring OPC UA - Key Concepts of a Layered Security Model

So far in our ongoing Exploring OPC UA blog series, we have taken a primarily general look at OPC UA Certificates and how they are used by OPC UA clients and OPC UA servers to keep industrial data secure.

In this third post of the series, we'll take a step back and look at OPC UA security in general with respect to the layered approach that is employed to cover aspects such as authentication, confidentiality and the integrity of communications.

A core pillar of OPC UA is the focus on security, not just for data integrity reasons, but also for service availability. The OPC UA specifications summarize the security focus should be in three areas:

1. Authentication between client and server applications
2. The ability to determine whether a user is authorized to connect and/or perform the requested action
3. The confidentiality and integrity of the communications.

This means that a strictly layered approach to security is pivotal to an OPC UA implementation, where each layer is responsible for verifying that the connection/action is allowed, and any unapproved actions can be rejected quickly.

What layers are involved in the OPC UA security model?

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 that this blog series has focused on 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 (Part 1 and Part 2 of this blog series look at this a little closer).
   
   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 is 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 resources (i.e. cert tags/nodes may not be accessible by every user, some users might have read only access, etc.)

Considerations when designing your own OPC UA security model

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

• 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. Do not do it! Especially on publicly exposed OPC UA servers.

• 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?

• All this talk of certificates becomes somewhat pointless if the OPC UA server endpoint is not configured to use security. While I would not go so far as to recommend that every OPC UA connection should be encrypted and secured – it is something that must be taken into consideration when designing a system.

  • 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)?

• Does my server allow me to configure users?

  • 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)?

• 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 considerably longer than what is listed above, but these should offer an easily digestible starting point to drive an internal conversation about the needs of your organization.

Subscribe to our blog to stay tuned for the rest of this series where we will be looking at how to specifically secure OPC UA solutions available from Software Toolbox, which should be useful to our users migrating to OPC UA but uncertain of how to take full advantage of the security benefits.