Open Source Software (OSS/FLOSS) and Security
•Download as ODP, PDF•
3 likes•2,301 views
This document discusses open source software (OSS) and security. It defines OSS and outlines some of its typical development models and security advantages compared to proprietary software, such as mass peer review improving quality and security. It notes that neither OSS nor proprietary software is always more secure and that each case needs to be evaluated individually. The document provides statistics showing OSS has scored better than proprietary software on some security metrics. It discusses how to evaluate OSS for security and considers both unintentional and intentional vulnerabilities.
![Outline ,[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (19)
Similar to Open Source Software (OSS/FLOSS) and Security
Similar to Open Source Software (OSS/FLOSS) and Security (20)
More from Joshua L. Davis
More from Joshua L. Davis (20)
Recently uploaded
Recently uploaded (20)
Open Source Software (OSS/FLOSS) and Security
- 1. Open Source Software (OSS/FLOSS) and Security MIL-OSS Dr. David A. Wheeler August 3, 2010 This presentation contains the views of the author and does not indicate endorsement by IDA, the U.S. government, or the U.S. Department of Defense.
- 3. Typical OSS development model
- 4. Security: Extreme claims on OSS
- 6. Open design: A security fundamental
- 7. Proprietary advantages… not necessarily
- 8. FLOSS security preconditions (unintentional)
- 10. Open proofs – using OSS to mature research
- 12. to study and modify the program, and
- 14. Antonyms: proprietary software, closed software
- 16. Mass peer review typically greatly increases quality/security
- 24. IBM reports invested $1B in 2001, made it back in 2002
- 26. Models: Sell service/hw, commoditize complements, avoid costs, ...
- 27. Users use commercial off-the-shelf (COTS) because they share maintenance costs – OSS does!
- 29. OSS users typically pay for training & support (competed)
- 30. OSS users are responsible for paying/developing new improvements & any evaluations that they need; often cooperate with others to do so
- 31. Goal: Active development community (like a consortium) Trusted Repository Distributor User Source Code Bug Reports Improvements (as source code) and evaluation results: User as Developer “ Stone soup development” Development Community
- 36. Survey of 6,344 software development managers April 2005 favored FLOSS [BZ Research]
- 37. IE 21x more likely to get spyware than Firefox [U of Wash.]
- 38. Faster response: Firefox 37 days, Windows 134.5 days
- 39. Browser “unsafe” days in 2004: 98% Internet Explorer, 15% Mozilla/Firefox (half of Firefox’s MacOS-only)
- 40. Windows websites more vulnerable in practice 17% (GNU/Linux) 66% (Windows) Defaced 66.75% (Apache) 24.81% (IIS) Deployed websites (by name) 29.6% (GNU/Linux) 49.6% (Windows) Deployed Systems FLOSS Proprietary Category
- 42. FLOSS: Slackware Linux 9%, GNU utilities 6%
- 44. Linux kernel TCP/IP had smaller defect density [Reasoning]
- 46. ... limit DoD access to—and overall expertise in—the use of powerful FOSS analysis and detection applications that hostile groups could use to help stage cyberattacks.
- 47. ... remove the demonstrated ability of FOSS applications to be updated rapidly in response to new types of cyberattack . Taken together, these factors imply that banning FOSS would have immediate, broad, and strongly negative impacts on the ability of many sensitive and security-focused DoD groups to defend against cyberattacks.” - Use of Free and Open Source Software in the US Dept. of Defense (MITRE, sponsored by DISA), Jan. 2, 2003 “ In cyberspace, coding is maneuver ” - Jim Stogdill; see http://www.slideshare.net/jstogdill/coding-is-maneuver
- 52. Vincent Rijmen (AES): “forces people to write more clear code & adhere to standards”
- 53. Whitfield Diffie: “it’s simply unrealistic to depend on secrecy for security”
- 55. Source can be regenerated by disassemblers & decompilers sufficiently to search for vulnerabilities
- 56. Secrecy inhibits helpers, while not preventing attackers
- 59. Brief secrecy works (10-30 days), not months/years
- 70. If already deployed, need to deploy fix
- 75. Users' increased transparency -> examination & feedback
- 78. Process for reporting security vulnerabilities?
- 79. Cryptographic signatures for current release?
- 80. Developer mailing lists discuss security issues and work to keep the program secure?
- 84. Trick is to get result into user supply chain
- 85. In FLOSS, requires subverting/misleading the trusted developers or trusted repository/distribution…
- 87. Distributed source aids detection
- 89. Consider supplier as you would proprietary software
- 90. Risk larger for small FLOSS projects
- 94. Hidden for 7 years in proprietary product
- 95. Found after release as FLOSS in 5 months
- 96. Unclear if malicious, but has its form
- 99. OSS slight advantage: More likely to know who developers are
- 102. Evidence of hardened repository
- 105. "From the publications alone, without access to the source code, various details were still unclear... what we did not realize, and which hardly could be deduced from the literature, was [an optimization] employed in GRASP and CHAFF [was critically important]... Only [when CHAFF's source code became available did] our unfortunate design decision became clear... important details are often omitted in publications and can only be extracted from source code... making source code ... available is as important to the advancement of the field as publications” [Biere, “The Evolution from LIMMAT to NANOSAT”, Apr 2004]
- 109. Backup slides
- 110. Securing Open Source Software (OSS/FLOSS) MIL-OSS Dr. David A. Wheeler August 3, 2010 This presentation contains the views of the author and does not indicate endorsement by IDA, the U.S. government, or the U.S. Department of Defense.
- 112. Build (new) secure OSS component
- 119. Typically embedded in OS or low-level libraries
- 120. Examples: StackGuard, Exec-Shield, MALLOC_CHECK_
- 121. Encourage development of these!
- 125. Don’t forget physical & personnel security
- 126. Security Controls: NIST 800-53, DODI 8500.2 (E4)
- 129. Review projects: OpenBSD, Debian Security Audit, ...
- 130. Tool vendors: Coverity (with DHS), Fortify, etc.
- 132. What’s project’s reputation? Why? Is it widely trusted?
- 134. OSS: Min. privileges, simplicity, carefully checks input
- 135. OSS: Scanning tools/peer review sample - no/few real problems
- 137. OSS: Is there an active community that reviews changes?
- 138. How are security vulnerabilities reported? Are they fixed?
- 143. Prefer implementation tools that prevent errors (vs. C,C++)
- 144. Turn on warning flags, use coding style that avoids mistakes
- 145. “ So simple it’s obviously right”; OSS: Embarrassment factor
- 147. Peer review. OSS: Mass peer review – enable it (e.g., common CM tools/languages/licenses; broad usefulness; incentives)
- 148. Develop & include automated regression test suite
- 152. Establish project website (mailing list, tracker, source)
- 153. Document scope, major decisions
- 154. Use typical infrastructure, tools, etc. (e.g., SCM)
- 155. Maximize portability, avoid proprietary langs/libraries
- 156. Must run - Small-but-running better than big-and-not
- 164. Find code written by people you don’t trust (via CM system)
- 166. Use their process; initial security discussions often private
- 169. OSS: Can independently maintain code: modify for specific needs and/or retain desirable functionality, even if original developer uninterested
- 173. Do risk/benefit analysis before proceeding
- 175. GPL incompatibility foolish (MPL, BSD-old)
- 176. Over 3/4 OSS projects use a top 10 license
- 177. "Do not write a new license if it is possible to use [an existing common one]... many different and incompatible licenses works to the detriment of OSS because fragments of one program can not be used in another...” - Bruce Perens
- 178. FLOSS License Slide: Determining License Compatibility Permissive Weakly Protective Strongly Protective See http://www.dwheeler.com/essays/floss-license-slide.html
- 182. Maximize future flexibility/reuse: Use GPL-compatible one!
- 184. $ savings/longevity/common library: Weakly protective ( LGPL)
- 193. To control just name/brand, use trademark (not copyright)
- 194. Backups
- 196. Read reviews
- 198. Support can be competed
- 199. Can be modified, redistributed
- 200. Outlay costs per improvement, not per seat
- 205. Anyone can review/comment on design
- 206. Anyone (inc. you) can evaluate source code for security
- 209. Forking usually fails; generally work with community
- 210. Comparing GOTS, COTS Proprietary, and COTS OSS
- 212. Policy noncompliance (FAR’s market research, “OSS neutral”)
- 213. Many PMs unfamiliar with OSS: don’t consider using or creating
- 214. Many OSS projects ignore solicitations & RFPs
- 219. If I copy your software.. you still have the software
- 223. Testing: opensourcetesting.org lists 275 tools Apr 2006, inc. Bugzilla (tracking), DejaGnu (framework), gcov (coverage), ...
- 224. Formal methods: Community Z tools (CZT) , ZETA, ProofPower, Overture, ACL2, Coq, E, Otter/MACE, PTTP, Isabelle, HOL4, HOL Light, Gandalf, Maude Sufficient Completeness Checker, KeY, RODIN, Hybrid Logics Model Checker, Spin, NuSMV 2, BLAST, Java PathFinder, SATABS, DiVinE, Splint (as LCLint), ...
- 225. Analysis implementation: Common LISP (GNU Common LISP (GCL), CMUCL, GNU CLISP), Scheme, Prolog (GNU Prolog, SWI-Prolog, Ciao Prolog, YAP), Maude, Standard ML, Haskell (GHC, Hugs), ...
- 227. Acronyms (1) BSD: Berkeley Software Distribution COTS: Commercial Off-the-Shelf (either proprietary or OSS) DFARS: Defense Federal Acquisition Regulation Supplement DISR: DoD Information Technology Standards and Profile Registry DoD: Department of Defense DoDD: DoD Directive DoDI: DoD Instruction EULA: End-User License Agreement FAR: Federal Acquisition Regulation FLOSS: Free-libre / Open Source Software FSF: Free Software Foundation (fsf.org) GNU: GNU’s not Unix GOTS: Government Off-The-Shelf (see COTS) GPL: GNU General Public License HP: Hewlett-Packard Corporation IPR: Intellectual Property Rights; use “Intellectual Rights” instead IT: Information Technology LGPL: GNU Lesser General Public License
- 228. Acronyms (2) MIT: Massachusetts Institute of Technology MPL: Mozilla Public License NDI: Non-developmental item (see COTS) OMB: Office of Management & Budget OSDL: Open Source Development Labs OSI: Open Source Initiative (opensource.org) OSJTF: Open Systems Joint Task Force OSS: Open Source Software PD: Public Domain PM: Program Manager RFP: Request for Proposal RH: Red Hat, Inc. ROI: Return on Investment STIG: Security Technical Implementation Guide TCO: Total Cost of Ownership U.S.: United States USC: U.S. Code V&V: Verification & Validation Trademarks belong to the trademark holder.
- 230. “ Use of Free and Open Source Software in the US Dept. of Defense” (MITRE, sponsored by DISA)
- 231. President's Information Technology Advisory Committee (PITAC) -- Panel on Open Source Software for High End Computing, October 2000
- 232. “ Open Source Software (OSS) in the DoD,” DoD memo signed by John P. Stenbit (DoD CIO), May 28, 2003
- 233. Center of Open Source and Government (EgovOS) http://www.egovos.org/
- 235. Open Source and Industry Alliance http://www.osaia.org
- 236. Open Source Initiative http://www.opensource.org
- 237. Free Software Foundation http://www.fsf.org
Editor's Notes
- “ SFU” is “Services for Unix”, nee Interix (the relationship is more complex; see their sites for more information). Parts of SFU are covered by the GPL (see “Customizing Microsoft Windows Services for UNIX Installation”). Microsoft has historically railed against the GPL, as being a license that will destroy the software industry, but this claim is obvious nonsense – it was at the same time selling GPL’ed software, and it is still competing with commercial companies whose products are based on GPL software (e.g., Linux kernel). Nowadays, Microsoft is actively courting OSS developers through Codeplex. The 37K/38K numbers for Linux are from 2004.
- Reliability Fuzz GNU/Linux Windows Crash Downtime TCP/IP Defect Defect density
- Username “politically” passowrd “correct” was a major Interbase backdoor, hidden for years when it was proprietary, and found quickly soon after it was releaesd as FLOSS. It’s not known if, or how widely, this was exploited before it was revealed.
- Note that CVE entries of similar / competing products may hint at problems in THIS component too. If one implementor makes a mistake, another implementor is much more likely to make the same mistake.
- The set of laws governing software are typically called “intellectual property rights” laws, but this term is very misleading. Knoweldge - including software - is really nothing like traditinoal property. If I take your car, you don’t have the car; but if I copy software, you still have the software. Using terms like “intellectual property rights” can make people unable to see what is different about software, and limits their thinking. I prefer the term “intellectual rights”, because now you can focus on the rights of each party, instead of simply who is the “owner”.