This document provides an overview of open source solutions for defense and intelligence communities. It discusses how open source software can help address major IT challenges around legacy system integration, data integration, information sharing, certification and accreditation, and software verification. Open source is defined as commercial software and allowed under government policies. Common myths about open source being unsecure, unsupported, or not commercial are addressed. Case studies are presented on how open source can help with problems like system transformation and testing automation. Insider threats are identified as a key cybersecurity risk that open source may help mitigate.

1. Weapons Free!
Open Source Solutions to Programmatic and Operational Challenges
Faced by the Defense and Intelligence Communities in the Age of
Sequestration
Prepared for WSO2Con 2013
Prepared by
Adam Firestone
Director of Solutions
WSO2 Federal Systems, Inc.

2. Weapons Free
• Weapons Control Status
–
The three levels of weapons control status (WCS) outline the
conditions, based on target identification criteria, under which
friendly elements may engage. The commander sets and
adjusts the weapons control status based on friendly and
enemy disposition. In general, a more restrictive WCS relates
to a higher probability of fratricide. The three levels, in
descending order of restriction, are-●
●
●
WEAPONS HOLD (Engage only if engaged or ordered to
engage)
WEAPONS TIGHT (Engage only targets positively identified
as enemy)
WEAPONS FREE (Engage any targets not positively
identified as friendly)
• From US Army Field Manual 3-21.10

3. Agenda
• Legal and Policy Basis for
Government Use of Open
Source Software
• Open Source and the Big 5
Government IT Challenges
• Open Source Cybersecurity

5. It Isn’t Shareware.com!
• Many misconceptions about open
source software (OSS); a few
examples:
–
–
–
–
“It’s a security risk.”
“I need a commercial product. This
isn’t commercial!”
“It’s a threat to innovation!”
“The use of OSS is contrary to DoD
information assurance regulations.”

6. All in the Name of
Liberty
• OSS freedoms:
–
–
–
–
Run the software for any
purpose
Study the software
Modify the software
Freely redistribute copies
of the original or modified
software without royalties
to the original author

7. A Rose by Any Other
Name
• Synonyms
–
–
–
–
Free software
Libre software
Free and open source software
(FOSS)
Free-libre open source software
(FLOSS)
• Antonyms
–
–
Proprietary software
Closed software

8. Why SHOULD the
Government Use OSS?
• Lower risk
–
Possibility of detailed evaluation when
you have the source code
• Lower TCO
–
–
–
Freely distributable at no additional cost
Shared development costs
Freedom from vendor lock-in
• Fit for purpose
–
Can be modified for special purposes and
to counter attacks

9. Comparing GOTS,
Proprietary Software
and OSS
Support
Strategy
Cost
Flexibility
Risks
GOTS
High
High
Become obsolescent
(government bears all
costs & can’t afford
them)
Proprietary
Medium Low
*
Abandonment & *high
cost if monopoly
OSS
Low*
* Can be as costly as
GOTS if fail to
build/work with
developer community
High

10. DoD OSS Policy Memo
(16 OCT 2009)
a. In almost all cases, OSS meets the definition of “commercial
computer software” and shall be given appropriate statutory
preference in accordance with 10 USC 2377…
b. Executive agencies, including the DoD, are required to conduct
market research [which should] include OSS… There are
positive aspects of OSS that should be considered…
c. DoDI8500.2 control “DCPD-1 Public Domain Software Controls,”
doesn’t forbid the use of OSS
d. Ensure that the plan for software support (e.g., commercial or
Government program office support) is adequate for mission
need.
e. Government is not always obligated to distribute the source
code of any modified OSS to the public

11. DoD OSS Policy Memo
(16 OCT 2009)
e. Software source code and associated design documents
are “data”… and therefore shall be shared across the DoD
as widely as possible
f. Software items, including code fixes and enhancements,
developed for the Government should be released to the
public (such as under an open source license) when:
–
–
–
The project manager, program manager, or other comparable
official determines that it is in the Government’s interest to do
so, such as through the expectation of future enhancements
by others.
The Government has the rights to reproduce and release the
item, and to authorize others to do so.
The public release of the item is not restricted by other law or
regulation

13. Myth: OSS is not Commercial
Software
Reality: OSS is Commercial
• Nearly all OSS are commercial items
• U.S. Law (41 USC 403), FAR, & DFARS
–
Commercial item is:
●
(1) Any item, other than real property, that
is of a type customarily used by the general
public or by non-governmental entities for
purposes [not government-unique], and
–
–
–
(i) Has been sold, leased, or licensed to the
general public; or
(ii) Has been offered for sale, lease, or
license to the general public...
Intentionally broad; "enables the Government
to take greater advantage of the commercial
marketplace” [DoD AT&L]

14. Myth: OSS is not Commercial
Software
Reality: OSS is Commercial
• U.S. Law (41 USC 403), FAR, DFARS
require preference of commercial
items (inc. COTS) & NDI:
–
Agencies must
●
(a) Conduct market research to
determine [if] commercial items or
nondevelopmental items are
available …
●
(b) Acquire [them when available]
●
(c) Require prime contractors and
subcontractors at all tiers to
incorporate, to the maximum extent
practicable, [them] as

15. Myth: OSS Conflicts with DoD
IA Policy
Reality: DoD IA Policy
Supports OSS
• DoDI 8500.2 DCPD-1 "Public Domain Software Controls” is
often misinterpreted
–
–
People read THIS:
●
“Binary or machine executable ... software products and other
software products with limited or no warranty such as those
commonly known as freeware or shareware are not [to be] used
in DoD information systems ...”
But forget to read the SECOND PARAGRAPH
●
“[because they’re] 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.”
• Doesn’t apply to OSS! The source code is available!

16. Myth: Proprietary is Always More Secure
Reality: Open Design is a Security Advantage
• Saltzer & Schroeder [1974/1975] - Open
design principle
–
the protection mechanism must not depend on
attacker ignorance
• Security by obscurity doesn’t halt attacks;
thorough review makes code more secure
• BUT
–
–
–
OSS developers/reviewers need security
knowledge
The code must be reviewed
Problems must be fixed

17. Myth: Proprietary is Always More Secure
Reality: Open Design is a Security Advantage
• Borland InterBase/Firebird Back Door
–
–
–
–
user: politically, password: correct
Hidden for 7 years in proprietary
product
Found after release as OSS in 5 months
Unclear if malicious, but has its form

18. Myth: OSS is Unsupported
Reality: OSS is Commercially
Supported
• Businesses support OSS!
–
WSO2, Red Hat, Novell, HP, IBM,
DMSolutions, SourceLabs, OpenLogic,
Carahsoft, ...
• Average OSS developer 30yrs old,
11yrs experience
• OSS doe not mean no cost
–
–
Training, support, transition, etc. are
not free-of-cost
Competition often produces lower TCO
& higher ROI for OSS

19. Some US Government OSS
Policies
• OMB policy “Technology Neutrality” (2011-01-07)
–
–
“agencies should analyze alternatives that include…
open source”
Updates OMB-04-16 (2004-07-01) = OSS okay in
federal government
• DOD policy “Clarifying guidance regarding Open
Source Software (OSS)” + FAQ (2009-10-16)
–
–
Makes clear OSS can be used, counters
misconceptions
Updates May 2003 memo
• Consumer Financial Protection Bureau’s Source
Code Policy
–
–
–
Released 2012-04, reuses DoD 2009 policy
Two parts, “use of external OSS” & “Redistribution”
http://www.consumerfinance.gov/developers/sourcec
odepolicy/
• cendi.gov, e.g., “Frequently Asked Questions about
Copyright and Computer Software”
http://www.cendi.gov/publications/09-1FAQ_OpenSo

21. The Big 5
• Transformation and Integration of
Legacy Systems
• Integration and Exploitation of
Heterogeneous Data Sources
• Secure Multi-Level Information
Sharing
• Optimizing Certification and
Accreditation Activities
• Modernization and Automation of
Software Verification and Validation

22. Transformation
Comma
nd
Authorit
y
Routing
System
Targetin
g
System
Proprietary
Message
Format
Unstructure
d
U
S
A
T
S
Weapon
N
U
22
Proprietary
Message
Format
N
I
B
A
E
L
Plannin
g
System
Proprietary
Message
Format
Delivery
Platform
Proprietar
y
Message
Format

23. Transformation Solution
Concept
Collapse multiple components into a single,
distributed, service oriented system
Targ
etin
g
App
Rou
ting
App
Thr
eat
Anal
ysis
App
Miss
ion
Plan
ning
App
ISR
App
Task
ing
APP
Enterprise
Integration
Platform

24. Transformation Solution
Components
Enterprise Integration
Platform

25. Transformation Solution
Architecture

26. Integration of Heterogeneous
Data Sources
Consuming System, Service or Application
WSO2 Data Services Server
(“DAL in a Box”)
HTTP
HTTPS
JMS
SMTP
FTP
FTPS
SFTP
TCP
SQL
NoSQ
L
CS
V
OD
S
RD
F
We
b
Pag
e

27. Secure Multilevel Information
Sharing

28. Optimizing Certification and
Accreditation
Where C&A Fits in the Process Today
Dream
It
Plan It
Build It
Test It
Submit
to C&A
PANIC!
PANIC!
Receive
C&A
Results
Spend
Lots of
$ and
Time

29. Optimizing Certification and
Accreditation
Front End Loading C&A
Continuous
Continuous
Deployment
Deployment
Project and
Project and
Team
Team
Management
Management
Software
Software
development
workflow
workflow
Governance
Governance
and
and
Compliance
Compliance
Test
Test
Automation
Automation
Continuous
Integration
Integration
Development
Dashboards
Dashboards
Continuous
Continuous
Build
Build
Develop Code
Source Control
Source Control
Issue Tracking
Issue Tracking

30. Modernizing Verification and
Validation

31. Modernizing Verification and
Validation
Only the Audience Changes
Continuous
Continuous
Deployment
Deployment
Project and
Project and
Team
Team
Management
Management
Software
Software
development
workflow
workflow
Governance
Governance
and
and
Compliance
Compliance
Test
Test
Automation
Automation
Continuous
Integration
Integration
Development
Dashboards
Dashboards
Continuous
Continuous
Build
Build
Develop Code
Source Control
Source Control
Issue Tracking
Issue Tracking

33. It’s a Dangerous Cyber
World, Folks

34. The Most Dangerous
Threat is Still the Insider

35. Managing the Insider
Threat

36. A Quick Recap
• Open source is commercial software
and fully applicable to defense,
intelligence and other government
requirements
• Open source effectively responds to
today’s top government IT
challenges
• Open source can mitigate today’s
key cybersecurity threats

38. Contact
• Adam Firestone
–
–
–
–
Director of Solutions
WSO2 Federal Systems
703-879-5176
adam@wso2federal.com

39. Thank You