David A. Wheeler's Blog

Wed, 21 Dec 2011

U.S. Department of Defense Removes Open Source Software Roadblocks (AppDev STIG)

The U.S. Department of Defense (DoD) has changed one of its key software development documents, making it even clearer that it’s okay to use open source software (OSS) in the DoD. This is good news beyond the DoD; if the US DoD can widely accept OSS, then maybe other organizations (that you deal with) can too.

That key document has the long title “Application Security & Development (AppDev) Security Technical Implementation Guide (STIG),” aka the AppDev STIG.  The AppDev STIG includes some guidelines for how to write secure software, and a checklist for use before you can deploy custom software in certain cases. In the past, many people thought that using OSS in the DoD required special permission, because they misunderstood some of DoD’s policies, and this misunderstanding had crept into the AppDev STIG.  The good news is that this has been fixed.

Here’s the basic background.

Open source software (OSS) is software where anyone can read, modify, and redistribute the source code (its “blueprints”) in original or modified form.  OSS is widely used and developed in industry; some popular OSS includes the Linux kernel (the basis of Google’s Android), the Firefox web browser, and Apache (the world’s most popular web server).  You can get quantitative numbers about OSS at http://www.dwheeler.com/oss_fs_why.html.  There is a lot of high-quality OSS, and OSS is often very inexpensive even when you include installation, training, and so on.

Unfortunately, previous versions of the AppDev STIG were often interpreted as saying that using OSS required special permission.  This document matters; DoD Directive (DoDD) 8500.01E requires that “all IA and IA-enabled IT products incorporated into DoD information systems shall be configured in accordance with DoD-approved security configuration guidelines” and tasks DISA to develop the STIGs.  It’s often difficult to get systems fielded unless they meet the STIGs.

AppDev STIG version 3 revision 1 (an older version) said:

(APP2090.1: CAT II) “The Program Manager will obtain DAA acceptance of risk for all open source, public domain, shareware, freeware, and other software products/libraries with no warranty and no source code review capability, but are required for mission accomplishment.”

(APP2090.2: CAT II): “The Designer will document for DAA approval all open source, public domain, shareware, freeware, and other software products/libraries with limited or no warranty, but are required for mission accomplishment.”

Many people interpreted this as saying that any use of OSS required special permission.  But where would the Defense Information Systems Agency (DISA), the author of the AppDev STIG, get that idea?  Well, it turns out that this is a common misunderstanding of DoD policy.  DoD Instruction 8500.2, February 6, 2003 has a control called “DCPD-1 Public Domain Software Controls” (http://www.dtic.mil/whs/directives/corres/pdf/850002p.pdf), which starts with this text:

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.

A lot of people stopped reading there; they saw that “freeware” required special permission, and since OSS can often be downloaded for free, they presumed that all OSS was “freeware.”  They should have kept reading, because it then goes on to make it clear that OSS is not freeware:

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…

This latter part makes it clear that software only requires special treatment if the government cannot review, repair, or extend the software.  If the government can do these things, there’s no problem, and by definition OSS provides these rights.  But a lot of people didn’t understand this.

This was such a common misunderstanding that in October 2009, the DoD CIO’s memo “Clarifying Guidance Regarding Open Source Software (OSS)” specifically stated (in Attachment 2, 2c) that this was a misunderstanding (http://dodcio.defense.gov/sites/oss/2009OSS.pdf).  The DoD CIO later instructed DISA to update the AppDev STIG so this misunderstanding would be removed.

The latest AppDev STIG (Version 3, Release 4) has just fixed this (http://iase.disa.mil/stigs/app_security/app_sec/app_sec.html).  The new STIG:

  1. Refers to the DoD OSS policy of 2009, instead of the old one.
  2. Has better definitions for software types, including “OSS” and “commercial software”.  Its old definitions caused problems for OSS use; the “commercial software” definition was even inconsistent with US law, the Federal Acquisition Regulation (FAR), and the DoD FAR Supplement (DFARS).  In particular, it makes it clear that most OSS is commercial software as defined by law and regulation.
  3. Makes it clear that special DAA approval is ONLY required if BOTH of the following are true:  “(1) no source code to review, repair, and extend, and (2) limited or no warranty, but are required for mission accomplishment.”  See checklist items (APP2090.1: CAT II) and (APP2090.2: CAT II).  This is the big change.

Two related points:

  1. Sadly, the AppDev STIG latest revision has a formatting glitch; all second-level headings aren’t numbered in the body, with the result that the table-of-contents numbers don’t match the body.  Still, it has the updated technical content, and future versions will presumably fix the formatting.
  2. The wording of DoDI 8500.2’s DCPD-1 has been confusing people for years (I hear that at least parts of NASA have also used this text, inheriting the same confusion).  In the short term, the DoD CIO’s formal clarification should help.  In the longer term, there is an effort to switch the DoD to a single set of federal information assurance controls defined in NIST Special Publication 800-53.  Its equivalent control, SA-6(1), has much clearer text.

But the editorial gaff in the AppDev STIG, and the work on improving the wording of controls long term, shouldn’t detract from the main point.

The main point is:

Open Source Software (OSS) is now much easier to use in the DoD.

path: /oss | Current Weblog | permanent link to this entry