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

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.

4c3ed917e59156a36212d48155831482?s=128

André Arko

May 31, 2013
Tweet

Transcript

  1. Security is hard

  2. André Arko @indirect   

  3. None
  4. [ANN]

  5. ! +

  6. + !

  7. + !

  8. ! ! !

  9. Security is hard

  10. but we can’t go shopping

  11. !

  12. Ruby security releases

  13. None
  14. None
  15. None
  16. this is not normal

  17. None
  18. Rails security releases

  19. None
  20. None
  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

  56. None
  57. google severity scale $100 to $20,000

  58. google paid over $130k so far this year

  59. None
  60. facebook

  61. None
  62. facebook $500 minimum no maximum

  63. github

  64. None
  65. github no stated reward $? maximum

  66. engine yard

  67. None
  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?