Securing Open Source Software: Advantages and Challenges

1. Securing Open Source Software: Advantages and Challenges Mitch Stoltz Head Security Engineer Netscape Client Products Division

2. 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?

3. 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”

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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

13. Re-Framing the Question “Is open source code more secure than proprietary code?”

14. Re-Framing the Question “Is open source code more secure than proprietary code?” This is the wrong question.

15. 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?

16. 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

17. 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

18. 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

19. 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

20. 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

21. Challenges & Solutions • Challenge: Developer Education • Solution: Identify Common Mistakes & Teach Best Practices • We need new, innovative forms of developer education

22. 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

23. Questions & Comments Welcome