Windy City Rails - Layered Security
•
2 likes•879 views
This document discusses the concept of layered security and provides examples of controls that can be implemented at different layers. It recommends starting security design by addressing specific problems and goals. Controls are then designed to solve those problems. Layers discussed include the edge, application, and data layers. Examples of controls for each layer are provided, such as static configuration, authentication caching, and firewalls at the edge layer and middleware like Rack Attack in the application layer. The importance of monitoring, auditing and proper logging is also discussed.
Report
Share
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/