Use of Free and Open-Source Software (FOSS) in the U.S. Department of Defense

Use of Free and Open-Source Software (FOSS) in the U.S. Department of Defense is a 2003 report by The MITRE Corporation that documented widespread use of and reliance on free software (termed "FOSS") within the United States Department of Defense (DoD). The report helped end a debate about whether FOSS should be banned from U.S. DoD systems, and helped redirect the discussion towards the current official U.S. DoD policy of treating FOSS and proprietary software as equals.

History

Version 1.0

The FOSS report began in early 2002 as a request relayed to Terry Bollinger of The MITRE Corporation to collect data on how FOSS was being used in U.S. DoD systems. The driver for the request was an ongoing debate within the U.S. DoD about whether to ban the use of FOSS in its systems, and in particular whether to ban GNU General Public License (GPL) software. The U.S. Defense Information Systems Agency (DISA) was also interested, and agreed to sponsor the report. The first draft was completed two weeks later, and version 1.0 was released a few weeks after that. It quickly gained notoriety for its documentation of widespread use of FOSS in the U.S. Department of Defense, and consequently was mentioned in an article about free software in the Washington Post.

The attention resulted in a new round of reviews and edits. Microsoft Corporation requested that Ira Rubinstein, their legal counsel and liaison for DoD software policy issues, be permitted to participate. Rubinstein, who is listed in the preface as the first reviewer, produced the most detailed critique of the report. His recommendations resulted in a massive expansion of the coverage and analysis of free software licenses.

Version 1.2

The final report, version 1.2.04, was completed on January 2, 2003. It was first published on the DISA web site, and is now available on the DoD CIO web site on open source software resources.

Impact

Prior to this report, very little data had been available about how—and even whether—FOSS was used widely in U.S. DoD systems. The report changed this aspect of the discussion immediately, proving beyond any reasonable doubt that the U.S. DoD was already a major user of FOSS. More importantly, the report documented that FOSS was being used in important and even mission-critical situations. One of the more surprising findings documented in the report is that the cyber security community was the most upset of any group at the prospect of FOSS being banned. From their perspective, FOSS provides high code visibility and the ability to fix security flaws quickly and quietly. As a result of the findings, any serious consideration of banning FOSS was dropped. The effort to develop a policy on using FOSS instead moved towards a much more even-handed policy that was initiated with the Stenbit open source software policy, that requires U.S. DoD groups to treat FOSS in the same fashion as proprietary software, and subsequently made even more explicit in the 2009 Wennergren clarification of the Stenbit policy.

The broader impact can be realized by recognizing that if the security-conscious U.S. DoD had banned FOSS, it is likely many other federal components, state and local governments, corporations, and international groups would have followed suit. The result would have been a world much less friendly both to FOSS and to FOSS-like efforts.

Findings

Below is the executive summary of the report. The full report was published in multiple formats, which can be found along with related open source software resources on Bollinger's personal website.

This report documents the results of a short email-mediated study by The MITRE Corporation on the use of free and open-source software (FOSS) in the U.S. Department of Defense (DoD). FOSS is distinctive because it gives users the right to run, copy, distribute, study, change, and improve it as they see fit, without having to ask permission from or make fiscal payments to any external group or person. The autonomy properties of FOSS make it useful for DoD applications such as rapid responses to cyberattacks, for which slow, low-security external update processes are neither practical nor advisable, and for applications where rapid, open, and community-wide sharing of software components is desirable. On the other hand, the same autonomy properties complicate the interactions of FOSS with non-FOSS software, leading to concerns—some valid and some not—about how and where FOSS should be used in complex DoD systems.

The word free in FOSS refers not to fiscal cost, but to the autonomy rights that FOSS grants its users. (A better word for zero-cost software, which lacks such rights, is "freeware.") The phrase open source emphasizes the right of users to study, change, and improve the source code—that is, the detailed design—of FOSS applications. Software that qualifies as free almost always also qualifies as open source, and vice versa, since both phrases derive from the same set of software user rights formulated in the late 1980s by Richard Stallman of the Free Software Foundation.

The goals of the MITRE study were to develop as complete a listing of FOSS applications used in the DoD as possible, and to collect representative examples of how those applications are being used. Over a two-week period the survey identified a total of 115 FOSS applications and 251 examples of their use.

To help analyze the resulting data, the hypothetical question was posed of what would happen if FOSS software were banned in the DoD. Surprisingly, over the course of the analysis it was discovered that this hypothetical question has a real-world analog in the form of proprietary licenses that if widely used would effectively ban most forms of FOSS. For the purpose of the analysis, the effects of the hypothetical ban were evaluated based on how FOSS is currently being used in survey examples. In the case of niche-dominating FOSS products such as Sendmail (ubiquitous for Internet email) and GCC (a similarly ubiquitous compiler), a large amplification factor must also be taken into account when estimating such impacts. The actual levels of DoD use of such ubiquitous applications is likely to be hundreds, thousands, or even tens of thousands of time larger than the number of examples identified in the brief survey.

The main conclusion of the analysis was that FOSS software plays a more critical role in the DoD than has generally been recognized. FOSS applications are most important in four broad areas: Infrastructure Support, Software Development, Security, and Research. One unexpected result was the degree to which Security depends on FOSS. Banning FOSS would remove certain types of infrastructure components (e.g., OpenBSD) that currently help support network security. It would also limit DoD access to—and overall expertise in—the use of powerful FOSS analysis and detection applications that hostile groups could use to help stage cyberattacks. Finally, it would remove the demonstrated ability of FOSS applications to be updated rapidly in response to new types of cyberattack. Taken together, these factors imply that banning FOSS would have immediate, broad, and strongly negative impacts on the ability of many sensitive and security-focused DoD groups to defend against cyberattacks.

For Infrastructure Support, the strong historical link between FOSS and the advent of the Internet means that removing FOSS applications would result in a strongly negative impact on the ability of the DoD to support web and Internet-based applications. Software Development would be hit especially hard for languages such as Perl that are direct outgrowths of the Internet, and would also suffer serious setbacks for development in traditional languages such as C and Ada. Finally, Research would be impacted by a large to very large increase in support costs, and by loss of the unique ability of FOSS to support sharing of research results in the form of executable software.

Neither the survey nor the analysis supports the premise that banning or seriously restricting FOSS would benefit DoD security or defensive capabilities. To the contrary, the combination of an ambiguous status and largely ungrounded fears that it cannot be used with other types of software are keeping FOSS from reaching optimal levels of use. MITRE therefore recommends that the DoD take three policy-level actions to help promote optimum DoD use of FOSS:

1. Create a "Generally Recognized As Safe" FOSS list. This list would provide quick official recognition of FOSS applications that are (a) commercially supported, (b) widely used, and (c) have proven track records of security and reliability—e.g., as measured by speed of closures of CERT reports in comparison to closed-source alternatives. Initial applications for consideration would include, but not be limited to, the set of 115 already-used applications identified by the survey in Table 2, plus other widely used tools such as Python ([1]) that did not appear in this first set of results. In formulating the list, quick consideration should be given in particular to high value, heavily used infrastructure and development tools such as Linux, OpenBSD, NetBSD, FreeBSD, Samba, Apache, Perl, GCC, GNAT, XFree86, OpenSSH, BIND, and sendmail.
2. Develop Generic, Infrastructure, Development, Security, & Research Policies. The DoD should develop generic policies both to promote broader and more effective use of FOSS, and to encourage the use of commercial products that work well with FOSS. A good example of the latter is the Microsoft Windows Services for UNIX product, which relies on FOSS (GPL) software to reduce development costs and dramatically increase its power. A second layer of customized policies should be created to deal with major use areas. For Infrastructure and Development, these policies should focus on enabling easier use of GRAS products such as Apache, Linux, and GCC that are already in wide use, but which often suffer from an ambiguous approval status. For Security, use of GPL within groups with well-defined security boundaries should be encouraged to promote faster, more locally autonomous responses to cyber threats. Finally, for Research the policies should encourage appropriate use of FOSS both to share and publish basic research, and to encourage faster commercial innovation.
3. Encourage use of FOSS to promote product diversity. FOSS applications tend to be much lower in cost than their proprietary equivalents, yet they often provide high levels of functionality with good user acceptance. This makes them good candidates to provide product diversity in both the acquisition and architecture of DoD systems. Acquisition diversity reduces the cost and security risks of being fully dependent on a single software product, while architectural diversity lowers the risk of catastrophic cyber attacks based on automated exploitation of specific features or flaws of very widely deployed products.