Open-source solutions for programmatic and operational challenges faced by defense and intelligence communities

  • By Adam Firestone
  • 12 Jan, 2014

A common misconception among non-technical communities is that open-source software (OSS) is similar to shareware. What do you have to say about this?

Open-source software is not shareware. The fear about shareware - and it’s been codified in US government information assurance regulations such as Department of Defense Instruction (DoDI) 8500.2, is that it creates an “abandoned binary” problem where there is either an extremely limited or no warranty and where the original source code is unavailable for review. In OSS, the source code is completely available for review, repair or extension. Later documentation, such as NIST Special Publication (SP) 800-53 rev 3, is much more clear on the issue.

What about the security risk aspect? Any comments?

A lot of people feel, without understanding what open source is, that it is a security risk because anyone can see or modify the code. This misconception was thoroughly debunked by Saltzer and Schroeder in their seminal 1975 paper on the open design principle The Protection of Information in Computer Systems. Security by obscurity is both obsolete and fatally flawed as a protective mechanism. The US Department of Defense (DoD) is aware of this misconception, and issued a policy guidance memo on 16 October 2009 endorsing the use of OSS.

There’s a lot of talk about cyber security. How can a government deal with such threats using OSS?

Perhaps the most difficult conceptual hurdle for government organizations to scale is that the “cyber” world and the “information assurance (IA)” world are really one and the same. We need to start addressing security both fundamentally - at the earliest stage of system requirements definition - and holistically - spanning the entire security spectrum from AAA (Authentication, Authorization and Auditing/Monitoring) to endpoint protection, malware detection, remediation and exploitation. All of these capabilities can be implemented using OSS.

Can you describe some significant advantages of OSS, particularly for defense and intelligence?

It’s really not that OSS is advantageous to the defense, intelligence and homeland security communities in particular so much as that OSS is advantageous to the enterprise in general. Unlike proprietary offerings, which generally have to be used “as-is,” OSS can be used, studied, and modified to suite the individual and independent needs of the organization, command or mission. The original or modified source code can also be redistributed without royalties to the original author, reducing Total Cost of Ownership (TCO). This combination - of being able to modify the software to meet the needs of the mission (as opposed to the current paradigm of modifying the mission to meet the limitations of the software) plus lower TCO is very powerful.

When compared with proprietary software, do you think OSS can be more beneficial to users?

The real key to OSS is product flexibility and programmatic productivity. However, it’s important to note that these advantages are only really gained if the government entity and its contractors work actively and collaboratively with the developer community. It’s a paradigm shift that’s all about communication.

How would you put this into perspective?

Have you heard about the InterBase story? Borland put out a database called InterBase a number of years ago. It was widely employed in commercial enterprises. After it had been sold for seven to eight years, Borland decided to open source the product. Within just five months of open sourcing, a back door was discovered. If the user name “politically” and the password “correct” were entered, you were in with administrator privileges! Seven years as proprietary software and nobody knew it was there, five months as OSS and it was figured out. This had everything to do with the open source adage that “given enough eyeballs, all problems are shallow.” Again, it’s a mindset more than a technology.

You mentioned that the US Department of Defense doesn’t prohibit the use of OSS in their systems. How would you justify this statement?

As I noted earlier, the US Department of Defense Chief Information Officer’s office put out a memorandum on 16 October 2009 that clearly declared OSS to be the equivalent of proprietary software, and something that should always be considered in solution development.

Could you describe some ‘myths’ about the use of OSS in government systems?

The technical community knows about OSS because they live it and breathe it. Unfortunately, we’ve done a tremendous disservice to acquisition professionals, and it’s important to provide them with accurate data so that they can more readily perform in their roles as stewards of the public trust and purse.

Firstly, many believe that OSS is not commercial software. This is not only untrue, there’s US Federal Law on the matter too! According to Title 41, Section 403 of the United States Code, OSS meets all the criteria to be categorized as a commercial product. It’s more useful to think of “commercial software” being split into two broad categories - OSS and proprietary software.

Another myth is that there is a conflict between the use of OSS and the DoD Information Assurance Policy. People tend to read the section of DoDI 8500.2 about how software products that have a limited or no warranty, such as those commonly known as freeware or shareware, are not to be used in DoD information systems. What they need to do is read the next paragraph that reads:

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

Clearly this doesn’t apply to OSS, because the source code is readily available!

In your opinion, what are some of the key IT challenges faced by the US government?

The top four that come to mind are:

  • The transformation and integration of legacy systems;
  • The integration of critical legacy data and data stores; there is a lot of old information that is mission critical, and it needs to be converted, integrated and/or transformed;
  • The integration of multiple, heterogeneous data sources; and
  • Addressing the multi-level/cross-compartment information sharing problem.

What is the problem with data integration mechanisms currently used by the DoD?

Integration of heterogeneous data sources from across the Department and the Intelligence Community (IC) is currently inefficient and isn’t done with an enterprise approach. As a result, the costs for just the US Army are staggering. The need for integration using modern, modular and loosely coupled approaches is clear.

How can OSS address these problems?

Rapid - and secure - information sharing across organization, classification and compartment borders is completely possible. The architecture leverages OSS from across the OSS community. We’re talking WSO2, Apache, etc. Products are integrated to address the problem in a cost and resource effective manner, which allows the multiple networks to be collapsed and minimizes the attack surface of those assets that need to be protected.

Can you tell us more about the Certification and Accreditation process?

Yes. But that would take volumes. The current post-production C&A model works well for hardware, but probably isn’t the most efficient for software.

Is there any solution that addresses this?

Yes, front-load the C&A process and place it back on the developers as they develop! Ensure that the only code that gets into the approved baseline is that which has passed security, functionality, interoperability, performance and certification testing. This can be accomplished with a DevOps PaaS - or, as I like to call it, a distributed, governed, Cloud-based IDE. WSO2 offers these capabilities in its WSO2 App Factory product. It’s a unique tool. It’s not the only one out there, and it’s certainly not the only open source option, but in my opinion, it is an extremely viable option.

About Author

  • Adam Firestone
  • Director
  • WSO2