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 High Level Overview of the PCI-DSS Applying OWASP to PCI-DSS issues Card breaches and exposures Closing comments and questions

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

6. 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… The 12 Requirements of the PCI-DSS v1.2 1Install and maintain a firewall configuration to protect cardholder data 2Do not use vendor-supplied defaults for system passwords and other security parameters 3Protect stored cardholder data 4Encrypt transmission of cardholder data across open, public networks 5Use and regularly update anti-virus software or programs 6Develop and maintain secure systems and applications 7Restrict access to cardholder data by business, need-to-know 8Assign a unique ID to each person with computer access 9Restrict physical access to cardholder data 10Track and monitor all access to network resources and cardholder data 11Regularly test security systems and processes 12Maintain a policy that addresses information security for employees and contractors

14. OWASP context… The 12 Requirements of the PCI-DSS v1.2 1Install and maintain a firewall configuration to protect cardholder data 2Do not use vendor-supplied defaults for system passwords and other security parameters 3Protect stored cardholder data 4Encrypt transmission of cardholder data across open, public networks 5Use and regularly update anti-virus software or programs 6Develop and maintain secure systems and applications 7Restrict access to cardholder data by business, need-to-know 8Assign a unique ID to each person with computer access 9Restrict physical access to cardholder data 10Track and monitor all access to network resources and cardholder data 11Regularly test security systems and processes 12Maintain a policy that addresses information security for employees and contractors

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 Applying OWASP to PCI-DSS issues Card breaches and exposures Closing comments and questions

17. OWASP PCI Project  Link: http://www.owasp.org/index.php/Category:OWASP_PCI_Project “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” OWASP PCI Project Goal

18. Where PCI assessments fail… PCI Requirement % of failures 3Protect stored data79% 11Regularly test security systems and processes74% 8Assign a unique ID to each person with computer access71% 10Track and monitor all access to network resources and cardholder data71% 1Install and maintain a firewall configuration to protect cardholder data66% 2Do not use vendor-supplied defaults for system passwords and other security parameters 62% 12Maintain a policy that addresses information security for employees and contractors 60% 9Restrict physical access to cardholder data59% 6Develop and maintain secure systems and applications56% 4Encrypt transmission of cardholder data across open, public networks45% Source: VeriSign, based on 112 assessments

19. Applying OWASP… PCI Requirement % of failures 3Protect stored data79% 11Regularly test security systems and processes74% 8Assign a unique ID to each person with computer access71% 10Track and monitor all access to network resources and cardholder data71% 1Install and maintain a firewall configuration to protect cardholder data66% 2Do not use vendor-supplied defaults for system passwords and other security parameters62% 12Maintain a policy that addresses information security for employees and contractors 60% 9Restrict physical access to cardholder data59% 6Develop and maintain secure systems and applications56% 4Encrypt transmission of cardholder data across open, public networks45% Source: VeriSign, based on 112 assessments

20. Requirement 3  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…. Protect stored cardholder data

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  Build security into your applications:  Input validation  Error handling  Secure cryptographic storage  Secure communications  Role-based access control “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”

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 PCI Requirement / OWASP Top 10 6.5.1Cross-site scripting (XSS) 6.5.2 Injection flaws, particularly SQL injection. Also consider LDAP and Xpath injection flaws as well as other injection flaws. 6.5.3 Malicious file execution 6.5.4 Insecure direct object references 6.5.5 Cross-site request forgery(CSRF) 6.5.6 Information leakage and improper error handling 6.5.7 Broken authentication and session management 6.5.8 Insecure cryptographic storage 6.5.9 Insecure communications 6.5.10 Failure to restrict URL access

29. Bonus Rant: 12.1.2  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 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.

30. High Level Overview of the PCI-DSS Applying OWASP to PCI-DSS issues Card breaches and exposures 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 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.pcisecuritystandards.org  www.owasp.org www.owasp.org  www.owasp.org/index.php/Category:OWASP_PCI_Project www.owasp.org/index.php/Category:OWASP_PCI_Project  www.aegenis.com www.aegenis.com  www.pcianswers.com www.pcianswers.com  www.storefrontbacktalk.com www.storefrontbacktalk.com  www.privacyrights.org/ar/ChronDataBreaches.htm www.privacyrights.org/ar/ChronDataBreaches.htm  http://risky.biz http://risky.biz  www.security-assessment.com www.security-assessment.com

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