The document summarizes security practices at Greenhouse, a company that provides recruiting optimization software. It discusses Greenhouse's use of a bug bounty program, third-party security audits, and processes to instill a culture of security. Greenhouse stores sensitive user data and aims to demonstrate its security to customers through these measures. The document provides examples of security issues found through the bug bounty program and audit and recommends security practices for Rails applications.

1. RECRUITING OPTIMIZATION SUMMIT 2015
Security at Greenhouse
Mike O’Neil, Tech Lead

2. Software that optimizes your company’s entire recruiting process:
• Sourcing – spend your money & time effectively
• Interviewing – perform structured, purposeful interviews
• Decision making – support your hiring decision with data;
see what worked, what didn’t, and refine your process
What is Greenhouse?

3. • Javascript
• Rails
• Postgres
• Heroku + AWS
Our Stack

4. • We store sensitive data (PII, salary negotiations, etc.)
• Customers need to trust us with that data
• “We’re secure” isn’t quite good enough. We have
to be able to demonstrate it.
Security is important

5. • Invite others to “hack” on the product
• Undergo third party audits
• Instill a culture of security
How do we do that?

6. Invite others to “hack”
on the product

7. • We chose HackerOne: https://hackerone.com/greenhouse
• Security researchers from all over try to find exploits
• Pay out a small bounty for verifiable exploits
• Hundreds of man-hours for very little payout
Start a Bug Bounty Program

8. • Cross-site issues (XSS / CSRF)
• Clickjacking (embed your site in an iframe elsewhere)
• Reflected File Download (JSONP vulnerability)
• Best practices: missing security headers, DNS
configuration not optimal, etc.
• 2 CVEs found: Solr, and Rails itself
What bug reports did we see?

9. The attacker was able to determine if a file exists outside of the
Rails root (but not retrieve the file).
How? Simply visit:
“Arbitrary File Disclosure” found in Rails core
http://yoursite.com/..%2F..%2F..%2Fbin/bash
This results in a special 404 response, indicating the file exists.

10. • Triage: prepare to be overwhelmed in the beginning
• Too many fake bug reports
Downsides to a Bug Bounty Program

11. • Find security holes
• Low cost, low barrier to entry
• Gain exposure to a wide array of attack vectors
• Show people you care about security
Upsides to a Bug Bounty Program

12. Undergo third-party
audit

13. • We’re not security experts ourselves
• Customers need assurance that our product is secure
• Some companies won’t sign on to Greenhouse without it
Call in the experts

14. They come on-site and have complete access to our code and
test environment.
• Penetration testing (blackbox and whitebox)
• Code review
• Design review
iSEC Partners

15. Only one: $$$
Downsides

16. Instill a culture of
security

17. • Use 1Password to store all your account passwords
• Don’t send API keys, etc. to each other over email in plaintext:
everyone needs a PGP key
• Enable 2FA on Github / Heroku / AWS
• Background checks for anyone with access to production
• Tech leads review all code
Processes we follow

18. A few things you can
be doing to secure your
Rails app…

19. Rack::Attack (https://github.com/kickstarter/rack-attack)
config/initializers/rack_attack.rb:
Throttle your login page
config = { :limit => 5, :period => 1.minute }
Rack::Attack.throttle('login', config) do |request|
if request.post? && request.path == ‘/your/sign_in/path’
request.params['user']['email']
end
end

20. If you use CanCan, put this in your base controller:
Ensure all controllers do authorization
check_authorization
Now if you don’t call authorize! in a controller action, an
AuthorizationNotPerformed error is raised.
Tip: Start with a “reporting” mode before flipping it live. Catch
this error and log it, then fix the offending controller actions.

21. • SymmetricEncryption gem (github: reidmorrison)
• We created an ActiveRecord keyword to indicate which
columns should be encrypted/decrypted.
Encrypt sensitive data in your database
class User < ActiveRecord::Base
encrypt_columns :api_key
end
user = User.new
user.api_key = ‘abc123’ # encrypted automatically
user.api_key # decrypted on the fly

22. • DOS attack: open a lot of connections, send partial
requests, but never complete them.
• Rails servers are susceptible to this attack, e.g. unicorn
• Solution: Put nginx in front of Rails, bump up
worker_connections quite a bit.
• On Heroku? Use a buildpack to run nginx.
Mitigate slowloris attack

23. Mike O’Neil
moneil@greenhouse.io
http://greenhouse.io