This work is licensed under a Creative Commons Attribution 4.0 International License.
by Andy Oram
October 20, 2015
This article originally appeared on the International Manufacturing Technology Show site.
A continuous stream of news items about security break-ins remind us that smart objects are sometimes too smart for their own good. As networking, analytics, and control mechanisms become increasingly integrated with factories, as well as with the objects they manufacture, manufacturers have to search for radical, innovative approaches to security. Could it help to open source the software used for these activities?
Open source software is not magically better than closed, proprietary software. The two types of software tends to suffer from bugs—including serious security flaws—at comparable rates. But opening the code has great value in the security community. Security experts are far-flung and individualistic. They like working in the open.
Numerous computer companies, including Microsoft and a contest organized by Google and Hewlett-Packard, offer bounties to outsiders who discover flaws in web browsers. Some of the code is open source and some is closed.
Opening your source code can be scary. In theory, attackers could discover and exploit flaws before the white hats find and fix them. But attackers have more tools than one might imagine to attack closed code: disassemblers, side channel attacks (such as tracking electrical emissions), and more. If an attacker has physical access to a device, numerous techniques can be used to break down its defenses. Working over a network is harder, but can still break a closed device.
One intriguing tool that both defenders and attackers use is fuzzing, a technique of sending random streams of data to the device’s web interface or some network port. Often this triggers failures or other behavior that shouldn’t happen—and the attacker can then determine how to reliably reproduce the attack.
Fuzzing is particularly interesting because it works best when the attacker has the source code, as shown in one technical discussion of an open-source fuzzing tool. This tool was developed by a white hat, and turned up serious security flaws in major tools such as OpenSSL. The tool came along too late to uncover the notorious Heartbleed flaw, but would have uncovered that flaw had the tool existed earlier.
Opening source code can also be scary because it exposes the quality of your programmers to the world. Are they ready to have their work scrutinized publicly? Anecdotes suggest that programmers are less worried about publicity than management. It’s better to hear the bad news before you have a failure or break-in.
You can publish your source code without making it fully open source. Open source means not only that people can view the code, but that they can change it and distribute new versions. This can benefit you in the long run, too. As a trade-off for letting other people use your software (including competitors), you may get enhancements you never imagined for yourself. You’ll also be fostering a community of developers who deeply understand your software, making it easier to hire experienced programmers and get them productive quickly.
But at least let the world see your code. It’s like getting an expert code review for free. The attackers will get into your system regardless, if they choose to do so—and the lesson you learn then will be a painful one.
This work is licensed under a Creative Commons Attribution 4.0 International License.
Author’s home page
Other articles in chronological order
Index to other articles