should not be used as security capabilities (identiﬁers 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
Conﬁdential business information 3. Conﬁdential: Information that customers consider conﬁdential 4. Sensitive: Personal and Private Information (PII), information that THE LAW considers conﬁdential! 5. Highly Sensitive: Encryption keys, server secrets, staff/admin passwords
risks of giving a credit card number to a website, or sending an unencrypted e-mail, or leaving ﬁle sharing enabled, or doing any of the dozens of things he does every day on the Internet.” – Bruce Schneier, in Beyond Fear, p 29
name or ﬁrst 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 identiﬁcation 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 identiﬁcation numbers or other access codes
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
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 ﬁnancial data
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
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.
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 conﬁrmed deletion of the e-mail. All of those whose information was in the spreadsheet were contacted by phone and then in writing. All those notiﬁed were offered free credit monitoring services for a year.
keys in your source code repository, which turns out to be a major problem. • External web application ﬁrewall service, such as CloudFlare • Robust application code that has been built following a Secure Software Development methodology. Abuse stories along with user stories.
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.
inspects inbound HTTP/HTTPS trafﬁc and rejects suspect trafﬁc • Active log monitoring, such as fail2ban that blocks at the ﬁrewall 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
employees with access to sensitive information • Regular security guards at your building • High fences, biometric gates, controlled access parking lots • Guards with riﬂes and dogs that inspect trafﬁc coming and going from your campus
• 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.
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)
that I can ﬁnd 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
production servers. Set the secure cookies ﬂag in your production.rb. • Insist that your web servers (nginx or Apache) are conﬁgured 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 identiﬁes security issues.