Security is Hard (RedDotRubyConf 2015)

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