SPONOSORED BY: SOFTWARE TOOLBOX
Summary
This e-book focuses on OPC UA security concepts including but not limited to certificates and message signing, encryption and topics surrounding OPC UA security architecture in your system. It goes beyond that, though, by considering the broader environment in which OPC UA is used and recognizing that most of readers come from the operations technology (OT) space. Engineers & technicians in OT are bombarded with automation technologies, tools, and work to do, while their employer’s IT & cybersecurity teams are trying to prevent disastrous security breaches and issues, all while keeping an industrial operation running at full speed. Also included are detailed guides on configuring secure OPC UA client & server specific communications for six popular OPC UA solutions.
The Layered Approach to OPC UA Security
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 Specs summarize the security focus in three areas:
- Authentication between client and server applications
- The ability to determine whether a user is authorized to connect and/or perform the requested action
- 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 are the Layers in the OPC UA Security Model?
The OPC UA Spec documentation visualizes the OPC UA security model as having three layers:
- 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.
- 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.
- 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.).
Considerations for Your Own OPC UA Security Architecture
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.
- 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.
- 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. You may have good business reasons to not use OPC UA security, and ultimately you own that decision, but 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 offer a starting point to drive a conversation in your organization to ensure a system that meets the unique requirements of your project.