Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (16)
Similar to Windy City Rails - Layered Security
Similar to Windy City Rails - Layered Security (20)
More from Aaron Bedra
Recently uploaded
Recently uploaded (20)
Windy City Rails - Layered Security
- 1. Layered Security Whoever said it was like chess never heard of Tetris Aaron Bedra Chief Security Officer, Eligible @abedra keybase.io/abedra
- 2. What problem are you solving?
- 3. Start with problems and goals
- 4. Design specific controls that solve specific problems
- 5. Proper security design has layers
- 6. Process things at the right time and place
- 7. Locality of reference is just as important in good security design
- 8. Start with a wide net and narrow focus as you get closer to the data
- 9. What does it look like?
- 10. Edge Core
- 11. Layers as they apply to Rails • CDN • Load Balancer • Web Server • Application • Rack • Active/Action* • Database
- 12. Or more succinctly, edge, application, data
- 13. Act as far up the stack as you can
- 14. The closer to data a request gets the more damage it can cause
- 15. The Edge
- 16. This is where you want to do most of the work
- 17. Static configuration goes a long way!
- 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. You can also add dynamic controls to the edge
- 20. Dynamic controls • Authentication caching • Web Application Firewalls* • Load Shedding • Repsheet
- 21. The Application
- 22. In Rails the Application layer has two parts
- 23. We can (and should) separate what we do in Rack and what we do after it.
- 24. There’s a nice list of pre- processing tools you can pick up for Rack
- 25. Rack controls • Rack Attack • Rack Honeypot • Rack DetectTor/Rack Tor Block • Warden • Rack Throttle • Rack Cylon • Custom Middleware
- 26. Rack should do a lot of the heavy lifting for checks that don’t require additional data
- 27. Leave what’s left for the application
- 28. Rails controls • Lots of built-ins • Authorization • Encryption* • Domain specific logic (fraud, business rules, etc) • A proper secure development lifecycle
- 29. Software security has to play a major role
- 30. It should be present in every development phase
- 31. And the stuff in between
- 32. Your build should have Tests Some notion of what is tested Code metrics Brakeman Bundler Audit
- 33. Data stores
- 34. You all have work to do here
- 35. A lot of times this gets ignored
- 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. The stuff in between
- 38. You can’t forget about monitoring, auditing, and proper logging!
- 39. You’ll thank yourself when things get rough
- 40. And last but not least, focus
- 41. Security is not something you do when you can
- 42. Doing it halfway will only create false confidence
- 43. And remember…
- 45. 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/