Top 5 Misconceptions About Open Source In Government Programs

On March 15, 2013, ComputerWeekly.com, the “leading provider of news, analysis, opinion, information and services for the UK IT community” published an article by Bryan Glick entitled: Government mandates 'preference' for open source. The article focuses on the release of the UK’s new Government Service Design Manual, which, from April 2013, will provide governing standards for the online services developed by the UK’s government for public consumption.

Perhaps the most interesting part of the new document is a section entitled: When to use open source. Interesting to me, at least. For a number of years I’ve been advocating the use of open source products for projects within the US defense and intelligence communities. So, forgive me for going a little green with envy when I read the following within that section:

Use open source software in preference to proprietary or closed source alternatives, in particular for operating systems, networking software, web servers, databases and programming languages.

The statement doesn’t leave much room for discussion or doubt. When there’s a choice between comparable alternatives, open source wins. Period. How enlightened!

Within US government programs, while the use of open source software (OSS) is not mandatory, it is both permissible and often encouraged. However, due to the Byzantine nature of the controlling laws, regulations, policies, and guidance (LRPG) as well as some popular misconceptions, architects, systems engineers, and developers often encounter reactions ranging from unfamiliarity to resistance when recommending the use of OSS. For the remainder of this article, we’ll debug five of the most widespread misconceptions. Specifically, we'll talk about the myths that:

1. OSS isn't widely used in government programs
2. OSS isn't equivalent to commercial software
3. Government information assurance policies prohibit OSS
4. OSS is less secure than proprietary software
5. It's easier to insert malicious code into OSS

1) OSS isn’t widely used in government programs

Open source components and applications have long been leveraged by US government programs, and often provide irreplaceable core system capabilities. To name a few:

• Mozilla Firefox Browser and Thunderbird Email Client
• Google Android Operating System for Mobile Devices
• Apache Tomcat Web Server and Servlet Container
• Linux Operating System
• PostgreSQL Object Relational Database Management System (ORDBMS)
• Drupal Content Management System
• WSO2 Enterprise Service Bus (ESB)
• Apache Hadoop Distributed Computing Framework
• NASA World Wind Geospatial Information System (GIS)

2) OSS isn't equivalent to commercial software

Most, if not all, OSS applications and components are, by law, commercial items. The definition comes from a US federal law (41 USC 403, subsection 12) that identifies a 'commercial item' as:

(A) Any item, other than real property, that is of a type customarily used by the general public or by nongovernmental entities for purposes other than governmental purposes, and that

(i) has been sold, leased, or licensed to the general public; or

(ii) has been offered for sale, lease, or license to the general public.

(B) Any item that evolved from an item described in subparagraph (A) through advances in technology or performance and that is not yet available in the commercial marketplace, but will be available in the commercial marketplace in time to satisfy the delivery requirements under a Federal Government solicitation.

(C) Any item that, but for

(i) modifications of a type customarily available in the commercial marketplace, or

(ii) minor modifications made to meet Federal Government requirements, would satisfy the criteria in subparagraph (A) or (B).

The interpretation of this law as declaring OSS to be 'commercial software' was confirmed by the DoD’s issuance of Clarifying Guidance Regarding OSS on October 16, 2009 and the US Navy’s issuance of a memorandum for OSS guidance on July 5, 2007.

Moreover, the US Office of Management and Budget (OMB) has recognized the commercial nature of OSS support agreements since the 2003 issuance of memorandum M-03-14: Reducing Cost and Improving Quality in Federal Purchases of Commercial Software. Indeed, many well-known commercial companies (e.g., IBM, RedHat, Novell, Microsoft, etc.) earn considerable revenue by supporting open source products. Other commercial companies, such as WSO2, build open source software products and generate revenue solely from support and consulting associated with those products.

3) Government information assurance policies prohibit OSS

This misconception derives from a misreading or, more accurately, an incomplete reading of DoD Instruction 8500.2 Information Assurance (IA) Implementation. This document contains an enclosure (Enclosure 4) entitled: Baseline Information Assurance Levels. This enclosure contains a number of software controls with which an approved system must comply (or, if non-compliant, must receive a waiver from the Designated Approval Authority (DAA)). Among them is control DCPD-1 Public Domain Software Controls. The idea that OSS is prohibited arises because many people only read the first set few lines, which read:

Binary or machine executable public domain software products and other software products with limited or no warranty such as those commonly known as freeware or shareware are not used in DoD information systems unless they are necessary for mission accomplishment and there are no alternative IT solutions available.

The text of the control continues, however:

Such products are assessed for information assurance impacts, and approved for use by the DAA. The assessment addresses the fact that such software products are difficult or impossible to review, repair, or extend, given that the Government does not have access to the original source code and there is no owner who could make such repairs on behalf of the Government. (Emphasis added.)

The key to fully understanding this control lies in the last sentence, which discusses consequences flowing from the fact that the government does not have access to the original source code. The control (which was put in place to deal with abandoned binaries) clearly cannot apply to OSS because by definition, the user has access to the source code!

4) OSS is less secure than proprietary software

There is a common misunderstanding along the lines of "since OSS is available for the world to see, it’s easier to hack." Put another way, the assertion is that since the source code for proprietary software is not disclosed, attackers are unaware of vulnerabilities. Reality and the information technology community disagree with this premise. As far back as 1973 Jerome Saltzer and Michael Schroeder argued in their paper The Protection of Information in Computer Systems that depending on attacker ignorance isn’t an effective protection mechanism. More recently, security experts Vincent Rijmen (one of the creators of the Rijndael algorithm that later became the Advanced Encryption Standard (AES) and Whitfield Diffie (a pioneer of public key cryptography) echoed the sentiment.

It’s especially telling that prior to adopting the Rijndael algorithm as AES in Federal Information Processing Standard (FIPS) 197 in 2001, the National Institute of Standards and Technology (NIST) published the algorithm publicly. Approximately three years were allocated, during which cryptanalysts from all over the world were asked to try to defeat Rijndael. In the end, all attempts failed, and AES remains the core of US government encryption methods today. Of the transparent (and essentially open source) process, Bruce Schneier, author of one of the losing algorithms said, "I have nothing but good things to say about NIST and the AES process."

5) It’s easier to insert malicious code into OSS

One of the arguments made against OSS is that anyone can modify it, including attackers. The reality is that ANY code can be modified; all you need is a hex editor. The real issue is getting the modified code into the supply chain. Not only does this premise require subverting both the developers and the trusted repository, but it simply ignores the realities of working with a distributed source. OSS, whether developed by a community or a company, is regularly reviewed by a loosely coupled inspection organization that is many times the size of those economically feasible for proprietary developer companies. Additionally, the wide range of reviewers results in inspection from many different perspectives.

As a result, it is much more difficult for subverted code to remain undetected for long.  Perhaps the most illustrative story in this vein is that of Borland’s InterBase/Firebird database. When developed, a back door was built into the system.  Using the username 'politically' and the password 'correct' it was possible to get administrative access to the database over the Internet. At the time of discovery in 2001, it was estimated that the back door had existed at least since 1994. From an OSS standpoint, it’s interesting to note that Borland open sourced the InterBase source code under a Mozilla Public License in mid-2000. Within five months of the open source release, the security hole that had lain undiscovered for at least seven years had been discovered.

Conclusion

In summary, while the US government has, to date not issued guidance requiring a preference for open source, it has clearly indicated that open source products are to be given at least as much preference as proprietary products. Additionally, open source products come with some significant intrinsic benefits with respect to security and information assurance. What this really means is that acquisitions managers have greater choice and an increased ability to make programmatic decisions that increase capability while lowering total cost of ownership.  And that’s a recipe for success all around.

Originially posted on The Intelligent Triad. Reposted by Opensource.com under Creative Commons.