Thursday, December 04, 2008

Open Source Cliches of the Day

First it was ludicrous article Open source is dead long live open source (don't get me started about the notion that Open Source code is so good that it doesn't need support, put the crackpipe down!) and then Bejtlich Cited in Economist.

While kudos go out to Richard (and I'm quite jealous) about being cited in The Economist I wish it would have been about NSM and not Open Source:
One way for governments to do this [to become resilient to cyber attack], says Richard Bejtlich, a former digital-security officer with the United States Air Force who now works at GE, an American conglomerate, might be to make greater use of open-source software, the underlying source code of which is available to anyone to inspect and improve. To those outside the field of computer security, and particularly to government types, the idea that such software can be more secure than code that is kept under lock and key can be difficult to accept. But from web-browsers to operating systems to encryption algorithms, the more people can scrutinise a piece of code, the more likely it is that its weak spots will be found and fixed. It may be that open-source defence is the best preparation for open-source attack.
Besides being included in article on my non-favorite topic of late (cyber-anything makes me ill) I think Richard is repeating one (or maybe two) security cliches: the "more eyes mean greater security" and the oft-repeated negation of "security through security."

OpenBSD is not PHP.
Linux is not Apache.
Tomcat is not BIND.
Debian is not OpenSSH.
Fedora is not SELinux.
Firefox is not Ruby on Rails.

Each of these may or may not be "more secure" than the other--or compared to an individual development team within a vendor we know and love/hate.

Software security is about tools, talent, and techniques not whether code of open or closed. Developer culture and committed project leadership are what make software secure, not whether the code exposed to clueless masses to find security flaws. Furthermore, there is great diversity in code quality, development (and business/sponsorship) models among Open Source pojrects that make it very difficult to make these sort of generalizations about the security of Open Source, let alone the role of Open Source in "resisting a Cyberattack" and much better case could be made based about the Open Source network security toolset that Richard champions in thwarting attackers -- as opposed to the inherent robustness and integrity of the Open Source codebase. With the exception of the Intel community, how many government personnel (or their contractors) are spending time scrutinizing the Linux kernel source? Jakarta Struts?

Not too many, I would guess.

While I am certainly a huge advocate of Open Source (and have had the [mis]fortune of developing/operating Open Source-based security platforms performingcritical functionality within a large Enterprise to back it up) security would not be at the top of the list as the reason to develop on (or deploy) an Open Source stack. For me it is about control, customization, and cost. Probably in that order. Yes, transparency, can result in improved code security (meaning fewer vulnerabilities per line of code) and better decision making in terms of deciding when and whether to patch (if I can look at the diff I don't have to guess about the true impact of the cryptic Cisco/Microsoft advisory or worse) but this is only a potential that in many (perhaps) Open Source projects don't live up to in reality.

No comments: