PCI DSS and PA-DSS

1. OWASP Education Computer based training PCI DSS and PA-DSS Nishi Kumar IT Architect Specialist, FIS Chair, Software Security Forum at FIS OWASP CBT Project Lead OWASP Global Industry Committee Nishi.Kumar@owasp.orgContributor and Reviewer Keith Turpin Reviewer Kuai Hinojosa Christian Heinrich

2. Objectives • Understand PCI compliance • Know most common PCI issues • Understand PCI DSS and PA-DSS requirements • Understand the mapping between OWASP Top 10 for 2010 and CWE/SANS Top 25

3. PCI – Payment Card Industry “The PCI Data Security Standard represents a common set of industry tools and measurements to help ensure the safe handling of sensitive information…the standard provides an actionable framework for developing a robust account data security process - including preventing, detecting and reacting to security incidents.” – PCI Standards Council

4. DSS in a nutshell • The PCI (Payment Card Industry) DSS (Data Security Standard) is: • A set of minimumbaseline controls for securing payments • Required (everyone in the payment lifecycle must comply) • A unified standard agreed to by all card brands

5. A unified standard

6. Everyone must comply (resistance is futile) Everyone must be compliant with the standard

7. Lifecycle Process for Changes • PCI change management process

8. PCI – Payment Card Industry There are two sets of standards developed based on the type of payment application PCI DSS – PCI Data Security Standard PA-DSS – Payment Application Data Security Standard Payment applications that are sold, distributed or licensed to third parties are subject to the PA-DSS requirements

9. PA-DSS • Formerly known as -PABP (Payment Application Best Practices) supervised by Visa • Goals • Develop secure payment applications that do not store prohibited data, such as full magnetic stripe, CVV2 or PIN data • Ensure their payment applications support compliance with the PCI DSS • The requirements for the PA-DSS are derived from the PCI DSS

10. PCI DSS PCI DSS only applies if PANs are stored, processed and/or transmitted.

11. The most common PCI audit issues…

12. PCI – Payment Card Industry • Most of the time, it’s one or more of the “deadly half-dozen”: • If you can get past these, you’re in pretty good shape

13. Enemy #1: Inappropriate Scope • #1 most common assessment issue • Remember, the assessment scope applies only to the Cardholder data environment (CDE) • Cardholder environment: systems that store, process, or transmit cardholder data • The assessor must include everything in scope that is not segmented from the CDE • No segmentation? Then the assessor must include everything in scope • This is where everybody starts • This approach rarely (never?) leads to a clean Report of Compliance (ROC)

14. Scoping Example • Red area denotes scope of PCI assessment

15. The Solution: Zones (Enforcement of Scope) • Once you have defined the scope of the CDE, you need to enforce it usually with: • Firewalls • Physical separation (“air gap”) • If you don’t enforce the scope, again the assessor must evaluate the entire environment • Document it • Document how your zoning approach enforces the scope • Document why you’ve chosen the approach you have • Document who is responsible for maintaining the boundary

16. Enemy #2: Inadequate Documentation • Remember, the requirements aren’t “rocket science” • Chances are good you are already (mostly) compliant • But “if there’s no document, it doesn’t exist” • QSA(Qualified Security Assessor) must disregard ad-hoc or informal processes • Which means you need to have documented policy and defined procedures • You need to document – even if you’re pretty confident that your process meets the requirement

17. The Solution: They have to document as well… • “Forewarned is forearmed” • QSA’s must follow the defined assessment procedures. This means everything they are going to do, look for, evaluate, request, or sample is written down and can be found online • If you had the answers to a test ahead of time, wouldn’t you at least glance at it while studying? • https://www.pcisecuritystandards.org/security_standards/documents.php?agreements=pcidss&assocation=PCI%20DSS

18. Enemy #3: Apps • Apps are hard, no matter how you slice it • The requirements for apps are pretty tough • OWASP Guide (OWASP “Top Ten”), CWE/SANS Top 25, CERT Secure Coding • Lifecycle requirements • Requirements for code review and “application-level firewall” (this means “a web application firewall (WAF)”*) • Need to have a solid strategy for application security in place

19. Solution : Apps • Read OWASP • The application requirements are verbatim from the OWASP Guide (OWASP Top 10), CWE/SANS Top 25 and CERT Secure Coding • Assessor will be looking for a documented SDLC (software development lifecycle) that incorporates specific application security testing • Assessors will usually look at the process first, and only a sample of specific apps

20. Enemy #4: Data Storage • You can’t store authorization data after authorization • Don’t ever store track (magnetic-stripe) data or CVV/CVC. No matter who says to • There are good business reasons to store the PAN • “One click” • If you’re going to store it, you need to protect it • If you store the PAN, you’ll need to encrypt, truncate, or hash • Encrypting the PAN is the only approved way to store it so you can use it later

21. Solution : Data Storage • Limit what you keep • If there’s any way you can get away with it, try not to store the PAN • If we store the pan select a well-vetted algorithm that is currently considered to be strong (e.g., FIPS 140-2 (i.e. Triple-DES, AES, RSA) or an equivalent standard) • Consider a “data deletion” policy to govern storage of cardholder data

22. Enemy #5: Inadequate Compensating Controls • If you can’t meet particular controls, you attempt to apply compensating controls • However, there are specific rules for compensating controls that need to be followed • Not following the rules means your assessor can’t accept it

23. Solution : Inadequate Compensating Controls • Compensating controls need to meet the intent and the rigor of the original requirement • Adding key management doesn’t help you meet an authentication requirement • Compensating controls must be documented • Compensating controls are subjective, document them fully to build your case • Even if you can’t meet a control, document why you can’t and what else you are doing to address the issue • Assessor wants to agree with you. Thorough documentation makes it easy for the assessor to agree • Compensating controls have a shelf life • They’re a “stop-gap”, not an “end state • Example: Lack of encryption on a mainframe would be accepted for a certain period of time

24. Enemy #6: Bad Timing • There are times when you have a fantastic strategy for how to solve an issue, but the QSA can’t use it because it’s not what’s in production • A QSA (Qualified Security Assessors ) can’t validate to what’s not in production • If it’s not in production now, it can’t be in or out of compliance – it’s just not thereNotes: QSA’s are required based on the tiers. You can get this information from http://whatlevelami.com/

25. Solution : Bad Timing Pre-assess and preplan • Read the documentation the assessor will be using to evaluate you • PCI Assessment Procedures available from the PCI Standards Council website (http://www.pcisecuritystandards.org) • PCI Standards Documentation • Pre-assess • Do the pre-assessment questionnaire (even if you don’t have to) • Go through a pre-assessment exercise (with or without a QSA) to make sure you have everything in place before the assessment starts • Deploy compensating controls before use them for the “real deal”

26. PCI DSS Requirements

27. PCI DSS Requirements

28. OWASP Guide, SANS CWE Top 25, CERT Secure Coding PCI DSS Requirements

29. PCI DSS Requirements

30. PA-DSS Requirements

31. OWASP Top 10 & 2010 CWE/SANS Top 25 mapping

32. OWASP Top 10 & 2010 CWE/SANS Top 25 mapping

33. OWASP Top 10 & 2010 CWE/SANS Top 25 mapping • Not a comprehensive or equivalent comparison • OWASP defines ten risks - made up of several specific vulnerabilities • CWE/SANS Top 25 is only a fraction of the full CWE list of weaknesses • Complete mapping will have many CWEs listed for each item on the OWASP Top 10 list • Mapping should be used for general reference purposes only

34. 2010 CWE/SANS Top 25

35. Cert Secure Coding Standards • Establish coding guidelines for commonly used programming languages that can be used to improve the security of software systems under development Based on documented standard language versions as defined by official or de facto standards organizations Secure coding standards are under development for: • The CERT C Secure Coding Standard, Version 2.0 • The CERT C++ Secure Coding Standard • The CERT Oracle Secure Coding Standard for Java

36. Summary • Most issues are preventable • Most of the issues come down to planning and preparation • Planning you do in advance of the assessment translates directly into dollars for your organization • Less time-consuming for the assessment (which means it’ll be cheaper) • A “clean” ROC means you don’t need to pay for do-overs • Comprehensive documentation means less time your staff spends answering questions • Act before the assessment • The time to find out that you have issues is before the assessment • Planning should be thorough – shoot for no surprises once the assessment is underway

37. References • MITRE - http://www.mitre.org/ The MITRE Corporation is a not-for-profit organization that manages several Federally Funded Research and Development Centers. Mitre currently runs various IT security projects including the Common Weakness Enumeration (CWE) and it is the official source for the CWE/SANS Top 25 Most Dangerous Software Errors. CWE Database - http://cwe.mitre.org/ • SANS - http://www.sans.org The SysAdmin, Audit, Network, Security (SANS) Institute operates as a commercial research and education company. SANS is well known for its Internet Storm Center, its comprehensive list computing security training programs and its work with Mitre on the CWE/SANS Top 25 Most Dangerous Software Errors.

38. References • OWASP - www.owasp.org The Open Web Application Security Project (OWASP) Foundation is a not-for-profit organization whose goal is to improve the safety and security of the world’s software. OWASP is probably best known for its key projects, like the Top 10 Web Application Security Risks, and for its application security conferences. • CERT - www.cert.org The CERT® Program is part of the Software Engineering Institute (SEI). CERT's primary objectives include analyzing and communicating the state of internet security through its US-CERT Vulnerability Notes Database and improving software security with its secure coding practices publications. US-CERT Vulnerability Notes Database - http://www.kb.cert.org/vuls/ CERT Secure Coding Practices - http://www.cert.org/secure-coding/