Abstract : OPC (OLE for Process Control) is an industry standard, the culmination of collaboration between many world-leading automation software and hardware companies and Microsoft. It consists of a series of standard interfaces, attributes, and methods for process control and manufacturing automation applications. For companies using the OPC protocol in their production environments, selecting suitable security protection products based on their own capabilities is becoming increasingly important. However, parsing the OPC protocol down to the instruction level is insufficient; further in-depth analysis is needed to determine whether the objects operated by the OPC protocol operation instructions are within safe limits.
Keywords : Automatic control network; OPC protocol; Security
Intermediate Classification Number: TP9 Document Identification Code: B
Foreword
OPC stands for OLE for Process Control, and its emergence has built a bridge between Windows-based applications and field process control applications. In the past, to access data from field devices, each application software developer needed to write dedicated interface functions. Due to the wide variety of field devices and continuous product upgrades, this often placed a huge workload on users and software developers. This usually couldn't meet actual needs, and system integrators and developers urgently required a plug-and-play device driver that was efficient, reliable, open, and interoperable. In this context, the OPC standard was born. The OPC standard is based on Microsoft's OLE technology, and its development was accomplished by providing a standard OLE/COM interface. OPC technology uses OLE2 technology, and the OLE standard allows multiple microcomputers to exchange documents, graphics, and other objects.
Several automation hardware and software vendors collaborating with Microsoft have jointly developed an OLE/COM interface protocol called the OPC specification to improve interoperability between automation/control applications, field systems/devices, and office applications in the process control industry. OPC can be considered the fieldbus for industrial monitoring software. Its basic idea is that each hardware vendor develops a universal data interface (OPCServer) for its devices, allowing other systems to read and write information. Client application software can also read and write hardware device information through the OPC specification interface (acting as an OPCClient). Since hardware vendors typically package hardware drivers into OPCServers and sell them separately, upper-layer applications acting as OPC data clients do not need to include any communication interface programs or concern themselves with the specific details of the underlying hardware. They only need to adhere to the OPC data interface protocol to obtain data from OPC data servers provided by different hardware vendors.
Currently, there are two main types of OPC protocols: one is "Classic," based on Microsoft COM/DCOM technology, and the other is OPCUA, based on Web services. The former, built on top of the DCOM protocol, was developed earlier and is widely used in various industrial control systems, becoming the de facto standard in industrial automation. The latter, developed later, incorporates security considerations and encryption mechanisms in its design, but its current application is smaller. This article primarily discusses the protection of the former in industrial control systems.
Microsoft's DCOM protocol was designed before network security issues were widely recognized. OPC Classic, based on the DCOM protocol, did not add any security-related features. Almost all well-known industrial automation software (including HMI software, advanced control and optimization software, monitoring platform software, and integrated software) are developed based on the Windows platform and use or partially use OPC technology. Therefore, protecting industrial control systems that use the OPC protocol for communication has become complex and difficult.
1. Server dynamic port
OPC servers are developed for hardware from various vendors, eliminating the differences in hardware and systems between vendors and thus enabling hardware-independent system architectures. Simultaneously, by utilizing a data type called Variant, it can provide data formats according to the application's requirements, independent of the data types inherent in the hardware.
OPC can be called a "software bus." Applications only know how to read OPC data sources, making it easier, more versatile, and simpler. The device driver (OPCServer) only knows how to convert field data into OPC-formatted data.
High-speed data transmission performance.
A security management mechanism based on distributed COM. Reduced development costs. Clearly defined system boundaries, reducing fault diagnosis and maintenance costs. Unlike most application layer protocols, the underlying protocol of OPC, DCOM, uses a dynamic port mechanism; the communicating parties need to negotiate the required port before actually establishing a data connection.
The OPC client first initiates a connection to port 135 of the OPC server using port 5568 as the source port. After the connection is successful, the OPC server allocates a new port 1118 and returns a response message to the client through the RemoteCreateInstance method of the ISystemActivator interface. Then, the client initiates a new connection to port 1118 of the server using port 5569 as the source port for the subsequent actual data transmission.
Security threats faced
Industrial control network systems based on the OPC protocol face a variety of threats. In the context of the convergence of enterprise management networks and the internet, the isolation of industrial control systems is broken, leading to an unprecedented increase in network threats. The opening of unused ports, security vulnerabilities in the operating systems upon which industrial software relies, and the inherent insecurity of industrial protocols all pose significant security risks to industrial control networks. Before truly connecting to enterprise management networks and the internet, OPC-based industrial control systems must incorporate appropriate security devices to improve their network security. Because the OPC protocol differs from traditional IT application layer protocols, the depth of OPC protocol parsing determines the true effectiveness of security products in protecting industrial control systems.
2. Comparison of security protection schemes
2.1 Traditional IT System Firewalls
If a traditional IT system firewall (hereinafter referred to as "traditional firewall") is installed for protection in an industrial control system based on the OPC protocol, since the traditional firewall does not support any parsing of the OPC protocol, in order to ensure the normal use of OPC services, it is necessary to open all open ports of the OPC server. The range of port numbers that can be assigned to the OPC server is very wide - if the OPC server is installed on Windows Server 2008, more than 16,000 port numbers may be used, and earlier versions of Windows have more than 48,000 port numbers.
Traditional firewall deployment diagram
In the diagram above, a traditional firewall is installed at the boundary between the enterprise management network and the production control network for protection. Since the OPC server may use any available port for actual data connections, and the specific port number is found in the response message to client requests, the traditional firewall cannot identify the specific port number used by the OPC server. To ensure that OPC clients can connect to the OPC server normally, the firewall needs to be configured to allow access to all ports. Such a traditional firewall is essentially useless, leaving the production control network wide open and almost completely exposed to attackers.
2.2 Port Protection Industrial Firewall
Unlike traditional firewalls, industrial-grade firewalls, which have been developed in recent years specifically for protecting industrial control sites, generally support deep parsing of OPC. However, depending on the parsing depth, the protection capabilities of industrial firewalls in OPC-based networks also vary.
Industrial firewalls that perform simple OPC parsing can track the dynamic ports used to establish OPC connections, minimizing the number of open ports on the industrial control network. See the diagram below:
Port protection level industrial firewall deployment diagram
Port-protected industrial firewalls are also deployed at the boundary between the enterprise's production network and production control network. In this case, the configuration policy only needs to open port 135 of the OPC server. When the OPC client establishes a connection with the server, the port-protected firewall tracks and resolves the dynamic port negotiated between the OPC server and the OPC client, and then automatically adds the dynamic port to the firewall's open ports, thereby minimizing the number of open ports on the production control network. Compared with traditional firewalls, the protection capability is further improved.
2.3 Command Protection Industrial Firewall
While port-protected industrial firewalls offer enhanced protection compared to traditional firewalls, attackers can still send malicious OPC commands through established data channels. Therefore, dynamic port tracking alone is insufficient to guarantee the security of OPC-based industrial control systems. Further analysis of the OPC protocol has led to the development of command-level protection industrial firewalls, which are currently the mainstream industrial firewalls on the market. The requirement for deep OPC protocol analysis has also been included in the draft of the national standard for industrial firewalls (this standard has not yet been officially released). Command-level industrial firewalls deployed at the boundary between the enterprise management network and the production control network analyze the OPC protocol down to the command level. They can not only track the dynamic ports negotiated between the OPC server and OPC client, minimizing open ports on the production control network, but also perform real-time detection of command requests transmitted between the OPC client and OPC server. They can intercept and issue alarms for operation commands that do not meet security requirements, significantly improving the network security of OPC-based industrial control systems.
In addition to command protection, industrial firewalls also offer more user-friendly features, such as built-in read-only templates. These templates cater to most business scenarios using the OPC protocol, as industrial control systems typically only collect data using OPC, and read-only templates fully meet on-site security requirements. The built-in read-only templates in industrial firewalls can be deployed with a single click, offering security and convenience, reducing administrator maintenance costs, and effectively protecting industrial control system data from malicious tampering.
3 Comparison of OPC data acquisition schemes
OPC servers typically support two types of access interfaces, providing access mechanisms for different programming language environments. These two interfaces are: Automation interface and Custom interface. The Automation interface is usually a standard interface defined for scripting programming languages, allowing the development of OPC server client applications using languages such as Visual Basic, Delphi, and PowerBuilder. The Custom interface, on the other hand, is a standard interface specifically designed for high-level programming languages such as C++. Currently, OPC data acquisition solutions are mainly divided into two categories: driver-based methods and Dynamic Data Exchange (DDE).
3.1 Driver Method
The driver method is a method of data acquisition that involves writing custom one-to-one drivers and interface programs for different devices.
1. Although custom drivers and interface programs can be written, the variety of programs is rapidly increasing because many different types of control devices and software packages need to communicate. Issues include inconsistencies between drivers from different device vendors, limited hardware performance support, drivers that cannot adapt to upgraded hardware, and access conflicts (two applications cannot access the same device simultaneously because they use independent drivers).
2. For technical personnel developing monitoring software, 20-30% of their time is spent writing communication drivers. Application software providers spend too much money developing and maintaining proprietary interfaces, which not only increases the burden on users but also fails to solve the interoperability problem between different systems in practice. In a sense, users are controlled by their software providers.
3.2 Dynamic Data Exchange (DDE)
DDE, or Dynamic Data Exchange, is the predecessor to OLE technology. It's a method for dynamically moving data between applications developed using Microsoft's Win32 Application Programming Interface (API). The DDE protocol transmits information between applications, enabling them to share data and exchange data using shared memory.
Disadvantages of Dynamic Data Exchange (DDE)
Hardware manufacturers, while recognizing the need to develop software programs to connect their hardware, are limited by their ability to develop communication drivers, thus confining their program development options to either DDE or a dedicated DDE export table. Choosing either DDE for program development risks either limiting user software choices or hindering user acceptance of the hardware. Furthermore, because DDE is based on Windows message passing, it suffers from the following problems: (1) slow data transmission speed; (2) lack of secure management mechanisms; (3) high development difficulty; (4) lack of functional flexibility; and (5) unsatisfactory reliability.
4. Conclusion
Today's industrial data communication is primarily organized according to the automation system pyramid: at the top, the computer layer, standard IT protocols (Internet Protocol) are used. For machine-to-machine and process communication (distributed controller layer), OPCUA (IEC 625412) is rapidly gaining importance compared to traditional Ethernet-based M2M fieldbus systems (e.g., PROFINET, EtherNet/IP, EtherCAT, Modbus/TCP, CC-LinkIE, POWERLINK, SERCOSIII). For companies with OPC protocols in their production environments, selecting suitable security protection products based on their own capabilities is becoming increasingly crucial. However, parsing the OPC protocol down to the instruction level is insufficient; further in-depth analysis is needed to ensure that the objects operated on by the OPC protocol commands are within safe limits, and to perform security checks on the values of the operated objects to ensure that every byte sent by the OPC protocol is identifiable, controllable, and harmless.
