Last week a security researcher, Dillon Beresford of NSS Labs, presented at the Blackhat conference on the security vulnerabilities he found in Siemens PLC firmware. One of many stories on Dillon’s findings can be found here. Among other things, Dillon found “dancing monkeys” in the code! Actually, what he found was this graphic of four dancing monkeys inserted in the firmware as an “Easter Egg” - meaning it was intentionally put there by a developer as a joke. Easter Eggs are cute in websites and video games but not in software that is operating critical infrastructure. This finding raises concerns about Siemens software quality assurance practices. While this prank is most likely harmless, imagine, for example, if the same thing was found in the code of the Airbus you flew last week?
In light of this story, I thought I’d post a link to an article I had published earlier this year in CONTROL magazine entitled, “Demanding Software Security Assurance”. The objective of the article was to communicate that the “science” behind writing software for safety and security critical applications has been around for decades but unfortunately it has not been integrated into the software development lifecycle (SDL) of many major industrial automation suppliers. This is largely because, until recently, much of the automation market didn’t recognize cyber security as a significant threat. Of course, that has all changed but it will take time for automation suppliers to catch up. The article describes practical measures that manufacturers can take to integrate security into their SDL and a certification program from the ISA Security Compliance Institute called ISASecure that recognizes products that have achieved a various levels of software security assurance.
I hope if you haven’t seen this article previously you’ll take a moment to read it. As Eric Byres pointed out in his blog on the Beresford findings, “Now it is time for customers to demand better (security) via purchasing specifications. Customers need to insist that companies have their development processes certified by ISASecure. They need to see clear evidence of an SDL process in place and they need to see in writing exactly what notification process vendors will provide when they discover a vulnerability.”