Security assessments by their nature focus on negative findings that could lead to vulnerabilities, and the preponderance of our report focused on what Digital Bond viewed as security deficiencies in the OPC UA specification and SDK code. That said, there are numerous examples of positive findings and text in the report. In fact, there is no comparison between the security in OPC UA and the security of any other control system protocol, with the possible exception of Secure DNP3 and its IEC equivalent. The OPC Foundation should be commended for their security efforts and pressure should be applied to other protocols to step up.

[Note: The security details of OPC UA are being written on a SCADApedia page as the OPC UA blog series is being published]

The major positive security findings are:

• The OPC UA specification supports options for the use of encryption for confidentiality and signatures for source authentication and integrity. Asset owners using OPC UA will be able to secure client / server communication using the protocol itself rather than add-on security.
• OPC UA uses a profile approach for specifying functionality including the crypto algorithms and key lengths. This provides flexibility and extensibility. For example, a country or industry sector may develop a new algorithm or select a set of algorithms and parameter settings. These could be listed as a new profile without changing the OPC UA specification. Additionally, the current profiles have leveraged existing, vetted crypto primitives and algorithms rather than try to tackle the difficult process of developing a new security algorithm. Smart choice. [Slight negative - we would have liked to see elliptic curve cryptography because of its computational and message overhead efficiency, but it was not included in the additional profiles due to patent and licensing issues].
• The overall code quality of the OPC UA SDK was very good. The code base is surprisingly clean of vulnerabilities for a code base of its size. In fact, it is among the cleanest code Digital Bond has seen in the control system space. The code is well written, easy to follow and contains good use of comments. Many common coding errors were not found. For example, there were no off-by-one buffer overflows found, very limited use of insecure function calls, and good boundary checking of buffers both on the stack and on the heap. There are a number of well-written OPC wrappers of common C functionality. Comments in the code remind developers to use safe functions.
• The security event logging required by the specification will be a fantastic help to attack detection and after incident analysis. It is the best the Digital Bond team has seen in this space by far.

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