Security Comparisons of Open Source and Closed Source Programs Katherine Wright

1. Security Comparisons of Open Source and Closed Source ProgramsKatherine Wright

2. Introduction • What is open source • Why is open source potentially more secure • Why is closed source potentially more secure • Payne's studies • Ransbotham's studies

3. What is an open source program? A development methodology in which the source code is available to anyone to read and modify, from the inception of the project through its lifecycle Also includes licensing the work so that it can be used in other projects and so that derivative works can be created

4. Open Source and Free Software Open source – works should be made available to the public Free software – “The word "free" in our name does not refer to price; it refers to freedom. First, the freedom to copy a program and redistribute it to your neighbors, so that they can use it as well as you. Second, the freedom to change a program, so that you can control it instead of it controlling you; for this, the source code must be made available to you.” Richard Stallman Free as in beer (“gratis”) vs free as in speech (“libre”)

5. Why Open Source: Peer Review Largest stated reason for open source If everyone can see source code, no one can sneak in • Backdoors • Trojans Use peer review process to guarantee security and stability of algorithms

6. Peer Review Users submit bug reports Sometimes patch bugs Have the ability to verify security of algorithms and code

7. Why Open Source: Version Control Large open source projects usually have good version control Ability to roll back easily if malicious changes made Linux-like projects: Can only submit patches, which are verified

8. Why Open Source: In-house modifications Security critical entities can more easily verify that software is not malicious Less secure software can be modified to meet security needs If vulnerability is discovered, patches can be rolled out without waiting on a central entity

9. SE Linux Developed by NSA and others, released in 2003 Can be applied to UNIX-like kernels (Linux, BSD among others) Implements MAC Ability to provide a more secure OS, without requiring development

10. Why Closed Source: Security through Obscurity Security through obscurity – If nobody knows that a vulnerability exists, they won't take advantage of it. Probably. Source code – easy to read, well-commented Binaries – require reverse engineering, cryptic Defenders vs Attackers Ransbotham study indicates shorter turn-around on exploits for open source projects

11. Why Open Source: Security through Obscurity fails Can't rely on vulnerabilities to remain hidden Attackers can exploit development servers, fuzz input, reverse engineer binaries, etc. Security through obscurity not enough on its own. Somebody will find out.

12. Why Closed Source: Few reviewers Average open source project, likely not reviewed, likely not secure Even well-maintained projects often adopted before thorough review But can give false sense of security

13. Why Closed Source: Amateurs vs Professionals May be many eyes, but how many qualified Open source projects often free, not-for-profit Hard to attract talented individuals Microsoft, IBM, large corporations can have dedicated security teams

14. Why Closed Source: Open Source Amateurs Most open source projects need programmers No quality control on contributors Don't necessarily know how to protect against common vulnerabilities

15. Why Closed Source: Patching When patches released, user must be notified, download new version Derivative works must be patched Can have significant delay Closed source tends to have better patch pushing methods/fewer derivative works

16. Why Closed Source: Certification Software packages must be certified by the federal government before can be used No open source packages have passed (Maybe SELinux?)

17. Payne Study Done in 1999 Examined Solaris, Debian GNU/Linux and OpenBSD Compared CIA vulnerabilities and features

18. Payne Study cont Debian Solaris OpenBSD Features Average 6.42 5.92 7.03 Vulnerabilities Average 7.72 7.74 4.19 Unscaled Score −1.30 −1.80 2.80 Scaling Factor 1.25 0.52 3.60 Final Score −1.0 −3.5 10.2

19. Ransbotham Study Analyzed real vulnerability and exploit report data for closed source and open source programs Uses a lot of arcane statistics Statistics indicate that open source projects more likely to be exploited, and exploits happen earlier

20. Ransbotham Study cont Open source projects – 3,369 (26%), Closed source – 3,121 (23%), Unknown – 6,611 (51%) Open Source Closed Source Variable Value Count Percentage Count Percentage Exploited No 329 91.64% 457 87.21% Yes 30 8.36% 67 12.79% Complexity Low 187 52.09% 245 46.76% Medium 131 36.49% 225 42.94% High 41 11.42% 54 10.31%

21. Conclusions/Questions http://www.youtube.com/watch?v=9sJUDx7iEJw

22. Bibliography Hoepman, Jaap-Henk and Bart Jacobs. (2007), Communications of the ACM, 50: 79-83. <http://cacm.acm.org/magazines/2007/1/5754-increased-security-through-open-source/fulltext> Payne, C. (2002), On the security of open source software. Information Systems Journal, 12: 61–78. doi: 10.1046/j.1365-2575.2002.00118.x <http://onlinelibrary.wiley.com/doi/10.1046/j.1365-2575.2002.00118.x/full> Ransbotham, Sam. (2010), An Empirical Analysis of Exploitation Attempts based on Vulnerabilities in Open Source Software. <http://weis2010.econinfosec.org/papers/session6/weis2010_ransbotham.pdf> Wheeler, David. Is Open Source Good for Security? <http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/open-source-security.html>