Open source software — it’s fast, it’s popular, it’s practical, and, best of all, it’s free.
Chances are (if your firm is like most) you’re using some of it somewhere in your enterprise; in fact, you’re probably using it in multiple places. One of the most frequent questions security professionals get asked is how open source software compares to its commercial counterparts from a security perspective.
There are a number of well-respected individuals arguing on both sides of the “open source security” fence: some say that the fact that open source code is transparent and freely available helps make open source more secure than commercial software.
On the other hand, there are other well-respected individuals who claim that lack of contractual agreements between vendor and purchaser in the open source world makes open source deployments less secure.
So which is it? Is it better to run your company’s firewall or IDS using an open source tool, or is it better to buy something off the shelf? Let’s step through some of the most common arguments used by each side of the open source security debate and see how they do or do not stand up in the light of practical reality.
True or False: More Scrutiny Means More Security
One of the most commonly cited arguments in evaluating the relative security of open source software is that “more eyes on the code” means fewer security problems. In other words, more scrutiny of the underlying source code in terms of testing, review, audit and debugging translates directly to increasingly robust software in the final product. This is unquestionably true. However, the argument that open source projects are generally more secure because the source code is available (and therefore has undergone more scrutiny) — well, that’s where things start to get fuzzy.
Let’s face it — not all software is created equal. Some software is popular and some isn’t. Some developers are committed to testing/auditing and some aren’t. While heavily used and actively maintained open source applications like Apache and OpenSSH probably receive a great deal of scrutiny (both public and private), smaller applications or applications that are not as actively maintained probably have not.
Remember, just because the source code for a given piece of software is available for review doesn’t necessarily mean that anybody actually does review it. By the same token, commercial software vendors vary as well — some are actively committed to making sure their source code is thoroughly tested and audited whereas others couldn’t care less. Some vendors will, if asked, provide source code to certain users (e.g. high-volume purchasers), or to the public at large provided that intellectual property protections are maintained.
Just because a product is commercial doesn’t mean that it’s not reviewed. As is often the case in real-world situations, the answer depends on the circumstances.
True or False: Accountability and Support Mean More Security
Advocates for commercial software security often suggest that the contractual relationship between purchaser and vendor in typical commercial software licensing arrangements provides a degree of accountability not present in an open source context. The thinking is, if a security flaw is found or if the product does not work as advertised, then a single entity (the vendor) can be held accountable and be pressured to deliver a fix, to update the product, or to provide sufficient support to get the product (or feature) operational. The argument is that open source does not involve these relationships and is therefore somehow “less secure” than commercial counterparts.
How does this argument stand up in practice? Again, it depends. Just as not all software is created equal, not all support offerings are created equal. In some cases, open source developers provide paid support relationships for projects they maintain for users that need it; in other cases, non-affiliated third parties provide support for the open source tool. Also, many open source products are very open about making available answers to previously asked questions via mailing list archives and/or “knowledgebase” Web sites.
The ease with which answers to questions can be obtained will depend on the particular open source project under consideration — larger projects are more likely to have published responses to related questions (security-related and otherwise) in the past that can be leveraged by the savvy administrator.
In the same vein, vendors provide varying levels of support. The amount of attention your particular request will receive will be based on the type of support relationship entered into and the particular support policies of that vendor. Don’t forget that just because you’re paying for support doesn’t mean it’s any good, and just because support is free doesn’t mean it isn’t good.
True or False: More Updates Mean More Security
“Release early, release often” is the approach taken by many open source projects. In many open source projects, the philosophy espoused is that fixes to security flaws should be made immediately available to the users of the software so that administrators can quickly respond to potential security issues. In this view, administrators are informed as rapidly as possible to security issues and issued either a workaround or a patch that they can immediately employ to make sure that their systems remain secure — or, at the very least, that they know about the issue so that they can monitor for attackers making use of it.
By contrast, many commercial vendors make patches available on a set schedule — for example quarterly or monthly. Their philosophy is to keep the security issue as secret as possible until the fix is prepared; then, by releasing the fix according to a known timetable, administrators are able to plan, test and deploy the fixes in a controlled manner so as to minimize impact to production operations.
What is important to realize about both of these philosophies is that they both have the same goal. In both the “release early, release often” and the set timetable approach, the goal is to make it easy for the administrators to deploy the patches, fixes and workarounds to impacted machines.
The “release early, release often” view attempts to inform the administrator first and foremost — by making the administrator aware of the issue, the belief is that the administrator will be best equipped to deal with the issue rapidly. The “timetable” approach embraces the idea that planning is most important — administrators are not “overwhelmed” by patches but are instead given time to prepare for when the fix comes out.
Which approach is “better” or “more secure?” As you probably expect by now, that will depend on the specifics of the environment. Is your firm’s environment one where administrators are able to rapidly respond to security-related changes, or is it one where quite a bit of planning and resource allocation is required to make production-related changes? Are administrators comfortable staying alert for notifications regarding possible issues in software employed? Is there a preference for immediate notification to a potential issue?
So, at the end of the day, is open source more secure? Is commercial software more secure? Yes and yes — depending on your enterprise and the particular projects/products in question. Just like asking, “are Fords faster then GM?” — it depends on the Ford and depends on the GM. A 2007 Jimmy, for example, is likely to whoop the pants off your grandma’s Edsel — but maybe the Corvaire wouldn’t do so well against a Mustang. No one software licensing model is going to fit everybody’s needs — it pays to evaluate each product and project in light of your own firm’s requirements. What might be better for the next guy might not be better for you.
Ed Moyle is currently a manager withCTG’s information security solutions practice, providing strategy, consulting and solutions to clients worldwide, as well as a founding partner ofSecurity Curve. His extensive background in computer security includes experience in forensics, application penetration testing, information security audit, and secure solutions development.
Loading ...
Accountability:
A line of open source code has an identifiable author who feels pride or shame.
The individual coders of a proprietary vendor have no personal accountability and therefore arguably less care in their work.
Release early:
Even if a new open source patch is released every day, an administrator still has the choice to only review/apply them once a month if so desired.
A proprietary vendor never gives the administrator the option of applying a fix as soon as possible, nor even of knowing about the vulnerability.
The missing piece in this whole argument is the system design.
?nix systems have always had security. It was included in the earliest designs by Ken Thompson and continues today.
Like it or not, OS-2 and all versions of Windows have their roots in MS-DOS which had no security. The security efforts in Windows are an add-on to the original DOS designs.
Though it may be improved, Vista’s security is still, at it’s base level, an add-on to the original DOS designs. It can be no other way if the intent/requirement is to maintain some portion of compatibility with existing (legacy) applications.
Speaking as a programmer with 30+ years experience, a MCSE and a Unix professor at a local college, if Microsoft or anyone else redesigned Windows from the ground up, any backward compatibility with legacy applications would be lost. Many security companies would be out of business. Fewer network professionals would be needed. In short, the design would resemble, if not match, Ken Thompson’s original designs.
It seems to me that the marketing boys and girls have taken lessons from stage magicians. Look to your left while my assistant hides the facts on your right.