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

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 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.