Last week’s Defense Daily Cyber-Security Summit in Washington drew participants from industry and government agencies including the intelligence community (I could tell you, but…), NRC, TSA and the DoD. The panel on which I spoke discussed “open security” and included representatives from HP’s Fortify group and experts from NSA and Homeland Security. The conclusions confirmed my belief that it’s much more about how you manage the software than whether it is open source or proprietary.
Obviously, the more secrecy the better when it comes to security… or maybe not. Auguste Kerckhoff, a 19th century Dutch cryptographer, took the counter intuitive (and now pretty well accepted) position that a crypto system should be secure even if the enemy knows its ins and outs (save for the key). That, at least, says that there is nothing inherently insecure about open source. And the “many eyeballs” argument suggests that open source could, in fact, be more secure than proprietary software, although opponents would say that few of those eyeballs would have the expertise to know a vulnerability if it bit them.
The prevailing wisdom seems to be that open source software can be secure, just as proprietary software can have holes like Swiss cheese. The more important issue is how the software is managed. Most software today is multi-source, i.e. an assembly of components from a variety of sources, open and closed. Knowing what’s in the software is a baseline requirement for assessing its security. The pervasiveness and availability of open source makes this a fundamental challenge to the point that, without a tight process for managing code provenance, there’s literally no way to know what’s in the code and how good it is along many dimensions. Fortuitously, concerns about software licensing and intellectual property, having little to do with security, motivate companies to implement processes which can provide the basis for security assessment, as well.
Of course security is an issue that persists after deployment. Even if a developer does extensive due diligence on a component before integrating, a new vulnerability may be discovered in that component a day or a year later. Meanwhile, as code gets shared inside an organization, use of that component may have propagated far and wide. I know of a bank CIO who literally spent months tracking down all instances of a piece of code that was found to be vulnerable. So code needs to be managed both during development and after deployment.
Fundamentally, the access developers have to open source makes it difficult to know what’s in the code. Licensing concerns drive many companies to develop processes to deal with the issue, but as I often find myself saying, “There are a lot of good reasons beyond licensing to manage what’s in your code,” and security is certainly a big one, particularly around Washington.
Photo credit: www.pikeresearch.com
