securing open source software advantages and challenges n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Securing Open Source Software: Advantages and Challenges PowerPoint Presentation
Download Presentation
Securing Open Source Software: Advantages and Challenges

Loading in 2 Seconds...

play fullscreen
1 / 23

Securing Open Source Software: Advantages and Challenges - PowerPoint PPT Presentation


  • 81 Views
  • Uploaded on

Securing Open Source Software: Advantages and Challenges. Mitch Stoltz Head Security Engineer Netscape Client Products Division. Open Questions. Is Open Source software more secure? What are the security advantages of the open source model? What are the disadvantages?

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Securing Open Source Software: Advantages and Challenges' - nituna


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
securing open source software advantages and challenges

Securing Open Source Software: Advantages and Challenges

Mitch Stoltz

Head Security Engineer

Netscape Client Products Division

open questions
Open Questions
  • Is Open Source software more secure?
  • What are the security advantages of the open source model?
  • What are the disadvantages?
  • How can those disadvantages be overcome?
the promise of open source
The Promise of Open Source

“Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.

Or, less formally, ‘Given enough eyeballs, all bugs are shallow.’ I dub this: ‘Linus's Law.’”

- Eric Raymond,

“The Cathedral and the Bazaar”

the promise of open source1
The Promise of Open Source
  • No organizational bottleneck in the original developer
    • Anyone can download and test
    • Less communication necessary
    • Development, testing/verification, and maintenance can be done by different organizations
the promise of open source2
The Promise of Open Source
  • Independent verification means not having to trust manufacturers’ claims

What is impossible to prove is that proprietary software is more secure than free, without the public and open inspection of the scientific community and users in general. This demonstration is impossible because the model of proprietary software itself prevents this analysis, so that any guarantee of security is based only on promises of good intentions (biased, by any reckoning) made by the producer itself, or its contractors. -Edgar David Villanueva Nunez, Congressman, Peru

the promise of open source3
The Promise of Open Source
  • Popularity among academics and students increases the pool of knowledgeable reviewers
  • Potential for very fast turnaround time for security fixes
opposing views
Opposing Views

Inherently, the closed nature of proprietary software is its first line of defense regarding security issues…

Opening the code to potential attackers provides a free education…

-Kenneth Brown, Alexis de Tocqueville Institution

People unfamiliar with the open source model are accustomed to keeping their source secret. When their source does become public, it's almost always related to a security breach or the threat of a security breach.

-Michael Warfield, LinuxWorld

opposing views1
Opposing Views
  • Open source gives a short-term advantage to attackers
    • Attackers can find and exploit flaws before most users can find out about the problem and apply a fix
  • Security breaches bring negative publicity to a company - there’s an incentive to conceal information about flaws
misconceptions
Misconceptions
  • Too little control over what code goes into a project
    • “If anyone can contribute, how can we trust the result?”

The GPL does not require `patches to wander in', a big part of the freedom inherent in it is that the impacted agency has the power to fix a problem, on the spot, and share the fix at essentially no cost with other impacted agencies. Trying to do that with proprietary software is generally illegal. -Leon Brooks

misconceptions1
Misconceptions
  • Code that is kept secret is inherently safer
    • Kerchoffs’ Principle: The security of an algorithm should depend only on the key
    • Corollary: Minimize the number of secrets that must be kept to maintain security

Public algorithms are designed to be secure even though they are public; that's how they're made. So there's no risk in making them public. -Bruce Schneier, Crypto-Gram

misconceptions2
Misconceptions
  • But secrecy is not necessarily unsafe…

Minimize the number of secrets in your security system. To the extent that you can accomplish that, you increase the robustness of your security. To the extent you can't, you increase its fragility. Obscuring system details is a separate decision from making your system secure regardless of publication; it depends on the availability of a community that can evaluate those details and the relative communities of "good guys" and "bad guys" that can make use of those details to secure other systems. -Bruce Schneier, Crypto-Gram

misconceptions3
Misconceptions
  • Open source software is inherently safer
    • Source availability is no guarantee of effective review
    • Few open source contributors know how to look for security flaws in code

simply publishing the code does not automatically mean that people will examine it for security flaws. Security researchers are fickle and busy people. They do not have the time to examine every piece of source code that is published. So while opening up source code is a good thing, it is not a guarantee of security… -Bruce Schneier

re framing the question
Re-Framing the Question

“Is open source code more secure than proprietary code?”

re framing the question1
Re-Framing the Question

“Is open source code more secure than proprietary code?”

This is the wrong question.

re framing the question2
Re-Framing the Question

New Questions:

  • What are the requirements for building and deploying secure software?
  • What aspects of open source development make these requirements easier or harder?
  • What can we do to help the open source model deliver on its promise of security?
challenges solutions
Challenges & Solutions
  • Challenge: Responsible Disclosure
    • Early disclosure can lead to increased attacks
    • but people have a right to know the risks of the software they use

Those advocating secrecy are right that full disclosure causes damage, in some cases more damage than good. They are also right that those who build attack tools should be held liable for their actions; the defense of "I just built the bomb; I didn't place it or set the fuse" rings hollow. But they are wrong to think they can enforce secrecy. Information naturally disseminates, and strategies that go against that are doomed. -Bruce Schneier

challenges solutions1
Challenges & Solutions
  • Challenge: Responsible Disclosure
    • Companies conceal vulnerabilities and are slow to provide fixes
    • but some “security researchers” disclose vulnerabilities for personal publicity

Someone who releases a harmful program through a press release has a different agenda than to help you. -Bruce Schneier

A large portion of security experts go home at night and write tools for the script kiddies. -Marcus Ranum

challenges solutions2
Challenges & Solutions
  • Solution: Limited Initial Disclosure (A Compromise)
    • Limit technical description of vulnerabilities to a group of experts and stakeholders until bug is fixed
    • Low barrier to entry in the group
    • Reporter, group members keep things honest
    • Full disclosure after fix is distributed
challenges solutions3
Challenges & Solutions
  • Challenge: Lack of Qualified Reviewers
    • Security problems are subtle and often missed even by expert programmers
  • Solution: Finding, Training, and Incentivizing Bug Hunters
    • Training Reviewers to spot problems
    • Netscape Bug Bounty Program
challenges solutions4
Challenges & Solutions
  • Challenge: Automating & Systematizing Security Review
    • repeated mistakes
    • no feedback to developers
  • Solution: Tight Feedback Loops
    • Integrate security scanners into build feedback
    • Review past problems and integrate findings into future security evaluations
challenges solutions5
Challenges & Solutions
  • Challenge: Developer Education
  • Solution: Identify Common Mistakes & Teach Best Practices
    • We need new, innovative forms of developer education
key sources
Key Sources
  • “The Cathedral and the Bazaar,” Eric Raymond
    • http://www.tuxedo.org/~esr/writings/cathedral-bazaar
  • “Crypto-Gram,” Bruce Schneier, Sep. 1999, Jan. 2000, Feb. 2000, Sep. 2000, May 2002
    • http://www.counterpane.com/crypto-gram.html
  • “Opening the Open Source Debate,” Kenneth Brown
    • available at http://www.adti.net
  • “Dispelling Myths about the GPL and Free Software,” John Viega and Bob Fleck
    • http://www.cpi.seas.gwu.edu/oss/cpi_rebuttal.pdf
  • “Why Open Source? Look at the Numbers!” David Wheeler
    • http://www.dwheeler.com/oss_fs_why.html#security