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