1 / 39

Where worlds collide…

Where worlds collide… PCI-DSS for OWASP Practitioners OWASP Day NZ July 2009 Introduction Dean Carter aka fosm Principal QSA and Senior Consultant Leader of the Security Advisory Services team

arleen
Télécharger la présentation

Where worlds collide…

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Where worlds collide… PCI-DSS for OWASP Practitioners OWASP Day NZ July 2009

  2. Introduction • Dean Carter aka fosm • Principal QSA and Senior Consultant • Leader of the Security Advisory Services team • QSA, CISSP, CISM, GREM, CCNA, CCA, MCDBA, MCSE, MCP+I, Dip. QA, Cert QA and BSC (Bronze Swimming Certificate) etc etc etc • A multitude of exams does DO NOT prepare you for real life! • Real life background in Financial Services, Telecommunications and Media, Government and other • Prior to IT spent 8 years in Quality Assurance

  3. Why am I here? • PCI applies if you store, process or transmit cardholder data • OWASP is directly referenced in 6.5 of PCI-DSS • 56% of organisations fail PCI section 6 • “develop and maintain secure systems and applications” • Every vendor wants to sell you a shiny solution to “fix PCI” • I’m not here to sell you anything or baffle you with made-up statistics • I will show you how OWASP can assist your PCI compliance efforts

  4. Overview 1 High Level Overview of the PCI-DSS 2 Applying OWASP to PCI-DSS issues Card breaches and exposures 3 4 Closing comments and questions

  5. Pointing out the obvious… Compliant does not equal secure!

  6. 1 High Level Overview of the PCI-DSS Applying OWASP to PCI-DSS issues Card breaches and exposures Closing comments and questions

  7. PCI – Welcome to Acronym City! Here are just a few key acronyms for today: PCI-DSS = PCI Data Security Standard QSA = Qualified Security Assessor CHD = Card Holder Data PAN = Primary Account Number SAD = Sensitive Authentication Data

  8. Card Holder Data (CHD)

  9. Why do we need the PCI-DSS? “Data breaches were a leading cause of financial fraud against consumers in 2008 and were the source for much payment card fraud, which was the most-common fraud type.” Source: Gartner - 2008 Data Breaches and Financial Crimes Scare Consumers Away - G00165825- Feb 2009

  10. Evolution of attacks

  11. PCI–DSS – Who does it affect? • Anyone who transmits, processes or stores payment card data • Yes, this include Debit Cards with Card Brand logos! • For example… • Merchants • Trademe.co.nz • 1-day.co.nz • Your local supermarket • Paystations in parking buildings • Service Providers • Paymark aka ETSL (payment gateway) • DPS (payment gateway) • Datacom (IT services provider) • Rivera (web hosting) Source: PCI-SSC website – Asia-Pac Participating Organisations

  12. PCI intent - in one sentence… Protect card holder data from inappropriate disclosure

  13. Show me the PCI-DSS…

  14. OWASP context…

  15. Is there a PCI silver bullet? • No, there isn’t • There is no Santa or Tooth Fairy either…. Sorry! • No single product solution can solve your compliance issues • BUT! As we will shortly see, use of OWASP initiatives is a key ingredient to success • You still need to read and comprehend the OWASP Development Guide • You still need to read and comprehend the PCI-DSS v1.2 • I’m just here to convince you the value of reading both and applying the knowledge you will gain!

  16. High Level Overview of the PCI-DSS 2 Applying OWASP to PCI-DSS issues Card breaches and exposures Closing comments and questions

  17. OWASP PCI Project • OWASP PCI Project Goal • “To build and maintain community consensus for managing regulatory risk of web applications. For those with existing website security programs, to ensure their activities uniformly meet PCI requirements, and for those getting started - to aid in building a website security strategy that also ensures sustainable PCI compliance” Link: http://www.owasp.org/index.php/Category:OWASP_PCI_Project

  18. Where PCI assessments fail… Source: VeriSign, based on 112 assessments

  19. Applying OWASP… Source: VeriSign, based on 112 assessments

  20. Requirement 3 Protect stored cardholder data • Rule 1– You must not store Sensitive Authentication Data (SAD) • Principle 1 – if you don’t need it, DON’T store it! • Principle 2 – if you must store PAN then first consider: • Outsourcing • Truncation • Tokenisation • The next option is encryption….

  21. Tokenisation • The PAN is replaced with a 16-character unique identifier called a “Token.” • Tokens are used to indirectly reference cardholder data that is stored in a separate database, application, or offsite secure facility • 4000 0012 3456 7899 -> 2eh193a0362b351d • Reduces scope but does not remove the need to be PCI compliant

  22. Truncating • If you don’t need, don’t store it! • Truncation: • eg: 4000 00XX XXXX 7899 • NB: When you truncate to “first 6, last 4” of the PAN, then you no longer are storing CHD

  23. Encryption – Golden Rules Encrypt data at the point of capture Only decrypt when required Use industry standard algorithms Protect your keys

  24. Requirement 6 Develop and maintain secure systems and applications

  25. Requirement 6.3 • “Develop software applications in accordance with PCI DSS (for example, secure authentication and logging) and based on industry best practices, and incorporate information security throughout the software development life cycle” • Build security into your applications: • Input validation • Error handling • Secure cryptographic storage • Secure communications • Role-based access control

  26. Requirement 6.3.7 • “Review of custom code prior to release to production or customers in order to identify any potential coding vulnerability • Code reviews ensure code is developed according to secure coding guidelines such as the Open Web Security Project Guide (see PCI DSS Requirement 6.5).” Test that the application was built securely OWASP Testing Guide

  27. Requirement 6.5 • “Develop all web applications (internal and external, and including web administrative access to application) based on secure coding guidelines such as the Open Web Application Security Project Guide. Cover prevention of common coding vulnerabilities in software development processes, to include the following:” Check for the 10 most common vulnerabilities Yes! The OWASP Top 10…

  28. 6.5 – OWASP Top 10

  29. Bonus Rant: 12.1.2 • 12.1 Establish, publish, maintain, and disseminate a security policy that accomplishes the following: • 12.1.2 Includes an annual process that identifies threats, and vulnerabilities, and results in a formal risk assessment. Annual threat risk assessment The most under-rated , most overlooked aspect of the PCI-DSS Refer to OWASP section on Threat Risk Modeling Keep in mind that new threats will emerge targeting old code

  30. High Level Overview of the PCI-DSS Applying OWASP to PCI-DSS issues Card breaches and exposures 3 Closing comments and questions

  31. CHD – it gets everywhere!!!! Just a few places I have found CHD recently!

  32. Recent CHD exposures

  33. Commentary on exposures • So, what is my point? CHD is exposed by: • Theft of documents • Poor document disposal • Skimming / fake PoS terminals • WiFi attacks • “Rogue” employees and careless “trusted” third parties • Theft of computers laptops, desktops and servers • Configuration errors • Web site compromises • Unencrypted data being stored • Application of OWASP concepts reduces the attack surface!

  34. High Level Overview of the PCI-DSS Applying OWASP to PCI-DSS issues Card breaches and exposures 4 Closing comments and questions

  35. Fixing legacy systems • If you find yourself fixing an existing PCI system…. • Ask yourself….Is it really fixed? • Confirm, confirm, confirm! • In my experience the storage of CHD may have been fixed at a point in time…. • What about the historical data? • Was it cleaned it up? • Backups? • Paper records? • Have hard disks been scrubbed?

  36. Real Life Example • An example of how things can turn to cactus… • So… you think you are compliant…. • You have invested a LOT of time and effort • You read the PCI-DSS • You convinced your developers to read the PCI-DSS and OWASP • You hired a QSA • What could possibly go wrong? • Your QSA finds PANs on your system on the last day of assessment • WTF? • Yeah...sods law… a gateway failed so you failed back to an old piece of code…

  37. Parting Thoughts The challenge is to achieve, maintain AND validate compliance Secure application development is a key activity OWASP is great, free resource to assist you Reduce scope by reducing card holder data storage Complying to a standard is a minimum goal not an end goal

  38. Useful Links www.pcisecuritystandards.org www.owasp.org www.owasp.org/index.php/Category:OWASP_PCI_Project www.aegenis.com www.pcianswers.com www.storefrontbacktalk.com www.privacyrights.org/ar/ChronDataBreaches.htm http://risky.biz www.security-assessment.com

  39. Thank you Questions? Email: dean.carter@security-assessment.com

More Related