RMR Preview for Defending Against Data Breaches, as a Practicing Ruby Developer

You've been hearing about big data breaches in the news. As a developer who doesn't specialize in security, knowing how to protect your application from getting hacked may seem like a daunting task. However, fundamentals in the design and development process will greatly increase the security that protects your users from harm.

1. Data breaches are a major concern that cannot be mitigated by wishful thinking alone
2. Application Security is about preventing abuse by adversaries who have access to the system, focusing on the app itself rather than just its environment
3. Have an Information Classification system
4. Treat security as a requirement by writing Abuse Stories along with your User Stories.
5. Apply practical technical countermeasures, such as including OWASP Top 10 and your abuse stories in your automated test suite

This presentation covers the systematic use of Abuse Stories along with User Stories with security constraints. This is an open area of research how to best apply these practices to custom software development practices, especially within an Agile or Extreme Programming development environment that is developer lead.

For additional in depth discussion of preventing data breaches in custom software development, including additional User Stories and Abuser Stories, see my 2015 ISSA conference paper at https://rietta.com/papers/data-breaches/ISSA2015/Defending-Against-Data-Breaches-in-Custom-Software-ISSA2015-Rietta.pdf.

Transcript

1. Frank S. Rietta, 
 M.S. Information Security rietta.com/blog @frankrietta on Twitter September 09, 2015 Defending Against Data Breaches, as a Practicing Ruby Developer
2. Slides on Speaker Deck 
 http://bit.ly/1UBWevu
3. 1. Data breaches are a major concern that cannot be mitigated by wishful thinking alone 2. Application Security is about preventing abuse by adversaries who have access to the system, focusing on the app itself rather than just its environment 3. Have an Information Classification system 4. Treat security as a requirement by writing Abuse Stories along with your User Stories. 5. Apply practical technical countermeasures, such as including OWASP Top 10 and your abuse stories in your automated test suite
4. Application Security is the subset of Information Security focused on protecting data and privacy from abuse by adversaries who have access to the software system as a whole. Its purpose is to make software resilient to attack, especially when network defenses alone are insufficient.
5. Security is not an On/Off switch
6. Photo Credit: johnjoh on Flicker, CC BY-SA 2.0.
7. Source: 
 McCandless (2015)
8. Variety of hacking actions within Web App Attacks patterns (n=205) Source: Verizon DBIR (2015), p 41
9. Major Preventable Flaws • Compromised staff credentials, which would be preventable by two-factor authentication • Automated technical exploits, that are aggressively applied over a large number of sites, succeeded because basics are ignored • Poor security, including unencrypted backups, leading to an unauthorized person having access to both the data and the means to read it
10. Hoglund, Greg , and Gary McGraw. (2004) Exploiting Software, p 9. “Most outsourced software (software developed off-site by contractors) is full of backdoors…. Companies that commission this kind of software have not traditionally paid any attention to security at all” (2004).
11. Security-based Development Adapting heavy Security Enhanced Software Development Lifecycle to an Agile approach
12. Security is a Requirement
13. 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
14. Protect Data in All Its States Source: McCumber. 1991
15. User Stories 
 & Abuser Stories I want an easy login experience I want to obtain credentials and steal things
16. User Stories Are composed of three aspects: 1. a written description of the story used for planning and as a reminder 2. conversations about the story that serve to flesh out the details of the story 3. tests that convey and document details and that can be used to determine when a story is complete
17. As a Visitor, I can create a new account by filling in my e-mail address and desired password Security Notes: • Can we verify that the user really has the email address on signup? • The password should be at least 12 characters long and should definitely allow for spaces and punctuation
18. As a Staff member, I can choose the “Assist Customer” button to login in as that customer to provide him or her with excellent service. Security Notes: • We need to have a ton of logging around this feature • Staff members should be required to have authenticated with two-factor so that we do not have an unauthorized person accessing this with just a staff credential • Let’s identify certain private fields that customer service does not need access to while helping the customer. Those should be restricted; can we use the database SQL permissions to raise an exception if any of those fields is accessed while using this feature?
19. Attack Stories • As an authenticated customer, I see what looks like my account number in the URL, so I change it to another number to see what will happen. • As an authenticated customer, I paste HTML that includes JavaScript into every field possible to see what happens. • As a Malicious Hacker, I want to gain access to this web application’s Rackspace Cloud account so that I can lock out the legitimate owners and delete the servers and their backups, to destroy their entire business
20. High Level Abuse Stories • As a disgruntled employee who will soon be fired, I want to permanently delete as much data as possible, so that I can cause chaos. • As a scam artist, I want to obtain employee names, addresses, and social security numbers, so that I can steal their identity and finance a Corvette under their name. • As a competitor, I want to be able to look at confidential designs, so that I can beat you to market. Source: Fitzer, James R. Agile Information Security, p 37
21. A secure file upload system example
22. 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.
23. 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
24. Security notes • 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.
25. 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
26. 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
27. models/SecureAttachment.rb Notice the processors and styles options to has_attached_file
28. lib/paperclip_processors/ pgp_encrypt_to_finance_team.rb A simple encryption filter using the gpgme gem, that interfaces with GnuPG on the server
29. Stored on an OpenStack Files Container Automatic Delete, Random File Names that give no information about the file. Amazon S3 would work as well.
30. Additional Practical Countermeasures • Read the OWASP Top 10 • Use Secure HTTP Headers and enable SSL-only with Strict-Transport Security on all production sites • Run automated audit tools, such as Brakeman, Bundler-audit, Code Climate, and Linters • Use GnuPG (or PGP) as part of your workflow • Practice on the OWASP Railsgoat!
31. Thanks!
32. 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
33. • Rietta builds security into every layer of every system we make. • Security is at the heart of everything we do. Crazy bank-level security. • So you know your, and your customers', information is safe. And someday you'll thank us for it. A Security-based Development Firm