windy city rails - layered security
TRANSCRIPT
Layered SecurityWhoever said it was like chess never heard of Tetris
Aaron Bedra Chief Security Officer, Eligible @abedra keybase.io/abedra
What problem are you solving?
Start with problems and goals
Design specific controls that solve specific
problems
Proper security design has layers
Process things at the right time and place
Locality of reference is just as important in good
security design
Start with a wide net and narrow focus as you get
closer to the data
What does it look like?
Edge
Core
Layers as they apply to Rails• CDN
• Load Balancer
• Web Server
• Application
• Rack
• Active/Action*
• Database
Or more succinctly, edge, application, data
Act as far up the stack as you can
The closer to data a request gets the more damage it can cause
The Edge
This is where you want to do most of the work
Static configuration goes a long way!
Static configuration checklistAt 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
You can also add dynamic controls to the
edge
Dynamic controls
• Authentication caching
• Web Application Firewalls*
• Load Shedding
• Repsheet
The Application
In Rails the Application layer has two parts
We can (and should) separate what we do in Rack
and what we do after it.
There’s a nice list of pre-processing tools you can
pick up for Rack
Rack controls• Rack Attack
• Rack Honeypot
• Rack DetectTor/Rack Tor Block
• Warden
• Rack Throttle
• Rack Cylon
• Custom Middleware
Rack should do a lot of the heavy lifting for checks that don’t require additional data
Leave what’s left for the application
Rails controls• Lots of built-ins
• Authorization
• Encryption*
• Domain specific logic (fraud, business rules, etc)
• A proper secure development lifecycle
Software security has to play a major role
It should be present in every development
phase
And the stuff in between
Your build should have
Tests
Some notion of what is tested
Code metrics
Brakeman
Bundler Audit
Data stores
You all have work to do here
A lot of times this gets ignored
Database checklistNothing 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!!!
The stuff in between
You can’t forget about monitoring, auditing, and
proper logging!
You’ll thank yourself when things get rough
And last but not least, focus
Security is not something you do when you can
Doing it halfway will only create false confidence
And remember…
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/