Open Source vs. Closed Source Security

One of the most interesting social achievements in the information industry has been the successful development, deployment, and use of Open Source software. By its nature, Open Source has created a great deal of controversy within the IT industry, as many organizations fight fiercely to defend their commercial products. There is a lot at stake as newer and better Open Source applications appear on the market, and many organizations have a lot to lose in the process.

What Is Open Source?

Though everyone seems to define Open Source somewhat differently, most seem to agree that an Open Source application has at least the following properties:

• The application is freely distributable, without having to pay a fee for it.

• The application is available in code format, meaning anyone can view the actual programming source for the application.

• The application can be modified and improved by anyone (though not necessarily distributed in the modified state).

This is not to say that an Open Source application has no owner, or that a programmer must give up rights to the work. Nor does this mean that a developer cannot make a profit off an Open Source product. The owner of the Open Source application, however, gives up the ability to hide the ideas and profit directly from the distribution of the software.

The idea of Open Source may be simple, but its effect is quite profound from both the technical and social aspects. Not since the evolution of the Internet have we seen a concept that has the potential to turn the technical world upside-down. Let's take a quick look into Open Source and how it affects our security practices.

The Problem with Closed Source Applications

When Organization X develops a new software product (a firewall, for example), the entire composition of that product is created within a very restrictive atmosphere. The code of the application is only seen by a handful of core developers who work under high-pressure deadlines to get the software out the door as soon as possible. The test process consists of simulations performed by the developers themselves and Beta-testing users who have no access to "look under the covers." No matter how great the intentions of the organization, no matter how great the budget, and no matter how talented the programmers, developers are severely limited in their ability to discover application errors, potential exploits, and generally improve the functionality and efficiency of the product.

Once the application is completed, the source is locked away, along with all the knowledge used to create it. Thus, there is no way for other developers and organizations to benefit from the lessons learned in the software development process. Every new firewall must be created from scratch, ultimately reliving the mistakes and errors experienced by other firewall developers before. Without access to the source, it becomes extremely difficult to build on the efforts of others, thus greatly restricting the ultimate evolution of a security product.

Finally, new applications almost always incorporate Closed Source application code developed by other organizations. It is rare to find an application programmed completely from scratch because developers rely on pregenerated code from other organizations to save time and effort in their own projects. Thus, a security flaw in a proprietary applet could cause a security flaw in the thousands of other application that were built on that applet by other organizations. This type of situation has caused an extraordinary number of headaches in the world of security. Similar to the previous discussion on trust, application developers must trust all of the pregenerated code integrated in their applications.

The Open Source Dream

The goal of the Open Source concept is similar to the new dream of the Internet: to have a self-sustaining, ever-improving, massive collaboration of effort. In theory, an Open Source application has the greatest potential for achieving perfection from the standpoint of being error-free, tightly secured, and optimally efficient. Open Source development also allows for developers to freely build on the concepts and code of other developers, dramatically increasing the speed at which software development can evolve.

Since Open Source code can be read by anyone, it is subject to the scrutiny of thousands of developers around the world who can pick the code apart. This exposes errors and potential security flaws at a much greater rate than could ever be achieved by a Closed Source application. No development team, regardless of size, talent, or budget, could ever achieve a level of scrutiny as great as that of an Open Source application.

Finally, developers building Open Source code have the ability to review the code before integrating it into their own products. Thus, the developers are able to check the source for errors, security issues, or hidden incompatibilities with their own products before integration.

The Open Source Reality

It is fair to say that Open Source has not yet achieved its ultimate potential. The development of good Open Source operating systems and major Open Source applications and services has opened the door for many changes in technology. Numerous Open Source security applications have sprung up in every genre, including firewalls, penetration testing, and intrusion detection.

Despite all the great Open Source achievements, however, the concept has still not received a welcome among the common user community or the majority of large organizations. Several issues have greatly slowed the reality of Open Source, including:

• Lack of support One of the biggest problems with most Open Source applications is the general lack of formal technical support. An organization implementing an IPChains firewall, for example, does not have a phone number to call or a technical representative who can come out and fix a network outage. While a great deal of support comes from the Open Source user community, it is very hard to sell this idea within a large corporation where SLAs are highly valued.

• Limited accountability Developers of Open Source software have no formal accountability that ties them to the quality of their products. If, for example, an Open Source IDS had a major flaw within it, nobody is accountable when that flaw is discovered. Since no one is accountable and no one stands to lose customers or contracts, there is no guarantee that a patch will be generated to fix the problem. This can also limit the developer's motivation to make sure such flaws don't exist in the first place.

• Lack of organization While Open Source applications can be modified and enhanced by the general user community, there is no inherent ability to organize such efforts within the Open Source model. Each developer has his or her own process for considering modifications from other developers and integrating them into their own products, which can affect the speed of product evolution. Thus, most of the additions and enhancements actually found for Open Source products are available from third-party developer updates that may not be compatible with updates from other parties.

• Lack of Open Source friendliness The focus of most Open Source products seems to be to make the applications more and more functional, flexible, and have additional capabilities. Most off-the-shelf products, however, are focused on the creation of the graphical user interface (GUI) and tools to make them more user-friendly. Oftentimes, there is no functional difference between the capabilities of an Open Source application and an application that costs tens of thousands of dollars, but the expensive solution is selected because of its friendly presentation.

How Secure Is Open Source?

I previously discussed the concept of secretless security, a topic closely related to the security of Open Source applications. The tendency is to think that a firewall's code should be kept secret so that hackers will not have the opportunity to review it and find its weaknesses. Nothing could be further from the truth as has been proven time and again by the countless vulnerabilities found in Microsoft, Solaris, and other Closed Source operating systems. If a vulnerability exists within an application, it will eventually be discovered; it is only a matter of when it is discovered and who discovers it.

When a new version of Linux is released, a number of vulnerabilities and patches appear within a matter of weeks. This is because the source of the software has come under the scrutiny of thousands of developers around the world. If Linux was Closed Source, these vulnerabilities would most likely not be discovered by a developer reviewing pieces of the code, but rather by thousands of hackers attempting various exploits on it. With Closed Source software, there is a greater chance that the vulnerability will remain unknown until a successful hack occurs.

The Ultimate Potential

Open Source software has a much higher potential for security than Closed Source. If, for example, we wanted to guard national secrets behind a firewall, we could not simply trust the developers of the firewall or the firewall's operating system. Extending that level of trust to a vendor would be extremely risky. At the same time, developing our own Closed Source version would leave us with a product that has not been scrutinized by thousands of developers around the world. Thus, the most reasonable solution would be to use an Open Source product that we ourselves can scrutinize and that has already been scrutinized by the public.

When Should Open Source Security Software be Used?

All this begs the question: When should we use Open Source software? Over the past few years, information security has attracted a great many Open Source solutions. Every off-the-shelf security product has at least a few competing Open Source products with similar capabilities. Organizations implementing security now have the choice to deploy packaged products or Open Source applications within their environments. So, how do we choose which way to go? The considerations in Table 10.1 should help us decide:

Table 10.1. Considerations Before Implementing Open Source Solutions

Support Considerations
How much support does the organization need? Does the operations staff have the expertise and availability to operate without direct support?	Most likely, installation or maintenance support will not be directly available. Most support for Open Source applications is provided through user forums and frequently asked questions (FAQ) pages.
Does the solution have a dedicated Web site and user forum?	Before any Open Source security solution is implemented, an organization should be sure these basic forms of support are available.
Does the Open Source solution provide a complete and comprehensive manual and help system?	Before a security product is implemented, an organization should be extremely familiar with its use. If an error is made in the implementation or maintenance, the organization could be left vulnerable to attack. Unfortunately, many Open Source products do not come with good documentation.
Technical Considerations
Does the solution provide an easy-to-use interface?	An easy-to-use interface greatly reduces the chance of errors occurring during implementation and maintenance.
Does the solution provide regular updates?	Security products must be constantly updated as new exploits are created. A patch should be released soon after an exploit or vulnerability is discovered.
Has the solution been widely distributed for at least six months?	It is extremely important to avoid being a guinea pig with any security solution. Make sure the product has been widely used for some time before adopting it.
Political Considerations
Do you need some form of accountability?	Open Source products are not generally associated with any accountability beyond the developer's desire to support the product. There is usually no organization to take legal or political blame for any problems.
Making a Decision
Given all this information, do the cost savings and other factors justify the use of the Open Source product?	Be sure to include the costs of implementation, support contracts, and maintenance.