SPONSORED BY: Software Toolbox
You have likely heard that OPC UA offers strong, natively built-in security. However, you may not be familiar with the multiple security risk areas covered, what you should consider in their implementation, and how to practically leverage OPC UA’s security across systems, both old and new.
In this article we will discuss these factors at varying levels of technical depth, but also provide links to other resources for those wanting to get into deep technical details. We will also discuss practical implementation considerations around firewalls, certificate management, varying levels of standards implementation, and legacy application integration with OPC UA.
OPC UA Security Model Background
A strength of OPC UA is that its security is implemented in multiple places and methods to address different risks:
- Is the OPC UA connection request coming from a system and software application that I trust, if not, it should be stopped immediately, to avoid denial of service attacks on the UA server
- And how do we keep the client-server conversations secret; not just at the time of connection, but over time, especially with increasing computing power making algorithms easier to break?
- Who is the connecting user? And are they authorized to connect based on their authentication credentials?
- What rights, to read or write to resources on my system, have I authorized for that user?
OPC UA implements a layered approach, where each layer takes responsibility for different parts of security and quickly rejects unapproved sources, users, or actions. For users, this is all handled by the OPC client and server product implementation, abstracting the details for you to configuration steps. If you are developing an application, there are toolkits that also abstract the details.
The OPC UA specification documentation visualizes the OPC UA security model as having three layers that address the 4 areas mentioned above, as shown below. The benefit of multiple layers is the ability to stop issues before they can get to the next layer.
- 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. Relying on an IP address or port remaining unknown is not genuine security; therefore, this layer can, and should, include defenses outside the scope of OPC UA (e.g. firewalls, IP based access control lists, etc.) that will reject a connection before it is ever established at any OPC UA layer.
- OPC UA Communication Layer – This is where most of the OPC UA communication activity occurs and where factors 1 and 2 in our list are addressed.To address factor 1, a robust method is needed to uniquely identify each combination of software application and machine. Secure certificates is that method. When you install and configure your OPC Client and OPC Server, the applications should guide you through, or automatically generate, a self-signed certificate instance for you that is unique to the application and the computer. We’ll talk more about Certificate Authority (CA) issued certificates and global certificate management later.
The first time the client and server application connect, the person setting up the system should inspect the certificate details through the software user interface and make a trust decision – factor number 1 from our list. Once that decision is made, it does not have to be made again, unless either or both certificates change by either the issuing application or if they are otherwise altered.
Imagine that a certificate has been altered and is no longer trusted. The OPC UA Application should reject the connection attempt as the Secure Channel Is being established. This is significant, because insecure connection attempts should be immediately rejected as low on the protocol stack as possible. This helps prevent denial of service or resource exhaustion types 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.
Once the connection is made and secured, using the certificate exchanged between client and server, the client and server then generate a time limited secure key pair inside that secure connection that allows for rapid secure data exchange. At a user configurable time period, the client and server generate new keys, which further reduces the risk of anyone getting in the middle of the conversation over time. This addresses factor number 2.
Readers wanting to learn more about the details of how this works should refer to our technical blog on OPC UA Certificate Basics and OPC UA Symmetrical and Asymmetrical Key Exchanges.
- OPC UA Application Layer – This is where factors 3 and 4 in our list are handled: 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 the application making the call have trusted each other; the conversation between OPC UA client and OPC UA server is secured through encryption. The only thing left to verify is whether the user, who interacting with the application, is authorized to access the resources in question and to then restrict them to only the rights assigned to their credentials.The way this typically works is that the user credentials are provided by the OPC UA client application as the OPC UA 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 restrict access to specific resources (i.e. certain tags/nodes may not be accessible by every user, some users might have read-only access, etc.)
Practical Considerations When Implementing your OPC UA Based System
So that deep technical information is great, but what about practical advice to get started? We’ve compiled these points from our experience working with users and system integrators implementing OPC since 1996, and OPC UA since its release.
Security Only Works if Enabled
Right, it sounds like an obvious statement, but our solutions consultants and support team regularly encounter user systems with OPC UA security turned off or set to minimal levels. Maybe you do that for troubleshooting, but you should never leave a production system operational with the client & server support across all layers of OPC UA security left in a state where they are disabled!
Know Who to Trust, Configure It, & Remove Default Users
To utilize authentication and authorization, factors 3 and 4, your OPC UA client and server will need to support users, and they will need to be configured with the desired level of user access permissions (i.e. can I restrict read/write access, access to specific tags, etc)? Ideally, you will operate on a zero-trust principle and only allow users access to what they need. Never leave default users and passwords enabled if the product has any or allow users full-access that do not need it.
Careful What Certificates You Trust
It’s also important to be conscious of which certificates you are trusting from what systems & applications. Given the importance of the OPC UA 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?
In the simplest case, certificate exchange between a single client and server should be easy. In the case of many clients and servers, this could become a challenge to manage the N-N large number of connections. There is also the question of self-signed certificates. In practice, in today’s OPC UA implementations, most connections are using certificates that were generated by and “signed” for long validity periods by the system that generated them.
You may know this, but public websites are secured using certificates that were issued by and signed by a third-party known as a Certificate Authority (or CA) such as Digicert, Google, Lets Encrypt, and many others, not self-signed. CA issued certificates have a limited lifetime and provide public revocation lists. If a certificate is hacked, or otherwise compromised, it can be revoked, and browsers and servers then know to not trust those certificates. Currently, we do not see OPC UA systems using CA signed certificates much in practice; however, we believe that will change due to a vendor agnostic management tool that is becoming available.
How to manage large number of systems? Or Use CA Signed Certificates?
This is where a software application called a Global Discovery Server (GDS) comes in. This technology, as part of the OPC UA specification, provides a means for a central software application, in an enterprise, to manage certificates for many clients and servers. Server and client applications register their certificates with the GDS server one time; and administrators approve trusts one time. From then on, all clients and servers use the GDS to get connected and avoid the 1-1 exchange and approvals, and approvals are managed centrally by a trained administrator. The central management opens possibilities for central certificate issuance, use of CA signed certificates, checking of revocation lists, and, eventually, shorter lifetime certificates through automated renewals, as industry battles ever increasing compute power, reducing the time it takes to break encryption keys.
There is also a version of a GDS called a “Local Discovery Server” or LDS, that operates on a single machine, with those being more common today; but GDS applications are becoming more common as more suppliers work to implement support for them. In our testing and implementation work, we like to use the Unified Automation GDS application.
You can learn more about LDS and GDS in our technical deep dive blog.
Firewall Ports and OPC UA Communications
We’ve discussed this in another technical blog the perils of opening any firewall ports and IP addresses. 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 IP and port scan on your network away from a potentially compromised system. Do not do it!
As a vendor, we cannot recommend that you ever open ports for inbound communications nor expose your network through VPNs or other means. It’s best to initiate conversations from secure layers out to DMZ’s or external systems.
There is a new part of the OPC UA standard called OPC Reverse Connect that has been released, and in time being adopted by suppliers. However, in the meantime, there are solutions that can sit in a DMZ and receive outbound data from secure areas and help you get the benefits of exchanging data using a DMZ, data diodes and proxies for existing OPC Classic applications and more. You can learn more in our Connect Differently technical blog post.
N-N Connections / OPC UA Publish & Subscribe
Besides offering the GDS for large scale certificate management, the OPC UA specifications also include a publish/subscribe implementation that can use MQTT and brokers for transport, offering users the opportunity to use the robustly defined OPC UA companion specifications or user-defined information models to MQTT publish & subscribe implementations. Software Toolbox offers OPC UA Pub/Sub support in the OPC Router product and for application developers in the OPC Data Client Toolkit.
Varying Levels of OPC UA Functionality
A sometimes-heard criticism of OPC UA is that there are too many pages of specifications and parts. It is true that the OPC UA specification has many parts, but vendors and developers need only implement what they plan to use, starting with the base functionality which always includes security, and most often generic data for real-time data exchange. We like to compare this concept to a restaurant with a large menu. You never go in for dinner and order everything they offer for one meal. You order only what you want. With OPC UA you consume and implement only what you need.
Beyond the core functionality, based on the type of software or device, vendors may implement Alarms & Conditions or History. They may also implement their own information models or even the OPC Foundation Companion Specification models. So, what happens when you encounter a system that you need to integrate that implements a portion of OPC UA that you haven’t yet implemented?
Fortunately, there are solutions for this that empower smooth integration between these systems. You can learn more in our technical blog post about leveraging OPC UA Companion Specs and OPC UA Pub Sub or another blog post about transforming data between different portions of the OPC specifications.
Systems Not Yet Supporting OPC UA
The world we operate in has a mix of technologies and there are solutions to help. We covered this in detail in our Making the Most of Secure OPC UA Data Access article in OPC Connect. We also recently published a story about a logistics implementation that used a combination of OPC classic and OPC UA.
Conclusions and Resources for Learning More
OPC UA provides a robust, multi-layered security model that addresses the variety of risks that present in OT integration. In practice, users and integrators encounter systems with different levels of functionality and technological age. Those users are able to still leverage OPC UA through off-the-shelf solutions that seamlessly let them gain the benefits of OPC UA while not having to rip and replace existing systems.
To learn more about OPC UA Security and implementations of OPC UA Security in action in several Software Toolbox solutions, download our OPC UA Security Concepts E-Book
About Software Toolbox
Software Toolbox, founded in 1996 and a Charter Member of the OPC Foundation, was the world’s first industrial automation software company focused on software that leverages open standards for OT, IT, business and now cloud systems. Through our early leveraging the internet for global support reach we’ve built an installed base on every continent (yes even the South Pole Station!), they are known for their technical expertise across their variety of solutions that empowers success and reduces the risk of multi-vendor applications. Our raving fan users that trust our brand are a clear testament to the value we provide through the Software Toolbox way.