Institute for Defense Analyses. Open Source Software in Government: Challenges and Opportunities David A. Wheeler (IDA) & Tom Dunn (GTRI)

Transcription

1 Institute for Defense Analyses Open Source Software in Government: Challenges and Opportunities David A. Wheeler (IDA) & Tom Dunn (GTRI)

2 Outline Introduction Inertia Fears about low quality or malware Concerns about commercial support and warranties Procurement Certification & Accreditation Standards / Interoperability Challenges to the release of code from government Need for guidance Need for education 2

3 Introduction Homeland Open Security Technology (HOST) is a DHS project, focusing on: Discovery Collaboration Investment GTRI and IDA conducted interviews to identify impediments, lessons learned, & recommendations on open source software (OSS) in government We talked with OSS experts, OSS suppliers, and OSS consumers (contractors/integrators and government employees) Categories created from what interviewees said (not pre-created set) Presentation is a subset of the paper Formerly titled Lessons Learned 3 HOST info at:

4 Inertia Fear of change We haven t done it that way before High transition costs inhibit switching to anything else Lack of government software expertise Ignore / don t know current policies Policies are used as weapons in office politics 4

5 Fears about low quality or malware There is a concern over the ease of getting malware into OSS. Actually, it s pretty easy to get malware into proprietary software too. [OSS is unique in that it gives complete visibility into the supply chain.] Just because you cannot [review] the source [of proprietary software] does not mean the software is safe... I would rather know where it came from so I know what to target in my evaluation. 5

6 Concerns about commercial support and warranties perception that [OSS] will not have any support or anyone to call Often not hard to find someone to support OSS, but it is not as easy as with commercial [proprietary] software that comes with support built in. Having people understand the business model is the problem. 6

7 Procurement Wrong incentives within government and contractors Government program offices are dis-incentivized to reuse and collaboratively develop software Reduced government headcount threatens people s status & rank Contractors do not want to share with each other they see that as a detriment, it affects follow-on contract likelihood. When developing new, a contractor can charge a whole lot more what s the incentive to buy or reuse stuff? Difficult to sustain investment in infrastructure or OSS Acquisition process mismatches typical OSS business model Many OSS companies give away software, sell support Procurement paperwork impedes small businesses the government artificially inflates the cost of software, with unnecessary flaming hoops to jump through & The [government] paperwork burden is obscene 7

8 Procurement (2) OSS does not cost enough we tend to throw out [the] most expensive and least expensive and only deal with folks in the middle, ignoring lower-priced approaches a cultural thing of you get what you pay for. If you aren t spending millions of dollars [others believe] you aren t being serious about the problem. Concerns about GNU General Public License (GPL) Requirements inflexibility Section 508 accessibility Trouble keeping up with COTS/OSS development speed The OSS development model is based on a very fast, evolutionary cycle... In government additional requirements require [extended review] Solution: Require in contracts that contractors share & provide full rights in software they develop Solution: Release government-funded software as OSS by default 8

9 Certification & Accreditation (C&A) Some like the clear, specific requirements of government security requirement specifications Government security specifications inflexible even one tiny, little thing can block [a program s] adoption [widely-used and commercially accepted software] may lack something required by government policy, such as DoD Common Access Card (CAC) card support, X.509 support, or FIPS validation you may need to purchase a [proprietary] clone just to comply with policy even if the alternative doesn t add any value in its situation Accrediting Authorities should do risk management, not delegate to processes Need to share/co-develop C&A and Authority to Operate (ATO) information C&A cost barriers to entry Include OSS projects when creating specifications 9

10 Standards / Interoperability Standards can enable competition The de facto standard becomes one particular vendor. [I recommend that government, both federal and not,] adopt as many standards as possible [and] become vendor agnostic. Then OSS can conform to the standard, and it puts them in the game Open standards simplify integration Anything standards compliant easily federates; [a product that] uses all open standards is easier to integrate. Important government role [A] great role the government can play is [in] setting standards. They can hire people who know security very well, and run a committee for a long time to create a good standard. 10

11 Challenges to release of code from government Fear that a release obligates the government to support it or use its derivatives Attribution of government employees sometimes considered unacceptable Export control and other policies make contributing to the public too slow Government creates too many project forks Difficult to release government code even within government Need a default-open government forge not just a depository 11

12 Need for guidance Need guidance on evaluating and selecting OSS Need guidance for contributing back to OSS community Need guidance about releasing government-funded OSS 12

13 Need for education General OSS education In terms of [OSS] use, the barriers are most typically education. People have a lack of information. Intellectual rights and OSS license education There is an utter lack of knowledge on copyright. [OSS] licensing is an issue because people don t understand it Procurement education One OSS supplier was forced to become an expert in procurement, security, [the supplier is] educating the Contracting Office & COTR Certification & Accreditation (C&A) education Nobody understands the C&A process. FISMA is all about teaching the customer. [e.g., teaching them] the difference between certification and accreditation is crucial. 13 Widespread comments about the need for education

14 Conclusions To maximally use its limited resources, the U.S. government must address these challenges to reduce the unnecessary barriers to the use and development of OSS Education/guidance Increased transparency / openness Many interviewees stressed requiring software and C&A materials developed with government funding be maximally: shared and developed collaboratively provide full data rights to the government (unless it can be justified that fewer rights benefit the government as a whole) release such software as OSS by default 14

15 Questions? If you want the report when it comes out, hq.dhs.gov (HOST address) Author contacts: Tom Dunn Georgia Tech Research Institute (GTRI) (757) gtri. gatech. edu Dr. David A. Wheeler Institute for Defense Analyses (IDA) (703) ida. org 15

16 Backups 16

17 Potential Investments Secure, Certified Software Stacks with Government "Seal of Approval OSS Authentication modules Biometrics OSS Identity management Windows SSH Client with full CAC support (OpenSSH/PuTTY CAC) Secure Government Dropbox curl FIPS crypto Full S/MIME Stack with Web-Mail OSS full disk encryption with HSPD- 12 Support Government Operating System Distribution Android, esp. security capabilities Enterprise App Store Digital Forensics Hosting resources Summer of C&A / Release C&A/ FISMA documentation as OSS Tournament Labs Joint Government/Industry Consortium Add OSS to DAU Curriculum OSS Information Assurance Tools Static Code Analysis Fuzzers 17 Database of curated bugs

18 History of presentation This presentation is an update to the previous presentation HOST Lessons Learned Given at MIL-OSS, Document was previously titled Lessons Learned 18