Windy City Rails - Layered Security

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/