What a Ruby developer can do to help prevent a Data Breach

Data breaches are a major problem faced by society. We trust increasing amounts of private information to web applications, some built by startups and others by major corporations. No matter the organization though, these systems are built by individual developers making practical, specific coding decisions within their code that impact the security of the system and its data.

Individual developers have a responsibility have a personal standard of due care in their work. To be aware of what decisions they can personally make that protect their systems’ users and their employers or clients.

In this talk, the students are expected to become exposed to and learn:

1. That users perceive a breach a privacy even when the actions may be legal and permitted by terms of service.

2. The concept of relative risks and the balancing act that is fundamental to a comprehensive information security plan

3. That a data breach is the disclosure and access of sensitive information to an unauthorized person and that it does not matter if specific evil was done with that information

4. A short list of State and Federal laws that define legally protected private information, called Personally Identifiable Information (PII)

5. A discussion on professional ethics and reasonable standard of due care.

6. Become familiar with the OWASP Top 10, which is a list of ways that web applications are frequently compromised.

7. Become familiar with the availability of inexpensive physical 2 factor authentication and security credential devices that can be integrated into a system being built in Ruby on Rails.

With this knowledge, the hope is that the students will rise to the occasion and seek out additional knowledge about this topic. Moreover, by drawing a personal line in the sand, that each developer will be better prepared to push back within their organizations when sensitive information is being included with an application and to recommend appropriate safe guards or to decline to implement features if reasonable due care is being left out of the process.

The video of the presentation is available at
https://vimeo.com/97299282

Transcript

1. What a Ruby developer can do to help prevent a Data Breach Frank S. Rietta, 
 M.S. Information Security
2. This talk’s video https://vimeo.com/97299282
3. User’s feel a breach of privacy even if the terms and conditions spell out in mouse print that they agree to such sharing
4. – Bruce Schneier, in Beyond Fear, p 29 “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.”
5. 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
6. Data Breaches
7. – Data breach. (Wikipedia) “A data breach is a security incident in which sensitive, protected or confidential data is copied, transmitted, viewed, stolen or used by an individual unauthorized to do so.”
8. 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
9. 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
10. 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, many states are beginning to introduce legislation that would make PCI compliance (or at least compliance with certain provisions) mandatory for organizations that do business in that state • It does not apply to checking account numbers, but following the same rules would be prudent in a system that handles financial data
11. 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.
13. 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.
14. Ebay
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. Target
18. Professional Ethics what is your reasonable standard of due care?
19. What You can Actually Do as a Web Application Developer
20. 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.
21. OWASP Top 10 • Injection • Broken Authentication and Session Management • Cross-Site Scripting (XSS) • Insecure Direct Object References • Security Misconfiguration
22. 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
23. API Tokens a brief aside in a common pattern
24. 72322b88-a702-495e- b17a-a34adbc1df87
25. – rfc4122, Section 6, Security Considerations
 http://www.ietf.org/rfc/rfc4122.txt “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.”
26. But! There is a way because an API key is just a username and a random password.
27. { { ba0468d92fec4410a01fc8189fddb8e9:4c45 a42d6df28efb56b16106b76a02bf44b529221 9885cdbe5cb6aa789a819ab521de201ad77 4e0bf3f8cc4e36e2d2b8b5aa63161447a401 Strip out the dashes in the UUID Add a long randomly generated password Colon as a 
 separator 
 character
28. Further Reading • 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)
29. OpenPGP Key Backup Package • One security catalog envelope, 6 x 9 inch • Two premium stock #10 security envelopes for printed key material and the revocation certificate • One 3 5/8 in x 6 1/2 inch security envelope for the password card • One 3 x 5 inch card for handwritten password • One USB disk for electronic backup of the key material • Tamper evident labels with appropriate warnings