Introduction of the OPC protocol
The OPC protocol grew out of the idea of creating a standard, common interface for communicating industrial control systems. The control systems market had originally been dominated by proprietary communication protocols, each tied to a particular hardware platform (a PLC) from a particular manufacturer. These proprietary protocols were complex and differed from each other, which required a specific development to connect each PLC with the management systems of: manufacturing MES, process PIMS, ERP/SAP company.
Evidently all these protocols were not compatible with each other and there was no common language that all control systems could "speak" to communicate easily.
To meet this need for generic communication, the OPC protocol was born.
The OPC protocol is based on a technological pillar, which is Microsoft's COM and DCOM technology. This technology makes it possible to communicate the different equipment that make up an industrial process network, but adding a layer of abstraction to the information.
The OPC protocol uses the classic client-server architecture to manage communications. The OPC server has the task of encapsulating the information and publishing it (making it available and accessible to other equipment) using its data interface. The OPC client has the ability to connect to the OPC server and access the published information.
In classic OPC, these data and communication interfaces are based on Microsoft COM and DCOM technology.
In OPC UA (the latest update of the standard), two protocols are used for communications:
- An OPC-TCP protocol, which is a high-performance low-level (binary) protocol.
- An HTTP protocol based on web services.
Evolution of the OPC protocol
The first version of the OPC dates back to 1995, so we should be aware that this protocol is almost 30 years old. In these 30 years, industrial environments have changed and so have the needs that drive them.
The original version of the OPC protocol was designed to meet the communication needs of the industry at that time. This implied the need to cover three data niches: live data, alarms and events, and historical data. For each of these niches a different specification was created:
- OPC DA (Data Access): allows access to live process data.
- OPC A&E (Alarm and Events): used to capture alarm and event information generated in any production process. Alarms for high temperature, low flow, high pressure and production events (batch started, phase X started, batch Y manufactured).
- OPC HDA (Historical Data Access): this specification allowed the server to periodically capture live data at certain intervals, creating a "live data history" that would be stored and later consulted by the OPC client.
Of the three specifications, the OPC DA interface is the most widely used and the most widely implemented in industrial devices using this protocol. It is actually the simplest protocol of the three. The OPC A&E and OPC HDA interfaces are less relevant and are used as a complement to OPC DA, especially A&E which is used to integrate alarms from multiple systems, when the control system begins to have a certain size and it is important to have an overview.
Then came OPC XML DA, which was a failed attempt to create a platform-independent OPC specification. This specification tried to replace Microsoft's proprietary COM and DCOM technology with HTTP/SOA and other web technologies, but trying to keep the functionality of OPC-DA. Its main problem was its low performance and high resource consumption on the server.
Los problemas del OPC Clásico
Microsoft's COM and DCOM technology has a problem in the complexity of its configuration. For this, a Windows tool called DCOMCNFG is used, which allows configuring each DA service (the OPC DA is really just another object within the DCOM) and configuring the startup and activation levels, access permissions and configuration. Most OPC protocol integration manuals leave this protocol completely unprotected, giving all users full access (administration access). It does not matter which manufacturer's OPC protocol manual it is from.
The correct and secure configuration of the OPC DA is a complex and not at all trivial issue, adding the problem that it is not really an encrypted communication.
Another problem is the massive use of TCP ports (see Note 1), which must be opened in firewalls when this protocol is used between the OT industrial network and the IT company management network.
When these port openings are requested from cybersecurity personnel, it is always the same question, "Is it really necessary to open all these ports?"
Note 1: To make an Ethernet communication, apart from knowing the IP addresses of both devices, the port must also be known. The port is identified by a number between 1 and 65535. This number is the identifier of the communication channel. Based on this between two machines, we can have 65535 communication "pipes" that we can open to exchange information simultaneously.
The solution: OPC UA
OPC UA was developed to solve these problems.
You need a tool that is "independent" of the hardware platform (and the underlying operating system), but must maintain: classic OPC performance and features.
The emergence of OPC UA is a game changer for OPC communications.
Total decoupling of COM and DCOM technologies from Windows, ceasing to be a mandatory requirement and providing platform independence.
This implies a change in the meaning of the acronym OPC, from OLE for Process Control to Open Platform Communication.
In order to achieve an independent infrastructure, while maintaining all functionality, the transport mechanisms and data model are defined.
Regarding transport, two mechanisms are defined, as mentioned above, a high-performance binary OPC-TCP protocol for intranet communications and access to accepted Internet standards such as HTTP via web services.
Regarding the data model, the rules and blocks necessary for accessing the address space are defined. This is the famous Classic OPC tree structure, where the tags or items that are the identifiers of the live values to be read hang.services in OPC UA are defined in an abstract way and the transport mechanisms are used to exchange data between client and server. Thanks to this abstraction, a client can access the data without understanding the underlying data model.
OPC UA vs. classic OPC security measures
Several security measures are implemented in the OPC standard to ensure confidentiality, integrity and availability.
To achieve this, the following objectives are set:
- Application authentication
This mechanism allows OPC UA applications to identify each other. They have a digital certificate that they share in the connection phase.
On the other hand, in classic OPC, not all OPC clients and servers support this type of authentication. This authentication requires a configuration of the DCOM objects (Dcomcnfg tool). It is hard work and requires advanced knowledge to be implemented correctly (which is not usual), as it requires configuring all the DCOM elements.
OPC UA makes it easier to implement application authentication compared to the classic version.
- User authentication
In OPC UA user authentication is mandatory.
There are several authentication mechanisms supported, compared to the classic version, where authentication is not enabled by default, being costly and complex to implement.
Three mechanisms are supported: Username and password, Digital certificate and Kerberos ticket.
All applications using OPC UA must support at least username and password. It is the easiest to implement, but must be configured in each application.
User identification is application specific.
OPC UA user identification works similarly between machines within: a workgroup, a domain, between different domains, or even when the operating systems are different.
In classic OPC, access is not restricted by default.
In a domain environment, the domain identifies all classic OPC servers and assigns them appropriate access rights to the user groups (roles) of the clients that will connect. Since all accounts in a domain are managed from a domain controller, it is simple to enable user authentication.
In a non-domain environment, it can be configured, but requires additional work to identify the users, which are common accounts on all machines, common user group.
- User authorization
In OPC UA, when the user is identified and authenticated, the application is in charge of restricting access rights for browsing and read/write, etc.
The same is true in classic OPC, applications provide individual access restrictions for a given element against read or write DCOM access.
But in practice, this is actually included in very few.
- Server availability
Server availability is not inherent to the protocol. It is recommended that OPC servers implement backup and redundancy servers.
- System auditability
OPC UA also contemplates the ability to be audited.
OPC UA defines the mechanisms for a server to store log files of all relevant events.
- Confidentiality and integrity
Data confidentiality and integrity is implemented at the OPC UA transport layer by encrypting communications.
If web services are used, the WS Secure Conversation protocol is used.
If the binary TCP version is used, an adaptation of WS Secure Conversation is used. There is also a mixed version in which TLS is used.
In classic OPC, DCOM can be configured to sign data and encryption, but it is not a default option.
Therefore, the main advantage of OPC UA is that encryption is enabled by default.
Conclusions
At this point it is quite evident the numerous weaknesses of classic OPC, both in terms of cybersecurity and configuration complexity. This is the reason why the organization that manages the protocol, OPC Foundation, has redefined the new OPC UA standard, correcting and implementing new mandatory security mechanisms, which were unthinkable almost 30 years ago when the first classic OPC standard was defined.
The advice is simple, the more exposed an OPC communication is the more advisable the migration to the new OPC UA.