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

Understanding & Defending Against Data Breaches...

Frank Rietta
February 05, 2015

Understanding & Defending Against Data Breaches, as a Practicing Software Developer

A presentation on security incidents that lead to customer data breaches, which have been happening at an increasing rate, from the latest Anthem Blue Cross breach, to Target, to Home Depot, to breaches including the MongoHQ incident that lead to the BufferApp compromise.

Video is at:
https://www.youtube.com/watch?v=dj196NhPyWs&list=PLqZY2tk6rSRl8tS4zmgxijjw35lRe-Ptk&index=2

Event meetup page:
http://www.meetup.com/nashrb/events/217795882/

Resource for finding out State laws on data breaches
http://www.ncsl.org/research/telecommunications-and-information-technology/security-breach-notification-laws.aspx

History has taught us that waiting until a software project is complete and bolting security on through the use of security software or network security countermeasures is not effective enough. To have a chance to build a secure system, a team requires the active support of developers and for the organization to adopt a written information security policy that influences business model decisions and the user story writing workshop. It's not just about code and most non-developer stakeholders truly do not have enough knowledge to make informed decisions without the help of the developers. That means that developers need to be aware of basic legal requirements and be able to communicate these issues during the planning process.

Frank is the CEO of a development agency with team members in Nashville, TN, and in Atlanta, GA. Rietta works primarily with startup companies that are building out their web app and infrastructure.

Whenever you’re considering the security of a system, ask three questions:
1. Secure against what?
2. What is the worst thing that can happen?
3. Compared to what alternative?

You can learn more about Rietta at https://rietta.com
Frank is on Twitter at https://twitter.com/frankrietta

This presentation was given on Thursday, February 5, 2015, at the Nash.rb meetup in Nashville, Tennessee.

Frank Rietta

February 05, 2015
Tweet

More Decks by Frank Rietta

Other Decks in Technology

Transcript

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

    on Twitter ! February 5, 2015 Understanding & Defending Against Data Breaches, as a Practicing Software Developer
  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. 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
  4. 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.
  5. TN § 47-18-2107 
 Release of personal consumer information •

    (1) "Breach of the security of the system" means unauthorized acquisition of unencrypted computerized data that materially compromises the security, confidentiality, or integrity of personal information maintained by the information holder.… • (A) "Personal information" means an individual's first name or first initial and last name, in combination with any one (1) or more of the following data elements, when either the name or the data elements are not encrypted: • (i) Social security number; • (ii) Driver license number; or • (iii) Account number, credit or debit card number, in combination with any required security code, access code, or password that would permit access to an individual's financial account;…
  6. TN § 47-18-2110
 Protecting social security numbers from disclosure A.

    [Any business] that has obtained a federal social security number for a legitimate business or governmental purpose shall make reasonable efforts to protect that social security number from disclosure to the public. Social security numbers shall not: A. …(2) Be required to be transmitted over the Internet, unless the Internet connection used is secure or the social security number is encrypted; B. (3) Be required to log onto or access an Internet web site, unless used in combination with a password or other authentication device; … B. On and after January 1, 2009, a violation of subsection (a) is a Class B misdemeanor. Each violation of subsection (a) shall constitute a separate offense.
  7. Anthem Blue Cross • Announced last night - 2/4/2015 •

    Attackers gained unauthorized access to Anthem’s IT system and have obtained personal information from our current and former members such as their names, birthdays, medical IDs/ social security numbers, street addresses, email addresses and employment information, including income data. (Forbes) • In the wake of the attack, Anthem has reset the passwords of all employees with higher-level access to its data systems, and has blocked all access that involves only one password, Mr. Miller said. (Wass Street Journal) • 80 million people potentially affected
  8. 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
  9. Buffer App 
 (through MongoHQ) • Attackers gained access to

    plaintext Facebook and Twitter access tokens of users of the Buffer social media management profile
  10. 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.
  11. Target & Home Depot • Massive credit card data breaches

    • One of the reasons that will finally lead to the implementation of smartcard-based credit cards in the United States.
  12. As a Pawn Shop Clerk, I scan a copy of

    the customer’s drivers’ license because the company is required by law to keep this record at least two years from the date we purchase a used valuable from a customer.
  13. Security facts for this story • Data is an image

    of a drivers’ license, PII by law • Protected by State Law?: ! • Yes! • Avoid storing it?: • No • Retention Period: • 2 Years
  14. • At the conclusion of the data retention period, a

    record should show that the system did collect the required information, but that it has been deleted in the ordinary course of business at the conclusion of the retention period. • With public key encryption using GnuPG, the server will have never had the key needed to decrypt an encrypted drivers license.
  15. Design considerations • Protect data with encryption and access control

    • Automatically delete after the expiration date • Log authorized access to the file • The project is already using Paperclip, so let’s stick with that • The application and it’s API endpoints are already SSL-only with Strict Transport Security turned on • Assume the company already knows about GnuPG encryption so that authorized people can decrypt on their duly authorized computers
  16. Controller! Upload and Download actions Paperclip Filter! Encrypt with GnuPG

    rather than resize images. Server has no decryption key available. Model! Secure Attachment to track file record and the delete_at date Private OpenStack Files Container! Expiration Date Set on Each File, No Publicly Accessible URL Access Control CanCan Ability Definitions
  17. Stored on an OpenStack Files Container Automatic Delete, Random File

    Names that give no information about the file. Amazon S3 would work as well.
  18. Practical Countermeasures • Have a Defense in Depth strategy, that

    includes multiple concurrent countermeasures. • Use Secure HTTP Headers and enable SSL-only with Strict-Transport Security on all production sites • Include security concerns in your user story writing and ALWAYS ask about ways to change the business model to avoid PII. • Run automated audit tools, such as Brakeman, Bundler-audit, Code Climate, and Linters
  19. Frank S. Rietta, M.S. Information Security • My blog, where

    I write on security and other topics • https://rietta.com/blog • On Twitter • https://twitter.com/frankrietta • Learn more about Rietta’s community sponsorship, including the Atlanta Ruby Users’ Group videos • https://rietta.com/community