Real World Open Source: Security
Security breaches in software applications and networks are one of the biggest threats organizations currently face. But unless you pack your computers into boxes and go back to pencils, paper, and typewriters, being mindful of electronic security is an unavoidable reality and business expense. Because security vulnerabilities are such a high stakes issue, the subject has become a political hot potato between open source and commercial software advocates, with each pointing a finger at the other. Some commercial software vendors claim that their model promotes security while the open source model weakens it; some open source developers claim the exact opposite.Security is often the first concern when deciding between open source vs. commercial software. The many philosophical differences result in pros and cons for each side.
For organization making the decisions, however, blanket generalizations are best avoided.
The traditional argument in favor of closed proprietary software is "security through obscurity." The idea is rooted in the fact that if people can't see inside, they can't find the software's weaknesses. Open source developers, on the other hand, argue that keeping the source code in plain view results in mistakes that could benefit hackers being more quickly caught and repaired.
Both arguments contain partial truths. The commercial software argument presumes the information needed to breach an application is limited to inside knowledge of that program's source code. However, this is demonstrably untrue: Hackers have long found "holes in the dike," as it were, simply by feeling around and launching myriad attacks against the product to find signs of weakness. None of this requires inside knowledge, as has been demonstrated time and time again in the thousands of security holes found in many commercial products throughout the years.
The traditional argument in favor of closed proprietary software is "security through obscurity." The idea is rooted in the fact that if people can't see inside, they can't find the software's weaknesses.
On the other hand, the open source advocate's faith in maintaining source code in plain view assumes the right set of eyes sees the vulnerability before the wrong set of eyes. This is not "automagically" true, as they like to say in programming lingo. Presumably, the most popular applications with large installed bases and active community support will benefit most from open source transparency. But more eyes is no guarantee. Even Apache, Linux, and the cause celebre browser, Firefox, have suffered security breaches despite being popular open source projects.
Open source advocates argue that even when a security breach is found, it can be fixed quickly and a patch made available almost immediately. Critics counter there is no way to determine who has supplied the fix and how reliable it is.
Commercial software vendors suggest that their brand is their credibility. Here, critics counter they have reason to drag their feet on security vulnerabilities to maintain a good image and thus may not release patches until after a security hole becomes public knowledge.
As an example, the two major products in the Web server market are the open source Apache and the commercial Microsoft IIS. Since 1999, the Apache Software Foundation has released 132 reports of known vulnerabilities. Microsoft has released 116 for IIS. Fixes for both include updated software patches and recommended configuration changes. The numbers here really reflect the whole philosophical debate over security between open source and commercial software. There is no conclusive answer.
The limitation of any stereotype is that it overlooks the individual. When choosing software products, the individual security history matters most. Most software applications particularly servers possess weaknesses. While Web sites like SecurityFocus.com provide detailed vulnerability reports for most software vendors, don't judge a product solely on the sheer number of incidents. A high incident rate could simply mean that the vendor or the product's maintainers are very pro-active, which could be reassuring.
Also consider the nature of security weaknesses in a product's history. Denial of service incidents may indicate the product
Neither commercial nor open source software enjoys a "set it and forget it" security. It just isn't possible in today's massively networked world.
Finally, vendor reports found on sites like SecurityFocus typically include proposed solutions, so be sure to check out the kinds of solutions the vendor offers for the product under consideration. Easy-to-install patches involve minimum administrative overhead. Complex reconfiguration of the software may require more time, knowledge, and introduce the risk of causing new problems.
In open source, software vulnerability reports typically propagate from the bottom up. For example, if a security hole is discovered in Apache, the Apache maintainers will likely report on the bug first. Vendors like Red Hat (and even Apple) package Apache with their operating systems, so the Apache report will eventually bubble up to them and be resolved via their updates.
Receiving security notices from Red Hat or Apple is efficient because their ears are to the ground for a wide variety of programs. On the flipside, they may be slower than the product's developers to announce a security flaw and its fix.
Neither commercial nor open source software enjoys a "set it and forget it" security. It just isn't possible in today's massively networked world. Vigilance means staying in close contact with vendor or developer about newly discovered flaws and holding a healthy suspicion about any product or vendor that admits to few of them.