Transitioning from PCI DSS 2.0 to 3.1

Transcription

1 Transitioning from PCI DSS 2.0 to 3.1 What You Need to Know April, 2015 Emma Sutcliffe, Director, Data Security Standards

2 About the PCI Council Founded in Guiding open standards for payment card security Development Management Education Awareness

3 PCI Core Security Standards Protection of Cardholder Payment Data Manufacturers PCI PTS Pin Entry Devices Software Developers PCI PA-DSS Payment Applications Merchants & Service Providers PCI DSS Secure Environments PCI Security & Compliance P2PE Ecosystem of payment devices, applications, infrastructure and users

4 More PCI Standards and Programs PCI HSM Security Requirements PCI PIN Security Requirements Terminal Software Security Guidelines ATM Guidelines document PCI Card Production Mobile Best Practices Qualified Integrator and Reseller Tokenization Product Security Guidelines

5 The Standards Continually Evolve Feedback Research Threat Landscape

6 Feedback and Involvement Board of Advisors Executive Committee Participating Organizations Standards & Operations Committees Task Forces & Working Groups Special Interest Groups

7 Happy New Year! 1 st January 2015 PCI DSS v3.0

8 At a Glance PCI DSS v2.0 to v core security principles of PCI DSS remain Some new sub-requirements that impact PCI DSS security efforts Future implementation dates provided for more significant changes Guidance on business as usual Enhanced testing procedures to clarify level of validation expected for each requirement Aligned language between requirements and testing procedures for consistency Added Guidance Column to clarify intent of each requirement Separate from Report on Compliance (ROC) reporting template

9 New Requirements Effective July 1 st Develop web applications to protect against broken authentication and session management Service providers use a unique authentication credential for each customer Protect card-reading devices used to capture payment card data from tampering and substitution 11.3* Implement a methodology for penetration testing for service providers acknowledgement of responsibility * PCI DSS v2.0 requirements for penetration testing must be followed until v3 is in place.

10 PCI DSS v3.1

11 Types of Changes Change Type Clarification Additional guidance Evolving Requirement Definition Clarifies intent of requirement. Ensures that concise wording in the standards portrays the desired intent of requirements. Explanation, definition and/or instruction to increase understanding or provide further information or guidance on a particular topic. Changes to ensure that the standards are up to date with emerging threats and changes in the market.

12 PCI DSS v3.1 Key Themes Clarification & Guidance Evolving Requirements

13 Summary of Changes

14 PCI DSS v3.1 Change highlights Corrections to format and typographical errors Clarification of language to promote understanding & consistency Clarification & Guidance Updates to guidance column Removal of redundant language Updated compensating control example

15 PCI DSS v3.1 Change highlights Requirement 3.4 new testing procedure to address hashed and truncated PAN in the same environment Clarification & Guidance Requirement 6.6 updated testing procedure to clarify WAF alerts are immediately investigated Requirement 4.2 Included SMS as an example of end-user messaging technology and added guidance Emphasized requirements and testing procedures that apply only if the entity is a service provider

16 PCI DSS v3.1 Change highlights Testing Procedure clarification that both devices and device location be observed Requirement address concerns about daily log monitoring applying to out-of-scope systems Clarification & Guidance Requirement clarified penetration testing is to verify out-of-scope systems are segmented from systems in the CDE Testing Procedure 12.9 clarification for assessors to review templates rather than actual agreements

17 PCI DSS v3.1 Change highlights Evolving Requirements SSL and early TLS no longer considered to be strong cryptography PCI DSS Requirements 2.3, and 4.1

18 Addressing SSL in PCI DSS v3.1 Summary of approach SSL and early versions of TLS are not considered strong cryptography Future sunset date for using these protocols as a security control will be defined to allow time to migrate New implementations should not use SSL or early versions of TLS Existing implementations will need to have a documented plan to address risk mitigation during migration Allowance for POS POI terminals (and the SSL/TLS termination points to which they connect) that can be verified as not being susceptible to any known exploits

19 New and Existing Implementations What is a new implementation? What is an existing implementation?

20 POS POI Environments Why allowance for POI environments?

21 ASV Scans How do SSL vulnerabilities affect ASV scan results?

22 Additional Guidance Information Supplement Clarification on new vs. existing implementations Guidance on allowances for POS POI environments Suggestions/examples of risk mitigation techniques Suggestions/examples on alternative cryptographic options Webinar Available on PCI SSC website

23 Where Do I Begin with the Migration Process? Suggested steps: Identify all system components and data flows that use/support vulnerable protocols Identify business and/or technical need for using the vulnerable protocol Immediately remove or disable instances without a supporting business or technical need Identify technologies to replace the vulnerable protocols Document a migration project plan Implement risk reduction controls Perform migrations and follow change control procedures Update system configuration standards as migrations are completed

24 Understanding PCI DSS v3.1 Review Summary of Changes, FAQs and Information Supplement Work with PCI DSS coordinator, departments involved with payments, and your acquirer or payment brands to understand key questions Determine if SSL or early TLS is used in your environment Plan migration according to PCI DSS and supporting guidance

25 What Else? Supporting documents will also be updated Self-assessment Questionnaires (SAQs) Attestations of Compliance (AOCs) Reporting Templates PCI DSS Glossary of Terms, Abbreviations, and Acronyms Prioritized Approach FAQ Knowledgebase

26 PCI DSS v3.1 Key Themes Clarification & Guidance Evolving Requirements

27 Recent Bulletins & Webinars Shellshock GHOST Backoff

28 Tokenization Product Security Guidelines Technical best practices Security considerations include: Token generation How tokens are retained for use (e.g. in back office systems) and storage Secure implementation controls to address potential attack vectors and mitigate associated risks Just Released!

29 Special Interest Groups Recent Publication Penetration Testing Guidance Difference between vulnerability scans and penetration tests Qualifications of a penetration tester Penetration testing methodology Penetration test reporting guidance and template

30 Making Payment Security Business-as-Usual

31 Maintaining PCI DSS Compliance

32 Compliance vs. Security

33 Challenges of Maintaining Compliance Reliance on annual assessments Pressure to meet customer demands Failing to adapt to changes

34 Implementing PCI DSS into BAU Processes Monitor security control operation Detect and respond to security control failures Understand how changes in the organization affect security controls Conduct periodic security control assessments

35 BAU Guidance Resources Guidance within PCI DSS Information Supplement: Best Practices for Maintaining PCI DSS Compliance

36 Partner with the Council

37 Training Highlights PCI Awareness Training PCI Essentials PCI Professional Program (PCIP) Internal Security Assessor (ISA) Online! Qualified Security Assessor (QSA) Qualified Integrators and Resellers (QIR) Program Corporate Group Training Let Us Come To You! To learn more, visit:

38 The Formula for PCI Success + + = Technology Processes People Security

39 Maintaining Security is Running a Marathon, not a Sprint

40 Save the Dates Community Meetings 2015

41 Please visit our website at

42 Questions?