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.

Transcript

1. Security is hard
2. André Arko @indirect
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
47. facebook $500 minimum no maximum
48. github
50. github $100 minimum $5000 maximum
51. heroku
53. heroku $100 minimum $1500 maximum
54. engine yard
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