Security Comparisons of Security Comparisons of Open Source and Closed Open Source and Closed

Source ProgramsSource Programs

Katherine WrightKatherine Wright

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

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

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”)

Why Open Source: Peer Review

Largest stated reason for open sourceIf everyone can see source code, no

one can sneak in Backdoors Trojans

Use peer review process to guarantee security and stability of algorithms

Peer Review

Users submit bug reportsSometimes patch bugsHave the ability to verify security of

algorithms and code

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

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

SE Linux

Developed by NSA and others, released in 2003

Can be applied to UNIX-like kernels (Linux, BSD among others)

Implements MACAbility to provide a more secure OS,

without requiring development

Why Closed Source: Security through

ObscuritySecurity 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 AttackersRansbotham study indicates shorter turn-

around on exploits for open source projects

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.

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

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 individualsMicrosoft, IBM, large corporations can

have dedicated security teams

Why Closed Source: Open Source

AmateursMost open source projects need

programmersNo quality control on contributorsDon't necessarily know how to protect

against common vulnerabilities

Why Closed Source: Patching

When patches released, user must be notified, download new version

Derivative works must be patchedCan have significant delayClosed source tends to have better

patch pushing methods/fewer derivative works

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?)

Payne Study

Done in 1999Examined Solaris, Debian GNU/Linux

and OpenBSDCompared CIA vulnerabilities and

features

Payne Study cont

DebianSolaris 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

Ransbotham Study

Analyzed real vulnerability and exploit report data for closed source and open source programs

Uses a lot of arcane statisticsStatistics indicate that open source

projects more likely to be exploited, and exploits happen earlier

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%

Conclusions/Questions

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

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>