1. Open Source Security Updates Why it's Different; What you Should Know Josh Bressers Friday, 11 May 2007

2. Define: Open Source What is Open Source? ● A group of individuals across the world working together ● It's not uncommon for many of these individuals never to have met in person The source code is available The shipped binaries are built in house

3. Define: Distribution (vendor) Collection of software (mostly open source) ● Distributions typically do not write most of the software they ship Projects usually are not distributors ● This is not always true; many of the larger projects are also distributors ● This poses a unique challenge for keeping an Open Source distribution secure

4. Security Updates What is a security flaw? CVE NVD Severity Sources Embargoed Issues

5. Security Flaw http://en.wikipedia.org/wiki/Security_bug A security bug is a software bug that benefits someone other than intended beneficiaries in the intended ways.

6. CVE

7. NVD

8. Severity Based on a technical assessment of the flaw, not the threat ● Unique to each Red Hat product ● Determines the priority through Engineering and QA Compatible withing rankings used by Microsoft and Apache

9. Sources Where does this information come from? http://www.awe.com/mark/blog/200704101400.html

10. Embargoed Issues Sometimes a flaw needs to be kept a secret ● This is often for the good of the community ● Can help give vendors time to create a fix to help prevent the creation of a worm An extra challenge for Open Source projects ● CVS and mailing lists are usually public

11. Red Hat Security Response Team What is the Red Hat Security Response Team? ● Worldwide group of individuals responsible for fixing security bugs in Red Hat products What does the team do? ● Understands flaws ● This covers all shipped Red Hat products ● Assigns severity

12. Closed Source Security Updates One vendor ● Single-source accountability The customer must trust the vendor ● Not all vendors are always honest ● They've been caught before ● Open Source makes this very hard to do

13. Open Source Security Updates Community Involvement Backporting Multiple sources of information

14. Community Involvement Vendor Security Mailing list Public security mailing lists Public patches Public bugs

15. Backporting

16. Where do the patches come from? ● Vendors and projects often work together to produce the best possible patch Who verifies it? ● The Open Source nature of development helps keep quality high ● Once the flaw is public, the patch is available for anyone to analyze

17. Multiple Sources of Information ● Who can be trusted? ● Most security mailing lists have a terrible signal-to-noise ratio ● Who verifies the information? ● Sometimes there is a great deal of conflicting information ● Third party researchers ● Other vendors ● Other projects

18. Challenges Communication ● Upstream communication ● Vendor communication Leaks Lack of interest Backporting Binary only packages

19. Conclusion What can we make of all this? ● Hire a team of security professionals ● Find a third party you can trust

20. Questions?