My talk from Windy City Rails 2016

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/