linuxcon na 2015:are today's foss security practices robust enough in the cloud era?

Click here to load reader

Post on 21-Aug-2015

49 views

Category:

Technology

0 download

Embed Size (px)

TRANSCRIPT

  1. 1. Lars Kurth Community Manger, Xen Project Chairman, Xen Project Advisory Board Lead CentOS Virtualization SIG Director, Open Source Business Office, Citrix lars_kurth
  2. 2. Was a contributor to various projects Worked in parallel computing, tools, mobile and now virtualization Community guy at Symbian Foundation Learned how NOT to do stuff Community guy for the Xen Project Working for Citrix Member of OSS Business Office Accountable to Xen Project Advisory Board Chairman of Xen Project Advisory Board
  3. 3. Users Safe
  4. 4. Think of your vulnerability process as a team-effort to ensure that All doors are closed All doors are locked All windows are boarded up Fences have no weaknesses
  5. 5. Encourage discoverers to report security issues to [email protected] Discoverers are in control You cant stop them from releasing/using information A robust vulnerability process encourages discoverers to work with you
  6. 6. Ensure that your project fixes security issues as quickly as possible You dont want unaddressed vulnerabilities
  7. 7. Exposure time to security issues is minimized A maximum of users apply patches quickly Minimize risk
  8. 8. ResponsibleF A X FullF XA I: Vulnerability Introduced D: Vulnerability Discovered R: Vulnerability Reported A: Vulnerability Announced F: Fix Available X: Fix Deployed Vulnerability exists: we do not know whether it is exploited in the wild Vulnerability is known about by a privileged and small group of users Vulnerability is known publicly R R I D
  9. 9. Linux Kernel/LXC/KVM if reported via OSS Security Linux Kernel/LXC/KVM if reported via [email protected] OpenStack for low impact issues Full Linux Kernel/LXC/KVM if reported via OSS Security Distros Linux Distributions (both open source and commercial) QEMU, Libvirt, oVirt, ... Responsible Distro Model OpenStack for intermediate to high impact issues OPNFV, OpenDayLight : process modeled on OpenStack Xen Project for all issues (also handles 3rd party issues, e.g. QEMU) Responsible Cloud Model Not clearly stated Docker : states responsible disclosure; but policy docs / CVE pages are empty Cloud Foundry : no clearly stated process; no published CVEs CoreOS: just a mail to report issues Kubernetes: no information (or could not find it, which is an issue in itself) Approach Used by Projects
  10. 10. Open-source software projects are often well intended, but security can take a back seat to making the code work. OpenDaylight, the multivendor software-defined networking (SDN) project, learned that the hard way last August after a critical vulnerability was found in its platform. It took until December for the flaw, called Netdump, to get patched PC World, March 2015
  11. 11. Source: yanilavigne.net via domics.me
  12. 12. Wide range of approaches No consistent Best Practice across projects Newer projects are lagging behind
  13. 13. Using the pre-dominant model as baseline Applies to Linux Distros, OSS Sec Distros, QEMU, Mike Licht @ Flickr
  14. 14. A X Typically fixed time during which the security issue is handled secretly Depends on discoverers wishes R: Vulnerability Reported T: Triage P: Vulnerability Pre-disclosed A: Vulnerability Announced F: Fix Available X: Fix Deployed Vulnerability is known by the reporter and the security team Note: It may also be known and used by black hats Vulnerability is known about by a privileged and small group of users Vulnerability is known publicly Description, CVE allocation, Pre-disclosure period What can and cant be done with privileged information can differ significantly between projects R Patch/fix creation and validation FT P
  15. 15. Micolo J @ Flickr
  16. 16. mindfulness @ Flickr
  17. 17. F A XR Disclosure Time
  18. 18. I personally don't like embargoes. I don't think they work. That means that I want to fix things asap. Linus Torvalds, 2008
  19. 19. People are less willing sometimes to brush the problem [of fixing security issues] under the mat, and leave it up to vendors that have disclosures, like infinitely long disclosure times. Linus Torvalds, 2015
  20. 20. Long disclosure times discredit responsible disclosure From a few days to many months (recent example: Apple) Long disclosure times create a disincentive for reporters to work with you Increases the risk of 0 day exploits Pre-defined disclosure times help manage vendors Example later Most successful projects have a 2-3 weeks disclosure period
  21. 21. The capability to fix issues within the recommended time Larger and distributed projects can struggle to fix all issues in time The capability to handle the entire process in secret
  22. 22. Assigning CVE numbers is best practice in by established projects and vendors in the Linux/Cloud ecosystem
  23. 23. CVE databases (such as www.cvedetails.com) can be used to evaluate your project This shows Xen Project CVE stats Before 2012, we didnt have fewer vulnerabilities than after We just didnt have a process requiring creation of CVEs
  24. 24. A fair comparison between projects/technologies using CVE data is not easily possible Not all projects/products create CVEs for all their issues Example: Linux/QEMU only do so for severe ones Policies are not always published Some projects dont assign CVEs at all Some technologies/products cannot be easily identified in databases Example: KVM, LXC Sometimes CVEs can affect several products But are counted only against one Open source product definitions on cvedetails are often sloppy
  25. 25. Mike Licht @ Flickr
  26. 26. Description, CVE allocation, A D Pre-disclosure period R Patch/fix creation and validation FT P What happens here depends on your process goals
  27. 27. Make sure that a fix is available before disclosure Make sure that downstream projects and products (e.g. distros) can package and test the fix in their environment Allow service providers that use your Software to start planning an upgrade (at scale this can take a week) Allow service providers that use your Software to deploy an upgrade before the embargo completes
  28. 28. What is allowed during pre-disclosure Who is privileged and trusted to be on the pre-disclosure mailing list Disclosure Time
  29. 29. Make sure that a fix is available before disclosure Make sure that downstream projects and products (e.g. distros) can package and test the fix in their environment Allow service providers that use your Software to start planning an upgrade (at scale this can take a week) Allow service providers that use your Software to deploy an upgrade before the embargo completesCloud Model Distro Model
  30. 30. Emerged recently! Recognizes the needs of service providers Pre-Cloud Computing! Services and their users are vulnerable during pre-disclosure period
  31. 31. More Cloud/Service users than direct users of your software Example: AWS stated in 2014 that they have > 1M users (and a lot more instances) AliCloud claims that they have > 1M users
  32. 32. Just imagine what the reputation damage would have been, if Xen had put AWS, Rackspace, SoftLayer, users at real risk of a vulnerability. There were 100s of stories at the time, despite the fact that users were never put at risk, but merely inconvenienced !
  33. 33. Pre-disclosure list membership: more members, more risk of leakage In the Distro Model, the number of privileged users is typically