OPC UA: Part 5 – Vendor Implementation Security Considerations
During our application assessment of the OPC UA SDK, it was very clear that vendors creating OPC UA clients and servers are going to make a number of choices that affect security of their offerings. All OPC UA servers will not be created equal from a security perspective.
When the fixes from our assessment are completed, which hopefully will remove some of the possibilities for a vendor to do something insecure, we plan on issuing a Security Considerations For the Purchase of an OPC UA Server document. In the meantime here are some of the interesting areas:
- Certificate Handling: This is a huge area as mentioned in previous parts of this blog series. How are self-signed certificates going to be marked as trusted or replaced with signed certificates? Verify, preferably through testing, that self-signed certificates will not be accepted or used until specifically trusted. How can a CA certificate be trusted and then used to automatically trust any certificates signed by that CA? How are trusted certificates removed or marked as untrusted? Does this close any open Secure Channels that relied on the now untrusted certificate?
- Message Processing: The specification recommends, but does not require, “strict message processing”. The recommendation is messages that are not in the required format be dropped and an appropriate error logged. This would significantly lessen the effectiveness of fuzzing to identify and exploit coding errors. An OPC UA server should return a Bad_DecodingError or Bad_EncodingLimitsExceeded ServiceFault if message processing fails. A reasonable test is to fuzz the OPC UA protocol and verify one or the other of these Service Faults is returned.
- Authorization: Authorization is left completely up to the vendor implementation. How are roles supported? How granular is the authorization? This will be a huge area to consider for some implementations.
- Key Storage: OPC Security relies on the secure key storage of a client or servers asymmetric private key. If this key is known an attacker could recover all of the other keys. Part 4 of the specification says, “Each application instance certificate has a private key which should be stored in a location that can only be accessed by the application”. However it does not levy any specific requirements or testing of this general requirement. Potential purchasers should learn how the private key is stored and determine if there are possible or likely circumstances in which an attacker would be able to gain access to this private key.
- Secure Channel / Session Compromise: Part 4, Section 5.3 levies requirements that a Secure Channel or Session be immediately terminated if “through some out-of-band mechanism” that security credentials have been compromised. However there are no specifications or recommendations of out-of-band mechanisms or requirements on how the termination should take place.
- Denial of Service Protection: There are a number of considerations in this category. For example, the OPC UA specification requires the server vendor to identify the maximum number of Secure Channels it will support, but it does not require the server to stop establishing Secure Channels as the threshold is neared or reached. Vendors should program these limits into the server application. It may prevent new Secure Channels, which would likely have a very minor short-term impact since Secure Channels are long lasting, but it would prevent a complete loss of availability. The server application should also set a high priority alarm as the threshold is neared and met.
- Random Number Generation: Random numbers are used to create the security parameters used in the Secure Channel and Session establishment. A weak random number generator could compromise all the other security algorithms used in OPC UA. The specification recommends a number of random number generators, but does not have any specific requirements on the random number generator algorithm or process.
Beyond these items, there is the issue of secure coding practices – - or lack thereof. These tend to be ignored when people are purchasing a “standard protocol”. The folly of believing all OPC implementations are created equal was seen in Langner’s denial of service testing paper from S4, Mora’s 24 test cases for overflows and other problems, and Lewis’s DCOM endpoint checking. And this was on the old OPC that had been out for years. It is reasonable to ask vendors about their security development lifecycle, see copies of their design documents, QA tests and results, and any security analysis performed. I’m not going to throw stones at specific vendors in this blog entry, but Digital Bond definitely has OPC vendors we recommend to be avoided and those we recommend from a security perspective. We expect this will be true for OPC UA implementations, maybe even more so.
See the rest of the OPC UA blog series:
- Part 1: Intro
- Part 2: Positive Findings
- Part 3: Specification Vulnerabilities
- Part 4: OPC UA SDK Vulnerabilities
- Part 5: OPC UA Vendor Implementation Security Considerations
- Part 6: Asset Owner Tip Sheet to Analyzing The Security of Competitive OPC UA Servers
- Part 7: Specification and SDK Improvements
Author: Dale Peterson
Posted: November 12th, 2008 under OPC.
Comments: 7
Comments
Comment from Ralph Langner
Time: November 12, 2008, 3:34 pm
Great analysis, Dale.
Comment from Stefan H. Leitner
Time: November 14, 2008, 5:54 am
These are surely important areas to think about. However most of these considerations are questions that have to be answered for any kind of application using certificates and asymmetric keys and is not really specific to OPC UA.
Comment from Dale Peterson
Time: November 14, 2008, 8:14 am
Stefan – I agree with your comment that many of the issues are related to the use of certificates rather than a unique feature of OPC UA.
That said, my concern is few in the control system community have experience with a PKI. My expectation is we will see many OPC UA servers that will be compliant with the standard and insecure out of the box because vendors will not want to burden customers with the PKI work. Even worse, asset owners will have heard for years that OPC UA is secure and have a false sense of security.
It will fall on asset owners to evaluate and compare the security implementation, like they do other critical features, rather than rely on a server being secure because it is compliant with the standard.
Comment from Ralph Langner
Time: November 14, 2008, 11:44 am
As we are talking about metrics around the corner…
One metric worth considering is the time that average staff needs to implement the target level of security. How many hours/days/weeks/months will it take for the average electrical engineer to set up a reasonably secure UA installation?
(I like this metric. Easy to collect, good unit of measure, meaningful, …)
We’re doing cyber security seminars now for years, but I have yet to meet an attendee who would have come with a good understanding of certificates… So I must underline Dale’s argument. Security products or procedures that cannot be mastered by their target users or require much more time and knowledge than what is available are of little help.
Comment from Dale Peterson
Time: November 14, 2008, 12:15 pm
Ralph,
I believe, and at this point it can just be a belief because these products don’t exist yet and the certificate trust requirements may change in the next standard rev, that:
- it is possible for an OPC UA vendor to implement a secure PKI for OPC UA that does not require an asset owner to understand anything about PKI if they are willing to go through a minor process and manually approve new certificates.
- there will be significant variance in the PKI process implementation by vendors in terms of flexibility and ease of use. Potential purchasers will need to evaluate the PKI process and see if it will realistically work with their environment and staff. Open question is whether they will be able to evaluate the security of the vendor proposed process.
- many vendors will attempt to avoid the whole issue by making it as easy as possible to use out of the box even at the cost of security. In some cases because the vendor development team does not understand security and PKI.
After that vendor bashing, let me say something nice about vendors. They are businesses. They respond to customer demand. I have heard and blogged on horror stories where vendors have added security that required very minor action by the customers and this led to a revolt. As a product business I have to respond to market demand, and if the market demand is damn the security if it makes my life an iota more complicated it is wrong to place all blame on the vendor.
My hope is some of the leading vendors will have a secure and easy to deploy and maintain OPC UA server, and these vendors will be rewarded with market share. What I keep harping on is the expectation that the vendor variance is likely to be large in security and ease of use of this “standard”. All OPC UA servers will not be created equal from a security standpoint.
Comment from Ralph Langner
Time: November 14, 2008, 2:52 pm
Well… I don’t have any qualms about vendors who completely ignore security AND SAY SO. Let’s not forget that there continue to be enough places for installations without any security features, thank God. My concern is what you have raised before: “Even worse, asset owners will have heard for years that OPC UA is secure and have a false sense of security.”
One could say that in some areas, security by obscurity is being replaced. We’re starting to see the illusion of security, by reference to what actually COULD be secure if done right. Here’s an example. When installing a leading SCADA product, the admin is prompted to accept some default security settings. All those settings are listed in detail. If you choose the print option of this dialog, you get 8 (eight) pages. If you understand what you then hold in your hands, you learn that the box is completely opened. However, this is just if you understand the details. If not, you’ll probably feel very secure. Not good.
Comment from software development uk
Time: August 14, 2009, 10:30 am
Hey, that was interesting,
As we are talking about metrics around the corner…
One metric worth considering is the time that average staff needs to implement the target level of security. How many hours/days/weeks/months will it take for the average electrical engineer to set up a reasonably secure UA installation?
(I like this metric. Easy to collect, good unit of measure, meaningful, …)
We’re doing cyber security seminars now for years, but I have yet to meet an attendee who would have come with a good understanding of certificates… So I must underline Dale’s argument. Security products or procedures that cannot be mastered by their target users or require much more time and knowledge than what is available are of little help.
Thanks for writing, most people don’t bother.
Write a comment