Fred Avolio, Avolio Consulting, Inc.
The term "open source" means different things to different people. In the intelligence community, it refers to information sources that are out in the open: books, various news media, published papers, Usenet News groups, etc. When discussing computer software products, Opensource.org (at http://www.opensource.org/osd.html) has a definition that includes (and expands on) these basic tenets:
For the purpose of this discussion, we will focus on #2. When does it make sense to require an open source security solution? I will briefly discuss the reasons why some favor open source solutions, in general, and lay out some pros and cons.
Again, according to Opensource.org, "The basic idea behind open source is very simple. When programmers on the Internet can read, redistribute, and modify the source for a piece of software, it evolves. People improve it, people adapt it, people fix bugs. And this can happen at a speed that, if one is used to the slow pace of conventional software development, seems astonishing."
For security products, most often people cite one or more of the following reasons for wanting source code to the product. Having the source code allows the following.
It is a rare organization that has the resources (time and expert personnel) to do #1. There are organizations that are mandated to attempt this on a "best effort" basis (some by law — those in the intelligence community, for example). For these companies and agencies, full time software engineers are initially employed to examine the code, and then to examine the code changes as new versions of the software come out. The source code provided must be in a form that will compile and run just as the pre-packaged product does, or another method of verification is required so that the examiner knows that the code she is reviewing is actually the source code for the running product.
In the past US and other government agencies have evaluated software systems using code review as part of the process (for example, the US Department of Defense "Orange Book" process). Today, even those processes have een abandoned; they took too much time, were too expensive, and produced a list of evaluated products that were old and, so did not support the latest hardware, software, and application features desired and required by potential customers.
The second point is vital for some organizations, and those will almost always use a product for which they can purchase the source code. Again, most organizations do not have the resources for this. This, of course, requires the availability of software engineers who are intimately familiar with the product and can react at a moment’s notice to track down and fix bugs. The vendor might not support such "customer repaired" products. The user organization now finds itself in the code revision management business.
The number 3 point suffers from the supportability problem of #2. There will always be unique requirements. This is part of what causes someone to purchase one product over another. It is possible that the requirement is so unique (it may be innovative) that a "one off" (special) version of the product is the only answer.
It may be argued that an open source solution (whether freely available or not) means a myriad of support engineers scattered throughout the Internet. This may be true, but many ortganizations cannot trust security related software touched my hundreds or thousands of "faceless" volunteers.
While open source solutions, as defined above, provide for these requirements, for most organizations the challenges may outweigh the results. In lieu of source code, requirements 2 and 3 may be met through a special support contract with the vendor (should the vendor be interested in doing this … it may come down to a simple matter of money). Certainly maintaining a special version of a product for a particular customer is expensive, but may be less expensive than the customer’s trying to do this. Also, what is unique for one customer today, may become mainstream tomorrow. A customer-specific requirement could find its way into the product in the fullness of time.
With regards to #1, most security systems are too complex to be able to meaningfully evaluate (a topic of its own), and so for most of us we must rely on vendor QA processes, field testing, and comments from other users to give a sense of a product’s stability.
We can also decide to only purchase security products certified by a trusted third party. While none use source code evaluation (the same reasons apply), often testing functionality against public test criteria is sufficient. I thing it is the only practical way to evaluate a very complex system, anyway.