OPC UA is a complex, interleaved 12-part specification. To understand OPC UA security one has to read multiple parts of the specification, but we have provided an overview in an OPC UA SCADApedia page that continues to be developed.

The specification analysis portion of our assessment report had many findings at the Exposure, Concern and Observation level. This is not unusual given the complexity of the specification, and the effort required to maintain consistency across many different parts of the specification. Also, we want to reiterate that the OPC Foundation is addressing many of these findings, and we will provide the resolution or mitigation when available in Part 7 of this series.

So here are the highlights:

The biggest issue we found in numerous parts of the OPC UA specification was the security features can provide a high level security, but an OPC UA user could easily have a false sense of security even with a compliant product with security measures turned on. Even worse, the default, out-of-box configuration could be compromised even in an OPC UA server that is billed by a vendor as secure because it is encrypted and signed.

X.509 Certificate Infrastructure
The specification requires OPC UA client and server applications create self-signed certificates at application installation. Any entity or attacker can create a self-signed certificate. This is similar to verifying a person’s identity by asking the person if he is who he claims to be. No trust should be placed on a self-signed certificate without some sort of out-of-band process.

The specification allows OPC UA client and server applications to accept self-signed and other certificates without any automated or manual process to determine if a certificate should be trusted. It is likely that many vendors, and subsequently many users, will want to avoid the difficulties of deploying a public key infrastructure (PKI) or forcing a manual process to approve new certificates as they arrive at the OPC UA client or server.

The result is an OPC UA server, even one requiring encryption and signatures, could be compromised by anyone who is able to gain access to OPC UA client software. The attacker would just have an encrypted and authenticated Secure Channel to pass attacks through to the server. The OPC UA specification should be modified and be very clear that all certificates must be explicitly trusted through a PKI or other process prior to use. This is true for both the OPC UA client and server receiving an unknown application instance certificate.

The specification also is unclear and conflicting in places on the requirement to sign and encrypt security critical service messages, most importantly, OpenSecureChannel and CloseSecureChannel messages. It appears at one time the intention was to make security mandatory on these messages even when the Message Security Mode is set to NONE, which would provide a useful minimal level of security prior to any communication, but the specification has not accomplished this due to conflicting information in different specification parts.

If Secure Channels are allowed to be created and closed without security the OPC Foundation should modify the specifications to indicate there are Secure Channels and Channels. Again this is a false sense of security issue with someone thinking they are getting security from a Secure Channel even though sign and encrypt are set to none.

Other Issues

There were many areas in the specification that provided the vendor with implementation choices that would have a dramatic impact on the security of the OPC UA server. We will cover these in Part 5 of the series. These are not necessarily deficiencies in the specification, but a yellow flag for potential OPC UA users that all OPC UA security is not equal.

See the rest of the OPC UA blog series:

• Part 1: Intro
• Part 2: Positive Findings
• Part 3: Specification Vulnerabilities
• Part 4: SDK Vulnerabilities
• Part 5: OPC UA Vendor Implementation Vulnerabilities
• Part 6: Asset Owner Tip Sheet to Analyzing The Security of Competitive OPC UA Servers
• Part 7: Specification and SDK Improvements