Digital Bond comments on OPC Foundation and UA security


SCADA security specialist Digital Bond has recently conducted a security assessment of the OPC UA Specification and OPC Foundation's UA SDK. The results of this audit are currently being summarised in a series of posts to the Digital Bond blog.

Part 3, on specification vulnerabilities, and Part 4, SDK vulnerabilities, have inevitably led to a string of comments, notably from Eric Murphy, on OPC Foundation's TAC blog, and also at

It seems clear that OPC UA will, by the time of its release, be one of the most secure automation standards. This is in no small part thanks to Digital Bond's input. At issue is whether OPC Foundation could/should have done more to build security into UA early on, avoiding the additional delays that are now inevitable.

Digital Bond's Dale Peterson offered us his viewpoint on OPC Foundation's attitude to security in UA, both past and present, and sheds more light on Digital Bond's role in the process. His comments are reproduced here in full.

"On the plus side, the OPC Foundation has always been open to review by security professionals. They have a very refreshing attitude: they want to know about and fix any security vulnerabilities. This is very rare.

"There has been, in my opinion, a longstanding problem that there was not enough security expertise on the OPC UA team: people who are security engineers and who have created and analyzed security protocols. Digital Bond (Matt Franz and I) looked at the specs early on and found some really serious mistakes, such as only digitally signing the header - with a very minor amount of time invested. To their credit, the OPC Foundation addressed these findings, but we raised the concern that a team of security professionals needed to be involved in detail. We did not want our cursory review and comments to be considered 'the security vetting' and pulled back from being involved. Not because it wasn't important, but simply because we have limits on our pro bono time.

"The OPC Foundation is not unique in this problem. There are so many efforts, and a limited number of people with the security and control system skills that get the support from their organizations to contribute to a standards or specification effort. ISA, PCSF, API, AWWA, as well as the protocol organizations all suffer from this. The sincere effort to add security to the protocol, and willingness to accept and act on criticism actually reflects well on the OPC Foundation.

"When the standards and SDK were in a near complete stage - not a moving target - we decided to invest the time to do assessment of the specification, source code and binaries. It is really important to highlight that just is an assessment of the SDK and not a vendor's application. We expect significant differences in the security of OPC UA applications, and we will cover some of the issues beyond code quality in Part 5."