Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Windy City Rails - Layered Security

448 views

Published on

My talk from Windy City Rails 2016

Published in: Technology
  • Be the first to comment

Windy City Rails - Layered Security

  1. 1. Layered Security Whoever said it was like chess never heard of Tetris Aaron Bedra Chief Security Officer, Eligible @abedra keybase.io/abedra
  2. 2. What problem are you solving?
  3. 3. Start with problems and goals
  4. 4. Design specific controls that solve specific problems
  5. 5. Proper security design has layers
  6. 6. Process things at the right time and place
  7. 7. Locality of reference is just as important in good security design
  8. 8. Start with a wide net and narrow focus as you get closer to the data
  9. 9. What does it look like?
  10. 10. Edge Core
  11. 11. Layers as they apply to Rails • CDN • Load Balancer • Web Server • Application • Rack • Active/Action* • Database
  12. 12. Or more succinctly, edge, application, data
  13. 13. Act as far up the stack as you can
  14. 14. The closer to data a request gets the more damage it can cause
  15. 15. The Edge
  16. 16. This is where you want to do most of the work
  17. 17. Static configuration goes a long way!
  18. 18. Static configuration checklist At least a B+ rating on SSL Labs* Reject extensions that you don’t want to accept Reject known bad user agents Reject specific known bad actors Custom error pages that fit your application Basic secure headers
  19. 19. You can also add dynamic controls to the edge
  20. 20. Dynamic controls • Authentication caching • Web Application Firewalls* • Load Shedding • Repsheet
  21. 21. The Application
  22. 22. In Rails the Application layer has two parts
  23. 23. We can (and should) separate what we do in Rack and what we do after it.
  24. 24. There’s a nice list of pre- processing tools you can pick up for Rack
  25. 25. Rack controls • Rack Attack • Rack Honeypot • Rack DetectTor/Rack Tor Block • Warden • Rack Throttle • Rack Cylon • Custom Middleware
  26. 26. Rack should do a lot of the heavy lifting for checks that don’t require additional data
  27. 27. Leave what’s left for the application
  28. 28. Rails controls • Lots of built-ins • Authorization • Encryption* • Domain specific logic (fraud, business rules, etc) • A proper secure development lifecycle
  29. 29. Software security has to play a major role
  30. 30. It should be present in every development phase
  31. 31. And the stuff in between
  32. 32. Your build should have Tests Some notion of what is tested Code metrics Brakeman Bundler Audit
  33. 33. Data stores
  34. 34. You all have work to do here
  35. 35. A lot of times this gets ignored
  36. 36. Database checklist Nothing uses the root user Strong and securely stored production passwords Separate users for runtime and migrations Separate databases for production, staging, test, etc Firewalls for everything but the systems that need access Logs, logs, logs Backups!!!
  37. 37. The stuff in between
  38. 38. You can’t forget about monitoring, auditing, and proper logging!
  39. 39. You’ll thank yourself when things get rough
  40. 40. And last but not least, focus
  41. 41. Security is not something you do when you can
  42. 42. Doing it halfway will only create false confidence
  43. 43. And remember…
  44. 44. References • dev.ssllabs.com/ssltest/ • www.keycdn.com/blog/http-security-headers/ • github.com/repsheet • github.com/rack/rack/wiki/List-of-Middleware • guides.rubyonrails.org/security.html • www.owasp.org/index.php/Ruby_on_Rails_Cheatsheet • brakemanscanner.org/

×