Why is OPC-UA Important
In the rapidly evolving landscape of industrial automation, the OPC-UA protocol stands out as a cornerstone technology, celebrated for its interoperability, rich information modeling capabilities, and much more. Equipment, devices, servers and clients require interoperability, especially when dealing with diverse data formats from various devices, software, and machines. OPC-UA ensures data from different sources is correctly interpreted and communicated in formats each source can understand.
OPC-UA is widely adopted in Operational Technology (OT) industries such as process control, oil and gas, food and beverage, waste management and pharmaceutical industries with continued growth due to the following reasons:
-
Enables smart manufacturing. More on Smart Manufacturing.
-
Contributes to the reduction of complexity in communication between OT Systems and data repositories
-
Accommodates legacy and new OT systems
-
Supports an open data format
In this blog post we’ll share how the OPC-UA protocol is structured, understand what to be aware of when consuming OPC-UA supported products, and where to learn more about the protocol.
How the Protocol Works
Let’s take a deeper dive into how the OPC-UA protocol works by looking at the OPC-UA message format and walking through an example. OPC-UA is known for its robust and flexible data modeling capabilities, providing secure and reliable communication across diverse systems. Its hierarchical structure enables efficient data organization and interoperability, making it ideal for complex industrial applications. The following is a high level structure for an OPC-UA message:
Name | Description |
MessageType | A three byte ASCII code that identifies the Message type. |
Reserved | Ignored. Set to the ASCII codes for ‘F’ if the MessageType is one of the values supported by the OPC UA Connection Protocol. |
MessageSize | The length of the Message, in bytes. This value includes the 8 bytes for the Message header. |
Body | The Body of the message. |
The main benefits of OPC-UA are within the Body of the message which has a hierarchical structure organized into an address space that consists of nodes representing various elements such as objects, variables, methods, and references. These nodes are connected in a way that defines their relationships and dependencies, creating a nested structure for organized data access and manipulation.
For example, an “Assembly Line'' could represent an object node within the OPC-UA data structure to monitor many operating machines within an assembly line. Here is how the hierarchical structure could be leveraged in this example:
-
Assembly Line Object: The top-level node representing the entire assembly line.
-
Machine Object Nodes: Nested within the assembly line node, each representing an individual machine.
-
Sensor Variable Nodes: Contained within each machine node, these nodes provide specific data points such as temperature and pressure readings.
The systems can use the hierarchical structure to collect data from various sensors (e.g., temperature, pressure) nested under each machine node and aggregate this information at the assembly line level to monitor overall performance or trigger actions from data thresholds or anomalies.
Other examples could be for managing connections between systems at a smart manufacturing site organized by rooms and floors within a building or at an oil and gas drilling site organized by drills and rigs.
While the Body of the message provides the main benefits of OPC-UA, the SecureChannel layer in the MessageType field defines the security properties of the connections. The SecureChannel sets up important security configuration options for encryption and authentication for OPC-UA messages with the server.
It is important to note that the services configured in the SecureChannel are typically not implemented by the OPC-UA Application directly. Instead, they are provided by the communication stack that the OPC UA Application is built on.
How Vendors Support OPC-UA on Deployed Systems
When a customer buys a system with an OPC-UA server, they typically need to configure several aspects to ensure proper integration and operation. Here’s a list of what they might be responsible for:
-
Network Settings: Configure IP addresses and communication ports for endpoints that support the customer network infrastructure.
-
Security Settings: Set up security policies and user authentication mechanisms. This includes configuring user accounts, roles, and permissions, as well as encryption and security certificates.
-
Data Access and Configuration: Set up which data points or tags will be exposed by the OPC-UA server, including configuring the data model and mapping it to the server's data source.
-
Client Configuration: Ensure that OPC-UA clients are properly configured to connect to the server. This includes setting up the correct server URL, security settings, and subscription details. A few example OPC-UA clients: UAExpert (free), Prosys OPC-UA CLient (free for personal use), and KEPServerEX (paid)
-
Alarm and Event Settings: Configure how alarms and events are handled, including setting up the rules for when alarms are triggered and how they are communicated.
-
Logging and Diagnostics: Set up logging and diagnostic tools to monitor the server’s performance and troubleshoot any issues that arise.
-
Integration with Other Systems: If the OPC-UA server is part of a larger system, a customer will need to configure it to work with other systems or software platforms.
It is common for customers responsible for OT networks to collaborate with integration providers that specialize in setting up a complex thread of systems leveraging OPC-UA.
Common Cybersecurity Pitfalls of OPC-UA
While OPC-UA offers a robust set of security features it is important to understand the potential security pitfalls to safeguard critical infrastructure from vulnerabilities and cyber threats.
If evaluating OPC-UA capabilities for a specific vendor provided technology, it is essential to conduct a thorough assessment to ensure the solution meets your needs. For security items that are the responsibility of the vendor to provide, we recommend verifying the following items:
-
ssl Certificates. Many vendors do not provide the option to set up client authentication with SSL certificates, which poses a significant security risk. Customers should ask vendors for details on how to configure these certificates.
-
When implementing ssl certificates it is important to identify a certificate rotation policy and make sure clients do not reuse certificates
-
Please view the “How Corsha Protects OPC-UA” section of this blog post to understand how Corsha mitigates Improper management of ssl Certificates
-
-
Encryption. Related to support of ssl certificates, many vendors do not allow encryption, for example, opting to allow only HTTP instead of HTTPS for communication with their equipment. Customers should ask vendors what encryption options (including algorithms) are available with their provided OPC-UA server.
-
XML Configuration. To consistently configure the security settings of an OPC-UA server, make sure to ask if the server can be configured via XML. Customers should ask vendors if security settings such as Security Configuration, Security Policies, and User Token Policies can be rapidly configured via an XML file.
-
An example of this configuration can be found in Github here
-
Graphical Design tools can be used to easily create an XML configuration file such as UAModeler and Prosys OPC UA Modeling Tool
-
System updates and monitoring is also an important aspect of implementing proper cybersecurity practices within an OPC-UA connected network. For those implementing OPC-UA based solutions it is important to consider the following aspects:
-
Plan for Patch Management. Regularly updating and applying patches to your OPC UA server software is essential to protect against newly discovered vulnerabilities. The plan should take into account how often upgrade maintenance will occur and when the best maintenance windows will take place. If systems using OPC-UA servers are running 24/7, maintenance for upgrades should still be accounted for.
-
Enable Logging and Monitoring. Implementing comprehensive logging and real-time monitoring helps detect unusual activity and provides valuable insights for addressing potential threats. It is easy to define the data that will be sent to a consumer, but customers should define the following to help configure the OPC-UA data flow for monitoring purposes
-
What systems and associated data need to be monitored?
-
Where will the data be stored and for how long?
-
What data and data anomalies should trigger cybersecurity incident response playbooks?
-
Interested in learning more?
OPC-UA is a powerful and versatile communication protocol that is widely used in industrial automation for secure and reliable data exchange. In this blog post we covered the structure of the protocol, what to be aware of when procuring a system that supports OPC-UA, and common cybersecurity pitfalls of OPC-UA.
There is still so much to learn! The following resources are recommended to deepen your understanding of OPC-UA, and empower you to effectively implement and secure this protocol in your industrial systems:
-
The official documentation from the OPC Foundation, which provides comprehensive information on OPC-UA technologies, standards, and use cases.
-
The OPC UA Server Simulator by Integration Objects, which offers a simulation environment to test and validate OPC-UA clients.
-
The open62541 Docker image, which allows users to quickly deploy an OPC-UA server using the open-source open62541 library.
-
The umati Sample Server, an open-source example implementation that showcases how to use OPC-UA in machine tool applications.
How Corsha Protects OPC-UA
The cybersecurity pitfalls outlined in this post can lead to breaches particularly where credentials are compromised or in situations where credentials aren’t even required to gain access in the first place. So how does Corsha mitigate these issues and retain the interoperable capabilities of OPC-UA?
The approach is to integrate the Corsha Platform with the OPC-UA protocol directly. Corsha wraps the original OPC-UA message with Corsha specific headers and includes an additional factor of Authentication, called the CorshaCred, as shown in the message format table below.
Name | Description |
MessageType | Custom Corsha Message |
Reserved | Reserved (ignored) |
MessageSize | The length of the Message |
CorshaCred | One-time use credential |
OriginalMessage | Unmodified OPC-UA message |
The CorshaCred is a one-time use credential that is checked prior to allowing a message to reach its target server. If a CorshaCred is checked successfully the Corsha specific headers are stripped and the original OPC-UA message is allowed through, not impacting the configuration of the receiving server.
For more information on CorshaCreds, how they are checked, or the Corsha Platform please visit docs.corsha.com.
About Eric Kumar
Eric Kumar is the Head of Customer Success at Corsha Inc., with over ten years of managing high-performing customer-focused teams in the security and startup industries. Eric is a technical professional with deep experience in each phase of the customer lifecycle, improving cross-functional and bottom-line performance, and is recognized for enabling customers meet their goals with complex solutions and delivering a vision for stakeholders.
About Corsha
Corsha is an Identity Provider for Machines that allows an enterprise to securely connect, move data, and automate with confidence from anywhere to anywhere. Corsha builds dynamic identities for trusted machines and brings innovation like automated, one-time-use MFA credentials to APIs. This ensures automated communication across clouds, data centers, or shop floors is pinned to only trusted machines and helps an organization move past outdated, costly secrets management and reimagine identity and access for machines.