OPC-UA Deep Dive Series (Part 10): Security Tips for Asset Owners

Team82’s OPC UA Deep Dive Series was always meant to be a compilation of our research into this most important of operational technology protocols. OPC UA standardizes data and communication between dozens of proprietary industrial control systems and devices that otherwise could not share information. Modern automation runs on OPC UA. 

Therefore, it made sense to deeply examine the security of the protocol, starting with its origins and ultimately arriving at its security features and attack surface. The installments of this comprehensive guide that we’ve published since last April dissects these concepts and also includes practical and theoretical attacks against OPC UA, tools you can use to test the security of your implementations, and a community of vendors and practitioners who have collaborated with us to improve the safety and reliability of products built on top of the protocol. 

In this final entry of the series, we will briefly recap the results of our research and also share helpful tips for asset owners. We are confident that OPC UA implementations are much more secure and robust. Most of our research was focused on helping OPC UA developers and vendors improve their protocol stack implementations, but we would like to share some tips for asset owners as well.

Outcomes of Team82’s OPC UA Deep Dive Series

First, some outcomes:

• Pwn2Own ICS: We participated and demonstrated our OPC UA exploits at three Pwn2Own competitions: Pwn2Own ICS 2020, 2022, 2023

• CVEs: We found and reported on ~50 OPC-UA vulnerabilities/CVE across ~15 protocol stacks, which affect hundreds of OPC UA products.

• Exploit Techniques: We developed ~12 unique exploit techniques that are universal and affected multiple vendors and pushed to change the specs.

• Open-Source Tools: We have released open-source tools: our OPC UA network fuzzer and the OPC UA exploit framework.

• OPC UA Specifications: We helped to improve the specifications and pushed the vendors toward better and more secure products.

• OPC UA Slack: We’ve collaborated with major OPC-UA vendors and created a safe place, via a dedicated Slack workspace) to discuss security issues, architecture, and possible improvements for OPC-UA protocol stack implementations.

• Public Talks: We’ve presented this research at major security conferences including DEFCON and Black Hat

OPC UA Security Best Practices for Asset Owners

Now, a do’s and don’ts checklist of best practices you can use to assess the safety of your deployments. 

Always: Update Software  ✅

Regularly updating software is crucial for maintaining security because updates often include patches for known vulnerabilities. Software updates should not only cover the OPC UA server but also any underlying operating systems, libraries, and dependencies. Implementing a robust update process ensures that security patches are applied promptly to mitigate potential threats.

Always: Enable Auditing and Logging ✅

Enabling auditing allows for the tracking and monitoring of access and activities on the OPC UA server. Auditing helps in identifying security incidents, detecting anomalies, and providing accountability for actions performed within the system. By enabling auditing, organizations can enhance security posture and comply with regulatory requirements related to data protection and access control.

Always: Define Role-Based Access Controls ✅

Role-based access control (RBAC) is essential for managing and controlling user access to OPC UA resources based on their roles and permissions.

Organizations should define roles and associated permissions tailored to their specific security requirements and operational needs.

RBAC helps in enforcing the principle of least privilege, ensuring that users only have access to the resources necessary for their tasks, thereby reducing the risk of unauthorized access and potential misuse of privileges.

Never: Expose OPC UA to the Internet ❌

Exposing OPC UA servers directly to the internet increases the risk of unauthorized access and potential cyberattacks. It's recommended to deploy OPC UA servers within a secure network environment, preferably behind firewalls and other network security measures.

If remote access is required, consider using secure VPNs or implementing other secure access methods rather than exposing the servers directly to the internet.

Never: Allow Anonymous Authentication ❌

Allowing anonymous authentication poses significant security risks because it allows anyone to access the OPC UA server without providing credentials. Enforcing authentication ensures that only authorized users or devices can access the server, thereby preventing unauthorized access and potential data breaches.

Never: Allow Common Credentials ❌

Sharing or using common credentials across multiple users or systems increases the risk of credential theft and unauthorized access. Each user should have unique credentials, such as usernames and passwords, to access the OPC UA server. Implementing strong password policies and multi-factor authentication can further enhance security by adding layers of verification.

Never: Weak Security Mode (e.g. Invalid or None) ❌

OPC UA supports different security modes, including None, Sign, SignAndEncrypt.

Choosing None or an invalid security mode leaves  communication unprotected, making it vulnerable to eavesdropping, tampering, and other security threats. It's essential to select an appropriate security mode based on the security requirements of the system and the sensitivity of the data being transmitted.

Never: Bad Security Policy (e.g. None) ❌

OPC UA defines various security policies, such as Basic256, Basic256Sha256, etc., which specify encryption and signature algorithms. Selecting the None security policy means no encryption or signature is applied to the communication, leaving it vulnerable to attacks.

Organizations should choose security policies that provide adequate protection based on their security requirements and compliance standards.

Avoid: Self-Signed Certificates ❌

Using self-signed certificates for authentication and encryption. Doing so may introduce security risks, because they are not issued by a trusted Certificate Authority (CA). Self-signed certificates can be susceptible to spoofing attacks and may not provide the same level of trust and validation as certificates issued by trusted CAs. Whenever possible, organizations should run their own CAs because they need to control their trusted network of applications. OPCA UA certificates are generally not designed to be verified primarily by a global CA, for example.