Using open source for security

There is a widespread and wholly inaccurate impression that open source development is somehow haphazard and undisciplined, a free-for-all among brilliant but uncoordinated individuals.

In fact most major open source projects are very tightly managed and run by highly-disciplined teams. Astaro discusses examples of successful open source security projects and describes some weaknesses that need to be addressed by IT organizations or vendors.

It is clear that the challenges related to security are escalating. Outbreaks of viruses and worms are becoming more virulent and spreading faster. Blended threats and application-specific attacks are becoming more sophisticated and harder to detect.

Wireless communications, instant messaging and peer-to-peer networks are opening new holes in corporate defence systems.

Top management is taking a sudden and unaccustomed interest in IT security. Yet IT departments are not getting additional resources to meet these growing pressures.

Innovation in open source

How can the open source community help? Clearly there is a terrific surge of innovation in the field of IT security coming from open source developers and the supporting infrastructure of Linux – and open source-related organizations, websites and publications.

A search on the word 'security' on the freshmeat website (http://freshmeat.net) turns up more than 1,200 entries.

Security advantages of open source

When it comes to Linux versus Windows it is almost a matter of philosophy. There is no doubt that today there are far more worms and exploits on Windows-based systems than on Linux-based products.

Yet it is not certain if this is simply because the worldwide success of Windows systems makes a more inviting target for hackers, or if the architecture of Linux is inherently more resistant to attack.

In any case there is a strong case that Linux does have structural advantages when it comes to security. For example you can strip out elements of Linux that are not needed from a security standpoint.

This removes many vulnerabilities that a hacker could use to attack a more complex version of the operating system. Performing this kind of pruning would be far more difficult with Windows.

A more important factor however is the fundamental development process used for open source projects.

For major projects, code is rigorously examined and exhaustively tested by hundreds of individuals – far more than even the largest commercial vendor can bring to bear on a single product.

The pace of learning and improvement is also much faster than would be possible in a typical commercial setting. Vulnerabilities are exposed more quickly and solutions developed and tested more readily.

Perhaps most important, in the open source world it is impossible to hide or downplay security vulnerabilities. The open source development process harnesses human nature to ruthlessly expose and eliminate weaknesses rather than to deny mistakes or delay remediation.

Myths about open source development

The widespread impression that open source development is somehow an undisciplined free-for-all among brilliant but uncoordinated individuals is clearly off-mark. Most major open source projects are very tightly managed by a small, highly-disciplined core team.

This team determines the architecture of the software, selects the code to be included and manages all phases of the development process. It enforces strict source control processes, and establishes detailed coding styles and security guidelines.

Critical mass in the open source world comes from the dozens, hundreds or even thousands of developers who examine and test existing software and submit new code.

These developers provide the quantity of inspiration, innovation and plain hard work that is impossible to duplicate in a commercial setting. However the core team is always there to coordinate the work of the masses and select the best work to include in the primary branch of the software.

An excellent example of a cutting-edge open source effort is the netfilter project (www.netfilter.org), a Linux-based packet filter that features stateful firewalling, network address translation (NAT), load balancing and other kinds of packet mangling.

The project was founded in 1999 in Australia and has now grown to more than 100,000 lines of code contributed by over 700 developers. There are currently about 300 active developers submitting about 1,400 postings a month to the development mailing lists.

The core team consists of four members who winnow down the submissions to an average of 65 code improvements and fixes per month.

Limitations of open source

Open source projects are an outstanding source of world-class security technology, but they are not a panacea for developers or IT managers who need to deploy reliable, manageable software in a real-world production environment.

The open source community is driven by technical enthusiasm, not commercial needs. While most open source developers understand the requirements of IT departments very well they cannot reasonably be expected to donate their free time to working on mundane management issues.

As a result open source projects provide brilliant, innovative solutions to fundamental problems but ease of use and ease of management are typically afterthoughts.

This tendency can manifest itself in several ways: command-line interfaces or less-than-intuitive GUIs, lack of documentation and help facilities, highly manual methods to update software and threat signatures, and limited reporting capabilities.

These shortcomings are minor for the highly-skilled developer who enjoys digging into a new piece of technology but they are fatal for the systems administrator or IT manager who needs to complete a lot of tasks in a short time.

Beyond the level of the individual open source project there is no incentive to integrate separate packages into what an IT manager would view as a complete solution. While all open source code is available for inspection that does not mean that all of it is inspected with equal thoroughness.

Many eyes will view the technically exciting parts but the environment does not lend itself to saying: Will you please review and test the boring parts? Finally support options are limited for most open source software.

Harnessing open source software for security

How can organizations harness the explosive growth and innovation of the open source community (and its low costs) without suffering from limitations?
There are basically two choices:

  • allocate sufficient resources to fill the gaps; 
  • let a commercial vendor integrate and support a complete solution based on open source components.

In both cases the tasks are basically the same:

  • Somebody needs to create the interfaces and the documentation to make the technology readily accessible to the typical overworked user or administrator (who is being distracted by a constant barrage of competing demands).
  • Somebody needs to set up automated processes to validate settings, patch software, update threat signatures and back up configurations.
  • Somebody needs to create the reports so that the average administrator (who is still distracted and harried) can troubleshoot problems and track trends.
  • And if the solution involves multiple components (which is typical in security), someone needs to integrate the components and do thorough testing to make sure that the pieces work together under all types of hostile conditions.

An illustration: preparing Snort for the typical administrator

One of the most successful open source projects is Snort (www.snort.org), a network intrusion detection system.

Snort's intrusion detection engine is widely considered to be equal to or better than any vendor-developed alternative and the project supports a database of more than 2,000 intrusion detection rules.

However the Snort technology in its raw form is much better suited to a highly-trained security specialist than to the average systems administrator.

Configuring the system and the large number of rules requires a fairly high level of expertise, not to mention a lot of time. Updating the rule set on a regular basis is also a time-consuming manual process.

Astaro decided to utilize the Snort project as the core of a new intrusion protection module of our Linux perimeter security solution. However to fit the software to the needs of a typical administrator we had to add quite a bit of functionality.

For example we:

  • created a user interface that made it simple to turn intrusion detection rules on and off either individually or in categories relating to different applications and protocols (so for example if a particular application or protocol is not in use at a site all of the related rules could be turned off for better performance); 
  • modified the automated update service so that new intrusion threat patterns could be added with the same process that updates the firewall software and virus signatures; 
  • integrated the intrusion detection engine with our firewall so that the firewall could immediately block intrusions (and modified the user interface mentioned above so that the administrator could toggle back and forth between 'intrusion detection' and 'intrusion prevention' for each rule); 
  • removed some of the functionality from the open source project by eliminating some of the intrusion detection rules that we felt would cause too many false positives or slow down performance without providing a measurable benefit to security.

A two-way street

Commercial companies who utilize open source projects must make significant contributions back to the community such as funding projects and developers, and making versions of proprietary software available at no cost.

It is also important to adhere to the various open source licensing rules for example by publishing any changes made to the project code. These activities make commercial companies active contributors to the growth and success of the open source movement.

As an organization you could use open source security projects 'out of the box' if you have a high skill level, a tolerance for rough edges and no need to rely on less dedicated co-workers.

You would also have the option of committing resources in order to add management features, integrate components, and provide support so that the technology can be utilized by your average administrator.

Or you could work with a vendor who integrates and packages open source projects for a commercial audience.

This article first appeared in the BCS Annual Review 2006