Security is hard, but we can't go shopping (RubyKaigi 2013)

The last few months have been pretty brutal for anyone who depends on Ruby libraries in production. Ruby is really popular now, and that’s exciting! But it also means that we are now square in the crosshairs of security researchers, whether whitehat, blackhat, or some other hat. Only the Ruby and Rails core teams have meaningful experience with vulnerabilites so far. It won’t last. Vulnerabilities are everywhere, and handling security issues responsibly is critical if we want Ruby (and Rubyists) to stay in high demand.

I’ll 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. [ANN]
5. ! +
6. + !
7. + !
8. ! ! !
9. Security is hard
10. but we can’t go shopping
11. !
12. Ruby security releases
16. this is not normal
18. Rails security releases
21. this isn’t normal either
22. wait what’s a CVE?
23. common vulnerabilities and exposures
24. numbering authorities
25. apple adobe cisco redhat etc.
26. cve.mitre.org nvd.nist.gov
27. minaswan security? vulnerabilities?
28. dhh + rails not as nice
29. dhh + rails but we can learn from them
30. so many gems for everything
31. so many chances for security issues
32. rubygems bundler json rexml rack
33. arel activerecord actionpack activesupport rdoc (rdoc?! yup.)
34. what should we do?
35. updating is a pain
36. updating blocks feature development
37. updating is insurance
38. a small cost to mitigate risk
39. without it failures are catastrophic
40. !
41. disclosure liability lawyers
42. updating is hard work !
43. but updating is worth it
44. update sleep well at night !
45. reporting security issues
46. responsible disclosure
47. the worst except for all the other options
48. the best yet because everyone ends up unhappy
49. !
50. but no one ends up screwed
51. disclosure companies hate it
52. responsible clever, triumphant hackers hate it
53. rewards! !
54. rewards! ! maybe everyone ends up happy?
55. google
57. google severity scale $100 to $20,000
58. google paid over $130k so far this year
60. facebook
62. facebook $500 minimum no maximum
63. github
65. github no stated reward $? maximum
66. engine yard
68. engine yard no compensation $0 maximum
69. you anyway, back to
70. find a bug? what if you
71. questions ask yourself two
72. not mine? can I access something
73. other people? can I disable something for
74. disclose responsibly if the answer was yes
75. publicly contact an author before reporting
76. look for a security policy email in gemspec email on github
77. have empathy work together
78. if all else fails
79. fix it! if all else fails
80. finally, what about your gems?
81. your gems are security vulnerabilities waiting to happen
82. unless your code is perfect (and you want to buy this )
83. easy sympathetic discoverer
84. easy write fix, review fix release + announce
85. medium problem in the wild
86. medium announce if safe fix ASAP, test fix release + announce
87. hard researcher out for glory
88. hard respond ASAP set expectations update every 24-48h fix + release + thanks
89. make it as easy as possible
90. personally gemspec email github email
91. on a team security address PGP key disclosure policy
92. ecosystem mailing list for announcing security issues and releases
93. bit.ly/ruby-sec-ann
94. go shopping we can !"#$ %&'(
95. questions?