Upgrade to Pro — share decks privately, control downloads, hide ads and more …

[Slides Only] How a Ruby/Rails developer can he...

[Slides Only] How a Ruby/Rails developer can help prevent a Data Breach - ATLRUG

Slides only, no speaker notes, version of https://speakerdeck.com/rietta/rails-developer-can-help-prevent-a-data-breach-atlrug.

Given at the Atlanta Ruby Users’ Group monthly meeting on
August 13, 2014.

Frank Rietta

August 13, 2014
Tweet

More Decks by Frank Rietta

Other Decks in Programming

Transcript

  1. Frank S. Rietta, 
 M.S. Information Security ! rietta.com/blog @frankrietta

    on Twitter How a Ruby/Rails developer can help prevent a Data Breach
  2. Is XYZ secure? • Ask three questions: 1. Secure against

    what? 2. What is the worst thing that can happen? 3. Compared to what alternative?
  3. “Do not assume that UUIDs are hard to guess; they

    should not be used as security capabilities (identifiers whose mere possession grants access), for example. A predictable random number source will exacerbate the situation.” – rfc4122, Section 6, Security Considerations
 http://www.ietf.org/rfc/rfc4122.txt
  4. But! There is a way because an API key is

    just a username and a really good random password.
  5. • Information classification • A technical Ruby thing - implementing

    a secure API token - it’s a username and password. • Data breaches • Professional ethics • The OWASP top 10 and Secure Headers
  6. Commercial Information Classifications 1. Public: Public information 2. Internal Use:

    Confidential business information 3. Confidential: Information that customers consider confidential 4. Sensitive: Personal and Private Information (PII), information that THE LAW considers confidential! 5. Highly Sensitive: Encryption keys, server secrets, staff/admin passwords
  7. Users can feel a privacy breach even if the terms

    and conditions spell out in mouse print that they agree to such sharing. This is a yellow line violation.
  8. “The average computer user has no idea about the relative

    risks of giving a credit card number to a website, or sending an unencrypted e-mail, or leaving file sharing enabled, or doing any of the dozens of things he does every day on the Internet.” – Bruce Schneier, in Beyond Fear, p 29
  9. Unfortunately, web app developers have trouble with relative risks too

    though usually, with things more subtle than the average computer user Photo Credit: Lisamarie Babik / Wikipedia
  10. “A data breach is a security incident in which sensitive,

    protected or c o n fi d e n t i a l d a t a i s c o p i e d , transmitted, viewed, stolen or used by an individual unauthorized to do so.” – Data breach. (Wikipedia)
  11. Georgia Law (10-1-911) • “Personal information” means an individual's first

    name or first initial and last name in combination with any one or more of the following data elements, when either the name or the data elements are not encrypted or redacted: • Social security number; • Driver's license number or state identification card number; • Account number, credit card number, or debit card number, if circumstances exist wherein such a number could be used without additional identifying information, access codes, or passwords; • Account passwords or personal identification numbers or other access codes
  12. Other Laws • 18 U.S.C. § 1030 (1986) (the Computer

    Fraud and Abuse Act of 1986) • U.S. Federal Privacy Act of 1974, 5 U.S.C. § 552A • U.S. Health Insurance Portability and Accountability Act (HIPAA) of 1996, PL 104-191 • U.S. Health Information Technology for Economic and Clinical Health Act (HITECH) of 2009 • U.S. Gramm-Leach-Bliley Financial Services Modernization Act, PL 106-102
  13. PCI-DSS • The Payment Card Industry Digital Security Standard prescribes

    technical security countermeasures, called controls, and liabilities for the handling or mishandling of card holder payment information • Contract law, not mandated by the government yet • Although PCI DSS is an industry standard rather than a legal mandate, states are beginning to introduce legislation that would make PCI compliance mandatory • It does not apply to checking account numbers, but following the same rules would be prudent in a system that handles financial data
  14. An adversary cannot steal data from you that your system

    does not process. 
 
 So, it’s good to minimize your systems’ exposure by proactively avoiding PII whenever possible.
  15. bit.ly • In May, 2014, the offsite database backup was

    compromised. All data, including users’ API keys and hashed passwords were exposed • The backup database was not encrypted • It turns out that the attackers gained access to the database backup through a compromised employee account • If bit.ly had been using 2-factor authentication on employee accounts, this attack would likely have never taken place
  16. Buffer App 
 (through MongoHQ) • Attackers gained access to

    plaintext Facebook and Twitter access tokens of users of the Buffer social media management profile
  17. Humana’s Atlanta breach • In May, 2014, without regard to

    an IT strategy that included laptops with full drive encryption, an employee in Atlanta also copied patient health data to a USB disk • Furthermore, the employee left the laptop and the unencrypted external disk in a vehicle were it was stolen by a thief • Because unencrypted data has left the custody of the company and is in the hands of a thief and the data is not encrypted, this is a data breach of private health information.
  18. Ruby Tuesday (2013) • A Support Center staff member at

    Ruby Tuesday, the restaurant chain, exposed current employees’ information to a former employee. • The spreadsheet, inadvertently attached to the e-mail, contained employees’ names, Social Security numbers, bank name, bank account type, bank account numbers and routing numbers. • Ruby Tuesday immediately tried to recall the e-mail, and contacted the recipient who confirmed deletion of the e-mail. All of those whose information was in the spreadsheet were contacted by phone and then in writing. All those notified were offered free credit monitoring services for a year.
  19. Defense in Depth • Never put server credentials or API

    keys in your source code repository, which turns out to be a major problem. • External web application firewall service, such as CloudFlare • Robust application code that has been built following a Secure Software Development methodology. Abuse stories along with user stories.
  20. Compartmentalize • Need-to-know where employees, especially customer service do not

    have access to sensitive information that is not vital for them to do their job. See Insider Threat. • Database with varying level of permissions, enforced by the database server, following the principle of least privilege • Multi-factor authentication for privileged users, something they know and something they have.
  21. Enhanced Measures • Web application firewall, such as ModSecurity that

    inspects inbound HTTP/HTTPS traffic and rejects suspect traffic • Active log monitoring, such as fail2ban that blocks at the firewall level • Encrypted records in the database using Public Key Cryptography • Military-grade cryptographic smart cards, similar to the Common Access Card, that control access to computers systems and decrypt messages with that user’s key that never leaves the card
  22. Organizational Countermeasures • In depth criminal background checks on all

    employees with access to sensitive information • Regular security guards at your building • High fences, biometric gates, controlled access parking lots • Guards with rifles and dogs that inspect traffic coming and going from your campus
  23. Use encryption when appropriate • gpgme gem • attr_encrypted gem

    • Your database’s support for encrypted records, such as pgcrypto in PostgreSQL • But remember that crypto is usually not broken, it is bypassed. Key management becomes the hard challenge to properly utilizing encryption within your application.
  24. OWASP Top 10 • Injection • Broken Authentication and Session

    Management • Cross-Site Scripting (XSS) • Insecure Direct Object References • Security Misconfiguration
  25. OWASP Top 10, continued • Sensitive Data Exposure • Missing

    Function Level Access Control • Cross-site Request Forgery (CSRF) • Using Components with Known Vulnerabilities • Unvalidated Redirects and Forwards
  26. 1. Strict Transport Security (HSTS)! 2. SecureOnly (cookies can only

    be sen't over SSL)! 3. X-Frame Options (prevents click-jacking)! 4. Cache-Control * 5. Content Security Policy (CSP) 6. X-Content-Type (MIME Type Sniffing) 7. HTTPOnly (cookies can't be accessed by JavaScript) Secure HTTP Headers
  27. Further Reading • The OWASP Railsgoat Project (github.com) • Ruby

    Midwest 2013 Rails Application Security in Practice by Bryan Helmkamp (youtube.com) • Ruby on Rails Security Guide (rubyonrails.org) • Modern Software is Like Lego & WTF Don’t People Use Secure Headers? OWASP presentation by Mark Curphey @curphey • Use GPG to hide Rails secrets (bugsnag.com) • OWASP Top Ten (2013) (owasp.org)
  28. Security on Rails The only Ruby on Rails security book

    that I can find at this time. It’s from 2010, but the principles that are covered are timeless and will serve you well to read. ! http://www.amazon.com/ Security-Rails-The-Pragmatic- Programmers/dp/1934356484
  29. Immediate Technical Actions • Insist on SSL-only for your clients’

    production servers. Set the secure cookies flag in your production.rb. • Insist that your web servers (nginx or Apache) are configured with Strict Transport Security X-Frame-Options. • Explain that Two-Factor Authentication is industry standard for staff/admin access and just build it in my default. • Run brakeman as part of your build process and do not deploy to production if it identifies security issues.
  30. Startups should ask for less personal information. Please Favorite if

    you agree… http://twitter.com/frankrietta