Security is Hard (RedDotRubyConf 2015)

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.

4c3ed917e59156a36212d48155831482?s=128

André Arko

June 04, 2015
Tweet

Transcript

  1. Security is hard

  2. André Arko @indirect

  3. None
  4. None
  5. Security is hard

  6. but we can’t go shopping

  7. !

  8. Ruby security releases

  9. None
  10. None
  11. None
  12. that is a lot of releases

  13. None
  14. Rails security releases

  15. None
  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

  51. None
  52. google severity scale $100 to $20,000

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

  54. None
  55. facebook

  56. None
  57. facebook $500 minimum no maximum

  58. github

  59. None
  60. github no stated reward $? maximum

  61. engine yard

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