Security is Hard, But We Can't Go Shopping (Madison Ruby 2014)

Security is Hard, But We Can't Go Shopping (Madison Ruby 2014)

The last year has been brutal for Ruby and security. Ruby has gotten quite popular, which is really exciting! But it also means that we are now square in the crosshairs of security researchers, whether whitehat, blackhat, or some other hat. Before 2013, only the Ruby and Rails core teams had meaningful experience with security issues. This year everyone got meaningful experience. Vulnerabilities are everywhere, and handling security issues responsibly is critical if we want Ruby (and Rubyists) to stay safe and in high demand.

I discuss responsible disclosure, as well as repsonsible ownership of your own code. How do you know if a bug is a security issue, and how do you report it without tipping off someone malicious? As a Rubyist, you probably have at least one library of your own. How do you handle security issues, and fix them without compromising apps running on the old code? Don’t let your site get hacked, or worse yet, let your project allow someone else’s site to get hacked! Learn from the hard-won wisdom of the security community so that we won’t repeat the mistakes of others.

4c3ed917e59156a36212d48155831482?s=128

André Arko

August 23, 2014
Tweet

Transcript

  1. Security is hard

  2. André Arko @indirect

  3. None
  4. Bundler

  5. Security is hard

  6. but we can’t go shopping

  7. !

  8. accelerating security issues are

  9. Ruby+Rails security releases

  10. ruby CVEs 0 1 2 3 4 5 6 2009

    2010 2011 2012 2013
  11. rails CVEs 0 3 6 9 12 15 18 2009

    2010 2011 2012 2013
  12. wait what’s a CVE?

  13. common vulnerabilities and exposures

  14. numbering authorities

  15. apple adobe cisco redhat etc.

  16. cve.mitre.org nvd.nist.gov

  17. minaswan security? vulnerabilities?

  18. dhh + rails not as nice

  19. dhh + rails but we can learn from them

  20. so many gems for everything

  21. so many chances for security issues

  22. rubygems bundler json rexml rack

  23. arel activerecord actionpack activesupport rdoc (rdoc?! yup.)

  24. what should we do?

  25. updating is a pain

  26. updating blocks feature development

  27. updating is insurance

  28. a small cost to mitigate risk

  29. without it failures are catastrophic

  30. !

  31. disclosure liability lawyers

  32. updating is hard work !

  33. but updating is worth it

  34. update sleep well at night !

  35. reporting security issues

  36. responsible disclosure

  37. the worst except for all the other options

  38. the best yet because everyone ends up unhappy

  39. !

  40. but no one ends up screwed

  41. disclosure companies hate it

  42. responsible clever, triumphant hackers hate it

  43. rewards! !

  44. rewards! ! maybe everyone ends up happy?

  45. facebook

  46. None
  47. facebook $500 minimum no maximum

  48. github

  49. None
  50. github $100 minimum $5000 maximum

  51. heroku

  52. None
  53. heroku $100 minimum $1500 maximum

  54. engine yard

  55. None
  56. engine yard no compensation $0 maximum

  57. you anyway, back to

  58. find a bug? what if you

  59. questions ask yourself two

  60. I shouldn’t? can I access something

  61. other people? can I disable something for

  62. disclose responsibly if the answer was yes

  63. publicly contact an author before reporting

  64. look for a security policy email in gemspec email on

    github
  65. have empathy work together

  66. if all else fails

  67. fix it! if all else fails

  68. finally, what about your gems?

  69. your gems are security vulnerabilities waiting to happen

  70. unless your code is perfect (and then I have a

    bridge to sell you)
  71. easy sympathetic discoverer

  72. write fix, review fix release + announce easy

  73. medium problem in the wild

  74. medium announce if safe fix ASAP, test fix release +

    announce
  75. hard researcher out for glory

  76. hard respond ASAP set expectations update every 24-48h fix +

    release + thanks
  77. make it as easy as possible

  78. personally gemspec email github email

  79. on a team security address PGP key disclosure policy

  80. ecosystem mailing list for announcing security issues and releases

  81. bit.ly/ruby-sec-ann

  82. go shopping we can !"#$ %&'(

  83. questions? bit.ly/ruby-sec-ann @indirect