People want a certain and definite solution to a problem, including security. Take these seven steps and you will be secure. Run this tool and you will find all vulns. Buy a product with this certification and you will not be compromised. Unfortunately security doesn’t work that way and even solutions that reduce risk must be analyzed in more than a binary manner.
Two recent examples of false expectations of perfection popped up around our blog. Jose recently commented on the VxWorks vulnerability and Achilles Certification of VxWorks.
Dale, I think the problem here is that VxWorks just got his Achilles certification and is being marketed as a very secure operating system to the control community. However, I did not heard anything from Wurldtech about the vxworks vulnerabilities – no single word in their blog as well. Why the certification process did not spot it? I understand that there is no 100% secure thing and all tests will fall into a miss or another, but that was not the case: there were a “backdoor” listening and a simple scan should have found it. Don’t you think this selective silence abount the problem put the certification process in discredit? I will no more care if a vendor claims their products have the Achilles stamp…
Wurldtech’s Achilles certification primarily tests the robustness of the protocol stack. Will it crash when it is fuzzed? Many field devices have very fragile protocol stacks because they were not subjected to negative testing. It is not rare for field devices to crash not just when attacked but also when unexpected traffic is received. The Achilles certification process does not test for the vulns found by HD Moore. [FD: Wurldtech is a past Digital Bond client — but you will find on this blog both positive and negative commentary on their service offerings]
I will sympathize a bit with Jose in that Wurldtech has not discussed how vulnerabilities in certified products have and could occur. Marketing is inclined to talk about the positive aspects of a product or service and be a bit more reticent on what is not provided.
The second example occurred when Joe Weiss blogged on all the things that did not stop Stuxnet including a couple of our research results:
The DOE-funded Digital Bond effort to develop IDS rules and signatures were not effective as they did not address the Stuxnet worm. The DOE-funded Bandolier project did not address older versions of Windows which are prevalent with many ICS installations and are vectors for Stuxnet. The DOE-funded Integrated Security System didn’t find it and ironically the project lead was Siemens Corporate Research.
This is nonsensical, especially Bandolier. There is no Bandolier Security Audit File for the affected system or application, and an audit file will never stop an attack. It is like saying why didn’t checking the tire pressure on my car last week stop a radiator leak?
But let’s look at a better Bandolier example. Let’s say we did have a Bandolier Security Audit File for the Siemens’ WinCC application and system. Since the default password cannot be changed, we would not have an audit check that tested if the default password had been changed. Does this make Bandolier a failure because it can’t guarantee someone won’t use the default password? The answer depends on how vulnerable the optimal security configuration is for the application and system. If there is no way of significantly improving the security posture by hardening the security configuration parameters, then Bandolier is of little value. This is why Bandolier Security Audit Files are developed for the more modern SCADA and DCS components that can be hardened.
Security is not yes or no. There is no perfect standard, certification or technology that is going to eliminate your security problem.
Now Joe does have a point with the IDS signatures. There could have been a signature that identified use of the Siemens’ default password. Ralph Langner calls this an infinite-day attack because it will never go away, and i-day signatures would be a great addition to IDS. Our IDS signatures are a small subset of what is possible, less than 1%, and focus mostly on protocol usage such as Modbus TCP, DNP3, EtherNet/IP, and ICCP. It would be great if we had time and money to have a team writing signatures on a full time basis or see someone else to this. However IDS signatures are not going to identify new, unknown attacks. This is why DoE and DHS are funding anomaly based IDS approaches at places like SRI and the University of Illinois. Anomaly detection is a much harder problem though than signature based IDS.
To be continued . . .