Digital Bond has posted Part 3: Specification Vulnerabilities and Part 4: SDK Vulnerabilities of their OPC UA Security Audit. As expected the audit turned up many points, good, bad and ugly.
The Good: These were covered in a previous post, but two items to highlight are
1. The OPC UA SDK code is very clean, well written, easy to follow and contains good use of comments.
2. Mandating that an OPC UA server make use of certificates prior to creating secure channels is essential.
The Bad: I suppose one obvious bad point is that any vulnerability was found in the code and specification, but that was to be expected. The code issues will be corrected in the next revision and the OPC Foundation is addressing many of the specifications findings. The test that brought the OPC UA server down using the Test Application as a ‘fuzzer’ does raise concerns. This sort of security focused testing is exactly the reason the OPC Foundation had the audit performed in the first place. It highlights the need for more application testing as well as considering OPC applications when planning your Network Security system.
Another warning is an oldie but a goodie; “the same OPC protocol implementations, even interoperable, will have different quality of implementations from different vendors”. This is true from a security perspective and other aspects. It’s also true for any product built to meet a particular standard; OPC, Modbus, DNP, etc. Anyone who has worked with standards knows that there is a balance that needs to be struck between ensuring a common ground and providing the flexibility for innovation in products. The good news is that OPC UA has mandated a core set of security features that must be implemented, and outlines what the user is getting by way of different Profile levels. However this will not completely remove the need for users to evaluate who their OPC vendor will be. Does your OPC vendor provide security in their products? Are they active members in progressing the OPC UA standards and products? Do they maintain high compliance and interoperability testing standards? These sorts of questions should reflect on what the quality of the end products will be.
The Ugly: The main finding that is both good and bad, so ends up ugly is the use of certificates and public key infrastructure [PKI]. They are good because they are a proven way of ensuring that only authorized users are accessing the system. They are bad in that depending on how they’re implemented they could either; not provide sufficient protection or become a barrier to interoperability. Two of the goals of OPC UA are to provide seamless interoperability and a high level of security. To achieve both these goals the OPC UA specification makes use of self-signed certificates, and the option to set the Message Security Mode to NONE. Vendors must implement security, but users have the ability to essentially turn it off. If it is turned OFF, then this needs to be very apparent to users to avoid instilling a false sense of security.
As the audit revealed, the specifications are not clear enough or offers conflicting details on how to get this implemented properly. So the main action points for clarifying the specification are:
1. The OPC UA specification has to be clear on how certificates are explicitly trusted through a PKI or other process prior to use, for both the OPC UA client and server.
2. If Secure Channels are allowed to be created and closed without security the specifications to need to clearly indicate Secure vs Unsecure Channels.
This will most probably have an impact on Security Profiles as well.
Personally I wasn’t too surprised by the overall findings. We felt the code was good, but not perfect. The process of implementing a secure but interoperable framework, even leveraging existing security standards, is a tricky task. After looking at all the possibilities, considering the various requirements and putting the results onto paper (and into code) it is all too easy to ‘lose the forest for the trees’ so to speak. We knew that having someone with a strong security background and a fresh view audit the results would show the areas that might be confusing and conflicting. And they did.
As has been noted all these issues are being addressed. When that's done we can rename this post ‘OPC UA Security: Good and Pretty’ (or at least Pretty Good J )
As a closing note, I hope to see many of you out to the OPC UA DevCon and Workshop in Munich in October. It will be a great chance to meet with the specification developers and discuss OPC UA security and other topics. I encourage you readers out there to track me down at the conference, and we can have a chat on OPC over a good German beverage.
UPDATE: It seems that some of my thoughts on the OPC UA Security audit raised the question on why security experts were not involved in the early design of OPC UA. In fact many such experts have been actively involved since the start. My point was that the external audit was an extra step to ensure that nothing was missed when reviewed by fresh set of eyes from the outside. Below is a response from the Randy Armstrong on the matter:
"The OPC Foundation has actively sought advice from numerous security experts from the very beginning and the specification already includes many updates based on feedback from those experts. Dale’s recent review was the first review that included an analysis of the code and, for obvious reasons, could not start before the code base was reasonably stable. We received the results of this review a month ago and are in the process of updating the specifications and the codebase accordingly."