on Twitter How a Ruby/Rails developer can help prevent a Data Breach This topic is expansive and the time that I have allotted is short. My goal is that in the next 45 minutes, to give you all a chance to learn about the anatomy of a data breach and a practical framework for you to think more clearly about security risks and appropriate countermeasures. ! I am the CEO of a development shop with team members here in Atlanta, GA, and in Nashville, TN. We work primarily with startup companies that are building out their web app and infrastructure. Our latest projects are involving Ruby on Rails 4 on the backend with AngularJS based front-end clients. ! The big ideas: (1) Security is about balancing risks, (2) security does not have to significantly increase development costs if the developers pay attention in the early design, (3) protecting our users and clients is ethically important, (4) defense in depth means that you always use multiple concurrent mechanisms to protect information.
boolean YES or NO answer to this question, universally, by the end of this talk, we should be in a position to think systematically about this fundamental question. !
what? 2. What is the worst thing that can happen? 3. Compared to what alternative? Two questions that will instantly make you a security expert… Secure against what? A question about your threat model. What is the worst thing that can happen? What is the cost of a failure of security? Compared to what? Is your in-house, PHP solution, more secure? Really? ! ! !
API token is a security mechanism used in many REST APIs to allow access to a server and its resources without a user’s username and password being needed. Formally, it is a bearer token, that is it is a security capability that is an identifiers for which the mere possession grants access. ! See https://en.wikipedia.org/wiki/Capability-based_security for more on capability-based security architecture design. ! For the Ruby code for this demo, see https://github.com/rietta/ApiTokenDemo/.
want to create an API token system for our REST API so that clients can get a token and then commands on behalf of a user or an organization. We did not want to just generate a short random string because of the chance of collisions. The UUID is a very tempting mechanism for this and Stack-overflow suggests that it may be a way to go. Should we use it as our API token?
want to create an API token system for our REST API so that clients can get a token and then commands on behalf of a user or an organization. We did not want to just generate a short random string because of the chance of collisions. The UUID is a very tempting mechanism for this and Stack-overflow suggests that it may be a way to go. Should we use it as our API token?
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 Nope! A UUID makes a terrible security token. It’s right there in the standards document that defined it. Brandon Dees explains it well: Main thing is uuid -> unique within a system, but not random / unguessable, secure random -> random / unguessable depending on the number of bits, but there is no built in guarantee of uniqueness, although at a certain level of bits it is just as unlikely as uuid ! If you want a guaranteed unique id that is also unguessable, you have to concatenate the UUID with something random. 20+ bytes is enough to be implausible to brute-force if there is any rate-limiting. For comparison 16 ASCII characters can represent a 128 bit value and 32 characters a 256 bit value, which are the common key lengths used alongside AES for full partition disk encryption.
just a username and a really good random password. See has_secure_password, http://api.rubyonrails.org/classes/ActiveModel/SecurePassword/ClassMethods.html. ! api_username = SecureRandom.uuid().gsub('-', ‘') api_password = SecureRandom.hex(56)} generated_token = “#{api_username}:#{api_password}".strip ! The result looks like this…
dashes in the UUID Add a long randomly generated password Colon as a separator character The UUID is the username and the random string after it is a random password. The server treats this password as a has_secure_password secret and thus is reasonably secure against guessing. Bcrypt is good at this sort of password security. ! See https://github.com/rietta/ApiTokenDemo for a demo implementation that uses has_secure_password in Rails 4.
has helped shape my career. It was in 2006 and I was taking a graduate-level software project management class. We were writing use cases for the system and I kept wanting to address application security.
professor And he was technically right! But at the same time, this is a devastating point of view because it meant that security was not going to be part of the design process that the budding project managers were going to be learning and taking back to their day jobs.
and it cannot be adequately bolted on at the end nor can it be provided by the system architecture alone without being part of the fundamental web application and business model design. Security has to be part of the mindset throughout the development process, from your user story writing workshop to the final implementation and deployment details, to active monitoring in production. ! But, at the end of the day, Security is all about…
management. It’s about identifying ! In Beyond Fear, Bruce Schneier, presents a foundation of using a series of 5 questions to evaluate a security problem and compensating control: ! 1. What assets are you trying to protect? 2. What are the risks to these assets? 3. How well does the security solution mitigate those risks? 4. What other risks does the security cause? 5. What costs and trade-offs does the security solution impose? !
a secure API token - it’s a username and password. • Data breaches • Professional ethics • The OWASP top 10 and Secure Headers The total talk is one hour. I believe that it will be an interactive discussion, though I plan to leave 20 minutes for question and discussion. ! This is the conference talk version of the presentation. Lecture, followed by Q&A.
your company Security faces the weakest link problem. That is, the security of the entire system is only as secure as the weakest of its countermeasures. ! It’s important to remember that the insider threat is real. It’s not just that an employee in your company has to go rogue either. ! If an attacker gains access to a team member’s password, he can maliciously gain access to the information that that employee had access to. If there are not additional security measures to prevent the access other than the compromised password then there is a data breach. Restricting information based on the principle of least privilege and having two-factor authentication would be two layers in a defense to protect the sensitive information that a customer service agent has access to. ! Additionally, anything that the customer service agent has access to is something that a Social Engineering attack can talk that employee into divulging inappropriately. It was just this sort of attack that Kevin Mitnick was famous for. His Ghost in the Wires: My Adventures as the World’s Most Wanted Hacker [Kindle Edition] is a great read to learn how he did it. In the end, he compromised major companies as a conman, not through Hollywood movie plot technical attacks.
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 Above the yellow line, you have some wiggle room. Between the yellow and the red line is the uncanny valley of personal information and below the red line, enhanced security countermeasures are highly advised. —- You may be familiar with information classification in the military, you hear about secret or top secret information. In a commercial application, such as yours there are other categories of information. The five categories are Public, Internal Use, Confidential, Sensitive, and Highly Sensitive. Most business information is Internal Use, most customer data is Confidential, except that checking account numbers and payment data and drivers license details are Sensitive. Encryption keys and staff passwords are Highly Sensitive. For more, see the Information Classification section. ! The Georgia Institute of Technology has a slightly different, four tier classification system. It’s worth reading about and helped me as I developed this classification. ! DATA CATEGORIES FOR THE INSTITUTE The term data classification used in this guide should not be confused with the practice of handling or working with “classified data” (e.g. Government Classified data). Georgia Tech classifies all data into one of four Data Categories. !
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 One irony to security countermeasures is that often mitigating one risk in a security system makes it more brittle to another risk. ! Security is about paying attention to the many relative risks faced by a system and deploying countermeasures that address those risks with acceptable tradeoffs. ! A great essay to read is Rare Risk and Overreactions https://www.schneier.com/blog/archives/2007/05/rare_risk_and_o_1.html ! Before we get started with the question of data breaches, I want to start with…
though usually, with things more subtle than the average computer user Photo Credit: Lisamarie Babik / Wikipedia On the next slide, we will see a case in point… ! Image is used under the terms of the Creative Common License, with attribution given. Photo Source: https://en.wikipedia.org/wiki/File:Pair_programming_1.jpg Photographer: Lisamarie Babik This image, originally posted to Flickr, was reviewed on February 23, 2010 by the administrator or reviewer File Upload Bot (Magnus Manske), who confirmed that it was available on Flickr under the stated license on that date.
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) The wikipedia article goes on to say that: “Data breaches may involve financial information such as credit card or bank details, personal health information (PHI), Personally identifiable information (PII), trade secrets of corporations or intellectual property…”
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 Most states have similar statues. PII is defined by State and Federal laws, including the Georgia data breach law. You can access GA law online at http:// www.lexisnexis.com/hottopics/gacode/banner.htm.
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 financial data PCI DSS version 2.0 consists of six core principles, supported by 12 accompanying requirements, and more than 200 specific procedures for compliance. These include • Principle 1: Build and maintain a secure network: • Requirement 1: Install and maintain a firewall configuration to protect cardholder data. • Requirement 2: Don’t use vendor-supplied defaults for system passwords and other security parameters. • Principle 2: Protect cardholder data: • Requirement 3: Protect stored cardholder data. • Requirement 4: Encrypt transmission of cardholder data across open, public networks • Principle 3: Maintain a vulnerability management program: • Requirement 5: Use and regularly update antivirus software. • Requirement 6: Develop and maintain secure systems and applications. • Principle 4: Implement strong access control measures: • Requirement 7: Restrict access to cardholder data by business need-to-know. • Requirement 8: Assign a unique ID to each person who has computer access. • Requirement 9: Restrict physical access to cardholder data. • Principle 5: Regularly monitor and test networks: • Requirement 10: Track and monitor all access to network resources and cardholder data. • Requirement 11: Regularly test security systems and processes. • Principle 6: Maintain an information security policy: • Requirement 12: Maintain a policy that addresses information security. ! Penalties for non-compliance are levied by the payment card brands and include not being allowed to process credit card transactions, fines up to $ 25,000 per month for minor violations, and fines up to $ 500,000 ! Miller, Lawrence C.; Peter Gregory (2012-07-20). CISSP For Dummies (Kindle Locations 10038-10056). Wiley. Kindle Edition.
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 From the FAQ: Were any of my Bitlinks affected or changed? No. The production database was never compromised nor was there any unauthorized access to our production network or environment. The data was from an offsite static backup. There was no risk of any data, including redirects, being changed. ! Bitly says it has learned about the breach from the security team of another technology company, but the organization in question has not been named. ! It turns out that the attackers gained access to the database backup through a compromised employee account. ! “We audited the security history for our hosted source code repository that contains the credentials for access to the offsite database backup storage and discovered an unauthorized access on an employee’s account,” Bitly CTO Rob Platzer notes in a blog post. ! “We immediately enabled two-factor authentication for all Bitly accounts on the source code repository and began the process of securing the system against any additional vulnerabilities.” ! Additional actions subsequent to the breach
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. You cannot account for everything and polices can be bypassed by users. Furthermore, security is a weakest link problem. Can you think of reasons that the employee was encouraged to copy data in an insecure manner using the external disk? If you were a developer on the project that built the IT system that is in use, what could you do in the design phase to minimize the need of employees to copy data in such a manner? ! Further reading • Humana Data Breach in Atlanta for an Unencrypted USB Disk (rietta.com) • Humana security breach could affect 3,000 local members (11alive.com)
company recently discovered a cyberattack that comprised a small number of employee log in credentials, allowing unauthorized access to eBay’s corporate network. As a result, a database containing encrypted password and other non-financial data was compromised. There is no evidence of the compromise affecting accounts for Paypal users, and no evidence of any unauthorized access to personal, financial or credit card information, which is stored separately in encrypted formats. The company is asking all eBay users to change their passwords.” ! http://www.ebayinc.com/in_the_news/story/faq-ebay-password-change
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. http://www.databreaches.net/e-mail-gaffe-exposed-ruby-tuesday-employee-financial-data-to-a-former-employee/ ! An e-mail gaffe by a Support Center employee Ruby Tuesday exposed current employees’ information to a former employee. ! The spreadsheet, inadvertently attached to the July 8 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.
authentication that does not rely an your users’ phones! See http://yubico.com. If you just want 2FA then the standard Yubikey cost half the Neo. They have a variety of options from you to choose from based upon your organization’s need. ! Photo by Frank Rietta.
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. Abuse stories with your 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. Abuse stories with your user stories. ! Until Rails supports different database credentials per controller, use multiple smaller applications in a service-oriented architecture where each app has its own database credentials with restricted access to the minimal information needed to do that particular job.
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 Abuse stories with your user stories.
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 Abuse stories with your user stories.
from Kernel Concepts in Germany and an inexpensive USB smart card reader that I bought on Amazon for about $10. ! It may in fact be the best option for some environments as part of a comprehensive defense in depth strategy. ! Photo by Frank Rietta.
• 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. • Links • https://github.com/ueno/ruby-gpgme • https://github.com/attr-encrypted/attr_encrypted • http://www.postgresql.org/docs/9.3/static/pgcrypto.html
Management • Cross-Site Scripting (XSS) • Insecure Direct Object References • Security Misconfiguration The OWASP top ten is a compilation of the 10 most critical web application security risks faced by all apps. ! These are but a small few examples of how a data breach can happen. ! PII is inadvertently published to an open location and becomes accessible to Google A SQL injection attack leaks database records An attacker gains unauthorized access to the web server through a Rails vulnerability and there is no way to prove that records were not accessed A database backup is exposed because the backup keys were in a Github repository and the database was not encrypted A customer service agent’s password is compromised and no additional factors stand in the way of the attacker from accessing PII
Function Level Access Control • Cross-site Request Forgery (CSRF) • Using Components with Known Vulnerabilities • Unvalidated Redirects and Forwards The OWASP Top 10 2013 http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202013.pdf !
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 HSTS is my favorite. And if you are really, really serious there is https://hstspreload.appspot.com/. If accepted, your site will be added to the Google Chrome HSTS list and Chrome will never, ever, ever get back together with your unencrypted port 80 on your web server. Only SSL from now on. ! An example of enabling HSTS in Apache is this command in your sites-enabled/domain.conf Header set Strict-Transport-Security "max-age=16070400; includeSubDomains” ! 16070400 seconds is a little over 6 months. Meaning that a browser will not reconnect with your non-SSL site at all for 6 months. And if you have an SSL only site then all that plaintext endpoint should be doing is redirecting back to your SSL site. ! — The list on this slide is an adaptation of slide 13 of Modern Software is Like Lego & WTF Don’t People Use Secure Headers? OWASP presentation by Mark Curphey @curphey. That presentation goes on to provide statistics about the rate that these security features were observed in use on group of surveyed sites: • 205 sites implement CSP (0.002%) • 1,955 sites implement HSTS (0.02%)
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) The important thing to remember that there is no end-state in security. Unless you want to shut down your computers and live in a concrete bunker. Rather, security is a continual process driven by knowledge and seeking information.
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 The author, Ben Poweski is on Twitter at https://twitter.com/bpoweski.
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. Yubikey devices are inexpensive and effective and there is a Gem that can be integrated with a Rails app easily to enable 2FA with it. See https:// github.com/titanous/yubikey. ! brakeman is a good security tool and using it is a good start to improving your application’s security. https://rubygems.org/gems/brakeman
you agree… http://twitter.com/frankrietta 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.
rietta
cer
riofujimon
wenas
ikumatadokoro
memory1994
hsawaji
happymana
nekomatu
little_rubyist
har1101
qnighy
maruto
samanthasiow
quramy
caitiem20
honnibal
brettharned
chriscoyier
colly
tanoku
speakerdeck
shlominoach
sugarenia
jcasabona
