Coding under PCI's Death Grip

A short (5 minute) talk on developing under the constraints and requirements of the PCI DSS. Presented at the Sydney Ruby meet up, Tuesday 8th of May 2012.

Transcript

1. Matthew Savage - Director of IT & Security @ Fat Zebra Coding under PCI’s Death Grip fatzebra.com.au
2. PCI-DSS • Designed to keep your credit card data safe • (Un)fortunately there are developer requirements: Requirement 6: Develop and maintain secure systems and applications Unscrupulous individuals use security vulnerabilities to gain privileged access to systems... For in-house developed applications, numerous vulnerabilities can be avoided by using standard system development processes and secure coding techniques. Requirement 6.3: Develop software applications (internal and external, and including web based administrative access to applications) in accordance with PCI DSS (for example, secure authentication and logging), and based on industry best practices. Incorporate information security throughout the software development life cycle. These processes must include the following... (Source: http://bit.ly/pci-dss-v2, PCI-DSS 2.0 Manual, Pages 38 & 39)
3. How does this apply to me? • Your transmit credit card data in any form (plain or encrypted), including: • Card Number • Magnetic Stripe Data (all tracks) • CVV, CSC, CAV, CVC, ABC, whatever else everyone calls it - colloquially known as those ‘three digits on the back of your card’ •Even if you don’t handle credit card data these concepts apply to you - secure coding isn’t exclusive •PCI-DSS also applies to merchants - however most aren’t aware of this
4. What needs to be done? •Be security conscious and informed - read the great RoR security guides: http://guides.rubyonrails.org/security.html •Never trust user input - validate everything •Say no to (SQL) injections - don’t let your database suffer •Never, ever, ever store cardholder data • You must never store the CVV... ever. • You should also never store the card number - mask it, or let your gateway store it and keep the token (unless you are Fat Zebra) http://xkcd.com/327/
5. Sanity Checks - because Humans are fallible •No tool will ever replace awareness and being proactive •But they can help...: Verification, Awareness of problems, guards against deploying with vulnerabilities... •Static Analysis with Brakeman: Analyse your Rails project for possible issues and put the brakes on your insecure releases •Tie Brakeman into your CI for extra awareness points brakemanscanner.org
6. And other options...? •What value do you put on your site? •Consider how much a breach could cost you, then weigh up the cost of services such as external scanners: •Regular (weekly...?) scans help keep on top of any vulnerabilities •Discover issues before an attacker does - be pro-active •Synergy! •The ‘site seals’ don’t really build confidence - they are just great SEO for the scanners
7. Thinking about PCI? •Don’t do it alone - its a nightmare! •Find a good assessor and work closely with them •Once you implement a PCI policy make sure its enforced and updated •Remember that PCI Compliance is a yearly thing
8. Twitter/fat_zebra Twitter/amasses Matthew Savage - all round nice guy Questions? ? JOIN US matthew.savage@fatzebra.com.au Feel free to email, tweet, send smoke signals (may not get direct answers) or buy me coffee (will get direct answers)
9. JOIN US Thanks! matthew.savage@fatzebra.com.au Matthew Savage - Masters in Modesty (UNSW) Twitter/fat_zebra *not a real degree Slides available from bit.ly/pci-deathgrip