Cultural Changes Key to Reducing Barriers to Open Source Software

Australian Defence Force (ADF) and U.S. military personnel work side-by-side in the Air Operations Centre (AOC) during exercise Talisman Saber 07. The U.S. Pacific Command is working with the ADF, Defense Information Systems Agency GRIFFIN program office and the U.S. Joint Forces Command Joint Futures Lab to install open standard chat between the U.S. secret and Australian secret networks to provide cross-domain chat down to tactical level. This will enable improved collaboration during real-world operations and exercises such as Talisman Saber.

Misconceptions about open source software have made many U.S. Defense Department sectors reluctant to employ this technology. Although a 2003 department policy allows its use, many still believe that open source software poses an increased security risk to networks and that it is not supported as well as commercial products.

An example of such software is the U.S. Joint Forces Command’s (JFCOM’s) J-9 Joint Futures Laboratory redact tool. JFCOM developed a free open source software redaction tool to remove changes from standard office documents. “Secure Save” uses OpenOffice.org software to redact non-viewable text, images, metadata and other undesired elements of standard office documents. This tool could be applied to remove information from documents to declassify them and transfer them between networks of different classifications. Today when operators declassify information, they delete it from a document, but the changes are retrievable and could result in the inadvertent disclosure of classified/sensitive information.

This was the case in 2005 when the text from a redacted classified document from Multi-National Force–Iraq (MNF-I) was unintentionally exposed to the public. MNF-I issued a report in Adobe Portable Document Format that described the investigation into the shooting of an Italian journalist. While the actual report posted on the Internet appeared to be unclassified, an Italian citizen was able to recover the deleted classified text by cutting and pasting the document into Microsoft Notepad.

The cost of cleaning up a “network spill” that introduces classified material on an unclassified network is running about $11,000 per incident on the Navy/Marine Corps Intranet (NMCI), so the free Secure Save tool could produce monetary savings for the Navy. Additionally, it would cover more file formats than the costly commercial redaction product currently available on the NMCI. The Navy is missing the opportunity to use this solution because a misunderstanding of the risks of open source software and Defense Department (DOD) apprehension are at the forefront.

Some of the confusion stems from a lack of understanding regarding the differences between open standards, open source, freeware and closed-source software. Open standards are generally described as a specification for a procedure, protocol or technology developed by a recognized standards body, such as the World Wide Web Consortium, that is available for anyone to implement. The standard must be patent-free or under reasonable and nondiscriminatory patent license to be considered open.

Freeware is software that is distributed completely free of charge and may be open or closed source. Adobe Reader is a good example of freeware. Open source software is available for anyone to view, modify, compile and use. It is not necessarily free or unsupported. Red Hat Linux is a good example, as is MySQL. AB’s MySQL Database, though open source, does not allow people outside the company to contribute software to the product. It is essentially no different from Microsoft SQL, except everyone can see the source code. Open source also can mean a different vendor support model whereby instead of paying for a license and support, customers obtain support from any vendor.

Closed source software, which provides no access to source code, also could be freeware. For example, the PocketMac BlackBerry software is free, but it is not open source. Closed source software is a misnomer, as it is often not really closed. For example, Microsoft shares its source code with a number of national governments, including China.

Open source software is not necessarily free throughout its life cycle. The cost of maintaining this software must be budgeted or there is a risk of fielding an unsustainable capability. While cost is often a factor, capability and adaptability are important; but perhaps the more important criterion of source software is improved interoperability.

An excellent example of public sector use of open source software providing a model for DOD to emulate is from the state of California’s Air Resources Board. The board’s chief information officer, Bill Welty, has long been a proponent of open source for its flexibility, adaptability, cost savings, innovation and interoperability. Welty states, “Sixty five percent of our applications run on Linux, and over 60 percent of our databases leverage open source solutions. We use Linux, Apache, MySQL, PHP, Python and Perl [a combination of software programs known as LAMP stacks]. Over the years, since 1994, we’ve easily saved more than $500,000 in software licenses. While the cost benefits have been substantial, improvements in interoperability along with quick procurement cycles and boosts to staff morale—programmers really like ‘owning their code’—have been key driving forces. This has been the true value of LAMP and our other open source initiatives.”

One common misconception about open source software is that it can be changed by anyone and is less secure; however, most open source is strictly governed. For example, the Apache Software Foundation has tight configuration management controls for developers. Its  products are so good that most major software vendors include some Apache software in their products including Microsoft, IBM, Oracle and Sun. A number of DOD communications systems use Apache software. When it comes to security and who contributes the code, it is no different from the global contributors for commercial code. Companies such as Microsoft, Cisco and Oracle have massive investments in code development overseas. Rarely is DOD, the National Institute of Standards and Technology or the National Security Administration able to see that code. In several instances, potential backdoors, usually unintentional, with closed source software packages occur. It comes down to trust in the software suppliers and their processes to validate security. Open source code is available for all to inspect. With open source, there is a chance for DOD code review.

Another common misconception is that commercial software vendors are more responsive to fixing identified security problems. No objective statistical evidence exists to prove that theory. There also is no legal requirement for any vendor to develop fixes for DOD. In fact, dozens of outstanding security issues exist with several major software vendors’ products. The end user license agreements (EULA) of most DOD software state that vendors are under no obligation to fix the software, and in many cases, they have not. One commercial software vendor had a security hole in its intercept communications that took months to patch.

A bug in OpenSSL was found, fixed and the fix released within days. That type of responsiveness is required to support the warfighter. Many DOD-identified security problems with open source software are corrected in the same time frame or faster than commercial software. Because the code is open, security experts can inspect it to verify the fix. The government, as a software user, also can contribute to the development of that software by detecting and even correcting vulnerabilities.

Several large companies whose software is in heavy use in DOD advocate a shared source code model in which people can view the source code but not change it. This shared source code approach has some problems, though. By sharing source code with organizations, the users have the ability to find flaws in the software. However, because they are not able to fix code security flaws, unscrupulous organizations may use access to source code to develop software that exploits the bugs. This shared source code approach potentially contributes to the rise in zero-day exploits in a number of commercial products. The best approach for truly secure systems is transparency—release the software as open source because security by obscurity rarely works well.

Concern exists that open source code development in nations not necessarily friendly to the United States could make command and control systems vulnerable to future attack. However, most commercial software used in DOD and the intelligence community is partially or completely developed overseas. Five major software companies have software development operations in Russia, India, Israel and China. The U.S. government cannot sue these companies because of security problems as a result of the EULAs. People have tried and failed because they accepted the agreement when they used the software. DOD does not inspect every line of code in every software program it uses, and leadership accepts some risk. Because open source code is transparent, issues are quickly discovered and corrected by the community. No software system is perfectly secure, and all have vulnerabilities, making a security-in-depth architecture critical. The right mind-set is to assume that all software might have back doors, intentional or unintentional, and to build a security architecture that can detect, mitigate and counteract such attack vectors.

Another open source misconception is that it is harder to have the software accredited. Open source software was approved for use within DOD in 2003 as long as it meets the security and validation requirements in National Security Telecommunications and Information Systems Security Policy Number 11 and other DOD configuration guidelines just the same as commercial software. The main accreditation system for products that have information assurance capabilities is Common Criteria (ISO/IEC 15408:2005). In the United States, the National Information Assurance Partnership is responsible for Common Criteria evaluations. One challenge for the open source community and most small business software vendors is the extremely high cost of having a product Common Criteria evaluated. This high cost of entry actually lowers the government’s security posture by reducing the number of vendors and solutions that can be used by government customers.

The costly Common Criteria evaluation process continues to be a significant ongoing issue for open source software. Fortunately, due in part to commercial partnerships, several critical open source software products have evaluations completed. A recent success story was the FIPS-140(2) certification of OpenSSL achieved by the Open Source Software Institute and its consortium.

When commercial companies deem certification of open source software is in their best interest, they often pay for Common Criteria Certification evaluations. Examples are Red Hat and SUSE Linux operating systems, which have achieved Common Criteria evaluation at Evaluation Assurance Level 4 and are authorized for use on all DOD and intelligence community networks, as well as OpenSSL. Other widely used open source software is available with no evaluations planned, including PostgreSQL and Apache Hypertext Transfer Protocol Server. Hopefully the trend for industry to obtain the evaluations will continue, but for some open source software, the government may need to fund evaluations where considered critical.

A MITRE study for the Defense Information Systems Agency on the use of free and open source software in DOD discovered 115 open source software applications being used in more than 250 settings. The Navy Fleet Numerical Meteorology and Oceanography Center (FNMOC) was one of those organizations. FNMOC runs the only Navy operational nonresearch supercomputer. Its mission is to provide around-the-clock weather/ocean products for DOD. FNMOC has used open source software operationally for 10 years. The organization cut costs significantly and has not experienced any major security problems. An important safeguard is to download from authoritative sources and check the cryptographic signatures on all packages. Their front end e-business suite runs on a 230-node IBM Cluster under Red Hat Enterprise Linux, and their front-end Web tier is based on the JBoss-Tomcat application server with Apache Hypertext Transfer Protocol Server. They use PostgreSQL because the performance is on par with commercial software but with significant cost savings. Recently, their high-performance computing group moved from proprietary symmetric multiprocessing operating systems to Linux. This speaks to the maturity of open source software.

Additionally, FNMOC has a Navy Cooperative Research and Development Agreement with the Open Source Software Institute to “identify, document and facilitate the transition of open source solutions into selected naval enterprise architecture environments and Web services programs.”

As DOD engineers and acquisition professionals move forward in developing and procuring future networks, open source software should be a key consideration. Understanding common misperceptions about its risks and benefits is imperative.

Cmdr. Danelle Barrett, USN, is a navy information professional officer, Standing Joint Force Headquarters, U.S. Pacific Command; Boyd Fletcher is lead engineer, Cross Domain Collaborative Information Environment, U.S. Joint Forces Command Joint Innovation and Experimentation Directorate (J-9); and Dave Huff is chief engineer at Fleet Numerical Meteorology and Oceanography Center.

Also contributing to the article: John Lever, director for information architecture governance, Naval Meteorology and Oceanography Command; John Scott, RadiantBlue Technologies Incorporated, and one of the authors of open technology development in the U.S. Defense Department; and Dr. Scott Starsman, chief engineer, Defense Systems Division, Avineon Incorporated.